---

В Blue мы уделяем много времени размышлениям о управлении проектами. Это критически важно для того, что мы делаем, и для успеха того, что мы предоставляем нашим клиентам. Без твердого понимания управления проектами, как мы можем построить программное обеспечение для управления проектами?

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

Хотя обычно (и приемлемо) ориентироваться на проект, полагаясь на более неформальное, интуитивное чувство, это вряд ли масштабируемый подход — и не без своих недостатков.

Проект

Давайте начнем с определения проекта.

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

• У проекта есть ограниченные ресурсы (время, деньги, люди);
• Проект выполняется для достижения конкретных целей;
• У проекта есть определенный объем работ (то есть есть четкие вещи, которые он не будет делать);
• Проект подвержен неопределенности и рискам.

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

• Менеджер проекта;
• Цель;
• Список задач — это часто называется планом;
• Назначенный человек для выполнения каждой задачи;
• Сроки для каждой задачи;
• Стратегия коммуникации с регулярными обновлениями и встречами, а также план, где будет храниться информация.

Мы обнаружили, что эти вещи обычно применимы ко всем проектам и, если они выполнены хорошо, устраняют 99% всех проблем в проектах.

Менеджер проекта

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

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

Стоит рассмотреть, что менеджер проекта должен и не должен делать. В конце концов, на нем лежит большая ответственность, и он должен серьезно относиться к этой ответственности.

Часто управление проектом может занимать значительную часть бюджета проекта — обычно от 2% до 10% в зависимости от того, насколько рискован проект. Чем больше риск, тем больше требуется управления проектом, чтобы гарантировать, что все идет по плану и проект не провалится.

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

Менеджер проекта также отвечает за общение с заинтересованными сторонами проекта и информирование их о ходе выполнения.

Точно так же, как мы обсуждали в Приоритизация для лидеров, менеджеры проектов должны постоянно сосредотачиваться на точке ограничения. Если получение одобрения от заинтересованных сторон занимает слишком много времени, то они должны быть сосредоточены на получении этого обязательства. Они должны постоянно задавать себе вопрос: «Что мешает нам завершить цели проекта и как я могу как можно быстрее устранить эту проблему?»

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

Цель

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

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

Цели проекта должны быть SMART:

• Конкретные. У проектов часто есть высокоуровневые цели, которые звучат больше как миссия или видение. Пример плохой цели: «улучшить поддержку клиентов». Это недостаточно конкретно. Что-то вроде «Мы стремимся ответить на 90% запросов клиентов в течение 30 минут к концу IV квартала» гораздо более конкретно.
• Измеримые. Когда вы устанавливаете конкретные цели, вы, как правило, одновременно решаете проблему измерения, потому что тогда легко оценить, достигнута ли цель.
• Достижимые. Цели имеют смысл только если они могут быть достигнуты. Но это не оправдание для создания легких целей. Хорошая цель должна иметь элемент напряжения — быть достаточно сложной, чтобы ее можно было достичь, но не невозможной или маловероятной.
• Актуальные. Это может показаться самоочевидным, но вы будете удивлены, как часто это происходит. Цели проекта должны быть достижимы в ходе выполнения проекта. Нельзя устанавливать цели, которые не могут контролироваться командой проекта, выполняющей конкретную работу проекта. Например, команды, работающие в производственном подразделении корпорации, могут не влиять на опыт покупок клиентов в магазине.
• Ограниченные по времени. Хорошие цели должны иметь привязку к времени. Это может быть сложно, особенно в современных программных проектах, где объем работы не всегда ясен, поэтому сроки могут быть крайне трудно оценить. Иногда вы можете ошибиться в несколько раз, и это не вина конкретного человека. Тем не менее, наличие сроков гарантирует, что общий объем проекта остается в определенных рамках. Если у вас есть месяц для решения проблемы по сравнению с годом, вы получите совершенно разные решения.

Цели должны повторяться всем членам команды до тошноты: они должны (в переносном смысле) устать от того, что менеджер проекта постоянно обсуждает цели. Некоторые панели мониторинга в реальном времени (или как можно ближе к реальному времени), которые отслеживают прогресс, также могут быть бесценны для обеспечения того, чтобы все были согласованы с целями и знали, как проект движется.

Список задач

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

Планы часто являются предположениями, но они все равно имеют ценность. Это связано с тем, что сам процесс планирования помогает прояснить, что мы знаем, а что еще не знаем.

