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

Согласно статистике, более 60% ИТ-проектов проваливаются или не достигают цели из-за неграмотного руководства проектом, которое вылилось в неправильную мотивацию команды, неправильную оценку сроков и бюджета проекта и т.д.

Рассказываем о том, как правильно выстроить работу проектной команды, чтобы цель проекта была достигнута, система – внедрена, и заказчик остался доволен.

Проект по внедрению информационной системы: описание, особенности, роли

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

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

Проект – это деятельность, предпринимаемая для получения конкретного результата.

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

Результат проекта:

• Сроки
• Стоимость
• Цели
• Содержание

Проект – это деятельность, которая имеет начало и конец, а также подразумевает какую-то конкретную стоимость.

У проекта есть цель, задачи и бюджет.

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

1. Адаптация системы

• Выявление требований
• Доработка
• Настройка

2. Подготовка к запуску

• Заполнение данными
• Настройка прав
• Инструкции
• Обучение

3. Опытная эксплуатация

• Исправление ошибок
• Доработки
• Консультации

Также может присутствовать этап Предпроектного обследования.

Что такое адаптация системы? Систему необходимо подготовить для того, чтобы ей мог пользоваться заказчик. Системы, которые разрабатывает фирма «1С», являются типовыми, рассчитанными на какую-то среднюю ситуацию. А все бизнесы уникальны. Поэтому необходимо систему как-то адаптировать к тому конкретному бизнесу, в котором заказчик будет ее использовать.

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

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

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

До начала проекта часто проводится предпроектное обследование, которое может называться экспресс-диагностика, экспресс-обследование. Это короткое обследование, которое проводят опытные специалисты, руководители проекта, для того, чтобы понять, что необходимо этому заказчику в целом, в общем, как будет выглядеть проект, какие подразделения он затронет, ориентировочно какие сроки, какая стоимость.

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

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

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

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

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

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

Это две разных позиции консультантов, которые на крупных проектах занимают разные люди.

У программистов тоже может быть специализация, например, программист-архитектор. Это человек, который проектирует сложные программные доработки. Он проектирует какие-то новые модули, если необходимо их разработать, новые объекты.

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

Кроме того, в проектной команде еще существует такая роль, как технический руководитель проекта.

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

Со стороны заказчика проектом занимается группа сотрудников заказчика, которую принято называть рабочей группой.

У исполнителя, у внедренцев – проектная команда, а у заказчика –рабочая группа.

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

Ниже куратора проекта находится руководитель проекта со стороны заказчика. Руководитель проекта со стороны заказчика – это человек, который организует сотрудников заказчика для того, чтобы они сделали какие-то вещи, необходимые в ходе выполнения проекта, например, рассказали команде внедрения, какие у них требования к системе, согласовали какие-то проектные документы, провели тестирование доработанного программного продукта. Сотрудников заказчика необходимо организовывать, мотивировать, заставлять все это делать. Этим занимается руководитель проекта со стороны заказчика.

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

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

Плюсы участия в проекте:

• постоянное место работы
• на проектах решаются интересные задачи
• проекты позволяют приобрести хороший опыт решения бизнес-вопросов при помощи продуктов фирмы 1С
• плюс для резюме
• хорошее повышение квалификации, которое, конечно, играет важную роль в карьерном продвижении специалиста.

Минусы участия в проекте:

• высокие риски по оплате. Если клиент не заплатил деньги фирме, то и разработчикам, и программистам тоже могут и не оплатить
• концентрация на одном заказчике. Если вы проводите на проекте год, то этот год вы занимаетесь одним заказчиком, и ваш опыт ограничен только его спецификой. За это время можно было бы сделать, например, несколько небольших внедрений в самых разных областях и приобрести, может быть, какой-то другой опыт в плане автоматизации других областей
• на проектах, как правило, не работает ваш прежний опыт. Каждый клиент уникален и каждый проект уникален
• ситуация постоянного стресса. Ситуация, когда вы должны уложиться в бюджет, в сроки, выполнить большое количество разнородных, сложных работ, оплата которых и приемка которых, и оценка результата которых зависит от сторонних людей, от заказчика.

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

