Типичные ошибки – фактор роста аналитика и менеджера

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

Я всю жизнь в IT. Сначала – как разработчик и аналитик, потом стала руководителем подразделения аналитиков и далее работала на разных руководящих должностях, в том числе как зам. директора производственного центра.

Кроме этого я программный директор «Летнего аналитического фестиваля», эксперт Школы 21 и автор курсов – регулярно обучаю системному и бизнес-анализу.

В ходе своей деятельности я вырабатывала подходы, чтобы команда была эффективнее, а аналитики работали быстрее и качественнее. И сейчас хочу этим поделиться.

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

Сначала хочу познакомить вас с тремя принципами, которые я применяю в жизни и особенно в работе.

• Важно посмотреть на ситуацию сверху – даже если это непросто и приходится рисковать, находясь на высоте, занимаясь промышленным альпинизмом (картинка слева).

• Быстрее находишь, когда знаешь, что ищешь. На картинке справа изображено животное, но его не разглядеть, если не знать заранее, что это лиса – тогда виден хвост и ее можно увидеть.

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

Предлагаю вам тоже руководствоваться этими принципами.

Типичные ошибки на проекте

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

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

Определить бизнес-цели

Фредерик Брукс, автор известного бестселлера «Мифический человеко-месяц» в своей книге сказал: «Самая сложная часть построения систем ПО – это решить точно, что же создавать».

Именно о том, как выяснить требования у заказчика и его окружения, и придумать, что создавать, мы сегодня и поговорим.

На слайде – уровни требований по Вигерсу.

С заказчиком мы работаем на уровне требований заинтересованных сторон.

Потом по его требованиям пишем спецификации, и разработчики по ним разрабатывают – на уровне функциональных требований.

А сдаем-то мы ему задачу на уровне бизнес-требований. И сдаем мы то, что заказчик себе в голове придумал, а не то, что он нам сказал. Он нам сказал: «Хочу такой-то отчет с такой-то сортировкой». А для чего? Мы у него не спросили.

Здесь возникает разрыв между тем, что он нам сказал, и тем, что мы сдаем.

Получается, что он не все нам сказал. Он построил себе в голове модель, а нам сказал какие-то куски. Все остальное мы из него не можем извлечь.

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

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

И сдаем уже то, что соответствует этим бизнес-целям – те требования, которые он в голове придумал, но нам не сказал, мы вытащили из целей.

Это позволяет нам еще до начала проекта закрыть проблему «Заказчик изменил требования», которая возникает, если мы не выяснили цели у заказчика.

Провести обследование

Давайте рассмотрим концептуальную модель бизнес-анализа.

Руководство к своду знаний BABOK Guide v3 нам говорит, что концептуальная модель бизнес-анализа – это шесть связанных между собой сущностей:

• Изменения

• Потребности

• Решения

• Заинтересованные стороны

• Ценности

• Контент

С какой из их правильнее начать, чтобы обследовать и спроектировать систему?

Как говорит Дерек Хитчинс, бывший военный летчик, ставший потом известным айтишником: «Система успешна тогда, когда с ее помощью добиваются успеха все ключевые заинтересованные стороны». Поэтому шаги обследования мы начнем с заинтересованных сторон.

Мы выделяем заинтересованные стороны и одновременно изучаем домен, предметную область – на диаграмме эта сущность называется «Контекст».

Первым делом нам нужно определить стейкхолдеров – тех, кто:

• может влиять на систему;

• оказывается под влиянием системы;

• считает себя затронутым системой;

• и может повлиять на выбор путей реализации системы.

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

Здесь я привела табличку с вопросами, которыми выявляю самых ключевых и критичных стейкхолдеров – в BABOK Guide 3 примерно то же самое, но я немного расширила.

Следующие шаги обследования касаются изучения предметной области:

• мы смотрим на бизнес-процессы;

• определяем роли и функции ключевых стейкхолдеров;

• и выделяем бизнес-правила.

Здесь на слайде перечислены техники, которыми мы это делаем.

В итоге мы сможем нейтрализовать ошибки вида:

• «Заказчик вспомнил, что была еще такая функция» – эта ошибка обычно вызвана тем, что мы не познакомились со старой системой.

• «Появились требования регулятора». Регулятор в данном случае – это тот, кто задает правила.

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

Следующим шагом определяем:

• «Потребности» – ЗАЧЕМ нужно проектировать систему;

• «Ценности» – в чем ценность системы для бизнеса.

Для этого мы вместе с ключевыми стейкхолдерами формулируем:

• Проблемы и потребности.

• Возможности.

• Цели и ценности ключевых стейкхолдеров.

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

Для сбора бизнес-требований Вигерс предлагает концепцию, которая показана на слайде.

Обратите внимание, что пункты этой концепции базируются на ценностях.

Помните, мы говорили о том, что одна из возможных ошибок связана с тем, что мы не выяснили цели заказчика?

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

Четвертый шаг обследования – определяем функции системы и строим ее границы. На этом этапе мы подключаем в модель «Решение».

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

Здесь я описала некоторые типы критериев успеха, чтобы было понятнее, что это такое.

