Каждый, кто сталкивался с необходимостью разработки программного продукта, знает, как важно выбрать подходящую схему взаимодействия с компанией-разработчиком. Понимание того, как и в каком темпе идет разработка, вовлеченность обеих сторон помогает сделать интересный и качественный продукт. Сегодня мы рассказываем о преимуществах и недостатках существующих моделей, и как использовать их с выгодой для себя.
Самые популярные модели сотрудничества — это повременная, известная как 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 обращаются клиенты, — это приложения, по которым уже велась разработка, но успешно не завершилась. При этом клиенты видели, что что-то идет не по плану, но продолжали ждать и надеяться, что в итоге получат работающий продукт. В таких случаях у нас есть один совет: если видите, что работы идут не так, как должны (сроки срываются, промежуточные результаты не демонстрируются) — смените подрядчика. Практика показывает, что это дешевле и быстрее, чем пытаться запугать или оштрафовать текущих разработчиков.
Работайте с разработчиками грамотно. Вникайте в процесс разработки, а не избегайте его. Тогда успех гарантирован.