Блоги сообщества аналитиков

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

Идея вступления сложилась под влиянием этих двух статей: Improve Reqts Understanding by Playing Serious Games и Vizualize & Manage Dev Understanding. В кратком изложении это звучит примерно так:

Успех проекта и качество конечного продукта в существенной степени зависит от понимания предметной области (application domain) и требований как самим заказчиком, так и разработчиком. В начальный момент проекта их понимание  далеко от совершенство и может быть выражено следующим рисунком:

 1 - область взаимного понимания требований разработчиком и заказчиком
 2 - область понимания требований разработчиком
 3 - область понимания требований заказчиком
 4 - область требований, которые слабо понимают и те, и другие
 r - требование, красное r - некое критичное для проекта требование.

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

Естественно, что основной задачей становится с одной стороны расширение областей понимания как заказчиком, так и разработчиком. А с другой максимально возможное (ну или целесообразное) сближение этих пониманий, т.е. расширение зоны пересечения областей 1 и 3.

Однако возникают как минимум две задачи: 1/ как измерить уровень понимания предметной области и требований; и 2/ как изменять (увеличивать, управлять) этот самый уровень. В данном случае простейший и достаточно очевидный способ это использование номинальной шкалы. Вводятся пять уровней понимания:  1/ слабое понимание, 2/поверхностное, 3/ограниченнное, 4/глубокое, 5/относительно полное. Отнесение понимания сотрудника к тому или иному уровню может осуществляться, естественно, самыми разными путями: методом экспертизы, методом опроса. Однако в выше названных статьях предлагает иной менее тривиальный способ: игры! Вернее особые корпоративные игры. Играя в эти игры люди выигрывают или проигрывают. Проигрыш скорее всего будет соотносится  с 1 уровнем понимания, а вот в зависимости от "скорости" выигрыша уровень может изменяться от 2 до 5. С другой стороны тут можно использовать просто статистику побед и проигрышей.

Предлагаются следующие игры: "Бридж" (вернее сам процесс торговли в бридже), 10/20 вопросов, Собери пазл,  Охота за мусором, Приобщение к культуре, Декодирование. Я не буду описывать правила каждой из этих игр, о них можно почитать в статье, догадаться или поискать описание правил на русском. Каждая из этих игр ориентирована на одну из зон понимания, что изображены на рисунке. Порядок использования данной методики следующий: 1/ определить нужды заказчика и пользователей, 2/ сформирование общее видение возможностей и функций системы. Здесь имеет смысл остановиться и напомнить, что все описанное выше направлено на изменение понимания требований. Не на навыки и качество выявление треований, или на качество самих требований. Предполагается, что требования (нужды) каким-то образом получены и, возможно, даже структурированы. Однако предлагается тезис, и он в общем не противоречит наблюдениям, что ряд требований вполне понятны из своих формулировок, другие требования легче сформулировать, чем понять, третьи, казалось бы, состоят из знакомых слов и имеют явную логику формулировки, но совершенно бессмысленны, если не имеешь нужного бэкграунда и вовлечения. Остается третий очень важный пункт методики: выбор игры. И тут предлагается неожиданное решение: планшетка для спиритических сеансов. Весьма необычно, согласитесь.

 Впрочем, наверняка, планшетку можно заменить подбрасываием монет, костей и т.п. Вообщем теория вероятностей должна помочь. Автор методики поступает вполне разумно, выкидывая из рассмотрения два крайних уровня и оставляя поверхностное, ограниченное и глубокое понимание как со стороны разработчика, так и заказчика. Получаем 9 возможных сочетаний и три уровня внимания или риска:

П. разработчика П. заказчика Уровень риска -  Игры и их последовательность
1 Глубокое Глубокое  Зеленый - Торговля в бридже с заданными правилами
2 Глубокое Ограниченнное Зеленый - 20 вопросов и бридж
3 Глубокое Поверхностное Зеленый - 20 вопросов
4 Ограниченное Глубокое Желтый - 10 вопросы, Бридж, Собери пазлы, Приобщение с учителем, Декодирование
5 Ограниченное Ограниченное Желтый - 10 вопросы, Бридж, Собери пазлы, Охота за мусором, Приобщение с учителем, Декодирование  
6 Ограниченное Поверхностное Желтый - 10 вопросы, Охота за мусором, Декодирование  
7 Поверхностное Глубокое Красный - Собери пазлы, Приобщение с учителем, Декодирование  
8 Поверхностное Ограниченное Красный - Собери пазлы, Охота за мусорм, Приобщение с учителем, Декодирование    
9 Поверхностное Поверхностное Красный - Охота за мусором, Декодирование

При использовании данной методики важна даже не точность измерения, а скорее выявление устойчивого тренда снижения числа заинтересованных лиц с уровнями в красной и желтой зоне риска.

Таким образом, подводим итоги:
1. игры можно использоватькак инструмент измерения, так и инструмент изменения уровня понимания (в сторону улучшения, конечно)
2. здесь рассматриваются задачи улучшения взаимодействия и сотрудничества - превратить заказчика и разработчика в семейную пару с большим опытом совместного проживания
3. не до конца ясно ( и у многих слушателей возник скептис) как можно убедить заказчика играть в такие игры, хотя может это тоже важный момент данной методики?
4. не ясно каков КПД такой методики, целесообразна ли она экономически

Надеюсь, участники дискуссии меня дополнят и поправят.

PS. Полезные ссылки:
Problem Frames Approach
How can you improve your Requirements Understanding?