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

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

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

Навык «ноль»

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

Командная работа

В неё отлично «втыкаются» все, кому не лень. Коллеги, в команде не может не быть лидера. Я понимаю, что «форминг-норминг-...», но при формировании команд я разделяю вас так, чтобы были в команде люди с ярко выраженными лидерскими способностями. Не надо фокусироваться только на техническом решении задач, я понимаю, что вам хочется быть в числе первых и принятии бизнес-решений, и в технических вопросах, но если вы реально можете помочь команде организоваться и не мешать друг другу — к черту дверь сделайте это. Возможность показать свою крутость как аналитика и архитектора при этом от вас не уйдет. Не забывайте, что зачет как в играх, так и в реальной жизни — командный. Вспомните OpenTalk #4, как все воткнулись не только в техническую составляющую, а и в командную :)

Подмена постановки задачи решением

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

Язык общения — язык целей

Язык бизнеса недоступен разработчикам софта и наоборот. Поэтому, появляется каста шаманов в лице бизнес- и прочих аналитиков, которые, владея языком заказчика, переводят язык бизнеса на некий технический или приближенный к техническому и это служит входными данными для разработчиков. При этом, очень часто, возникает риск потери обратной связи — как в любой системе с дополнительными передаточными звеньями, каждое из которых говорит на своем языке. Как выход — разработчикам научиться говорить на языке заказчика и бизнес-аналитиков. Поэтому, в реальной жизненно важно объединить бизнес-анализ и проектирование — чтобы аналитики посмотрели, как и в чем они могут помочь разработчикам и наоборот. В наших играх мы будем делать то же самое :) Итак...
Чтобы говорить на одном языке — говорите языком бизнес-целей. В чем плюсы:
  • Заказчик легко оперирует бизнес-целями — это его мир.
  • Заказчик легко приоритизирует бизнес-цели.
  • Бизнес-цели легко иерархизируются и декомпозируются — из общих путей достижения цели легко, как правило, выделяются цели нижнего уровня и т.д.
  • Правильно декомпозированные бизнес-цели очень короткие по формулировкам и легко осмысливаются.
  • Иерархия бизнес-целей дает нам иерархию конечных пользовательских фич/кейсов/сценариев/историй/...
  • Понимание сути автоматизируемого процесса разработчиком делает его работу осмысленной — мотивация, фан, все дела :)
  • Язык бизнес-целей описывает конечные процессы. Бесконечных проектов не бывает. Смотри выше про мотивацию, фан, все дела :)
  • Оперирование целями процесса вместо путей их достижения — отличное средство применить вытягивающие подходы и принципы и удешевить проект при улучшении его интегрального качества.
  • Оперирование целями процесса вместо путей их достижения — отличное средство получить одинаковое с заказчиком понимание «готово»: до свидания размен багов на фичи и прочие «качели» и «отжимания» с заказчиком.
  • И т.д. Буду описывать по мере написания :)
Все это отлично позволяет управлять рисками — рисками подмены постановки задачи решением, приоритизации, верификации, изменения требований и многих других. ЗЫ: Жаль, что только вот ваши бизнес-аналитики в этом не сильно иногда заинтересованы — если все будут уметь бить в бубен, то шаман не нужен :) УбиватьУбирать из проекта таких аналитиков.

Расстановка приоритетов

Одна из самых больших жизненных проблем автоматически транслируется на требования :) Неправильная расстановка приоритетов приведет к тому, что будет выполнена некритичная работа и не выполнена критичная. Очень часто, неправильная расстановка приоритетов следует из незнания/непонимания/нежелания применять «вытягивающие» принципы вместо «вталкивающих». Иными словами, вместо того, чтобы делать только то, что мешает использовать проект в ближайшее время или прямо сейчас, мы занимаемся ерундой из разряда «а что бы нам ещё такого воткнуть в проект, чтобы он стал клевым?». Вместо борьбы с препятствиями, мы получаем смоляную яму собственной неуверенности и жадности.

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

Работа на опережение

Фактически, планируя, мы пытаемся заглянуть в будущее и определить путь, по которому наша текущее состояние проекта превратится в желаемое. Управляя рисками — мы тоже заглядываем в будущее и пытаемся предвидеть всяческие камни на этом пути. При работе с требованиями тоже надо управлять рисками. Например, появилось понимание, как добиться какой-либо цели. Очевидно же, что следом пойдет вопрос о стоимости пути достижения. Потому что требования — это, в некоторой степени, зеркало потребностей заказчика. А потребность заказчика — или получить максимальное качество за приемлемую цену или получить приемлемое качество за минимальную цену. Поэтому — надо готовиться к вопросам «сколько стоит?», «как удешевить?» еще на этапе анализа требований. Потому что вы ещё не продумали реализацию, а заказчик уже приоритизирует. Так зачем делать лишнюю работу — опередите его и присоединитесь к нему в этом процессе :) То же самое и по другим аспектам.

