"Гнем" Waterfall

Введение (точнее продолжение)

По итогам рассмотрения обоих методов управления получилось, что Scrum (Agile) лучше использовать на внутренней автоматизации, Waterfall – при привлечении подрядчика. Но и в том и в том случае у нас остались незакрытыми определенные возражение:

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

Говорить в целом о какой-то универсальной «золотой» методике управления проектами не приходится – её нет. Но есть разумный подход к автоматизации, который я постараюсь изложить далее, в привязке к этапам проекта – напомню, что говорим мы конкретно о проектах внедрения «тяжелых» программ, таких как 1С:ERP.

Этап продажи проекта

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

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

Следующая задача – это провести правильную декомпозицию этих целей до конкретных управленческих задач. Что это значит, рассмотрим на практике: предположим, что мы решили, что внедрение 1С:ERP поможет нам снизить затраты. А за счет чего снизятся эти затраты?

1. Мы будем качественно контролировать наш производственный персонал, и они будут работать больше, а получать столько же.  Хорошая идея – но нужно подумать – а они точно согласятся работать больше? Или они у Вас уволятся? И где Вы найдете новых? Здраво оцените эти риски, прежде закладывать такую задачу в проект автоматизации.
2. Мы будем качественно контролировать расход материалов. Вообще отлично – а у Вас есть актуальные нормативы расхода материалов? А как быстро Вы их актуализируете? А у Вас есть люди чтобы это сделать? Программа сама нормы не посчитает, и сама в себя их не занесет.
3. Мы исключим закупку и производство неликвидов. А мы умеем прогнозировать сбыт? А с какой вероятностью? 1С:ERP пока этого не умеет.

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

И без этого ни чего у Вас не взлетит – хоть Agile это будет, хоть PMBoK – мы автоматизируем бизнес и здесь всё идет от реальных целей бизнеса.

Этап проектирования

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

Здесь важна квалификация консультанта или бизнес-аналитика, который должен грамотно подобрать из существующего в 1С:ERP, то необходимое заказчику. И правильно показать это – составить пример в демо-базе на данных заказчика и продемонстрировать систему лучшим образом: НЕ НУЖНО показывать то, как производят самолеты на данных мебельного завода – утрудитесь создать адекватный пример. Тогда не нужно будет писать бумажный талмуд ТЗ - люди уже увидели в системе себя, они согласуют и общее описание концепции автоматизации. Только не забудьте вписать в неё важные для Вас требования, без чего это решение не заработает.

Суммирую: идем от бизнес-требований, грамотно показываем примеры в демо-базе, согласуем проектное решение. Делаем всё быстро.

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

Что если заказчик не знает, чего хочет? Не в состоянии выставить бизнес-требования?

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

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

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

Этап адаптации системы (доработка типовой конфигурации)

Если мы не смогли уложить бизнес-требования в типовой функционал программы, то нужно дорабатывать 1С:ERP. Работаем также от «наглядности» – в первую очередь готовим эскизы новых экранных форм, эскизы будущих отчетов, описываем логику их работы. Согласовываем всё это с заказчиком – это основа будущего ТЗ на доработку. Под эту основу проектируем внутренние механизмы программы – код, регистры и т.п.

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

По сути это тоже квази гибкий подход к разработке – идем от приемки работ (то есть от будущего тестирования нашего решения). И тоже стараемся работать максимально наглядно.

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

Этап обучения пользователей

Повторю своё выступление на Infostart Event 2017 – не научишь пользователей на этапе обучения. Пока сами не начнут работать – не научатся. Поэтому наша задача на этапе обучения – убедить пользователей, что они смогут работать в программе – показываем им примеры их работы в 1С:ERP на их данных, чтобы они максимально быстро вникли в ситуацию – «заходишь сюда, делаешь так – вот твои пельмени, всё понял?». Не показываем общих вещей и всего сразу и всем одновременно – это не работает.

Об инструкциях – их редко кто читает, по возможности избегаем этого.

Тоже достаточно гибкий подход – без абстрактного преподавания обо всем и ни о чем.

Но не забываем подписывать протоколы обучения – кто учился и чему.

Этап опытно-промышленной эксплуатации

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

1. Каждое обращение пользователей фиксируем.
2. Дальше оно маршрутизируется на следующие очереди (трекеры):
   1. Это не ошибка – пользователь забыл, как работать.
   2. Это баг – но можно найти обходное решение.
   3. Это баг – работать так не можем.
3. На обращения во всех очередях накладывается матрица приоритетов:
   1. Сделать сейчас – иначе нас отсюда выгонят к вечеру.
   2. Сделать до завтра – иначе нас выгонят завтра.
   3. Сделать в разумные сроки – указать какие.

По комбинации 2.a + 3.a быстро назначаем умного консультанта, удостоверяемся что пользователь понял и может работать дальше.

По комбинации 2.b + 3.a быстро даем обходное решение, контролируем что оно работает.

По комбинации 2.с + 3.a бежим сразу и всем составом – кто первый добежит. Таких ошибок должно быть минимальное количество – это критический просчет на этапе проектирования.

По комбинации 2.a + 3.b назначаем в очередь консультантам с высоким приоритетом, за час до конца дня удостоверяемся что такая очередь пуста – иначе бежим всем составом её разгребать.

По комбинации 2.b + 3.b даем обходное решение, пишем пользователю что его задача поставлена разработчикам. Контролируем завтра, что пользователь пользуется заплаткой.

По комбинации 2.с + 3.b ставим срочную задачу разработчикам, контролируем процесс её решения в течение дня.

По комбинации 2.a + 3.c назначаем в очередь консультантам со средним приоритетом, контролируем срок.

По комбинации 2.b + 3.c даем обходное решение, пишем пользователю что его задача поставлена разработчикам. Контролируем срок реализации.

По комбинации 2.с + 3.c ставим задачу разработчикам, срок реализации.

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

Примерно вот так:

Несколько «хинтов» из практик:

1. Взятые в работу задачи как-то помечайте, но с доски не снимайте – чтобы видеть.
2. Задачи могут переходить из столбцов – например, когда «когда-то» превращается в завтра.
3. Чтобы не мучиться с назначением приоритетов (a-b-c) в процессе работы, заранее сегментируйте пользователей по приоритетности решения их проблем. Например, если это кассир и он не может принять иди выдать деньги, то это однозначно a. Потом, когда люди будут обращаться, приоритеты будут назначаться автоматически – Вы будете их лишь корректировать.

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

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

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

Вот Вам и квази канбан доски и ретроспектива.

Заключение

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

По идее, Вы должны сесть и написать табличку с тремя столбцами:

1. Что полезного я получу от внедрения нового инструмента в работу.
2. Что я потеряю при этом, какие риски появляются.
3. Где я могу это применять.

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

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

АНОНС: В рамках первого дня Infostart Event 2018 состоится круглый стол, где мы "вживую" обсудим оба подхода к автоматизации - использование классического Waterfall и гибких методов управления проектами. Будем очень рады, если посетители круглого стола сами захотят выступить и рассказать о своем опыте работы - с чем они столкнулись на практике. Время круглого стола смотрите в программе мероприятий.