Бесконечная разработка

Проект не заканчивается бесконечное количество времени, постоянное ощущение недоработки, все планы и представляемые в начале проекта сроки нарушены... Знакомая ситуация? Разберем в этой статье причины подобных ситуаций, и как их избежать на практике.

Бесконечная разработка или доработка - это распространенная "ловушка" разработки, и вполне реальная. К попаданию проекта в подобную ловушку могут быть причастны как исполнители, так и заказчики.

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

Главная задача разработчика - составить план, не терять его из фокуса и управлять ходом разработки.

Именно исполнитель должен управлять разработкой, направляя команду и правильно распределяя задачи. План необходим для грамтоного распределения ресурсов. А вместо изменения процессов "на ходу", открывая огромное окно для рисков качества и сроков разработки, иногда лучше донести заказчику важность соблюдения изначального плана.

Ошибки заказчика, в основном, заключаются в слабой вовлеченности на старте проекта, а также в бесконтрольной тяге к модернизациями и улучшениям еще не реализованного проекта. Это нормально, но с этим надо правильно работать, в том числе и разработчикам. В целом, если говорить о разработке, то управлять разработкой должны именно разработчики - аккуратно, но твердо направлять проект и клиента к желаемому результату должны те специалисты, которые имеют опыт реализации подобных разработок. Что же касается самих ошибок - например, на этапе формирования технического задания разработчик лишь общими мазками описал планируемый функционал и инструментарий, исходя из запроса и данных, предоставленных заказчиком, но, при этом, задал множество уточняющих вопросов, а заказчик, особо не вникая, согласовал задачу, не обозначив какие-то мелкие, но важные требования. В итоге, по завершении первых этапов на взгляд исполнителя всё выполнено корректно, а на взгляд заказчика получилось вообще не то, что было нужно. Однако, бывают случаи, когда объем проекта действительно не до конца ясен, а логика каждого блока сформировывается в процессе работы над ним.
Также опасна ситуация, описанная выше - заказчик уже в процессе разработки по заданному плану начинает требовать срочные доработки, настаивая на пересмотре плана разработки.

Главная задача заказчика - предоставлять по запросу все данные, давать развернутые ответы даже на повторно заданные вопросы, а также не настаивать на срочных доработках и изменениях.

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

Для достижения максимально качественного результата требуется соблюдать три пункта:

1. Разработчику - максимально погрузиться в процессы компании заказчика, а заказчику - максимально подробно рассказать об этих процессах.
При взаимодействии чем больше информации будет друг у друга с обеих сторон, тем более точный и качественный результат получится по итогу разработки, и тем меньше доработок и уточнений потребуется в процессе.

2. Разработчику - составить дорожную карту / план разработки, не отклоняться от него, и курировать разработку
Разработчики должны составить дорожную карту / план, и следить за тем, чтобы обе стороны придерживались этого плана (за исключением случаев, когда какие-то пункты плана неактуальны и нецелесообразны к реализации). Возможно построение двух карт - краткосрочной и долгосрочной. В долгосрочной разработчики на старте сотрудничества прописывают глобальные задачи с приблизительным стартом работ и дедлайном (безусловно, даты могут корректироваться, но находиться плюс-минус в изначальном диапазоне). В краткосрочной карте глобальные задачи разбиваются внутри блоков проекта на более мелкие, также с датами старта и дедлайнами. Краткосрочная дорожная карта дописывается и корректируется в течении всего проекта, используя долгосрочную как основной план - это нормально, особенно для средних и больших проектов.

3. Заказчику - не торопиться со стартом проекта и идеями в процессе.
Во-первых, как бы это не звучало, заказчику иногда нужно уметь "умерить аппетит". Замечательная фраза “аппетит приходит во время еды” идеально описывает ситуацию, а в работе над объемными проектами такой "аппетит" играет скорее негативную роль, чем позитивную. Как мы писали выше, требуется взвешивать реальную срочность доработок и согласовывать их с разработчиками (а разработчики могут отказать, объяснив причины отказа в корретировке плана). Во-вторых, не торопиться с запуском. Мы никогда не торопим клиента, и, наоборот, просим больше времени на этапе погружения в проект и составления Технического Задания. Грамотно составленная карта / план, расписанное ТЗ, учёт всех нюансов и деталей, а также моделирование ситуаций использования конечного продукта значительно сокращает количество и срок доработок в дальнейшем. То есть неспешный, но выверенный старт разработки способствует ускорению самой работы над проектом, в перспективе снижая общий срок разработки. Мы не одобряем подход запуска проекта с фразой “По пути разберемся”, потому что срочный и быстрый запуск с крайне сжатыми сроками старта дает лишь мнимую иллюзию скорости - при таком подходе проект как раз погрязнет в "бесконечных доработках", или результат будет не удовлетворяющим. Требуйте план или дорожную карту разработки вашего проекта, как минимум глобальную, а, в идеале, расписанную по первому блоку. Также важно перед обращением к исполнителю для себя расставить приоритеты, что требуется закрыть в ближайшее время, а что можно делать параллельно или следующими этапами.

Считайте свое время и деньги, правильно расставляйте приоритеты и выбирайте опытных исполнителей.