Читать книгу Разумный метод управления - Юрий Валентинович Гугнин - Страница 3

Перед тем, как что-то делать, стоит ответить себе на вопросы: «зачем это делать?» и «как это делать?». По поводу роли менеджера проектов уже много лет ломаются копья в литературе и в социальных сетях (здесь и далее я считаю, что менеджер любого уровня фактически является проектным менеджером, потому что развитие бизнеса или подразделения – это тоже проект).

Основные вопросы, которые мучают спорщиков:

– что входит в роль менеджера?

– должен ли менеджер хорошо разбираться в технологиях?

– нужен ли менеджер вообще?

Что входит в роль менеджера проекта?

Основные зоны ответственности, которые входят в роль менеджера:

– лидерство;

– управление клиентом;

– управление командой;

– управление продуктом;

– управление рисками по срокам, бюджетам и ресурсам;

– документооборот;

– администрирование рабочего процесса.

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

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

Скорее всего, так получается, потому что создание проекта – командная игра. Идеальная команда кросс-функциональна, как хорошая команда регбистов или спецназовцев. Понятное дело, что 100 % кросс-функциональности достичь очень трудно и дорого (да и вообще, каждый человек индивидуален). Но двигаться в этом направлении весьма полезно.

В чем суть кросс-функциональной команды? В том, что качества и роли распределены по игрокам более-менее равномерно. Например, в баскетболе: да, в команде может быть один самый опытный защитник, но если он вдруг в отпуске, заболел или просто задержался «в нападении», остальные игроки могут достойно выполнить его функцию и отразить атаку, пусть и не так филигранно. Говорят, самые яркие примеры кросс-функциональности – команды в регби. Там каждый игрок должен хорошо играть на любой позиции.

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

Опять же, повторюсь: совсем не обязательно, чтобы все менеджерские роли в проекте выполнял один человек. Роль менеджера может быть распределена по команде, и это нормально. Главное, чтобы все зоны ответственности были закрыты.

Должен ли менеджер проекта хорошо разбираться в технологиях?

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

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

Нужен ли менеджер вообще?

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

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

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

Конечно же, я не сам это придумал. Меня вдохновил пример трех великих компаний: Valve, Gore и SemCo. В списке литературы есть ссылка на руководство для новичка в компании Valve, а про Gore и SemCo много информации в интернете.

О продюсерах

Меня очень часто спрашивают, кто такой продюсер и чем он отличается от менеджера. На мой взгляд, продюсер – это человек, который умеет превращать идею в готовый продукт. Например, определение термина «продюсер» в киноиндустрии: создает условия для создания фильма. Он вовлекает в проект людей, находит финансирование, делает все необходимое от этапа идеи для запуска проекта. Например, Тимбалэнд – это продюсер, Ричард Брэнсон – продюсер. Таким образом, менеджеры, работающие на проектах в агентстве или на стороне клиента, не могут называться продюсерами: они просто осваивают готовый бюджет за счет умения распределять ресурсы и контролировать ход выполнения задач.

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

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