Заметки по работе с требованиями с претензией на методичку. Часть 2-я
Продолжаем начатый разговор.
Изменения требований
Наиболее часто встречающийся вопрос на всяческих конференциях и тусовках в контексте «что делать и как с этим бороться?». Понятно, что водопад — идеальная модель разработки с огромным минусом в виде наличия фактора времени :) Потому к водопаду стремятся и устраивают кучу маленьких водопадиков с фиксированием неизменных требований на короткий период, пытаясь побороть таким образом риск фактора времени. Бороться с фактором времени, ИМХО, бесполезно — моральное устаревание требований и следующие за этим изменения есть нормальный процесс. А вот с разрухой в головах и нецелесообразными прыжками в стороны можно попробовать повоевать :)В подавляющем большинстве случаев, изменения требований не касаются изменения целей проекта — они затрагивают пути достижения этих целей. Причины могут быть разные, но самая важная из них — осознание факта, что запланированный путь не позволяет добиться поставленной цели. Как правило — это субъективное мнение.
Плохо, если это — мнение заказчика. Тут понадобится кропотливая работа по вытаскиванию из него обоснования такого мнения. Но, если вы с заказчиком с самого начала приучились работать от целей и выстраивать логические обоснования достижимости/недостижимости по дереву целей и кейсов или картам фич (если юзаете FDD) или какому-то другому способу визуализации связей «цель — путь её достижения», то процесс внесения изменений в требования становится менее эмоциональным и более научным, ибо принятие решения о изменении приоритетов или контекста задач без явного или не очень «технико-экономического обоснования» — не обходится. Также, когда у команды руль в способах верификации достижения целей, то предсказывание изменений становится менее интуитивным.
Все остальные причины, по которым вносятся изменения в требования (кроме кардинального изменения окружения продукта или гика-заказчика) достаточно легко можно отбить, оперируя приоритетами, целесообразностью, соотношением «цена/сроки — результат». Понятно, что бывают исключения, но это — отдельный разговор :)
Нефункциональные требования
Безумно раздражает любого технаря, когда кто-то дает качественную характеристику проекта через прилагательные: «удобный», «быстрый», «надежный», «безопасный» софт. Попытка сформулировать такие требования детально, обычно обречена на провал — среднестатистический заказчик неспособен это сделать. В зависимости от зрелости и подверженности двойным стандартам, аналитик либо бесится, либо увлекается детализацией и анализом таких требований, повышая приоритет этим рискам. И то, и другое — вредно в масштабах всего проекта.Что можно сделать, если говорить на языке бизнес-целей? Можно обозначить нефункциональные требования как цели, которых нужно добиться. Получаем ситуацию, что нефункциональные требования к кейсам у нас транслируются от нефункциональных требований/целей более высокого уровня и декомпозируются в конечные задачи.
Спящие кейсы
Характерно для сложных процессов с отложенными задачами — раз в год отчет сгенерить, проверка состояний объектов при наступлении событий и т.д. Такие действия тоже подчиняются определенным бизнес-целям и если в ходе работы над требованиями они не всплыли — они не нужны. Тем, кто занимается автоматизацией бизнес-процессов — такие вещи могут периодически осложнять жизнь. Особенно, при наличии толстых троллей на стороне заказчика, готовых раздуть из этого проблему сроков, бюджета и готовности проекта к приемке.Про троллей, кстати, на хабре было отлично написано. Те, кто в теме и интенсивно использует сценарии приемки и принципы «мы не беремся за работу, пока не понимаем, как её будем сдавать» — прочли и ещё раз погладили себя мысленно по голове :)
Распухание требований и функциональные перекосы
Когда никто не работает с целями проекта, то вытягивающие принципы забываются и начинается наталкивание фиче-листов чем попало — эдакий фиче-центрик подход. Нужность фичи не рулит — рулит её наличие.Если идти от целей, то разговор о том, нужна ли эта фича или нет именно сейчас — упрощается. Если фича отвечает неприоритетной цели или соотношение «приоритет цели — цена фичи» нарушена — в сад. Если у фичи нет конкретной цели — тем более в сад.
Если проект сложный и предназначен для нескольких целевых аудиторий, то встречается также перекос в степени детализации (и как следствие — готовности к реализации) требований для разных групп пользователей — в зависимости от «горластости» и «лоббистости» представителей этих групп. Иными словами — если в комплексном продукте много владельцев, то вопрос приоритизации становится болью в ...
Для борьбы с этим нужно очень тщательно выписать иерархию целей и приоритизовать цели верхних уровней непосредственно с ЧДПР (Человек Действительно Принимающий Решения) — тогда у всех активных владельцев требований (владельцев продукта) на стороне заказчика будут отличные удобные гробики коридоры, за которые ступить они могут только эскалируя вопрос наверх. По опыту, два этих геморроя часто ходят рядом. Бороться, ИМХО, с ними лучше вместе, чем по отдельности — методы те же самые.
Продолжение следует.
Дмитрий Зиновьев
Vasiliy Litvin
Vasiliy Litvin
Igor Yamshanov
Sergiy Movchan (COTOHA)
Sergiy Movchan (COTOHA)
17 коментарів
Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.