3 важных и 3 очень важных навыка проект-менеджера

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

Обычно описывают последовательность действий, которая позволит сделать проект максимально эффективным способом: в срок, с тем функционалом, который необходим заказчику, и с минимумом телодвижений. Обычно внутри лежит идеологический пласт, такой, как Agile manifesto или lean practice. Иногда методология освещает только часть процесса, как, например, экстремальное программирование, которое говорит исключительно о том, как эффективно создавать код, не затрагивая правил общения с заказчиком или планирования. В любом случае, это не очень длинный, понятный алгоритм, как достичь поставленной цели.

Я сама люблю и применяю:

• Kanban доска для того, чтобы планировать работу с задачами на сервисе (Trello, кстати, очаровательный инструмент для этого);
• SCRUM для проектов разработки;
• Prince 2 для структурирования работы с заказчиком и финансами на проекте.

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

Коротенько расскажу, какие фреймворки про что.

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

ITSM и COBIT освещают процессы, необходимые при построении сервиса: первый с точки зрения тех, кто процессы ставит, второй с точки зрения аудитора.

TOGAF – про процессы, необходимые для управления компанией.

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

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

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

О них мы и поговорим дальше.

3 очень важных навыка, которыми менеджер проекта должен владеть, иначе с проектом все будет нехорошо, несмотря на отлаженные процессы и высокие технологии

1. Получить работу, проанализировать, запланировать.
2. Собрать и организовать людей.
3. Проконтролировать работу в срок и с нужным качеством.
4. Сдать работу.

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

1. настройка отношений доверия;
2. постановка задач;
3. умение мотивировать.

Доверительные отношения

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

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

• от сотрудников – делать вовремя релизы и присылать вовремя отчеты, раз уж вы вовремя платите им зарплаты-премии;
• от клиентов – вовремя отвечать на ваши письма и принимать решения;
• от себя – выполнять обещания.

И в тот день, когда расстроенный клиент прибежит ругать сотрудника за то, что он не вовремя закрыл тикет, вы откроете инструкцию и скажете: «Мы отвечаем за свои слова и тикет был закрыт в течение, скажем, 2-х дней. 2 дня по нашей с вами инструкции — это вовремя. Я вижу, что вы не довольны. Давайте обсудим инструкцию, если 2 дня — это много». В этот момент, как ни странно, клиент становится счастлив: он видит, что ситуацией можно управлять, достаточно создать и зафиксировать договорённости.

С кем нужно настраивать доверительные отношения? Я сейчас приводила в пример подчинённых и клиентов. Однако и ваш начальник, и ваши коллеги – все должны знать вас как человека, слову которого можно доверять.

Для чего это нужно?

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

Основные правила постановки задач таковы:

• по SMART. Тут не нужно длинных дискуссий, я думаю, теории много лет.
• по процессу или по результату, в зависимости от того, кто перед вами: новичок или проверенный кадр. По процессу для новичков объяснять поэтапно, как нужно делать. По результату – достаточно обрисовать, что должно быть сделано, доверив технические подробности профессионалу. В любом случае, совсем не лишне обозначить точки сверки с курсом – даты, когда вы встретитесь, чтобы понять, что все идёт по намеченному плану.
• на языке собеседника. У каждого человека есть любимый набор слов, который очень четко отражает его мыслительные процессы. Кто-то, рассказывая о проекте, говорит в красках о том, как они шли (процесс) к общей цели, кто-то отмечает чего удалось достичь (результат). Кто-то делает упор на классной команде, кому-то важнее технологии. Одни все время повторяют «смотри!», а другие чаще используют «слушай!». Человеку действительно проще вас понять, если вы будете использовать его слова.
• перепроверить понимание. К сожалению, что вы сказали и что человек понял — это две большие разницы. Правило для важных или объёмных задач — попросить человека пересказать услышанное, а ещё лучше прислать вам письмо с описанием задачи. Тогда, если он что-то недопонял, у вас будет шанс его сразу поправить.
• принять результат. Вроде бы очевидная штука, но бывает, что задачу тебе ставят, а потом как бы забывают принять. Делать что-то настолько неважное, что об этом ваш начальник может легко забыть, демотивирует хуже некуда. Так что важно не забыть.

Тема мотивации модная и раскрученная, в сети можно найти достаточно курсов, у «Стратоплана», у Гандапаса. Много книг написано про мотивацию. Мои любимые – в списке ниже.

По-моему, мотивация – штука, сильно похожая на продажи, как ни странно это звучит. Большая часть людей к чему-то стремится. Если человек ни к чему не стремится, стоит его потыкать палочкой – вдруг он умер. Если он не умер, не в глубокой депрессии и психически здоров, он чего-то от жизни хочет. Ваша задача, как и в продажах – поговорить с человеком и выяснить его потребности и стремления, понять, как ваш «продукт» (проект, задача) могут закрыть эти потребности и в итоге «продать». То есть дать ему ту работу, которую он будет делать с радостью и хорошо. Или отпустить, поняв, что «продукта» для этого «клиента» у вас сейчас нет.

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