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

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

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

1. Методологии

   

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

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

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

   Я думаю, все методологии знать необязательно. Главное — выбрать то, что работает хорошо именно для вас.

2. Фреймворки

   

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

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

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

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

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

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

3. Техскилы

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

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

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

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

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

По сути, менеджер любого проекта — это настройщик одного и того же процесса:

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

Все, о чем мы говорили выше, это размышления на тему, какие методы и лучшие практики выберет тимлид для того, чтобы эти 4 пункта были сделаны технически верно.

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

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

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

Посмотрим на них более подробно.

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

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

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

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

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

   В проекте такие отношения также подразумевают под собой четко описанные правила работы. Я не про бюрократию. Например, если команда нашей компании ^[2] работает с тикетами, у нас должна быть инструкция для работы с ними, открытая и понятная для сотрудников и клиентов. Не потому что мы без неё работать не сможем, а потому, что договорённости между всеми сторонами должны быть прозрачны.

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

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

   

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

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

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

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

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

3. Умение мотивировать

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

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

   Как и хороший продажник, хороший менеджер это скорее тот, кто умеет дослушать и услышать, чем тот, кто долго и заливисто говорит. Для меня один из главных инструментов работы с мотивацией – квартальные беседы, о которых я писала статью раньше ^[3].

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

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

Литература про мотивацию:

1. Слава Панкратов. Черная книга менеджера.
2. Как пасти котов. Наставление для программистов, руководящих другими программистами.
3. Ли Яккока. Карьера менеджера.

Автор: Fkleto4ku ^[4]

Автор: ICLServices

Источник ^[5]