Эффективный менеджмент проектов в сфере информационных технологий.
В современной России понятие "Эффективный менеджмент" является, скорее, ругательным. Ниже я попробую описать, каким я вижу действительно эффективный менеджмент (управление), исходя из своего опыта. Возможно, изложенные мной принципы применимы не только к проектам в сфере информационных технологий, однако, я не имею достаточного опыта, чтобы это утверждать.
Для управления проектом я сформулировал 3 принципа, по аналогии с 3 знаменитыми законами робототехники Азимова:
1) Работники должны быть счастливы на работе, и им не нужно мешать работать.
2) Менеджер должен заботиться об увеличении производительности труда и предлагать новые технологии работы, если это не противоречит п. 1.
3) Менеджер должен задавать общее направление проекта, если это не противоречит п. 1 и п. 2.
Теперь рассмотрим эти принципы подробнее.
Пункт 1.
Сначала разберемся со счастьем.
Есть мнение, что человеческий ресурс в высокотехнологичных проектах, таких как разработка программного обеспечения, вещь второстепенная, а сосредоточиться надо на идеях, процессах и технологиях. Однако оглянитесь вокруг: все, что вы видите, сделано людьми, а не хитрыми инструментами. На заре человеческой эволюции, и первобытных гоминидов не было ничего, кроме рук и голов. Именно люди являются главной движущей силой любого производственного процесса.
Прекрасно, если работа у вас поставлена так, что в процессе нет незаменимых людей: уровень формализации и документирования позволяет с минимальными затратами заменить в проекте одного специалиста на другого, с аналогичными навыками. Однако, что делать, если ни один из кандидатов в работники работать не желает?
Традиционные инструменты управленца - кнут и пряник. В качестве первого предлагаются ругань, штрафы, ухудшение условий работы и увольнение. В качестве второго - денежные премии. Но отрицательными стимулами можно добиться только того, что человек станет работать хуже. А как положительный стимул деньги работают лишь до определенного момента (хорошая видео презентация на эту тему: http://www.youtube.com/watch?v=u6XAPnuFjJc). Когда денег становиться достаточно для жизни, которую человек считает для себя приемлемой, дальнейшее увеличение зарплаты лишь наполняет работника чувством собственной важности, и заставляет относиться к своим обязанностям менее внимательно и выполнять их со все меньшей охотой.
Поэтому человека надо вынуждать к работе исподволь. Сделать его окружение таким, чтобы при наличии альтернатив, наиболее приятным занятием для него являлась работа. Установить удобную мебель, чтобы он не торопился домой в свое старое кресло. Кормить вкусными обедами, чтобы не мечтал весь день, о том, как вернется домой и, наконец-то, нормально наестся. Установить на работе спортивный снаряд и организовать вечерние походы в фитнес-центр, чтобы человек не думал вместо работы о том, как гробит сгорбившись за компьютером свое здоровье.
Конечно, это немного подло. Каждый менеджер в душе идеалист и считает, что тяга к работе должна исходить от сердца, и хороший, годный сотрудник будет работать от зари до зари лишь потому, что радеет за идею, в любых, сколь угодно скотских условиях. Но такие алмазы среди работников редки. Поэтому рядовых сотрудников приходится обманывать, устраивая для них хорошие условия.
Теперь разберемся с тем, чтобы не мешать людям работать.
Китайская мудрость гласит: проверяя без конца того, кому мы дали поручение, разве не уподобляемся мы человеку, выдергивающему росток из земли всякий раз с той лишь целью, чтобы удостовериться наверняка, растут или нет корни?
Из того, что я выше написал о порочной натуре работников (не хотят трудиться за идею, и даже за долю от дохода, а хотят, чтобы работать им было приятно), может возникнуть впечатление, что средний работник - существо низменных побуждений и вообще, от природы глуповатое. Это не так.
Каждый человек в течение жизни чему-то учиться. Каждый миг его бодрствования занят совершенствованием в чем-либо. Один хорош в логике, другой в вождении, третий в ковырянии в носу. Допустим, два водителя имеют одинаковый опыт и подготовку. Но один лучше на дороге. Зато он узкий специалист - может только водить, а второй - может неплохо водить, и одновременно говорить по телефону. Если вы в чем-то превосходите другого человека, то и другой человек в чем-то превосходит вас. Это нормально.
Среди менеджеров, действительно желающих сделать свой проект хорошо, часто встречаются люди, одержимые жаждой контроля. Они требуют каждодневных и подробных отчетов о работе, не высыпаются, читая допоздна всю проектную документацию и проверяя каждую строчку программного кода. И, конечно, находят ошибки. Часть ошибок порождается неопытностью или случайными заблуждениями работников. Часть - различием в видении общей картины проекта у управленца и разработчиков. Часть - тем, что руководитель и исполнитель просто используют разные способы решения одной задачи. Поэтому, при тесном контроле не обойтись без огромного количества исправлений.
В итоге, менеджер приводит всех исполнителей к своему уровню, кого поднимает, кого - низводит. Это не только сильно уменьшает радость от работы, но и понижает ее производительность в целом. Так сколь угодно большая группа работников по суммарной производительности труда становится примерно равна одному увлеченному управленцу.
Конечно, совсем без контроля не обойтись. У каждого в работе возникают проблемы, они могут быть вызваны недостатком квалификации или коммуникации. И если процесс работы предоставить самому себе, перед сдачей проекта может неожиданно выясниться, что не готово 99%. Но контролировать надо не людей, а результаты их работы. При этом, на возможно более высоком уровне, опускаясь на низкий только если в каком-то из верхних сегментов возникли явные проблемы.
Создайте комфортные условия для работы и предоставьте специалистам делать то, в чем они считаются специалистами, и результаты вас приятно удивят.
Кстати говоря, многие менеджеры считают, что их задача - управлять работниками, навроде того, как кучер правит лошадью. Для создания же комфортных условий работы есть отдел кадров и хозяйственный отдел. На самом деле, это поддерживающие службы, обеспечивающие основную деятельность. Основной же деятельностью занимаются разработчики, а менеджер - наиболее заинтересованный в ее результатах человек. Таким образом, повышение эффективности работы - его основная обязанность, какими бы средствами оно не осуществлялось.
Пункт 2.
С этим гораздо проще. Проблема в том, что технологии не стоят на месте. Отставая от них, можно отстать от конкурентов. Поэтому процесс работы нужно все время совершенствовать, особенно в сфере информационных технологий.
Кое-что каждый работник может оптимизировать на своем рабочем месте самостоятельно. Однако, не каждый будет это делать. Большинство либо не желает лишний раз напрягаться, либо слишком загружено в текущих процессах, чтобы думать об их оптимизации. Поэтому инициатива по внедрению новых технологий и подходов к работе должна если не исходить от менеджера, то, во всяком случае, находить у него поддержку. К тому же, только при активном продвижении руководства новая, не привычная технология сможет закрепиться в большом коллективе и начать приносить пользу.
Мы определились ранее, что позволяем каждому сотруднику самостоятельно делать то, в чем он хорошо разбирается. Но расширить сферу его компетенций и связать его труд с трудом других работников может только менеджер. К тому же, узнавать новое и развиваться интересно, и повышает интерес к работе.
Системы управления версиями программного обеспечения, автоматизированные системы тестирования, стандарты управления качеством, электронный документооборот, технологии удаленной работы - вот лишь некоторые примеры того, без чего сейчас существуют многие предприятия сегодня.
Тем не менее, нельзя в погоне за призрачным конкурентным преимуществом в одночасье ломать налаженные производственные процессы. Отсюда и требование, чтобы модернизация и оптимизация не мешали людям получать удовольствие от работы, и, следовательно, приносить прибыль предприятию.
Пункт 3.
Часто менеджеры выстраивают приоритеты в обратном порядке:
1) Главное - двигаться к цели;
2) Оптимизировать процесс движения, если это не противоречит 1);
3) Заботиться о работниках, если это не противоречит 1) и 2).
Процесс работы, построенный таким образом, часто выглядит со стороны образцово-показательным. Однако результат достигается редко. Дело в том, что первоначально поставленная цель почти никогда не бывает тем, чего действительно требуется достичь.
Согласно классической, «водопадной» модели разработки, сначала определяется цель, потом детально определяется путь ее достижения, потом, шаг за шагом, идет процесс движения к ней. Возврата на предыдущий шаг не предусмотрено. Я ни разу не видел, чтобы в проекте, созданном таким образом, результат соответствовал бы ожидаемому. Не даром модели каскадного типа все больше уступают место Agile-based моделям, например, Scrum.
С другой стороны, можно подумать, что требование двигаться в заданном направлении противоречит пункту 1. Как можно понукать работников, не ущемляя их свободы, «не мешая им работать»? Большого противоречия здесь нет. Если создать для грамотных специалистов хорошие условия работы, рано или поздно они чего-нибудь достигнут. Но что это будет - заранее не сможет сказать никто. Это обычная модель стартапов, так популярная на западе уже много лет. Без четкого плана больших успехов добились Google, Twitter и даже Apple с Microsoft. Но теперь, получая деньги за конкретные продукты, а не надеясь сделать мир лучше абстрактной идеей, они не могут блуждать без направления, хотя бы приблизительного. И работников надо подталкивать в его сторону.
Для этого в каждом проекте, достаточно большом, чтобы требовать привлечения более одного работника, должен быть архитектор. Часто архитектора нет совсем. Например, делается система электронного документооборота. Все участники процесса, независимо от роли, представляют, из каких «блоков» такая система состоит. ТЗ осталось от прошлого подобного проекта, его не надо писать с нуля, не надо даже перечитывать и переписывать, достаточно лишь подправить некоторые избранные моменты, и можно сдавать. То, что кому-то надо построить цельную концепцию системы сообразно с виденьем, пожеланиями и потребностями заказчика (это разные вещи), никому не приходит в голову. В результате получается кадавр, собранный из остатков трупов других проектов и нежизнеспособный.
Бывает, что в качестве архитектора выступает коллективный разум. Избранные члены проектной группы собираются на регулярные «митинги» и вырабатывают единое видение проекта. Конечно, по мере продвижения оно может изменяться. Проблема тут в том, что каждый понимает каждого чуточку иначе. Если команда не является хорошо «притертой» и «сработавшейся», обсуждения часто скатываются в непродуктивные споры или обсуждение второстепенных деталей. К концу проекта либо случается выкидыш нежизнеспособного кадавра, потому что на него все махнули рукой, устав возиться, либо в проектной группе все становятся друг другу врагами из-за слишком бережного отношения к собственной, взлелеянной точке зрения.
Бывает, что функции архитектора берет на себя менеджер. Не самый худший вариант, но и не лучший. Менеджеру сложно возражать. Не даром в любом нормальном государстве разделяют законодательную и исполнительную власть. Имеет смысл сделать это и на проекте.
Для управления проектом я сформулировал 3 принципа, по аналогии с 3 знаменитыми законами робототехники Азимова:
1) Работники должны быть счастливы на работе, и им не нужно мешать работать.
2) Менеджер должен заботиться об увеличении производительности труда и предлагать новые технологии работы, если это не противоречит п. 1.
3) Менеджер должен задавать общее направление проекта, если это не противоречит п. 1 и п. 2.
Теперь рассмотрим эти принципы подробнее.
Пункт 1.
Сначала разберемся со счастьем.
Есть мнение, что человеческий ресурс в высокотехнологичных проектах, таких как разработка программного обеспечения, вещь второстепенная, а сосредоточиться надо на идеях, процессах и технологиях. Однако оглянитесь вокруг: все, что вы видите, сделано людьми, а не хитрыми инструментами. На заре человеческой эволюции, и первобытных гоминидов не было ничего, кроме рук и голов. Именно люди являются главной движущей силой любого производственного процесса.
Прекрасно, если работа у вас поставлена так, что в процессе нет незаменимых людей: уровень формализации и документирования позволяет с минимальными затратами заменить в проекте одного специалиста на другого, с аналогичными навыками. Однако, что делать, если ни один из кандидатов в работники работать не желает?
Традиционные инструменты управленца - кнут и пряник. В качестве первого предлагаются ругань, штрафы, ухудшение условий работы и увольнение. В качестве второго - денежные премии. Но отрицательными стимулами можно добиться только того, что человек станет работать хуже. А как положительный стимул деньги работают лишь до определенного момента (хорошая видео презентация на эту тему: http://www.youtube.com/watch?v=u6XAPnuFjJc). Когда денег становиться достаточно для жизни, которую человек считает для себя приемлемой, дальнейшее увеличение зарплаты лишь наполняет работника чувством собственной важности, и заставляет относиться к своим обязанностям менее внимательно и выполнять их со все меньшей охотой.
Поэтому человека надо вынуждать к работе исподволь. Сделать его окружение таким, чтобы при наличии альтернатив, наиболее приятным занятием для него являлась работа. Установить удобную мебель, чтобы он не торопился домой в свое старое кресло. Кормить вкусными обедами, чтобы не мечтал весь день, о том, как вернется домой и, наконец-то, нормально наестся. Установить на работе спортивный снаряд и организовать вечерние походы в фитнес-центр, чтобы человек не думал вместо работы о том, как гробит сгорбившись за компьютером свое здоровье.
Конечно, это немного подло. Каждый менеджер в душе идеалист и считает, что тяга к работе должна исходить от сердца, и хороший, годный сотрудник будет работать от зари до зари лишь потому, что радеет за идею, в любых, сколь угодно скотских условиях. Но такие алмазы среди работников редки. Поэтому рядовых сотрудников приходится обманывать, устраивая для них хорошие условия.
Теперь разберемся с тем, чтобы не мешать людям работать.
Китайская мудрость гласит: проверяя без конца того, кому мы дали поручение, разве не уподобляемся мы человеку, выдергивающему росток из земли всякий раз с той лишь целью, чтобы удостовериться наверняка, растут или нет корни?
Из того, что я выше написал о порочной натуре работников (не хотят трудиться за идею, и даже за долю от дохода, а хотят, чтобы работать им было приятно), может возникнуть впечатление, что средний работник - существо низменных побуждений и вообще, от природы глуповатое. Это не так.
Каждый человек в течение жизни чему-то учиться. Каждый миг его бодрствования занят совершенствованием в чем-либо. Один хорош в логике, другой в вождении, третий в ковырянии в носу. Допустим, два водителя имеют одинаковый опыт и подготовку. Но один лучше на дороге. Зато он узкий специалист - может только водить, а второй - может неплохо водить, и одновременно говорить по телефону. Если вы в чем-то превосходите другого человека, то и другой человек в чем-то превосходит вас. Это нормально.
Среди менеджеров, действительно желающих сделать свой проект хорошо, часто встречаются люди, одержимые жаждой контроля. Они требуют каждодневных и подробных отчетов о работе, не высыпаются, читая допоздна всю проектную документацию и проверяя каждую строчку программного кода. И, конечно, находят ошибки. Часть ошибок порождается неопытностью или случайными заблуждениями работников. Часть - различием в видении общей картины проекта у управленца и разработчиков. Часть - тем, что руководитель и исполнитель просто используют разные способы решения одной задачи. Поэтому, при тесном контроле не обойтись без огромного количества исправлений.
В итоге, менеджер приводит всех исполнителей к своему уровню, кого поднимает, кого - низводит. Это не только сильно уменьшает радость от работы, но и понижает ее производительность в целом. Так сколь угодно большая группа работников по суммарной производительности труда становится примерно равна одному увлеченному управленцу.
Конечно, совсем без контроля не обойтись. У каждого в работе возникают проблемы, они могут быть вызваны недостатком квалификации или коммуникации. И если процесс работы предоставить самому себе, перед сдачей проекта может неожиданно выясниться, что не готово 99%. Но контролировать надо не людей, а результаты их работы. При этом, на возможно более высоком уровне, опускаясь на низкий только если в каком-то из верхних сегментов возникли явные проблемы.
Создайте комфортные условия для работы и предоставьте специалистам делать то, в чем они считаются специалистами, и результаты вас приятно удивят.
Кстати говоря, многие менеджеры считают, что их задача - управлять работниками, навроде того, как кучер правит лошадью. Для создания же комфортных условий работы есть отдел кадров и хозяйственный отдел. На самом деле, это поддерживающие службы, обеспечивающие основную деятельность. Основной же деятельностью занимаются разработчики, а менеджер - наиболее заинтересованный в ее результатах человек. Таким образом, повышение эффективности работы - его основная обязанность, какими бы средствами оно не осуществлялось.
Пункт 2.
С этим гораздо проще. Проблема в том, что технологии не стоят на месте. Отставая от них, можно отстать от конкурентов. Поэтому процесс работы нужно все время совершенствовать, особенно в сфере информационных технологий.
Кое-что каждый работник может оптимизировать на своем рабочем месте самостоятельно. Однако, не каждый будет это делать. Большинство либо не желает лишний раз напрягаться, либо слишком загружено в текущих процессах, чтобы думать об их оптимизации. Поэтому инициатива по внедрению новых технологий и подходов к работе должна если не исходить от менеджера, то, во всяком случае, находить у него поддержку. К тому же, только при активном продвижении руководства новая, не привычная технология сможет закрепиться в большом коллективе и начать приносить пользу.
Мы определились ранее, что позволяем каждому сотруднику самостоятельно делать то, в чем он хорошо разбирается. Но расширить сферу его компетенций и связать его труд с трудом других работников может только менеджер. К тому же, узнавать новое и развиваться интересно, и повышает интерес к работе.
Системы управления версиями программного обеспечения, автоматизированные системы тестирования, стандарты управления качеством, электронный документооборот, технологии удаленной работы - вот лишь некоторые примеры того, без чего сейчас существуют многие предприятия сегодня.
Тем не менее, нельзя в погоне за призрачным конкурентным преимуществом в одночасье ломать налаженные производственные процессы. Отсюда и требование, чтобы модернизация и оптимизация не мешали людям получать удовольствие от работы, и, следовательно, приносить прибыль предприятию.
Пункт 3.
Часто менеджеры выстраивают приоритеты в обратном порядке:
1) Главное - двигаться к цели;
2) Оптимизировать процесс движения, если это не противоречит 1);
3) Заботиться о работниках, если это не противоречит 1) и 2).
Процесс работы, построенный таким образом, часто выглядит со стороны образцово-показательным. Однако результат достигается редко. Дело в том, что первоначально поставленная цель почти никогда не бывает тем, чего действительно требуется достичь.
Согласно классической, «водопадной» модели разработки, сначала определяется цель, потом детально определяется путь ее достижения, потом, шаг за шагом, идет процесс движения к ней. Возврата на предыдущий шаг не предусмотрено. Я ни разу не видел, чтобы в проекте, созданном таким образом, результат соответствовал бы ожидаемому. Не даром модели каскадного типа все больше уступают место Agile-based моделям, например, Scrum.
С другой стороны, можно подумать, что требование двигаться в заданном направлении противоречит пункту 1. Как можно понукать работников, не ущемляя их свободы, «не мешая им работать»? Большого противоречия здесь нет. Если создать для грамотных специалистов хорошие условия работы, рано или поздно они чего-нибудь достигнут. Но что это будет - заранее не сможет сказать никто. Это обычная модель стартапов, так популярная на западе уже много лет. Без четкого плана больших успехов добились Google, Twitter и даже Apple с Microsoft. Но теперь, получая деньги за конкретные продукты, а не надеясь сделать мир лучше абстрактной идеей, они не могут блуждать без направления, хотя бы приблизительного. И работников надо подталкивать в его сторону.
Для этого в каждом проекте, достаточно большом, чтобы требовать привлечения более одного работника, должен быть архитектор. Часто архитектора нет совсем. Например, делается система электронного документооборота. Все участники процесса, независимо от роли, представляют, из каких «блоков» такая система состоит. ТЗ осталось от прошлого подобного проекта, его не надо писать с нуля, не надо даже перечитывать и переписывать, достаточно лишь подправить некоторые избранные моменты, и можно сдавать. То, что кому-то надо построить цельную концепцию системы сообразно с виденьем, пожеланиями и потребностями заказчика (это разные вещи), никому не приходит в голову. В результате получается кадавр, собранный из остатков трупов других проектов и нежизнеспособный.
Бывает, что в качестве архитектора выступает коллективный разум. Избранные члены проектной группы собираются на регулярные «митинги» и вырабатывают единое видение проекта. Конечно, по мере продвижения оно может изменяться. Проблема тут в том, что каждый понимает каждого чуточку иначе. Если команда не является хорошо «притертой» и «сработавшейся», обсуждения часто скатываются в непродуктивные споры или обсуждение второстепенных деталей. К концу проекта либо случается выкидыш нежизнеспособного кадавра, потому что на него все махнули рукой, устав возиться, либо в проектной группе все становятся друг другу врагами из-за слишком бережного отношения к собственной, взлелеянной точке зрения.
Бывает, что функции архитектора берет на себя менеджер. Не самый худший вариант, но и не лучший. Менеджеру сложно возражать. Не даром в любом нормальном государстве разделяют законодательную и исполнительную власть. Имеет смысл сделать это и на проекте.