Что такое технология управления проектом

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

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

Управлять проектами можно по-разному, всё зависит от специфики и выбранной технологии — правил и принципов, по которым строится работа команды.

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

Для управления проектами существуют стандарты.

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

Стандартами в области управления проектами занимается Институт управления проектами (Project Management Institute, или PMI). Это международная профессиональная некоммерческая организация сообщества специалистов по управлению проектами.

Институту принадлежит авторство свода знаний о том, как управлять проектом, PMBоK (Project Management Body оf Knowledge).

В PMBоK систематизированы стандарты и инструменты для работы в проектном менеджменте. На PMBоK основан экзамен для сертификации проектных менеджеров PMP (Project Management Professional) от PMI, этот сертификат ценится у работодателей по всему миру.

В основе методологии PMBоK — процессная модель управления проектом.

Любой проект состоит из множества процессов, у каждого из них есть:

• входы — то, что нужно для выполнения процесса,
• выходы — то, что получится в результате процесса,
• инструменты — конкретные способы получения выходов из входов.

Первое издание PMBoK было в 1996 году. С того времени его регулярно обновляют и дополняют.

В 2021 году вышла седьмая редакция PMBоK. Она является актуальной на данный момент.

Это документ, в котором описаны все основные термины, понятия, и стандарты для управления проектами в целом. То есть речь не идет о проектах внедрения информационных систем, в PMBоK рассматриваются общие положения о проектах вообще.

В седьмом издании PMBоK описаны:

• 12 принципов управления проектами;
• 8 областей реализации проектов;
• рекомендации к построению системы ценностей проекта и компании;
• раздел по адаптации описанных в книге методов управления к конкретным проектам;
• модели, методы и артефакты — раздел с инструментами для осуществления рекомендаций на практике.

PMBоK является главным источником нормативной информации по проектам, источником стандартов ISO, ГОСТов.

PMBоK выделяет так называемые области знаний. Это перечисление того, чем руководитель проекта должен управлять в ходе проекта:

• Управление содержанием проекта определяет, чего нужно достичь в рамках реализации проекта.
• Управление временем проекта. Руководитель проекта должен следить за тем, чтобы все выполнялось по графику.
• Управление деньгами проекта. Бюджет проекта, транзакции и пр.
• Управление качеством проекта. На протяжении всего проекта руководитель проекта должен следить за тем, чтобы всё, что было описано в рамках содержания проекта, выполнялось на нужном уровне качества.
• Управление заинтересованными сторонами проекта включает в себя организацию эффективного взаимодействия и оперативное решение возникающих недоразумений между командой проекта и заинтересованными лицами.
• Управление коммуникациями проекта включает в себя как коммуникацию внутри команды проекта, так и внешние коммуникации с экспертами, подрядчиками и т.д.
• Управление ресурсами проекта: серверами, программным обеспечением, недвижимостью и т.д.
• Управление поставками проекта: от планирования закупок, до заключения контрактов с поставщиками.
• Управление рисками проекта.
• Управление интеграцией проекта. Эта область знаний подразумевает объединение всех ресурсов и процессов проекта для его успешной реализации. Речь идет о том, что, если наш проект включает какие-то параллельные работы или включает разные участки, которые слабо связаны друг с другом, мы должны осуществлять координацию этих участков, должны планировать и отслеживать, чтобы в соответствии с нашими планами шло взаимодействие и синхронизация между вот этими работами.

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

Кроме областей знаний, в PMBоK выделяют еще группы процессов. Группы процессов соответствуют стадиям или фазам выполнения проекта.

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

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

Жизненный цикл проекта по PMBоK состоит из следующих фаз:

• Инициация (запуск проекта);
• Планирование (группа процессов по выработке планов);
• Исполнение (процессы, которые реализуются для достижения результата всего проекта);
• мониторинг и контроль (группа процессов, которые помогают отследить прогресс работы над проектом и определить необходимость корректировок);
• завершение (формальные процессы, которые завершают работу над проектом, например, подготовка отчета).

Чтобы проект успешно прошел весь жизненный цикл, нужны процессами управления проектами. Всего в PMBoK их 44. По каждой из групп процессов и для каждой из фаз в PMBоK определены процессы управления проектами и роли участников проекта.

