Главная / Блог / Регламент работы студии по разработке OnePix

Регламент работы студии по разработке сайтов OnePix

Рекомендации для комфортной и продуктивной работы

Регламент работы студии по разработке сайтов OnePix

1. Рабочее время команды

Рабочее время команды начинается в 10:00 и заканчивается в 20:00 по московскому времени в будние дни (суббота и воскресенье выходные). В этот промежуток мы готовы оперативно отвечать на все интересующие Вас вопросы, давать обратную связь и комментарии. В остальное время мы отвечаем по возможности или в каком-либо экстренном случае. Тем не менее, заказчик может оставлять сообщения в нерабочее время, мы их обработаем в рамках рабочих часов.

2. Время ответа в чатах

Время ответа в чатах составляет до 2-3 часов в рамках рабочего дня. В зависимости от загрузки команды проекта. Если для того, чтобы ответить на вопрос нужно провести подготовительную работу, то в течении данного времени мы напишем, что вопрос «Принят» к рассмотрению и постараемся обозначить время, в течении которого дадим ответ на вопрос.

3. Состав команды проекта

Команда проекта состоит, как правило, из менеджера проекта (отвечает за коммуникацию и организационные вопросы), тимлида проекта (отвечает за техническую составляющую).

По всем организационным вопросам можно обращаться к менеджеру проекта, по техническим вопросам к тимлиду проекта. Однако, каждый проект индивидуален и состав команды зависит от его требований и объёма.

4. Коммуникация по проекту

Ведётся удобным для заказчика способом (Telegram/WhatsApp/Skype/Slack) в общем чате по проекту.

5.  Звонки и переписки

Звонки и переписки заказчика с командой проекта важно вести в общем чате, а не в личном. Это необходимо, так как все участники проекта будут видеть все договоренности и историю переговоров. Что позволит, в случае необходимости (например, больничный, отпуск), безболезненно передать проект другому менеджеру/тимлиду.

6.  Общение с разработчиками

Обратную связь, комментарии и вопросы по проекту от заказчика предпочтительнее получать в текстовом формате в общем чате или, например, в Trello, а не аудиосообщением или звонком.

Это позволит увеличить скорость внесения необходимых изменений со стороны разработки, так как менеджеру проекта, всё равно, необходимо перевести все договорённости в текстовый вид, чтобы поставить задачу разработчикам.

Однако, каждый вопрос индивидуален и иногда бывает так, что проще созвониться, чем написать.

7.  Плановая загрузка команды

Наша компания планирует загрузку разработчиков на день (ежедневно в 10:00 по московскому времени) и на неделю (каждый понедельник). Поэтому мы всегда стараемся получать заявки от заказчиков перед планированием, чтобы иметь возможность более точно прогнозировать загрузку команды и сроки проектов. Однако, мы всегда оставляем запас в районе 20% от времени разработчиков, чтобы иметь возможность выделять время на экстренные задачи, которые могут возникнуть у наших заказчиков.

8.  Подходы ведения проектов

В нашей компании есть несколько подходов к ведению проектов. Выбор подхода работы зависит, в первую очередь, от наличия у заказчика видения конечного результата, требований и технического задания.

8.1  Линейный подход

Линейный подход — основные требования заказчика собираются в начале проекта а затем создается последовательный план для реализации этих требований (например, 1 этап — дизайн, 2 этап — вёрстка, 3 этап — программирование и интеграция на CMS). Такой подход даёт хороший результат в проектах с заранее определенными требованиями и способами их реализации. В основном, он подходит для проектов с фиксированным бюджетом, где необходимо разработать сайт или функционал “с нуля”.

Однако, у данного подхода есть нюанс. Он заключается в том, что в процессе реализации проекта у заказчика могут появиться новые требования (изменения/добавления в макетах или функционале и т.п.), которые не были заранее оговорены и запланированы для разработки.

В ситуации, когда в процессе работы появляются новые требования мы готовы идти на встречу и вносить необходимые изменения, отклоняясь от первичного технического задания, однако заказчик должен понимать, что это может повлиять на смету и сроки проекта в сторону увеличения. Поэтому мы не рекомендуем вносить изменения в требования до полного выполнения первичного ТЗ, чтобы не увеличивать сроки проекта. Мы сторонники того, чтобы сначала выполнить основную и первично оговоренную часть задания и только после приёмки результата дорабатывать и модернизировать продукт по новым требованиям.

8.2  Гибкий подход

Гибкий подход основан на том, что команде разработки не требуется детального технического задания, которое, в отличии от линейного подхода, не подлежит изменениям на протяжении всего проекта. Также, не предполагается поэтапное планирование, так как гибкий подход построен на спринтах (временных отрезках) длительность 1-2 недели между встречами исполнителя и заказчика. В рамках данных встреч выделяются приоритеты, ставятся задачи и оценивается выполнение задач, поставленных на предыдущий спринт. В процессе взаимодействия исполнителя и заказчика формируется и разрабатывается продукт, концепция которого может значительно отличаться от первоначальной. 

Бюджет в таких проектах не фиксированный, а считается за фактически отработанное время исполнителем в рамках примерного “от” и “до” прогноза по спринту.

8.3 Форматы поддержки

Как правило, на подобных проектах мы создаём доску в формате канбан в любой удобной для Вас системе (trello, notion и т.д).

Далее — работаем по следующей инструкции:

Trello инструкция

1. Вы добавляете новые задачи в колонку “Backlog/Обсуждение”.

2. Если задача согласована, тогда мы переносим задачу в колонку “На оценке”.

3. После согласования цены и сроков задача берется “В работу”.

4. После выполнения задачи, необходимо, чтобы Вы подтвердили, что задача выполнена.

5. Если работа принята, то задача переносится в «Готово»

6. После полной оплаты (обычно, 1 раз в месяц) задача переносится в «Готово и Оплачено».

8.4 Комбинированный подход (оценка и планирование каждого этапа проекта по отдельности)

В случае, когда линейный подход в чистом виде невозможен по причине отсутствия у заказчика детальных требований и полноценного видения конечного результата, но клиент хочет больше предсказуемости по бюджету проекта, то мы предлагаем подход оценки каждого этапа по отдельности.

В первую очередь, мы оговариваем с заказчиком точную цену на этап проектирования и дизайна, а на последующие этапы (например, вёрстка по макетам, интеграция на CMS, программирование и пр.) мы даём  примерную оценку “от” и “до”. 

Чтобы запустить работы по дизайну нужно, относительно, не так много информации — количество оригинальных страниц и их примерная структура, сайты-примеры и понимание примерной цветовой схемы, логотипа, брендинга. Всё остальное выясняется в процессе взаимодействия веб-дизайнера с заказчиком. 

В это время и с оглядкой на дизайн-макеты составляется техническое задание на последующие этапы разработки. Это позволяет сэкономить время и уменьшить сроки, так как этапы создания технического задания и отрисовки макетов идут параллельно.

Доверьте нам создание сайта под ключ для вашего бизнеса!

Мы готовы обсудить ваш проект, создать стратегию реализации сайта и сформировать индивидуальное предложение. У вас есть вопросы? Просто оставьте заявку на сайте и мы свяжемся с вами в ближайшее время.

Получить консультацию Наше портфолио