Однажды на вебинаре я рассказывала о работе с заинтересованными сторонами (стейкхолдерами) и заметила как сложно слушателям принимать, что заинтересованные стороны - это не обязательно только те, кто владеет бюджетом на разработку или кто будет пользоваться результатом. Недавно вспомнила об этом наблюдении, когда на предложение расширить круг заинтересованных в новой фиче услышала от коллеги: "Я общаюсь непосредственно с заказчиком!" Действительно, есть устоявшийся термин «заказчик», который выглядит привычным и понятным в контексте заказной проектной разработки, в силу привычки термин перекочевал и в продуктовые команды. Кому приходилось работать в заказной разработке, тот хорошо понимает как может иногда происходить анализ стейкхолдеров: пришел менеджер, назвал ряд контактных лиц (чаше всего менеджеров или ключевых экспертов компании-заказчика), при этом для аналитика крайне малы шансы встретить других участников автоматизируемого процесса. Что ждет ваше приложение, если при этом часть стейкхолдеров или часть структуры компании не попадет в сферу внимания аналитика?
Когда я перешла из компании-подрядчика во внутреннюю разработку в банк, самым ярким впечатлением было — можно договориться о встрече с сотрудниками в отделении банка, с конечными пользователями! В те времена, каждая встреча с конечными пользователями вызывала у меня шок - «в поле» все происходило вообще не так, как мы предполагали, сидя в офисе за моделированием процессов и интерфейсов. Так бывает, если аналитики обсуждают требования только с теми, кого принято называть «заказчики». Ваши собеседники могут быть уверены, что хорошо знают «как должно быть», но при этом они давно не работают в тех же условиях, что и конечные пользователи. В результате вы проектируете приложение в отрыве от реального контекста, а пользователи после внедрения придумывают разные «костыли», чтобы не пользоваться вашим приложением или компенсировать его недостатки. Сколько раз вы слышали или говорили что-то вроде: «Наши заказчики сами не знают, чего хотят»? Что если они отлично понимают, чего хотят, а вот аналитики не сумели понять опыт, сферу ответственности и интересы тех, с кем они разговаривает?
Бывает, что потребности «заказчиков» конфликтуют с потребностями тех, кто этим самым «заказом» будет пользоваться (конечных пользователей). Например, руководителю бизнес-подразделения важно перевести CRM систему на новый тех.стек и архитектуру, чтобы оптимизировать расходы на содержание АС. При этом конечному пользователю - рядовому операционному сотруднику - важно чтобы все работало «как есть», например от того, что он только месяц как адаптировался и научился работать в текущей версии системы без нарушения своих SLA не готов в очередной раз остановить процесс.
Понятно, что в таком контексте предложение внедрить новую систему имеет ограничения. Если полностью пренебречь ожиданиями конечных пользователей и увлечься улучшениями, которые дает новый тех.стек, то цели руководителя бизнес-подразделения могут быть провалены за счет снижения операционных показателей и увеличения количества обращений в поддержку в результате перехода на новую версию инструмента. Конечные пользователи обычно не принимают решений по фиче и бывают в буквальном смысле не заинтересованы в изменении, при этом приложение точно не «взлетит», если в их понимании оно увеличивает время исполнения бизнес-операций.
Приходилось вам оказаться в ситуации, когда внедрение фичи откладывается из-за обнаруженного (например, на ПСИ) несоблюдения внешних или внутренних регламентов компании? При этом в команде разработки чаще всего звучит недовольство, менеджер в очередной раз переносит сроки внедрения и тоже не особенно счастлив. Была ли возможность проконсультироваться у комплаенс\юристов на этапе выбора решения, а не при внедрении? Как так вышло, что эксперты в регуляторных требованиях не участвовали в задаче? В некоторых случаях ответ на этот вопрос в том, что аналитик выявил требования «заказчиков», а не всех возможных заинтересованных сторон. Далеко не каждый раз причина именно в этом, но такой случай не редкость.
Пример из книги К. Вигерса "Разработка требований к программному обеспечению" (Издание третье, Часть 1 глава 2)
Я знаю проект, в котором на финальном этапе выявления требований при проверке правильности потока процессов аналитик поинтересовался у заинтересованного лица: "Вы уверены в правильности шагов вычисления налога в этом потоке?" На что получил такой ответ:"Ну, я не знаю. Я не занимаюсь налогами - для этого есть отдел по налогам." На протяжении многих месяцев работы над проектом никто из команды не разговаривал ни с одним сотрудником из отдела по налогам. В команде даже не догадывались, что такой отдел вообще существует. ... В результате проект был задержан на несколько месяцев.
Подмена термина «заинтересованные стороны» термином «заказчик» в итоге грозит команде разработки срывом сроков, нарушением поставленных бизнес-целей, изменениями «на лету», неиспользуемыми фичами и пр. Чтобы этого избежать имеет смысл в начале работы поискать ответы на несколько вопросов:
- Кто владеет бюджетом на разработку?
- Кто принимает решения по функционалу системы?
- Кто будет платить за использование решения (например, купит подписку на использование приложения для видео-конференций)?
- Кто будет конечным потребителем результата (непосредственно проводить видео-конференции в приложении)?
- Чьи интересы прямо или косвенно могут быть затронуты?
- Кто может влиять на ход реализации?
- Кто хотел бы получить выгоды, но не получит их?
