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