Поговорим о типичных ошибках аналитиков и менеджеров, поскольку любой менеджер – это аналитик, а любой аналитик – это менеджер, и в наши компетенции ходит возможность делать системы качественнее.
Я всю жизнь в 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.
