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

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

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

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

Если компания не продала часть часов, то она потеряла#nbsp;деньги. Это заставляет компанию торопить разработку или устанавливать минимальный лимит по часам.

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

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

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

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

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

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

Микроменеджмент — стиль управления, который подразумевает контроль каждого шага исполнителя. Микроменеджмент от заказчика появляется из-за отсутствия доверия и создает токсичную атмосферу. Для того, чтобы у вас не было желания микроменежить, создайте прозрачныеи удобные инструменты управления проектом.

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

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

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

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