Как руководить внедрением системы, если вы не ИТ-специалист

Даже если инновации внедряет подрядчик, нужна своя команда проекта. В бизнесе не должно быть позиции: «Мы ведь деньги заплатили. Просто выдайте нам готовый продукт, а мы пока отдохнём». Более того, у своей команды проекта должен быть руководитель. Но как быть, если вас назначили, а вы не разбираетесь в ИТ?

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

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

Функции и обязанности руководителя проекта

Руководители проекта со стороны компании и организации-подрядчика идут к одной цели. Но часто рамки «местного» РП в проекте больше: он не только отвечает за внедрение продукта, но и организовывает работу и выделение ресурсов внутри предприятия, закупку и настройку нового «софта», инфраструктуры.

Руководитель проекта в компании должен:

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

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

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

Сленг, или Говорите по-русски

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

Но иногда всё же профессиональный сленг разработчика вызывает беспокойство. Например, когда он говорит:

• при клике на кнопку из этой ручки получаем айди объекта;
• в чьём скоупе данная фича?
• завтра релизим вместе с фиксом багов.

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

Основы процесса разработки. Нужно ли их знать?

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

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

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

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

Оценка сроков и сложность поставленных задач

Допустим, вы разобрались с этапами проекта, согласовали план-график. Но в процессе работы будут появляться новые требования и ошибки, на которые потребуется дополнительное время.

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

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

Общение с ИТ-специалистами. Три правила для РП

Итак, вы разобрались с методикой, подбили смету. Осталось самое сложное — работа с людьми.

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

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

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

Да это же баг! Объяснение неисправностей системы

Популярная проблема при общении с ИТ-специалистами, которая раздражает обе стороны, — это объяснение ошибок в системе (багов).

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

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

Источник: Monkeyuser.com

Как видите, подводных камней в работе РП не так много. Даже если вы не трудитесь в ИТ-отделе, рассчитывайте на свою команду. Она вам точно поможет.