Участники проекта – это сотрудники, обладающие определенной востребованной в проекте компетенцией, выполняющие свою трудовую функцию и несущие в рамках этого ответственность.
Итак, рассмотрим на примере крупного IT проекта предприятия с сильной проектной матрицей (с хорошо развитым проектным управлением, где РП обладает широким кругом полномочий, а именно участвует в распоряжении бюджетом проекта и набором/увольнением сотрудников в проект):
Участники:
Руководитель проекта (РП): назначается приказом гендиректора по предприятию или устным распоряжением руководителя структурного подразделения к которому он относится. Если тебя официально не назначили, то есть нет никакого документа, подтверждающего твои полномочия и ты не был представлен команде как руководитель проекта, то готовься к дополнительным трудностям, а как с ними разбираться мы рассмотрим в следующих статьях. Найм РП и перекладывание на него всех организационных и прочих системных проколов и недоработок, затыкание им управленческой дырки и прикрытие им своей неполноценности и недоработки частая причина найма этого самого РП. И как выплывать в такой ситуации мы поговорим в следующих статьях. Подписывайтесь на мой канал.
Права РП: распоряжение бюджетом проекта (как правило совместно с непосредственным руководителем), набор команды в проект (ключевой момент - он принимает итоговое решение по участнику, если в твоем случае это не так бери на заметку и будь бдителен, чтобы не стать крайним, а не главным в проекте), постановка задач проектным группам, контроль выполнения, работа с заказчиком.
Ответственность: выполнение проекта в срок, в рамках выделенного бюджета, достижение показателей по прибыльности, достижение показателей в рамках стратегии предприятия (например, выход на нового заказчика с результатами проекта за счет собственных средств предприятия и получение крупного заказа). Координация работы между командами. Взаимосвязь с внешними и внутренними соисполнителями. Внешние это сторонние организации контрагенты, а внутренние это внутренние соисполнители по какому то блоку задач и те самые структуры, которые отвечают за операционную деятельность организации.
Основная задача: построить работу в проекте так, чтобы система сама работала, а не приходилось ее тащить и напрягаться сверх сил.
Менеджер проекта: может быть совмещен с РП, в разных организациях по разному, но сейчас мы говорим о сильной матрице и поэтому мы говорим об этом отдельном участнике. Назначается, также в приказе об открытие проекта или устным распоряжением. В некоторых организациях прописывается в уставе проекта, ну или прочих организационно-распорядительных документах.
Права: как правило властных полномочий не имеет, занимается в основном рутинным планированием, текущим мониторингом, аккумулированием отчетности по проекту, мелкой коммуникаций и координацией, заказами комплектующих, оформлением служебок, заявок, работает по поручениям РП.
Ответственность: точное выполнение поручений РП в срок, вникание в проект изнутри, для точного понимания и мониторинга состояния работ, грамотная письменная и устная речь для докладов РП, организация какого-то пула работ по поручению РП.
Основная задача: замещать РП во всех рутинных организационных вопросах и вопросах связанных с постоянным мониторингом и отчетностью по ходу проекта.
Администратор проекта: редкий участник, но бывает отдельно выделяют человека. Его задача-это ведение протоколов, оформление документов, приемка-передача документов и т.д.
Аналитики: занимаются уточнением требований технического задания. Как правило даже согласованное задание от заказчика содержит не мало не освещенных вопросов, которые требуется дорабатывать, предлагая концептуальное решение и согласовывая его с заказчиком и РП, занимаются проработкой требований технического заданию, с целью его декомпозиции на конкретные задачи и прорабатывают схемы решения этих задач на уровне бизнес логики, а может и глубже на уровне API, то есть могут разрабатывать программный интерфейс совместно с архитектором.
Архитектор – на основании общей концепции проекта разрабатывает аппаратную и программную архитектуру. Помимо общей архитектурной концепции в виде блок схем и диаграмм, он занимается расчетом производственных мощностей, возможно, с подбором железа под эти мощности, расчетом необходимых пропускных способностей всех интерфейсов, подбором ПО (например, опенсорсного под эти требования), разрабатывает архитектуру изделия от общего к частному вплоть до описания базовых классов для программистов, разрабатывает логику взаимодействия всех компонентов (например, в виде диаграмм взаимодействия с использованием нотации C4 или UML). В дальнейшем при реализации проекта архитектор отвечает за взаимодействие всех компонентов согласно разработанной им архитектуре и интеграцию при сдаче проекта.
Архитектор может не подчиняться РП, чаще они работают на несколько проектов, а може быть всецело выделен под проект, в таких случаях на него еще часто ложится обязанности руководителя devops в проекте.
Devops инженеры: классическое определение – это сотрудник который как клей увязывает все неувязываемые узлы проекта и решает все крайние вопросы и технические и организационные. На практике девопс как правило это выражается в следующем. Сначала в проекте девопс инженера можно привлечь для настройки работ в таких инструментах как jira/confluence и git(если это достаточно крупный проект и этим не будет заниматься сам РП), далее ему необходимо организовать производственный конвейер на котором будут работать разработчики и тестировщики CI/CD. В дальнейшем когда проект уже перейдет в стадию подготовки к сдаче ему скорее всего придется заниматься пуско-наладкой продукта, то есть его развертыванием, конфигурированием и настройкой и участвовать в отладке с разработчиками. Вообщем этого участника проекта желательно иметь full time.
Дизайнеры: разрабатывают UX/UI. Получают задачи от руководителя проекта согласовывают с ним результат (если проект крупных, то РП работает с руководителем группы дизайнеров).
Frontend разработчики: разрабатывают frontend согласно UX/UI от дизайнеров. Работают по задачам от РП
Backend разработчики: разрабатывают часть ПО отвечающую за реализацию бизнес логики продукта, программный интерфейс (API).
Тестировщики: тестируют как элементы frontend, так и бизнес логику, занимаются интеграционным тестированием, когда продукт собирается из нескольких компонентов, а также приемочным тестированием, которое проводится после выкатки на продакшн или при отгрузке заказчику.
Технические писатели: занимаются разработкой технической документации. Это может быть программная документация, такая как руководство пользователя, так и проектная такая как совместные решения с заказчиком.
Также в проекте могут участвовать иные сотрудники, различные специализированные прикладные программисты, математики-исследователи, аналитики данных и т.д. в зависимости от специфики, но основной состав проектов по разработке каких-либо аппаратно-программных комплексов я описал выше.
Также необходимо иметь в виду, что с проектом связаны такие сотрудники как закупщики, логисты, менеджеры по развитию, маркетологи, а также инженеры – конструкторы если проект имеет, разрабатываемую аппаратную часть в которую входят какие-либо механические или электронные составные части.
Проектные роли.
Почему это важно и почему важно различать склонность сотрудников к той или иной роли и почему важно уметь эти роли назначать самому?
Проект состоит из людей и взаимоотношений между ними поэтому имеет место разделение на формальные и неформальные.
Формальные – это административная проектная роль. Начальник группы, начальник отдела, начальник компонента в проекте, то есть человек, который по формальным признакам несет ответственность за пул вверенных ему задач. Эта роль оформляется официально, но не всегда совпадает с возможностями сотрудника, его мотивацией, его профессиональным интересом, его личной предрасположенностью данному роду деятельности. Например, начальник отдела может быть хорошим технарем, но некудышным организатором и и провалы в коммуникации, он не может построить системное управление в своем отделе, не имеет авторитета среди сотрудников или не имеет заинтересованности сотрудников так как не решает их вопросов и возможно даже не понимает в чем заключается их нематериальная мотивация в работе.
Не формальные - эта роль к которой сотрудник сам предрасположен или стремиться получить. Самый простой пример это неформальный лидер – ему важно, чтобы сотрудники были привязаны к нему, зависели от него или ценили его. Основные неформальные роли участников проекта на которые следует обратить внимания РП это: инициатор – человек, который наиболее активно начинает какую то новую деятельность, такому можно поручить какую-то исследовательскую задачу, финишор – человек, которому хорошо получается закрывать вопросы, подчищать все хвосты, ставить последнюю точку в вопросе, закрывать задачу. Такому сотруднику можно передать задачу, которую кто – то начал и по какой то причине не закончил. Если у инициатора она вызовет отторжение, то финишор справиться с ней на отлично. Сошиалайзер – человек коммуникатор, он часто спрашивает как у кого дела, приветлив, с ним люди не чувствуют себя напряженно. При этом он нейтрален, он не ищет в коммуникации какой-то своей выгоды, ему это просто нравиться общаться с людьми. Такого человека хорошо привлекать на совещания, переговоры, так как он сможет задавать позитивный тон, успокаивающий, особенно на совещания с руководством, которое настроено выдрать РП. Контролер – ну тут все понятно, этого человека лучше привлечь к контролю, но не своих коллег, а, например, контрагентов внутренних или внешних. Таких ролей достаточно много, но уже становится понятно, что чем лучше ты умеешь различать эти роли. Тем легче тебе ставить задачи и добиваться результата других. А еще лайфхак, тот кто роли раздает имеет над этими людьми власть. Об этих тонкостях поговорим в следующих статьях. Подписывайтесь на мой канал
