Записки руководителя проекта по мотивам романа об управлении проектами

Сегодня речь пойдет о книге Тома ДеМарко «Deadline. Роман об управлении проектами». Автор позиционирует свою книгу как роман, и это действительно похоже на роман (по крайне мере читается она достаточно легко).

Из предыстории книги известно, что ещё в детстве Тома заинтересовали книги физика Джордж Гамоу. Интерес этот состоял в том, что научные постулаты в своих рассказах физик описывал образно и доступным языком.

ДеМарко, вдохновившись этой идеей, поставил себе цель (естественно, уже во взрослом состоянии) написать книгу о достаточно сложной области — об управлении проектами -, но написать её простым языком, понятным неспециалистам. Как руководитель десятков ИТ-проектов могу сказать, что автору это удалось.

Интерес к данной книге возник в связи с тем, что много внимания уделяется именно ИТ-проектам. Пересказывать «Dedline..» нет смысла (кто заинтересуется – сам прочитает). Здесь просто поделюсь мыслями, пропущенными через свой опыт, которые возникли по итогам прочтения книги:


    1. Для управления ИТ-специалистами (фактически — сотрудниками интеллектуального труда) ни в каком виде не применимы стандартные методы директивного управления – посредством приказов и распоряжений, без склонности к диалогу.

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

// Для себя мы уже давно это осознали, что крайне проблематично — построить так называемый «оазис инновационности» внутри классического директивно управляемого предприятия. Такая модель управления просто губит все творческое, создаваемое в этом «инновационном оазисе».

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


    1. Увеличение количества людей, задействованных на проекте, зачастую приводит к снижению скорости выполнения проекта, нежели к его увеличению.

  • // Нас всегда удивляло – когда в составе проектных команд числятся по 30/40/50 человек. Такими командами становится просто сложно управлять.

    // Во многих инновационных компаниях есть такое понятие как «the Two Pizza Rule» — правило двух пицц. Оно гласит – размер команды для эффективного взаимодействия не должен превышать количество людей, которых можно накормить двумя пиццами. Поэтому команды должны быть ограниченного размера (чтобы не терять много времени на коммуникации).

    // Однако есть и оговорка – когда проект продуман, когда он имеет чётко выстроенный скелет, когда работа становится уже менее интеллектуальной, а более технической (например, когда нужно просто писать код по очень чётким параметрам) – в такие моменты команда может впитывать в себя человеческие ресурсы и очень сильно возрастать.

    При этом на начальных фазах проекта (разработка продукта, продумывание системы и т.д.) размер команды должен быть ограничен, чтобы проект не переходил в пустую бюрократию.


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

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

    // Часто, когда что-то становится неясным, непонятным (либо люди просто о чём-то не договорились), вместо простых и ясных формулировок, начинают писать абстрактные, но очень сложные и умные фразы. Они не повышают ясности документации, но и не оспариваются теми, кто утверждает эту документацию. Люди руководствуются принципом – раз это написали специалисты, а я это не понимаю, то скорей всего дело во мне, но не могу же я признаться, что я что-то не понимаю.

    // Поэтому при проектировании сложных ИТ-проектов даже самые сложные вещи должны быть переложены на какие-то простые и понятные модели. Если же сложные вещи описаны сложно, и они непонятны всем участникам проекта, которые об этом молчат, то это верный знак того, что проект идёт под откос. Другими словами – в любых (даже самых сложных проектах) должны быть ясные и понятные описания требований к этим проектам.

     

    Книгу рекомендую к прочтению всем менеджерам, кто в том или ином виде является ключевым участником ИТ-проектов, а тем более – непосредственным руководителям проектов.

    Книга, скорее всего, найдет живой отклик у ИТ-ков. Но полезнее она будет всё-таки менеджерам. Тем, кто не является сам ИТ-специалистом.

    Печать статьи

    Добавить комментарий

    Ваш e-mail не будет опубликован. Обязательные поля помечены *