Как не потерять деньги и время при взаимодействии с заказной разработкой?

Как не потерять деньги и время при взаимодействии с заказной разработкой?

Аутсорс-разработка может предоставить заказчикам бизнес-аналитиков, менеджеров продуктов, UX-дизайнеров, менеджеров проектов, разработчиков — то есть обеспечить полный цикл создания digital-продукта. Расскажу про несколько типов компаний, которые доверяют разработку подрядчикам, и дам рекомендации — на что им обращать внимание. 

Крупные офлайн-бизнесы без собственного отдела разработки (фарма, продуктовые сети)

Типичные запросы: автоматизировать бизнес-процессы и внутренние решения, выпустить свое приложение. 

Такие компании умеют считать деньги и понимают: заказать внешнюю разработку дешевле, чем набрать штат разработчиков, аналитиков, UX-дизайнеров и т.д. Тем более, потом с этими сотрудниками надо что-то делать — загружать работой или распускать. А это невыгодно.

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

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

Мы пишем о менеджменте продуктов и развитии в телеграм-каналах make sense и Продуктовое мышление.

Менеджеры продуктов или CTO 

Типичные запросы: целый продукт или часть продукта — причем только разработка. 

На что обратить внимание: важно иметь подробную документацию (визуализированное техзадание, User Story, User Flow и т.д.) и четко понимать, какой нужен дизайн. И я считаю, что проектирование продукта все равно лучше отдать подрядчику — оно плотно связано с разработкой и  не все дизайнеры способны понять, насколько сложно создавать продукт по их макетам, удобно ли будет конечным пользователям. 

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

Стартапы или компании, которые приходят от других подрядчиков

Типичные запросы: переписать продукт, незаметно для пользователей постепенно заменить старые компоненты на новые.

Обычно стартапы первое решение делают силами разных разработчиков и фрилансеров — просто чтобы работало. А когда вырастают, все начинает ломаться: первое техническое решение уже не справляется с возросшим трафиком, надо переписывать продукт практически с нуля. Сложность в том, что одновременно приходится поддерживать прежнюю версию продукта, переписывать отдельные компоненты и поочередно подключать их, следя, чтобы ничего не сломалось. 

На что обратить внимание: на приоритизацию бэклога. У таких клиентов есть задачи двух типов — исправление багов и разработка новых фич. Подрядчик ставит на проект выделенную команду, которая будет заниматься только этим клиентом, а такая команда не может «попилить» пару часов сегодня, потом вернуться к проекту через неделю. 

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

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

Корпораты уровня Сбера

Типичные запросы: сделать какой-то крупный фрагмент продукта или целый продукт. 

На что обратить внимание: заранее определиться с графиком выпуска всех компонентов, в которые будут интегрироваться решения, отданные на аутсорс; составить четкие требования к архитектуре; выдать подрядчику подробную внутреннюю политику разработки. Это вопросы, которые курирует CTO со стороны клиента. У таких компаний обычно есть своя сложившаяся экосистема, и от них нужны прозрачные и подробно описанные принципы разработки. Тогда сотрудничество, скорее всего, будет успешным. Если же внутренние процессы и стандарты не описаны, тяжело будет обеим сторонам.

Универсальные советы для взаимодействия с заказной разработкой

Всем, кто идет за аутсорс-разработкой, я рекомендую четко прописать процессы взаимодействия: 

  • Как принимается работа?
  • Когда подрядчик отдает код, какими частями?
  • Что будет, если заболеет программист или возникнут непредвиденные обстоятельства?
  • В каком виде передается отчетность?
  • Как глубоко заказчик погружается в процесс разработки?
  • Как происходит согласование, что именно согласовывается. Например, что будет, если заказчику не понравился дизайн? Сколько «бесплатных» правок включено в договор? 

Хороший подрядчик должен сам рассказать обо всех этих процессах и разрешении спорных моментов — причем объяснить весь путь, вплоть до окончания контракта и даже чуть дальше. Ведь после релиза продукта расходы не заканчиваются — платформы (например, Android или iOS) могут обновиться, понадобится техподдержка и небольшие доработки, обнаружатся баги. И надо понимать, по какому прайсу, в каком порядке и как все это будет исправляться — и будут ли это делать те же исполнители, которые работали над продуктом.

Какого подрядчика выбрать

Надо определиться со своими приоритетами: что вам важнее — скорость, качество или стоимость? 

  1. Если вы стартап и на текущем этапе качество вам не столь важно, выбирайте близкого себе по духу подрядчика и не забывайте про аналитику. В можете нанять на фрилансе недорогих junior и middle-разработчиков, которые все делают — не очень быстро, но дешево. 
  2. Если в приоритетах скорость и качество, то надо обращаться в студию формата нашей Progress Engine. Будет дорого, зато с гарантированным качеством и очень быстро. 
  3. Если необходимо сделать брендовый продукт — надо обращаться к проверенным знакомым подрядчикам или ориентироваться на премии и награды. Мнению экспертного сообщества можно доверять.

Что проверить: существуют компании, которые выставляют на сайте в разделе «Наши клиенты» логотипы известных брендов, а по факту с ними не работали. Поэтому надо спрашивать, какой именно продукт они делали, могут ли показать рекомендательные письма, дать контакты клиентов, которые готовы предоставить отзыв о совместной работе.

Добавить комментарий

ProductSense'22 — 10-11 октября, конференция по менеджменту продуктов Узнать больше