» » » » Скотт Беркун - Искусство управления IT-проектами


Авторские права

Скотт Беркун - Искусство управления IT-проектами

Здесь можно купить и скачать "Скотт Беркун - Искусство управления IT-проектами" в формате fb2, epub, txt, doc, pdf. Жанр: Прочая околокомпьтерная литература, издательство Издательство «Питер»046ebc0b-b024-102a-94d5-07de47c81719, год 2014. Так же Вы можете читать ознакомительный отрывок из книги на сайте LibFox.Ru (ЛибФокс) или прочесть описание и ознакомиться с отзывами.
Скотт Беркун - Искусство управления IT-проектами
Рейтинг:
Название:
Искусство управления IT-проектами
Издательство:
неизвестно
Год:
2014
ISBN:
978-5-388-00543-4
Вы автор?
Книга распространяется на условиях партнёрской программы.
Все авторские права соблюдены. Напишите нам, если Вы не согласны.

Как получить книгу?
Оплатили, но не знаете что делать дальше? Инструкция.

Описание книги "Искусство управления IT-проектами"

Описание и краткое содержание "Искусство управления IT-проектами" читать бесплатно онлайн.



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

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

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






Другой не менее интересный наглядный урок управления проектами можно получить в приемных покоях скорой помощи. Мне приходилось смотреть по каналу Discovery и слышать по радио истории о том, как небольшие команды опытных врачей, медсестер и других специалистов работают вместе как проектная команда, которая справляется с разнообразными и не всегда обычными медицинскими случаями, встречающимися у доставляемых пациентов. Неудивительно, что представители именно этой профессии изобрели процесс классификации, вошедший в практику разработчиков программных проектов для распределения по приоритетам проблем и недостатков (этот вопрос обсуждается в главе 15).

Рис. 1.1. Теоретически во многих отраслях протекают схожие рабочие процессы. Всегда отводится время на планирование, выполнение и доработку (тем не менее не следует обращаться за медицинской помощью на кухню и требовать обед в пункте первой медицинской помощи)

Мир медицины, особенно травматология, являет собой превосходный образец командной работы, принятия решений в критических ситуациях и результатов реализации проектов, которые ежедневно влияют на судьбы многих людей (на рис. 1.1 дается примерное сравнение этой и других областей работы). Атул Гаванде (Atul Gawande) в своей превосходной книге «Complications: A Surgeon’s Notes on an Imperfect Science» (Picador USA, 2003) написал следующее:

Мы рассматриваем медицину как хорошо организованную область применения знаний и навыков. Но это не так. Эта область науки далека от совершенства, в ней постоянно меняются представления, используется неточная информация, допускаются ошибки персонала, и все это на грани жизни и смерти. Можно ли назвать наукой все, что мы делаем? Да, конечно, но это еще и навыки, интуиция, а иногда и просто догадки на основе имеющегося опыта. Промежуток между тем, что мы знаем и к чему стремимся, сохраняется. И этот промежуток значительно усложняет нашу работу.

Это высказывание, как и многие другие в весьма поучительной книге Гаванде, справедливо и в отношении разработки программного обеспечения. Фред Брукс (Fred Brooks) в классической книге «The Mythical Man-Month» (Мифический человеко-месяц), касающейся разработки программ, проводит схожие параллели между командами хирургов и программистов. Несмотря на то что при разработке веб-сайтов или баз данных жизни мало что угрожает, люди из разных команд могут столкнуться с многими схожими ситуациями и сложностями.

Роль управления проектами

Руководство проектами может быть профессией, работой, ролью или обыкновенным действием. В некоторых компаниях есть руководители проектов, чья работа заключается в наблюдении за всеми проектами, в разработке которых участвует двести человек. В других компаниях эта должность относится к категории рядовых младших менеджеров, чья зона ответственности – небольшой участок крупного проекта. В зависимости от структуры организации, сложившейся корпоративной культуры и целей проекта, управление проектами может быть как неформальной ролью («когда понадобится, то этим кто-нибудь займется»), так и четко выраженной («Винсент, Клод и Рафаэль – полноценные руководители проектов»).

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

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

Иногда все прекрасно обходятся и без специально назначенного руководителя проекта. Программисты и их начальники составляют графики и технические планы (если таковые предусмотрены), а бизнес-аналитик или специалист по рынку проводит работы по планированию или составлению технических требований. Все остальные обязанности, которые можно определить как руководство проектом, просто распределяются по специалистам команды. Возможно, люди в команду нанимались с прицелом не только на создание программного кода. И они не стали бы сторониться начального планирования, разработки пользовательского интерфейса или выработки бизнес-стратегии. За счет этого можно добиться существенной оптимизации работы. При условии, что все готовы разделить ответственность за общее дело и разделить обязанности, которые выполнял бы в команде руководитель проекта, то команде понадобится на одного человека меньше. Что может быть лучше простоты и эффективности.

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

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

Управление программами и проектами в Microsoft

В конце 80-х годов компания Microsoft решала непростую проблему увязывания инженерных работ с маркетинговыми и бизнес-задачами каждого подразделения (кто-то может сказать, что Microsoft и многие другие компании до сих пор не могут решить эту проблему). Некий мудрец по имени Джейб Блюменталь (Jabe Blumenthal) додумался до того, что должна быть специальная должность, и ее исполнитель будет занят выполнением этих двух функций, одновременно играя роль лидера и координатора. Он должен был работать над проектом с первого дня планирования и до последнего дня тестирования. На такую должность следовало бы взять того, кто достаточно хорошо разбирается в программировании, чтобы снискать уважение программистов, но это также должен быть человек, не обделенный талантами и имеющий заинтересованность в более широком участии в создании конечного продукта.

Чтобы работать в этой роли, этот сотрудник должен иметь склонность к такой разносторонней деятельности, как составление технических условий, обсуждение маркетинговых планов, составление календарных планов, управление командами, осуществление стратегического планирования, выполнение классификации ошибок и дефектов, поддержание командного духа, а также выполнение ряда других необходимых функций, которыми кроме него больше некому как следует заняться. Эта новая роль в компании Microsoft получила название руководителя проектов. В его непосредственное подчинение попадали не все специалисты команды, но руководителю проектов давались существенные полномочия по руководству и управлению проектом. (В теории управления это примерно соответствует идее матричной организации управления,[5] при которой существуют две линии структуры подчиненности специалистов: одна основана на функциях специалиста, а другая – на конкретном проекте. Таким образом, программист или тестировщик может иметь двойную подчиненность: основную, в соответствии со своей функциональной ролью, и второстепенную, но не менее серьезную, в соответствии с проектом, над котором он работает.)


На Facebook В Твиттере В Instagram В Одноклассниках Мы Вконтакте
Подписывайтесь на наши страницы в социальных сетях.
Будьте в курсе последних книжных новинок, комментируйте, обсуждайте. Мы ждём Вас!

Похожие книги на "Искусство управления IT-проектами"

Книги похожие на "Искусство управления IT-проектами" читать онлайн или скачать бесплатно полные версии.


Понравилась книга? Оставьте Ваш комментарий, поделитесь впечатлениями или расскажите друзьям

Все книги автора Скотт Беркун

Скотт Беркун - все книги автора в одном месте на сайте онлайн библиотеки LibFox.

Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь.
Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

Отзывы о "Скотт Беркун - Искусство управления IT-проектами"

Отзывы читателей о книге "Искусство управления IT-проектами", комментарии и мнения людей о произведении.

А что Вы думаете о книге? Оставьте Ваш отзыв.