Эта статья покажет, как использовать графически-текстовые методы для структуризации процессов и разработки ПП как при продуктовом подходе, так и при проектном. Данный подход является классическим водопадным, но с применением элементов, заимствованных из Agile. В Waterfall модели есть 6 ступеней: пресейл (да, да, да пресейл не часть водопада, а часть воронки продаж, но мы ее рассмотрим вкупе, т.к. без него никуда), обследование, моделирование, проектирование, разработка и внедрение.

Проблемы, с которыми сталкиваемся

Я Team Lead и Бизнес-Архитектор компании ПервыйБит. По специфике нашей компании мы занимаемся крупными корпоративными проектами по внедрению комплексов программных продуктов. Зачастую мы сталкиваемся сразу со множеством проблем. Давайте по порядку разберем эти проблемы:

1.       Как оценить проект на стадии Пресейла?

Классика (ну по крайней мере в нашей компании)

Зачастую к нам приходят заказчики (в основном российские) с запросом: «Мы хотим внедрить ERP решение». Поскольку мы занимаемся в основном 1С, то это обычно бухгалтеры, причем цель перехода они объяснить не могут. Часто это просто кто-то что-то не может сделать и думает: «А ERP ведь может все…» или собственник сказал: «Мы ведь не хуже западных компаний, но SAP дорого (да и сбежал из России), а вот ERP от 1С это по нашему бюджету».

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

В итоге мы назначаем платное «Экспресс»-обследование (в кавычках, так как это минимум 2, а то и 8 недель) или аудит (тоже платный), ну или на крайний случай, если они не хотят платить деньги за данные услуги, считаем по экспертному методу. Я внедрял ПО на похожих предприятиях и примерно знаю, сколько времени нужно на проект и сколько стоит каждый контур (естественно закладываем риски).

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

Я стал ИТ-специалистом не так давно (3-5 лет назад), до этого я был 15 лет начальником производства на предприятии по производству оборудования для государства и мне приходилось работать с разными людьми (алкоголики на производстве, саботажники, бездельники, формалисты и т.д.), так что я умею работать с разными людьми и имею право так писать.

Да, бывает, что западные компании переходят на российский софт (ну сбежал SAP, ничего не поделаешь). Они дают ТЗ на 100500 страниц, где описано, как это сделано в SAP, и плюс еще приврали (ну им кажется, так будет лучше работать) и конечно, они расскажут вам, как все это нужно и назначат тендер… В итоге функциональности выше крыши (как следствие и пилить типовое решение уууу как долго…). Даже если ты выиграешь, они потом при реализации скажут: «Ой, мы упустили это в ТЗ, но вы ведь профессионалы и должны были предусмотреть, что это не склеится в единую структуру…»

Итог всего: или мы закладываем стоимость Bugatti Bolide (и все равно можем промахнуться), или сильно условная цена после экспертной оценки.

Как я предлагаю делать

Просите организовать встречу с бизнесом (всех сразу) буквально на 2 часа (ну проект от 10-15 млн., смогут оторвать людей на 2 часа) и вы с ними в быстром темпе накидываете цепочки событий (это и есть USM). Выглядит это примерно так (мы пользуемся приложением StoryMap прямо в JIRA):

• Сверху идут процессы;

• под ними идут действия;

• над процессом указываются люди, которые задействованы.

Задача этой сессии — просто записать все процессы и обозначить шаги, но это не так просто, как может показаться, тут еще важна последовательность. Надо выстраивать процессы в той последовательности, в которой они идут (благо в инструменте есть Drag&Drop, и все легко перетаскивается, если вы захотели что-то поменять).

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

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

2.      Как понять специфику бизнеса и взаимосвязи между контурами (Обследование)?

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

Классика (ну по крайней мере, в нашей компании)

• Отправляем ряд аналитиков, которые обследуют каждый свой контур;

• аналитики провели интервьюирование, получили ряд протоколов;

• архитектор проекта, если он не смог присутствовать на всех встречах, по этим протоколам рисует себе «картину жизни» в компании (допустим, архитектор почти все понял);

