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

Содержание

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

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


О чем эта книга?

Управлять в сфере информационных технологий сложно. Менеджер должен проявить нечеловеческую выносливость и решительность, обладать трезвым рассудком и незатуманенным взором, всегда находить нестандартные решения задач и порождать нешаблонные идеи. Всему этому господин Беркун научился в корпорации Microsoft.

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


Чему учит эта книга?

Скотт Беркун в книге «Искусство управления IT-проектами» не раскрывает перед читателем принципиально новые позиции, которые бы стали для них открытием. Многое из написанного покажется знакомым, о чем-то Вы слышали, а некоторые методы использовали сами. Автор поможет расставить все точки над «и», системно описав как правильно пользоваться тем или иным управленческим подходом.

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


Для кого эта книга?

Пособие разработано для теоретиков и практиков IT структуры, менеджеров, бизнесменов, студентов, обучающихся управленческому делу.

СКАЧАТЬ БЕСПЛАТНО КНИГУ «Искусство управления IT-проектами»

По ссылке доступен фрагмент книги, который предоставлен издателем для бесплатного ознакомления.


После прочтения вы можете купить полную версию книги по ссылке в конце ознакомительного фрагмента


Скотт Беркун, Сделано – читать онлайн полностью – ЛитРес

Издано с разрешения O’Reilly Media, Inc.

Благодарим за консультации Илону Ноженко

Все права защищены.

Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.

© 2008 Scott Berkun

© 2019 Mann, Ivanov and Ferber

Authorized Russian translation of the English edition of Making Things Happen ISBN 9780596517717

This translation is published and sold by permission of O’Reilly Media, Inc. , which owns or controls all rights to publish and sell the same.

© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2019

* * *

Предисловие

С первым изданием случилось невероятное. Книга разошлась огромным тиражом; попала в несколько списков бестселлеров, стала номинантом различных премий и привлекла достаточно внимания, побудив автора объехать весь мир и рассказать о своих идеях. А потом произошло еще более неожиданная вещь: у книги поменялось название.

Мы с издательством O’Reilly договорились, что если уж книге предстоит обрести вторую жизнь (изначально книга называлась «Искусство управления IT-проектами»[1]), то нужно ее доработать. Мы обновили и дополнили текст, чтобы чтение доставило вам еще большее удовольствие. Если вам интересно, почему изменили название, позвольте перечислить несколько возможных причин.

1. Министерство национальной безопасности усмотрело в старом названии террористическую угрозу.

2. Тим О’Райли[2] решил, что его медиаимперия станет № 1 в мире, если он пойдет на хитрость со сменой названия и убедит читателей купить книгу во второй раз.

3. А здесь можете записать любое объяснение, какое придет вам в голову.

Какой бы ни была причина, мы снова взялись за старое. Я сделал все, что в моих силах, чтобы улучшить книгу и при этом не обречь ее на фиаско «Звездных войн» Джорджа Лукаса[3]. Перечислим в двух словах, что изменилось.

• Текст вычитан на предмет ясности и краткости изложения. Книга стала более содержательной, без «воды».

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

• Я добавил новый раздел по дискуссионным группам, чтобы помочь вам сформировать такую группу и продолжить обучение.

Если вы никогда не слышали об этой книге, введение расскажет вам все, что нужно знать.

После выхода первого издания два года назад я был очень занят. Я написал другую книгу под названием «Откуда берутся гениальные идеи»[4], выпустил ряд статей, подкастов и видео. Я продолжаю вести популярный блог по креативу и менеджменту. Все это можно найти на www.scottberkun.com.

С наилучшими пожеланиями,

Скотт Беркун

Редмонд, Вашингтон

Март 2008 г.

Введение

* * *

Мой любимый вопрос – «как?». Как это работает? Как это устроено? Как они это сделали? Стоит мне увидеть что-то интересное, меня переполняют вопросы с этим коротким, но сильным словом. И большинство ответов строится на том, как люди применяют свои интеллект и мудрость, а не конкретные технологии и теории.

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

Несмотря на несколько обобщенное название книги, мой основной опыт работы связан с технологиями, в частности в Microsoft Corporation. Я проработал там с 1994 по 2003 годы, возглавлял команды по проектам Internet Explorer, Microsoft Windows и MSN. Несколько лет я посвятил группе совершенствования разработок Microsoft. Я обучал и консультировал команды во всей компании, часто выступал на конференциях, читал лекции в других корпорациях и университетах. Большинство советов, уроков и примеров, собранных в книге, опираются именно на этот опыт.

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

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

Для кого эта книга

Чтобы узнать, подходит вам эта книга или нет, предлагаю вернуться к оглавлению, выбрать тему, которая вас интересует, и пробежать глазами, что я написал. Я никогда не доверял введениям и вам не советую, но все-таки продолжу.

Книга будет особенно полезна тем, кто может отнести себя к одной или нескольким категориям.

• Опытные тимлиды и руководители. Эта книга прекрасно подходит для лидеров проектов любого типа. Несмотря на примеры из области разработки программного обеспечения, идеи легко применимы и к другой работе. Вы можете быть лидером команды по должности или просто одним из более опытных ее членов. И хотя некоторые темы наверняка покажутся вам знакомыми, вы сможете выработать свое мнение, даже если не согласны со мной.

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

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

• Студенты, изучающие менеджмент, проектирование и разработку программного обеспечения. Я использую слово «студенты» в широком смысле: если вы интересуетесь этими темами или официально учитесь, эта книга должна привлечь ваше внимание. В отличие от того, что можно прочитать в учебниках, мы делаем акцент на конкретику. Опыт и примеры абсолютно реальны, и именно они легли в основу уроков и методов, а не наоборот. Я намеренно избегал разграничения учебных дисциплин: на мой взгляд, разграничения никогда не помогали ни проектам, ни пониманию реального положения дел (мир не делится по тому же принципу, что университетские занятия). Напротив, в этой книге переплетаются вопросы бизнес-теории, психологии, тактики менеджмента, процессов проектирования и разработки ПО таким образом, чтобы из каждой темы читатель смог извлечь для себя пользу.

 

Что я думаю о вас

• Вы не глупы. Надеюсь, я правильно выбрал тематику и хорошо написал, и вы не хотите, чтобы я ходил вокруг да около. Лучше я сразу перейду к делу. Даже если у вас меньше или больше опыта или вы специалист в совершенно другой области, я считаю вас коллегой, обратившимся ко мне за советом.

• Вы любопытны и прагматичны. Я опираюсь на примеры из многих дисциплин и предполагаю, что вы найдете для себя ценные уроки, не ограниченные разработкой приложений и программного обеспечения. Для пытливых умов я приготовил ссылки и дополнительные материалы, иногда в сносках, так что они не будут мешать чтению. Предполагаю, вы хотите учиться, открыты новым идеям и понимаете ценность аргументированных мнений, даже если не согласны с ними.

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

• Вы не слишком серьезно относитесь к себе, программному обеспечению и менеджменту. Разработка программного обеспечения и управление проектами могут наводить тоску. Конечно, такая книга не отличается интригующим сюжетом (другое дело, если бы о разработке программного обеспечения написал Марк Твен или Дэвид Седарис[5]), но я решил не лишать себя удовольствия пошутить над собой (или другими) или разъяснять те или иные моменты на забавных примерах.

