Comments 14
Многое из написаного здесь специфично именно для заказной разработки. Если не трогать аспект people management (а это совершенно отдельная тема), а сосредоточиться на продуктовой разработке, то я бы добавил следующее:
Неуменее или нежелание думать о том, что нужно пользователю. "Это проблема продакт менеджера" - поверьте, это точно путь в никуда. На старших уровнях engineering management становится слабо отличим от product management - что естественно, потому что на самых верхних уровнях (executive management) эта разница зачастую исчезает вообще.
Стремление делать фичи, а не решать проблемы. Этот пункт тесно связан с предыдущим. Зачастую я вижу, как начинающие менеджеры пытаются питчить "фичи", не очень понимая, какую пользовательскую проблему они решают. Я помню фразу Генри Форда про более быстрых лошадей, но даже в создании автомобиля был четкий акцент на решение проблемы пользователей - пусть даже они не могут ее правильно сформулировать.
Желание получить полную, стопроцентную ясность "а что же мы все таки делаем?" до того, как написана первая строчка кода. Вот поверьте, так просто не бывает. 100% ясность может быть только если мы пытаемся скопировать фияу конкурента - и значит, мы уже опоздали на рынок. Умение жить в климате постоянной неясности, нечетких требований - и умение их постепенно прояснять - это критический скилл для senior management. На верхних уровнях менеджмента проблемы зачастую формулируются как "у нас что-то все плохо, а надо чтобы было все хорошо" - и это, к сожалению, не преувеличение.
На самом деле о менеджменте написано много, очень много книг. Своим менеджерам, как начинающим, так и опытным, я часто рекомендую книгу The Manager's Path - там есть ответы на многие вопросы. В то же время, я активно советую им изучать аспекты смежных профессий - например, если ваша работа завязана на активное взаимодействие с пользователем, изучение таких дисциплин как User Experience, UX Research и просто product management становится очень важным.
Когда-нибудь я соберусь с мыслями и напишу длиннопост на эту тему, но если интересно - готов пообщаться и поотвечать на вопросы.
Спасибо за дополнение!
В основном мы занимаемся заказной разработкой, поэтому многие выводы пришли именно из "заказного" опыта. Но если говорить про самостоятельного проджект менеджера в продуктовой компании, то думаю большинство пунктов будут актуальными, просто заказчиком будет продакт менеджер
Но насчет того, что важно думать что нужно пользователю соглашусь, как и с остальными двумя пунктами
У нас 100% внутренняя разработка, и я готов подписаться под всеми шестью пунктами.
По крайней мере, для крупной компании это очень даже актуально.
Спасибо, полезная статья
Кстати, мы активно нанимаем аналитиков-джунов, которые под руководством старших менеджеров будут расти в проджект-менеджеров.
А почему не аналитиков "сеньоров"?
Из-за специфики нашей деятельности
То что касается прям глубокого системного-системного анализа берут на себя техлиды, а глубокий бизнес анализ обычно берут на себя бизнес аналитики на стороне клиента
Поэтому мы пришли к тому, что целевая позиция аналитиков по мере роста - менеджер проектов, в которых проектирования больше чем коммуникации с кучей стейкхолдеров
А если брать синьеров аналитиков, то им негде будет разгуляться - технику взяли на себя наши техлиды, продуктовую часть продакты на стороне заказчиков, а управление проектом и принятие основных решений менеджеры
Думаю важен навык умения отходить от ТЗ, по мере завершения разработки. Гибкость
Часто наблюдал что заказчику на самом деле нужно не совсем то что он описал в ТЗ. И по мере завершения работ он начиная пробовать в деле продукт, наконец-то внятно озвучивает что именно он хотел.
Так же когда он получил некий минимум из ТЗ. Заказчик входит во вкус и начинает сыпать просьбами на новые фичи, которые ему реально и были нужны.
Последним предложением убили желание поделиться статьей внутри компании :(
Придется копипастнуть в простодокумент.
#2. Не пользуются календарём
Для крупной компании пункт выглядит малореальным - такие даже испытательный срок не пройдут, либо быстро научатся пользоваться.
А вот пункт "Не умеют назначать встречи" очень распространен среди новичков. Например:
Приглашают не всех, кого нужно или наоборот, лишних
Встреча без повестки, а ещё лучше - с непонятным названием и с непонятной целью
Назначают внезапно, а не заранее
6 ошибок, из-за которых менеджеры-джуны остаются джунами