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

И так, поехали.

Замечали, как обычно устроена реклама? Первое, что надо сделать – сильно-пресидьно напугать. Ну, вы видели, как это делают. Красное вино, борщ, кетчуп – и все это на белую сорочку. Затем появляется волшебный стиральный порошок, который моментально возвращает одежде первозданную белизну.

Так же поступлю и я.

Пугаю

Компания Standish Group, проанализировав работу 364 американских корпораций и итоги выполнения более 23 тысяч проектов, связанных с разработкой ПО, в своем докладе с красноречивым названием «Хаос» (Jim Johnson, «Chaos: The Dollar Drain of IT Project Failures. Application Development Trends», January 1995. Standish Group.) пришла к следующим неутешительным выводам. «Только 16,2% проектов завершились в срок, не превысили запланированный бюджет и реализовали все требуемые функции и возможности; 52,7% проектов завершились с опозданием, расходы превысили запланированный бюджет, требуемые функции не были реализованы в полном объеме; 31,1% проектов были аннулированы до завершения. Для проектов, которые завершились с опозданием или были аннулированы до завершения, бюджет среднего проекта оказался превышенным на 89%, а срок выполнения — на 122%».

С тех пор мало что изменилось.

Ретроспектива результатов анализа успешности программных проектов за 15 лет (рис. cartmendum)

Напугал?

А теперь я расскажу вам о том, какие нужны ингредиенты, для того чтобы ваш проект всегда укладывался в треть успешных. Их всего четыре. 4П: Продукт, Персонал, Процесс и ПМ. Но эти ингредиенты должны быть, не абы какими, а только правильными.

Правильный продукт

Том Демарко в соей статье (Tom DeMarco, Software Engineering: An Idea Whose Time Has Come and Gone?, © 2009 IEEE) пишет, что в разработке ПО есть два типа программных продуктов:

• Тип A, которые приносят 10% прибыли.
• Тип B, которые приносят более 500% прибыли.

Большинство провальных проектов относилось к типу A. Вывод, давайте разрабатывать правильные программные продукты типа B.

Правильный персонал

Не стоит нанимать сотрудников, которые умеют хорошо работать и потом постоянно пытаться их мотивировать работать хорошо. Надо искать тех, кто не умеет работать плохо. Вот их основные отличительные характеристики:

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

Все мы знаем про Пирамиду Маслоу, но я мало встречал людей, которые знакомы с его последними работами, опубликованными учениками после его смерти (А. Маслоу, «Новые рубежи человеческой природы»). Приведенные характеристики – это прямая цитата книги Маслоу, из того места, где он описывает людей будущего. Согласитесь, что среди классных программистов таких большинство.

Правильный процесс

Не существует единственного правильного процесса разработки ПО. По ходу проекта все меняется. Меняется персонал. В начале было 3 человека, в теперь – 25, человек. В начале стажер был счастлив фиксить баги в чужом коде, а теперь он уже видит себя архитектором. Меняется продукт. В начале было 10 KSLOC, а теперь — уже 500 KSLOC. Правильный процесс — это адаптивный процесс. Модель процесса постоянно должна подстраиваться под изменения. Главный принцип — не люди должны строиться под выбранную модель процесса, а модель процесса должна подстраиваться под конкретную команду, чтобы обеспечить ее наивысшую производительность.

Правильный процесс (рис. cartmendum)

И, наконец, правильный ПМ

Правильный ПМ – это не тот, кто, закинув ноги на стол, двигает прогресс бар на диаграмме Ганта. Рабочий день правильного ПМа выглядит, примерно, так.

Правильный ПМ

• 9:00 – наблюдает, кто еще не закончил вчерашний рабочий день, что за ночь наколбасила его команда, сколько автотестов обвалилось.
• 11:00 – общается, пытается понять, что вообще происходит вокруг.
• 13:00 – анализирует проблемы и выявляет их причины.
• 15:00 – опираясь на свой багаж знаний, синтезирует решение.
• 17:00 – корректирует рабочий процесс.
• 18:00-9:00 – обобщает новый опыт и кладет его в свою базу знаний.

Если ПМ в течение дня не пообщался с каждым из своих подчиненных то, зря мы ему платим зарплату.

К чему все это?

Я описал четыре ингредиента для приготовления блюда «успешный программный проект». Однако, я ничего не сказал о главном — о рецепте приготовления этого блюда. А здесь все не просто. Их существует 1001 штука. Именно эти рецепты мы будем обсуждать 6 декабря на 3-ей Международной конференции в области управления программными проектами «Software Project Management Conference».

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

До встречи в Казани!

Автор: craft_brother

Источник