Как пользоваться этой книгой

Если в какой-то момент вы заскучаете или сочтете примеры неактуальными, пропустите это место. Я написал эту книгу, учитывая потребности людей, которые привыкли «листать», а не читать или же нуждаются в конкретном совете прямо сейчас. С главами можно знакомиться в любом порядке, особенно с теми, что посвящены человеческой природе (главу 8, главу 9, главу 10, главу 11, главу 12, главу 13 и главу 16). Однако есть польза и от чтения по порядку, от начала до конца. Некоторые концепции, представленные позже, опираются на те, что даны раньше, и большинство проектов описываются в хронологическом порядке. Первая глава – самая общая и глубокая. Если вам любопытно, зачем вообще нужен проект-менеджмент или что говорят о нем авторитетные люди, то стоит почитать ее. Если начнете и вам не понравится, настоятельно рекомендую опробовать другую главу, прежде чем покинуть корабль.

Все ссылки и URL, приведенные в книге, а также дополнительные примечания и комментарии, доступны онлайн на www.makingthingshappen.org. Если вас интересуют дискуссионные группы по этой книге, загляните в приложение. Там вы узнаете, какие группы существуют и как организовать свою собственную группу.

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

Глава первая. Краткая история управления проектами (и зачем это вам нужно)

* * *

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

Эту книгу можно рассматривать с трех позиций: как сборник отдельных статей, как цельное повествование и как справочник по наиболее распространенным ситуациям. Каждая глава посвящена отдельной высокоуровневой задаче, намечает общий план работы и предлагает методы ее успешного выполнения. Однако в первой главе я придерживаюсь иного подхода: есть три более общих момента, которые облегчат дальнейшее чтение, и мне бы хотелось обсудить их прямо сейчас.

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

История нам в помощь

Проект-менеджмент как идея зародился очень давно. Если вспомнить все, что создала наша цивилизация, то у нас тысячелетний опыт проектов, на котором можно учиться. От современных разработчиков ПО ниточка тянется к строителям египетских пирамид или римских акведуков. В любую эпоху менеджеры проекта играли одну и ту же роль: применяли технологии к решению актуальных для своей эпохи задач. Однако сегодня, пытаясь улучшить управление проектами и разработку ПО, многие пренебрегают уроками прошлого. Как правило, в поисках полезных знаний мы выбираем из всей линии времени отрезок, приближенный к сегодняшнему дню.

История инженерных проектов показывает, что большинство из них имеет ярко выраженные общие черты. У них есть требования, план и ограничения. Они зависят от умения общаться, принимать решения, сочетать креатив и логику. Как правило, проекты предполагают определенный график работы, бюджет и клиентов. А главное, основная задача проекта – объединить работу разных людей в единое целое и создать нечто полезное для других (клиентов). Мы можем использовать HTML, C++ или бетон и сталь, но для всех проектов существуют общие неизменные принципы.

Я пришел к ним, интересуясь эффективными методами разработки приложений и программного обеспечения. Обратил внимание на другие области, чтобы узнать, как там решаются важнейшие задачи и проблемы проектов. Cтал разбираться в организации таких проектов, как космический телескоп «Хаббл» и «Боинг 777». Можно ли заимствовать что-то из их спецификаций и планирования? Есть ли сходство в управлении проектами между моими программистами и строителями афинского Парфенона или небоскреба «Крайслер-билдинг» в Нью-Йорке? А в чем отличия и чему учит их анализ?

Возьмем, к примеру, редакторов газет, которые ежедневно «производят» информацию. Ведь они занимались мультимедиа (иллюстрациями и словами) задолго до того, как появилась идея публикаций. А съемки художественного фильма? Запуск «Аполлона-13»? Изучая эти вопросы, я смог найти новые способы управления проектными командами.

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

Перечислю ключевые выводы своих исторических исследований.

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

2. Чем проще вы воспринимаете свои задачи, тем эффективнее и сосредоточенее выполняете работу. Простой взгляд на свою деятельность поможет найти больше примеров и уроков из истории и современных отраслей, позаимствовать их, найти сходства или различия. Это похоже на японскую концепцию шошин, что означает «сознание новичка»[6], или открытый разум, – важную часть многих боевых искусств. Пытливый и открытый ум делает возможным рост и требует немало практики. Познание нового требует выйти за узкие рамки «безопасного» восприятия своей работы.

3. Простой не значит легкий. Ведущие спортсмены, писатели, программисты и менеджеры воспринимают свои занятия как нечто простое и при этом сложное. Помните, что простой и легкий – разные вещи. К примеру, пробежать марафон – простая задача. Вы начинаете бежать и не останавливаетесь, пока не преодолеете 42 километра. Куда уж проще? То, что это нелегко, не отменяет простоты задачи. Быть лидером и менеджером тоже сложно, но по своей природе делать работу определенным образом ради достижения определенной цели – это просто.

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

УЧИМСЯ НА ОШИБКАХ

Человеческие существа отличаются практически уникальной [среди животных] способностью учиться на чужом опыте, но при этом удивляют очевидным нежеланием делать это.

Дуглас Адамс[7]

Мои исследования поставили меня перед вопросом: зачем добровольно страдать от ошибок и разочарований, когда можно избежать их? Если история древнего и современного управления проектами известна и нам платят за умные решения, независимо от источника вдохновения, почему так мало компаний вознаграждает людей за то, что они обращаются к урокам прошлого? Проекты выполняются или закрываются (а именно такая судьба ждет многие проекты

[8]), но причины этого анализируются редко. Создается впечатление, что менеджеры большинства организаций не вознаграждают людей за подобную информацию. Возможно, они боятся того, что можно обнаружить (и ответственности). Или никому не интересно анализировать неприятный, плачевный опыт, когда можно потратить время на новую задачу.

 

В своей книге «Инжиниринг и человеческий фактор: роль ошибки в успешном дизайне» (To Engineer Is Human: The Role of Failure in Successful Design, Vintage Books, 1992) Генри Петроски[9] объясняет, что ошибки нередко приводили к прорывам в разработках. Отчасти это происходит потому, что ошибки вынуждают нас быть внимательнее. Они требуют, чтобы мы пересмотрели предположения и принципы, о которых забыли (сложно притворяться, что все хорошо, когда прототип горит синим пламенем). Как говорил Карл Поппер[10], есть только два типа теорий: ошибочные и недоработанные. Без неудач мы самонадеянно забываем, что наше понимание несовершенно.

Смысл в том, чтобы учиться на чужих ошибках. Хотя детали провалов могут быть разными в зависимости от проекта, основные причины или ошибочные действия команды вполне можно применить к вашему случаю (и избежать их). Пора прекратить прятаться от поражений. Напротив, нужно рассматривать их как возможность чему-то научиться. Какие факторы стали причиной неудачи? Какие из них можно свести к минимуму или полностью исключить? Согласно Петроски, знания, которые мы черпаем из неудач, – самый богатый источник прогресса, если нам хватит смелости проанализировать, что произошло.

Возможно, именно поэтому в Boeing Company, одном из крупнейших в мире производителей авиационной техники, конструкторские просчеты становятся уроками

