Истории успеха на этапе моделирования

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

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

Если что-то пойдет не так, все найдут отговорки, чтобы не быть виноватым. Только один человек не найдет таких отговорок – это руководитель проекта.

Поэтому нам с вами как руководителям проектов нужно четко понимать нашу ответственность и роль. И с этой позиции начинать как-то действовать.

О том, какими средствами на этапе моделирования направлять команду проекта к результату, и пойдет речь в докладе.

Основные тезисы:

1. Как правило, основные проблемы проекта связаны с тем, что на этапе моделирования мы что-то делаем неверно.

2. Поговорим о том, что хорошего в проект добавляет моделирование.

3. Как организовать моделирование: каких «актеров» взять в команду, как их замотивировать и вывести на результат.

4. Как извлечь проекту пользу из этапа моделирования.

5. Кого по итогам проведенного моделирования, нужно наградить или «наградить».

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

Варианты моделирования, которые применяются в проектах

Выделим три основных варианта, как происходит моделирование.

Водопад, классика:

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

• Все участники вовлечены и хорошо представляют себе, какую нужно сделать систему.

• По мере моделирования образ системы уточняется деталями.

Agile:

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

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

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

В целом, Agile – технология рабочая, мы ее применяем в рамках отдельных этапов на крупных проектах, в целом организованных по «Водопаду».

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

Не вовремя:

• Вариант, когда мы проводим моделирование формально, для галочки. Делаем его не вовремя и вообще не управляем им.

• На приемо-сдаточных испытаниях или в опытной эксплуатации пользователи предъявляют дополнительные требования к системе: «работает не так», «нам надо еще».

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

Влияние моделирования на проект: выгоды и затраты

Если мы этап моделирования сделали правильно, у нас появляются выгоды.

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

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

Вроде с заказчиком начинаете договариваться: «Здесь нужно сделать отчет, а вот здесь сделать механизм интересный, АРМ предусмотреть»; и последовательно с ним проговариваете все пункты. При этом вы не тратите сил и времени на то, чтобы создавать систему. Вы все проецируете у себя в голове и в голове у заказчика.

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

Это малозатратно. Это просто ваши фантазии и фантазии заказчика, переложенные в технический язык.

3. Закрепляем ценность проекта в глазах заказчика: системы еще нет, а ценность очевидна. Если проект большой, и результат мы получим через несколько месяцев, а то и через год, за это время заказчик от проекта отвлекается. Ему нужно решать свои задачи – разные ситуации на рынке происходят.

Но если вы с заказчиком все вопросы проговариваете, вы сразу закрепляете, что через полгода у него появится хорошая система. Например, вы ему показываете, как он сможет сам формировать в системе БДР. Раньше ему все отчеты в Excel подгоняли. А теперь он как собственник сможет управлять своим предприятием, а не смотреть цифры, которые ему предоставили.

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

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

На основании требований они составят технический проект и задачи к реализации программистам. Дальше ваш проект перейдет в фазу проектирования и реализации.

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

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

Сказать им: «Ребята, если вы сейчас не включитесь, система будет плохой. Если вы не предложите правильный вариант, потом будем тысячу раз переделывать».

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

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

Затраты вы тоже понесете. Ничего не дается бесплатно.

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

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

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

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

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

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

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

4. Необходимо обсудить и согласовать методологию моделирования, согласовать график встреч.

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

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

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

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

Кто заинтересован в моделировании

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

Рассмотрим аргументы «За» и «Против» для нескольких сторон.

РП заказчика и собственник:

• Аргументы «За» – четкое планирование, снижение рисков задержки по срокам, не нужен дополнительный бюджет.

• Аргументы «Против». Главное возражение, что им этап моделирования не нужен. И они правы. Им лично этот этап не нужен, но он нужен вам. Вы должны честно сказать, что если этап моделирования не сделать хорошо, вдумчиво и со всей вовлеченностью, системы не получится.

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

Функциональный заказчик и пользователи:

• Аргументы «За» – понятно уже сейчас, как работает система; можно убрать риск, что разработчики что-то забудут сделать в системе; сейчас можно сказать, как будет работать система, потом уже сложнее.

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

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

Аналитики:

• Аргументы «За». Нельзя подготовить прототип системы, если непонятно, что нужно в итоге пользователям. СА нужно передать согласованные с заказчиком формулировки задач.

• Аргументы «Против». Нужно создавать проектную документацию. Все еще может поменяться, надо смотреть и дорабатывать на более-менее живом прототипе.

• Как вовлекать. С ними нужно обязательно разделить общие ценности. Их нужно продвинуть на шаг вперед, чтобы они сами захотели помоделировать. Желательно, чтобы внутри команды между вами и аналитиками был найден хороший компромисс. Тогда люди будут делать сами и с интересом.

Позитивные примеры моделирования

Покажу пару реальных примеров, когда мы получили хорошую пользу от моделирования.

1. Модельный пример позволил убедить заказчика стартовать проект. У нас была достаточно сложная продажа многомиллионного проекта в сложные времена с пандемией, когда денег всем не хватает. У заказчика был серьезный внутренний вопрос – надо или не надо?
   Была собрана группа особо возражающих, и проведено мини-моделирование ряда участков, которое им сняло возражение и неуверенность в создаваемой системе.
   Заказчик дал добро. Проект сейчас уже по ряду контуров находится в эксплуатации, и остальные этапы развиваются как положено, в соответствии с графиком.

