Место гибких методов управления (Agile) в практике 1С

В рамках этой статьи предлагаем сконцентрироваться на конкретной проблематике – что нам подойдет, если мы говорим о проектах внедрения масштабных, комплексных решений, таких как «1С:ERP» или «1С:Управление Холдингом». И чтобы уж совсем конкретизироваться будут даваться два варианта автоматизации – собственными силами и силами подрядной организации.

Waterfall

Первый, «традиционный» подход – это классический Waterfall, или каскадная модель. Что здесь важно:

1. Есть некий долгосрочный план проекта – от чего мы идем, к чему должны прийти.
2. План имеет понятную структуру этапов работ:
   1. Сбор требований.
   2. Проектирование.
   3. Адаптация (доработка) типового решения.
   4. Обучение будущих пользователей.
   5. Перенос начальных данных и опытно-промышленная эксплуатация системы.
   6. Перевод в промышленную эксплуатацию и выход из проекта на текущее сервисное сопровождение.
3. Этапы работ имеют декомпозицию до конкретных задач, конкретным исполнителям по всей своей «длине».

Какие у нас здесь есть проблемы на практике.

Waterfall: внедрение программы своими силами

Так как мы работаем внутри предприятия, то мы вроде как уже одна большая семья. И тут Вы приходите с предложением заключить «брачное соглашение»: прописать на долгосрочную перспективу кто за что отвечает, что будет сделано, а что нет. «А как же любовь?» — спросит у Вас финансовый директор. «В семье не без урода!» — подтвердит главный бухгалтер.

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

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

Waterfall: привлечение на проект внешнего подрядчика

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

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

Agile

В парадигме конкретизации будем говорить не об Agile в общем, а о конкретной методике среди гибких методов – Scrum.

Технологическая концепция Scrum:

1. Есть некий заказчик (Product Owner), который знает, что ему нужно.
2. Знания заказчика собраны в общий список КОНКРЕТНЫХ задач по автоматизации – бэклог в терминах Scrum.
3. Работа по автоматизации состоит из циклов – спринтов, в терминах Scrum. Каждый спринт начинается с отбора задач из бэклога, которые войдут в текущий спринт. Отбирает их заказчик (исходя из его понимания приоритета), совместно c командой проекта (Development team). Фактически при отборе происходит торг – сколько задач из бэклога влезет в этот спринт. Спринты достаточно короткие – оптимально 2 недели.
4. В процессе работы над спринтом идет активное взаимодействие команды проекта с заказчиком – он доступен в режиме реального времени. Также активно отслеживается динамика выполнения работ (погуглите «burndown chart») и фиксируются все причины задержек. Ежедневно проводятся отчетные собрания по спринту, где под руководством лидера команды (Scrum master) сотрудники команды отчитываются о выполненной работе.
5. В конце спринта команда выпускает релиз, который передается заказчику, производится итоговое собрание (ретроспектива), где сотрудники команды, совместно с заказчиком анализируют проблемы законченного спринта, так чтобы они не повторились в дальнейшем.

Во втором пункте специально выделено слово «КОНКРЕТНЫХ». Бэклог не должен содержать абстрактные задачи, например, «настроить статьи бюджетирования». Должно быть детально написано какие статьи и как должны быть настроено – постатейно. Иначе трудно оценить – помещается ли задача в спринт или нет и сколько она займет времени. А на этом и держится вся технологическая концепция Scrum – мы определили ПОНЯТНЫЙ для себе план работ, который сейчас делаем.

Кроме технологической концепции Scrum не менее важны психологические составляющие (даже более важны):

1. Команда и заказчик мотивированы – они ХОТЯТ сделать этот проект.
2. Нет преград для коммуникаций – заказчик открыт для команды проекта, команда открыта для заказчика – люди друг-другу полностью доверяют.

Scrum: внедрение программы собственными силами

Мы большая и дружная семья предприятия, в которой нет места недоверию и мы ХОТИМ внедрить «1С:ERP». Требования к психологическому настрою выполнены, дело вроде за малым – внедрить технологию.

Но есть подводные камни. Наиболее важные такие:

1. У нас несколько равновесных заказчиков (финдир, коммерческий директор, директор по производству), каждый из которых тянет одеяло на себя и считает свои задачи более приоритетными. Нам нужен тот, кто эти споры урегулирует – нужно вовлекать в проект генерального или исполнительного директора. А ему это вообще интересно?
2. Мы договорились о приоритетах и в рамках первого спринта решили начать с производства. К спринту 20-му мы дошли до финдира и тут выяснилось, что мы забыли учесть в производстве аналитику, которая нужна в бюджетировании. Мы будем переделывать 20 спринтов? Это сильно демотивирует, а если такое будет происходить регулярно? Как выделить связанные части программы, так чтобы мы решали задачи комплексно? А если мы только учимся работать в программе?
3. В один из серых и дождливых понедельников, спустя год после начала проекта, в переговорную, где идет очередная шумная ретроспектива, заглядывает генеральный и злобно спрашивает – «А когда эта бесконечная фигня с автоматизацией закончится?». У Scrum нет понятных критериев завершения проекта – есть задачи, команда их делает – как оценить перспективы и трудоемкость ВСЕГО проекта? Может за то время, которое было и будет еще потрачено, было проще нанять внешнего подрядчика?

Scrum: привлечение на проект внешнего подрядчика

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

1. Заявляем, что общий бюджет на проект — вот такой-то, но через доп. соглашения к основному договору можно будет его расширять. Проект на фикспрайс.
2. Заявляем часовую стоимость работ и рубим спринты сколько душе заказчика угодно – пока платит.

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

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

В общем пока всё печально и непонятно куда бедному крестьянину податься. Но выход есть – о нем во второй части статьи.

Для иллюстрации статьи взяты изображения из открытых источников. Всякое совпадение иллюстраций и текста статьи случайно и имеет развлекательный характер (why so serious?).