[11]. Boeing ведет свою черную книгу с момента основания компании и помогает инженерам извлекать опыт из ошибок прошлого. Поступая так, любая компания не только повышает шансы на успех проектов, но и создает условия для открытого обсуждения неудач, отрицает их или прячется. Мне кажется, разработчикам ПО тоже стоит вести черные книги.

Разработка, кухня и скорая помощь

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

Один мой знакомый разработчик уверен, что коль скоро принимает сложные решения – по проектированию, координации процесса, тестированию изменений за несколько часов или даже минут, затем выпуску продукта, – его проектам и обязанностям нет аналога во всей истории Вселенной. Он с гордостью перечислит все, чем овладел: CSS, XHTML, Flash, Ajax и другое – и станет убеждать, что пятьдесят лет назад эти технологии потрясли бы величайшие умы. Уверен, вам тоже доводилось встречать таких людей. Или, возможно, самим казалось, что до вас никто не решал такие сложные задачи.

Я предложил этому разработчику заглянуть «за кулисы» его любимого ресторана в разгар рабочего дня. Всем будет весьма полезно хоть раз получить представление о том, что творится на кухне (рекомендую блестящую книгу Энтони Бурдена «О еде: строго конфиденциально»[12]), однако сейчас я подразумеваю продуктивность. Когда люди впервые видят молниеносное управление и координацию работы на профессиональной кухне в разгар рабочего дня, им уже не кажется, что их работа самая сложная на свете. Повара жонглируют горячими сковородками с разными блюдами на разном этапе готовности, носятся между конфорками из одного угла кухни в другой, а официанты при этом вбегают и выбегают, сообщают о новых заказах, изменениях и проблемах.

И все это происходит в небольшом тесном помещении, где температура намного выше 30 градусов, под ярким флуоресцентным светом. И сколько бы заказов они ни готовили каждые несколько секунд, новые поступают примерно с той же скоростью. Иногда заказы возвращаются обратно, или, как в программных проектах, в последнюю минуту клиент вносит поправки (столик 1 не переносит лактозу, на столик 2 нужен соус и т. д.). Наблюдать за большими шумными кухнями – одно удовольствие. Хотя на первый взгляд кажется, что там царит полнейший хаос, большинство команд разработчиков только позавидует интенсивности и точности действий лучших кухонь.

Шеф-повара и линейные повара – менеджеры кулинарных проектов или, как называет их Бурден, регулировщики движения (кстати, еще одна профессия для вдумчивого изучения). Хотя персонал кухни работает в гораздо меньших масштабах и пользуется гораздо меньшим почетом, чем менеджер команды разработчиков, по ежедневной интенсивности их даже сравнивать нельзя. Если не верите, когда в следующий раз окажетесь в ресторане, спросите официанта, можно ли одним глазком посмотреть на работу кухни. Скорее всего, он откажет, но если все-таки согласится, вы не будете разочарованы. (В некоторых модных ресторанах и барах есть открытая кухня. Если найдете такую, сядьте поближе и понаблюдайте за одним из поваров хотя бы несколько минут. Смотрите, как размещаются заказы, как они отслеживаются, собираются и доставляются. Если на кухне аврал, то вы совершенно по-другому посмотрите на поиск и исправление ошибок в программах.)

Еще одна любопытная область – скорая помощь. Я смотрел по каналам Discovery и PBS, как небольшие команды врачей и медсестер оказывают пациенту помощь и находят выход из совершенно непостижимых ситуаций. Не удивительно, что именно врачи неотложной помощи изобрели процесс триажа[13], который применяется в разработке ПО для сортировки задач или ошибок в соответствии с приоритетами (подробнее – в главе 15).

В медицинской среде, особенно травматологии, находятся удивительные параллели для командной работы, принятия решений в условиях высокого стресса и результатов проекта, которые влияют на многих людей каждый день (на рисунке 1. 1 вы видите краткое сравнение с медициной и другими сферами работы). Как писал Атул Гаванде

Скотт Беркун, «Искусство управления ИТ-проектами» / Хабр

На рынке сейчас не так много хороших русскоязычных книг по теме управления проектами, хочется немного рассказать о тех, которые мне попались. Начну с этой:
Скотт Беркун, «Искусство управления IT-проектами» (O’REILLY)  ПИТЕР, 2007

Эта книга — одна из первых опубликованных книг Скотт Беркуна, опытнейшего «экс-менеджера» Microsoft (работал там с 1994-2003), участвовавшего в проектах Internet Explorer, Windows, MSN и др., а теперь занимающегося написанием книг и консультированием.

У Скотта есть собственный сайт, где можно подробнее узнать о его текущей деятельности: http://scottberkun.com/

Содержание


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

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

Стиль изложения


Нельзя с полной определенностью сказать, в чем причина – в плохом переводе, либо же в собственном стиле автора, но книга кажется «сухой» и написана скучновато. (Тут важно понимать, что моим идеалом «литературности» подобных книг, для меня являются книги ДеМарко, а далеко не каждому удается так писать).

Для кого эта книга


Сам автор позиционирует эту книгу как вполне универсальную (среди перечисления людей, которым будет полезно ее прочтение, автор указал: опытных и начинающих менеджеров проектов, программистов, тестеров (и других исполнителей) и даже студентов).
Мое личное впечатление – Скотт пытался составить максимально исчерпывающее руководство по управлению IT -проектами для начинающих менеджеров, впихнув в формат небольшой книги все этапы разработки ПО, с которыми он сталкивался. (При этом, увы, пострадала полнота изложения, иногда это весьма сильно видно).
Можно сказать, что книга больше предназначена для начинающих. Но и для опытных, практикующих, менеджеров проектов она будет весьма полезна, с точки зрения пере- и до-осмысления собственного опыта управления.
Лирическое отступление: Лично мне кажется, что такие книги вообще бессмысленно читать, не имея хоть какого-то опыта соответствующей деятельности. Они проходят через такого читателя не оставляя в нем никаких новых знаний или мыслей.

Резюме


Книга целиком «списана» с личного опыта автора. Это, с одной стороны – хорошо, поскольку постоянно приводятся реальные примеры из периода его работы в Microsoft, с другой стороны – не очень, поскольку иногда складывается впечатление, что анализом чужого опыта Скотт не занимался (то ли не хотел или не считал нужным, то ли просто было некогда).
Нельзя назвать эту книгу шедевром (содержание не совсем соответствует «яркому» названию), но крепким середнячком – вполне (даже с претензиями на «лидера», учитывая в целом небольшое количество хороших подобных книг).
Могу ее смело рекомендовать как начинающим руководителям проектов (даже совсем «зеленым», в качестве «руководства»), так и опытным (что бы еще раз задуматься о многих злободневных вопросах).
Небольшой комментарий: Начинающим менеджерам (или тем, кто планирует перейти в менеджеры) хочется посоветовать читать книгу осторожно, иногда в тексте встречаются яркие проявления «перекоса» в сторону субъективного взгляда автора, не забывайте – что у каждой компании свой, как это принято говорить, контекст.
По 5ти-бальной шкале книгу можно оценить следующим образом:
  • За содержание: 4
  • За стиль и качество изложения: 3+

