Ап, и «топы» у ног моих сели

Николай Волков, член Клуба 4CIO и бывший ИТ-руководитель «Иркута», сравнил айтишника, стоящего у руля в крупном проекте, с дрессировщиком в клетке с тиграми. Пока ты веришь в себя, топ-менеджеры и команда тебя слушают, но если дал слабину — разорвут. Может и не в буквальном смысле, но авторитет — наверняка.

Можно ли поделить ИТ-проекты на те, которые «внедрил и забыл»,и те, что не кончаются никогда?

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

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

Можете привести пример сложного проекта на «Иркуте»?

Если говорить об «Иркуте», то таким по-настоящему сложным был проект по внедрению PLM — системы управления данными об изделии в конструкторском бюро и на производстве. Вот такие проекты не прекращаются. Хотя бы потому, что первую версию мы делали, основываясь на данных, которыми владели на начало проекта. Пока реализовывали его, поняли, что потребуется доработка.

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

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

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

Какие изменения, помимо количественных, происходят с проектной группой при переходе от этапа внедрения к этапу поддержки?

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

Нужно ли выбивать под проект и его поддержку дополнительные кадры?

Чтобы под проект были выделены дополнительные кадровые ресурсы, он должен быть крупным с точки зрения основного бизнеса предприятия. Например, создание нового изделия (авиационной техники) — это крупный проект Под такой создается отдельная команда. Для ИТ-проектов — нет. В «Иркуте» хорошо развита система проектного управления, для непроиводственных проектов в основном применяется матричный способ. То есть проектная команда собирается как виртуальная оргструктура. В нее назначаются люди из разных подразделений, которым за участие в проекте, а это, по сути, переработка, выплачивается премия из мотивационного фонда. Такой подход позволяет избежать дополнительных финансовых издержек, за исключением создания упомянутого мотивационного фонда, а также расходов на премии членам комиссии по изменениям.

После внедрения нередко проявляются проблемы. Как понять, кто в них виноват: поддержка или внедренцы?

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

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

И надо помнить, что чем больше времени проходит после ввода решения в эксплуатацию, тем меньше внимания уделяется проекту и тем меньше шансов реализовать все «хотелки», которые не удалось «впихнуть» в первую версию.

Что скажете, насчет претензий команды сопровождения ИТ-решения?

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

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

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

Так что же, не принимать ни один проект без документов?

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

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

Столкнулись ли вы с этим при внедрении PLM-системы?

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

Какова разница между собственной разработкой и готовым решением при поддержке системы?

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

Как формировать в проекте команду единомышленников и может ли ИТ-руководитель вести всех за собой?

Это как в клетке с тиграми — пока ты веришь в себя и знаешь, что ты прав, тебя слушают. Ты можешь организовать весь процесс. Как только где-то что-то проморгал — пропал. Можно также сравнить процесс с ездой на велосипеде. Чуть зазевался — упал. При этом если у ИТ-специалиста изначально нет авторитета в бизнес-подразделениях, то говорить не о чем. Его привлекут лишь на этапе сопровождения. Скажут: «Знаешь, мы тут такую систему придумали, принимай».

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

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

Что же касается лидерства в проекте, не стоит айтишнику, как мне кажется, всех «строить». Зачем его ставить над «топами» из бизнеса? Они ведь потому и топ-менеджеры, что обладают уникальными организаторскими способностями, иначе бы до своих постов не добрались. ИТ-руководитель должен быть уважаемым членом команды. Способным, к примеру, рассказать о методологии внедрения. Если он показал себя на относительно мелких проектах, то и на крупном к нему прислушаются.

Стоит ли в «Учебник 4CIO» вставить главу о том, как перевести проект в процесс?

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

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