Не планируешь — планируй провал.

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

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

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

Эта последняя часть обратного процесса планирования обычно выявляет упущенные задачи.

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

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

Назначенный человек для выполнения каждой задачи

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

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

1. Фаза проектирования 1 от проектировщиков
2. Проверка осуществимости 1 от строителей
3. Фаза проектирования 2 от проектировщиков
4. Проверка осуществимости 2 от строителей
5. Обзор от старшего заинтересованного лица
6. Финализация дизайна от проектировщиков
7. Финальные проверки от строителей
8. Одобрение от заинтересованных сторон

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

Сроки для каждой задачи

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

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

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

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

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

Стратегия коммуникации

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

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

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

Таким образом, очевидно, что сами инструменты не так важны; это просто факт, что по мере увеличения числа людей в команде (скажем, 10) командная работа становится все более сложной.

Это связано с тем, что командная коммуникация не масштабируется линейно по сравнению с количеством людей в команде.

Например, если у вас команда из 2 человек, существует одна коммуникационная нить (между двумя людьми). Добавьте еще одного человека в смесь; теперь у вас три коммуникационные нити. Таким образом, хотя размер команды увеличился на 50%, количество коммуникационных нитей увеличилось на 300%.

Давайте посмотрим, как это растет:

• 2 члена команды = 1 коммуникационная нить
• 3 члена команды = 3 коммуникационные нити
• 5 членов команды = 10 коммуникационных нитей
• 8 членов команды = 28 коммуникационных нитей
• 10 членов команды = 45 коммуникационных нитей
• 15 членов команды = 105 коммуникационных нитей
• 20 членов команды = 190 коммуникационных нитей
• 30 членов команды = 435 коммуникационных нитей
• 50 членов команды = 1,225 коммуникационных нитей
• 100 членов команды = 4,950 коммуникационных нитей

Это можно выразить следующей формулой:

n(n-1)/2

Где n — это количество людей, которые должны быть вовлечены в проект.

Как вы видите, это число растет экспоненциально по мере увеличения размера команды. Если у вас команда из 10 человек, необходимо управлять 45 потенциальными коммуникационными нитями. Но если у вас команда из 50 человек, то существует 1,225 потенциальных коммуникационных нитей — это в 27 раз больше! А если у вас команда из 100 человек, то существует 4,950 возможных коммуникационных нитей — это в 110 раз больше!

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

Например, у вас команда из 10 человек, но они находятся в разных частях мира. В этом случае все равно существует 45 потенциальных коммуникационных нитей, которые необходимо управлять — даже если члены команды не находятся физически близко друг к другу.

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

n(n-1)/2

Где n — это количество каналов коммуникации.

Давайте снова возьмем количество коммуникационных нитей выше, но на этот раз предположим, что n состоит из:

• Электронной почты
• Группового чата
• Личного чата
• Комментариев в системе управления проектами
• Звонков
• Заметок/Комментариев в документах

Подставив числа, мы получаем:

• 2 члена команды = 6 коммуникационных нитей
• 3 члена команды = 18 коммуникационных нитей
• 5 членов команды = 60 коммуникационных нитей
• 8 членов команды = 168 коммуникационных нитей
• 10 членов команды = 270 коммуникационных нитей
• 15 членов команды = 630 коммуникационных нитей
• 20 членов команды = 1,140 коммуникационных нитей
• 30 членов команды = 2,610 коммуникационных нитей
• 50 членов команды = 7,350 коммуникационных нитей
• 100 членов команды = 29,700 коммуникационных нитей

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

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

И хотя идея «стратегии коммуникации» может звучать сложно и грандиозно, это не обязательно так. Главное — установить несколько принципов, обозначить ключевые каналы коммуникации и, возможно, также сказать людям, что не следует делать.

Несколько основных принципов, которые стоит учитывать:

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

Что касается каналов коммуникации, чем меньше, тем лучше. Мы бы предложили сократить их до следующих:

• Программное обеспечение для управления проектами для обсуждения задач.
• Встречи (очно или удаленно) с протоколами встреч и местом, где можно найти все протоколы встреч проекта в одном месте.
• Документы: это могут быть комментарии и обсуждения в Google Docs или специфических инструментах (например, Figma для UX-дизайна), которые позволяют оставлять комментарии.

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

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

Заключительные мысли

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

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

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

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