определение scott berkun и синонимы scott berkun (английский)

scott berkun: определение scott berkun и синонимы scott berkun (английский)

арабский болгарский китайский язык хорватский Чешский Датский Голландский английский эстонский Финский французкий язык Немецкий Греческий иврит хинди Венгерский исландский индонезийский Итальянский Японский корейский язык Латышский Литовский язык Малагасийский норвежский язык Персидский Польский португальский румынский русский сербский словацкий словенский испанский Шведский Тайский турецкий вьетнамский

арабский болгарский китайский язык хорватский Чешский Датский Голландский английский эстонский Финский французкий язык Немецкий Греческий иврит хинди Венгерский исландский индонезийский Итальянский Японский корейский язык Латышский Литовский язык Малагасийский норвежский язык Персидский Польский португальский румынский русский сербский словацкий словенский испанский Шведский Тайский турецкий вьетнамский

содержание сенсагента

  • определения
  • синонимов
  • антонимов
  • энциклопедия

Решение для веб-мастеров

Александрия

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

Попробуйте здесь или получите код

SensagentBox

С помощью SensagentBox посетители вашего сайта могут получить доступ к надежной информации на более чем 5 миллионах страниц, предоставленных Sensagent.com. Выберите дизайн, который подходит вашему сайту.

Бизнес-решение

Улучшите содержание своего сайта

Добавьте новый контент на свой сайт из Sensagent by XML.

Сканирование продуктов или добавление

Получите доступ к XML для поиска лучших продуктов.

Индексирование изображений и определение метаданных

Получите доступ к XML, чтобы исправить значение ваших метаданных.

Напишите нам, чтобы описать вашу идею.

Lettris

Lettris — это любопытная игра-тетрис-клон, в которой все кубики имеют одинаковую квадратную форму, но разное содержание. На каждом квадрате есть буква. Чтобы квадраты исчезли и сэкономили место для других квадратов, вам нужно собрать английские слова (left, right, up, down) из падающих квадратов.

болт

Boggle дает вам 3 минуты, чтобы найти как можно больше слов (3 буквы и более) в сетке из 16 букв. Вы также можете попробовать сетку из 16 букв. Буквы должны располагаться рядом, и более длинные слова оцениваются лучше. Посмотрите, сможете ли вы попасть в Зал славы сетки!

Английский словарь
Основные ссылки

WordNet предоставляет большинство определений на английском языке. Английский тезаурус
в основном заимствован из The Integral Dictionary (TID).
English Encyclopedia лицензирована Википедией (GNU).

Перевод

Измените целевой язык, чтобы найти перевод.
Советы: просмотрите семантические поля (см. От идей к словам) на двух языках, чтобы узнать больше.

8016 онлайн посетителей

вычислено за 0,187 с

Руководство Монтгомери Скотта по навыкам управления проектами

Хотите научиться управлять проектами и не знаете, с чего начать? Скотти тебя прикрывает. Я не могу объяснить, как остановить прорыв в ядре варпа. К сожалению, я тоже не знаю, как изменить полярность. Но я знаю, что от Скотти можно многому научиться об основных навыках управления проектами. Это может показаться странным или даже совершенно странным.

Для тех, кто сбит с толку, я имею в виду Монтгомери Скотта, гениального главного инженера Starship Enterprise. Он, возможно, самый популярный шотландский фантастический персонаж всех времен. Он также вытащил «Энтерпрайз» из большего количества неприятностей и кризисов, чем я могу сосчитать.Независимо от того, являетесь ли вы давним поклонником «Звездного пути», как я, это руководство поможет вам развить навыки управления проектами.

Урок 1: Как стать чудотворцем в управлении проектами

В эпизоде ​​«Реликвии» из «Звездного пути: новое поколение» Скотти появляется после того, как несколько десятилетий застрял в транспортном средстве. Несмотря на то, что его технические знания несколько устарели, Скотти все же осознает важность управления ожиданиями — особенно ожиданиями капитана. Скотти шокирован, когда Джорди Ла Фордж (главный инженер Star Trek: The Next Generation), похоже, имеет совсем другое понимание ожиданий.

Лейтенант-коммандер Джорди Ла Форж: Да, хорошо, я сказал капитану, что сделаю этот анализ через час.

Скотти: Сколько времени это действительно займет?

лейтенант-коммандер Джорди Ла Форж: Час!

Скотти: О, вы не сказали ему, сколько времени * на самом деле * это займет, а?

лейтенант-коммандер Джорди Ла Форж: Ну, конечно, знал.

Скотти: О, дружище. Вам нужно многому научиться, если вы хотите, чтобы люди думали о вас как о чудотворце.

Укрепление репутации чудотворца — один из навыков управления проектами, о котором почти никто не говорит. Это не то, что можно увидеть в учебных пособиях PMP (во всяком случае, я никогда не видел). Когда вы управляете ожиданиями, как Скотти, гораздо легче преуспеть в реализации ваших проектов. Также важно отметить, что Скотт по-прежнему вносит ключевой вклад, несмотря на свои устаревшие технические навыки. Необязательно владеть всеми техническими навыками, чтобы стать успешным менеджером проекта.

Урок 2: Написание плана управления проектом, The Scotty Way

Планирование проектов — важный инструмент в вашем наборе навыков управления проектами. Чтобы гарантировать качество, чтобы запустить свои тесты, вам нужно знать, когда разработка программного обеспечения завершит тестируемую версию приложения. В «Реликвиях» Скотти делится одним из лучших советов, которые я видел по планированию управления проектами.

Скотти: Хороший инженер всегда немного консервативен, по крайней мере, на бумаге.

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

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

Урок 3: Поиск альтернатив

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

Находясь на планете в «Галилео Семь», Скотт пытается отремонтировать поврежденный корабль-шаттл. В отчаянии он обсуждает ситуацию с неукротимым научным сотрудником Энтерпрайза, мистером Споком:

Спок: Рассмотрите альтернативы, мистер Скотт.

Скотт: У нас нет топлива! Какие альтернативы?

Спок: Мистер Скотт, всегда есть альтернативы.

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

Урок 4: Станьте авторитетом: напишите книгу по теме

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

В «Реликвиях» Скотт и Ла Форж вместе работают над восстановлением поврежденного космического корабля до полной работоспособности. Корабль не эксплуатировался десятилетиями; У двух инженеров есть несколько вариантов. Только креативное мышление и авторитет, который приходит от написания о своей профессии, спасают ситуацию.

Скотти: Перенаправьте дейтерий из основного крионасоса во вспомогательный резервуар.

Лейтенант-коммандер Джорди Ла Форж: Эээ, танк не выдерживает такого давления.

Скотти: [смеется] Где ты… откуда ты взял эту идею?

Лейтенант-коммандер Джорди Ла Форж: Что вы имеете в виду, откуда я взял эту идею? Это указано в технических характеристиках импульсного двигателя.

Скотти: Регламент 42/15 — Различия в давлении в хранилище резервуаров IRC?

лейтенант-командир Джорди Ла Форж: Да.

Скотти: Забудь. Я это написал.

