Сказка. А может, и быль. В одной большой компании было несколько офисов, в частности, офис в городе A (в дальнейшем — просто Team А) и офис в городе B (в дальнейшем — просто Team B). В этих офисах практически в одно и то же время начинались два проекта для двух разных клиентов.
Команды были одинакового уровня технической экспертизы; использовали одинаковый набор технологий; оба проекта были примерно на одном уровне сложности бизнес-фукнциональности, а заказчики одинаково четко понимали, что им необходимо (PDF-документ в 10 листов). Оба проекта были оценены в четыре месяца разработки.
Начало
Предвидя риски сдачи проекта и то, что заказчик захочет больше оговоренного (как это обычно и бывает), Team A решила составить максимально детальную спецификацию, просчитать каждое отклонение, подписать это все у заказчика и только после этого приниматься за реализацию.
Team B решила писать документацию по ходу выполнения. Они пригласили Product Owner к себе и, собрав экспертную группу, закрылись с ним в одной комнате. Через две недели были готовы (довольно поверхностные) диаграммы модулей и их взаимодействия, определены технологии и используемые фреймворки, составлен продукт-беклог, уточнено и оценено задач на два спринта вперед, выбран спринт-беклог. Началась имплементация.
Коротко ли, долго ли — но прошел месяц.
Первые результаты
Team A дописала и дооформила очень детальную design specification, составила и утвердила (подписала у клиента) план проекта и была готова приступить к реализации.
Team B — как раз закончила первый спринт и демонстрировала клиенту первый релиз.
Быстро сказка сказывается, да не быстро код пишется и тестится.
Минул еще месяц
Team A с удивлением обнаружила, что после их первого релиза клиент поменял свои требования, и теперь они не совпадают с тем, что было зафиксированно и подписано. Клиент, скрепя сердце, соглашается с изменениями (подписано ведь) и платит за них. Архитектура проекта все больше и больше отклоняется от изначальной.
Что же происходит в Team B? Клиент тоже меняет требования, добавляет истории и детализацию в беклог. Количество feature points, в которые оценивается беклог, уже вдвое превысила тот «very basic», с которого начинали. Клиент волнуется что новый, раздутый скоп не будет выполнен к оговоренному времени. Однако он не платит за изменения и (после детального многочасового разъяснения ситуации), очень ответственно подходит к приоритезации задач.
Прошли оговоренные четыре месяца
Team A уже усердно трудится над новым проектом для нового заказчика. После очередной волны оплат за изменения клиент потерял веру, что когда либо увидит рабочий продукт, и пересмотрел свои приоритеты в финансировании.
Team B, успешно сдав клиенту «basic, but functional» версию, трудится над второй фазой (advanced). В неё перешло большинство «дополнительных» задач которые клиент увидел и добавил в ходе первого этапа. Клиент счастлив и поговаривает о фазе номер три.
Мораль
Здесь, как в известной песне: «Думайте сами, решайте сами — иметь или не иметь».
Очевидным фактом является то, что чем раньше заказчик видит результат, тем больше у него доверия к исполнителю. А доверие — это та основа, без которой невозможно построить качественный продукт, максимально полно отвечающий реалиям бизнеса.
Конечно, все это становится возможным при определенных обстоятельствах:
- Заказчик должен быть если не техническим специалистом, то по крайней мере экспертом в своей области, способным делиться знаниями;
- команда должна показывать абсолютно все, что происходит, включая внутренние проблемы;
- в начале проекта заказчик должен понять и принять то, что он платит за скорость работы и качество команды. И что обьем работ в данном случае есть величина производная, и влиять на него он может только балансируя между скоростью и качеством (в определенных пределах);
- заказчик должен быть достаточно мотивирован, чтобы выделять время на проект (лучше всего, когда это его единственный проект или он является владельцем бизнеса).
Конечно, можно сказать, что это чистая теория и агитация, условия требуют идеального заказчика и т.п. Но, во-первых, вся эта сказка происходила на моих собственных изумленных глазах. И во-вторых, вы никогда об этом не узнаете, пока сами не попробуете.
Ещё немного морали
Основная проблема компаний, продающих сервис по разработке ПО, заключается в том, что они часто увлекаются собственными целями, иногда в ущерб целям заказчика. Хотя любая такая компания на каждом углу рекламирует противоположное. Отсюда возникают риски, что заказчик уведет команду или не заплатит за проект; отсюда же возникает барьер закрытости и недоверия.
Однако я верю, что ситуация может быть другой, если с самого начала строить взаимоотношения на доверии и совместной работе в составе одной большой команды, не заморачиваясь на бюрократию и документы, которые очень быстро устареют.
Хотя, конечно, за четыре месяца Team А заработала больше денег за счет change request-ов. :-)
