Возникает вопрос: а почему, собственно нужна такая обратная связь? Ведь задачи в процессе исполнения перемещались по доске, каждая смена статуса имела свой чек-лист завершения, включая, естественно, критерий сделанной задачи, Definition of Done (DoD)? Разве этого недостаточно? Ответ – нет, недостаточно. Если бы ценность задачи можно было бы обеспечить выполнением чек-листа, то никакой бы Agile был не нужен, с организацией IT-проектов хорошо бы справились методы классического менеджмента. Проблема состоит в высокой сложности социотехнических систем, в результате чего все представления о необходимых функциях и о работе пользователей – не более чем гипотезы, подлежащие проверки. А на бытовом уровне эта ситуация хорошо описывается словами «заказчик сам не знает, чего он хочет». Именно поэтому разработанный софт требует постоянной проверки: несет ли он ценность пользователям. Впрочем, тоже самое можно сказать о любых других продуктах – проверить, полезен ли он потребителям, нужен ли им можно только экспериментально.

Обычно Демо проводится в виде встречи, на которой присутствует команда и все заинтересованные стейкхолдеры: члены команды демонстрируют созданную ценность и получают обратную связь. Именно такую форму рекомендует Scrum Guide. Процедура кажется простой, однако практически с таким способом связано несколько проблем, которые мы обсудим далее.

Проблемы получения релевантной обратной связи

Итак, какие же проблемы могут быть связаны с простой демонстрацией?

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

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

Отметим, что далеко не всегда эти проблему могут быть в конкретно вашем проекте. Наоборот, в большинстве проектов демонстрации стейкхолдерам достаточно, иначе бы в Scrum Guide не было бы рекомендованного способа. Ну или так было, когда Scrum формировался. Отметим, кстати, что переход от функциональных требований к user story отчасти проблемы демонстрации решал: мы вместо выполнения функций описывали цели пользователей, и демонстрация, как пользователи будут их достигать, работая используя разработанный софт, должна быть достаточна. Однако, что делать, если проблема в вашем проекте существует? Правильный способ решения этих проблем – придумать альтернативные механизмы получения релевантной обратной связи и встроить в процесс именно их, чтобы обеспечить выполнение основной функции демо. Например, в цикл выполнения задачи может быть включено не только тестирование, но выкатка на боевые сервера и A/B тестирование на пользователях. Или установка его на тестовые сервера заказчика с приближенными к боевым данными, и проведение обучения и демонстрации конечным пользователям. Таким образом, есть различные варианты. Но на практике вместо разработки механизмов часто просто назначают формального ответственного «ты будешь смотреть и оценишь результат». И в результате команда идет по неверному пути, а выясняется это только на внедрении функционала. Я слышал истории, когда эти проблемы возникали даже когда таким ответственным стейкхолдером был руководитель проекта от заказчика: он был на демо, был очень доволен, команда была вдохновленной. А потом оказалось, что он не слишком давно работает у заказчика, и его представления о процессе были основаны на опыте работы в другом месте. Поэтому, когда функционал принесли конечным пользователям, то выяснили его слабую пригодность для реального процесса. Заметим, что техническая выкатка изменений на боевые сервера не спасает, так как пользователи, не зная о новых функциях им просто не пользуются. А вот изменение работы пользователей в любом случае надо отдельно организовывать.