Роман Колос – Partner и CTO DNA 325; Senior Project Manager в Dowell.
Рома – это воплощение слова flexible и человек-Agilе.
Практик, который прошел путь от UI дизайнера до CTO.
Рома сейчас Вы СТО. Расскажите как начинали и как выросли до этой роли.
Я начинал с работы аналитиком, нужно было делать технические задания и мокапы. Поскольку это был аутсорс, то это был больше Project Management, но когда в компании начали появляться свои проекты – Product Management.
У меня было мало проектов, где были обе эти роли и их выполняли разные люди. Хотя по сути у них прямо противоположные задачи. Project Manager и Product Manager должны конфликтовать и из-за этого рождается успех проекта. Product хочет чтобы все было сделано идеально и ему плевать сколько это займет времени.
Хороший Product – тот, который достигает каких-то целей в виде KPI. Project Manager хочет как можно проще и в оговоренные сроки.
Конечно, это мешает работать, когда ты выполняешь обе функции: например, хочешь сделать идеальный продукт, но начинаешь резать функционал в угоду тому чтобы выполнить KPI не по функциональности продукта, а уложиться в сроки. У тебя есть KPI и продукта, и проекта, и они взаимоисключающие. Я часто переобуваюсь в воздухе: в начале проекта во мне преобладает Product Manager, ближе к концу – Project Manager, а в середине они борются.
Что нравится в работе Project Manager-а?
Работа с программистам и решение сложных логических задач. Мне не интересно заниматься проектами, которые я прекрасно знаю, как выполнять. И меня привлекали и привлекают на проекты, где нужно разбираться с чем-то новым: либо технологически, либо придумать новый продукт на рынке. В остальном, PM – это операционист, который обеспечивает работу проекту по раннее утвердженному роадмапу в сроках.
Когда ты управляешь людьми, а не ресурсами, они преподносят много нового и ими нельзя управлять через инструментарий. Люди всегда приносят хаос. PMство – это всегда работа с рисками, ты всегда должен быть готовым к факапу. Это нормальное состояние,когда все горит и идет не по плану. Если все идет по плану, то тебе дадут второй проект.
Тогда насколько глубокими должны быть технические знания PM?
Они должны быть на уровне понимания того как работают технологии, которые применяются на проекте, понимание самой архитектуры проекта, но не на уровне кода, не нужно уметь делать это самостоятельно. Project Manager должен правильно прогнозировать сроки и сложность выполнения. При разговоре с Product Manager-ом или Product Owner-ом я должен дать ответ сразу, а не бежать к разработчикам, писать им ТЗ и ждать ответ 4 дня. Это роль Project Manager-а в продуктовой компании, потому что в аутсорсе ты говоришь не только сроки, но еще и деньги.
PM по-настоящему становится PMом когда может говорить сроки и деньги – организовать работу занимает 80% времени, но только 20% сложности. Product Manager-у не обязательно знать технологии, он приходит к Project-у и говорит, что он хочет и как он хочет. Project Manager набирает команду и выбирает технологии. Product Manager – это больше про маркетинг и про UI/UX. Он контактирует с инвесторами и аналитикам, для него приоритет прибыль и конверсия.
Можете уточнить, какая роль y Product Owner?
Это более высокоуровневая роль, PO не дает команде уйти в сторону от основной цели или идеи продукта. Например, мы начали работать над некой СRМ, PO не должен сидеть и думать, где какая кнопка, это работа Product Manager. Product Owner смотрит ориентируемся ли мы на В2В или В2С, общее направление куда мы двигаемся. PO не должен решать проблемы на низком уровне, он стратег и всегда думает на несколько шагов вперед.
А в чем собственно заключается роль СТО?
В каждой компании по разному. В аутсорсе – это человек, который должен уметь ответить на любой технический вопрос. Грубо говоря, начальник всех PMов. СТО привлекают, когда на проекте начинаются проблемы, именно он поджигает бочку, на которой сидит PM.
Какими метриками вы руководствуетесь при оценке команды?
Несколько метрик которые сложно представить себе в виде KPI:
- Насколько легко сотрудник справляется с новой/неизвестной задачей;
- Насколько сотрудник способен принимать самостоятельные решения (хотя бы мелкие) руководствуясь своим ИМХО;
- Насколько точно сотрудник оценивает сложность будущей задачи и ставит сроки.
По сути это всё. Но это не мерило плохой/хороший. Это просто характеристики. Есть программисты, которые всегда пишут медленнее других и не выдерживают сроки, которые сами и установили. Просто это нужно учитывать при распределении задач на проекте и не давать им критические задания по времени.
Предсказуемость – основной критерий при оценке сотрудника.
Какие показатели, по Вашему мнению, являются ключевыми для продукта?
Для Project Manager KPI одни:
- сроки реализации фич
- скорость работы
У Product Manager другие:
- конверсия,
- удержание
у Product Owner третьи:
- стоимость команды,
- support,
- время выхода на безубыточность.
Эти KPI нельзя смешивать вместе.
Какие методы расстановки приоритетов вы используете?
Есть список фич которые мы утвердили в MVP – значит они должны быть реализованы. А порядок имплементации зависит от конкретики. В проекте все связано и следующую фичу часто сложно реализовать без реализации предыдущей. В целом все реализуется от “основной фичи продукта” и потом доделываются второстепенные.
А что насчет приоритезации bugs fixing по сравнению с новыми features?
Есть критические баги, которые блокируют возможность использования продукта – они с наивысшим приоритетом. Далее по согласованию с Product Owner. На стадии разработки 80% времени на новый функционал и 20% на багфиксинг, после релиза – наоборот.
Как Вы планируете риски?
Обычно все думают, что планирование рисков начинается и заканчивается с простой формулы “сроки умножить на 30%”. Работа с рисками этим не ограничивается. Да, эти 30% надо заложить, потому что обязательно что-то пойдет не так.
При этом нереально избежать всех рисков. Так что прикидывайте шанс возникновения риска, степень боли, которую принесет этот риск и если можете придумать что-то простое и сделать сейчас, чтобы потом снизить ту боль, которая произойдет то ставим это в план. Это касается как функционала в проекте, так и выбора технологий, так и состава команды.
Как контролируете качество?
Контроль качества – это KPI качества, а именно жалобы клиента. Главное, чтобы клиент был счастлив.
А что насчет soft skills?
Я видел разных PM-ов. Я дружу с людьми, кто-то доминирует и бьет палкой, а кто-то манипулирует жалостью. У каждого свой подход и у каждого подхода свои плюсы и минусы. Не могу сказать что какой-то лучше или хуже. Важно уметь PMить самого себя.
Что не нравится в работе Product Manager-а?
Последняя фаза, когда заканчивается процесс создания чего-то нового. Мне становится дико скучно и я спрыгиваю, когда проект отрелизился и перешел в стадию support. Его отдают другому ПМ-у, а я беру следующий.
Вернемся к началу. Человек приходит к Вам с идей. Какие шаги ее реализации?
Сначала понять чего заказчик действительно хочет, что в его голове лежат адекватные сроки и сложность выполнения, без этого нет смысла углубляться в проект. Когда заказчик приходит он же еще не знает, что сколько стоит и это моя задача посчитать.
Главная задача PM показать PO что ты понял его идею, и на первых встречах уже описать своими словами как будет выглядеть продукт и какие в нем будут фичи. Тогда он может поверить тебе, понимая что вы на одной волне и это стреляет. Чтобы стать Product Manager надо уметь заканчивать невысказанную мысль Product Owner.
Что рекомендуем почитать?
- Founders at Work: Stories of Startups’ Early Days
- Thinking in Bets: Making Smarter Decisions When You Don’t Have All the Facts
- The Art of Systems Thinking: Essential Skills for Creativity and Problem Solving
- Теория Решения Изобретательских Задач
Где рекомендуем учиться?
- IAMPM Productman
- GoPractice
- Для PRO – Reforge