Скотт Беркун - Искусство управления IT-проектами
- Название:Искусство управления IT-проектами
- Автор:
- Жанр:
- Издательство:Издательство «Питер»046ebc0b-b024-102a-94d5-07de47c81719
- Год:2014
- Город:Санкт-Петербург
- ISBN:978-5-388-00543-4
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Скотт Беркун - Искусство управления IT-проектами краткое содержание
В отличие от множества трудов, посвященных руководству проектами и командами, в этой книге не проповедуются никакие новые учения и не превозносятся великие теории. Скотт Беркун считает залогом успеха практику и разнообразие подходов. В книге описываются основные сложности и проблемные ситуации, возникающие в работе менеджера проекта, даны рекомендации по выходу из них.
Издание предназначено не только для лидеров команд и менеджеров высшего звена, но и для программистов, тестеров и других исполнителей конкретных проектных заданий. Также оно будет полезно студентам, изучающим бизнес-менеджмент, проектирование изделий или программную инженерию.
Текст нового издания значительно переработан автором с целью добиться большей ясности, кроме того, книга дополнена новым приложением и более чем 120 практическими упражнениями.
Искусство управления IT-проектами - читать онлайн бесплатно ознакомительный отрывок
Интервал:
Закладка:
Эти трудности типичны для любого человека, пробующего себя в роли лидера. Принятие решений – одна из ключевых задач лидеров и руководителей, и чем лучше руководитель, тем больше для принимаемых им решений требуется мужества (см. главу 12).
Некоторые решения не дают выигрышных вариантов
Одно из самых неприятных решений, принятых мною в качестве руководителя проекта, касалось панели компонентов Internet Explorer 4.0. Эта панель была новой частью пользовательского интерфейса. К левой границе окна браузера добавлялась вертикальная панель, помогающая пользователям перемещаться по результатам поиска, списку избранного или истории посещения веб-сайтов. За несколько недель до выпуска первой пробной версии (так называемой бета-версии) мы проводили исследования, касающиеся дизайна. Хотя о существовании проблемы нам было известно уже некоторое время, из-за возрастающего общественного давления, связанного с тем, что сейчас окрестили «войнами браузеров», мы, боясь попасть под огонь критики, стали опасаться проявления этой проблемы в выпускаемом продукте.
Проблема состояла в том, что в определенных условиях пользователь мог заставить браузер вывести в своем окне сразу три вертикальных панели, в результате для веб-страниц оставалось лишь совсем небольшое пространство. Увидев как пресса и специалисты тщательно исследуют IE 3.0, мы опасались, что пользователи бета-версии или журналисты «докопаются» до этих условий, сделают копию экрана, которая в конце концов попадет в обзор нового продукта. Подобные обзоры крайне важны, особенно для бета-версий. Надо было что-то предпринимать, и на это было указание руководства и согласие команды.
Я быстро составил список всех аргументов «за» и «против», обсудил его с моими программистами и другими руководителями проекта и обнаружил три жизнеспособных варианта. Все они не предвещали ничего хорошего. На доработку требовалось пять дней, которых у нас не было. Успеть в срок можно было, но для этого нам требовалось в ущерб качеству выпускаемого продукта урезать важную функциональность. Это решение было не сложным, требовало всего двух дней работы и позволяло устранить некоторые условия, вызывавшие проблемную ситуацию. Но это была «пустая» работа, от которой впоследствии нужно было отказаться (решение вполне подходило для бета-версии, но никак не для финальной версии). Последним из вариантов было бездействие с упованием на то, что никто не наткнется на проблему. Я отчаянно искал другие варианты, но так ничего и не нашел. Все идеи, с которыми ко мне приходили, сводились опять-таки к этим трем вариантам. Я помню, как засиделся вечером в офисе допоздна, уставившись на классную доску, проводя замкнутые линии вокруг того, что мне предстояло сделать.
Истории о нелегких решениях есть у каждого руководителя проекта. Если на вас возложена ответственность, то их не избежать. Это могут быть решения, касающиеся бюджета, найма и увольнения специалистов, сделок, технологии, судебных тяжб, переговоров, проектирования, бизнес-стратегии… можете сами продолжить этот перечень. Когда вы сталкиваетесь с трудным решением, единственно правильного ответа не существует. Вполне возможно, что к успеху приведет отказ от доступных (или вообще от всех) вариантов. Принятие решения, неважно насколько хорошо и дотошно исследована проблема, является неким прогнозом. На каком-то из уровней любое трудное решение сводится, в конце концов, к проницательности и мужеству руководителя проектов, а мужество команды состоит в том, чтобы следовать этому решению.
В данной конкретной ситуации с IE4 я выбрал бездействие. После бессонной ночи я решил, что лучше буду противостоять шумихе в печати, случись таковая (что отнимет время у меня, а не у программистов), а не страховаться от того, что еще не случилось. Я был не в восторге от этого, но чувствовал, что для проекта это решение было наилучшим. Команда еще раньше согласилась, что я приму решение единолично, так что мы сразу же двинулись дальше. [51]
Хорошие решения могут давать плохие результаты
Наш экскурс в прошлое невольно бросил тень на многих прекрасных мастеров в деле принятия решений. То, что события развивались непредсказуемо, еще не означает, что команда не сумела найти верного решения на основе имеющейся информации. Принимая сложные или трудные решения, невозможно охватить каждую возможность развития ситуации (хотя некоторые и попытаются это делать). Чем больше времени тратится на попытки учесть все непредвиденное (довольно распространенная привычка менеджеров низшего звена), тем меньше его остается на прогнозирование возможных результатов. Стоит ли беспокоиться о поражении молнией, если у вас проблемы с сердцем, плохой аппетит и вы не выходите из дома, поскольку упражняетесь в скоростном наборе текста.
Частичная неудача в работе над проектом не обязательно свидетельствует о том, что было принято плохое решение. Неудачи обычно происходят в силу обстоятельств, не подвластных ни руководителю проекта, ни команде, ни самой организации. Многое не поддается предсказаниям, а даже будучи предсказанным, не поддается расчетам. Несправедливо возлагать ответственность на тех, кто принимает решения, за обстоятельства, о которых они, возможно, ничего не знали или для возникновения которых ничего не предпринимали. Но именно так во многих организациях и происходит. Если команда, имевшая равные шансы на успех и неудачу, проигрывает, общественное мнение даже по прошествии времени имеет склонность не брать в расчет упорную работу и героические усилия людей, которые привели команду к поражению. Возлагать вину в деле принятия решений нужно крайне осторожно. Люди, которым свойственна смелость в принятии решений, очевидно будут терпеть неудачи чаще, чем склонные к более безопасным и осторожным решениям. Если вы хотите иметь дело с храбрыми людьми, им нужно обеспечить поддержку в больших ставках на игру, а после неудачного решения помочь встать на ноги.
Руководители проекта несут прямую ответственность за его судьбу. Я не предлагаю им для сплочения команды ходить и похлопывать всех по спине в знак одобрения. Нужно просто позаботиться о том, чтобы руководитель, принявший хорошее, но обернувшееся неважным результатом решение, не подвергался обвинениям. Если он озвучил свою логику и ход мысли до принятия решения, то даже при возникновении непредвиденных обстоятельств его логика и ход мысли звучат точно так же и после принятия решения. Состояние окружающего мира на момент принятия решения позже не претерпит изменений только потому, что мы теперь знаем о нем больше, чем знали тогда. Если существовало нечто, о чем не знали или чего не могли увидеть ни руководитель проекта, ни команда в целом, несмотря на все свои старательные попытки узнать или увидеть, их за это осуждать нельзя. Лучше пусть команда подумает, как общими усилиями раздобыть упущенные данные и сведения и применить их при принятии следующих решений.
Читать дальшеИнтервал:
Закладка: