Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Заметки по работе с требованиями с претензией на методичку. Часть 2-я

Продолжаем начатый разговор.

Изменения требований

Наиболее часто встречающийся вопрос на всяческих конференциях и тусовках в контексте «что делать и как с этим бороться?». Понятно, что водопад — идеальная модель разработки с огромным минусом в виде наличия фактора времени :) Потому к водопаду стремятся и устраивают кучу маленьких водопадиков с фиксированием неизменных требований на короткий период, пытаясь побороть таким образом риск фактора времени. Бороться с фактором времени, ИМХО, бесполезно — моральное устаревание требований и следующие за этим изменения есть нормальный процесс. А вот с разрухой в головах и нецелесообразными прыжками в стороны можно попробовать повоевать :)

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

Плохо, если это — мнение заказчика. Тут понадобится кропотливая работа по вытаскиванию из него обоснования такого мнения. Но, если вы с заказчиком с самого начала приучились работать от целей и выстраивать логические обоснования достижимости/недостижимости по дереву целей и кейсов или картам фич (если юзаете FDD) или какому-то другому способу визуализации связей «цель — путь её достижения», то процесс внесения изменений в требования становится менее эмоциональным и более научным, ибо принятие решения о изменении приоритетов или контекста задач без явного или не очень «технико-экономического обоснования» — не обходится. Также, когда у команды руль в способах верификации достижения целей, то предсказывание изменений становится менее интуитивным.

Все остальные причины, по которым вносятся изменения в требования (кроме кардинального изменения окружения продукта или гика-заказчика) достаточно легко можно отбить, оперируя приоритетами, целесообразностью, соотношением «цена/сроки — результат». Понятно, что бывают исключения, но это — отдельный разговор :)

Нефункциональные требования

Безумно раздражает любого технаря, когда кто-то дает качественную характеристику проекта через прилагательные: «удобный», «быстрый», «надежный», «безопасный» софт. Попытка сформулировать такие требования детально, обычно обречена на провал — среднестатистический заказчик неспособен это сделать. В зависимости от зрелости и подверженности двойным стандартам, аналитик либо бесится, либо увлекается детализацией и анализом таких требований, повышая приоритет этим рискам. И то, и другое — вредно в масштабах всего проекта.

Что можно сделать, если говорить на языке бизнес-целей? Можно обозначить нефункциональные требования как цели, которых нужно добиться. Получаем ситуацию, что нефункциональные требования к кейсам у нас транслируются от нефункциональных требований/целей более высокого уровня и декомпозируются в конечные задачи.

Спящие кейсы

Характерно для сложных процессов с отложенными задачами — раз в год отчет сгенерить, проверка состояний объектов при наступлении событий и т.д. Такие действия тоже подчиняются определенным бизнес-целям и если в ходе работы над требованиями они не всплыли — они не нужны. Тем, кто занимается автоматизацией бизнес-процессов — такие вещи могут периодически осложнять жизнь. Особенно, при наличии толстых троллей на стороне заказчика, готовых раздуть из этого проблему сроков, бюджета и готовности проекта к приемке.

Про троллей, кстати, на хабре было отлично написано. Те, кто в теме и интенсивно использует сценарии приемки и принципы «мы не беремся за работу, пока не понимаем, как её будем сдавать» — прочли и ещё раз погладили себя мысленно по голове :)

Распухание требований и функциональные перекосы

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

Если идти от целей, то разговор о том, нужна ли эта фича или нет именно сейчас — упрощается. Если фича отвечает неприоритетной цели или соотношение «приоритет цели — цена фичи» нарушена — в сад. Если у фичи нет конкретной цели — тем более в сад.

Если проект сложный и предназначен для нескольких целевых аудиторий, то встречается также перекос в степени детализации (и как следствие — готовности к реализации) требований для разных групп пользователей — в зависимости от «горластости» и «лоббистости» представителей этих групп. Иными словами — если в комплексном продукте много владельцев, то вопрос приоритизации становится болью в ...