Показав, что он написал ключевые технические спецификации, Скотти демонстрирует свой инженерный авторитет.Как только этот момент раскрывается, Ла Форж быстро становится более склонным прислушиваться к предложениям Скотта. По той же причине большинство пациентов склонны следовать указаниям врачей: у них есть авторитет, основанный на их профессиональном опыте.

В 21 и веке у вас есть много возможностей написать о своем опыте. Вы можете писать статьи для публикаций по управлению проектами . Вы можете создать блог, чтобы поделиться своим опытом. Вы можете сделать презентацию на конференции, а затем написать статью.Если вам есть что сказать, вы можете написать книгу о Kindle (при правильном маркетинговом выборе публикация на Kindle также может быть прибыльной).

Урок 5: Благодарим команду проекта

Какое обсуждение навыков управления проектами было бы полным без полного обсуждения общения? В моей книге нет стоящего обсуждения. В «То, что выживает» Скотт успешно завершает опасный проект и спасает положение. По любым разумным меркам это большая победа. В своей работе вспомните, когда вы в последний раз завершали успешный проект.Вы относились к своей проектной команде как к мистеру Споку?

Мистер Спок: Мистер Скотт, вы выполнили свою задачу.

Lt. Cmdr. Монтгомери Скотт: По крайней мере, можно сказать спасибо.

Мистер Спок: С какой целью, мистер Скотт? Что в вас, люди…

Lt. Cmdr. Монтгомери Скотт: [бормочет] Ничего.

Мистер Спок:… что требует подавляющего проявления эмоций в такой ситуации? Двое мужчин следуют единственно разумному образу действий, и все же вы ЧУВСТВУЕТЕ, что необходимо что-то еще.

Очень важно потратить время и усилия, чтобы поблагодарить свою проектную команду. Ищете идеи, как выразить свою признательность? Вдохновляйтесь «Привычки дзен: 10 отличных способов показать, что вы благодарны сегодня». Если кто-либо из членов вашей проектной группы работает удаленно, я рекомендую написать короткое написанное от руки благодарственное письмо и отправить его им по почте.

Урок 6: Когда начинать бунт проекта

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

Пришло время для радикальных действий по спасению проекта. Но что именно вы можете сделать? Одна из стратегий — организовать бунт проекта вместе с членами вашей проектной группы.Продолжайте читать, чтобы узнать, как Монтгомери Скотт думал о планировании мятежа на «Энтерпрайзе».

Посмотрим, что Скотти сделает в этой ситуации? В «Turnabout Intruder» капитан Кирк ведет себя очень странно. Фактически, некоторые из старших офицеров подозревают, что капитан нездоров и непригоден для командования. Несмотря на их опасения, прямое действие против капитана пересекает черту. В конце концов, Скотт предлагает радикальные меры.

Скотт: Нам придется захватить корабль.

Доктор Маккой: Мы говорим о мятеже, Скотти.

Скотт: Да.

Как выглядит бунт проекта в корпоративном мире? Это может быть несколько форм. Вы можете напрямую позвонить спонсору проекта и выразить обеспокоенность проблемами проекта. Вы также можете предложить исключить из проекта особо проблемного человека. В случае серьезных неэтичных действий у вас всегда есть возможность уволиться. Эти радикальные варианты «мятежа» являются мощным оружием, которое можно использовать только в случае серьезной катастрофы проекта.

Урок 7: Очень простая тактика Скотти по укреплению доверия

Вы знаете, как Скотти продолжает добиваться успеха за успехом? Все сводится к очень простой тактике. Когда вы читаете эту тактику, вы, вероятно, киваете и думаете про себя: «Конечно, я знаю об этом». Это вечный принцип успеха в управлении проектами (или профессионального успеха). Тем не менее, очень многие люди прилагают усилия, чтобы реализовать тактику Скотти, чтобы завоевать и поддержать его авторитет. Читайте дальше, чтобы узнать об испытанной тактике Скотти по поддержанию авторитета за границей Enterprise.

В культовом классическом эпизоде ​​«Проблемы с трибблами» Скотти занимается одним из своих любимых занятий (и я не имею в виду наслаждение виски!). Это занятие, которое капитан Кирк не разделяет. Тем не менее, именно это стремление во многом стало причиной невероятного успеха Скотта как инженера.

Капитан Кирк: Еще один технический журнал, Скотти?

Скотт: Да.

Капитан Кирк: Вы никогда не расслабляетесь?

Скотт: Я расслабляюсь.

Давайте рассмотрим этот краткий разговор между Кирком и Споком.Чем Скотт занимается на досуге? Он читает технические статьи, чтобы быть в курсе последних технологий. Когда вы в последний раз читали журнал о своей профессии? А как насчет вашей отрасли? Легко сказать себе, что вы слишком заняты. Что, если бы вы узнали одну новую идею, которая все изменила? В этом сила следования проверенному временем принципу Скотта, чтобы оставаться на вершине своей области.

С чего начать, чтобы быть в курсе последних идей? На PMI есть отличные блоги — именно там я узнал уроки от тренеров чемпионатов мира, хотя обычно я не слежу за спортом.Вы также можете подписаться на крупное деловое издание, такое как Inc Magazine. Я также рекомендую прочитать классические книги по управлению проектами, такие как «Making Things Happen: Mastering Project Management» Скотта Беркуна.

Как оставаться любопытным

Надеюсь, вам понравилось читать Руководство Монтгомери Скотта по управлению проектами. Было приятно поделиться с вами этими идеями. При правильном отношении вы можете найти вдохновение и идеи везде, даже в художественной литературе. Это просто вопрос проявления вашего любопытства.Недавно я полностью посмотрел сериал Star Trek: The Original Series на Netflix: эти идеи постепенно всплыли на поверхность в течение нескольких недель. Меня восхищает, как можно долго впитывать идеи и истории, а потом внезапно приходит вдохновение!

Вопросы и действия

В соответствии с традицией «4-х часовой рабочей недели» Тима Феррисса, я закончу вопросом и предложу вам действие.

Вопрос: Какой ваш любимый урок управления проектами от Монтгомери Скотта?

Действие: Найдите идею из своей любимой художественной литературы — романа, рассказа, сериала или фильма — и воплотите ее в жизнь.

Поделитесь своими результатами и мыслями, комментируя эту статью.

Получите информационный бюллетень по электронной почте Friday 5

Советы, ресурсы и полезные советы по продуктивности, которые доставляются каждую пятницу!

Успех! Теперь проверьте свою электронную почту, чтобы подтвердить подписку.

