Адаптивное управление программным проектом. Принципы и примеры

Хорошо управляемый проект может быть уcпешно выполнен обычной командой разработчиков.

Автор

Предисловие

Когда-то мы делали ракеты. Ракетой надо было управлять в условиях высокой неопределенности, как характеристик самого управляемого объекта, так и внешних условий. Чтобы эффективно справляться с неопределённостью использовали методы адаптивного управления. К адаптивным относятся такие системы управления, которые предназначены для функционирования в условиях априорной неопределённости и которые в процессе функционирования приспосабливаются к непредвиденным изменениям свойств объекта управления и внешней среды (В.Н. Буков. Адаптивные прогнозирующие системы управления полётом. — М.: Наука, — 1987).

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

Принципы и примеры

История. Винни-Пух и Иа

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

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

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

Иа: «Этот Винни просто тянет время своими глупыми вопросами! Он не хочет ничего менять! Лишь бы нечего не делать!»

Винни-Пух: «Этот осел опять рассуждает о сферических конях в вакууме! Конкретные вопросы его не интересуют! Будет и дальше постоянно генерировать свои новые идеи! Лишь бы ничего не делать!»

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

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

К счастью, Бог или большой взрыв (кому как больше нравится) создал нас разными и в этом наша сила. Это позволяет нам увидеть проблему с разных сторон, придает нашему зрению стереоскопичность и позволяет находить новые нестандартные решения. Поскольку в ходе проекта приходится взаимодействовать разными людьми, то отсюда первый принцип, позаимствованный из кибернетики.

Принцип #1. Принцип необходимого разнообразия

Для «хорошего» управления количество возможных состояний управляющего устройства (разнообразие) должно быть не меньше, чем количество состояний объекта управления. (У.Р.Эшби “Введение в кибернетику” М., ИЛ, 1959)

История. Делаем все по правилам

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

Такое поведение, как правило, типично для вчерашнего студента, который возомнил себя крутым профессионалом. Это, конечно, проблема руководителя, который не донес ему главной цели проекта – заработать деньги. Мы ведь занимаемся коммерческой разработкой. А боец-то думает, что мы делаем лучший в мире программный продукт. Отсюда второй принцип.

Принцип #2. Четыре условия эффективной работы

Для того чтобы ваш сотрудник мог эффективно решить поставленную вами задачу, необходимо и достаточно выполнение четырех условий:

• Понимание целей работы.
• Умение ее делать.
• Возможность ее сделать.
• Желание ее сделать.

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

Принцип #3. Четыре роли руководителя

• Штурман — видение цели и критерии ее достижения, наметить курс, по которому надо к ней двигаться.
• Наставник — «Делай как я!» —девиз состоявшегося руководителя. Помним, что «учитель не тот, кто учит, а тот, у кого учатся».
• Помощник — чтобы боец решил поставленную задачу, руководитель должен предоставить ему необходимые для этого рабочие часы. Еще, конечно, хорошо бы — компьютер.
• Вдохновитель — если боец не хочет решить поставленную задачу, он не решит ее за любое отведенное ему для этого время. Поэтому руководитель должен уметь находить требуемую мотивацию.

История. Менеджер должен занимать очередь…

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

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

Принцип #4. Принцип лидерства

Чтобы стать лидером руководитель должен поучить полное доверие команды и признание своего профессионализма.

История. Тихоня

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

Такое поведение, как правило, вызвано отсутствием доверия к руководителю. Чтобы завоевать доверие и профессиональное признание у руководителя есть четыре стратегии.

Принцип #5. Четыре стратегии лидера

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

Чтобы получить признание профессиональной компетенции, лидер должен сочетать директивное управление и объяснения — “продавать” свои решения, убеждать в их правильности. Завоевать доверие можно, если поощрять коллективное принятие решений, обмен идеями, поддерживать инициативу сотрудников. Делегирование возможно только при взаимном доверии.

История. Все достало…

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

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

Принцип #6. Принцип цикличности

Руководитель должен постоянно искать ответы на вопросы: «Что лишнее мы делаем?»; «Что можно делать проще?»; «Что угрожает проекту?», — работать на сокращение ненужных усилий вместо того, чтобы «стремиться к новым героическим подвигам». Необходимо перестраиваться, отказываться от того, что перестало действовать или стало работать неэффективно.
И, наконец, последний и на мой самый важный принцип адаптивного управления программными проектами.

Принцип #7. Принцип четырех «П»

Эффективность разработки ПО есть функция четырех «П»: Продукта, Проекта, Персонала и Процесса.

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

Заключение

У проекта разработки ПО должно быть не три, а четыре фактора успеха:

• Выполнен в соответствие со спецификациями.
• Выполнен в срок.
• Выполнен в пределах бюджета.
• Все участники проекта чувствуют себя победителями.

Успешных вам проектов!