Для борьбы с этим нужно очень тщательно выписать иерархию целей и приоритизовать цели верхних уровней непосредственно с ЧДПР (Человек Действительно Принимающий Решения) — тогда у всех активных владельцев требований (владельцев продукта) на стороне заказчика будут отличные удобные гробики коридоры, за которые ступить они могут только эскалируя вопрос наверх. По опыту, два этих геморроя часто ходят рядом. Бороться, ИМХО, с ними лучше вместе, чем по отдельности — методы те же самые.

Продолжение следует.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Схожі статті




17 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Дмитрий, используете ли Вы в своей практике какие-либо системы управления требованиями? Как вообще выглядит процесс сбора и проработки требований?

Я вчера на OpenTalk #5 рассказывал про Крея и его ответ на вопрос о САПР при проектировании суперкомпьютеров :)

Бумага + ручка, маркерная доска + маркер, вики, visio, word, excel. Псевдоязыки не используем — максимум графическое представление предметной области проекта или флоу какого либо процесса.

Это вкратце и поверхностно про систему управления.

Процесс сбора и проработки требований — как у всех: выясняем хотелку, превращаем его в требования, требования тестируем и так по кругу, пока нет оснований для общего решения о готовности превращения требований в сценарии поведения.

Лично Мое Субъективное Мнение — это относиться ко всем Руководителям Проектов — чем больше жаргона используется в общении с заказчиком тем больше надо уточнять что он имел ввиду, в компаниях мало грамотных тех. писателей , а от них как раз и зависит описание процесса в определениях понятных для разработчиков. Это из личного опыта чем малограмотнее постановщик задачи тем больше времени я трачу на расшифровку его требований . Заметьте не требований заказчика а именно требований описанных в ТЗ. Сказать что это замедляет работу — это ничего не сказать, при правильно написанном ТЗ время разработки (не путать с временем работы над проектом ) сокращается в разы и это малозависит разрабатываете ли вы корпоративное ПО или настольное для самого себя.
Хорошо написанное ТЗ это когда программист который его читает всё понимает и может начать разработку просто сидя и читая ТЗ. К сожалению много ТЗ составляется просто под копирку от требований заказчика с вкраплениями описания структур и эскизами экранов.
И как следствие не грамотный в технологиях тех. писатель мешает писать хорошо и как следствие тенят квалифицированного разработчика искать новое место работы , а не квалифицированного приучает жить в рамках жаргонизмов и ставит крест на повышении квалификации программиста .
О жаргонизмах отписал не зря если честно статья отличная , но множество жаргона делает её чтивом низкого качества — хотя по сути в статьях описаны очень серьёзные вещи.

Спасибо за статьи.

Спасибо за критику. Скажу честно — заметки писались под www.developers.org.ua/calendar/662 и спешка чуток была :)

Какие именно жаргонизмы резанули вам слух или были непонятны? Давайте сообща повысим «качество чтива» :)

Я не придераюсь к словам и не сказал что мне что то не понятно, но впечатление сложилось что если в статье так пишут, значит и ТЗ так будет составленно .

активных овнеров
- ну что это за моветон ?! :) я так понимаю это значит «ключевые сотрудники» которые отвечают за часть процесса , правильно ?

Спасибо

Я не придераюсь к словам и не сказал что мне что то не понятно, но впечатление сложилось что если в статье так пишут, значит и ТЗ так будет составленно .

мы не пишем ТЗ в обычном понимании :) мы от описания концепции переходим к сценариям поведения. естественно, что терминология предметной области согласовывается с заказчиком.

активных овнеров

— ну что это за моветон ?! :) я так понимаю это значит «ключевые сотрудники» которые отвечают за часть процесса , правильно ?

нет, это владельцы требований проекта/продукта на стороне заказчика. получился, фактически, реверанс в сторону скрамолюбцев :)

что ещё?

спасибо за ответы , теперь понятнее :)

спасибо за критику — поправил последний абзац. также, учел вопрос от Igor Yamshanov про ЧДПР.