PPT — Некоторые заметки от Berkun Art of Project Management Презентация PowerPoint

  • Некоторые заметки от BerkunArt of Project Management CS436 (материал для викторины) Луи

  • Документ о видении УПРОЩАЮЩИЙ эффект на проект Документ о видении — первый источник ЦЕЛЕЙ Документ о видении ОБЪЕДИНЯЕТ идеи из многих других источников. Он должен быть ВДОХНОВЛЯЮЩИМ Он должен быть ЗАПОМНИТЕЛЬНЫМ Пять качеств хорошего видения Луи

  • Какое одно предложение определяет этот конкретный выпуск этого конкретный проект? Как этот проект способствует достижению целей организации? Почему этот проект более актуален, чем другие? Ключевые моменты для обсуждения: видение Луи

  • Какие сценарии / функции для клиентов важны? Какие сценарии / функции для клиентов желательны, но не важны? Кто заказчики? Какие проблемы решает для них этот проект? Ключевые моменты для обсуждения: видение Луи

  • Кто является заинтересованными сторонами этого проекта (люди с полномочиями , которые не обязательно являются клиентами)? Почему эти клиенты будут покупать то, что мы предлагаем? Кто конкуренты и как будет сравниваться этот проект? Ключевые моменты для освещения: видение Луи

  • Что не будет частью этого проекта? Каким образом этот проект может провалиться и как минимизировать их вероятность? От чего зависят другие люди, вовлеченные в этот проект? Как будет делиться работа? Ключевые моменты, на которые следует обратить внимание: видение Луи

  • Трудно быть простым Чтобы хорошо писать, нужен один основной автор Объем не соответствует качеству Набросайте, просмотрите, исправьте! Избегайте: кухонной раковины, болтовни, бесхребетного бездельника, чего хочет вице-президент. Написание заявления о видении Луи

  • Покажи пользователю! Видение должно быть визуальным! Покажите данные и процесс! Луи

  • Дизайн = исследование: назначьте время для исследования Хорошие вопросы привлекают хорошие идеи: рассмотрите вопросы, которые привлекают внимание Плохие идеи часто приводят к хорошим идеям Мозговой штурм — это особый вид деятельности Опыт клиента начинается с дизайна Где идеи приходят от Луи

  • Идеи выходят из-под контроля Управление идеями дает твердую руку Изменения вызывают цепные реакции Творческая работа имеет импульс Контрольная точка этапы проектирования: видение / подтверждение концепции Альтернативы Спецификация Что делать с идеями Луи

  • Требования / ожидания Характеристики Технические характеристики / детали инженерного подхода Списки рабочих элементов: описание каждого задания по программированию, оценка времени, имена имен Критерии для тестирования / прохождение этапов Решение, что указать Loui

  • Заимствовать из других спецификаций! Избегайте жаргона и непонятного языка. Сохраняйте спецификации. Когда вы пишете, помните о конкретных читателях. Не давайте полных API, покажите некоторые детали. Опишите алгоритмы на высоком уровне. Получите обратную связь! Подробнее о спецификациях Loui

  • Лучшая работа людей: Слушайте и следуйте техническим советам Призывайте людей делать великие дела Вдохновляйтесь своими собственными чувствами о проекте Устраните препятствия для них Напомните им об их ролях Напомните им о целях проекта Обучайте и пусть учатся. Спросите их об их хорошей работе. Отношения Loui

  • Не раздражайте людей, e.g .: Предположим, я идиот. Не доверяй мне. Зря тратишь мое время. Управляй мной без уважения. Заставляй меня слушать или читать глупости. Отношения Луи

  • . «Иногда люди с большей властью, чем ты, навязывают тебе процессы . команда… «Защитите свою команду от процесса Ставка против процесса / встречное предложение Игнорировать процесс (будьте осторожны!) Отношения Луи

  • Не раздражающий адрес электронной почты: Краткий, простой, прямой Предлагает действие и крайний срок Приоритет Дону ‘ Я предполагаю, что люди читают его. Избегает воспроизведения.

  • Обзор: «Искусство управления проектами» Скотта Беркуна

    руд.com — Интернет-каталог: Искусство управления проектами

    О’Рейли недавно прислал мне обзорную копию книги Скотта Беркуна «Искусство управления проектами ». Я прочитал пару глав и, как рекомендовал сам автор, просмотрел кучу разделов, которые показались мне особенно интересными. Видите ли, у меня есть маркер для научно-популярной книги, которая действительно меня связывает — пока я читаю ее, я постоянно ругаюсь за то, что ее раньше не было.Я определенно чувствую это с этим.

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

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

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

    На книжном сайте О’Рейли есть PDF-файл с образцом главы (Глава 3: Как понять, что делать), чтобы дать вам представление. Но если ваша работа включает в себя какое-либо управление проектами, особенно в мире веб-разработки, вы можете взглянуть на это. Однако навыки, которые развивает Беркун, выходят за рамки роли одного члена команды — хорошее общение, соблюдение сроков и продвижение своей части проекта — это навыки, которые делают любого MVP команды.

    Управление изменениями: искусство балансирования

    Вкратце об идее

    Вы только что объявили об инициативе крупных изменений, которые выведут вашу компанию впереди ваших агрессивных конкурентов. Ответ ваших сотрудников? Гнев, тревога, отчуждение и замешательство. Зачем?

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

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

    Для успешной балансировки требуется:

    • Доверие сотрудников , которое вы создаете с помощью предсказуемости, — разъяснения намерений и основных правил компании и «умения говорить» — и способностей — артикуляции роли каждого человека в процессе изменений.
    • Сотрудник наделение полномочиями — искреннее приглашение каждому принять участие в создании желаемого будущего компании.

    Чтобы создать атмосферу доверия и расширения возможностей, вам нужна мощная структура поддержки: команда управления переходом.

    Идея на практике

    Группа управления переходом (TMT) имеет следующие обязанности:

    Установите контекст для изменений.

    • Через организованные обсуждения в компании TMT распространяет информацию о видении организации и конкурентной ситуации.После этого отдельные лица и команды могут согласовать свою деятельность с новым направлением компании.

    Стимулируйте разговор.

    • TMT организует ранние открытые обсуждения изменений между всеми подразделениями компании. Расплата? Прорывное мышление и новые идеи — от всех.

    Предоставить ресурсы.

    • TMT наделяет отдельных лиц конкретными полномочиями и предоставляет им ресурсы для правильного выполнения работы.Команда также может убивать проекты, не способствуя общему усилию.

    Координировать проекты.

    • По мере того, как компании переходят к быстрым программам изменений, количество команд и проектов увеличивается, равно как и неразбериха. TMT объединяет команды и проекты для поддержки более масштабных изменений и объясняет организации, как эти части сочетаются друг с другом.

    Обеспечьте соответствие сообщений и поведения.

    • Чтобы защитить доверие к усилиям по изменениям, TMT отслеживает и устраняет несоответствия между политиками руководства, мерами успеха и вознаграждениями (например,g., перенаправление менеджеров, которые поддерживают расширение прав и возможностей, но затем отбрасывают новые идеи).

    Предоставляем возможности для совместного творчества.

    • Чтобы предоставить сотрудникам реальную возможность вместе создавать будущее компании, TMT координирует и поддерживает обмен информацией, необходимой сотрудникам для принятия разумных решений и эффективных действий.

    Предвидеть и решать проблемы людей.

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

    Приготовьте критическую массу.

    • TMT обеспечивает доступность ресурсов и стратегий, необходимых для воспроизведения и передачи знаний, полученных в результате изменений.

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

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

    «Как будто в компании одновременно проходят пять медицинских процедур», — сказал он мне. «Один человек отвечает за лечение корневого канала, кто-то другой устанавливает сломанную ногу, другой работает со смещенным плечом, а третий — избавляется от желчного камня. Каждая операция проходит успешно, но пациент умирает от шока ».

    Проблема проста: мы используем механистическую модель, сначала примененную к управлению физической работой, и накладываем ее на новую ментальную модель сегодняшней организации знаний.Мы продолжаем разбивать изменения на мелкие кусочки, а затем управлять частями. Это наследие Фредерика Уинслоу Тейлора и научного менеджмента. Но при изменении задача состоит в том, чтобы управлять динамикой, а не частями. Задача состоит в том, чтобы обновлять умственную работу, а не копировать физическую работу. Цель — научить тысячи людей мыслить стратегически, распознавать закономерности и предвидеть проблемы и возможности до того, как они возникнут.

    Управление изменениями — это не то же самое, что управлять машиной или лечить человеческое тело по одному недугу за раз.Оба эти действия включают работу с фиксированным набором отношений. Правильная метафора управления изменениями — балансировка мобильного телефона. Сегодня большинство организаций реализуют ряд проектов в рамках своих усилий по внесению изменений. Организация может одновременно работать над TQM, реинжинирингом процессов, расширением прав и возможностей сотрудников и несколькими другими программами, предназначенными для повышения производительности. Но ключ к усилиям по изменению не в том, чтобы уделять внимание каждой части в отдельности; он соединяет и уравновешивает все части.В управлении изменениями важнейшей задачей является понимание того, как части уравновешивают друг друга, как изменение одного элемента меняет остальные, как последовательность и темп влияют на всю структуру.

    Одним из инструментов, который компании могут использовать для обеспечения этого критического баланса, является группа управления переходом, группа руководителей компании, подчиняющихся генеральному директору, которые посвящают все свое время и энергию управлению процессом изменений. Когда этот процесс стабилизируется, TMT распускается; до тех пор он наблюдает за корпоративными изменениями.Управление изменениями означает управление диалогом между людьми, возглавляющими усилия по изменению, и теми, от кого ожидается реализация новых стратегий, управление организационным контекстом, в котором могут происходить изменения, и управление эмоциональными связями, которые необходимы для любой трансформации.

    Вот как большинство компаний подходят к изменениям: генеральный директор или глава подразделения объявляют: «Мы должны внести некоторые изменения здесь. Следующие люди назначены в рабочую группу для разработки нашего нового дизайна.Целевая группа ответит мне через 90 дней ».

    Что произойдет дальше, можно предсказать. Целевая группа приступает к работе, закрываясь в конференц-зале, уделяя много времени тому, чтобы уложиться в срок. Члены не разговаривают ни с кем в организации. Они пытаются выработать собственную групповую динамику и проверяют множество возможных вариантов. Между собой они соглашаются: держать всех в курсе — это отвлечение, роскошь, которую они не могут себе позволить. Когда 90 дней истекут и пора доложить боссу, целевая группа найдет способ сообщить всем остальным, чего она достигла.

    Члены рабочей группы обычно соглашаются: держать всех в компании в курсе — это отвлечение, роскошь, которую они не могут себе позволить.

    Такой подход фактически гарантирует, что изменение не удастся. Предположение генерального директора и целевой группы: «Мы еще ничего не сказали, поэтому на самом деле мы не общаемся. Мы не отправляли никаких сообщений ».

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

    Когда целевая группа решает не информировать остальную часть организации о своей работе, она говорит: «Мы заняты выяснением вашего будущего — мы расскажем вам, что это такое, когда будем готовы.«Конечно, люди ненавидят информационный вакуум; когда в процессе изменений нет постоянного разговора, пустота заполняется сплетнями. Обычно слухи намного хуже и негативнее всего, что происходит на самом деле.

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

    Это обычный сценарий. Я видел, как это происходило в крупной компании, которая рассматривала возможность реструктуризации своей организации и переезда штаб-квартиры. Исполнительная группа, работающая над проектом, никогда не делала официального объявления. Но это не означало, что другие люди в организации не знали, что что-то происходит. Слова «Заседание комитета по реструктуризации» регулярно появлялись в календарях, которые секретари членов комитета вели для них.Люди заметили, что они тратили больше времени на этот проект, чем на любой другой. Мельница слухов сообщила, что, когда члены комитета выходили со своих собраний, они выглядели обеспокоенными.

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

    По прошествии девяти месяцев исполнительный комитет сделал официальное заявление — и даже это было сделано таким образом, чтобы свести к минимуму шанс для разговора.Каждый член комитета отправился в другое место и прочитал по одному и тому же сценарию на часовом собрании всей компании, которое состоялось в четверг. Объявление нельзя было назвать ужасным: комитет решил реструктурировать компанию и перенести ее штаб-квартиру в другой город. Увольнений не было, но тем людям, которые хотели получить работу в штаб-квартире, пришлось бы переехать. Из 35 000 компаний только около 1 500 сотрудников были затронуты этим решением.

    После объявления не было времени для вопросов и ответов, и не было обсуждения перехода.Руководители не сочли это необходимым, потому что в следующий понедельник они отправили папку с подробностями менеджерам пострадавших районов. Они решили, что лучше подождать, пока будет доступна вся информация, чем пытаться отвечать на вопросы сразу после объявления.

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

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

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

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

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

    До тех пор, пока менеджеры не послушали, не посмотрели и не поговорили достаточно, чтобы понять, что ответ на все эти вопросы — да, они вообще не общались.

    Согласно общепринятому мнению, изменение работает следующим образом: вы начинаете с того, что побуждаете людей принять новое корпоративное видение, тем самым изменяя их отношение. Затем они автоматически изменят свое поведение, что приведет к повышению эффективности работы компании. Увидев это улучшение, они подтвердят свою приверженность программе корпоративных изменений, и спираль успеха продолжится.

    Это могло произойти где-то в какой-то компании. Но чаще менеджеры, запускающие программу изменений, хотят, чтобы войска воодушевились; они хотят, чтобы их команда имела «выигрышную позицию».Поэтому, объявляя программу, они «ищут любви», стремясь убедить людей поверить в новое видение.

    К сожалению, в наши дни ожидать такой реакции от большинства компаний нереально. К настоящему времени войска прошли через столько программ, что относятся к ним скептически. Сегодня в компаниях полно «переживших перемены», циничных людей, которые научились жить в рамках программ изменений, не меняя по-настоящему. Их реакция противоположна обязательствам.Они говорят что-то вроде: «Я поверю в это, когда увижу» или «Конечно, звучит здорово, но что происходит, когда мы не подсчитываем числа?» Конечно, всегда есть энтузиасты. Все, что им нужно, — это разрешение попробовать новый подход. Но для других новая программа — всего лишь очередная причуда менеджмента в бесконечной череде управленческих причуд.

    К настоящему времени войска прошли через так много программ изменений, что относятся к ним скептически.

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

    Первое изменение в поведении должно произойти со стороны высшего руководства. Руководители должны спросить себя: «Если бы мы управляли так, как мы говорим, что хотим управлять, как бы мы действовали? Как мы будем решать наши проблемы? Какие встречи и разговоры у нас были бы? Кто будет участвовать? Как мы можем определить, распознать, компенсировать и вознаградить соответствующее поведение? » Когда лидеры и последователи работают бок о бок, чтобы найти ответы на эти вопросы, они вместе создают свое будущее.

    Например, один из популярных методов управления — опустить процесс принятия решений до самого нижнего приемлемого уровня. Звучит просто, обманчиво просто. Я присутствовал однажды утром, когда недавно просвещенный генеральный директор пошел на фабрику на собрание всех сотрудников. Он говорил о полномочиях и откровенности, а также о необходимости решить все вопросы. Затем он предложил всем присутствующим задать вопросы о том, что у них на уме. Один отважный рабочий поднял руку и спросил, почему директор завода может нести ответственность за оборудование стоимостью в миллионы долларов, но имеет право подписи только в размере 5000 долларов.

    «Хороший вопрос!» генеральный директор немедленно ответил. «Я так сильно верю в расширение прав и возможностей, что заработаю его полномочия на подписание в 1 миллион долларов».

    Работник, задавший вопрос, был впечатлен. Генеральный директор был в восторге. Директор завода был в ужасе. Что он узнал тем утром, что стоило 995 000 долларов? Кто поможет ему принимать решения, связанные с такими деньгами? Мог ли он ожидать пощады, когда совершил свою первую ошибку в размере 250 000 долларов? Генеральный директор сделал драматический жест любви, но упустил из виду важнейший элемент: он не подготовил директора завода к тому, чтобы взять на себя такую ​​большую ответственность.

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

    Расширение прав и возможностей не означает отказ. Определение контекста для изменений означает понимание того, что сотрудники делают и чего не знают.

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

    Снова и снова я был свидетелем одной и той же горькой истины: когда дело доходит до перемен, люди не верят в новое направление, потому что приостанавливают свое неверие.Они верят, потому что на самом деле видят поведение, действия и результаты, которые приводят их к выводу, что программа работает.

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

    На протяжении десятилетий менеджерам и рабочим велят сдерживать свои чувства за дверью. И это большая ошибка. Одно дело сказать, что поведение более доступно для менеджеров, чем чувства; совсем другое дело — сказать, что чувствам нет места в работе.

    В основе изменений лежат чувства; Компании, которые хотят, чтобы их сотрудники делали вклад своей головой и сердцем, должны признать, что эмоции необходимы для нового стиля управления. Старая парадигма менеджмента гласила, что на работе людям разрешается испытывать только те эмоции, которые легко контролировать, эмоции, которые можно отнести к категории «положительных».«Новая парадигма управления гласит, что управление людьми — это управление чувствами. Вопрос не в том, есть ли у людей «отрицательные» эмоции; вот как они с ними справляются. Фактически, наиболее успешные программы изменений показывают, что крупные организации напрямую связываются со своими людьми через ценности — и что ценности, в конечном счете, связаны с убеждениями и чувствами.

    Я видел классический пример этого в большой компании с более чем 100 000 сотрудников по всему миру, стремящейся разработать заявление о ценностях как способ сплотить своих людей.Управленческая команда взяла на себя интеллектуальную приверженность понятию ценностей, но за несколько месяцев не добилась больших успехов — пока однажды случайный прорыв не вывел их на другой уровень. Руководители собирались на встречу, но официальная повестка дня была отложена. Чтобы заполнить время, они вступили в неформальный разговор, задавая друг другу вопросы: «Что помогло вам сформировать ваши ценности? Как вы пришли к выводу, что у вас есть определенные ценности? »

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

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

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

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

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

    Раз в неделю люди могли посещать Жалкий город. Но им не разрешили туда переехать.

    Я видел этот процесс на работе в отделе информационных систем компании, которая подвергалась большой и сложной конверсии компьютеров.Вместо того, чтобы отрицать, что остальная часть организации предъявляет огромные требования к отделу и что все находятся в огромном стрессе, директор проекта решил признать, насколько сложным было преобразование. Первое, что он сделал, — это сшили футболки, достаточно большие, чтобы их можно было носить поверх рабочей одежды. На лицевой стороне были слова: «Да, это сложно». На обратной стороне было написано: «Но мы можем это сделать».

    Директор проекта также запланировал встречи во второй половине дня во вторник и пятницу с командой и их основными пользователями.Первые 15 минут группа посетит Жалкий город. Люди будут продолжать и продолжать с обычными жалобами, которые возникают в трудное время. Как группа, они могли осознать, насколько все это было ужасно на самом деле, но только на 15 минут. Затем в течение следующих 15 минут встреча превратилась в сессию хвастовства, где люди демонстрировали все маленькие победы — то, что сработало, то, как они обрадовали своих клиентов, проблемы, которые они превратили в успех. Одно правило заключалось в том, что каждый должен был хотя бы раз в неделю участвовать как в хвастовстве, так и в хвастовстве.

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

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

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

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

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

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

    Доверие во времена перемен основано на двух вещах: предсказуемости и способности. В любой организации люди хотят знать, чего ожидать; они хотят предсказуемости. Вот почему в разгар перемен доверие подрывается, когда меняются основные правила.Это особенно верно в отношении крупных, ранее успешных корпораций. В соответствии со старым психологическим контрактом между компанией и ее сотрудниками предсказуемость заключалась в неявном соглашении: в обмен на годы службы, пребывания в должности и лояльности сотрудники могли рассчитывать на работу. Карьерный путь тоже был предсказуемым. Например, инженер знал, что его или ее трудовая жизнь будет прогрессировать с определенной регулярностью, начиная с работы над небольшим проектом, затем над большим проектом, ведущим к назначению в качестве помощника менеджера, а затем к руководству.Была карта, по которой люди могли следовать, чтобы подняться в организации. Из-за увольнений и сокращения старый контракт был разорван. Пропал не только гарантированный карьерный рост, но и гарантия трудоустройства.

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

    Пример менеджера e

    Making Things Happen von Scott Berkun portofrei bei bücher.de bestellen

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

    Основываясь на своем девятилетнем опыте работы в качестве менеджера программ для Internet Explorer и ведущего менеджера программ для Windows и MSN, Беркун объясняет как техническим, так и нетехническим читателям, что нужно для реализации большого проекта программного обеспечения или веб-разработки. В «Making Things Happen» не упоминаются конкретные методы, но основное внимание уделяется философии и стратегии. В отличие от других книг по управлению проектами, Беркун предлагает личные эссе в удобном стиле и легком тоне, которые имитируют отношения мудрого менеджера проекта, который дает хорошие, увлекательные и страстные советы тем, кто спрашивает.

    Темы в этом новом издании включают:

    — Как добиться успеха

    — Принятие правильных решений

    — Технические характеристики и требования

    — Идеи и что с ними делать

    — Как не раздражать людей

    — Лидерство и доверие

    — Правда о свиданиях

    — Что делать, если что-то идет не так

    В комплекте с новым напоминанием автора и руководством для обсуждения для формирования групп / команд чтения, Making Things Happen предлагаются углубленные упражнения чтобы помочь вам применить уроки из книги к вашей работе.Это вдохновляющая, забавная, честная и убедительная книга, которая определенно является единственной книгой, которую вы и ваша команда должны иметь под рукой на протяжении всего жизненного цикла вашего проекта, исходя из редкой точки зрения человека, который участвовал в трудных битвах над крупнейшими проектами Microsoft и обучал проектированию и управлению проектами для MSTE, внутренней группы передового опыта Microsoft, это действительно ценный совет.

    Post A Comment

    Ваш адрес email не будет опубликован. Обязательные поля помечены *