Всем нравится предсказуемость, особенно в бизнесе. Потому неудивительно, что, подготовив «детальное» техническое задание, Заказчик требует четкие сроки и стоимость и ждет реализации приложения своей мечты. Возможно ли это на деле?
Что написано пером, не вырубишь и топором. Все будет сделано именно так, как написано в ТЗ (не будем брать случаи, когда подрядчик упустил, не заметил требования), но чувство необъяснимого разочарования посещает практически всех заказчиков, кто выбрал схему “фикса”: предоплата-результат-постоплата.
Что такое «фикс»?
Это схема, при которой подрядчик заранее, согласно ТЗ, рассчитывает точную стоимость и срок разработки мобильного приложения перед стартом работ. Обычно заказчик вносит предоплату в размере 30%-50%, а через несколько месяцев получает готовый результат «под ключ», вносит постоплату (не будем брать в расчет разного рода акции, которые нацелены на завоевание клиентов). Данная схема подойдет для установки окон, изготовления дивана, но далеко не для любого программного обеспечения.
Если на полную реализацию приложения требуется меньше одного месяца, «фикс» вполне подойдет. Во всех остальных случаях mobile.SimbirSoft рекомендует работать по повременной или поэтапной моделям.
Основываясь на собственном опыте и опыте коллег, мы собрали копилку причин, почему не стоит выбирать «фикс» при разработке мобильного приложения.
Причина 1: Теорема Гёделя о неполноте в действии
Согласно теореме Гёделя любое высказывание неполно. Значит, как бы детально ни составлялось техническое задание, в нем всегда будут упущения, как фактического, так и эмоционального характера. Читая одну и ту же строчку, подрядчик и заказчик умудряются по-разному ее понять и вложить разный смысл. Несложно предположить результат.
Причина 2: Всё течет, всё изменяется
Так устроены люди, что нам может не нравиться то, что нравилось еще вчера, цели и задачи становятся иными в мгновение, одним словом, всё меняется. Изменению не поддается лишь разрабатываемое по “фиксу” мобильное приложение. Ибо по ТЗ. Изменения в проекты со стороны заказчика вносятся в 9 случаях из 10, и это легко объяснимо нашей человеческой натурой: всегда стремиться к лучшему. Допустим, ваше видение продукта немного поменялось, пришла в голову «новая фишка», а вы выбрали “фикс” для разработки. Неприятно, но скорее всего вы услышите: «Этого не было в ТЗ, нам придется кое-что переделать. Мы оценим и скажем сколько дополнительно это будет стоить».
Причина 3. Есть контакт?
При фиксированной схеме разработки устные контакты между подрядчиком и заказчиком, как правило, минимальны. О чем говорить? Все же решено, ждем результат. Но в этом и кроется большая опасность. Чем меньше встреч, созвонов и обсуждений, тем больше расходится видение результата мобильного приложения у клиента и подрядчика.
Дабы наши доводы были еще более убедительны, обратимся к статистике. По данным 2015 года, только 11% проектов были успешно завершены, а треть проектов не была закончена вовсе. Печально, не правда ли? Интересна закономерность: чем меньше проект, тем больше вероятность закончить его вовремя. Опять же, это объясняется изменениями и новыми функциями в проекте по желанию заказчика. В итоге — недовольны обе стороны: и заказчик, и подрядчик. И у каждого своя правда. Однако мобильное приложение все же разрабатывается для потребностей заказчика, а чаще — для его клиентов или сотрудников.
Как же сделать заказчика счастливым?
Для того, чтобы мобильное приложение точно отвечало требованиям и просто нравилось заказчику, мы, в mobile.SimbirSoft, рекомендуем выбирать поэтапную разработку. Это сочетание гибкости и предсказуемости, когда стоимость и срок определены на этап (чаще всего 2-3 недели).
Во время разработки этапа вы продолжаете общение со специалистами подрядчика, обсуждая функции для будущего этапа разработки. Если появился новый приоритет, это также будет учтено. Клиент и подрядчик становятся единой командой, что необходимо для успеха. По окончании каждого этапа проводится демонстрация логически завершенного блока. Таким образом, вы становитесь свидетелем рождения и развития своего мобильного приложения. Кстати, для старта работ по поэтапной схеме не требуется четкое ТЗ, оно будет создаваться как паспорт приложения по ходу работ, всегда на один этап впереди разработки.
Надеемся, что пролили свет, почему фиксированная схема не всегда хороша для разработки заказного мобильного приложения. Выбирайте гибкие схемы взаимодействия, и пусть ваши приложения соответствуют вашим ожиданиям.