В России для управления проектами существует набор ГОСТов. Существует два набора ГОСТов:

Это ГОСТы для управления проектами. Опять же, речь идет об управлении какими угодно проектами, не обязательно проектами внедрения информационных систем.

И кроме этого, существует набор ГОСТов, разработанных именно для информационных систем и информационных технологий.

ГОСТы важны для заказчиков из оборонной сферы, из области государственного управления. Для некоторых заказчиков проектная документация, информационные системы должны быть обязательно разработаны в соответствии с ГОСТами.

Стандарты и ГОСТы — это очень общее теоретическое описание подходов к управлению проектами.

Для конкретного использования в проектах существует то, что называется технологиями внедрения.

Технологии — это конкретные способы описания работы, как и что мы делаем для того, чтобы выполнить проект.

Технологии внедрения:

• Практика сообщества «1С»
• Стандартные технологии «1С»
• Современные технологии:

– Agile технологии внедрения

– SCRUM технологии внедрения

Существуют стандартные технологии фирмы «1С», разработанные для того, чтобы партнеры фирмы «1С» выполняли проекты на одинаково высоком уровне. И кроме того, существуют современные технологии, которые называются Agile и Scrum, так называемые «гибкие технологии». Они частично перекликаются с общей практикой. Частично они отражены в стандартных технологиях фирмы «1С».

Практика сообщества 1С

Обычная практика выполнения проекта по внедрению ПП 1С выглядит следующим образом:

Внедренцы готовят для клиента коммерческое предложение, в котором описаны участки учета, то есть что мы автоматизируем, каких пользователей будем привлекать для работы в системе, в каких подразделениях система будет использоваться, какие будут сделаны ключевые доработки, общие сроки и стоимость. С точки зрения терминологии PMBоK коммерческое предложение является документом, который фиксирует параметры проекта.

Если клиента все устраивает, дальше идет этап написания технического задания (ТЗ), для этой цели проводят интервью, выполняют анализ старых информационных систем, и в результате общения с пользователями готовят описание необходимых доработок, если они нужны, и разрабатывают техническое задание.

Следующий этап — выполнение доработок, описанных в техническом задании. Результатом такой доработки является сдача-приемка всех этих доработок и акт. Или, с другой стороны, эти работы могут быть оформлены не каким-то фиксированным отдельным документом, а листами учета рабочего времени. Доработки выполняются по ТЗ, но нельзя заранее сказать, сколько времени это займет. Поэтому клиент ежедневно подписывает листы учета рабочего времени и потом уже производит расчет по факту того, сколько именно времени и денег заняла реализация тех требований, которые описаны в техническом задании.

И последний этап этой общепринятой технологии внедрения —собственно внедрение информационной системы. Выполняется загрузка начальных данных, консультация пользователей и после того, как пользователи начинают работать в системе, производятся какие-то дополнительные доработки по их требованиям.

Эта технология работы встречается очень часто для небольших проектов и для несложных систем, например, 1С:ЗУП, 1С:УНФ.

1С:Технология стандартного внедрения

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

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

1С:Технология стандартного внедрения (1C:ТСВ) является одним из наиболее популярных подходов к внедрению ПП 1С.

Эта технология предназначена для типового внедрения, которое выполняется практически без доработок. И речь здесь идет о каких-то программных продуктах, которые несложно внедрить.

ТСВ — самый быстрый и экономичный способ автоматизации, рекомендуемый для малого бизнеса и небольших стартапов.

Сферы применения 1C:ТСВ:

• Малый и средний бизнес;
• Предприятия, в которых бизнес-процессы полностью соответствуют стандартным сценариям работы в «1С»;
• Компании, с небольшим бюджетом.

1С:Технология стандартного внедрения подразумевает использование типовых решений. В ходе внедрения потребуется произвести определенные изменения текущих процессов, так как все будет подчинено логике типового решения. В проекте используется типовая документация.

Этапы:

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

1С:Технология быстрого результата

Для более крупных проектов фирма «1С» разработала Технологию быстрого результата (1C:ТБР).

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

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

