Скотт Беркун - Искусство управления IT-проектами
- Название:Искусство управления IT-проектами
- Автор:
- Жанр:
- Издательство:Издательство «Питер»046ebc0b-b024-102a-94d5-07de47c81719
- Год:2014
- Город:Санкт-Петербург
- ISBN:978-5-388-00543-4
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Скотт Беркун - Искусство управления IT-проектами краткое содержание
В отличие от множества трудов, посвященных руководству проектами и командами, в этой книге не проповедуются никакие новые учения и не превозносятся великие теории. Скотт Беркун считает залогом успеха практику и разнообразие подходов. В книге описываются основные сложности и проблемные ситуации, возникающие в работе менеджера проекта, даны рекомендации по выходу из них.
Издание предназначено не только для лидеров команд и менеджеров высшего звена, но и для программистов, тестеров и других исполнителей конкретных проектных заданий. Также оно будет полезно студентам, изучающим бизнес-менеджмент, проектирование изделий или программную инженерию.
Текст нового издания значительно переработан автором с целью добиться большей ясности, кроме того, книга дополнена новым приложением и более чем 120 практическими упражнениями.
Искусство управления IT-проектами - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Если конфликт возникает между людьми из двух разных организаций, ситуация усложняется, поскольку между вовлеченными в него людьми может быть меньше доверия и слабее уровень взаимоотношений. На первый план должна быть выдвинута задача создания некоего подобия целям проекта. (Зачем мы ведем совместные дела? В чем состоят взаимные выгоды от обмена результатами работы или ресурсами?) Как правило, все это должно быть сделано еще в стадии завязывания отношений (простейшей формой подобного соглашения является контракт). Должны быть выяснены интересы каждой из сторон и выработаны основы взаимоотношений, на которые можно будет сослаться, если в будущем возникнут конфликты и разногласия (именно соглашения в первую очередь способны свести подобные разногласия к минимуму). Но вместо предварительного соглашения, оно может быть заключено пост-фактум. Разрешить конфликт намного труднее при низком уровне доверия и доброжелательности, но это – единственный способ найти приемлемое решение.
Роли и четко определенные полномочия
Из занятий соревновательными видами спорта я извлек два урока. Во-первых, истинное доверие возникает лишь при встрече с трудностями и в процессе их преодоления. Только при проведении диспута, когда кто-то чем-то расстроен и вскрывается истина, возникает возможность укрепления взаимоотношений. Во-вторых, слаженная работа хорошей команды получается благодаря тому, что каждый знает свою роль не хуже, чем роли всех своих коллег. Когда каждый может положиться на вклад всех остальных и спокойно заниматься своим делом, все идет хорошо. Солист рок-группы не сможет выдать хорошего соло, если басист и ударник не зададут ему четкий ритмический рисунок. То же самое относится к нападающим и разыгрывающим в баскетболе, к форвардам и хавбекам в футболе. И разумеется, то же относится к программистам, тестировщикам и другим специалистам команды разработчиков.
По мере роста напряженности в команде возрастает возможность зависимости друг от друга. Все может сломаться, и люди, впервые столкнувшись с неудачей, испытывают страх или обвиняют во всем всех, кроме себя. В сложной работе часто складывается высокая степень взаимозависимости, означающая, что Фрэд знает, что он не сможет закончить свой тест, если Сара не сдаст к сроку свой фрагмент программного кода. Его волнения вполне обоснованы: у него нет достаточного опыта совместной работы, чтобы быть уверенным в ее способности справляться со своими обязательствами в сложных ситуациях.
Поэтому, когда возникает напряженность, в неопытных командах обычно наблюдается борьба ролей. Одни специалисты начинают ставить под сомнение способности других и предпринимают все доступные им меры защиты от чужих неудач (часто при этом тратя энергию впустую). Поступать подобным образом могут даже опытные люди, если они работают в команде, составленной из специалистов, не испытывающих особого доверия друг к другу.
Для руководителя проекта это означает, что укрепление ролевой структуры команды в тяжелые времена выдвигается на первый план. Нужно напомнить каждому, в какой степени от его работы зависят все остальные и какие результаты работы ему следует ожидать от других. Лидер должен выявить всех испуганных и напомнить им о том, что он вполне уверен в возможностях команды. Выясните, кто из сотрудников чувствует себя уязвленным, и займитесь изменением их восприятия. Сплочение команды не требует высокопарных речей и резких жестов. Нужно просто прийти к людям и вызвать у них чувство сопричастности к происходящему, вселить в них веру в способности внести свой вклад в успех общего дела.
Иногда для исполнения своих ролей люди нуждаются в поддержке и защите. Руководитель проекта должен поддержать тех людей, которые стараются выполнять свою работу, но получают несправедливые упреки от коллег. Зачастую подобное случается при ролевых разногласиях, к примеру, между программистами и тестировщиками, между разработчиками и специалистами по маркетингу. Поэтому случайно услышав какое-нибудь несправедливое замечание, вроде: «Боб, наверное, полный идиот, поскольку до сих пор не провел этот тест», вы должны выбрать момент и сказать: «Стив, Боб сейчас отстает, потому что команда разработчиков всю прошлую неделю топталась на месте. Не могли бы вы его выручить, ведь команда тестировщиков не раз вас выручала?» Станьте совестью команды и поддерживайте честные отношения между людьми, когда в этом возникает необходимость.
Если действительно в чем-нибудь проявится чья-то некомпетентность (например, Боб на самом деле окажется идиотом), руководитель проекта обязан нанять менеджеров и убедиться в том, что решение проблемы поручено тому, кто справится с ней наилучшим образом. (Основанием для вашей реакции должна стать та роль, с которой, как предполагается, данный человек не вполне справляется. Возможно, здесь дело не столько в компетентности, сколько в недопонимании ролей и обязанностей.) В большинстве случаев проблемы команд в стрессовой ситуации касаются вопросов общения, недобросовестности, недоверия и неразберихи в распределении ролей, а не глупости или неумения в чистом виде.
Все должны знать, кто принимает решения
В сложные времена не должно быть сомнений в том, кто имеет право принимать решения. Если команда зашла в тупик и в ближайшие пять минут нужно отдать какие-то жесткие распоряжения, от которых зависит судьба проекта, то кто должен это сделать? В военных организациях существует четкая иерархическая цепочка, поэтому там всегда есть точный ответ на данный вопрос. Поскольку решения должны приниматься в стрессовой ситуации и в кратчайшие сроки, нужна управляющая структура, не допускающая пререканий, рассчитанная на эффективные действия, независимо от степени запутанности ситуации. Большинство распоряжений, получаемых солдатами, основано на доверии командованию. А для проектов должно быть следующее правило: чем сильнее давление обстоятельств и выше ставки, тем меньше должно быть сомнений насчет того, в чьих руках находится власть.
При реализации проектов череда инстанций, задействованных в принятии сложных решений, должна определяться руководством, а точнее – руководством проекта. Если возникшие сложности касаются вопросов бизнеса, технологии и технических требований, никакой отдельный специалист (по маркетингу или разработке) не будет иметь нужный для этого всеобъемлющий кругозор. А руководитель проекта, учитывая степень его вовлеченности в проект, обладает самым точным пониманием различных взглядов и возможностью повлиять на принимаемые компромиссные решения. Если обязанности по руководству проектом возложены на несколько человек, должно быть абсолютно понятно, кто что решает и кто привлекается к выработке решения. Дискуссии по поводу распределения ролей, рассмотренные в главе 9, должны включать вопрос о полномочиях в принятии решений и могут использоваться для выяснения других вопросов, касающихся распределения властных полномочий.
Читать дальшеИнтервал:
Закладка: