Руководители IT-проектов (РП) на рынке труда в остром дефиците: по данным hh.ru на 1 вакансию приходится 1,9 резюме. Поэтому часто в компаниях один РП ведет по 5-6 проектов. При такой загрузке успеть все и сохранить качество практически невозможно.
Решить проблему с загрузкой нам помог администратор проектов. Прежде чем ввести эту роль, мы детализировали все задачи РП и выделили «рутину». Её и передали администратору. Как итог у РП появилась возможность вести больше проектов, сохраняя высокий уровень качества.
В статье Света Кыштымова, администратор проектов в Naumen, рассказала о роли администратора и задачах которые выполняет.
Света Кыштымова
Руководитель отдела администрирования проектов
Администратор проекта в Naumen — человек, который акцентирует внимание на договоренностях. Сейчас я администрирую проекты внедрения. То есть:
напоминаю коллегам о сроках;
веду протоколы встреч;
работаю с договорным отделом и организовываю согласование документов;
подвожу итоги проектов.
Ниже рассказала о проблемах, с которыми сталкиваются РП, и как администратор проектов помогает их избежать.
Сжатые сроки реализации проектов из-за долгих согласований договора
Когда компания заключает договор с клиентом, в нем указаны вполне реалистичные сроки. Но иногда внутреннее согласование может затягиваться, и времени на реализацию остается слишком мало. Поэтому я подключаюсь к проекту ещё на этапе переговоров с клиентами:
1. Вычитываю договор на предмет формальных сроков, результатов по ним и вношу в систему управления этапы проекта. Расписываю формальные артефакты, которые должны быть переданы заказчику — например, «ТЗ согласовано». То есть, создаю таймлайн, который РП наполняет задачами. В дальнейшем это помогает мне контролировать этапы проекта.
Ситуация: в договоре прописано, что через 15 дней мы должны подготовить частное техническое задание.
Мои действия: Фиксирую сроки в системе, периодически напоминаю о них РП и проверяю готовность документов. Заранее обращаюсь к коллегам из договорного отдела, сообщаю, чтобы документ начинали готовить, и в нужный срок он был готов к отправке.
Так как в проектах формируется большой объём документации, веду реестр документов и сверяюсь с тем что прописано в ТЗ, обрабатываю замечания от клиентов и прошу технического писателя внести правки.
2. Контролирую, чтобы все юридические договорённости были соблюдены, в том числе сроки. За несколько дней до дедлайна сверяюсь, всё ли идёт гладко. Когда возникают сложности, уточняю, могу ли помочь.
Ситуация: сотруднику нужно незапланированно взять отгул или больничный.
Мои действия: смотрим с руководителем на таймлайн — успеваем ли в этом случае сделать задачу в срок. Если нет, ищем замену, чтобы исключить риск срыва дедлайна.
3. Бывают ситуации, которые нельзя предусмотреть заранее, и сроки необходимо сдвинуть.
Моя задача — помочь снизить риск эскалации конфликта. Поэтому после переговоров РП с клиентом, я слежу за реализацией договоренностей. Например, связываюсь с бэк-офисом, приоритизирую документы, которые нужные отправить в первую очередь, и контролирую сроки исполнения.
Неоднозначные ситуации
Если со стороны клиента несколько стейкхолдеров, некоторые задачи бывают противоречивы. Например, у нас была ситуация, когда один из стейкхолдеров попросил удалить часть функциональности из проекта, так как она оказалась не нужна. Чуть позже пришёл второй и попросил вернуть фичу — она была полезна.
Чтобы руководитель мог сфокусироваться на теме разговора и лучше погрузиться в контекст, протокол первой встречи вела я. Мы подняли текст и убедились, что с нашей стороны всё реализовано по ТЗ. Затем встретились с аналитиками и уточнили, как можем исправить ситуацию. Оказалось, нужную функциональность легко восстановить, так как мы её не удалили, а скрыли. В итоге клиент остался доволен: мы не только удовлетворили потребность клиента, но и мы смогли отстоять свою позицию, предоставив зафиксированные договоренности.
Ещё ведение протокола встреч помогает в подготовке отчёта об обследовании и инструкций для пользователей. То есть, снимает часть задач с технического писателя и аналитиков.
Формирование задач при проведении ретроспективы
При проведении ретроспективы важно формировать повестку, а также фиксировать договоренности, задачи и ответственных за них. Иначе отсутствие даже одной может усложнить работу технической поддержки или привести к повторению ошибок на других проектов.
Часто я присутствую на ретроспективах и фиксирую всё, о чём говорят коллеги: что получилось хорошо, какие были проблемы и как можем их исправить. Это помогает улучшать процессы.
В прошлом году по итогам большого проекта, провели ретро и нашли пробел. У клиента был большой набор функциональности, за которую отвечали разные сотрудники. У внедрения не было списка команд и ролей, поэтому трудно понять — кто и за что отвечает. Решили, что будем прописывать в уставе проекта ответственных со стороны клиента в привязке к их функциональным модулям. Также контролировать их изменения на этапе всего проекта.
Никита Кардашин
Руководитель практики комплексной цифровизации процессов
«Введение роли администратора проектов помогло нам разгрузить руководителя проекта и освободить его время для решения профильных задач. А также — повысить лояльность клиентов, соблюдать договорённости, прозрачно обсуждать следующие шаги и наладить коммуникации».
Администратор проектов — человек-невидимка в мире ИТ, благодаря которому РП может спать спокойно и не волноваться о том, что он не успеет сделать «всё и сразу».
Руководитель проекта может облегчить себе жизнь и делегировать администратору рутинные, но важные задачи: фиксацию договоренностей, общение с клиентами, работу с документами и отслеживание сроков. Так РП сможет заниматься только профильными задачами, не смещая фокус на формальности.
Комментарии (12)
Batalmv
08.04.2024 07:48+1Странный подход
Во-первых, для разгрузки ПМа есть ПМ-джуны. Ну или из можно парочку завести. Или стажеров взять на практику (но это на совсем примитивные задачи). Основной ПМ даст им то, что посчитает нужным. Кому надо документы готовить, для кого надо с бумажкой для подписи побегать. Где-то формально заявки на доступа и прочую хроень делать. Всегда есть куча монотонной работы, которую можно поручить рукам, так как часто она делается по документам/инструкциям. А если джун не может и такое делать - пинок под зад и берем следующего.
А если нет - вырастет в ПМа + будет смотреть ккак и что делается. Зачем отдельный отдел - неясно. Но к примеру, я джун и идут в компанию учиться уму разуму. Понятно задачи вроде "покорми собак и ничего не трогать" не сильно радуют, но можно ходить и учиться. И я уже в штате подразделения, где возможен рост как эксперта. Там может маленький проетик дадут и так можно вырасти. Зачем идти в отдел на три "калеки", где расти некуда? Либо это будет отдел как D-лига в НБА. Типа внешне похожи на баскетболистов, может пару стрельнет, возьмем на контракт. Но смысл в отдельном отделе? Чисто синекура руководителю?
Во-вторых. Отдельный отдел == формальное распределение обязаностей плюс администратор мне не подчинен. Мне условно надо чтобы "покорми собак и ничего не трогай", а он и не покормил, и начал нос совать куда не просили. Если это в рамках одного подразделения - дал виртуально в "жбан" и все. Либо пинок под зад. А тут свой начальник, надо к нему идти - непонятно, к чему такие сложности. Проблемы обычно нет, так как есть ты ПМ - то ты все равно общаешься с ТОПами и поэтому для тебя нач. отдела мало что значит, но это как лишнее звено в процессе. Плюс сегодня он у меня, завтра у кого-то, ккто это решает? Так условно если два ПМа делят одного джуна помощника - вышли в курилку и перетерли. А тут начальник администраторов. Чего с ним или с ней делать? Прям сразу вспоминается анекдот про "лампочку и помощника"
В-третьих. Делегирование странных обязаностей вроде
В дальнейшем это помогает мне контролировать этапы проекта
Блин,если я ПМ - я отвечаю за сроки/бджетЇскоуп/риски. Какое в одно место контроль сроков администратором? Тут либо ПМы в этой организации набраны по объявлению возле овощной базы, либо у кого-то чуток мания величия. Ну правда, вы наняли ПМа чтобы контроль сроков возложить на кого-то другого
Чтобы руководитель мог сфокусироваться на теме разговора и лучше погрузиться в контекст, протокол первой встречи вела я.
Тут ОК, вопросов нет. Особенно если встреча удаленная и записана. Самая работа для джуна "ты там переслушай, перечитай стенограму и все выпиши".
общение с клиентами
Это даже сложно комментировать, по идее секретать на встречах сидит молча и не отсвечивает. Какое вообще общение с клиентом? Ну блин, это основное, что делает ПМ. Задача секретаря молча все писать и максимально тихо подсказывать боссу. Все. Даже носить серое и неприментое, чтобы "не пялились" :)
---------------------
Ну то такое, честно говоря, в современном мире только вроде от скрам-мастеров избавились, а тут новые "полезные" должности нарисовались
Gazirov
08.04.2024 07:48+3Сколько будет проектов у джуна если он будет администрировать 4х РП а у каждого по 6 проектов ? В какой момент он сойдёт с ума? За год-полтора джун должен вырасти и стать сам РП. И тут встаёт дилемма куда девать столько приростающих РП и из каких денег платить всем хорошую зарплату. С точки зрения сотрудника вы правы, но с точки зрения бизнеса дешевле платить 4 крутым РП и 2 администраторам чем, 6 РП и ещё джунов думать куда пристроить через год. А как там строиться орг структура да кому какая разница если все работает.
Batalmv
08.04.2024 07:48+1А зачем вам каждому ПМу джуна в помощь? Это если проект большой очень
---------------
Тут прикол в том, что задача администрирования типа очень важна и нужна. А в реале - на разве что для некоторых, и то не факт.
Точнее я бы сказал, она вообще не нужна, но в случае этой организации видно важно было найти должность и отдел для "хорошего" человека
С точки зрения сотрудника вы правы, но с точки зрения бизнеса дешевле платить 4 крутым РП и 2 администраторам чем, 6 РП и ещё джунов думать куда пристроить через год.
Странная математика. Для 4 ПМов, максимум один джун в помощь :) А не два администратора, к которым еще и один начальник :)
Gazirov
08.04.2024 07:48+1Вашем видении, все может делать один человек. Наверное да, когда проект не большой то так будет ок.
Можно сказать зачем нам аналитик, разработчик сам соберет требования, зачем нам тестировщик возьмем джуна разработчика он сам протестирует и еще и код поправит и под учиться и будет потом нормальный разработчик, девопс в целом тоже не нужен джун разработчик настроит инфраструктуру еще и прокачается. РП кажется тоже не нужен разработчик может же пообщается с клиентом и обо всем договориться делов то на 5 минут.
Тут мы попадаем в ловушку что все может сделать и 1 специалист, но если нагрузка возрастёте то качество и скорость очень сильно упадут. и тут нужен конвейер где каждый сотрудник работает в своем месте со своими узкими задачами.
Понятно что если у РП 1-2 проекта вяло текущих то ему не нужна никакая помощь. но в случае когда у вас 5 проектов и каждый день вы на созвонах, встречах и тд. и даже со всеми клиентами у вас любовь. Юридические моменты никто не отменял и если в договоре написано что 1 числа надо закрыть этап на бумаге, но вы физически не успели добежать до бухгалтерии и сказать отправляй документы то попадаете на штрафы не приятности и тд. и тут как раз помогает администратор.
Batalmv
08.04.2024 07:48Можно сказать зачем нам аналитик, разработчик сам соберет требования, зачем нам тестировщик возьмем джуна разработчика он сам протестирует и еще и код поправит и под учиться и будет потом нормальный разработчик, девопс в целом тоже не нужен джун разработчик настроит инфраструктуру еще и прокачается.
Речь не идет о том, чтобы нагрузить функциями другой роли. К чему ваш пример? Тут статья о том, что создали отдельное подразделение для помощи ПМам в выполнении ИХ функций
Вам нравится спорить с "придуманными" аргументами оппонента? Ну такое :)
Понятно что если у РП 1-2 проекта вяло текущих то ему не нужна никакая помощь. но в случае когда у вас 5 проектов и каждый день вы на созвонах, встречах и тд. и даже со всеми клиентами у вас любовь.
Если у вас 5 проектов, то либо это не проекты, либо надо больше ПМов. Да, такое бывает, но это действительно что-то мелкое и вялотекущее. Либо вооюще есть организации, которые проектом называют, ну не знаю, откгрузкуотгрузку со склада по заказу :)
Юридические моменты никто не отменял и если в договоре написано что 1 числа надо закрыть этап на бумаге, но вы физически не успели добежать до бухгалтерии и сказать отправляй документы то попадаете на штрафы не приятности и тд. и тут как раз помогает администратор.
Конечно, но в статье идет речь о контроле сроков со стороны администратора, что выглядит смешно. Бумажка - это такое. Вопрос в работах по акту. Если работы не выполнены - чем вам бумажка поможет? Чисто формально выдать документ, и пусть та сторона пишет "список замечаний"? Ну ... если организация автора статьи так работает, то наверное да - тут администраторы важны
А вот работы - это как раз то, что нельзя исправить за 5 минут до конца рабочего дня. Если ПМ провафлил сроки, то это надо было отслеживать намного заранее. Почему команда не справилась, почему в решении есть баги и т.д. Проблема случилась намного раньше и чего тут может помочь администратор - неясно
--------------------------------------
Знаете, у меня был опыт работы с ПМом, который пришел из секретарей. Терся возле борда как секретарь, в какой-то момент позицию сократили, пререшел в ПМы. Потом в большие руководители в ПМО. Ну такое
Но прикол в том, что сидим мы на встрече. Суть проста. В решении ИТ безопасность нашла уязвимости и предлагает устранить. Бизнес упирается "рогом", так как надо время, возможно чуток денег (не помню уже детали, но это не важно). Классический "песец, который подкрался незаметно", хотя о необходимости взаимодествовать с ИТ безопасностью заранее писалось в докмуентах не раз. Не утомляя вас деталями и сутью, перейду к фану
Новоиспеченный ПМ предлагает: "а давайте подпишем протокол что уязвимости нет". Ну ... на него смотят как на дебила, но он по ходу еще предлагает предложение раза три.
Понятно, что в психологии человека, который всю жизнь работал с бумажками, это и есть решение. Написал бумажку, вложил и дальше пусть парится кто-то другой.
Так и с вашим комментарием.
Мне очень сложно представить, что ПМ провафлит поход в бухгалтерию, если это важный дедлайн, к которому команда работала долгое время. Все документики уже написаны заранее, люди ждут и т.д. Но ... я не против, если в бухгалтерию побежит лично джун, так как бегающий ПМ. ккак и полковник в "в обычное время вызывает смех, а перед дедлайном - панику"
ZalmanRZ
08.04.2024 07:48+4Конечно можно посчитать сколько там у кого джунов секретарш и тд. Но автор не просто так делится своим подходом. Этот подход приносит результат. И заключается подход, не в том, что добавили еще одну единицу в процесс. А в том, что разделили задачи ПМ на более квалифицированные (разбивака проекта на подзадачи с учетом доступных ресурсов) и менее квалифицированные (пинать, эти доступные ресурсы). Тем самым оптимизировали работу структуры, дорогой специалист не занимается простой низкооплачиваемой работой.
Но опять же, есть разные подходы, кому то надо администрировать проекты, кому то не надо. То, что нет отдельной единицы ПМ, не значит, что планированием не надо заниматься, а если занимаешься планированием, стоит использовать прогрессивные подходы проджектменеджмента. Но это мое мнение, никому не навязываю.
Я допустим сам себе и тимлид, и техлид, и ПМ, но больше всего мне не нравится подрабатывать у себя джуном. Технические задачи я давно разделяю и то что попроще, на аутсорс. Но вот планирование, как то самому все делать приходилось. Теперь вот получается можно разгрузить себя еще немного. Спасибо автору.
sshmakov
Идея хорошая и правильная, а вот это вообще чудесно:
Ты слышишь, Матильда? У них и отдел администрирования проектов есть со своим руководителем. Ну ничего, секретарям тоже нужен карьерный рост.
blognaumen Автор
Добрый день!
Света управляет командой из двух человек, поэтому, помимо задач администратора, готовит отчёты и распределяет активности внутри своей группы. В команде Светы есть технический писатель и ещё один администратор — так как проектов в работе много, один администратор бы не справился :) Поэтому было решено создать отдельную команду, которая помогает бизнесу.
sshmakov
Извините за тупость, но я все равно не понимаю, для чего нужен отдел из трех человек, один из которых - руководитель. Если очень нужна иерархия, чтобы сотрудник входил в какой-то отдел, то почему администраторы не могут относиться, например, к отделу РП? Тем более, что на администратора просто передается часть рутинных обязанностей РП.
blognaumen Автор
Группа администрирования работает не только на проектах внедрения, а занимается отчетами, учетом лицензий, организацией обучения клиентов, организацией рабочего пространства для сотрудников подразделения и т.д. Также в практике два направления: продуктовое и центр внедрения. Группа администрирования работает на оба: например, тот же технический писатель занимается как проектной документацией, так и документацией для продуктов.
Если бы РП был прямым руководителем этой группы, на него легла бы дополнительная нагрузка — в виде распределения и контроля всех этих задач. Сейчас это делает Света.
sshmakov
Так, оказывается уже не отдел, а группа. Но в штатке сделали все же отдел.
По-моему, я ни разу не предлагал РП стать прямым руководителем группы. Но даже и так, распределение обязанностей в этой группе - небольшой налог за выполнение самих обязанностей.