Просмотр исходного текста страницы Команда ИТ-проекта: как избежать проблем

[[Категория:Алексей Кайдалов (Статьи)]]
[[Категория:Банковская автоматизация]]
[[Категория:CNews (Публикации)]]
[[Категория:2006 год (Статьи)]]
* [[:Категория:Алексей Кайдалов (Статьи)|Алексей Кайдалов]], ведущий эксперт ООО «Заказные ИнформСистемы»
* «Команда ИТ-проекта: как избежать проблем»<ref>[http://www.cnews.ru/reviews/index.shtml?2005/06/20/180560 Публикация] на сайте '''Cnews''', раздел «Аналитика», 20 июня 2005.</ref>

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

== Фактор риска ==

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

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

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

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

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

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

== Команда заказчика ==

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

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

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

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

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

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

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

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

С экспертами должно быть налажено продуктивное взаимодействие сотрудников исполнителя, для чего тоже требуются определенные организационные решения. Эксперты так же, как и координатор, назначаются ''официальным приказом''. В их рабочие обязанности включается регулярное участие в проекте, например, в течение первых 3-4 месяцев с момента начала работ эксперты проводят лекции и консультации по своей области не менее 6-8 часов в неделю, в последующие 6 месяцев их загрузка уменьшается до 1-3 часов в неделю. Мнение экспертов, заверенное руководителем проекта со стороны заказчика, должно считаться официальной позицией последнего, либо всю ответственность за формирование такой позиции может взять на себя координатор от заказчика.

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

'''4. Технический ИТ-персонал.''' К этой категории относятся сотрудники ИТ-подразделений заказчика, выполняющие технические и вспомогательные работы в команде проекта или во взаимодействии с ней: программисты, тестировщики, преподаватели, операторы, системные администраторы.

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

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

Группа обучения конечных пользователей ('''преподаватели''') функционирует временно, чаще всего в начале этапа опытной эксплуатации. Ее наличие обычно связано с двухступенчатой организацией обучения: вначале сотрудники Исполнителя обучают ИТ-сотрудников заказчика, затем последние обучают сотрудников бизнес-подразделений. Этот каскадный метод позволяет быстро обучить большое количество пользователей. В ряде случаев группа обучения существует у заказчика на постоянной основе. Это необходимо, когда автоматизация достигает уровня пользователей с высокой текучестью кадров — например кладовщики, кассиры и т. п.

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

'''Системные администраторы''' осуществляют техническую поддержку проекта, ведают вопросами безопасности и разделения доступа к данным.

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

<graph>
digraph G{
  node[style=filled shape=house fillcolor=darkseagreen2 fontsize=14 peripheries=2]
  root[label="Команда заказчика" shape=septagon peripheries=3 fillcolor=gold  fontsize=18]
  root->"Куратор"
  root->"Координатор"
  root->"Эксперты"
  root->"Техперсонал"
  node[shape=house fontsize=8]
  "Техперсонал"->"Программисты"
  "Техперсонал"->"Тестировщики"
  "Техперсонал"->"Операторы"
  "Техперсонал"->"Сисадмины"
}
</graph>


== Команда исполнителя ==

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

'''1. Координатор (руководитель проекта) от исполнителя.''' Как ни велико значение куратора и координатора от заказчика, в большинстве случаев ход проекта определяется руководителем проекта от команды исполнителя. Именно он в итоге составляет план работ по разработке, доработке и внедрению, включая индивидуальную загрузку конкретных сотрудников (в их число входят и специалисты заказчика, например эксперты), и контролирует выполнение этого плана.

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

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

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

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

'''2. Консультанты, аналитики.''' В общем случае, это специалисты по предметной области и по внедряемой программной системе. Выполняют две основные задачи: отвечают за сбор и предоставление участникам проекта различной информации (в части автоматизируемых бизнес-процессов и технических деталей реализации). Кроме того, в проектах внедрения настраиваемых систем — определяют необходимые настройки, и в большинстве случаев физически их выполняют. В известной степени, их можно рассматривать как экспертов со стороны исполнителя. Отличие консультантов от экспертов заказчика обычно состоит в лучшем знании стандартных, универсальных ИТ-решений для различных областей бизнеса и умении связно подавать информацию в виде технического задания, рабочей документации и других письменных документов.

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

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

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

В подавляющем большинстве случаев замена разработчиков исполнителем по ходу проекта не несет существенных рисков и широко используется на практике. На рынке труда имеется достаточное предложение разработчиков практически в любых программных средствах.

'''4. Технический ИТ-персонал.''' Аналогичный таковому со стороны заказчика, в проекте используется технический персонал исполнителя. Сюда относятся тестировщики, сотрудники службы техподдержки, системные администраторы.

'''Тестировщики''' исполнителя выполняют важную функцию по проверке работоспособности системы (или ее модулей) до ее передачи заказчику.

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

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

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

<graph>
digraph G{
  node[style=filled shape=house fillcolor=aliceblue fontsize=11 peripheries=2]
  root[label="Команда исполнителя" shape=pentagon peripheries=3 fillcolor=deepskyblue  fontsize=14]
  root->"Координатор"
  root->"Аналитики"
  root->"Разработчики"
  root->"Техперсонал"
  node[shape=house fontsize=7]
  "Техперсонал"->"Тестировщики"
  "Техперсонал"->"Техподдержка"
  "Техперсонал"->"Сисадмины"
}
</graph>




== Взаимодействие команд ==

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

Структура «идеальной» команды проекта представлена на рисунке.

[[Image:Структура «идеальной» команды проекта (2005).jpg|frame|center|Структура «идеальной» команды проекта.]]

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

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

'''Важные организационные вопросы.''' Наиболее существенные вопросы проекта требуют непосредственного участия куратора, что отображено отдельной связью на схеме. Это — вопросы осуществления оплаты, развертывания дополнительных работ, изменений в текущем проекте (договоре) в плане стоимости, объемов и сроков, и аналогичные организационные вопросы самого высокого уровня. В таком взаимодействии почти всегда также принимает участие координатор от заказчика, а иногда — и некоторые представители компании исполнителя, не показанные на схеме, в лице сотрудников служб маркетинга и даже руководства компании — когда решаются наиболее ответственные вопросы.

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

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

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

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

----

[[Image:Владислав Новожилов (2005).jpg|right|Владислав Новожилов]]


'''''Владислав Новожилов: От менеджмента успех зависит не меньше, чем от качества ИТ'''''

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

Хотя жизнь всегда богаче отвлеченной схемы, наш опыт работы подтверждает правильность основных положений статьи. В свое время совместными усилиями руководства ЕРКЦ и компании «[http://www.custis.ru/ Заказные ИнформСистемы]» нам удалось выстроить эффективную схему управления проектом автоматизации «Единого расчетно-кассового центра г. Саратова». Этот опыт представляется особенно ценным, поскольку при создании предприятия имели место несколько ключевых проблем.

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

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

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



== Ссылки ==
<references />

{{replicate-from-custiswiki-to-lib}}