4.1.2.Проектная команда исполнителя
Проектная команда исполнителя состоит из специалистов, занимающихся внедрениями ERP-систем. В нее входят:
- методисты (консультанты и аналитики),
- системные архитекторы,
- разработчики,
- тестировщики,
- технические писатели.
Обычно роли методистов, тестировщиков и технических писателей совмещают одни и те же специалисты с общим названием «консультанты». От слова «консультировать», поэтому и «консалтинговые услуги», и «консалтинг» (англ. consulting) как вид деятельности.
Системный архитектор формирует общую архитектуру будущей системы и принимает решение о способах реализации требований к ней.
Функциональные обязанности:
- анализ функциональных требований к системе и выявление противоречий;
- принятие решений о выборе способа реализации функциональных требований в системе;
- разработка концепции проектного решения, подготовка технического проекта;
- участие в разработке плана проекта и оценках бюджета;
- проработка границ прототипа системы;
- формирование спецификаций по возникающей в ходе проекта дополнительной разработке;
- поддержка и контроль качества работы разработчиков и консультантов.
Консультант выполняет основные работы в ходе проекта по коммуникации со специалистами заказчика, настройке прототипа учета в системе, подготовке технических заданий и инструкций, тестированию и обучению пользователей.
Функциональные обязанности:
- изучает требования заказчика к системе автоматизации, помогает их сформулировать и уточнить, если изначально требования не формализованы;
- определение, документирование и анализ бизнес-процессов заказчика;
- сбор требований к системе, анализ требований и их непротиворечивости;
- описание технических заданий (ТЗ) на модификации стандартной функциональности системы;
- согласование и утверждение технических заданий с ключевыми сотрудниками заказчика;
- настройка прототипа системы;
- тестирование и приемка модификаций от разработчиков;
- настройка системы в соответствии с требованиями учета заказчика;
- настройка ролей и прав доступа пользователей к системе;
- поддержка интеграционного тестирования системы с участием членов рабочей группы со стороны заказчика;
- подготовка документации для пользователей и администраторов системы;
- презентации функциональности системы для наглядного показа принимаемых проектных решений и достигнутых результатов;
- обучение членов рабочей группы со стороны заказчика и ключевых пользователей системы;
- аттестация сотрудников, прошедших обучение, на доступ к работе в системе;
- планирование и обеспечение переноса исторических данных из унаследованных систем в систему;
- начальная поддержка пользователей после запуска системы в промышленную эксплуатацию.
Разработчик проводит работы, необходимые для модификации стандартной функциональности системы по утвержденным техническим заданиям проекта.
Функциональные обязанности:
- проведение работ по программированию в системе;
- первичное тестирование и отладка модифицированных модулей;
- исправление ошибок в разработанном функционале системы;
- исправление критических ошибок штатной функциональности, по которым нет приемлемого способа обхода и срок исправления поставщиком системы не определен.
Внутри команды исполнителя у консультантов и разработчиков может быть дополнительная градация в зависимости от квалификации специалиста, например: стажер, специалист, ведущий специалист. Или возможна иная система позиционирования должностей (система грейдов, англ. grading) и ставок от этого. Главное – это поставить на задачи проекта специалистов с достаточной квалификацией для их решения.
Бывают ситуации, когда несколько ролей сосредоточены в одном человеке. Например:
- руководитель проектов + системный архитектор;
- руководитель проектов + консультант;
- системный архитектор + разработчик;
- системный архитектор + консультант;
- консультант + разработчик.
Рис. 4.3. Схема взаимодействия команды проекта
В частных случаях и в небольших проектах (реже бывает, что и в больших) это может быть небольшая группа таких «универсальных солдат», которые творят чудеса при внедрении системы. Но на практике для проектов внедрения систем класса ERP есть опасность возникновения ситуации, когда один человек – это и консультант, и разработчик: сам себе написал ТЗ, сам по нему все сделал, сам все протестировал (в процессе отладки, как разработчик и не более). Все вроде хорошо? Не совсем: ТЗ нужно формально описать и согласовать с ключевыми сотрудниками заказчика, как бы ни хотелось оптимизировать работу и самому себе ТЗ не делать. Протестировать модификацию необходимо. Руководство пользователя написать тоже нужно, обучение пользователей провести. А есть еще задачи коммуникации со сложными в общении пользователями и навыки формулирования понятных непрофессионалам текстовых описаний. И вот это часто совместить в одном человеке сложно: консультант ориентирован на коммуникацию с пользователями заказчика, разработчик – на стройную логику в коде. Но если у вас в команде такие универсальные люди есть (а они бывают, автор таких встречал), то их компетенциями необходимо умело управлять, соблюдая проектные методологии!
