В рамках этой статьи предлагаем сконцентрироваться на конкретной проблематике – что нам подойдет, если мы говорим о проектах внедрения масштабных, комплексных решений, таких как «1С:ERP» или «1С:Управление Холдингом». И чтобы уж совсем конкретизироваться будут даваться два варианта автоматизации – собственными силами и силами подрядной организации.
Waterfall
Первый, «традиционный» подход – это классический Waterfall, или каскадная модель. Что здесь важно:
- Есть некий долгосрочный план проекта – от чего мы идем, к чему должны прийти.
- План имеет понятную структуру этапов работ:
- Сбор требований.
- Проектирование.
- Адаптация (доработка) типового решения.
- Обучение будущих пользователей.
- Перенос начальных данных и опытно-промышленная эксплуатация системы.
- Перевод в промышленную эксплуатацию и выход из проекта на текущее сервисное сопровождение.
- Этапы работ имеют декомпозицию до конкретных задач, конкретным исполнителям по всей своей «длине».
Какие у нас здесь есть проблемы на практике.
Waterfall: внедрение программы своими силами
Так как мы работаем внутри предприятия, то мы вроде как уже одна большая семья. И тут Вы приходите с предложением заключить «брачное соглашение»: прописать на долгосрочную перспективу кто за что отвечает, что будет сделано, а что нет. «А как же любовь?» - спросит у Вас финансовый директор. «В семье не без урода!» - подтвердит главный бухгалтер.
Тут нужно иметь стальную волю, чтобы этот план имел какое-то отношение к реальности. А уж в процессе работ ссылаться на этот план будет вообще неприлично – «видишь же, задача более важная пришла». План проекта превращается в некую декларацию о намерениях – «мы хотим внедрить 1С:ERP и самоотверженно работаем на этим». Сколько может длиться такой «проект» - одному Богу известно, и чем работа закончится известно только ему.
Получается, что waterfall в рамках «дружной семьи» не работает – но так ли это – поговорим дальше.
Waterfall: привлечение на проект внешнего подрядчика
Понимая всю проблематичность внедрения такой сложной системы собственными силами, предприятия привлекают к проекту внешних подрядчиков – у которых уже есть соответствующий опыт работ. С подрядчиком также проще заключить «брачный контракт» – это позволяет призвать к порядку как внешнего исполнителя проекта, так и собственных сотрудников, до которых свои руки не доходят. Второй фактор иногда даже более важен – искать управу на непокорных собственных коллег проще чужими руками, чем лезть в это самому – проект закончится, а работать вместе придется и после проекта.
Проблема здесь только одна – квалификация самого подрядчика. Исполнитель должен быть достаточно погружен в проблематику решения подобных задач, чтобы выстроить реальную дорожную карту. То есть хороший проект должен максимально приближаться к серийному изделию: входы-выходы – знаем, как внутри устроено – знаем, подводные камни – известны, объем работ – понятен.
Agile
В парадигме конкретизации будем говорить не об Agile в общем, а о конкретной методике среди гибких методов – Scrum.
Технологическая концепция Scrum:
- Есть некий заказчик (Product Owner), который знает, что ему нужно.
- Знания заказчика собраны в общий список КОНКРЕТНЫХ задач по автоматизации – бэклог в терминах Scrum.
- Работа по автоматизации состоит из циклов – спринтов, в терминах Scrum. Каждый спринт начинается с отбора задач из бэклога, которые войдут в текущий спринт. Отбирает их заказчик (исходя из его понимания приоритета), совместно c командой проекта (Development team). Фактически при отборе происходит торг – сколько задач из бэклога влезет в этот спринт. Спринты достаточно короткие – оптимально 2 недели.
- В процессе работы над спринтом идет активное взаимодействие команды проекта с заказчиком – он доступен в режиме реального времени. Также активно отслеживается динамика выполнения работ (погуглите «burndown chart») и фиксируются все причины задержек. Ежедневно проводятся отчетные собрания по спринту, где под руководством лидера команды (Scrum master) сотрудники команды отчитываются о выполненной работе.
- В конце спринта команда выпускает релиз, который передается заказчику, производится итоговое собрание (ретроспектива), где сотрудники команды, совместно с заказчиком анализируют проблемы законченного спринта, так чтобы они не повторились в дальнейшем.
Во втором пункте специально выделено слово «КОНКРЕТНЫХ». Бэклог не должен содержать абстрактные задачи, например, «настроить статьи бюджетирования». Должно быть детально написано какие статьи и как должны быть настроено – постатейно. Иначе трудно оценить – помещается ли задача в спринт или нет и сколько она займет времени. А на этом и держится вся технологическая концепция Scrum – мы определили ПОНЯТНЫЙ для себе план работ, который сейчас делаем.
Кроме технологической концепции Scrum не менее важны психологические составляющие (даже более важны):
- Команда и заказчик мотивированы – они ХОТЯТ сделать этот проект.
- Нет преград для коммуникаций – заказчик открыт для команды проекта, команда открыта для заказчика – люди друг-другу полностью доверяют.
Scrum: внедрение программы собственными силами
Мы большая и дружная семья предприятия, в которой нет места недоверию и мы ХОТИМ внедрить «1С:ERP». Требования к психологическому настрою выполнены, дело вроде за малым – внедрить технологию.
Но есть подводные камни. Наиболее важные такие:
- У нас несколько равновесных заказчиков (финдир, коммерческий директор, директор по производству), каждый из которых тянет одеяло на себя и считает свои задачи более приоритетными. Нам нужен тот, кто эти споры урегулирует – нужно вовлекать в проект генерального или исполнительного директора. А ему это вообще интересно?
- Мы договорились о приоритетах и в рамках первого спринта решили начать с производства. К спринту 20-му мы дошли до финдира и тут выяснилось, что мы забыли учесть в производстве аналитику, которая нужна в бюджетировании. Мы будем переделывать 20 спринтов? Это сильно демотивирует, а если такое будет происходить регулярно? Как выделить связанные части программы, так чтобы мы решали задачи комплексно? А если мы только учимся работать в программе?
- В один из серых и дождливых понедельников, спустя год после начала проекта, в переговорную, где идет очередная шумная ретроспектива, заглядывает генеральный и злобно спрашивает – «А когда эта бесконечная фигня с автоматизацией закончится?». У Scrum нет понятных критериев завершения проекта – есть задачи, команда их делает – как оценить перспективы и трудоемкость ВСЕГО проекта? Может за то время, которое было и будет еще потрачено, было проще нанять внешнего подрядчика?
Scrum: привлечение на проект внешнего подрядчика
Между заказчиком и внешним исполнителем априори есть крепкий забор – заказчик хочет потратить на проект меньший бюджет, исполнитель не намерен работать себе в убыток. Нужно договориться о том, как в этом заборе сделать дверцу. Варианты:
- Заявляем, что общий бюджет на проект — вот такой-то, но через доп. соглашения к основному договору можно будет его расширять. Проект на фикспрайс.
- Заявляем часовую стоимость работ и рубим спринты сколько душе заказчика угодно – пока платит.
Первый вариант сразу не очень рабочий – как обоснованно контролировать динамику траты бюджета – сколько спринтов у нас еще осталось, как это соотносится с оставшимся бюджетом?
Второй вариант на первый взгляд живой, но мы фактически работаем по сценарию – мы команды внутри предприятия, с зарплатой в разы больше чем у сотрудников предприятия. Не всякое предприятие согласится на такое.
В общем пока всё печально и непонятно куда бедному крестьянину податься. Но выход есть – о нем во второй части статьи.
Для иллюстрации статьи взяты изображения из открытых источников. Всякое совпадение иллюстраций и текста статьи случайно и имеет развлекательный характер (why so serious?).
