• Деловое мышление. Правила, позволяющие принимать безошибочные решения — сразу и по любым вопросам
• Магия менеджмента

Блоги

• Agile Advice — Working With Agile Methods (Scrum, XP, Lean)

oz.by | ozon.ru | amazon.com

Первый среди равных. Как руководить группой проффессионалов. Дэвид Майстер и Патрик Маккенна
First Among Equals. How To Manage a Group of Professionals. David Maister, Patrick J. McKenna

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

В книге встречается довольно много советов, оформленных в виде списков, иногда складывается впечатление, что присутствуешь на презентации.

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

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

Моя оценка этой книге 4 с половиной звезды и только из за того, что она поздно мне попалась и некоторые темы были знакомы.

Ссылки по теме:

Некоторые отрывки вы можете прочитать на сайте издательства МИФ
Cайты авторов: Дэвид Майстер, Патрик Маккенна

Oz.by | Ozon.ru| Amazon.com

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

Автор книги Том Питерс по версии журнала “The Times” в 2007 году занимает 7-е место в рейтинге “The top 50 thinkers” Ну, наверное, потому он и гуру менеджмента, что имеет такие мысли и пишет такие книги.

Если попробовать охарактеризовать несколькими словами, то эта книга сносит башню, практически в прямом смысле этого слова. Во время чтения включается мозг который начинает генерировать просто огромное количество идей и переосмысливать происходящее с точки зрения автора. У меня не получилось прочитать эту книгу “запоем”, приходилось делать несколько перерывов, чтобы отдохнуть от энергии автора и дать улечся новым идеям и мыслям.

Питерс пишет свои книги в своеобразном и неповторимом стиле. Вот небольшой отрывок из книги

Что не так с этой картиной? Или: реформируйте ее!

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

На мой взгляд, ответ почти всегда — неизменное «Да!». Соответственно предлагаю вам рассмотреть следующие правила реформаторов, как я их называю:

Правило №1. Никогда не воспринимайте поставленную задачу буквально. Только идиоты воспринимают задания буквально! Те, кому суждено изменить мир (даже в минимальной степени), переиначивают любое задание до тех пор, пока оно не превратится в … по-настоящему классный WOW- БИХАГ-проект.

Правило №2. Вы никогда не сильны так, как во время вашего «бессилия». Когда вы действительно связаны по рукам и ногам? Когда за вами наблюдают! Каждый рассматривает малейший ваш шаг в электронный микроскоп. А вот когда вы официально бессильны … вы воистину свободны, чтобы вгрызться в любое поручение… и повеселиться на славу. Ваши махинации для «них» практически невидимы.

Правило №3. Каждый «маленький» проект содержит ДНК целой компании. Возможно, это «настоящий» секрет секретов: каждый маленький проект это … прозрачное окно … в душу организации, лучшее окно, чем «официальная политика».

Суммируя: вам не нужно официального проекта для штурма реальной возможности.

А теперь еще одна история. (Невыдуманная…)

«Мы с женой пошли на родительское собрание (в детсад), — пишет Джордан Айан в своей амечательной книге о креативности — нам сообщили, что наш начинающий художник (Кристофер) получит «неуд» по рисованию. Мы были шокированы. Как может ребенок — не говоря уже о нашем ребенке — получить плохую оценку по рисованию в таком юном возрасте? Его учительница сообщила нам, что

он отказался закрашивать
картинку, не выходя за контуры…

что являлось государственным требованием к «моторным навыкам данного возраста».

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

Вся власть менеджерам проектов!

Чарльз Уонг, блистательно умный и раздражительный основатель Computer Associates — штатный «противник» в отрасли программного обеспечения. Он и Белл, похоже, появились на свет из одного горохового стручка. Логика Уонга: проектная команда отстает от графика? Ну, и что делать? Удвоить активы (количество людей)? Нет, только не в мире-в-котором-живет-Уонг. Проектная группа отстает от графика? Уонг говорит: выявите в команде 25% наименее продуктивных парней… и устраните их.

Читателем предлагают мыслить красиво, мыслить странно и осмыслить гораздо больше «изменений», чем мы могли себе представить раньше.

Вы можете скачать и ознакомится с одной из глав книги с оффициального сайта Тома Питерса

Так же хочется порекомендовать другие не менее интересные книги этого замечательного автора

Проект. 50 верных способов превратить любое задание в грандиозный проект!
Oz.by | Ozon.ru

Человек-бренд
Oz.by | Ozon.ru

Профессиональная сервисная фирма
Oz.by | Ozon.ru

Немного об авторе

