Для организации нормальной работы, как с подрядчиком, так и внутри организации, нужно создать команду. В самом простом случае я вижу в этой команде 4 роли.
С моей точки зрения - они очевидны, возможно у вас есть свое видение процессов и ролей соответственно. Роли описаны для компании основной бизнес которой не связан с информационными технологиями, и ИТ рассматривается как вариант повышения эффективности основного бизнеса на примере использования некого приложения адаптированного или написанного с нуля под процессы в компании.
Менеджер (владелец системы)
Что делает.
Определяет стратегию развития, в каком направлении развивается система, что будет нужно предприятию от этой системы через год, возможно два. Утверждает бюджеты. Отвечает за работу с подрядчиком в целом. Утверждает задачи подрядчику. Устанавливает приоритет по задачам.
Что не делает.
Не является руководителем компании. Возможно заместитель или руководитель одной из функций (кроме ИТ). Не занимается вопросами как развивать систему. Т.е. ставит задачу – нужно увеличить надежность хранения данных. Не затрагивая вопроса как собственно увеличить.
Характеристики.
Человек полностью понимающий основной бизнес компании. Имеющий большой опыт работы в разных функциях компании. Имеющий определенный авторитет и политический вес в компании. Административно не относится к структуре ИТ и не являющийся специалистом по ИТ технологиям.
Аналитик
Что делает.
Описывает текущие процессы в компании в виде внутренних документов.
Разрабатывает и предлагает руководству оптимизацию существующих процессов и внедрение новых. Например, сейчас на составление одного договора с клиентом у продавца уходит 2 часа времени. В процессе анализа установлено что, если реализовать автоматическое составление и печать, то на подготовку договора будет уходить 2 минуты.
Превращает пространственные пожелания пользователей, в конкретный документ – бизнес требования. Отвечает за соответствие бизнес требований изначальным пожеланиям заказчиков.
Получает от подрядчика предложения по внедрению новых решений, продуктов и доработок. Анализирует насколько они необходимы компании. Если необходимы, предлагает руководству компании их внедрение.
Что не делает.
Не принимает управленческих решений, только предлагает их. Не устанавливает приоритеты по задачам для подрядчика. В общих чертах разбирается в ИТ и поэтому не передает абсолютно нереализуемые идеи архитектору. В отличии от менеджера, в переговорах с подрядчиком не имеет права на собственное мнения – озвучивает только то, что согласовано с руководством.
Характеристики.
Очень хорошо разбирается в процессах работающих на предприятии. Понимает, как оптимизировать работу отдела или отдельного сотрудника, даже если сам сотрудник это не может сказать. Поверхностно разбирается в ИТ технологиях.
Архитектор
Что делает.
Если менеджер определяет стратегию в каком направлении развивается система, то архитектор определяет как она развивается. Т.е. техническую сторону стратегии развития. Отвечает на вопросы типа сколько серверов нужно привлечь для обеспечения работы системы при увеличении нагрузки которую создадут 100 новых сотрудников, которых компания планирует привлечь в следующем году.
Пишет технические задания по предоставленным аналитиком бизнес требованиям и передает их подрядчику. Отвечает за соответствие технического задания бизнес требованиям.
Получает от подрядчика план работ по тех. заданию с оценкой трудозатрат. Анализирует предоставленный план. В случае необходимости согласовывает с подрядчиком внесения правок. Утверждает план работ перед тем как его подпишет менеджер.
После того как администратор установит пакета обновления на тестовой среде проверяет результат на соответствие техническому заданию. Принимает участие в тестировании. Принимает решение о приемке работ и переносе изменений на основную среду.
В переговорах с подрядчиком должен иметь свою позицию в вопросах как это будет делаться. Но вопросы что делать определяет менеджер.
Что не делает.
Не делает доработок системы. Не занимается администрированием или поддержкой приложения. Не обладает правами администратора на основной системе. В идеале не имеет прав администратора и на тестовой системе. Имеет доступ на девелоперскую среду, в рамках регламента предложенного подрядчиком.
Характеристики.
В отличии от администратора, должен обладать абсолютными знаниями по системе. А так же глубокими знаниями как технологий так и процессов ИТ в целом. Уметь вести переговоры, грамотно аргументировать свою точку зрения – от него зависит конечная цена работ и качество получаемого продукта.
Администратор
Что делает.
Работает с пользователями. Заводить и удалять из системы, обнулять пароли. Консультировать по вопросам типа, что нужно нажать что бы открылась эта форма или почему неактивна та кнопка.
В установленные сроки реагирует на сбои и ошибки системы. Должен перезапускать службы и перезагружать сервера. Выполнять другие шаблонные действия для поддержания или восстановления работоспособности системы. В случае аварий которые он не в состоянии решить, описывает проблему и передает ее подрядчику в рамках договора о поддержке.
Устанавливать полученные от подрядчика пакеты на тестовую среду. Принимать участие в приемочном тестировании пакетов на тестовой среде. Устанавливать пакеты на основную среду после приемки работ.
Составляет паспорт, договор о предоставлении услуг пользователям и другие внутренние документы по системе.
Все действия которые может производить администратор должны быть описаны в «Руководстве администратора» которое составляет поставщик системы и поддерживает его актуальность после обновлений и доработок системы.
Если все его задачи описать тремя словами то – освобождает архитектора от рутины.
Что не делает.
Не производит собственных доработок или изменений системы.
Характеристики.
По сути, его работа это сплошная рутина. От него не требуется особых знаний. Должен выполнять пару десятков операций. Большинство из которых должны быть описаны в «Руководстве администратора». Но требуется внимательность стрессоустойчивость и ответственность.
Подрядчик (понятно, что со стороны подрядчика так же работает целая команда, но с точки зрения заказчика – они единое целое)
Что делает.
Организовывает девелоперскую среду на своих мощностях. Самостоятельно контролирует изменения, вносимые своими разработчиками. При необходимости открывает к ней доступ архитектору.
Получает и анализирует техническое задание от архитектора. Предоставляет архитектору план работ с указанием трудозатрат своих менеджеров, аналитиков, программистов, тестировщиков. После согласования и уточнения плана, получает подписанный менеджером заказ на работы и оплату за работу аналитиков создававших этот план. Выполняет работы по согласованному плану. Предоставляет администратору пакет с изменениями и измененную версию руководства пользователя. После тестирования и подписания акта о приемке работ получает оплату.
Основываясь на своем опыте предлагает решения аналитику компании.
Что не делает.
Не занимается сбором требований и анализом процессов в компании. Любой анализ процессов со стороны подрядчика чреват решениями, которые не столько нужны компании, сколько должны принести доход подрядчику.
Не делает никаких предложений по системе никому кроме аналитика (по бизнес части) или архитектора (по технической части). Попытки «продать» какое либо решение бухгалтерам, маркетингу, продажам или кому то еще должны пресекаться с публичным наказанием виновных.
Не имеет доступа к основной среде. К тестовой среде – возможно, но без права внесения изменений.
Характеристики.
Роль подрядчика должна сводиться к предложению решений на основе своего опыта аналитику компании и написанию кода по техническому заданию полученному от архитектора.
