Смартсорсинг.ру

Сообщество руководителей ИТ-компаний, ИТ-подразделений и сервисных центров

Статьи в блогах Вопросы и ответы Темы в лентах Пользователи Компании Лента заказов Курс по ITSM

Жесткое следование методике управления проектом — это хорошо или плохо?

Жесткое следование методике управления проектом — это хорошо или плохо?

Управление проектами — это всегда поиск компромиссов между целью, скоростью ее достижения, затраченными ресурсами, рисками и другими параметрами. Но путь, которым будет достигнуто это равновесие — предмет многочисленных споров и дискуссий. Путь определяется методикой, о достоинствах и недостатках которой можно разговаривать бесконечно. Но сейчас хотелось бы поднять вопрос не качества какой-то конкретной методики, а степени ее соблюдения.

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

Примерно та же ситуация наблюдается и с методиками управления проектами. В реальных, а не абстрактных командах, неизбежны отклонения от параметров такой «теоретической модели», т.е. слепое следование установкам определенной теории может привести совсем не к тому результату, на который рассчитывает руководитель.

В определенных ситуациях надо уметь вносить правильные непротиворечивые допущения. Неумение или нежелание действовать гибко получило название «методологического безумия». По данным Сергеия Архипенкова (эксперта в управлении разработкой ПО, PMP® PMI и вице-президента Гильдии менеджеров программных проектов), термин ввел в обиход именно физик, так что сравнение с теоретической моделью физического процесса здесь не случайно. Правда, вводился он изначально не в рамках изучения отдельного явления, а по отношению к методикам исследований. К способу мотивации и контроля, который выбирают руководители НИИ для достижения определенного результата.

Программирование — несколько иная, новая отрасль, которая по своим характеристикам оказались ближе всего к научным исследованиям. Ведь очевидно, что в разработке ПО просто не сработают те инструменты управления, которые оказываются действенными на кассиров в супер-маркете.

В сферу разработки ПО вера в методологию пришла не так давно, лет 10 назад, но «симптомы» имеют много сходства с проектами научных институтов. Основные последствия так называемого «методологического безумия» в своих выступлениях и тренингах описывает Сергей Архипенков:

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

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

Последствия слепого следования методике более или менее понятны. Гораздо сложнее выделить границы применимости «теории», допустимые в каждом конкретном случае, отвечая на вопросы: стоит ли прислушиваться ко мнению программистов при управлении проектами, надо ли писать регламенты по методике, сколько и каких метрик использовать в процессе работы, и т.п.? А что вы думаете по этим вопросам?

Дополнительные материалы

Комментарии (1)

  • Аватар

    Бычков Валерий [vbychkov], 17 января 2012, 18:18

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