Руководство по управлению проектами и командами в ИТ

Оглавление:

Личный опыт или "что я знаю про управление проектами"
Классификация менеджеров и руководителей
Project Management (управление проектами)
[WIP] People Management (управление людьми)
[WIP] Product Management (управление продуктом)
[WIP] Тренды в IT или особенности работы с дата-проектами
Рекомендуемая литература

Опыт работы в компаниях разного размера и профиля: фриланс (Web разработка), стартапы, малый бизнес (основатель и директор BigData Team), средние и крупные компании (Yandex, Amazon AWS), гос. сектор и около (ВУЗы, корпоративные университеты, НКО/АНО);
Опыт работы в разных ролях: разработчик, аналитик, руководитель, консультант. Профиль на LinkedIn;
Опыт реализации крупных проектов от идеи дозапуска, развития и поддержки: англоязычная специализация "Big Data for Data Engineers", разработанная при партнерстве с Yandex, собрала более 100,000 слушателей по всему миру до ухода Coursera из России;

В сообществе менеджеров царят настоящие страсти. Бывают HR менеджеры, бывают Sales менеджеры, бывают даже Cleaning менеджеры, но чтобы не растекаться мысью по древу остановимся на менеджерах в IT.

По опыту работы в Amazon, у меня сложилась картинка о трех видах PM и неформальных руководителях:

Project Manager (менеджер проекта)
People Manager (руководитель команды)
Product Manager (руководитель продукта)
Team/Tech Lead (тех. лид)

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

Project Manager - это менеджер, который отвечает за реализацию конкретного проекта. У проекта есть поставленная цель, KPI (метрики качества), ресурсы (бюджет, команда) и ожидаемые сроки.

People Manager - особый зверь, редко встречаемый в чистом виде в реалиях российского бизнеса. Это человек, который отвечает за рост и психологическое состояние членов команды. В американских компаниях, члены команды подчиняются непосредственно ему (direct reports). В российских эту роль выполняют (или должны выполнять) HR-менеджеры, которые находятся в смежной структуре и, по факту, не влияют на распределение проектов и KPI сотрудников.

В списке определений выше, я сделал вольный перевод People Manager - "руководитель команды". В моем представлении, независимо от ожиданий работы HR-менеджера, если у вас есть подчиненные, то это ваша зона ответственности распределять проекты, выставлять KPI и работать "над" командой.

Product Manager - директор стартапа внутри компании. Уникальная возможность пройти весь жизненный цикл продукта (идея, реализация и запуск, развитие и поддержка) без необходимости открывать собственную компанию и брать на себя риски предпринимателя. Вы отвечаете за продукт:

определяете что нужно клиентам (market research)
определяете бизнес-модель и содержание продукта для удовлетворения клиентской потребности
определяете как о нем рассказать клиентам (sales & marketing)
согласовываете ресурсы (финансовые, инфраструктурные, человеческие ресурсы), сроки реализации и KPI
отвечаете за запуск и проверку market fit

Выше я отдельно выделил Team/Tech Lead - это (ясен пень) крутой технический специалист. Он(а) отвечает за стратегию развития ИТ продуктов команды (или компании). Если такой специалист, не хочет развиваться по ветке менджмента, то это прекрасная альтернатива. Совсем без soft skills, конечно, не обойдется, но требования на качество коммуникации и кунг-фу управления проектами сильно ниже.

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

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

Теория (мат. часть)

С точки зрения реализации проекта менеджер может повлиять на сроки реализации (time), на стоимость реализации (cost), на качество (quality) и функциональность (scope).

Многие книги или заметки по управлению проектами обычно используют всего три фактора: time, cost и scope. В этом случае, в определение функциональности (scope) зашивают качество (quality), к сожалению, не всегда хорошее. Пример:

Шеф, мы сделали функциональность подписи электронных документов (ЭДО)
Работает?
Да, но через раз, иногда пользователю нужно будет 5 раз попытаться загрузить документ. А если пользователь пытается загрузить документ после 20:00, то мы пишем письмо с рекомендацией попробовать на следующий день в рабочее время.

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

Вернемся к вопросу управления проектами (project management). Для реализации проекта менеджер должен уметь отвечать и держать на контроле всего три (казалось бы) простых вопроса: кто (сделает, cost), что (сделает, scope) и когда (сделает, time).

В ИТ, как и в жизни, единственное, что в постоянно, это изменения. Ответы на эти вопросы со временем будут меняться:

кто-то заболел и продолбал дедлайн - поехали сроки (time);
хотим поднажать и успеть к определенной дате - добавляем ресурсы (увеличиваем cost) или уменьшаем функциональность (scope) продукта;

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

Наглядное пояснение применимости разных методологий

В первом случае мы фиксируем scope (пример - построение космического аппарата по заданной спецификации). Скорее всего мы не будем укладываться в бюджет и/или сроки, когда что-то пойдет не по плану. В этом случае гуру менеджмента рекомендуют использовать методологию "Waterfall" (каскадная модель или модель "Водопад");
Во втором случае, наоборот, мы фиксируем бюджет и сроки, но тогда функциональность конечного продукта (scope) может меняться. В этом случае используются "гибкие" методологии (Agile).

Наглядное применение Agile (1 мин)

В ИТ, в большинстве случаев :

