Системный IT - интегратор
Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages
+7 (499) 755-54-96
info@itbconsult.ru
По будням с 9:00 до 20:00 (МСК)
ИТБ Консалтинг
+7 (499) 755-54-96

Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages
МЕНЮ

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

By nik Рубрика Блог

05

Июл
2019

Не всякий проект управления можно в точности описать словами. Тем более если проект связан с абстрактным понятием. Например, если речь идет о строительстве здания, то здесь можно подобрать конкретную методику и описать ее в деталях. Другое дело, если речь идет об автоматизации. Проблема заключается в том, что понятие автоматизации имеет разный смысл в зависимости от ситуации, будь то проект с нуля или готовая методика под конкретную ситуацию, плюс ко всему имеет значение и количество заказчиков. В результате, описывая в общих чертах все варианты, людям предъявляются данные, которые могут быть малополезными в практике. В таком случае будет целесообразно рассмотреть конкретный пример.

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

Waterfal или каскадная модель.

Его относят к традиционным методам. Озвучим наиболее важные моменты:

  1. Наличие долгосрочного плана с указанием финиша и цели.
  2. Четкая структура плана работ, которая состоит из сбора требований, проектирования, адаптации базового решения, обучения персонала, введение первичных данных, экспериментальный ввод системы в полную эксплуатацию, полный ввод системы в эксплуатацию и переход на сервисное обслуживание.
  3. Этапы работ имеют декомпозицию до конкретных задач, конкретным исполнителям по всей своей «длине».

Однако, данный метод имеет ряд недостатков. Рассмотрим их более подробно.

Самостоятельное внедрение программы.

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

Привлекаем помощь извне.

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

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

Agile.

Поскольку мы рассматриваем конкретные примеры, то в области Agile мы отдельно и подробно рассмотрим методику  Scrum.

В чем же заключается структура методики Scrum:

  1. Есть заказчик с определенными требованиями или Product Owner.
  2. Его требования собираются в список конкретных задач по автоматизации — бэклог в терминах Scrum.
  3. Автоматизация включает в себя несколько циклов-спринтов. Цикл начинается из отбора задач, заключенных в списке. Причем функцию отбора выполняет заказчик вместе со своей проектной группой. Иными словами, заказчик формирует список наиболее приоритетных модулей, которые войдут в текущий спринт. Сроки спринтов обычно не более 2 недель.
  4. Далее начинается работа над спринтом, в основе которой лежит плотное взаимодействие заказчика с проектной командой. Весь процесс отслеживается онлайн. Ведется контроль за динамикой процесса и причинами его задержки. Также каждый день проводятся собрания, на которых лидер проекта принимает отчеты о проделанной работе от своей команды.
  5. Заканчивается спринт выпуском релиза. Затем на итоговом собрании сотрудники команды обсуждают ретроспективу проекта, анализируют возникшие трудности текущего цикла с целью их избегания в будущем.

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

Однако, реализация Scrum зависит не только от выполнения его технологической концепции. Здесь еще важна и психология коллектива. Во-первых, они должны быть мотивированы на работу над проектом, иметь сильное желание его сделать. Во-вторых, оптимально налаженная коммуникация между заказчиком и проектной команды, они должны слушать и слышать, понимать друг друга и поддерживать.

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

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

  1. У вас есть пара-тройка отделов, руководители которых считают свои задачи наиболее важными. Соответственно, данный спор должен быть как-то разрешен с помощью генерального директора. Ему же, в свою очередь, может быть не до этого.
  2. Допустим, нам удалось решить спор самостоятельно, мы начали работу уже почти ее закончили. Но, на последнем этапе выявил ошибку, из-за которой придется переделывать все предыдущие этапы. Такое обстоятельство сильно негативно отразится на мотивации сотрудников, а вдруг это не последний раз? И что тогда делать?
  3. Допустим, автоматизация длится уже больше года, и тут у генерального директора не выдерживают нервы, и он решает спросить с сотрудников, когда это все закончится. И вот здесь возникает проблема, как правильно рассчитать перспективы и продолжительность всего проекта.

После обдумывания каждой из перечисленных ситуаций возникает вопрос: а не легче ли нанять внешнего подрядчика?

Scrum. Работа с внешним подрядчиком.

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

Здесь есть два варианта:

  1. Обозначить сразу размеры бюджета, запланированного на проект, но с оговоркой на возможность дополнительных расходов по обоснованным документально причинам.
  2. Определить почасовую оплату работ и делать спринты до тех пор, пока у заказчика есть на это деньги.

Первый вариант довольно слабый, так как четко контролировать движение бюджетных средств в проекте не получится. Вы попросту не сможете соотнести количество оставшихся спринтов с оставшимися бюджетным средствами.

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

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