Существует универсальная проблема бесконечных согласований ТЗ. Чтобы побороться с ней, на реальном проекте для регуляторной отчетности одна из наших команд решила попробовать творчески переосмыслить классический итерационный процесс.

- Вместо согласований документа, были запущены регулярки по совместному чтению спецификации командой ИТ и ответственными сотрудниками отчетности. Встречи от 3 до 5 раз в неделю, каждая по часу, которые сразу были выставлены на 3 месяца вперед и лонгировались при необходимости. Заказчики научились встраивать их в свой перегруженный график, привыкли на них ходить, была некоторая взаимозаменяемость, если ключевой ответственный за форму таки не мог прийти.

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

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

- Как следствие, разработка всегда могла реализовывать "бэк на минималках" еще на старте согласований, который давал возможность начать делать сверку на реальных данных. А UI со всеми его миллионами "бантиков", отладка и рихтовка алгоритмов - все это откладывалось до утряски того или иного вопроса сквозь десятки микро итераций.

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

В этом месте мы со студентами задумались, какая команда нужна, чтобы эффективно работать на сложном ИТ проекте?

Предыдущий пост #РПКлассики