Введение
Данная статья вторая из цикла про создание Карт процессов. Как и в предыдущей статье я буду касаться применения гибких методологий в проектах Waterfall, то в данном материале я покажу как создать с заказчиком верхнеуровневую модель процессов и зафиксировать 90% функциональных требований за одну встречу.
Я Team Lead и Бизнес-Архитектор компании ПервыйБит. По специфике нашей компании мы занимаемся крупными корпоративными проектами по внедрению комплексов программных продуктов. Самое сложное в нашей работе — это на этапе обследования зафиксировать все потребности клиента, синхронизировать в общую архитектуру комплекса систем, а этих систем бывает ох как много, и это я не говорю о внешних сервисах и ГИС системах.
Сразу оговорюсь, необязательно ждать обследования. Если
клиент готов выделить на 4 часа всех заинтересованных в проекте, то карту можно
строить и на стадии пресейла, это поможет определить рамки и понять объем
проекта.
Итак, Этап 1. Как бы ни хотелось, но это еще не построение карты
На первом этапе нам нужно:
Собрать ключевых пользователей и их руководителей (да, «банда» большая, но и мы в «тельняшках»). Тут надо предупредить, запаситесь попкорном, тот еще будет боевик. Так вот, все эти люди будут говорить (и даже самые тихони начнут общаться). Главное всем периодически напоминать, что им дальше работать в этом коллективе еще какое-то время, иногда споры бывают такие жаркие, что думаешь: «Ну все, я не уйду отсюда живым, зачем последнему выжившему свидетель?» (ну это, конечно, шутка).
На этой стадии нам нужно выделить большое помещение с проектором или огромной стеной. Огромная стена для трудоголиков, я предпочитаю проектор. Так вот, если у вас стена, то запаситесь стикерами разных цветов штук по 500 каждого (минимум 3 цвета, но чем больше, тем лучше) и фотоаппаратом (надо будет ваши труды зафиксировать, иначе уборщица со всей скрупулезностью уберет труды всей честной компании). Вот по этой причине я и предпочитаю проектор (наклеивать на него стикеры неудобно, но мы же ИТ-специалисты и можем подобрать нужный софт, да хоть тот же Excel (сразу предупрежу, Excel неудобно).
Сам софт! Я использую JIRA для управления командой и отслеживания продвижения проекта (да, она при должной смекалке сможет и Гант построить и показать состояние). Так вот, на JIRA у меня установлено приложение StoryMap, вот этой связкой я и работаю, Вы, наверное, спросите: «Зачем такие сложности, ведь много софта и даже попроще и не нужен такой монстр, как JIRA?» Да, Вы правы, ее настроить то еще удовольствие. Но, как Вы помните, я ее использую как Task Manager, и полученная карта будет интерактивно заполняться фактами, которые отражает команда и мы видим реализованную функциональность в рамках MVP, ближайших релизов и перспектив на развитие, плюс мы всегда легко сможем управлять тем какая функциональность где подключается (я пишу именно «подключается», поскольку как Вы помните, я «Одинэсник» и нам свойственно больше настраивать коробку нежели пилить кодом).
Собственно подготовка завершена, вот теперь переходим к самому главному - а с чего начать? Какой угол выбрать? Советую левый верхний, если вы не привыкли смотреть на сроки реализации проекта в прошлом, месяцев на 5-6. Да, такие проекты случаются у некоторых «одаренных» РП, и им приходиться обычно читать: «что у нас сегодня, ага январь», хотя на дворе июль, ну идею надеюсь уловили! Вот в следующей главе мы и начнем с этого левого угла.
Этап 2. Первые шаги, пока не уверенные, но быстро крепнущие
Почему я написал, что шаги неуверенные, хотя я уже построил много разных карт? Да все очень просто, карту строите не Вы, а вся та «банда», которая пока мило улыбается, но вскоре с пеной у рта что-то начнет доказывать своим коллегам (они еще не знают, как работать с таким инструментом и вообще, что сейчас будет)! Так вот, Вы во всей этой истории дирижер (покажите, как надо играть, а оркестр все сделает за Вас), Ваши аналитики играют роль барабанов задавая ритм и следя, чтобы отдельные скрипки не заиграли не ту мелодию.
Ну что, приступим:
Первым делом надо понять какие процессы есть и в какой последовательности они идут. И тут обычно ступор, клиент не понимает, что от него хотят. Тут включаются Ваши аналитики, они подсказывают, например:
Аналитик: «У вас есть продажи?»
Клиент: «Да»
Аналитик: «А как Вы ищете клиентов?»
Клиент: «Они нам скидывают заявку»
Аналитик: «Вот и первый процесс, назовем его «Получить заявку». Что происходит дальше?»
Клиент: «Ну мы идем согласовывать с ...»
Аналитик: «Хорошо, то, с кем вы идете согласовывать это шаги, сам процесс — это согласование, это второй процесс, что дальше?»
И тут клиента прорывает, он начинает все выкладывать,
иногда приходится возвращать его на рельсы, что мы обсуждаем процессы
Зарисовываем эти процессы, впоследствии мы начинаем развивать успех, «А то, что мы сейчас проговорили и продали, Вы закупаете или производите?» и так далее. Созданные карточки часто начинают двигаться, клиент говорил сначала «...выставляем счет, потом оплата, потом бронирование товара, потом отгрузка...», часто в этот момент кто-то из склада говорит: «Нет мы как увидели у вас заказ, сразу начинаем его откладывать на отгрузку...» Это самый замечательный момент, мы можем без усилий синхронизировать отделы, и вся наша команда будет знать, что зачем идет. В такие моменты мы показываем проблему нестыковок и даем шанс всем договориться... Обязательно ведите видеозапись встречи, иногда спор бывает сильно разгорается и вам нужно его несколько раз прослушать, чтобы понять к чему пришли клиенты
Собираем всю модель целиком на уровне процессов, далее говорим: "Ну с процессами и последовательность разобрались, теперь давайте зафиксируем ответственных за процессы". И тут мы видим опять ужас в глазах и читаются такие мысли: "Что значит ответственный, оно же само как-то работает..." (ну да ладно, тут мы рассказываем, что, зачем и почему. Люди адекватные соглашаются и прописывают владельцев процессов). Но тут не все так просто, у этого владельца есть целый профиль в системе и его надо заполнить. В дальнейшем это поможет и нам, и клиенту взаимодействовать. Если мы заполняем не на проекторе, а на стене, то такая же карточка на роль ответственного делается одна и хранится в уголке стены, а над блоками процессов приклеивается стикер только с ролью или ФИО сотрудника. Вроде все хорошо, но, как Вы поняли, это еще не все, рядом с ФИО сотрудника, должна быть ФИО нашего аналитика, который будет отвечать за тренинги по данному процессу и вообще до конца проекта за этот процесс. Если работаем через систему, то необходимо поставить признак, что это глобальная роль, чтобы в рамках каждого проекта не пришлось прописывать наших аналитиков
Этап 3. Мы наконец на первом этапе детализации наших процессов
Тут Мы начинаем декомпозировать процессы на шаги. Вот наконец и пришел заветный час того, кто хотел рассказать нам, как согласовываются заказы. Задача этого этапа — это разделить большие процессы на логические шаги, но главное не мельчить, здесь важна развернутая структура процесса, а не каждая мелочь.
На данной стадии ответственные за процессы начинают показывать из чего состоит процесс, и его коллеги начинают подсказывать как должно быть (ведь они умнее) опять жаркая дискуссия, где мы получаем более или менее согласованные шаги, и они действительно более осмысленные чем обычно мы слышим на классическом обследовании. Принцип их помещения в карту такой же как на предыдущем шаге. Добавляем, перемещаем, выкидываем или объединяем. Тут главное не стесняться, видите, что намельчили - объединяйте в одну карточку, а ненужные выкидывайте.
Все просто, но это даст согласованный процесс (да, он
плоский и без явной вариативности) но Вы не забывайте, если работаете на стене,
то переверните карточку и напишите условия вариативности, если работаете в
JIRA, то откройте описание задачи и все впишите туда, я часто даже прикрепляю
туда схемы BPMN2.0 или IDEF0.
Этап 4. Нюансы, проблемы и хотелки
Чтобы написать про эту часть, скажу так: «Здесь должно быть все!». Написал я это не для красного словца, а вполне с осмысленной идеей. Так вот, что нужно на этом уровне:
Функциональность, что есть сейчас и устраивает. Если Вы приверженец пера и чернил, тут как раз пора взяться за разноцветные стикеры, выделяйте разным цветом разные типы, желательно не использовать цвета процессов, но это не критично). Если Вы из тех, кто «Автоматизация наше все» то я, рисуя карту, использую типы задач, например, текущая функциональность — это тип «История»;
Далее идут проблемы, тут мы фиксируем что неудобно в текущей системе. С Вашего позволения про стикеры не буду, ну не пользуюсь ими, мне неудобно. А вот в JIRA, я применяю тип задач «Ошибка» тот же, что потом будет исправляться при фиксации багов, т.к. это тоже баги и их надо устранять;
Далее идут нюансы, с ними все просто — это истории с приоритетом «Высокий»;
И наконец, хотелки, некоторые пренебрегают ими боясь раздуть функционал, но я их люблю, это поле для творчества сейчас при отрисовке процессов. В будущем эти хотелки будут или реализованы (при составлении договора на этап проектирования, мы пробегаемся по хотелкам и ими балансируем этап проекта (чем бы клиент ни тешился, лишь бы платил) или отложены на развитие (развитие – это то, за что мы получаем второй мини-проект). После запуска мы поднимаем карту и говорим: «Вот есть пожелания, которые выходили за рамки проекта, и мы готовы их воплотить за n денег, правда нужно мини доп. обследование для актуализации хотелок и добавления новых, но это совсем другая статья.
В этом разделе мы описали все функции относительно каждого шага, тут если есть возможность, лучше тоже не мельчить, по крайней мере для общей картины, но запрета нет (если у людей после дискуссий по процессам есть силы генерировать идеи то welcome, самое главное, здесь должны активизироваться аналитики, они должны не только направлять, а полноценно вызнать про каждую функциональность у пользователя, им потом это демонстрировать и воплощать (с последовательностью я не напутал, как помните у нашей компании основной вектор проектов - это методология waterfall с адаптацией коробочных решений).
Этап 5. MVP, полная функциональность и развитие
Пора нашу карту разделить на этапы реализации. Да, да, да в Waterfall мы делаем все, и релиз — это полная функциональность, но я сейчас не про релизы, а про приоритезацию функциональности.
Первый приоритет — это то, без чего не будет вообще работать бизнес, он называется MVP. Получив данную функциональность на этапе обследования, вы поймёте тот минимум, чтобы заказчик смог запуститься в кратчайшие сроки, ну и плюс данные блоки должны работать «железно». Обычно, если после передачи в промышленную эксплуатацию ломается что-то из этого функционала, бизнес встает, а встает он когда? Правильно, в 3 часа ночи, а через час отгрузка крупному клиенту (да еще и ЖД вагоном, со стоимостью простоя…), и Вы вылезаете из теплой постельки и топаете к компу нажать 3 кнопки.
Второй приоритет – это полная функциональность. То, на что Вы подписались в контракте. Тоже надо делать, но, если к сроку Вы не успеете, заказчика все равно сможете запустить, и в процессе Вы доделаете остаток этой функциональности (обычно это удобство пользователя).
Третий приоритет – это развитие. Это то, что мы зафиксировали на обследовании, но не входит в реализацию по контракту. Если на проекте после первых двух приоритетов осталось время и ресурс, сделайте пару «бантиков» из этого функционала. Клиент доволен и скорее у вас что-то повторно закажет, а может порекомендует Вас в Холдинге и там всегда есть что делать.
Итак, в чем проблема всех проектов, в любой отрасли не только ИТ? Ответ один - превышение сроков и превышение бюджетов. Сталкивались? Если Вы ответите «Нет», напишите это в комментарии, я пойду копать картошку, видать я не подхожу для работы с проектами))) Про картошку это, конечно, шутки, но вот про сроки и бюджеты — это реалии. Конечно, мы все с этим сталкиваемся и когда видим, что не успеваем начинаем:
договариваться о продлении сроков;
договариваться об увеличении бюджета;
договариваемся об уменьшении функционала;
жертвовать качеством, т.е. выкидывать непроверенный функционал на клиента (если Вы пользуетесь этим шагом, Вам пора уходить из проектного бизнеса, не потому что это неправильно, а потому что у Вас в итоге и бюджет уйдет еще ниже и сроки уедут «вправо»).
Чтобы этого не было, давайте поймем, что не так с оценкой? Почему бюджет улетучивается, а сроки только растут? В данной статье я пройдусь только по «шапкам», чтобы понимать суть (будут запросы - напишу обзорную статью про проектные сроки и бюджеты).
Что не так?
Первый убийца сроков — это Гант (как ни странно, мы все его планируем, и он всегда съезжает). Да был такой человечек, который придумал такой способ визуализации. Способ хороший, но не надо его показывать команде! Спросите почему? Все потому, что есть такой эффект, под названием «Эффект студента» и что он нам гласит? Не откладывай на завтра то, что можно отложить на послезавтра. Как ни парадоксально, но оно так и есть. Если же Вы супер дисциплинированы, то и на это есть эффект под названием «Эффект Паркинсона», а он гласит: работа растягивается на то время, которое ей отведено. В итоге, если Вы нормальный человек, то найдете 1000 причин сделать работу попозже, если Вы супер дисциплинированный, то найдете те же 1000 причин для украшательства решения задачи (и неважно программист Вы или аналитик). А что происходит, если задача выполняется к концу, да, да, да еще один, но не "Эффект", а закон «Мёрфи», и он гласит: «Если что-нибудь может пойти не так, оно пойдёт не так» (кто любит критиковать использование иностранных названий, не радуйтесь, я сам переведу «Закон подлости»). И вот, на каждом отрезке Ганта мы получаем "плюс" по срокам из-за различных факторов, но никогда не получаем уменьшение сроков.
Теперь бюджет! Ну тут тайны открывать не буду, но скажу прямо: команда отчитывается, что все хорошо, что вот-вот закончат и что Вы делаете? Конечно, оплачиваете сверхурочные, так как из предыдущего абзаца мы видим, что сроки улетели и надо выкручиваться, в итоге команде озвучивают новые сроки, а дальше… нет не угадали, неуспешный выпуск продукта, ТЗ, протокола или чего-то в этом роде, а поднимаемся к началу этого раздела и перечитываем (именно, мы планируем, чтобы сорвать...).
Открою тайну, в подходе Agile тоже планируют, но они сразу говорят «Да кто его знает, наверное, 10 недель, но возможно сделаем быстрее на 4 недели или дольше на 6 недель» (не надо меня закидывать чем попало, я люблю гибкие методологии и сам частенько планирую так, но что есть, то есть). Вот тут и таится вся разгадка, нет единой оценки непонятно чего, есть окно, в которое они попадут с какой-то вероятностью... Далее все планирование и оценка сложности лежит на команде, и она все оценивает, Вы замеряете их скорость (какой объем они выполняют за итерацию) и постепенно сужаете рамки. Видели куда я спрятал «кролика»? Именно они дают результат в конце итерации, мы смотрим какой кусок они «съели» и даем на следующую итерацию такой же и подтверждаем гипотезу, что команда адекватно оценивает и двигается стабильно.
Теперь, как это перенести на Waterfall? Да, у нас нет такой возможности при работе с клиентом дать вилку в длительность проекта. Но USM - то, что мы делали на последнем этапе, дает нам управляемость разработкой. Вы даете приоритезацию на функции, а не стадии процесса и подходя к этапу разработки, у вас есть приоритет 1 - MVP, приоритет 2 - Полная функциональность и приоритет 3 – Развитие.
Как мы управляем сроками? Все просто, делаем MVP, причем не разрознено, а по процессам, т.е. есть "процесс 1" - сделайте MVP по нему, протестируйте и покажите пользователю, приступайте к MVP "Процесс 2" и так далее, пользователи захотят - протестируют, не захотят - тоже протестируют, но, когда им скажет руководитель проекта со стороны заказчика (это, кстати, задача Team Lead, организовать и донести, что так проект будет успешней). Таким образом, к концу сроков у Вас точно будет минимальный функционал, с которым заказчик сможет запуститься в случае, если срок очень важен, возможно у Вас будет часть или весь функционал полной реализации, ну и развитие Вы берете, если осталось время (не пренебрегайте сделать заказчику что-то из хотелок, если бюджет и сроки позволяют, что-то сверх ожидаемого делает клиента лояльней, и он вас посоветует по сарафанному радио или сам будет еще что-то заказывать только у Вас).
Как мы управляем бюджетом? Да все так же, мы видим
куда идем и можем на ранней стадии обсудить с заказчиком, что мы что-то
перенесем из полной функциональности в развитие, или он выделяет дополнительное
финансирование... но это на бумаге хорошо, обычно заказчик не согласится ни на
бюджет, ни на сокращение функционала. Ну в таком случае Вы плохо рассчитали
риски, значит оценка была неверна, в следующий раз оцените лучше! Есть, конечно,
и еще приемы управления бюджетом, но это тема другой статьи, по запросам
напишу)))
Заключение
В заключении напишу, что данная технология составления User Story Map описана для использования в каскадной технологии ведения проектов, однако может использоваться и в продуктовой разработке, и в управлении проектом. Спектр применения ограничен только Вашей фантазией.