уже есть фиксированная команда (cost)
довольно динамично могут изменяться реалии рынка или требования (хотелки) клиентов

Поэтому дополнительно к cost удобно зафиксировать сроки (time) и жить в рамках гибких методологий (Agile). Мы будем двигаться быстрыми итерациями (обычно 2-х-недельными) и на каждой итерации реализовывать новый элемент функциональности (scope) продукта.

Сложно найти хорошого проджекта, который не знаком с Agile и ритуалами фреймворка Scrum: стендапы, демо, ретро и планирование. Я специально называю их ритуалами, поскольку многие живут ритуалами, не познавая глубинного смысла. Далеко ходить за примером не надо. Я сам, работал в Rambler, Yandex, Amazon AWS и жил по ритуалам Scrum и Kanban более 5 лет. Познать глубинный смысл мне удалось только тогда, когда я стал предпринимателем, собрал команду и начал вести проекты по разработке с очень ограниченным бюджетом.

Проверь себя (часть 1)

Я подготовил лакмусовую бумажку (несколько простых вопросов) для проверки понимания глубинного смысла. Можете себя проверить:

Сколько времени длится ваш стендап? Если на стендап тратится больше 1 минуты на члена команды, значит вы проводите его неправильно.
Какая цель и глубинный смысл каждого из 4-х ритуалов? Объясните, почему Scrum развалится, если убрать любой из его ритуалов.

Финальный вопрос:

Рубрика: полезные вопросы для собеседования на роль project manager'а

Технологии

Технологии спешат на помощь проджекту для контроля ответов на вопросы "кто" (сделает, cost), "что" (сделает, scope) и "когда" (сделает, time). Наборы таких технологий обычно называются Project Management Tools (примеры: YouTrack, Jira, Redmine, GitLab и добрая сотня других аналогов). Если вы владеете хотя бы одним, то легко разберетесь и с другими.

Рассказывать очевидные вещи про то, как создавать задачи и Agile Board'ы я не буду. Важные аспекты, на которые следует обратить внимание, на основе практики использования - ниже.

Если понимание глубинных ценностей ритуалов Scrum - это стратегическое мышление project manager'а, то правильное использование Project Management Tools - это тактические маневры. Какие скилы нужно прокачивать (или что важно не забывать настраивать в ваших инструментах):

"кто" - у каждой задачи должен быть единственный/главный ответственный в текущий момент времени. Если система позволяет иметь нескольких ответственных (assignee), то важно помнить, что общая ответственность = общая безответственность;
"что" - важно уметь прокачивать скил формулировки задач и требований (ТЗ). Полезные лайфхаки - прокачать скилл написания user stories и, так называемых, DoD (Definition of Done - четкая спецификация, что именно будет реализовано и каким образом это проверить);
"когда" - у каждой запланированной для реализации задачи должен быть дедлайн. Важно настроить уведомления или dashboard'ы с перечислением горящих или просроченных задач;

Проверь себя (часть 2)

Если вы пользуетесь Scrum, то вы также должны знать следующие термины, техники, инструменты, и уметь анализировать их вывод:

Burndown chart
Capacity
Критический путь
Диаграмма Ганта и календарный план

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

Project Management:

Мифический человеко-месяц. Фредерик Брукс. Пример из практики менеджера проекта по созданию одной из первых операционных систем: "привнесение в проект новых сил на поздних стадиях разработки лишь отодвигает срок сдачи проекта". Нельзя просто взять и докинуть человеко-ресурсов для более быстрого выполнения задачи;
Agile и Scrum, рекомендации книг для погружения от Андрея Симкина (руководитель ИТ-продуктов, МТС Диджитал).

People Management:

Книги Патрика Ленсиони - короткие и содержательные брошюры про отношение людей к работе и как вы на это можете повлиять (как сотрудник или руководитель);
Развитие лидеров: Как улучшить свой стиль управления и общаться с
носителями иных стилей. Ицхак Адизес. У Адизеса есть целая трилогия, эта последняя в этой серии и имеет практические рекомендации по общению с людьми разного профиля. Полезный инструмент - модель PAEI;
Жесткий менеджмент. Дэн Кеннеди. У меня довольно негативное отношение к книге, но несмотря на это, там все равно есть полезные заметки и примеры из реальной жизни;
Математические методы и модели в управлении, Шикин Е.В., Чхартишвили А.Г., 2000. В свое время я подрабатывал репетирством студентов экономфака МГУ. Мне очень понравилась книга и курс Шикина. Там разбираются мат. методы: имея общие цели, каким образом правильно расставить KPI на различные департаменты, использующие общие ресурсы. Много интересных мыслей и методов для расширения кругозора и использования на практике;

Product Management:

Бизнес без MBA. Тиньков О., Ильяхов М. Хороший ликбез по всем темам, про которые должен знать руководитель продукта (компании). Некоторые темы (например, "управление ожиданиями") являются обязательными для изучения для всех менеджеров команды BigData Team;
«Бизнес класс» — бесплатная программа развития бизнеса от Google и Сбербанка для начинающих предпринимателей и собственников бизнеса. Раньше была доступна в интернете, возможно еще можно найти где-то ролики на Youtube. Модуль про финансы (capex, opex, прямые и косвенные расходы, EBITDA и инструменты оценки проектов) - лучшее, что я где-либо изучал.

Полезные ресурсы: