Project-менеджер | IT

Кроме моей основной любви к инфре и виртуализации, давно увлекаюсь темой product менеджмента периодически почитываю соотвествующие материалы, но заметил что уже достаточно долгое время пост Владислава Носковца с примерами тестовых заданий на позицию Product manager висит в топе выдачи (на Гугле, на Яндексе так вообще портал в ад октрывается), а новых, что-то не появляется. Да и не особо легко найти примеры структурированных решений. В этой статье я хочу решить один кейс из его подборки (No5. Mos.ru), параллельно решая несколько задач, во‑первых — привлечение комьюнити к обсуждению, было бы супер если более опытные коллеги оставляли ссылки на полезные материалы для джунов. Во вторых — хочется услышать конструктивные комменты на мой подход к решению этой задачи, что опять же поможет начинающим лучше понять тему.

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

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

Я неоднократно сталкивался с ситуацией, когда компания сначала инициирует новый (конечно же, очень важный) проект и только потом понимает, что все проектные менеджеры уже на 100% загружены. Но проект запущен, спонсор/заказчик обозначает дедлайны, тормозить никто не собирается. Компания выходит на рынок труда и открывает подбор на позицию проектного менеджера. Пока ищет, может пройти несколько месяцев. За это время уже сформируется гора операционки, документации и задач в бэклоге.

Есть у меня на работе один проект в котором есть маленькая фича — таблица параметров, где чётко написаны все названия (входные) по всем чихам заказчика и эти названия обязаны соблюдать и заказчики и исполнители (программисты). И таблица эта существует в двух экземплярах — у заказчика и у исполнителей. Как только заказчик что-то хочет, то сразу вопрос — что из существующих параметров использовать или добавляйте новые. Заказчик тему просёк и уже сам приносит таблицу и говорит — вот новая таблица параметров, вот расчёт на основе этих параметров (даже в Excel можно писать формулы с этими параметрами). В работу такое принимается часто в тот же день и так же быстро делается. Сроков никто специально не ставит, потому что исправления чисто статистически делаются до двух дней, а часто и раньше.

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

В далеком 2020г. medium еще не был заблокирован, а я отчаянно волонтёрил в московском отделении PMI на правах розжига инициатив, способствующих профессиональному росту членов сообщества по управлению проектами. С тех пор много воды утекло: стучаться через занавес становится сложнее, а рекомендовать просящим что-то «почитать полезного» потребность осталась.

Аннотация книги Марти Кагана «Transformed — Moving to the Product Operating Model». Каган — один из наиболее ярких IT-менеджеров в Кремниевой долине. В своих статьях и книгах он разбирает менеджмент таких гигантов, как Amazon и Spotify, описывает свой взгляд на ведение бизнеса, а в этой книге объединил весь этот опыт и представил самостоятельную «инструкцию» по трансформации работы над продуктом.

Лидер стремится вдохновить людей, дать им возможность пробовать и ошибаться, чтобы научиться. А менеджер, напротив, минимизирует риски, требует соблюдения плана и жёстких сроков. Лидер говорит: «Давайте попробуем, научимся на ошибках, посмотрим, как это сработает». А менеджер говорит: «Нам нельзя рисковать. Нужно сделать так, как проверено и безопасно». И вот тут вы, как руководитель, оказываетесь в состоянии внутреннего конфликта.