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

22.05.24

Управление проектом - Компетенции и навыки РП

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

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

 

Я всю жизнь в 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.

 

10 - 12 октября 2024 года состоится конференция INFOSTART EVENT, на которой прозвучит 130+ докладов.

Темы конференции:

  • Администрирование серверов 1С и СУБД. HighLoad оптимизация
  • Инструментарий разработчика. Приемы и методы разработки 
  • Интеграция и обмен данными 
  • Мобильная разработка и чат-боты 
  • Управление проектом и продуктом 
  • Управление командой 
  • Управление ИТ 
  • Мотивация, лидерство и личная эффективность 
  • Идеи и тренды в разработке

INFOSTART EVENT - крупнейшая профессиональная конференция для программистов 1С.


Подробнее о конференции.

 


См. также

Технические навыки аналитика 1С

Компетенции и навыки РП Бесплатно (free)

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

20.05.2024    918    0    TanyaRi    1    

6

Адекватность РП и тимлидов. Часть 1. Вмешательство в процесс и влияние на результат

Компетенции и навыки РП Конфигурации 1cv8 Бесплатно (free)

В процессе написания статей на тему Идеальное место работы ЗУПера нужен аргументированный текст про адекватного РП и тимлида. Информации получилось много, поэтому выделю в отдельные 2 статьи. Рассмотрим все особенности работы руководителей проектов.

02.05.2024    2812    0    biimmap    39    

38

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

Компетенции и навыки РП Руководитель проекта Бесплатно (free)

Статья о том, как быть эффективным руководителем проектов. Кто такой руководитель проектов, что подразумевает эта роль в проекте, и зачем она нужна?

22.03.2024    759    0    PChizhov    0    

6

Управление проектом Руководителем проекта со стороны Заказчика

Компетенции и навыки РП Взгляд со стороны Заказчика Бесплатно (free)

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

26.02.2024    1242    0    user1270271    0    

13

Нужно ли аналитику 1С знать конфигурирование?

Компетенции и навыки РП Работа с требованиями Бесплатно (free)

Аналитики 1С не всегда хорошо представляют себе, в каких таблицах системы хранятся данные, и из каких объектов состоит конфигурация. Как следствие – технические задания часто получаются непонятными для разработчиков. Расскажем о том, зачем аналитику разбираться в таких темах, как конфигуратор и структура метаданных, регистры, запросы, СКД, интеграция и обмен данными.

02.02.2024    1853    0    otkalo    1    

12

5 основных внутренних ограничений руководителя

Компетенции и навыки РП Руководитель проекта Бесплатно (free)

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

22.01.2024    1249    0    andmakarov    2    

13

Риски, роли, книги и светлое будущее для ПМов: проектный дайджест #35

Компетенции и навыки РП Обучение и наставничество Инструменты управления проектом Бизнес-аналитик Руководитель проекта Бесплатно (free)

Что интересного писали про управление проектами за прошедшую неделю? Мы прочитали все публикации vc, Хабра, Инфостарта (и не только) и выбрали самые крутые и полезные.

09.10.2023    1031    0    Birby    0    

2

Методика оценки задач или Как «не угореть» по срокам

Компетенции и навыки РП Программист Руководитель проекта Бесплатно (free)

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

31.08.2023    2898    0    Midzgun    4    

13
Оставьте свое сообщение