Питерс появился на общественной сцене в 1982 году с выходом написанной в соавторстве с Бобом Уотерменом книги «В поисках превосходства», которая возглавляла списки бестселлеров более двух лет. После «Поисков» Питерс выпускает «Страсть к превосходству» (1985, совместно с Нэнси Остин); «Пир во время хаоса» (1987); «Управление освобождением» (1992); «Семинар Тома Питерса» (1993); «Преследуя WOW» (1994); «Круг инновации» (1997); «Проект-50» (1999); «Брэнд твоего имени—50» (1999) и «Фирма профессиональных услугг—50» (1999). Недавно вышли две биографии Питерса: «Корпоративный человек корпоративному скунсу: феномен Тома Питерса» Стюарта Крейнера и «Том Питере: популярный пророк революции в улравлении» Роберта Хеллера.
Кроме писательской деятельности, Том Питерс занимается проведением семинаров — около 80 в год — и является председателем Tom Peters Company. За его плечами две научные степени по инженерно-строительной специальности, две степени в бизнесе и почетные ученые звании; четыре года действительной службы в американском Военном флоте (и походы во Вьетнам); работа в Белом доме в группе, занимавшейся проблемой злоупотребления наркотиками; и восемь лет в МсKinsey &Co, где он впоследствии стал одним из партнеров.

Как пасти кур. Нестандартное управление проектами
Дэвид Гарретт, Дэн Бредбери

Herding Chickens: Innovative Techniques for Project Management
by Dan Bradbary, David Garrett

Оценка: 4

Oz.by | Ozon.ru | Amazon.com

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

В целом книга больше напоминает большой набор рекомендаций по разным аспектам управления проектами, так сказать коллекция tips and tricks и классических рекомендаций, читается очень легко и совсем не скучно.

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

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

Еще понравилось несколько афоризмов:

— В офисе мы все носимся, как куры с отрубленными головами. Поэтому «выпас кур» — это подходящая метафора для описания работы менеджера проекта — главного петуха в капиталистическом курятнике.

— Текучка это когда даже самые лучшие работники иногда попадают под грузовики с пивом.

— Если вы собираетесь разводить кур и принебрегать основами птицеводства — это некомпетентность

— Первое впечатление от человека — самое верное, так как он еще не знает что от вас скрывать.

oz.by | ozon.ru | amazon.com

Шедевр от Тома ДеМарко «Deadline. Роман об управлении проектами». TomDemarco «Deadline: A Novel About Project Management»

Самый захватывающий роман, которые я читал за последние лет 5. Прекрасная подача материала. Одним словом must read каждому кто каким либо образом занимается управлением. Управление проектами — это прежде всего работа с людьми. Приведу все выдержки из записной книжки главного героя, думаю полезно будет их иметь всегда под рукой.

Из записной книжки мистера Томпкинса

Безопасность и перемены

1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
3. Неуверенность заставляет человека избегать риска.
4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.

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

Части тела, необходимые для управления проектами
1. Для руководства нужны сердце, нутро, душа и нюх.
2. Так что:
• руководить надо сердцем;
• чувствовать нутром;
• вкладывать в команду и проект душу;
• иметь нюх на всякую ерунду и бессмыслицу.

Собеседование и прием на работу.
1. Чтобы нанять человека на работу, менеджеру необходимы все его способности: сердце, душа, нюх и способность чувствовать нутром (по большей части последнее).
2. Не пытайтесь нанимать людей в одиночку — гораздо лучше задействовать в этом процессе интуицию двух менеджеров.
3. Попросите новых членов команды взяться в проекте за ту работу, которую им уже случалось успешно выполнять в прошлом, а прочие амбиции и рост отложить до следующего проекта.
4. Попросите наводку — тот человек, которого вы выбрали себе в команду, наверняка может посоветовать, кого вам еще следует нанять.
5. Больше слушайте, меньше говорите.

Повышение производительности
1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
2. Повышение производительности — результат долгосрочных усилий.
3. Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как обман.

Управление рисками
1. Чтобы управлять проектом, достаточно управлять его рисками.
2. Создайте список рисков для каждого проекта.
3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
4. Оцените вероятность возникновения и стоимость каждого риска.
5. Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.
6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.
7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.

Играй в защите
1. Сокращайте потери.
2. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
3. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
4. Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
5. Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
6. Считайте, что команда, которая хочет продолжать работать вместе и дальше, — это одна из основных целей любого проекта.
7. День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
8. Есть тысяча и один способ потратить день зря и ни одного, чтобы вернуть этот день обратно.

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

Извращенная политика
1. В любой момент нужно быть готовым отказаться от работы и попросить расчет…
2. …однако это не означает, что тем самым вы сумеете избежать последствий извращенной политики.
3. Извращенная политика достанет вас везде, даже в самой здоровой и чистой организации.
4. Главный признак извращенной политики: во главу угла ставятся личные цели и влияние, а не общие интересы компании.
5. Это может произойти даже тогда, когда личные цели напрямую противоречат целям организации.
6. Один из побочных эффектов извращенной политики: иметь хорошо укомплектованную команду становится небезопасно.

