Описание исходной ситуации
Сегодня поговорим о том, как можно минимизировать потерю времени и других ресурсов в небольших проектах внедрения-развития ИТ-систем у производителей продуктов питания.
Для многих предприятий информационные системы стали инструментом постоянного повышения эффективности через реализацию локальных проектов (маркировка готовой продукции, прослеживаемость на производстве, электронный документооборот и т.д.).
При этом для выполнения глобальных проектов (например, смена платформы информационной системы), как правило, привлекается сторонний интегратор, который приносит с собой в проект технологии – как управлять развитием ИТ систем.
Локальные же ИТ-проекты часто делаются «на коленке» и силами штатных ИТ-ков, что приводит к разногласиям между функциональными потребителями и ИТ-специалистами из-за отсутствия отлаженной технологии исполнения проектов и из-за отсутствия единого понимания – ЧТО и КАК должной быть получено в проекте. Вследствие этого частенько происходит разрушение архитектуры ИТ-системы во время выполнения проектов.
Почему это происходит и как скорректироваться?
Проблема:
- Разногласия, а иногда и конфликты, между функциональными потребителями и ИТ-специалистами возникают по причине низкой формализованности требований к изменениям.
Задача частенько описывается потребителями на словах (как «хотелка», а не как исполнимое для ИТ-ков ТЗ). При таком подходе функциональный потребитель сам иногда не понимает – что он хочет (а ИТ-специалист – тем более).
Решение:
Для того чтобы это исключить, необходимо утвердить формат описания требований в письменном виде со стороны функциональных потребителей и только в таком формате принимать задачу. Как только появляется необходимость переложить требования в письменный вид, степень осознанности и ясности требований возрастает на порядок. Как показывает практика, это уже больше половины успеха. Мы такой документ называем – технический проект.
Проблема:
- Последовательное разрушение архитектуры ИТ-системы. Так как локальное изменение воспринимается как незначительное в рамках всей системы, то и способ реализации часто бывает такой – «как увидел решение, так и сделал». А это приводит к появлению «костылей» в архитектуре ИТ-системы.
Один или два таких «костыля» незаметны в работе системы. Однако, когда их накапливаются десятки, то система становится неуправляемой, что начинает проявляться в нестабильности работы системы.
Внесение новых изменений в систему существенно усложняется. Из-за этого в какой-то момент развитие системы становится просто невозможным, и компания вынуждена ставить вопрос о замене системы на новую. А это, в свою очередь, приводит к необходимости выполнения дорогостоящих и болезненных изменений.
Решение:
Чтобы избежать такого сценария необходимо на основании технического проекта, полученного от функциональных потребителей, подготавливать техническое задание с описанием способов реализации требований в конкретной системе.
Такое техническое задание должно быть с одной стороны утверждено функциональным потребителем, а с другой стороны – архитектором системы, ответственным за поддержание целостности и непротиворечивости вносимых изменений (особенно когда изменения вносят разные люди). Только после этого можно начинать реализацию.
На первый взгляд такой путь кажется длинным. Однако на практике описанная последовательность действий позволяет ускорить выполнение локальных проектов. В первую очередь за счет того, что время, потраченное на проработку изменений, существенно сокращает время на реализацию решения и в разы сокращает время на сдачу решения функциональному потребителю и запуск изменения в работу.
Но что ещё более важно – такой подход в коммуникациях позволяет повысить взаимопонимание и удовлетворённость от работы между функциональными потребителями и ИТ-специалистами. А соблюдение архитектурной целостности позволяет продлить срок использования ИТ-решений и, как следствие, повысить финансовую отдачу от инвестиций в ИТ.
Если возникнет желание получить образец технического проекта для внедрения в свою практику локальных ИТ-проектов (ну или еще какие-то вопросы) – обращайтесь, будем рады помочь.