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

Ниже результат голосования по опросу "В какой момент Вы соглашаетесь быть РП проекта ?". Результат говорит о том, что только 8% понимают и используют все скрытые возможности этого этапа, которые я постарался описать в первой статье.

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

Ниже результат голосования по опросу "Соблюдаются ли требования Уставов в проектах вашей компании?". Результат, собственно, тоже ожидаемый. В 66% проектов вообще нет Устава, а 5% даже не догадывались, зачем он нужен и чем может помочь. Но меня удивило больше то, что 0% (НОЛЬ) ответило, что Устав соблюдается неукоснительно. Читайте об этом во второй статье.

Третья часть посвящается "Управлению Командами" на проекте. В ней я также расскажу про "лайфхаки", которые помогут вам спланировать работы, сформировать команды и управлять ими немного лучше, чем те, кто делает это "по-классике".

Итак, начнем....

Что я подразумеваю под "Формированием команды"? Это точка, когда уже выполнена предварительная оценка и предварительное планирование работ проекта. И настало время, собственно, найти и сформировать рабочие группы из тех "бравых" ребят, которые эти работы будут выполнять. При этом нужно понимать, что одни работы могут выполняться всего одним человеком (без команды), а другие работы требуют выделения отдельной команды для их выполнения (работа в команде). Причем для разных проектных работ требуются разные команды. Иногда количество команд на проекте может доходить до нескольких десятков. Это могут быть команды создания отдельных модулей, автоматизации крупных бизнес-процессов, реализации микро-сервисов, создания технологического процесса, разработки тест-кейсов, построения методологии и т.д. и т.п. Т.е. как чисто технические или чисто бизнесовые, так и смешанные.

Дзен №1: "Твой план проекта не высечен в камне. Начинай с прототипирования. Это поможет тебе выявить "забытые" требования и скорректировать план проекта в самом начале."

Первое планирование проекта никогда не будет финальным. Если есть возможность, то старайся первым этапом проекта запланировать задачи "Уточнение требований" и "Прототипирование". Цель - исследовать требования как можно лучше и сделать прототип будущей системы. На этапе прототипирования не нужно делать законченный работающий функционал. Задача прототипирования - нарисовать визуальные архитектурные схемы и интерфейс рабочих окон будущего продукта. Нарисуй их там где удобнее: в Visio или Figma или Draw.io, не важно. Главное - дать Заказчикам и Команде возможность посмотреть на будущий облик системы и ее интеграционные потоки. Если у тебя есть хорошая команда разработчиков, то можно даже прямо в системе на dev-стенде набросать базовые интерфейсы с полями отображения и ввода данных. Нужно как можно быстрее показать их Заказчикам и Команде и собрать обратную связь.

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

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

Дзен №2: "Превращай крупные задачи проекта в группирующие блоки. Дроби их на более мелкие самостоятельные подзадачи с зависимостями их выполнения друг от друга".

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

Руководствуйся принципом: "1 подзадача = 1 команда = 1 законченный результат", который можно показать, описать и использовать в следующих задачах проекта. Такое дробление поможет тебе избавиться от ситуации длительного неконтролируемого срока выполнения крупных задач. Ты сразу сможешь понять зависимости выполнения подзадач друг от друга (почему следующие подзадачи никак не могут начать выполняться). Заодно это поможет ответить на распространенный вопрос стейкхолдеров: "Нам не понятно где мы находимся и сколько еще нужно ждать завершения этой длительной задачи?"

Дзен №3: "Не относись к бюджету как к резиновой бочке. Вникай и разбирайся с предоставленными оценками сроков\стоимости и всегда формируй резерв."

Часто руководители проектов впадают в две крайности при планировании бюджета. Одна крайность исходит из ложного впечатления, что оцененные в начале проекта ресурсы справятся с поставленной задачей, а заложенные в проект затраты не вырастут. Другая крайность вытекает из плохой оценки (либо отсутствия оценки) и формирования резерва, взятого "с потолка". Обе крайности опасны, поскольку могут привести к перерасходу бюджета. Используй комбинированный подход: всегда получай предварительные оценки от команд и уже после этого закладывай резерв на непредвиденные ситуации (как правило такой резерв должен быть 10-15% от стоимости проекта).

