Самый важный вопрос, который возникает накануне внедрения любой программной системы, это «с чего начать»?
Существуют разные варианты подходов к внедрению информационных систем со своими преимуществами и недостатками:
Классический или каскадный подход:
Одна из самых старых методик, подразумевает последовательное прохождение стадий, каждая из которых должна завершиться полностью до начала следующей. В данной модели легко управлять проектом. Благодаря её жесткости, разработка проходит быстро, стоимость и срок заранее определены.
- Каскадное управление проектом начинается с этапа определения требованийили составления списка предполагаемых функций и характеристик системы.
- Создается объемное техническое задание, в котором по максимуму продуманы и описаны все процессы, включая самые мелкие.
- Под техническое задание создается календарный план работ.
- Разработчики создают архитектуру программного обеспечения на этапе проектирования.
- Далее идет этап реализации, в ходе которого осуществляется разработка и интеграция ПО.
- На этапе тестирования и отладкикоманда находит и исправляет ошибки.
- Далее идет этап установки, в ходе которого выполняется развертывание программного продукта.
- Последняя фаза — сопровождение, предусматривающая поддержку нормального функционирования программного продукта.
Ключевым моментом в таком подходе играет Техническое задание, а именно:
На составление подобного технического задания могут уйти месяцы и даже годы. В этот период мир не стоит на месте меняется как само автоматизируемое предприятие, так и окружающая среда, что приводит к потере актуальности ТЗ к моменту его завершения. От такого подхода плюсы получают, прежде всего, разработчики:
- Документ Техническое задание будет стоить дорого. Выполняется большой объем работы, занимающий значительное время. И заказчики обычно соглашаются с высокой ценой техзадания без каких-либо вопросов полагая что это позволит им зафиксировать конечный результат и получить такую систему которую им бы хотелось.
- Разработчики получают подробную инструкцию, на основе которой можно проводить работы. А в случае неудачных решений, имеющихся в подписанном ТЗ, оплачиваться отдельно.
Минус подхода заключается в его объеме и сложности. Создать всеобъемлющее техническое задание, в котором будут предусмотрены все модули, документы, все нюансы будущей работы невозможно. Система многофункциональна, и любые изменения в одном модуле могут повлечь за собой необходимость внести изменения в другой.
Аналогично и с ошибками при составлении технического задания: любые неправильные решения в одном модуле могут повлечь за собой множество изменений в других. Например, какой-то бизнес-процесс мог быть понят не верно, и тогда при внедрении выяснится, что часть документации и справочников – не нужны, а требуются совсем другие. Слишком большой объем информации, слишком высокая сложность системы – в результате, оказывается невозможно заложить изначально все нюансы и предусмотреть все возможные ошибки.
Когда этот подход наиболее эффективен:
— При разработке простых систем (2-3 месяца на весь цикл) в случае когда можно провести полное обследование и разработать ТЗ за пару недель и приступить к разработке без промедления.
— Другим случаем являются гос. учреждения которые любят получать большое количество документации подтверждающей проделанную работу, осваивать бюджеты, но не стремятся получить конкретную пользу от внедрения. Данный подход позволяет годами разрабатывать тех задания, к моменту окончания и началу разработки ПО описанные в нем процессы и функции устаревают, принимается решения о повторной разработке ТЗ и цик повторяется сколько угодно раз, либо делается не нужно примитивное мало функциональное ПО, но с грудами макулатуры которую всегда можно приложить в качестве подтверждения проделанной работы. Кому-то может не понравиться цинизм данного подхода, но таковы реалии нашей страны. Так же как осваиваются бюджеты на ремонт и строительство дорог с огромными откатами и ежегодной переделкой, так же хорошо подходит для освоения бюджета и каскадный подход в области информационных технологий.
— При желании обмануть заказчика он имеет все необходимые качества: большинство клиентов думают что ТЗ позволит им зафиксировать все свои «хотелки» и воспринимают их ка договор гарантирующий получение нужного функционала, высокая доля стоимости получаемая до получения какого-либо профита (ТЗ составляет от 30 до 70% стоимости проекта), возможность создать такое ТЗ при котором вся вина на не рабочий функционал ложится на заказчика и при этом дает возможность осуществлять минимум работ.
Поэтапное (или модульное) внедрение
По сути это эволюционное развитие каскадного подхода, когда на больших проектах столкнулись с устареванием ТЗ, а так же ввиду сложности найти универсальных специалистов разбирающихся во всех областях, проекты стали делить на части (направления, функциональные блоки, модули – кому как нравится) и каждый блок внедрять раздельно – либо в одно время, но разными командами, либо одной командой, но последовательно, либо разными командами последовательно (в частности последний вариант является самым распространенным при постепенной автоматизации растущей организации сторонними силами).
В этом случае составляют список наиболее значимых для бизнеса направлений и модулей для работы с ними. На их основе составляют некий план внедрения, который и является основой для начала работ.
На первом этапе необходимо сконцентрироваться на одном из процессов, который затрагивает основную и лучше коммерческую составляющую компании. Начинаем автоматизацию именно с данного процесса. Конечно, внедрение «по процессно» не позволит сразу осуществить максимальный охват пользователей, но даст пользователям представление о работоспособности системы и ее преимуществах.
В этом случае техническое задание также имеется. Как и календарный план при варианте работы, где за основу берут объемное ТЗ. Но здесь техническое задание не является таким всеобъемлющим, возможно составление для разных этапов работы собственных технически
Нужно отдать должное – данный метод гораздо результативнее классического каскадного подхода и чаще использовался практикующими внедренцами. Результат, хоть и частичный, достигается раньше и позволяет судить о квалификации проектной команды.
К недостаткам следует отнести дублирующиеся работы, чем большее число модулей внедряется, тем чаще приходится возвращаться и изменять уже проделанную работу. При параллельном внедрении несколькими командами возникает сложность взаимодействия между командами и те же трудности что и при каскадном подходе, поэтому он не получил большого распространения.
Когда этот подход наиболее эффективен:
— При автоматизации многопрофильного холдинга, с очень разнообразными направлениями деятельности, когда заранее принято решение о разделении баз и конфигураций для разных подразделений компании. В этом случае каждое подразделение можно автоматизировать отдельно, поэтапно включая эти блоки в общую ИТ-архитектуру холдинга.
— Модульный подход хорошо показал себя и на гос проектах, т.к. он предусматривает большой объем документации, хоть и чаще достигает результата (по сравнению с классическим каскадом), в то же время позволяет затянуть проект на досточно долгий срок чтобы освоить нужную величину бюджета.
SCRUM (классический)
Последнее время получил значительное распространение и много поклонников, впрочем, весьма оправданно. Суть подхода отражена в основных принципах scrum:
- Люди и их взаимодействие важнее процессов инструментов;
- Работающая система важнее исчерпывающей документации;
- Сотрудничество с заказчиком важнее жестких контрактных ограничений;
- Реакция на изменения важнее следования первоначальному плану.
Зачастую люди по-разному трактуют эти принципы.
Основным, на мой взгляд важнейшим преимуществом этого метода является получение рабочего продукта на самом раннем этапе проекта (особенно удобно при доработке коробочных версий). После запуска системы с минимальным функционалом осуществляется его циклическая доработка до тех пор, пока сам заказчик не решит, что дальнейшее развитие не целесообразно.
Таким образом клиент получает пользу и видит весь путь развития системы, вовлечен в процесс разработки и принимает решения о направлении этого развития, а также регулярно получает обратную связь от команды разработки.
Меньшая стоимость по причине отсутствия затрат на избыточную документацию и возможность контролировать степень доработок.
Недостатками являются отсутствие понимания стоимости проекта до начала работ и гарантий получения конечного результата. Такие серьезные ограничения требуют очень доверительных отношений к подрядчику, на что серьезные компании идти не готовы.
Надо иметь ввиду, что даже при согласии не каждая компания готова работать по SCRUM методике, т.к. это требует значительных затрат ресурсов со стороны сотрудников заказчика, а также определенный менталитет.
Когда этот подход наиболее эффективен:
— Увы, но в классическом понимании SCRUM не работоспособный подход, т.к. имеет слишком много жестких требований которые в реальном мире не выполнимы, а следовательно любое отклонение понимается как не попадание под понятие SCRUM..К примеру все спринты должны иметь строго одинаковую длину и скажем если демонстрация результатов спринта назначена на 10 утра каждую среду, то даже если среда выпадает на первое января встреча должна быть проведена ровно в 10 утра первого января в полном составе – перенесем на второе января или на 11 часов и это уже не scrum в его классическом понимании. Существует множество других не реализуемых на деле правил.
Совмещенный (комбинированный) подход
Если клиенту нужна рабочая система и в то же время он хочет получить ориентировочную стоимость проекта и план работ на начальном этапе приходится совмещать несколько подходов. Как правило выглядит это так:
На этапе обследования и планирования применяются элементы каскадного подхода.
- Готовятся упрощенные технические требования к системе.
- Формируется план-график внедрения
Далее сразу переходим к разработке с использованием Agile методов, преимущественно csrum с элементами канбан. Согласно разработанного план-графика составляется план сдачи блоков каждый из которых разбит на спринты, но их длина может отличаться в зависимости от задач входящих в каждый из блоков, что позволяет подстраиваться под реальный календарь и возможности представителей заказчика. Задачи распределяются с использованием Канбан подхода (для оптимизации ресурсов).
Преимуществами такого подхода являются получение представления о стоимости, длительности и трудоемкости проекта на раннем этапе (как в каскадном методе) и в то же время возможность влиять на его протекание, получение регулярной, частой обратной связи, готовность подрядчика оперативно реагировать на изменения и дорабатывать свой продукт в соответствии с изменениями рынка и пожеланиям заказчика (как при гибкой разработке), с оптимальным распределением ресурсов и минимизации стоимости (как в Канбан).
Недостатками является сложность использования данного подхода, т.к. большинство компаний интеграторов не имеет ресурсов для его применения, необходима слаженная сильная команда возглавляемая руководителем проекта со значительным опытом в подобных проектах.
Другим недостатком является необходимость значительного вовлечения представителей заказчика. В зависимости от сложности и масштабности проекта может потребоваться уделять проекту больше времени чем многие думают (к примеру на проекте с 15 разрабочтиками от заказчика потребуется 1-3 человека задействованных до 80% рабочего времени и 5-8 человек по 20-50% рабочего времени), но такая вовлеченность необходима для получения хорошего результата.
Когда этот подход наиболее эффективен:
— Если клиент сильно заинтересован в получении рабочего продукта в оговоренные сроки и готов уделить проекту свое внимание и мотивировать своих сотрудников на работу в команде в достаточном объеме.
— Если разработчику для статуса необходим данный проект (предоставление референса другим заказчикам или повышения квалификации своего персонала) и они готовы взять на себя риски связанные с недостаточной вовлеченностью представителей заказчика и компенсировать их своими ресурсами.