2. В процессе моделирования выявлены и устранены методологические проблемы на стороне заказчика. По мере хорошего моделирования у заказчика вскрывается много разных методических недоработок. Он думает, что у него в учете все хорошо: бухгалтерия работает, экономисты считают.
   А когда происходит скрупулезное прохождение по шагам бизнес-процессов компании, выявляется много мелких недочетов методического характера, которые нужно прорабатывать.
   Если они будут проработаны не сейчас, а когда вы прототип заказчику предоставите, то переделать систему будет уже в разы дороже. На это уйдет много сил, это может встретить сопротивление заинтересованных лиц и т.д. Лучше проработать все истории на начальном этапе.

Хорошая практика: главные этапы моделирования

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

Автоматизируем процессы.

• Всегда автоматизируем конкретные бизнес-процессы, а не подсистемы «Закупки», «Казначейство», «Продажи» и т.д. Мы всегда должны нарезать бизнес-процессы.

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

• Любое функциональное требование должно попасть в какой-то шаг процесса. И когда ваш заказчик прибежит с пеной у рта и начнет говорить: «Давайте еще один отчет сделаем». Открываете вашу карту и говорите: «В какой шаг? Ни в какой? Тогда давайте новый бизнес-процесс автоматизировать».

Это ваш мощный инструмент перед заказчиком.

Готовимся на берегу.

• Никакого «чего изволите». Инициатива и компетенции всегда должны быть на вашей стороне.

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

  • Готов модельный пример?

  • Готова программа моделирования?

  • Готовы функциональные требования в первом приближении?

• Если все нужные артефакты у аналитика готовы, пусть идет. Если не готовы – не позорьтесь, перенесите встречу с заказчиками на неделю. Ничего страшного не случится. Главное – продолжайте активно коммуницировать и держать инициативу.

• Потратьте силы на то, чтобы ваш аналитик был готов к встрече и выходил оттуда победителем:

1. Аналитик должен выносить со встречи уже какой-то проработанный артефакт – те же функциональные требования.

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

Договариваемся.

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

Когда вы планируете встречи, разделите их на три фазы моделирования:

• Ознакомление. На первом цикле встреч ваш аналитик должен подробно рассказать заказчику, как он видит автоматизацию процессов. Не нужно, чтобы заказчик что-то изобретал. Все уже рассказано – пусть аналитик покажет, как работает система, и обозначит узкие места, которые он сам видит.

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

• Функциональные требования. На третьем шаге зафиксируйте и согласуйте конечные перечни функциональных требований.

Это три фазы, которые сделают образ вашей будущей системы достаточным.

Обеспечение встреч. Когда вы прорабатываете встречи, добейтесь, чтобы:

• заказчик подготовил нужных людей – убедитесь, что нужные люди готовы;

• было готово оборудование, помещения, а в рамках пандемии, чтобы люди были доступны;

• ваш аналитик был готов к этой встрече.

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

Сразу формируйте результаты.

• По результатам встречи – протокол. Лучше его передать в течение суток и дозаполнять сразу на встрече.

• По результатам встречи изменения в проектных документах:

  • программа моделирования;

  • модельный пример;

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

Это – Agile-действия: итеративно по ходу каждой встречи начальные версии документов, сформированные аналитиком заранее, переходят в конечный вид, который согласован с заказчиком.

Как завершить моделирование? Когда прошли все три цикла встреч, нужно все заново собрать, скомпилировать, выслать заказчику и провести:

Круглые столы.

• Их можно провести раздельно, а можно – смежно по нескольким процессным блокам.

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

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

Согласование финалочек.

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

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

Управляющий комитет.

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

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

• Отстаивайте свой труд и те результаты, которых вы достигли.

Какие результаты нужно получить

• Уточненное описание автоматизируемых бизнес-процессов. Без этого никуда.

• Программы моделирования – по сути, это описание сценариев для ПМИ (программы и методики испытаний) и инструкции пользователей.

• Модельные примеры – это тестовая база для проверки разработанного прототипа системы.

• Функциональные требования – это ваши задачи и задания на проектировку.

• Протоколы встреч.

• Уточненный график и бюджет проекта. Если требования уточнили так, что появилось разработки на 500 человеко-часов, не стесняйтесь сказать заказчику, что неплохо было бы эту разработку оплатить. Или отказаться.

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

Негативные примеры моделирования

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

Отказ от моделирования или формальное моделирование. Отказ я не встречал, а формальное моделирование на проектах встречается часто.

Если заказчик на этапе моделирования что-то сделал для галочки, потом, когда пользователи реально идут работать в систему, у них начинается: «Здесь неправильно, здесь нужно вообще по-другому, здесь не учли и т. д.». В итоге, это дополнительная разработка, а в некоторых случаях и пересоздание системы.

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

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

Что будет, если моделирование выполнить неправильно

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

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

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

Герои моделирования – какие приготовить ордена и кого награждать

Больше всех в проекте нужно РП.

Все найдут оправдания, почему они «не смогли». Оправданий не будет только у вас.

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

Это три раза слово «Контроль», а может быть и четыре, как говорил Черчилль. Вы должны на каждом участке ввести разные контроли – тогда у вас все произойдет по плану, хорошо и с нужным результатом.

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

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

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

В завершение

Поделюсь с вами кейсами. Они начального характера, но с помощью них можно какую-то свою практику дальше развивать.

• Соглашение о моделировании

• График встреч моделирования

• Программа моделирования

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

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

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

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