Скептически относись к оценкам, кратным 8 часам для небольших задач (т.е. 1 рабочий день) и 40 часам для крупных задач (1 рабочая неделя). Такие оценки говорят о том, что они формируются "пальцем в небо". Для исполнителей такой подход к оценке очень удобен - можно заложить на задачу, например, целую неделю (40 часов), из которых реальная работа будет занимать конечно меньше, а остальное время будет списываться на активности, не имеющие к проекту отношения. Если тебе прислали оценки кратные 8 часам (для небольших задач) или 40 часам (для крупных задач), то это сигнал, чтобы насторожиться. Вполне возможно, что такие исполнители будут теми самыми "пожирателями" твоего "не резинового" бюджета.

После уточнения предоставленных оценок всегда делай резерв "на непредвиденные требования". Чем полезен резерв? Многие часто ради сокращения стоимости проекта стараются убрать лишние затраты и сократить размер резерва (или убрать его вовсе). Некоторые воспринимают наличие резерва как "признак плохой оценки". Резерв также могут "зарезать" для того, чтобы пролезть в выделенный бюджет или для того, чтобы уложиться в ожидания руководства. Однако, резерв на проекте крайне важен. Его можно сравнить со страховкой ОСАГО. Никто не застрахован от неприятных ситуаций. И лучше, чтобы эта страховка была, она часто спасает многих от неприятных последствий.

Дзен №4: "Небольшие команды из 3-4 человек более продуктивны, чем команды из 5 и более участников".

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

«Пусть это сделает кто-нибудь другой, а не я». Такая ситуация в психологии также называется "Социальная Лень". Максимилиан Рингельман провел исследования в надежде обнаружить некую закономерность падения личной производительности при совместном труде. В частности, он вывел формулу. Если взять производительность одного человека за 100%, то для совместной работы 2 человек индивидуальная производительность окажется примерно 93%, для трех человек - 85%, а в группе из восьми человек - 50%. При этом каждый отдельный участник группы полагает, что лично он выкладывается абсолютно. Никто не ощущает падения личной эффективности труда.

Причины, вызывающие "социальную лень":

1. Потеря личной ответственности за итоговый результат.

2. Утрата координации внутри группы (2 человека сильнее координируют совместную деятельность чем 8).

3. Уменьшение личной мотивации.

4. Анонимность личного вклада в результат.

5. Деиндивидуализация (размытие личностной ценности в общем результате ).

Небольшое отвлечение. Интересное следствие из «Эффекта Рингельмана», получившее название «Эффект не вмешивающегося свидетеля» - чем больше у трагического случая имеется свидетелей, тем меньше шансов у жертвы происшествия дождаться реальной помощи.
Если за трагедией наблюдает один человек, то он скорее всего попытается прийти на помощь, потому что лично понимает, что кроме него помочь просто некому. Велики шансы получения помощи и от группы из 2-3 человек. Но если за бедствием наблюдает толпа, то жертва, вполне вероятно, останется один на один со своей бедой. В такой ситуации люди невольно надеются, что оказывать помощь (и, соответственно, рисковать) будет некто другой. Лучше переложить ответственность за спасение на чужие плечи, чем рисковать самому.

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

Дзен №5: "Не планируй ресурсы исполнителей по принципу добавления всех, "кто в теме" или может помочь. Карта выделенных ресурсов часто "плывет", будь к этому готов".

Ресурсное планирование является важной вехой проекта. Нужно забронировать ресурсы исполнителей для твоего проекта заранее. Однако, на практике оно имеет весьма условный смысл. Забронированные ресурсы могут заболеть, внезапно уйти в отпуск, быть переброшены на другие более приоритетные проекты и т.д.

Поэтому выполняй первоначальное ресурсное планирование на весь проект сразу после того, как ты выполнил дробление крупных задач на связанные подзадачи и получил по ним список исполнителей с оценкой сроков\стоимости. Но будь готов к тому, что твоя карта ресурсов "поплывет". Зафиксируй ключевых сотрудников для каждой задачи. Обязательно собери со всех информацию об их отпусках. Наложи карту отпусков на карту забронированных исполнителей, отметь пересечения красным. Учитывай пересечение отпусков тех, кто уходит в отпуск с теми, кто их страхует и подменяет. В эти периоды производительность падает, потому что замещающий на период отпуска сотрудник не только выполняет свои задачи, но еще "тянет лямку за того парня". Регулярно актуализируй карту ресурсов в горизонте ближайших 3-х месяцев. Это позволит тебе заранее выявить приближающиеся риски срыва сроков из-за нехватки или переключения ресурсов.