Верификация

Требования — продукт жизнедеятельности, как и код :) И их нужно тестировать, как и код. Безусловно, что термины «полнота», «непротиворечивость», «реализуемость» и «тестируемость» очень хорошо звучат и дают представление о критериях качества требований. Но, в реальной жизни, полнота требований очень часто зависит не от бизнес-аналитика, а от заказчика. Даже самый квалифицированный аналитик может не успеть погрузиться в бизнес заказчика настолько, чтобы с очень большой степенью вероятностью проверить качество требований. Есть, правда, рецепт в виде перекладывания ответственности за требования на заказчика, но все мы знаем, что заказчик не всегда доступен или способен понять и протестировать все требования проекта. Про банальные человеческие ошибки и невнимательность в оценке полноты и трассировке требований может привести к тому, что со временем проект станет «другим», а приличное количество денег будет списано по принципу quick fail-а.
Оперирование бизнес-целями позволяет легко верифицировать с заказчиком требования — цели (как минимум верхнего уровня) изложены языком заказчика. Верификация результата тоже упрощается — общие пути достижения главных тоже изложены языком заказчика.

Дальше в программе (если успею до четверга :)


  • Нефункциональные требования
  • Спящие кейсы
  • Распухание требований
  • Изменения требований
  • Вытягивающие принципы

Ссылки по теме

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

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

Схожі статті




15 коментарів

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

Коментар порушує правила спільноти і видалений модераторами.

касательно каст — не переживайте, разработчики, тестировщики, менеджеры продаж тоже любят кастовость и любят дружить против кого-то :)
уже от политики компании зависит, какие отношения в её организме :)

я всегда борюсь с «кастовостью», например.

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

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

По поводу кривой МакКонелла. Тоже привлекло внимание, т.к. не знал что это такое.

Вот если кому нужно можно глянуть habrahabr.ru/...blogs/pm/75903

Что такое «принцип quick-fail»?

Одна из причин появления итеративных и инкрементально-итеративных подходов (читай — agile) — давайте не ждать пол-года, а потратим 100.000 из 1.000.000 и пощупаем частичный результат быстро. Даже если обломаемся — будем уже точнее знать, куда нужно вложить оставшиеся 900.000.
Иначе говоря — принцип быстрой идентификации рисков масштаба проекта путем выполнения быстро (и недорого) части проекта для получения реального опыта, подтверждающего или хоронящего бизнес-идею. Ключевой момент — за неудачу в этой части проекта никого не наказывают :)

Приехало в софт из инвестиционных практик.

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

Спасибо, полезно! Ждем продолжения)

кривая Макконелла

что это? никогда не слышал и слёту не нагуглил.

я разделяю вас так, чтобы были в команде люди с ярко выраженными лидерскими способностями

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

если тебе нужны команды, то лучше их назначить сразу с ролями (и скорректировать, если ошибся), но не требовать «сработаться» за полчаса.

...или получить максимальное качество за приемлемую цену или получить приемлемое качество за максимальную цену

минимальную во втором случае. или отдайте мне этого заказчика :)

что это? никогда не слышал и слёту не нагуглил.

кривая зависимости затрат от недооценки и переоценки

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

а победить — не? оно нам разве таки надо?

тебе это важно, возможно, как тренировка перед тем, как надо будет тренить реальную команду, но для участников о-толка это — имхо — лишнее и потеря времени

реальные команды тренятся по-другому. это же игра со своими ограничениями по асинхронности потоков информации :) касательно потери времени — как раз лаги из-за неорганизованности и вызывают потери :)

если тебе нужны команды, то лучше их назначить сразу с ролями (и скорректировать, если ошибся), но не требовать «сработаться» за полчаса.

а в реальной жизни заказчик тоже формирует команды?

минимальную во втором случае. или отдайте мне этого заказчика :)

таки очепятка, поправил, спасибо :)

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

где искать-то? :)

в какой-то из его книжек, не помню в какой :) могу нарисовать на флипчарте в четверг :)

я и предлагаю убрать и лаги и время на притирку.

т.е. индивидуальный зачет? :)

нет, но и самоформирование занимает не полчаса, правда?

для таких простых задач — меньше :) с учетом, что команды не из новичков состоят :)

где искать-то? :)

нагуглилось сразу в картинках по кейвордам Underestimation and overestimation McConnell

я понял. название кривой ты сам придумал? :)

нет. подслушал на видео одной конфы, где его любовно называли McC :)

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

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

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