Регламент работы студии по разработке 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 и т.д).
Далее — работаем по следующей инструкции:
1. Вы добавляете новые задачи в колонку “Backlog/Обсуждение”.
2. Если задача согласована, тогда мы переносим задачу в колонку “На оценке”.
3. После согласования цены и сроков задача берется “В работу”.
4. После выполнения задачи, необходимо, чтобы Вы подтвердили, что задача выполнена.
5. Если работа принята, то задача переносится в «Готово»
6. После полной оплаты (обычно, 1 раз в месяц) задача переносится в «Готово и Оплачено».
8.4 Комбинированный подход (оценка и планирование каждого этапа проекта по отдельности)
В случае, когда линейный подход в чистом виде невозможен по причине отсутствия у заказчика детальных требований и полноценного видения конечного результата, но клиент хочет больше предсказуемости по бюджету проекта, то мы предлагаем подход оценки каждого этапа по отдельности.
В первую очередь, мы оговариваем с заказчиком точную цену на этап проектирования и дизайна, а на последующие этапы (например, вёрстка по макетам, интеграция на CMS, программирование и пр.) мы даём примерную оценку “от” и “до”.
Чтобы запустить работы по дизайну нужно, относительно, не так много информации — количество оригинальных страниц и их примерная структура, сайты-примеры и понимание примерной цветовой схемы, логотипа, брендинга. Всё остальное выясняется в процессе взаимодействия веб-дизайнера с заказчиком.
В это время и с оглядкой на дизайн-макеты составляется техническое задание на последующие этапы разработки. Это позволяет сэкономить время и уменьшить сроки, так как этапы создания технического задания и отрисовки макетов идут параллельно.