Дзен №6: "Не превращай требования регулярного учета и списания времени по проекту в фактор негатива. Но также избегай формального списания времени - это враг твоего бюджета."

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

У этой задачи часто встречаются две крайности:

• одна крайность заключается в том, что руководитель проекта просит списывать время каждый день и чуть ли не каждый час: "Приступил к задаче - засеки время, сделал перерыв - засеки время, закончил работу - зафиксируй потраченное время". Конечно, это приводит к раздражению, ведь каждый исполнитель считает себя талантливым и творческим профессионалом, которому чуждо подобное отношение.

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

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

Конечно, подход к списанию часов зависит от регламентов и негласной культуры, установившихся в компании. Их часто сложно менять или игнорировать. Но я могу посоветовать подходить к списанию немного другим способом. Зафиксируйте для каждой задачи предельную трудоемкость ее выполнения. Сделайте всем исполнителям коммуникацию, что вы разрешаете списывать время постфактум так, как им это будет удобно. Но превышение предельной трудоемкости будет сигналом о плохой оценке или отсутствию контроля за списанием со стороны руководителя этого сотрудника. Если есть возможность, то выгрузите в Excel список задач с первоначальной оценкой и реально потраченными часами. Постройте сводную диаграмму сотрудники\задачи\план\факт и посмотрите по каким сотрудникам трудоёмкость фактического выполнения превышает первоначальную оценку (вылезает в красную зону). Сделай этот Excel с графиками публичным, разошлите всем участникам ссылку на него. Публичность - это ключ к честному списанию. Выход в "красную зону" - мотиватор делать лучше и быстрее. Многократный выход - повод для неприятного разговора с руководителем этого сотрудника и возможная эскалация выше (если руководитель не примет меры).

Дзен №7: "Будь готов к конфликтам в командах. Они неизбежны. Прими это как данность и держи руку на пульсе. Не пропусти моменты их зарождения.

Общая цель и общие ценности не всегда объединяют людей в команде. Точнее они могут быть тем самым клеем на начальном этапе ее становления. Но они не способны сразу и окончательно сделать ее "командой мечты".

Любая команда проходит фазы:

• формирование,

• притирка,

• конфликт,

• достижения понимания и подтверждение ролей;

  и уже после этого становится сплоченной "зрелой" командой. Причем все эти стадии проходятся строго последовательно. Если какая-то стадия не была "прожита", то скорее всего через какое-то время это выстрелит в виде неразрешенных вопросов и даже новых конфликтов.

Конфликты могут быть тоже разными и по разным причинам:

• конфликты межличностного общения (как часто принято говорить "не сошлись характерами". Например, один мой знакомый постоянно отслеживает выпуски моих статей и сразу, не читая, ставит дизлайк с неизменным типом "личная неприязнь к автору" - такое тоже бывает :) надо относиться к этому философски);

• конфликты за явное (формальное) и неявное (неформальное) лидерство - сразу скажу, что в команде допускается одновременное наличие формального лидера и неформального лидера при условии, что они обо всем договорились;

• конфликты, связанные со спорами в процессе обсуждения предлагаемых решений - самоутверждение за счет личной профессиональной экспертизы и неприятие критики;

• и другие причины, которые могут стать искрой или катализатором развития конфликта "на ровном месте".

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

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

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

P.S. Прошу не критиковать за возможные грамматические ошибки, пишу во внерабочее время и без редактора.

Очень сложный для меня вопрос, который я каждый раз задаю себе снова и снова.... Есть какое-то внутренне неугомонное желание помочь тем, кому предстоит плавать в сточных водах бурной реки "правильного управления проектами". А еще я хочу собрать обратную связь от тех, кому довелось столкнуться с похожими проблемами. Или они видят, что вот-вот столкнутся с ними и хотят знать где еще "подстелить соломку".

Если какие-то идеи "зацепили" или показались интересным в процессе прочтения, то напишите об этом в комментариях. А еще лучше, если вы подкинете свои мысли, какие еще проблемы могли "подкосить" проект или привели к особенно жестокой схватке или неприятным последствиям. Я их постараюсь разобрать и описать в следующих постах. Или просто поделитесь этой статьей со своими знакомыми - кто знает, может именно это спасет их проект или даже сделает их будущими героями моих статей (мир тесен) :)