Журнал об электронном контенте, документах и бизнес-процессах
ИТ-директору Делопроизводителю Кадровику Бухгалтеру
Внедрение электронного документооборота

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

  0 комментариев Добавить в закладки

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

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

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

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

Основная задача РП – привести проект к достижению целей, соблюдая сроки и бюджет.

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

 

Ещё материалы автора
Похожие записи
Комментарии (0)
Сейчас обсуждают
Больше комментариев