Статьи / RU

О чём стоит договориться с студией разработки?

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

Простои

Представим, что вы работаете с разработчиком/студией/подрядчиком по формату Т&Mпредыдущей статье я писал о плюсах и минусах этого формата). В этом формате исполнитель получает оплату за потраченные на проект часы.

Если студия нанимает разработчиков в штат, то она платит им фиксированную з/п в месяц. Другими словами, компания выкупает ~160 рабочих часов в месяц у человека и пытается их продать.

Если компания не продала часть часов, то она потеряла деньги. Это заставляет компанию торопить разработку или устанавливать минимальный лимит по часам.
null
СЕО along, когда разработчики простаивают
На придумывание и тестирование фич требуется время, которого у вас в таком формате работы не будет. Каждый день задержки создает напряженность между вами и подрядчиком.

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

Вовлеченность

Треть наших клиентов отказалась от предыдущей команды из-за низкой вовлеченности. И нет, вовлеченность это не про овертаймы по выходным и не про «быть на связи 24/7».
Вовлеченность — это желание и умение разработчиков думать о смысле того, что они делают. Заказчик далеко не всегда принимает правильные продуктовые решения. Ищите разработчиков, которые будут с вами спорить и доказывать вам, что вы неправы.

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

Обсудите уровень вовлеченностина берегу: будут ли разработчики с вами спорить, или же просто работать по вашему ТЗ?

Нет микроменедждменту!

Микроменеджмент — стиль управления, который подразумевает контроль каждого шага исполнителя. Микроменеджмент от заказчика появляется из-за отсутствия доверия и создает токсичную атмосферу. Для того, чтобы у вас не было желания микроменежить, создайте прозрачныеи удобные инструменты управления проектом.
  • Продуктовые требования советую собирать в гугл документах и прорабатывать предложения через гугл комментарии — так они не потеряются.
  • Комментарии по дизайну/UX/анимациям можно оставлять в виде комментариев в figma — по аналогии с гугл документами.
  • Попросите разработчиков настроить автоматический пайплайн публикации приложения в TestFlight (для iOS) или генерации apk (для android). Мы получаем фидбэк от клиента при каждом новом релизе. Заказчик смотрит результат нашей работы в любое время и в любом месте.
  • Если вы работаете по часам, то создайте прозрачный процесс отчетности. Попросите разработчиков использовать трекеры и собирать отчеты в часах в одном месте. Мы используем Clockify (Toggle тоже отличный вариант). Вам не придется каждый раз спрашивать менеджера проекта о том, “сколько мы потратили денег”.

При этом старайтесь доверять вашей команде и не надоедать постоянными вопросами в духе “почему эта задача заняла 5 часов, хотя мы планировали 4”? О доверии я писал в первой части  этой статьи.

О чём стоит договориться?

  • Договоритесь о том, кто будет платить за простои. Готовы ли вы платить за них?
  • Договоритесь об уровне вовлеченности. Готовы ли вы дать разработчикам свободу принимать решения?
Договоритесь о прозрачных процессах, чтобы вам не пришлось микроменеджить. Готовы ли вы доверять разработчикам?