Заметки по работе с требованиями с претензией на методичку. Часть 1-я
В рамках подготовки к игре OpenTalk #5 «Бизнес-анализ, управление требованиями, проектирование», я обещал в скайп-группе и рассылке подготовить методическое руководство для помощи как новичками, так и для тех, кто неоднократно был на моих семинарах/выступлениях/тренингах/дискуссиях. Ниже я постараюсь тезисно изложить основные грабли моменты, на которые мы все натыкаемся. Понятно, что это пока сборник заметок, который не дотягивает до систематизированной методички — буду улучшать :) Итак, поехали...
Навык «ноль»
К сожалению, не придумано пока способа быстро и легко превратить хотелку заказчика,Командная работа
В неё отлично «втыкаются» все, кому не лень. Коллеги, в команде не может не быть лидера. Я понимаю, что «форминг-норминг-...», но при формировании команд я разделяю вас так, чтобы были в команде люди с ярко выраженными лидерскими способностями. Не надо фокусироваться только на техническом решении задач, я понимаю, что вам хочется быть в числе первых и принятии бизнес-решений, и в технических вопросах, но если вы реально можете помочь команде организоваться и не мешать друг другу —Подмена постановки задачи решением
Очень часто, при обсуждении того, что нужно сделать, вместо вопросов «зачем?» и «чего мы должны добиться?», мы задаем вопросы «как?» или «что именно?». В результате, попадаем в зависимость от собственного или чужого решения или видения решения, напрочь отринув спектр возможных решений, которые могли бы больше подойти в данной ситуации. При этом, много потом говорим об правильном абстрактном проектировании, оторванном от конкретной реализации :)Язык общения — язык целей
Язык бизнеса недоступен разработчикам софта и наоборот. Поэтому, появляется каста шаманов в лице бизнес- и прочих аналитиков, которые, владея языком заказчика, переводят язык бизнеса на некий технический или приближенный к техническому и это служит входными данными для разработчиков. При этом, очень часто, возникает риск потери обратной связи — как в любой системе с дополнительными передаточными звеньями, каждое из которых говорит на своем языке. Как выход — разработчикам научиться говорить на языке заказчика и бизнес-аналитиков. Поэтому, в реальной жизненно важно объединить бизнес-анализ и проектирование — чтобы аналитики посмотрели, как и в чем они могут помочь разработчикам и наоборот. В наших играх мы будем делать то же самое :) Итак...Чтобы говорить на одном языке — говорите языком бизнес-целей. В чем плюсы:
- Заказчик легко оперирует бизнес-целями — это его мир.
- Заказчик легко приоритизирует бизнес-цели.
- Бизнес-цели легко иерархизируются и декомпозируются — из общих путей достижения цели легко, как правило, выделяются цели нижнего уровня и т.д.
- Правильно декомпозированные бизнес-цели очень короткие по формулировкам и легко осмысливаются.
- Иерархия бизнес-целей дает нам иерархию конечных пользовательских фич/кейсов/сценариев/историй/...
- Понимание сути автоматизируемого процесса разработчиком делает его работу осмысленной — мотивация, фан, все дела :)
- Язык бизнес-целей описывает конечные процессы. Бесконечных проектов не бывает. Смотри выше про мотивацию, фан, все дела :)
- Оперирование целями процесса вместо путей их достижения — отличное средство применить вытягивающие подходы и принципы и удешевить проект при улучшении его интегрального качества.
- Оперирование целями процесса вместо путей их достижения — отличное средство получить одинаковое с заказчиком понимание «готово»: до свидания размен багов на фичи и прочие «качели» и «отжимания» с заказчиком.
- И т.д. Буду описывать по мере написания :)
Расстановка приоритетов
Одна из самых больших жизненных проблем автоматически транслируется на требования :) Неправильная расстановка приоритетов приведет к тому, что будет выполнена некритичная работа и не выполнена критичная. Очень часто, неправильная расстановка приоритетов следует из незнания/непонимания/нежелания применять «вытягивающие» принципы вместо «вталкивающих». Иными словами, вместо того, чтобы делать только то, что мешает использовать проект в ближайшее время или прямо сейчас, мы занимаемся ерундой из разряда «а что бы нам ещё такого воткнуть в проект, чтобы он стал клевым?». Вместо борьбы с препятствиями, мы получаем смоляную яму собственной неуверенности и жадности.Также, правильной расстановке приоритетов очень сильно мешает прокрастинация — откладывание важных дел «на потом». Понятно, что при оперировании деревом бизнес-целей вы не сможете (хотя нет ничего недоступного для местных мастеров :) отложить на потом те задачи, которые мешают достижению целей.
Работа на опережение
Фактически, планируя, мы пытаемся заглянуть в будущее и определить путь, по которому наша текущее состояние проекта превратится в желаемое. Управляя рисками — мы тоже заглядываем в будущее и пытаемся предвидеть всяческие камни на этом пути. При работе с требованиями тоже надо управлять рисками. Например, появилось понимание, как добиться какой-либо цели. Очевидно же, что следом пойдет вопрос о стоимости пути достижения. Потому что требования — это, в некоторой степени, зеркало потребностей заказчика. А потребность заказчика — или получить максимальное качество за приемлемую цену или получить приемлемое качество за минимальную цену. Поэтому — надо готовиться к вопросам «сколько стоит?», «как удешевить?» еще на этапе анализа требований. Потому что вы ещё не продумали реализацию, а заказчик уже приоритизирует. Так зачем делать лишнюю работу — опередите его и присоединитесь к нему в этом процессе :) То же самое и по другим аспектам.Верификация
Требования — продукт жизнедеятельности, как и код :) И их нужно тестировать, как и код. Безусловно, что термины «полнота», «непротиворечивость», «реализуемость» и «тестируемость» очень хорошо звучат и дают представление о критериях качества требований. Но, в реальной жизни, полнота требований очень часто зависит не от бизнес-аналитика, а от заказчика. Даже самый квалифицированный аналитик может не успеть погрузиться в бизнес заказчика настолько, чтобы с очень большой степенью вероятностью проверить качество требований. Есть, правда, рецепт в виде перекладывания ответственности за требования на заказчика, но все мы знаем, что заказчик не всегда доступен или способен понять и протестировать все требования проекта. Про банальные человеческие ошибки и невнимательность в оценке полноты и трассировке требований может привести к тому, что со временем проект станет «другим», а приличное количество денег будет списано по принципу quick fail-а.Оперирование бизнес-целями позволяет легко верифицировать с заказчиком требования — цели (как минимум верхнего уровня) изложены языком заказчика. Верификация результата тоже упрощается — общие пути достижения главных тоже изложены языком заказчика.
Дальше в программе (если успею до четверга :)
- Нефункциональные требования
- Спящие кейсы
- Распухание требований
- Изменения требований
- Вытягивающие принципы
Kostyantyn Samoylov
Igor Yamshanov
Alexander Belchenko
Alexander Belchenko
Oleg Gumeniuk
Sergiy Movchan (COTOHA)
Sergiy Movchan (COTOHA)
Oleg Gumeniuk
15 коментарів
Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.