Историческая справка
Лет десять назад в IT начали привыкать к наличию менеджеров проекта в команде (изначально разработчики протестовали против того, что им подсовывают каких-то менеджеров, просят ходить на совещания, делиться прогрессом и проблемами с командой — да и сейчас есть менеджерофобия во многих компаниях, но она уже пониже).
И тут же, конечно, когда одно напряжение ослабло, появилось новое. Стало недостаточно крутым быть менеджером ПРОЕКТА. Много стали писать и говорить о том, что от проектов надо бы переходить к продуктам — дескать, это сложнее и интереснее, больше пользы бизнесу и больше славы менеджеру.
На уровне конкретных компаний это могло выглядеть как разделение ролей между бизнесовым менеджером и техническим менеджером, при этом первый отвечал за верхнеуровневые стратегические вопросы вроде бюджетирования, стратегии, аудитории, общался с директорами и инвесторами, а второй брал на себя, наоборот, более низкоуровневые вопросы, сроки разработки, ведение планов, перекрытие отпусков ответственных за куски работы другими людьми.
В таком раскладе условный менеджер продукта отвечал за то, зачем нам это делать, что мы делаем и кому это нужно, а условный менеджер проекта — за то, кто это делает, как это будет сверстано и когда мы всё докатим на продакшн.
Можно также увидеть, что область ответственности менеджера по продукту пересекается с маркетингом, бизнес-анализом, корпоративным лоббированием и презентацией идей. А область ответственности менеджера по проекту пересекается с рабочими областями тимлидов разработки, аналитиков и скрам-мастеров.
(дисклеймер для тех, кто срочно хочет поспорить: я пишу о собственном опыте про среднее из того, что повидала в десятке IT-компаний за 15 лет. Конечно, ваш опыт может отличаться — напишите о нем в своем блоге, это здорово повысит разнообразие контента. Но ваш опыт не отменяет моего, а я пишу, конечно, о своем)
Конечно, конкретный передел власти зависит от конкретной компании. Где-то один человек будет вынужден (и сможет) заниматься обеими частями: и тем, что и зачем, и тем, как и когда. Где-то первую часть на себя возьмет директор по продукту или тимлид группы, отвечающей за направление. Где-то вторую часть возьмет на себя аналитик, а менеджер будет отделен от исполнителей, ему останется чертить таблички и строить графики.
Именно поэтому я совершенно уверена, что «менеджер» ничего не обозначает. Что конкретно понадобится от человека на месте, будет зависеть от того, 1) что сейчас провисает в команде и компании и 2) какие сильные стороны может предложить человек. Круто, когда эти штуки совпадают. Но первое часто не очевидно ни на собеседовании, ни в первые недели и месяцы работы.
Определения
Мне кажется, что менеджер — это человек, который отлично выносит постоянную неопределенность и умеет быстро, гибко и постоянно перестраиваться в зависимости от вводных, а также живет в хорошем контакте с реальностью и умеет договариваться с окружающими.
А вот чем он управляет — зависит от обстановки за бортом.
Если отталкиваться от объективных определений, получится так.
Проект — это что-то, что ограничено по длине сроком, у чего есть известный нам заказчик и ресурсы и что отдано нам в ответственность.
То есть:
- проектом не может стать что-то бессрочное, проект конечен и его цель — достичь финальной точки
- что конкретно мы делаем, в какие сроки и зачем — уже известно (или можно решить до начала работ) и есть тот или та, кто имеет право принимать эти решения и принимает их (заказчик)
- кто выполняет работу в проекте — тоже известно. Мы имеем право нагружать задачами этих людей и они будут это делать (исполнители)
- мы имеем право интересоваться ходом работ, нас знают как ответственных лиц и с вопросами придут к нам (менеджер)
У проекта обычно можно выделить этапы. Некоторые этапы должны идти последовательно, если результат одного нужен для выполнения второго (или если их делает одна и та же команда), а некоторые можно пустить в параллель или отложить до лучших времен.
Этап обычно состоит из набора задач. Задача — это понятный отдельный кусок работы, у которого есть исполнитель, сроки и ТЗ (техническое задание: описание проблемы и предполагаемое решение. Что сейчас не так и что надо сделать, чтобы стало лучше).
Детализация ТЗ зависит от профессионализма исполнителя, от его глубины знания проекта и от того, насколько ему доверяет человек, который ставит задачу. Это может быть точное описание нужного решения или подробно расписанная проблема, то есть выбор оптимального решения может быть оставлен исполнителю. Но зафиксировать задачу в любом случае нужно, чтобы проще было принимать и обсуждать результат.
Задачи в составе этапа можно выполнять равномерно и последовательно (такой подход называется waterfall: когда «сошлась», как говорят в IT, первая задача, можно сесть за вторую), а можно обратиться к модной в последние десятилетия гибкой методологии и формировать внутри этапа «спринты» длиной в неделю или несколько недель.
Перед спринтом оценивают ресурсы: команду, доступное внутри него рабочее время. И стараются реалистично набрать задачи, которые за этот период можно выполнить. После спринта проводят ретроспективную оценку, насколько хорошо получилось на этот раз и какие выводы стоит сделать в следующем спринте. И снова планируют.
Спринтами, например, работают в компании Basecamp, о которой написано много (довольно рекламных, но бодрых) книг:
Продукт — это некая полезная штука, у которой нет финальной точки. Ее нужно развивать или поддерживать. По ее успехам можно строить графички.
Например, мобильное приложение — это продукт, а запуск мобильного приложения — проект. Сделать интерфейс для мобильного приложения — один из этапов проекта. Нарисовать кнопку — задача в этом этапе, которая выдана дизайнеру.
Менеджер может отвечать за продукт или направление, объединяющее в себе несколько продуктов. В таком случае оценка его работы часто зависит от ключевых показателей эффективности этих продуктов.
В творческих и личных областях
Если переложить это всё на творческие проекты и личные затеи, получится, что чаще всего вы сами себе заказчики (а поначалу и сами себе исполнители). Продукт — это то, что вы создали и поддерживаете, а проекты — это крупные куски создания или допилки этих продуктов (запуск, редизайн, настройка рекламы — всё, что имеет конечную точку в духе «вот теперь стало хорошо»).
Проект, как правило, можно расписать в документе с подзаголовками «Проблема», «Решение», «Сроки», «Этапы», «Исполнители», «Результат» — когда вы пропишете все шесть разделов для конкретного проекта, станет понятно, кто и что будет делать, зачем это всё нужно и что ожидается к какому сроку.
Не все проекты можно разбить на этапы, иногда есть только один этап. Но все этапы (или, если этап один, то сам проект) можно разбить на задачи.
Каждая конкретная задача — это кусок работы, который дальше можно запланировать в Гугл-календаре на среду после обеда или взять к обсуждению с коллегами. Чтобы приступить к работе, нужно разгрызть проект на задачи (этапы — опционально).
Про задачу можно сказать следующее:
- что конкретно должно получиться (название задачи)
- есть ли дедлайн
- подробное описание, ссылки, референсы, черновики
- кто будет делать
- от чего зависит эта задача (что должно быть, чтобы её сделать)
- что зависит от этой задачи дальше (что может произойти после этого)
Например:
- пост в инстаграм про варенье
- к понедельнику, чтобы можно было поставить в планировщик
- черновик — в Эверноте
- делегирую Фаине
- нужно заранее подготовить фоточку с вареньем, текст будет зависеть от вида варенья
- когда текст будет готов, можно будет открыть планировщик и расставить посты на неделю вперед
Да, так расписать каждую задачу — это отдельная задача! Кажется, что гораздо проще держать всё в голове. Как сяду, так и сделаю. Чего заранее расписывать?
Так, да не так. Во-первых, пока расписываешь, оказывается, что в голове всё выглядело таким понятным, а по факту нужно ещё многое решить и выбрать.
Во-вторых, если потом эти задачи нужно делегировать, по-любому придется расписывать подробности.
В-третьих, не все задачи такие короткие, как пост в инстаграм (написать который может быть быстрее, чем задачу оформить).
И в-четвертых, обдумывание задач помогает выделить взаимосвязи между ними. Если задача про пост зависит от фоточки, значит, нужно придумать, как до понедельника ещё и фоточку найти. Если эта задача должна быть готова перед планированием постов на неделю, дедлайн вырисовывается сам собой.
Списки задач можно держать где угодно: на Post-it стикерах на стене, в Ноушне или Эверноте, в Гугл-документе или файле в Ворде, да хоть на салфетках.
Неважно, где всё записано. Важно, чтобы это можно было окинуть взглядом и ответить на типичные вопросы менеджера.
Понимаем ли мы, что, как, зачем, какими ресурсами и для кого делаем?
Знаем ли мы, что нужно сделать в какой срок, и успеваем ли мы?
Видим ли мы взаимосвязь между задачами, их условный порядок, чтобы расположить их в календаре не случайным образом, а последовательно и удобно, чтобы ничего не искать полчаса, а взять уже приготовленное?
Верим ли мы исходя из этого в сроки, с которыми согласились, или их нужно подвинуть вперед, чтобы задачи комфортно вписались, или выкинуть какие-то задачи из ближайшего плана?
Когда будет следующая точка сверки, к которой мы подойдем с результатом очередного этапа и накопленным опытом, чтобы пересмотреть ожидания, сравнив их с реальностью?
Интересно.
А чем тебе самой управлять больше нравится — проектами или продуктами? Или не заметна разница?
Спрашиваю, потому что я хороший менеджер проектов (в твоей терминологии) и отвратительный менеджер продуктов. Внутри себя я всегда это называла «хороший второй и отвратительный первый». Мне не нравится решать ЧТО делать — я вижу много альтернатив одинаковой ценности, и выбирая одну — чувствую, как убиваю другие; это больно.
…Работу я подобрала «по специальности» — я учитель. Продуктом учителя (если глобально, не в деталях) является ребенок:)) Но поскольку ребенок человек, то он сам свой продукт — а учителю остается работать менеджером проектов:))
Ох, мне трудно согласиться, что ребенок — это продукт учителя. На мой взгляд, продукт учителя — это образовательный процесс. Ребенок — это клиент, а ещё точнее, родители ребенка — клиенты. Школа как инстанция — это посредник, отвечающий за гладкость процессов и взаимозаменяемость учителей по необходимости.
В таком случае проект учителя — это «1 А 2019/2010», то есть процесс учебы конкретной группы детей на протяжении учебного года. Я вижу так.
Отвечая на твой вопрос, разница для меня не просто заметна, а она полностью перекраивает всё пространство. Когда я управляла проектами, я общалась с одними людьми и заполняла одни пустующие места в окружающем мире, а когда продуктами, всё было настолько иначе, что это прям совсем другая жизнь.
Наверное, увлекательнее всего для меня всегда было руководить отделом. То есть управлять группой менеджеров.
Но это было и наиболее загрузно. Проще всего было менеджерить один-два проекта.
То есть со сроками и задачами, конечно, работать проще, чем с топ-менеджерами и инвесторами. Но и поскучнее (в том числе в хорошем смысле — то есть остаются силы и на что-то ещё).