Анализ проблемы и границы проекта · Конспекты по бизнес-анализу

Главные идеи#

Пять шагов анализа проблемы#

Договоритесь об определении проблемы. Запишите проблему в фиксированной форме и убедитесь, что все её принимают (шаблон ниже). В документе «Видение» Rational Unified Process (RUP) используется очень похожая формулировка проблемы.
Найдите корневые причины — проблемы, стоящие за проблемой, — с помощью диаграммы Исикавы («рыбий скелет») или расспросив тех, кто выполняет работу. Затем ранжируйте причины диаграммой Парето и устраняйте только те, исправление которых обходится дешевле, чем вред от них.
Определите заинтересованные стороны и пользователей. Заинтересованная сторона — любой, на кого новая система существенно влияет. Рассматривайте пользователей и остальные заинтересованные стороны отдельно: внимания требуют и те и другие.
Определите границу решения. Разделите мир на систему и то, что с ней взаимодействует. Действующее лицо (actor) — всё, что находится вне системы и взаимодействует с ней. Поиск действующих лиц — ключевой аналитический шаг.
Определите ограничения на решение. Перечислите каждое вместе с источником и обоснованием. Некоторые из них станут требованиями.

Три синдрома#

«Да, но…». Пользователи реагируют на увиденное словами «да, но…». Избежать этого нельзя, поэтому вызывайте эту реакцию рано, раскадровками и прототипами, а не поздно, готовым ПО.
«Неоткрытые руины». Чем больше требований вы находите, тем яснее, что их осталось ещё больше. Полнота — это горизонт, а не финишная черта.
«Пользователь и разработчик». Стороны различаются языком, опытом и мотивацией. Средства, которые предлагают авторы: считайте пользователей экспертами в предметной области и используйте раскадровки или прототипы, когда они не могут сказать, чего хотят; показывайте раскадровки, ролевые игры или прототипы как можно раньше; пусть аналитики, которые думают, что знают лучше, побудут в роли пользователя час или день; и примите как данность, что подозревать других в политических играх — просто человеческая природа.

Контекстно-свободные вопросы#

Спрашивайте о проблеме пользователя, не подразумевая решения: кто пользователь? Кто заказчик? Отличаются ли их потребности? Вопросы, связанные с решением, задавайте позже, чтобы получить обратную связь. В конце каждого интервью записывайте три самые важные потребности, которые вы услышали; по наблюдению авторов, примерно десять интервью дают около пятнадцати ключевых потребностей. Анкеты не заменяют интервью, но помогают проверить допущения и измерить предпочтения.

Пять элементов Дэвиса#

Авторы ссылаются на Дэвиса: определение системы полно, если оно охватывает входы, выходы, функции (как входы преобразуются в выходы), атрибуты системы (например, надёжность и сопровождаемость) и атрибуты среды (условия эксплуатации, совместимость). Чтобы проверить, является ли что-то требованием к ПО, убедитесь, что оно подходит под один из пяти элементов.

Границы: проблема 200%#

Закон Брукса гласит: если добавить людей в опаздывающий программный проект, он опоздает ещё сильнее. Леффингуэлл и Уидриг рассматривают границы как соотношение функций, ресурсов и времени и замечают, что проекты обычно начинаются примерно с вдвое большим объёмом работы, чем команда может выполнить. Задача — сократить границы, часто вдвое, а не добавлять людей.

Чтобы зафиксировать базовую версию (baseline), составьте список функций и расставьте приоритеты, грубо оцените каждую и определите её риск. Типичная базовая версия включает все критичные функции, одну-две важные, а полезные — только если хватает ресурсов; остальные переносятся в будущие релизы. Обещайте меньше, а делайте больше.

Переговоры о границах#

Не сокращайте границы без заказчика. Заказчик, который участвовал в решении, считает результат своим; тот, кто узнал о нём постфактум, винит команду. Авторы опираются на книгу Фишера, Юри и Паттона Getting to Yes: ставьте высокую, но разумную планку, отделяйте людей от проблемы, сосредоточьтесь на интересах, а не на позициях, знайте, в какой момент выйдете из переговоров, ищите варианты, выгодные обеим сторонам, и опирайтесь на объективные критерии. Формальный запрос новой функции — более простой случай: можно показать его влияние (что придётся убрать, чтобы освободить место). Функции, которые проникают в проект неформально, опаснее.

Модели процесса и границы#

Если применить каскадную модель к проекту с объёмом 200%, к сроку не будет работать ничего; спиральная модель Боэма оставит хотя бы несколько работающих прототипов и отзывы заказчика; итеративный подход Крачтена, позднее ставший основой RUP, даёт больше всего точек для корректировки границ по мере поступления обратной связи. Вывод авторов: успех определяет скорее управление границами, чем выбор модели.

Как применять#

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

Шаблон#

Шаблон

| Элемент | Ваш текст |
|---|---|
| Проблема | <опишите проблему> |
| затрагивает | <кого она затрагивает> |
| и приводит к | <последствия для заинтересованных сторон и бизнеса> |
| успешное решение должно | <главные выгоды от решения> |

Пример#

«Мастерская», вымышленная сеть веломастерских: Проблема — клиенты не знают, когда будет готов их велосипед, — затрагивает клиентов и сотрудников стойки приёма во всех 12 мастерских и приводит к постоянным звонкам о статусе, которые прерывают запись клиентов, и к невостребованным велосипедам; успешное решение должно автоматически сообщать клиентам об изменении статуса и освобождать время сотрудников стойки приёма. Сессия по корневым причинам показывает, что механики обновляют бумажную доску, которую больше никто не видит, поэтому первый релиз сосредоточен на фиксации статуса и уведомлениях, а заказ запчастей переносится в релиз 2.

Источники и что почитать#

D. Leffingwell, D. Widrig. Managing Software Requirements: A Unified Approach. Addison-Wesley, 2000. Рус. изд.: Д. Леффингуэлл, Д. Уидриг. Принципы работы с требованиями к программному обеспечению. Унифицированный подход. М.: Вильямс, 2002. Гл. 1–9, 19–20 и 23; гл. 21 (переговоры о границах с заказчиком); гл. 22 (модели процесса и границы).
F. P. Brooks. The Mythical Man-Month. Addison-Wesley, 1975. Рус. изд.: Ф. Брукс. Мифический человеко-месяц, или Как создаются программные системы. СПб.: Символ-Плюс (закон Брукса).