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

Первое

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

Почему waterfall предполагает, что команда айтишников не способна общаться с тем, кто имеет представление о продукте? Ведь они все интроверты, им надо сидеть программировать и не отвлекаться…

Самое дорогое – это начать писать код. И особенно дорого это становится, когда вы пишете не то, что на самом деле нужно. Здесь мы приходим к главному плюсу agile подхода – прежде чем делать что-то, убедись наиболее быстрым и дешевым способом, а то ли надо делать.

Второе

Это такое глубокое погружение в предметную область, что тебе кажется ты вот-вот сам начнешь программировать под iOS или Android. Представьте, команда сидит программирует, у нее появляются вопросы и, конечно же менеджер идет всё уточнять у заказчика. Это ведь его прямые обязанности. Выясняет, приносит команде в клювике, а тут еще столько же вопросов появляется, ведь они не переставали в этот момент работать. А всем известно, чем больше ты на самом деле знаешь, тем меньше ты знаешь 🙂

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

Третье

Мы не решили главного: команда все еще делает не то. И основное, что меня действительно бесит, это уклонение от ответственности. Заказчик получает нечто расстраивается, что результат не совпал с его ожиданиями, и менеджеру приходится придумывать сотни объяснений, почему мы молодцы, ведь мы работали и кто на самом деле виноват. Упоминаем все, что приходит на ум:API, которое дали не вовремя, непринятый дизайн и т.д.

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

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

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s