Чтобы сдать проект, нужно обязательно учитывать критерии успеха, иначе заказчик может сказать, что просил вообще не это. А если мы их учтем, мы можем закрыть проблему «Не поняли заказчика».

Дальше – о том, что важно не забыть при обследовании. Причем это не значит, что мы сначала цели выяснили, потом функции, а потом вспоминаем, что нужно не забыть – нет, эти шаги мы можем и должны делать параллельно.

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

Обязательно фиксируйте нефункциональные требования – на слайде подсказка, о каких нефункциональных требованиях нужно обязательно помнить практически на любом проекте.

Еще нужно не забыть про ограничения, особенности и вопросы организации внедрения. Особенно это важно для проектов внедрения, но и для проектов разработки тоже не стоит забывать. Мы в проект должны включить:

• миграцию;

• методику работы в штатном режиме;

• обучение персонала и т.д.

Возвращаемся к нашим ошибкам – если мы на этом этапе все учтем, мы можем закрыть пять ошибок, сейчас на слайде они зачеркнуты.

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

• Какие шаги нужно выполнить, чтобы перевести учет из старой системы в новую.

• Что должно быть реализовано на этапе внедрения.

• А что – уже во время эксплуатации.

И седьмой шаг – согласование и утверждение. Мы должны заранее узнать все правила согласования и утверждения проекта, и кто нам будет его согласовывать и утверждать. Это будет большой подмогой с нашей стороны менеджерам. И это – наша обязанность. Если аналитик говорит, что это задача менеджеров – это плохой аналитик, потому что менеджер эту информацию не узнает, если мы ему ее не дадим.

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

Пользуйтесь принципами бизнес-анализа и системной инженерии

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

Ивар Якобсон – человек, который придумал UML, участвовал в разработке UML2 и написал много книг. В 2017 году он был в Санкт-Петербурге на SECR – это такая конференция для разработчиков. И там читал доклад «Убейте методологии – высвободите практики».

В докладе были слова: «Люди перескакивают с одной новомодной методологии на другую, смешивая одно с другим и придумывая этому какие-то имена – Scrum, Kanban и так далее. А на самом деле, подкорка одна и та же. Не надо увлекаться этой сменой названий, надо смотреть в корень – на основные принципы не только бизнес-анализа, но и системной инженерии».

Что я хотела сказать этим докладом?

Если мы, как аналитики, будем учитывать опыт предыдущих ошибок, это станет трамплином для нашего роста.

Пока еще нет отдельной науки про бизнес-анализ или системный анализ. А те, которые есть – они не совсем про IT. А нам же жить как-то надо. Поэтому люди собираются и обмениваются мыслями, вырабатывают общие принципы.

Основные принципы зафиксированы в BABOK, и из BABOK в свое время Вигерс написал свою книжку. Есть и другие книги – их порядка 10. Можно и нужно читать и их, но на самом деле подкорка-то единая.

Не надо очень много знать, чтобы этим пользоваться, но когда мы этим пользуемся, у нас меньше ошибок, мы быстрее и качественнее делаем. Мы становимся более ценными для производства – я теперь говорю уже как руководитель разработки ПО, которому нужно, чтобы специалисты были высокого уровня.

Поэтому:

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

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

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

Источники

Список литературы на эту тему:

• IIBA «BABOK Guide v3. Руководство к своду знаний по бизнес-анализу»

• К. Вигерс, Дж. Битти «Разработка требований к программному обеспечению»

• Э. Халл, К. Джексон, Д. Дик «Инженерия требований»

• А. Коберн «Современные методы описания функциональных требований к системам»

• Ivar Jacobson «The Essence of Software Engineering»

• Ivar Jacobson «Kill All Methods – Free the Practices», SECR-2017

• Анатолий Левенчук «Системное мышление»

Очень рекомендую заглянуть в системную инженерию – нельзя сказать, чтобы я все взяла оттуда, но оно помогает.

Вопросы

Вы говорите, что причина проблемы «Изменились требования регулятора» в том, что мы не увидели ключевого стейкхолдера. На мой взгляд, это не ошибка, это риск, который мы не видим. Понятно, если у нас на проекте автоматизации регулятором выступает какая-то внутренняя УК, но если регулятор – это наше государство, то как тут выявишь стейкхолдера? Учитывая, что нам показал 2022-й год, когда компания может вовсю внедрять SAP, а потом бах, 24 февраля – импортозамещение, и люди требуют: «Переведите нас с SAP на 1С за 2 дня».

2022-й год – это исключение, как и 2020-й, когда вдруг все ушли на удаленку.

Я в данном примере говорю о том, что когда собираем информацию о стейкхолдерах, мы должны не забывать, что есть регуляторы. Мы в этом примере должны спросить: «Дорогой заказчик, а кто у тебя регулятор?». Но по поводу рисков я с вами согласна, что их надо по-другому рассматривать.

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

И это как раз закрывается этапом, когда мы смотрим, кто нам диктует требования и кто будет принимать. Если изменился человек, который будет принимать, а надиктовал другой, идем к тому, кто будет принимать и еще раз переспрашиваем его требования. Лучше спросить и догнать изменениями, если у него другая картина мира.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event.