Сбор метрических данных
1. Определяйте размер каждого проекта.
2. Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
3. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
4. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
5. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
6. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
7. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
8. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.

Процесс разработки и его улучшение
1. Хороший процесс разработки и его постоянное улучшение — весьма достойные цели.
2. Но существуют еще и рабочие цели и задачи: хороший работник сконцентрирует внимание как раз на них, даже если вы его об этом не просили.
3. Формальные программы, направленные на улучшение существующего процессе разработки, будут дорого стоить команде — и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то даже если это и произойдет, то едва ли выгоды от этого повышения покроют затраты.
4. Можно надеяться получить положительный результат от одного какого нибудь хорошо взвешенного и тщательно выбранного усовершенствования в методике работы. В этом случае оно может покрыть деньги и время, потребовавшиеся на его внедрение.
5. Попытка внедрить более одного усовершенствования методологии — гиблое дело. Программы, направленные на улучшение многих приемов и навыков (например, переход на следующий уровень СММ), скорее всего приведут к тому, что сроки только увеличатся.
6. Опасность стандартизированного процесса разработки состоит в том, что за рутинными операциями люди могут не заметить возможность сэкономить время и усилия по разработке проекта.
7. Что касается чрезмерно больших команд, то там стандартизированный процесс будет неукоснительно соблюдаться до тех пор, пока он позволяет всем чувствовать себя при деле (не важно, с пользой для проекта или нет).

Делать работу по другому
1. Есть только один способ сократить время на разработку, когда его и без того мало — уменьшить сроки отладки программы.
2. Проекты с высокой производительностью требуют гораздо меньше времени на отладку и исправление ошибок.
3. Проекты с высокой производительностью требуют гораздо больше времени на проектирование.
4. Нельзя заставить людей делать что то по другому, если ты о них не заботишься, если ты ими не интересуешься. Чтобы они изменились, ты должен понимать (и ценить) их самих, что они делают и к чему стремятся.

Что дает давление сверху
1. Люди не начнут быстрее соображать, если руководство будет давить на них.
2. Чем больше сверхурочной работы, тем ниже производительность.
3. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
4. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.
5. Ужасная догадка: давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.

Сердитый начальник
1. Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать их поведение. Точно так же дети, которых наказывали в детстве, часто впоследствии становятся жестокими родителями.
2. Неуважение и злоба, по мнению некоторых начальников, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но разве когда нибудь неуважение со стороны начальства приводило к тому, что люди начинали лучше работать?
3. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не признак того, что у него плохие подчиненные).

Туманные спецификации
1. Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.
2. Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению. Это значит, что она попросту ничего не специфицирует.
3. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.

Конфликт
1. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.
2. Процесс создания и распространения программных систем — прямо таки рассадник всевозможных конфликтов.
3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.
4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
6. Тяжело договариваться. Гораздо легче выступать посредником.
7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
8. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.

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

О персонале
1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую то работу).
2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.
3. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.
4. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!

Проблемы социологии
1. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня, а потом всегда строго ее придерживаться.
2. Каждому проекту нужна какая то церемония или ритуал.
3. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т. п.
4. Защищайте людей от оскорблений и ругани Начальства.
5. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего то очень боятся.
6. Наблюдение: если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)

О патологической политике (еще раз)
1. Эту патологию невозможно вылечить снизу.
2. Не стоит терять время или подвергать себя опасности, чтобы проверить предыдущий постулат на собственном опыте.
3. Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.
4. Чудеса, конечно, случаются, но лучше все же на них не рассчитывать.

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

Основы здравого смысла
1. У проекта должно быть два срока сдачи — запланированный и желаемый.
2. Эти сроки должны быть разными.

Причитал на днях книгу «Waltzing With Bears — Managing Risk on Software Projects» Tom DeMarco and Timothy Lister.
В русском варианте «Вальсируя с медведями. Управление рисками в проектах по разработке программного обеспечения.»
Том Демарко и Тимоти Листер.

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

В книге описано средство для моделирования рисков Riskology Simulator и как им пользоваться.

Вот некоторые выдержки из книги которые хотелось бы отметить:

Не беритесь за проект если в нем нет рисков

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

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

Краткий список основных рисков:

1. внутренние изъяны календарного планирования
2. раздувание требований (изменение требований)
3. текучесть кадров
4. нарушение спецификаций
5. низкая производительность

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

Мы совсем неплохо оцениваем. Нам просто плохо удается перечислять все допущения, лежащие в основе наших оценок.

PS: пока писал заметку нашел первый специализированный книжный магазин с книгами по управлению проектами — PM books