Чему учить ПМа — подход

В этом году затеял запустить в EPAM годовую программу обучения для менеджеров проектов. Сейчас работаю над ее содержимым, ну и думаю всем остальным будет интересно и полезно узнать что вошло в нее и почему. В этом посте расскажу не только что будет в программе, но и почему оно там появилось. Итак, по порядку. По порядку рекомендую начинать составление программы не с набрасывания беспорядочного набора тем, «которые совершенно необходимо знать современному ПМу.» Начинать надо с того, кто такой ПМ и какую основную задачу он выполняет. В моем скромном понимании ПМ – это человек, который лично отвечает за успех проекта, который ему доверен спонсором. Лично отвечает. Для области software outsourcing успех – это достижение требуемого Заказчиком результата приемлемого качества в рамках ограничений времени и ресурсов для получения Спонсором прибыли. Еще раз - действительная цель деятельности менеджера – это получение Спонсором (условно – Работодателем) прибыли. Все остальное, даже достижение результата – вторично. Тот, кто в этом сомневается, пусть попробует сделать проект для своего Работодателя с нулевой прибылью. Если это не исключительный случай (например, получение нового «жирного» Заказчика, когда пилотный проект часто делается себе в убыток), то ПМу очень быстро (и зачастую очень жестко) объяснят что он не прав. Таким образом смысл существования ПМа – это обеспечить достижение требуемого Заказчику результата для получения Работодателем прибыли. Для того, чтобы ПМ мог успешно решить эту задачу, он должен организовать всю цепочку работ от извлечения концепции из головы Заказчика до финального разрезания ленточки на пущенной в эксплуатацию системе. Для этого он должен отстроить процесс на проекте. Отстроить процесс – это означает организовать взаимодействие аналитиков которые пишут требования с архитектором который задумывает структуру решения которую затем реализуют в коде разработчики которым нужен CM из которого CI выпекает билд который тестируют тестеры чтобы его затем поставили на staging деплоймент-инженеры после чего ПМ произведет общение с Заказчиком которым одобрит постановку очередного билда на production. Как легко догадаться, для того чтобы организовать работу каждого упомянутого в цепочке камрада надо быть по крайней мере настолько же специалистом в его области как и она сам. Соответственно первый набор знаний для ПМа – это устройство каждой из областей: Requirements, Development, Testing etc. Но есть нюанс. Означает ли то, что ты в совершенстве знаешь устройство лошади и можешь ее лечить то, что ты будешь классным наездником? Нет – знание устройства лошади поможет тебе использовать ее эффективно, но управлять лошадью не научит. Это отдельная дисциплина. В случае разработки софта действует этот же странный эффект – управление (езда на лошади) должно прилагаться к процессу разработки и его участникам (лошадь), и это второй набор знаний. Соответственно в него входят понимание мотивации, создание морального духа, разрешение конфликтов, формализация процесса и т.д. В принципе, этих двух наборов знаний уже хватит чтобы быть дееспособным ПМом (я называю это «able PM», как у британских моряков был ранг «Able Seaman»). Но просто дееспоcобный ПМ отличается от advanced PM класса Jedi Knight еще одной важной вещью. Эта вещь называется понимание бизнес-модели, причем как модели своего Работодателя, так и модели Заказчика. Зачем? Потому что действительная цель, про которую мы часто забываем – это получение прибыли. Соответственно тот, кто максимизирует прибыль и для Заказчика и для Работодателя – он как Нео в матрице, умеет вытворять всякое. Потому что когда к business people обращаются «мы должны делать приложение с нормальной архитектурой», то они не слышат. Произнесенные слова для них как казахский язык для русского – буквы знакомые, а смысл высказывания нулевой – вот возьмите в руки баллончик с освежителем воздуха и прочтите часть аннотации, помеченную KZ – вы примерно поймете, что чувствуют business people в таких случаях. И software people в таких случаях удивляются – почему их не слышат? Увидеть мир бизнеса изнутри, понять его и почувствовать отношения внутри него, узнать его язык, научиться считать свою полезность в главном показателе бизнеса - $ прибыли на одну голову в штате. Вот отсюда появится способность предлагать и продвигать действительно полезные для бизнеса инициативы – потому что с точки зрения бизнеса и спецификации отличного качества, и TDD, и высокопроизводительные команды и прочие инициативы могут быть не просто бессмысленными – они могут быть вредными с точки зрения главной функции (максимизации прибыли). И разъяснение что такое хорошо и что такое плохо с точки зрения бизнеса обязательно должны стать частью программы. Казалось бы все. Но на самом деле весь описанный выше набор знаний – это туфта и провокация, если он не подкреплен умением эти знания применить. Потому что нет проекта и нет компании, в которой бы не пришлось биться за осуществление совершенно правильных и необходимых условий и действий. Почему так получается? Потому что любой проект делается не в вакууме – у него есть окружение: условия, возможности, наличие денег и людей, отсутствие денег и людей, фобии участников, рынок, кто у кого 3 года назад увел бабу, инвесторы и еще два воза всякой хренотени, и системы логики далеко не всегда линейны. И поэтому настоящие джедаи – это те, кто вопреки этим двум возам хренотени все-таки смогли сделать проект. И это правильное и специальное личное умение – достижение результата «несмотря на…», которое непременно должно быть у каждого, кто называет себя ПМом. Поэтому вся программа будет осуществляться в режиме «гонка на выживание» с непременным отчислением не набравших проходной балл – несмотря на все проблемы и отговорки. Просто потому что неинтересно – с точки зрения мохнатого капитализма результат или есть, или нет – а остальное вообще бессмысленно. Вот такая вот задумывается программа. Думаю, она станет краеугольным камнем для выведения новой касты джедаев, сурового и циничного капиталистического менеджмента, который сможет вывести прибыли на новый уровень – правда, одновременно здорово прибавит проблем топ-менеджменту. Но это уже совсем другая история… "Наша задача - воткнуть пылающий факел знаний в задницу невежеству". http://thetorch.ru

16 лет dev.by — «дефолтный» источник информации о беларусском ИТ

Вы можете...