Пользовательские истории. Искусство гибкой разработки ПО

Конец истории печален и вполне предсказуем.

Изредка, конечно, оценка снайперски точна, клиент получает именно то, что просил, а просил он именно то, что ему было нужно.

Но в большинстве случаев реализация решения занимает больше времени, чем предсказывал исполнитель. Работник, являющийся исполнителем, может приводить любые оправдания, в том числе, что в требованиях, которые ему дали, плохо проработаны детали или просто «требования никуда не годятся». Клиент может жаловаться на неточную оценку, и, кажется, никому не приходит в голову, что это оксюморон. Когда же решение наконец предъявлено и клиент получает то, что просил, он может попробовать полученное и обнаруживает, что это совсем не то, что ему было нужно, намеченной им цели достичь нельзя.

Самое ужасное здесь то, что клиент понимает свою проблему лучше всех, а вот найти ее решение у него получается хуже, чем у других. А исполнитель отлично понимает технологии, и чаще всего только он обладает достаточной квалификацией, чтобы решить проблему, потому что он работает с этими технологиями и знает, как они могут помочь в данном случае. Более того, большинство технических специалистов искренне хотят помочь, им было бы приятно знать, что результаты их труда полезны людям.

Но в антишаблоне «клиент – исполнитель» обсуждение проблем и решений заменено дискуссиями и соглашениями относительно требований. Проигрывают в такой ситуации все.

Одна из целей метода историй – избавиться от этого антишаблона.

Хороший пример отношений, разрушающих этот антишаблон, – отношения многих из нас со своим врачом. Попробуйте явиться в кабинет врача и предъявить ему свои «требования». Перечислите рецепты, которые вам нужно выписать, и процедуры, которые следует назначить. Если у вас хороший врач, он ответит: «Очень интересно, а сейчас расскажите мне, что вас беспокоит».

Я представляю себе диапазон, на одном конце которого слово «официант», а на другом – «врач». Вам нужно стремиться к тому, чтобы ваши рабочие отношения больше напоминали общение врача и пациента, а не официанта и гостя.

Владелец продукта как продюсер

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