Vigilantia ad vitandum incrementum
А вот ещё как бывает. Работаете по ватерфолу, как правильные пацаны бьёте проект на итерации, показываете заказчику промежуточные версии продукта, собираете обратную связь. Он же в ответ: «А сделайте ещё, пожалуйста, вот такую функцию, она же логична». Не хочется портить отношения с заказчиком, но таких хотелок может набраться десятка полтора и они могут вылиться в существенную сумму.
В этой статье рассказываю соображения о том, как работать с такими хотелками и держать бюджет в узде.
01
Перезакладывайтесь на этапе продажи. Процент зависит от особенностей заказчика, но 5 % должно хватить. Потом, если когда заказчик придёт с новыми хотелками, зафиксируете их, оцените и отследите, не превысили ли этот буфер.
02
Там же, на этапе продажи, договаривайтесь с заказчиком о том, чтобы он заложил в свои бюджеты до 10 % на дополнительные хотелки. Это спасёт вас от ситуации, когда заказчик, в целом, согласен, что эти работы не входили в скоуп, но бюджеты уже зафиксированные и влить в проект новые деньги невозможно.
03
Если темна вода в облацех, попробуйте договориться в первую очередь делать не сам проект, а аудит или пилот. Эти манипуляции не отнимут много денег, а плюсов дадут массу. Заказчик сам лучше поймёт, что именно хочет получить от основного проекта, вы поймёте, насколько заказчик охоч до накидывания хотелок.
04
Хорошие результаты даёт работа с портфолио и референсами. Если проект относительно типовой, проведите для заказчика подробную демонстрацию продукта, который ранее разрабатывала ваша компания и который похож на то, что хочет получить заказчик.
05
Проведите демо требований. Не торопитесь фрахтовать разработчиков, возьмите аналитика, дизайнера и архитектора, составьте юзкейсы и юзер стори, сделайте из них презентацию со связными процессами, вайрфреймами, соберите из вайрфреймов в фигме кликабельный прототип. Всё это тоже стоит недорого и включает у заказчика механизм выработки проектной «слюны», увидев прототипы, он может тут же выдать большую часть дополнительных требований и вы сможете оценить проект более качественно.
06
MVP. Что бы ни говорили о том, что концепция MVP устарела, это всё ещё отличный инструмент. Если никакие из вышеперечисленных методов не сработали, выделите на первую фазу разработки только одну-две ключевые функции, решающие ключевые боли пользователей. MVP будет проще оценить более точно, чем весь проект, вы здорово подстрахуетесь.
07
Управление ожиданиями. О важнейшей функции руководителя проекта нельзя забывать. На всех этапах заказчик должен точно представлять, что он получит в результате итерации и проекта целиком, как повлияет на параметры проекта каждое из его требований.
08
Процедура управления изменениями. «На берегу» договоритесь с заказчиком, как будете работать с изменениями. Кто может генерировать хотелки, какую валидацию они должны проходить, как будем работать с бюджетом, за счёт чего его расширять. Проговорите, какие хотелки вы сделаете «бесплатно» и при каких условиях. Хорошо бы закрепить эти договорённости в договоре.
09
Наладьте учёт изменений внутри команды. Определите, кто должен фиксировать изменения и вести их учёт. На мой взгляд, это должен делать аналитик, но если проект не очень разлапистый, можно и самому.
10
Научитесь говорить заказчику «нет». Для этого вам потребуются доверительные отношения с руководством, нужно быть уверенным, что после того, как заказчик попросит сделать хрень и вы ему откажете, директор вас не уволит. В продуктовой разработке с этим проще, конечно.
11
Проговорите с заказчиком, что каждая хотелка должна фиксироваться письмом и заказчик обязан ответным письмом её согласовать. Иначе потом никому ничего не докажете.
Задача со звёздочкой — всё то же самое с госами. На прошлом проекте мне таким макаревичем прилетело доработок на 921 час при оценке основного проекта около 5000 часов.
Оформить допсоглашение на эти часы решительно невозможно, госы всё делают исключительно через тендер. Часть хотелок прилетела в процессе переговоров по тендеру, часть уже после того, как тендерная процедура была завершена. Выкрутились, заключив договор техподдержки на нужно количество часов, с техподдержкой с юридической точки зрения всё чуть проще.
В целом, чтобы успешно отрабатывать попытки растянуть ваш «треугольник», нужно обговаривать условия на берегу, не лениться всё фиксировать, а также дружить с аккаунтами и сейлзами, которые помогут выбить дополнительные бюджеты, если соблюдение приведённых выше рекомендаций ни к чему не привело.
Ну и пишите ТЗ поподобнее.
