Не всякий проект управления можно в точности описать словами. Тем более если проект связан с абстрактным понятием. Например, если речь идет о строительстве здания, то здесь можно подобрать конкретную методику и описать ее в деталях. Другое дело, если речь идет об автоматизации. Проблема заключается в том, что понятие автоматизации имеет разный смысл в зависимости от ситуации, будь то проект с нуля или готовая методика под конкретную ситуацию, плюс ко всему имеет значение и количество заказчиков. В результате, описывая в общих чертах все варианты, людям предъявляются данные, которые могут быть малополезными в практике. В таком случае будет целесообразно рассмотреть конкретный пример.
В данной статье речь пойдет о конкретной проблеме, а именно о тех методах, которые пригодятся в проектах внедрения масштабных, комплексных решений, таких как «1С:ERP» или «1С:Управление Холдингом». И чтобы уж совсем конкретизироваться будут даваться два варианта автоматизации – собственными силами и силами подрядной организации.
Waterfal или каскадная модель.
Его относят к традиционным методам. Озвучим наиболее важные моменты:
Наличие долгосрочного плана с указанием финиша и цели.
Четкая структура плана работ, которая состоит из сбора требований, проектирования, адаптации базового решения, обучения персонала, введение первичных данных, экспериментальный ввод системы в полную эксплуатацию, полный ввод системы в эксплуатацию и переход на сервисное обслуживание.
Этапы работ имеют декомпозицию до конкретных задач, конкретным исполнителям по всей своей «длине».
Однако, данный метод имеет ряд недостатков. Рассмотрим их более подробно.
Самостоятельное внедрение программы.
В давно слаженном коллективе отношения между сотрудниками могут быть глубоко дружественными, почти семейными. Однако, если вы предложите расписать для каждого конкретную зону ответственности, то директор как минимум удивится, а бухгалтерия вообще покрутит пальцем у виска. Поэтому, чтобы воплотить такой план в жизнь, потребуются стальные нервы и сильные волевые качества. А при внедрении новой системе такая задумка вообще может провалиться в связи с новой более важной задачей. Внедрение 1С:ERP выводится на первый план и занимает большую часть внимания коллектива, а сколько продлится данная работа неизвестно. Соответственно, waterfall не сработает даже в самом сплоченном коллективе.
Привлекаем помощь извне.
Многие предприятия не рискуют связываться с такой проблемной и сложной системой в одиночку и привлекают специалистов извне. Они обладают соответствующим опытом работы, и сними легче определить зону ответственности, как для них, так и для своих сотрудников. Причем, что касается своих сотрудников, то призывать их к ответственности лучше через посторонних лиц, чем самому. Ведь подрядчики сделают и уйдут, а вы останетесь и будете работать дальше с теми, кому усложнили жизнь. А так вы и решите свою проблему, и сохраните ваши дружественные, почти семейные отношения с коллективом и начальством.
В данной ситуации существует только одна загвоздка – это профессиональная компетенция подрядчика. Он должен иметь приличную квалификацию и опыт работы, для того чтобы решать подобные задачи максимально приближенно к реальности. Для создания оптимального проекта специалист должен четко знать все входы и выходы, внутреннее устройство предприятия и его подводные камни, определять необходимый объем работ и их стоимость.
Agile.
Поскольку мы рассматриваем конкретные примеры, то в области Agile мы отдельно и подробно рассмотрим методику Scrum.
В чем же заключается структура методики Scrum:
Есть заказчик с определенными требованиями или Product Owner.
Его требования собираются в список конкретных задач по автоматизации – бэклог в терминах Scrum.
Автоматизация включает в себя несколько циклов-спринтов. Цикл начинается из отбора задач, заключенных в списке. Причем функцию отбора выполняет заказчик вместе со своей проектной группой. Иными словами, заказчик формирует список наиболее приоритетных модулей, которые войдут в текущий спринт. Сроки спринтов обычно не более 2 недель.
Далее начинается работа над спринтом, в основе которой лежит плотное взаимодействие заказчика с проектной командой. Весь процесс отслеживается онлайн. Ведется контроль за динамикой процесса и причинами его задержки. Также каждый день проводятся собрания, на которых лидер проекта принимает отчеты о проделанной работе от своей команды.
Заканчивается спринт выпуском релиза. Затем на итоговом собрании сотрудники команды обсуждают ретроспективу проекта, анализируют возникшие трудности текущего цикла с целью их избегания в будущем.
Отдельно хочется остановиться на втором пункте нашего списка, на моменте, где говориться про конкретные задачи. Для проекта очень важно, чтобы задачи были конкретными, а не абстрактными. Допустим, речь идет о настройках статей бюджетирования. Так вот, в задачах должно быть детальное описание того, какие статьи и как настраивать, строго по пунктам. То есть, в статье должно присутствовать то-то и то-то. В противном случае невозможно будет оценить объем работы по данной задаче и временной интервал на ее решение. А ведь это основа технологической концепции Scrum – определить конкретный план работ, которые в данный момент должны быть выполнены.
Однако, реализация Scrum зависит не только от выполнения его технологической концепции. Здесь еще важна и психология коллектива. Во-первых, они должны быть мотивированы на работу над проектом, иметь сильное желание его сделать. Во-вторых, оптимально налаженная коммуникация между заказчиком и проектной команды, они должны слушать и слышать, понимать друг друга и поддерживать.
Scrum: самостоятельное внедрение программы.
Итак, на вашем предприятии самый дружный коллектив, в котором все поддерживают и доверяют друг другу. И вы ставите перед собой задачу – внедрение «1С:ERP», вы всю жизнь ждали этого события и очень этого желаете. Но, и здесь найдутся свои подводные течения.
У вас есть пара-тройка отделов, руководители которых считают свои задачи наиболее важными. Соответственно, данный спор должен быть как-то разрешен с помощью генерального директора. Ему же, в свою очередь, может быть не до этого.
Допустим, нам удалось решить спор самостоятельно, мы начали работу уже почти ее закончили. Но, на последнем этапе выявил ошибку, из-за которой придется переделывать все предыдущие этапы. Такое обстоятельство сильно негативно отразится на мотивации сотрудников, а вдруг это не последний раз? И что тогда делать?
Допустим, автоматизация длится уже больше года, и тут у генерального директора не выдерживают нервы, и он решает спросить с сотрудников, когда это все закончится. И вот здесь возникает проблема, как правильно рассчитать перспективы и продолжительность всего проекта.
После обдумывания каждой из перечисленных ситуаций возникает вопрос: а не легче ли нанять внешнего подрядчика?
Scrum. Работа с внешним подрядчиком.
Для заказчика и внешнего подрядчика всегда существовал и будет существовать камень преткновения в виде стоимости проекта. Заказчик всегда будет стараться сэкономить бюджетные средства, а исполнитель будет требовать достойную оплату за свои труды. И вот здесь важно попытаться договориться между собой.
Здесь есть два варианта:
Обозначить сразу размеры бюджета, запланированного на проект, но с оговоркой на возможность дополнительных расходов по обоснованным документально причинам.
Определить почасовую оплату работ и делать спринты до тех пор, пока у заказчика есть на это деньги.
Первый вариант довольно слабый, так как четко контролировать движение бюджетных средств в проекте не получится. Вы попросту не сможете соотнести количество оставшихся спринтов с оставшимися бюджетным средствами.
Наиболее действенным кажется второй вариант, но и здесь возникает проблема. Получается, что мы создаем на предприятии команду, которая будет получать больше денег, чем сами сотрудники предприятия. Это может привести к волнениям в коллективе.
Получается тупиковая ситуация. И что же тогда нам делать, как из нее выйти? Об этом поговорим в следующей статье.
Вас также могут заинтересовать следующие материалы:
