Блог об управлении проектами

FAQ для начинающих. Новичков в управлении проектами интересуют ответы на одни и те же вопросы: «Как стать менеджером проектов?», «Что почитать по управлению проектами?», «Как правильно организовать свое рабочее время?», «Нужен ли проекту профессиональный менеджер или можно поручить проект техническому специалисту?» и т.д.
Ниже привожу небольшой FAQ для людей, которые хотят стать менеджерами проектов, но не знают, как это сделать и с чего начать.
( Collapse )

Об управлении рисками в проектах. Все, что вы не знали и боялись спросить о проектных рисках.
( Collapse )

Великие менеджеры, великие проекты. Рассказы о том, как делаются проекты, изменившие мир (здесь вы вряд ли найдете историю про внедрение 1С на заводе).
( Collapse )

«Непридуманные истории об управлении проектами» – рассказы из жизни менеджера проектов Леши Шрудкина и его коллег. Основано на реальных, хотя и не всегда приятных, событиях. Сериал без конца и края.
( Collapse )

Список лучших постов – рекомендовано к неторопливому прочтению.
( Collapse )

Задачки-водокачки – одна из самых интерактивных рубрик блога. Разбираем сложные управленческие ситуации, встречающиеся в абсолютно реальных проектах. Умные менеджеры ищут решение кейсов и учатся на своих и чужих ошибках.
( Collapse )

Вы обалдеете, сколько классных постов по тегам "заметки на бегу", "упражнение для менеджеров" и "менеджмент в литературе".

А уж сколько рецензий на  бизнес-книги в моем блоге – вообще с ума сойти.

А еще тут можно подписаться на мой телеграм-канал.

Продукт-менеджер должен находить баланс между активным и пассивным воздействием на мир. Поясню на примере.

Многим людям мешает шум, не дает сосредоточиться на важном и интересном. Можно решить проблему пассивно: дать им беруши с шумоподавлением. И таких продуктов — море. А можно решить проблему активно: взять пулемет и избавиться от источников шума. Вот вы сразу подумали про «перестрелять окружающих». Ну что вы, что вы. Не обязательно же люди — источник этого шума. )

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

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

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


Тут можно подписаться на мой телеграм-канал.

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

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

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

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

А что до идей, то Говард Эйкен, пионер американского компьютеростроения, любил повторять: «Не беспокойтесь о том, что кто-то украдет ваши идеи. Даже если они и правда хороши, вам придется заталкивать их людям в глотку».


Тут можно подписаться на мой телеграм-канал.

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

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

Но осознанная неуверенность — не слабость. Если человек действительно в чем-то сомневается и не скрывает своей неуверенности — это очень хорошо.

Когда вы с командой обсуждаете задачу, то ваша осознанная неуверенность стимулирует совместный поиск решения. Нет доминирования и навязывания своего мнения. Показная уверенность даже мешает — людям сложнее с вами спорить. И если ты такой умный и уверенный, зачем ты нас-то позвал?

Неуверенный кандидат на интервью аккуратно вовлек меня в обсуждение решения кейса — замечательно. Неуверенный партнер на переговорах вызвал желание ему помочь (не пожалеть, не проиграть, а помочь) — хорошо.
Фильмы Вуди Аллена и спектакли Евгения Гришковца показывают, что демонстрируемая неуверенность не мешает слушать и понимать авторов.

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

Тут можно подписаться на мой телеграм-канал.

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

Так делать не надо.

Есть пользователь. Есть продукт, который вы для него создали. Не надо вмешиваться в отношения пользователя и продукта.

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

Продукт — это не ваша классная продуктовая команда, не бэк-офис и не служба поддержки. Это отделенная от них сущность.

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

Тут можно подписаться на мой телеграм-канал.

1. Делегировать — это передать свою задачу подчиненному и освободить время для других дел. Для подчиненного это благо: он развивается, у него появляются функции руководителя, новая информация и власть.

2. Делегировать — вывести сотрудника за рамки его роли и обязанностей. Если задача соответствует роли сотрудника, это не делегирование, это просто задача.

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

4. Делегирование всегда происходит сверху вниз в иерархии управления. На горизонтальном уровне мы просто ставим задачи исполнителям.

5. Нельзя делегировать задачу в один момент. Делегирование — это процесс:
А. Руководитель показывает, как он делает задачу. Сотрудник смотрит.
В. Они делают задачу вместе, но сотрудник пассивен, основную часть делает руководитель.
С. Сотрудник делает, руководитель корректирует его действия.
D. Сотрудник делает, а руководитель его хвалит. Это важно. В этот момент руководитель становится пассивным наблюдателем, задача уже у сотрудника.
Е. Сотрудник действует самостоятельно.
F. Руководитель контролирует результаты и наказывает за косяки.

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

Пример: менеджер Антон нанимает разработчиков и аналитиков в команду. Он делегирует задачу «нанять разрабов» сотруднику Глебу.
А. Антон идет собеседовать кандидата и зовет с собой Глеба. Тот смотрит, как Антон проводит интервью, какие вопросы задает.
В. Антон проводит интервью. Глеб тоже иногда задает вопросы кандидату.
С. Глеб проводит интервью, а Антон задает уточняющие вопросы, помогает.
D. Глеб проводит интервью, Антон молча наблюдает, а после — хвалит Глеба.
E. Глеб на интервью, а Антон даже не пришел. Глеб сам нанял разраба.
F. Антон следит, кого нанимает Глеб. Когда Глеб решил нанять человека без полноценного интервью, только на основе рекомендаций знакомых, Антон не позволил.

6. Можно делегировать задачу, но не ответственность.
Антон избавился от задачи, но не получил права сказать: «У нас проблемы? Ну, это Глеб виноват, он плохих людей нанимает».

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

8. У делегирования должны быть ограничения по составу задач или по масштабу.
Глеб нанимает только разрабов, но не аналитиков. И с зп до 250К.

9. При делегировании сотрудник получает власть. Он обязательно начнет ей пользоваться и постарается ее приумножить. И нарушит правила. Поэтому ограничения и контроль — это важно.
Глеб хотел нанять человека за 300К, но Антон не позволил.

10. Микроменеджмент — враг делегирования. Он убивает инициативу сотрудника и смысл делегирования.
Антон не критикует действия Глеба, он доверяет ему и следит только, чтобы условия задачи выполнялись.

11. Делегировать — это правильно. Только надо правильно делегировать. )


Тут можно подписаться на мой телеграм-канал.

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

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

=> Быстрее всего люди обрабатывают положение точки на прямой. Поэтому двумерные объекты — самые удобные для восприятия. Где мы сейчас в проекте? А, вот линия времени, вот границы спринта, вот дата окончания. Все понятно.

=> Люди быстро обрабатывают длину линий и расположение объектов на плоскости. Это хорошая новость для любителей гистограмм и линейных графиков. Человек сразу понимает, какой столбик диаграммы длиннее. И какая точка выше остальных на точечной диаграмме. Точки и линии — это хорошо.

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

=> Любые 3D-объекты под запретом. Трехмерность на плоскости — гарантированное искажение и объекта, и его восприятия.

=> Цвет не может быть самостоятельным способом выделения объектов, потому что у человека нет предустановленных связей цвета и количества. Синее больше красного? Или красное больше? Цвет работает только вместе с другими способами выделения: все точки над прямой коричневые, а под ней — зеленые.

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

Тут можно подписаться на мой телеграм-канал.

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

Вот моя рабочая схема интервью.
1. Поздороваться, представиться.
2. Дать тест и уйти на полчаса. Тест — 2-3 вопроса. Никаких абстрактных задач «на логику». Тестировать нужно только реальные навыки, которые критичны для будущей работы. Я проверяю умение писать по-русски (или по-английски) без диких ошибок и навык оценивания ресурсов в проекте.
3. Вернуться и обсуждать с кандидатом решение задач из теста. Это первая точка выхода из интервью: если кандидат совсем не годится, можно с ним доброжелательно попрощаться.
4. Задать два-три теоретических вопроса, обсудить ответы кандидата. Что такое проект? Чем продукт отличается от проекта? Что такое риск? Какие бывают стратегии реагирования на риск?
5. Проверить способность задавать вопросы: предложить кейс, в котором не хватает данных для ответа. Убедиться, что кандидат это понимает, не боится и умеет задавать вопросы. Это вторая точка выхода из интервью. Если кандидат не может задавать вопросы, и это нельзя списать на стресс, с ним пора прощаться.
6. Дать кейс по специальности. Кейс должен быть близок к будущим рабочим обязанностям кандидата. Лучше всего дать описание реальной рабочей ситуации и обсудить, как кандидат будет действовать. Это третья точка выхода: если и ее прошли, то интервью надо довести до конца.
7. Еще один-два кейса по специальности.
8. Провокационный вопрос. Вежливо поставить под сомнение любое утверждение кандидата из обсуждаемого кейса. Посмотреть, как он будет отстаивать свою точку зрения.
9. Вопрос про ожидания. Как кандидат видит свою идеальную работу, как устроен его день, какие задачи он решает, с кем и как работает? Интересно, что же действительно важно для кандидата и есть ли у нас такое.
10. Вопросы про размеры вознаграждения и его структуру.
11. Ответить на любые вопросы кандидата.
12. Попрощаться, поблагодарить за интервью, рассказать о дальнейших вариантах развития событий.

Интервью лучше проводить после встречи кандидата с HR — тогда у вас меньше шансов напороться на неадекватов.)
Тут можно подписаться на мой телеграм-канал.

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

Это вызов: задается высокий уровень ожидаемого качества и пользы. Если пользы нет, то после начального периода люди просто удалят приложение.

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

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

Все остальные варианты меня либо дико раздражают, либо просто не работают.


Тут можно подписаться на мой телеграм-канал.

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

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

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

Чтобы эскалация работала, надо следовать нескольким простым правилам. Простым, но обязательным.

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

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

3. Эскалация — это инструмент управления. Это не способ пожаловаться на кого-то и вылить на него ведро говна. Это способ решить проблему, когда все другие инструменты не работают. Этику, уважение к коллегам и здравый смысл никто не отменял. Обычно проще договориться. У вас в компании проще сразу эскалировать? Сочувствую.

4. Эскалация — это инструмент управления. Ей пользуются дозированно и последовательно. Не надо сразу бежать жаловаться к начальнику начальника вашего оппонента. За один раз — один шаг. А то наживете себе лишних недругов из тех, кого пропустили в своем порыве поиска истины. Оно вам надо?

5. Эскалация — это инструмент управления. Работает он с фактами, а не с домыслами. Желательно — с письменными фактами. Тогда вам тоже станет понятно: есть документированная проблема или чьи-то действия всего лишь не соответствуют вашим ожиданиям. Или, может, вам кто-то персонально не нравится? Это не повод для эскалации.

6. Эскалация — это инструмент управления. Ее не надо бояться. Менеджер не выглядит слабым, если эскалирует проблему. Он выглядит слабым, когда проблема неожиданно для всех всплывает, а о ней никто не знал.

7. Эскалация — это инструмент управления. Им надо уметь пользоваться. Чтобы уметь — надо учиться. И чтобы во время обучения люди не пострадали.

Тут можно подписаться на мой телеграм-канал.