Как быть довольным разработкой

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

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

Клиенты, редко имеющие дело с ИТ, боятся повременной разработки. Опасение внушает непредсказуемость бюджета и времени, т.к. вы оплачиваете работы по итогам отработанного периода.
Миф: при работе по T&M подрядчик всегда увеличивает часы на разработку и намеренно сдвигает сроки.
Реальность: уважающие себя компании планируют разработку и делят ее на этапы, даже работая повременно. Те, кто не может разработать продукт в срок по повременной схеме, не сдаст проект вовремя и по фиксированной.
В чем плюс: оплачиваете реально отработанные часы без рисковых резервов, которые заложил подрядчик, и не вносите предоплат - все по факту.

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

1. Если нужно начать работы быстро: вы не тратите время на разработку ТЗ и на согласование перечня задач в договорах.
2. Если не хотите бумажной работы: после подписания договора, вы подписываете только акты выполненных работ, а не многочисленные дополнительные соглашения.
3. Если продукт многоэкранный (15+ экранов), и вы не до конца представляете все тонкости работы приложения. Если ваши маркетологи обнаружили, что приложению срочно нужна новая красивая кнопка, разработчики начнут работу сегодня или завтра.
4. Если требуется интеграция с внешними системами, базами данных и API. Даже, если вы заранее дали разработчику все доступы и денёк на “посмотреть”, в процессе работы и интеграции все может пойти совсем по-другому. По T&M у разработчиков больше маневров гибко интегрироваться, что позволит выпустить продукт быстрее.

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

Большего доверия у клиентов снискала фиксированная схема работы. Несмотря на неудачный опыт, многие возвращаются к ней снова. Почему? Предсказуемость. Также есть такие, кто пытается “запугать” подрядчика штрафами.
Миф: если мы зафиксировали сроки, стоимость и состав работ, все будет идти так, как я запланировал.
Реальность: ТЗ никогда не бывает полным. Это значит, что в нем всегда будут моменты, которые вы и разработчики будете трактовать по-разному. Если хотите работать по fixed price, убедитесь, что сможете общаться с разработчиками на техническом языке и грамотно объяснять, что конкретно от них хотите.
В чем плюс: если детально проработали ТЗ и все идет строго по плану, вы сможете заранее спланировать траты и платить по графику.

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

1. Для разработки MVP - базового функционала, который будете дорабатывать позднее. Такие проекты длятся около месяца, и там редко что-то меняется.
2. Если вы не торопитесь. На разработку подробного ТЗ уйдет время (даже, если оно было), потом вы уточните оценку и состав работ и приступите к согласованию юридических документов. Если не боитесь, что кто-то выпустит похожий продукт раньше, - работайте по fixed price.
3. Если готовы к тому, что не сможете ничего изменить и добавить. Подрядчик делает только те задачи, которые понятны из ТЗ. Фразы: “Давайте добавим еще одну кнопочку, она маааленькая, но очень важная” тут не работают.
4. Если готовы платить больше. Не секрет, что подрядчики закладывают риски в оценки проектов по fixed price, а если присутствует интеграция со сторонними ресурсами, оценка, а, следовательно, и стоимость может быть увеличена вдвое.
5. Если готовы жить в неведении. Схема работает так: вы отдали материалы, разработчик ушел делать и по итогам показал результат.

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

Где же компромисс?

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

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

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

1. Если хотите видеть промежуточный результат. В отличие от фиксированной модели, где разработчики сами устанавливают ход разработки, при поэтапном подходе вы обсуждаете с подрядчиком приоритетность задач и радуетесь промежуточным результатам. Если в команде есть продуктовый менеджер - еще лучше, он поможет вам генерить идеи.
2. Если хотите управлять бюджетом и платить по частям. Вы знаете точную стоимость работ на этап и платите ее аванс-постоплата. Очень удобно в отличие от схемы “половину за весь проект”.
3. Если хотите первый результат в кратчайшие сроки: поэтапная модель подразумевает, что базовая версия продукта будет готова уже после первых этапов. Уже возможно провести первое тестирование на реальных пользователях.

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



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

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