1C:ТБР предназначена к использованию в средних и крупных бизнесах. Видимые результаты от применения данной технологии в проекте внедрения появляются достаточно быстро. Технология сама по себе является гибкой, поэтому ее можно подстраивать под любые проекты. Если какая-то задача выходит за рамки стандартной, то для нее создается отдельное задание, учитывающее все ее особенности.

1С:Технология корпоративного внедрения

Для проектов по автоматизации крупных компаний и сложных процессов фирма «1С» разработала Технологию корпоративного внедрения (1C:ТКВ).

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

1C:ТКВ основывается на стандартах PMI, ГОСТ и др.

С помощью данной технологии появляется возможность создавать любые системы, даже самые сложные. Проект в момент реализации фактически не подлежит изменениям. ТКВ — это более глубокое управление проектами. Нужно создать общую концепцию информационной системы. Мы заранее понимаем, что по проекту будет много доработок, поэтому либо у себя на площадке, либо на площадке клиента разворачиваем сервер, на котором будет выполняться программная доработка. Организуем подключение туда всех участников проекта, консультантов, программистов.

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

В рамках разработки архитектуры системы проектируем систему, описываем, как она будет выглядеть.

Затем разрабатываем прототипы системы, такие, может быть, неработающие интерфейсы или какие-то объекты, которые имитируют реальную работу в информационной системе. Прототипы нужны только для того, чтобы пользователи, глядя на них, могли уточнить свои требования и конкретно показать, куда и какую кнопку им нужно добавить. Вот это называется прототипирование. И по результатам анализа готовятся требования на разработку рабочего макета. Кроме этих требований готовятся еще и контрольные примеры, т.е. мы описываем, какие данные наш рабочий код должен преобразовать в другие данные. На этом этапе мы готовим те данные, которые будем вводить в систему, чтобы проверить, что система действительно работает. И отдельно для этого этапа мы готовим план управления и бюджет проекта. Это документы, которые требует PMBоK.

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

Следующий этап — это опытная эксплуатация. В ходе опытной эксплуатации заказчик работает в этой информационной системе, проводит приемо-сдаточные испытания, прогоняет через систему контрольный пример, проводит тесты и принимает разработанный этап в работу.

Последний этап — это ввод этого участка в промышленную эксплуатацию, передача заказчику документации, передача необходимой информации службе поддержки и переход к следующему этапу.

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

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

Гибкая методология внедрения: Agile

Наряду с описанными выше существуют еще так называемые «гибкие технологии» от английского слова «agile», т.е «гибкий».

Agile — подход к управлению проектами, в основе которого лежит поэтапная разработка продукта, проходящая в несколько циклов (итераций или спринтов).

Каждая из итераций имеет одну и ту же структуру:

1. Планирование
2. Проектирование
3. Разработка
4. Тестирование.
5. Запуск (развертывание, деплой).

После окончания первого цикла компания запускает следующий, но работает над другой функцией.

Agile опирается на так называемый манифест Agile. Это такой набор лозунгов, который был принят много лет назад специалистами по управлению проектами.

Манифест Agile:

• Личности и взаимодействия важнее процессов и инструментов
• Работающая программа важнее полной документации
• Сотрудничество с клиентом важнее договоров и переговоров
• Готовность к изменениям важнее следования плану

Авторы манифеста Agile утверждают, что и проектная команда, и заказчики заинтересованы в том, чтобы проект был сделан. Поэтому давайте не будем тратить время на то, чтобы в документах согласовывать каждый нюанс, каждую деталь.

Манифест Agile признает, что уже в ходе разработки программного продукта возникают изменения, т.е. практически не бывает никогда такой ситуации, что мы заранее запланировали что-то разработать и вот в точном соответствии с этим планом именно вот это и разработали. Практически всегда в план вносятся изменения. Нужно быть готовым к этим изменениям, и вся практика управления проектами должна быть построена таким образом, чтобы необходимость внести изменения в исходный план работы не выглядела катастрофой, а являлась бы нормальной рабочей ситуацией. Да, мы собирались сделать одно, а теперь мы приняли другое решение и будем делать немного другое, и это нормально. А завтра мы примем третье решение и опять подстроимся. И вот давайте организовывать работу так, чтобы это было продуктивно и не приводило к стрессам, к краху проектов. Просто все равно мы в итоге сделали программный продукт, который нужен данному клиенту.