что ещё превращает статью для вас в «чтиво низкого качества» ? ;)

Не в обиду . А чем произведения Лукьяненко(Донцовой) отличаются от произведений Пушкина? ;) много жаргона.
К тому же я не редактор ДОУ что бы поправлять автора :) в его личном выборе формата статьи.
П.С.
Между жителями Санк-Петербурга и Москвы провели опрос — Как вы называете активную деятельность сопряженную с решением трудных вопросов.
Жители Санк-Петербурга ответили «Головной болью»

Жители Москвы ответили — «Геморроем».

Это я не к тому что кто то культурнее, а кто то нет. Ваши статьи читают ,а значит найдуться те кто будет их цитировать и примерять на свои проблемы.
Возможно те кто раньше чего то не знал смогут повысить свой уровень и станут относиться к проблемам, как преодолимым преградам, а не как тяжелоизличимому заболеванию. ;)

Удачи!

Спасибо.

А я не обиделся — мне как колумнисту конструктивная критика ценнее хвалебных отзывов :)

А ЧДПР это кто?

Чувствую, что «Принимающий Решения», а начало непонятно

Человек Действительно Принимающий Решения

жаргонизм :)

«удобный», «быстрый», «надежный», «безопасный»

я догадываюсь, как перевести на человеческий «быстрый», «надёжный» и «безопасный», но не знаю как «комфортный» (и его подмножества — «удобный», «производящий впечатление безопасного»).

какие цели могут стоять за таким нефункциональным требованием как «удобный»?

простой пример (клиент-серверное приложение):
— экономить время пользователя на выполнение операций
— упрощение компоновки контролов
— настройка индивидуальной компоновки
— упрощение правил влияния контролов и групп контролов друг на друга
— ранний отклик интерфейса на ошибки
— обработка данных на клиенте, а не на сервере
— уменьшение количества шагов операций
— «быстрые» операции
— стандартизация реакций интерфейса на воздействия пользователя

и т.д.

ЗЫ: иерархия списка не отобразилась :(

ну

экономить время пользователя на выполнение операций
 — это часто-густо цель всего приложения — автоматизировать что-то, чтоб избегать «ручных» ошибок и ускорить процесс.

ну к остальному тоже можно прикапаться типа «стандартно — не обязательно удобно», «упрощение компоновки контролов» находится в обратной зависимости от «уменьшение кол-ва шагов операции», всякое «быстрое» (данные на клиенте и т.п.) это ж к «быстро», не?

хотя при воспитанном (командой?) клиенте будет работать. что делать с дикими? :)

это часто-густо цель всего приложения — автоматизировать что-то, чтоб избегать «ручных» ошибок и ускорить процесс.

часто-густо в 21 веке это уже автоматизировано и его надо переавтоматизировать :) к тому же, если явно не определить цель экономии времени, то можно много чего наавтоматизировать, а потом насдавать :)

ну к остальному тоже можно прикапаться типа «стандартно — не обязательно удобно»,

речь идет о схожести реакций интерфейса на действия пользователя для различных фич. понятие «удобно» согласуется с целевой аудиторией. если заказчик выступает от её имени — не вопрос, согласуем с ним.

«упрощение компоновки контролов» находится в обратной зависимости от «уменьшение кол-ва шагов операции»,

не всегда. например — многоколоночную форму сделали одноколоночной. как был один шаг, так и остался.

всякое «быстрое» (данные на клиенте и т.п.) это ж к «быстро», не?

если клиент-сервер, то у него как минимум 3 «быстро» :)

хотя при воспитанном (командой?) клиенте будет работать. что делать с дикими? :)

Ну, даже с дикими заказчиками нужно как-то выстраивать взаимодействие. Неужели он настолько дикий, что ему нельзя продать тему по удешевлению разработки или улучшения качества без повышения цены? Ведь что такое цели + приемочные сценарии — это резкое удешевление согласования и последующей приемки при уменьшении потерь качества. Про остальное я молчу :)

Підписатись на коментарі