Модели сотрудничества: Как быть довольными разработкой, а не стать их жертвами?

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

Самые популярные модели сотрудничества — это повременная, известная как Time&Material (T&M), и фиксированная (fixed price).

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

Повременная разработка

Миф: при работе по T&M подрядчик всегда увеличивает часы на разработку и намеренно сдвигает сроки.

Реальность: уважающие себя компании планируют разработку и делят ее на этапы, даже работая повременно. Те, кто не может разработать продукт в срок по повременной схеме, не сдаст проект вовремя и по фиксированной.

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

Вам подходит T&M:

Если нужно начать работы быстро: вы не тратите время на разработку ТЗ и на согласование перечня задач в договорах.

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

Если продукт многоэкранный (15+ экранов) и вы не до конца представляете все тонкости работы приложения. Если ваши маркетологи обнаружили, что приложению срочно нужна новая красивая кнопка, разработчики начнут работу сегодня или завтра.

Если требуется интеграция с внешними системами, базами данных и API. Даже, если вы заранее дали разработчику все доступы и денёк на «посмотреть», в процессе работы и интеграции все может пойти совсем по-другому. По T&M у разработчиков больше маневров гибко интегрироваться, что позволит выпустить продукт быстрее.

Лайфхак: перед началом работ попросите разработчика предоставить предварительный план работ (роуд мап). Если ничего не будете менять и добавлять, сроки сдачи проекта вряд ли изменятся. Общайтесь с командой минимум раз в неделю на предмет того, что происходит на проекте и что планируется на следующей неделе. Если технические термины не понятны — не страшно! У любого проекта есть выделенный менеджер, который переведет их с «технического» языка на «человеческий».

Фиксированная разработка

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

Миф: если мы зафиксировали сроки, стоимость и состав работ, все будет идти так, как я запланировал.

Реальность: ТЗ никогда не бывает полным. Это значит, что в нем всегда будут моменты, которые вы и разработчики будете трактовать по-разному. Если хотите работать по fixed price, убедитесь, что вы сможете общаться с разработчиками на техническом языке и грамотно объяснять, что конкретно от них хотите.

В чем плюс: если детально проработали ТЗ и все идет строго по плану, вы сможете заранее спланировать траты и платить по графику.

Вам подходит fixed-price:

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

Если вы не торопитесь. На разработку подробного ТЗ уйдет время (даже, если оно было), потом вы уточните оценку и состав работ и приступите к согласованию юридических документов. Если не боитесь, что кто-то выпустит похожий продукт раньше — работайте по fixed price.

Если готовы к тому, что не сможете ничего изменить и добавить. Подрядчик делает только те задачи, которые понятны из ТЗ. Фразы: «Давайте добавим еще одну кнопочку, она маааленькая, но очень важная» тут не сработают.

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

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

Лайфхак: основная трудность взаимодействия по fixed price — отсутствие промежуточных результатов. Это значит, что вы отдаете материалы, вносите аванс, а потом получаете нечто, что должно быть похоже на изначальное ТЗ. На практике получается, что больше половины проектов не делаются вовремя, и это не всегда вина исполнителя. Найдите компромиссное решение с подрядчиком — и оба будете довольны результатом.

Компромисс: поэтапная модель

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

Что это такое? При работе по гибким методологиям Agile разработчики делят реализацию приложения на этапы. Каждый этап длится 2-3 недели, а по итогам демонстрируется логически завершенный функционал. Мы фиксируем с клиентами план работ и его стоимость на каждый этап и вносим изменения и дополнения после сдачи каждого из них.

Миф: даже работая по поэтапной модели разработчик может не уложиться в мой бюджет.

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

В чем плюс: управляйте бюджетом, расставляйте приоритеты и участвуйте в процессе. Получаете готовую версию в кратчайшие сроки.

Вам подходит поэтапная схема (limited):

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

Если хотите управлять бюджетом и платить по частям. Вы знаете точную стоимость работ на этап и платите ее аванс-постоплата. Очень удобно в отличие от схемы «половину за весь проект».

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

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

Примерно треть проектов, с которыми в mobile.SimbirSoft обращаются клиенты, — это приложения, по которым уже велась разработка, но успешно не завершилась. При этом клиенты видели, что что-то идет не по плану, но продолжали ждать и надеяться, что в итоге получат работающий продукт. В таких случаях у нас есть один совет: если видите, что работы идут не так, как должны (сроки срываются, промежуточные результаты не демонстрируются) — смените подрядчика. Практика показывает, что это дешевле и быстрее, чем пытаться запугать или оштрафовать текущих разработчиков.

Работайте с разработчиками грамотно. Вникайте в процесс разработки, а не избегайте его. Тогда успех гарантирован.