На основе манифеста Agile появилось целое семейство различных организационных технологий, которые в целом выглядят следующим образом: Существует владелец программного продукта, у которого есть некое видение, как и что должно работать. Кроме того, на стороне заказчика, на стороне клиента, есть заинтересованные лица проекта, которые могут дать так называемые user stories, пользовательские истории, т.е. рассказать о том, как должна вести себя программа для того, чтобы они получили то, что им нужно. И набор таких пользовательских историй является нашими требованиями, то есть тем, что мы берем в работу. Все эти пользовательские истории формируют большой список, который называется «Задачи к выполнению», или в английской методологии это Product Backlog. И этим списком ведают владелец продукта и команда разработки. Они этот список анализируют, проводят оценку пользовательских историй, оценивают их размер, важность и ценность для данного проекта, расставляют приоритеты и затем, в соответствии с расставленными приоритетами, эти пользовательские истории отправляются на реализацию.

 

Соответственно команда разработки обязуется, например, реализовывать в неделю 5 или 6 пользовательских историй. И в конце такого цикла разработки выпускается новая версия продукта. После того, как выпущена новая версия продукта, возможно, будут сгенерированы какие-то новые идеи для продукта. Владелец продукта их рассмотрит, впустит в проект. И вот таким циклическим способом постепенно, итерационно разрабатывается программный продукт.

Гибкая методология внедрения: SCRUM

Еще одним, несколько более детализированным способом организации разработки программных продуктов на гибких методах является технология, которая называется SCRUM.

SCRUM — это техника, которая включает в себя набор инструментов для работы по Agile.

SCRUM

• Основан на принципах Agile
• Для команд от 3 до 9 человек
• Разработка итерациями 2-4 недели
• Ежедневное перепланирование

Управление проектом по технологии SCRUM выглядит следующим образом: точно так же, как в Agile, заказчики направляют в проектную команду какие-то свои требования о том, что они хотят получить от программного продукта. И эти требования тоже попадают, как и в Agile, в Product Backlog. То есть, это пул задач к реализации, в которых мы должны расставить приоритеты, оценить их, выполнить оценку и запустить в работу. Дальше начинается цикл разработки, который в SCRUM называется спринт.

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

В ходе выполнения этих задач, то есть каждый день, в течение этих двух недель, проектная команда собирается и под руководством специального человека, модератора, который называется SCRUM-мастер, они проводят перепланирование задач и быстрое регламентированное обсуждение проблемы разработки. Каждый участник проектной команды должен ответить на вопросы: Что было сделано вчера? Что будет сделано завтра? Что мне мешает в работе? И, отвечая на эти вопросы, команда разработки совещается, корректирует какие-то свои действия и предпринимает какие-то действия к тому, чтобы выполнить план разработки на текущий спринт.

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

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

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

Необходимо понимать, что у гибких технологий есть не только плюсы, но и минусы.

Плюсы Agile и SCRUM:

• Гибкость и простота
• Удобно для больших проектных команд
• Высокая скорость разработки
• Мало оформления

Минусы Agile и SCRUM:

• Слабая формализация
• Нужен очень компетентный заказчик
• Размыта ответственность
• Нужно обучать и команду, и заказчика

Если у вас большая проектная команда, то гибкие технологии действительно удобны. Потому что, если вы руководите проектом по PMBOK или по ГОСТу, то у вас возникает очень много формальных коммуникаций, каких-то совещаний и других мероприятий, на которые ваши сотрудники смотрят как на потерю времени.

С применением гибких технологий сокращается время на формализацию, на какое-то согласование решений, и, естественно, повышается общая скорость разработки, общие темпы выполнения проекта.

Но, с другой стороны, из гибкости этих технологий происходят их минусы.

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

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

На самом деле не существует правильной или неправильной технологии внедрения, потому что в каждой компании есть свой опыт и своя, отработанная годами технология. Более подробно изучить проектные технологии внедрения можно на Курсе аналитика 1С.