• аналитик рисует схему процессов AS IS в IDEF0 по своему контуру;

• архитектор проекта по этим схемам и описаниям подтверждает, правильно ли он ранее понял структуру или нет, и на основании этого всего добра архитектор строит модель AS IS по компании (и если он не прав, а часто ошибки там все равно есть, то никто его не поправит, т.к. пользователи бизнеса, которые проверяют, ничего не понимают в нотации IDEF0, но скажут вам: «Да, все верно», они ведь «образованные» и видят, что все верно);

• далее аналогично с моделью ShouldBe;

• и в итоге архитектор выдает целевую архитектуру и дорожную карту развития (от старта проекта это занимает от 1 до 3 месяцев).

Как я предлагаю делать

• Первым делом, если была составлена USM на пресейле, собираемся «кружком» проектной команды и пересматриваем видео с сессии создания User Story Map и тех, кто там не присутствовал, погружаем в специфику (обязательно здесь появятся вопросы: что, как и почему. Все это тщательно фиксируем на следующем уровне карты (обычно для таких вопросов я в Jira ставлю тип «история» или «вопрос», а для ответов или фиксации реальных требований «задачу»). Эти вопросы вы зададите бизнесу. Когда получите ответ, не стесняйтесь завести новую задачу, а эту удалить после получения ответа. Карта — это рабочий инструмент, а не свалка идей и вопросов (на этом очень многие обжигались и тонули в куче карточек). На командной встрече вы уже сможете, не начиная обследования, понимать общую картину, с чем столкнётесь. И когда аналитики разбегутся по контурам на интервьюирование ключевых пользователей, они начнут заполнять этот нижний уровень карты (не отменяйте протокол, помните, карта — это ваш инструмент, а протокол — это то, что проверяет и подтверждает заказчик);

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

• после того, как интервью закончено, наступает время отрисовки и описания процессов AS IS. И тут нам приходит на помощь USM, ведь когда мы рисовали карту и двигали карточки таким образом, чтобы у нас образовывались последовательные истории, мы получили почти IDEF0 (тут меня наверно чем-то закидают методологи… ну допустим «помидорами», но я скажу). Абстрагируйтесь и возьмите верхний уровень карты. На что похожа предыдущая история? Это вход, сверху – пользователи (ну в IDEF0 их надо вниз), следующая история — это выход из предыдущей. Да, это не совсем IDEF0, но по нему вы легко нарисуете (что-то объединив, что-то декомпозировав) и самое главное, по USM архитектор легко сведет общий AS IS;

• далее, обратившись к уровню ниже, мы увидим функции, которые клиент хочет получить, и легко нарисуем процесс ShouldBe (в нашей компании мы отрисовываем в BPMN 2.0);

• далее, поскольку архитектор видит всю картину целиком и на схемах, и в USM, он уже более корректно может выбрать целевую архитектуру и создать дорожную карту;

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

3.       Что моделировать (Моделирование)?

Вот мы сделали документацию и теперь-то нам уже не нужна USM? И опять я скажу, что нет, она нам нужна даже больше, чем до этого момента.

Классика (ну по крайней мере в нашей компании)

• Аналитики пишут кейсы для демонстрации программного продукта, каждый по своему контуру;

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

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

• аналитик фиксирует договоренности;

• архитектор создает отчет по моделированию.

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

Как я предлагаю делать

• Кейс у вас уже есть, кейсы для моделирования — это USM. Все, что нужно команде, это собраться и распределить кто что показывает;

• далее настройка базы производится архитектором, чтобы покрыть всю потребность заказчика;

• аналитики наполняют базу примерами (данные примеры формируют сквозную цепочку операций согласно USM), в результате у заказчика будет сквозной пример;

• при демонстрации у нас под рукой USM, на основе которой мы можем проговорить функциональность и не забыть ее. Обычно те истории, которые показаны или обсуждены в рамках моделирования, меняют статус на «Принято в типовом функционале», если удовлетворили заказчика в типовом варианте или «Принято к разработке», если заказчик подтвердил, что данная функциональность требуется именно в том виде, в котором она может быть получена только после доработки (обычно сразу ставим приоритет, «Высокий» это MVP, «Средний» в рамках проекта, «Низкий» на развитие системы);

• далее в договоренности переносится почти вся USM (ведь она у нас уже ранжирована и подтверждена);

• формирование финального отчета является формальностью.

Как итог, мы уже получили задачи на проектирование и разработку в JIRA (это у нас и есть наши задачи по USM, поскольку это приложение JIRA, то и переносить ничего никуда не надо).

4.       Проектирование и разработка (эти 2 этапа я традиционно объединяю)

«Ну уж тут без ЧТЗ не обойдешься», скажут многие и опять будут не правы. Хотя я и не говорю, что ЧТЗ не нужно, ладно, дальше почитаете и поймете.

Классика (ну по крайней мере в нашей компании)

• Аналитик пишет огромный трактат (как вы помните, функциональность обсуждалась давно и что-то могло забыться, особенно если на моделировании вскользь коснулись), который должен проверить заказчик. Если аналитик не начинающего уровня, он пишет с привязкой к объектам системы (вплоть до регистров). Когда пользователь получает эту штуку на проверку, ну надо же подтвердить, что требование верное, он приходит в ужас и говорит: «Да это то, что нужно!» (аналитик же говорит, что это то, что заказали) и тут все вспоминают картинку с качелями, но я приведу другую (надо же разбавить стереотип);

• далее разработчик берет в работу, и вуаля – хобот;

• аналитик тестирует;

• тестировщик тестирует;

• показывают пользователю, а он говорит, что это не то.

Даже не буду комментировать это.

Как я предлагаю делать

Ну тут даже расписывать не буду, все очень просто. Когда аналитик работает с программистом, он для него пишет краткое ТЗ, далее они по USM проходятся, ну конечно, не по всей карте от и до, но по основным моментам. И по этой карте аналитик погружает программиста в специфику проблемы, что есть, что будет и как это должно произойти. В процессе этой беседы аналитик с программистом декомпозируют задачу, или группу задач, в мелкие «камушки». После получения мелких камней с техническими тонкостями, аналитик корректирует ТЗ и определяет MVP конкретной доработки. Я обычно делаю через релизы JIRA, MVP это первый, и далее еще 1 релиз, в нем всегда одна карточка «Проверил, проверь еще». Потом уже релизы делаются на дополнительные «бантики» и удобство пользователя. Каждый релиз вы демонстрируете пользователю и обязательно просите сделать минимум 3-4 документа или что там дорабатывалось.

5.       Наконец внедрение

Тут не буду вас путать классикой, просто расскажу, как USM помогают жить на внедрении:

• USM сам по себе - это прекрасные сценарии того, как ведут себя пользователи, следовательно, можно прогонять сквозные и интеграционные тесты просто глядя на карту;

• USM помогает найти ошибки, когда у пользователя что-то не получается;

• USM помогает, если в процессе внедрения нужно разработать дополнительный функционал;

• USM помогает сформировать план развития системы.

6.       А теперь об управлении проектом

Ну а теперь поговорим про то, что USM — это не только про продукт… Да, да это прекрасный способ управления проектом.

Когда мы начинаем проект, я его просчитываю (финансово) в MS Project, но проблема в том, что очень трудозатратно отслеживать фазы проекта, это кто-то должен вносить факт в документ. Но стоп, у нас ведь есть прекрасный инструмент JIRA. Хотя СТОП, мы тут всю дорогу обсуждали водопадную концепцию и тут всплывает, давайте управлять проектом инструментами Agile? Да, я не запутался, все просто, Jira может многое, а приложения для Jira еще больше. Вот я и пользуюсь StoryMap управления:

• Epic – это этап проекта;

• Story – это задача проекта.

Теперь как это выглядит, если после расчета в Project, я экспортирую задачи в Jira (занимает 2 минуты). Вот пример:

Далее есть еще такая классная штука как RoadMap, идет в том же приложении, что и StoryMap, но дает огромные возможности вести в Jira График Gant и смотреть, как команда продвигается по нему:

Заключение

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

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