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

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

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

Тематика проектов, которые вел менеджер

С этого начинались все мои беседы об опыте работы. Интеграция или веб, коммерческие или для внутреннего использования, это становилось основой бесед, поэтому и начала я с этого пункта портфолио.

Трудоемкость проектов

Оценивать трудоемкость проектов, которые вел менеджер, проще всего по объему человеко-часов, затраченных командой проекта на его реализацию. Однако, на мой взгляд, этот показатель эффективнее рассматривать как человеко-часы на промежуток времени, в который они были затрачены. Например, проект из 800 человеко-часов не дает понимании о сути нагрузки, а вот конкретизация 800 человеко-часов команды за 2 месяца — уже вполне свидетельствует о трудоемкости проекта.

Величина и состав команд проекта

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

Структура, коммуникация и мотивация в проектах

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

Сдача проектов в срок, планирование проектов

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

Напрямую этот показатель, конечно, не отражает эффективности и профессионализма, но является немаловажным для оценки менеджера.

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

Работа с документацией проекта

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

Контроль бюджета проекта

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

Успешность проекта

Я встречала оценку как определения критериев успешности проекта на этапе определения концепции проекта и контроля этих критериев при сдаче проекта заказчику, так и контроль зафиксированных извне критериев успешности на этапе сдачи проекта и его эксплуатации. Говоря об успешности проекта, можно отмечать и прибыльность проектов, и их окупаемость, и любые другие показатели, отражающие удовлетворенность клиента качеством продукта.

Применяемые технологии, методологии и инструменты

Часто мне задают вопрос, работала ли я в парадигме Scrum или с продуктами Atlassian Confluence. Просто перечисления, как правило, было достаточно.

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

Однако структурность представления и тезисность изложения не дает погрязнуть в деталях ни составителю, ни читателю. И, несомненно, всегда остается место для диалога.

Для примера — сжатое портфолио менеджера разработки веб-проектов:

• Специализация по проектам: веб-проекты, интеграция с расчетными и информационными системами, импорт и экспорт данных.
• Проекты от 40 (неделя) до 8000 (полтора года) человекочасов.
• Команды от 1 до 15 человек. В команду входили разработчики, технологи, системные аналитики, дизайнеры, верстальщики, инженеры телекоммуникационных систем, контент-менеджеры, тестировщики. В параллели велось до 10 проектов, находящихся на разной стадии разработки.
• В командах применялась материальная (премии) и нематериальная мотивация (обучение, акцент на важности исполнителя для результата, похвала и тд). Взаимодействие между коллегами строилось как неформально (стендапы, кофе-брейки и тд), так и формально (отчетность по задачам в информационных системах, фиксация согласовательных мероприятий).
• Менеджером осуществлялась проработка и формализация требований, написание ТЗ и разделение на версии продукта, согласование ТЗ с заказчиком и передача частей ТЗ как задач в работу, составление плана тестирования и эксплуатационной документации, обучение клиента работе с продуктом.
• Из 40 проектов за год по плану были сданы 90%, в остальных случаях сдвига сроков причинами были недостаточно проработанное ТЗ, неточность в оценке задач и изменения в требованиях, обусловленные сменой законодательства. Такая предсказуемость была достигнута через частый (для маленьких задач — ежедневный) контроль задач, постановку задач так, чтобы можно было протестировать результат задачи и презентовать его клиенту и разделение задач между разработчиками параллельно.
• Из 40 проектов, сданных за год, у 10 был превышен бюджет (в трудочасах). Причины превышения — неточность формулировки задачи разработчику и как следствие неточность оценки задачи. Контроль бюджета осуществлялся после трети выполнения задач, поэтому в некоторых проектах не пострадали сроки. В дальнейшем для избежания перерасхода бюджета применяю двойное согласование задачи: с технологом (ведущим разработчиком) и разработчиком проекта.
• Из 40 проектов окупились 30%, не окупились 10%, остальные находятся в процессе выхода на плановую прибыль. Половина клиентов рекомендуют компанию-разработчика коллегам, каждый 5й клиент заказывает дополнительные услуги.
• В сданных проектах применялся «водопад» и agile, документация велась в MSWord, задачи контролировались в Jira.

Автор: alessandra_malinina

Источник