Deadline. Краткое содержание книги Т. ДеМарко
Том ДеМарко написал историю об опытном руководителе, который попал в некую воображаемую страну, где в различные правила управления вносились поправки «сверху». Главный герой — менеджер Вебстер Томпкинс — мистическим образом оказывается в бывшей социалистической республике Моровии с тоталитарным режимом управления, где он был назначен руководителем нескольких проектов по созданию программного обеспечения.
Все принципы управления проектами описаны здесь в интересной и ненавязчивой форме — форме бизнес-романа.
Найдите правильных людей. Потом, что бы вы ни делали, какие бы ошибки ни допускали, люди вытащат вас из любой передряги. В этом и заключается работа руководителя.
— Вам не кажется, что у вас неоправданно много людей для каких-то шести проектов?
Томпкинс посмотрел на список проектов, которые отобрал для него Великий Вождь Народов.
— Понятно, — сказал он. — У нас тут работа всего-то для сотни человек.
— Верно. А что вы будете делать с остальными?
— Ума не приложу. Вы считаете, что я должен решать эту проблему? Ну, пусть тогда пойдут в отпуск.
— Это не проблема, Вебстер. Это ваш шанс. Шанс совершить небывалый эксперимент в управлении проектами. Неужели вам никогда не хотелось доподлинно узнать, как бы команда справилась с проектом, если бы использовала не эту, а другую методологию?
Неужели вам не интересно было бы дать одну и ту же задачу разным командам? Двум, трем…
Глаза мистера Томпкинса загорелись:
— Эксперимент… Одна команда работает под жестким контролем, другая — под умеренным, третья — практически свободно, и все три решают одну и ту же задачу. А мы смотрим, какая из них быстрее закончит. Всю жизнь мечтал сделать что-то подобное. Можно создать многочисленную команду, малочисленную и команду с оптимальным, на мой взгляд, числом участников…
— В одну команду набрать только опытных специалистов, в другую — опытных и новичков, — продолжила Лакса.
Но мистер Томпкинс уже насквозь проникся идеей.
— В одну набрать людей, которые уже работали вместе, и посмотреть, как они будут соревноваться с командой, где никто раньше друг друга не знал. Если мы это сделаем, то сможем разгадать одну из величайших загадок менеджмента. Мы узнаем, почему одним проектам сопутствует успех, а другим — нет.
— Все в ваших руках, Вебстер. Можете экспериментировать над всей Моровией, вот она, первая в мире Лаборатория по управлению проектами.
Томпкинс получил в подарок записную книжку, в которую он должен был записывать те открытия, которые он сможет сделать в процессе работы.
На первой странице тоже была сделана запись: Четыре основных правила менеджмента.
1. Найти нужных людей.
2. Дать им ту работу, для которой они более всего подходят.
3. Не забывать о мотивации.
4. Сплотить команду и поддерживать ее в состоянии сплоченности. (Все остальное — административная ерундистика.
)
Из записной книжки мистера Томпкинса
Безопасность и перемены
1. Человек противится переменам, если не чувствует себя в безопасности.
2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
3. Неуверенность заставляет человека избегать риска.
4. Избегая риска, человек упускает новые возможности и выгоды, которые могли бы принести ему перемены.
5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет тот же.
Отрицательная мотивация
6. Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
7. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
8. Если люди не справятся с поставленной задачей, вам придется привести в действие свои угрозы.
Люди всегда идут за сердцем, а не за головой. Они никогда не будут с вами просто потому, что вы невероятно умны, или потому, что вы всегда принимаете правильные решения. Они идут за вами, потому что любят вас. Понимаю, звучит немного странно, но это правда. Все мои бывшие руководители были сердечными людьми. Сердце большое, как дом, делает любого лидера истинным лидером. Конечно, есть менеджеры, которые руководят головой, а не сердцем, но за ними никто никогда не пойдет.
Части тела, необходимые для управления проектами
9. Для руководства нужны сердце, нутро, душа и нюх.
10. Так что:
- руководить надо сердцем;
- чувствовать нутром;
- вкладывать в команду и проект душу;
- иметь нюх, чтобы отличать полезное от бессмысленного.
Главнокомандующий на поле битвы как метафора управления проектами. К началу сражения работа главнокомандующего уже закончена.
Собеседование и прием на работу
11.
Чтобы нанять человека на работу, менеджеру необходимы все его способности: сердце, душа, нюх и способность чувствовать нутром (в наибольшей степени — последнее).
12. Не пытайтесь нанимать людей в одиночку — гораздо лучше задействовать в этом процессе интуицию двух менеджеров.
13. Поручите новым сотрудникам ту работу, которую им уже случалось успешно выполнять в прошлом, а профессиональный рост и амбиции пусть подождут до следующего проекта.
14. Попросите наводку: человек, которого вы взяли себе в команду, наверняка может посоветовать, кого еще следует нанять.
15. Больше слушайте, меньше говорите.
Повышение производительности
16. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность роботы.
17. Повышение производительности — результат долгосрочных усилий.
Продолжение — на Smart Reading
Зарегистрируйтесь на Smart Reading и получите доступ к этому и ещё 800 пересказам нонфикшен-книг.
Для многих книг есть инфографика. Все пересказы озвучены, их можно скачать и слушать фоном. Фрагмент озвучки:
Первые 7 дней доступа — бесплатно.
Быстрая регистрация
Том ДеМарко Deadline: Роман об управлении проекта…
Том ДеМарко Deadline: Роман об управлении проектами by Vsevolod Ustinov1. Руководство ИТ-проектами:
1.1. найти нужных людей
1.2. дать им ту работу, для которой они подходят больше всего
1.3. не забывать о мотивации
1.4. сплотить команду и поддерживать её
1.5. всё остальное — административная ерундистика
2. Безопасность и перемены
2.1. Если человек не чувствует, что находится в безопасности, он будет противиться переменам.
2.2. Перемены необходимы руководителю для успешной работы (наверняка они необходимы и в любой другой деятельности).
2.3. Неуверенность заставляет человека избегать риска.
2.4. Избегая риска, человек упускает все новые возможности и выгоды, которые могли бы принести ему перемены.
2.5. Человека легко запугать прямыми угрозами, но также можно просто дать ему понять, что при случае с ним могут обойтись грубо и жестоко. Эффект будет таким же.
3. Отрицательная мотивация
3.1. Угрозы — самый неподходящий вид мотивации, если вас волнует производительность сотрудников.
3.2. Чем бы вы ни угрожали, задача все равно не будет выполнена, если с самого начала вы отвели на ее выполнение слишком мало времени.
3.3. Более того, если люди не справятся, вам придется выполнить свои обещания.
4. Повышение производительности
4.1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность работы.
4.2. Повышение производительности — результат долгосрочных усилий.
4.3. Любые средства для повышения производительности, которые обещают немедленный результат, на самом деле не что иное, как «птичье молоко».
5. Управление рисками
5.1. Чтобы управлять проектом, достаточно управлять его рисками.
5.2. Создайте список рисков для каждого проекта.
5.3. Отслеживайте те риски, которые являются причиной провала проекта, а не только конечные риски.
5.4. Оцените вероятность возникновения и стоимость каждого риска.
5.5. Для каждого риска определите показатель — симптом, по которому можно определить, что риск превращается в проблему.
5.6. Назначьте специального человека для управления рисками, и пусть он не поддерживает девиз «Мы можем все!», который культивирует начальство.
5.7. Создайте доступные (возможно, анонимные) каналы для сообщения плохих новостей руководству.
6. Игра в защите
6.1. Сокращайте потери.
6.2. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам.
6.3. Чем раньше вы прекратите ненужную работу, тем лучше для всего проекта.
6.4. Не пытайтесь создавать новые команды без необходимости; поищите в коллективе уже сложившиеся и сработавшиеся команды.
6.5. Оставляйте команды работать вместе и после окончания проекта (если они сами того хотят), чтобы у пришедших вам на смену руководителей было меньше проблем с плохо срабатывающимися командами.
6.6. Считайте, что команда, которая хочет продолжать работать вместе и дальше — это одна из основных целей любого проекта.
6.7. День, который мы теряем в начале проекта, значит так же много, как и день, потерянный в конце.
7. Сбор метрических данных
7.1. Определяйте размер каждого проекта.
7.2. Не усердствуйте поначалу с выбором единицы измерения — если впоследствии вам предстоит работать с реальными данными, для начала сойдут и абстрактные единицы.
7.3. Стройте сложные метрики на основе простых (тех, которые легко подсчитать в любом программном продукте).
7.4. Собирайте архивные данные, чтобы считать производительность труда по уже законченным проектам.
7.5. Работайте над формулами вычисления сложных синтетических метрик до тех пор, пока полученные результаты не будут наиболее точно отражать отношение абстрактных единиц к указанному в архивных данных объему работ.
7.6. Проведите через всю архивную базу данных линию тренда, которая будет показывать ожидаемый объем работ в виде отношения значений сложных синтетических метрик.
7.7. Теперь для каждого нового проекта достаточно будет высчитать значение синтетической метрики и использовать ее при определении ожидаемого объема работ.
7.8. Не забывайте об «уровне помех» на линии производительности и используйте его, как индикатор при определении допустимых отклонений от общей траектории.
8. Что дает давление сверху
8.1. Люди не начнут быстрее соображать, если руководство будет давить на них.
8.2. Чем больше сверхурочной работы, тем ниже производительность.
8.3. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда плохо.
8.4. Возможно, руководство так любит применять давление, потому что просто не знает, как еще можно повлиять на ситуацию, или же потому, что альтернативные решения кажутся им слишком сложными.
8.5. Давление и сверхурочная работа призваны решить только одну проблему — сохранить хорошую мину при плохой игре.
9. Сердитый начальник
9.1. Злость и неуважение заразительны. Когда высшее руководство демонстрирует злость и неуважение к подчиненным, руководители среднего звена начинают копировать их поведение.
9.2. Неуважение и злоба, по мнению некоторых начальников, должны заставить подчиненных лучше работать. Это типичная политика «кнута и пряника». Но разве когда-нибудь неуважение со стороны начальства приводило к тому, что люди начинали лучше работать?
9.3. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность (а вовсе не признак того, что у него плохие подчиненные).
10. Туманные спецификации
10.1. Неясность спецификации говорит о том, что между участниками проекта есть неразрешенные конфликты.
10.2. Спецификация, в которой нет списка типов входящей и исходящей информации, не должна даже приниматься к рассмотрению.
Это значит, что она попросту ничего не специфицирует.10.3. Никто никогда не скажет вам, что спецификация плоха. Люди скорее будут обвинять себя в неспособности понять написанное, чем ругать авторов спецификации.
11. Конфликт
11.1. Проект, в котором участвуют несколько сторон, обязательно столкнется с конфликтом интересов.
11.2. Процесс создания и распространения программных систем — прямо таки рассадник всевозможных конфликтов.
11.3. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов.
11.4. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
11.5. Донесите до каждого, что постараетесь учитывать интересы всех участников, и проследите, чтобы так оно и было.
11.6. Тяжело договариваться. Гораздо легче выступать посредником.
11.7. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника.
11.8. Не забывайте: мы находимся по одну сторону баррикад. По другую сторону находится сама проблема.
12. Кто такой катализатор проекта
12.1. Существуют люди катализаторы. Они помогают создать здоровую команду, отношения, боевой дух. Даже если бы они больше ничего не делали (а как правило, они делают куда как много), их роль в проекте остается одной из наиболее важных.
12.2. Посредничество — еще одна сфера, в которой люди катализаторы просто незаменимы. Впрочем, посредничеству можно научиться, это не очень сложно.
12.3. Первым шагом к посредничеству должна быть маленькая церемония. Например, можно произнести фразу: «Вы позволите мне попробовать помочь вам решить этот спор?»
13. Проблемы социологии
13.1. Собрания должны быть небольшими. Для этого нужно сделать так, чтобы люди не боялись пропускать ненужные им собрания. Самый простой способ — заранее опубликовать повестку дня, а потом всегда строго её придерживаться.
13.2. Каждому проекту нужна какая-то церемония или ритуал.
13.3. С помощью церемоний можно концентрировать внимание собравшихся на основных целях и задачах совещания: сократить состав рабочей группы, повысить качество программного кода и т. п.
13.4. Защищайте людей от оскорблений и ругани Начальства.
13.5. Запомните: в работе страх = гнев. Те руководители, которые любят кричать на своих подчиненных и всячески унижают и оскорбляют их, на самом деле просто чего-то очень боятся.
13.6. Если бы для всех проявление грубости и злости к подчиненным всегда значило бы, что начальник просто боится, то никто из начальников не стал бы так себя вести просто из страха, что его страх станет заметен! (Это, конечно, не решает проблем такого руководителя, но, по крайней мере, оберегает его подчиненных.)
14. О персонале
14.1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую-то работу).
14.2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.
14.3. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
14.4. Те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!
15. Человеку свойственно ошибаться
15.1. Нам кажется, что самое страшное — не знать чего то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.
16. О паталогической политике
16.1. Эту патологию невозможно вылечить снизу.
16.2. Не стоит терять время или подвергать себя опасности, чтобы проверить предыдущий постулат на собственном опыте.
16.3. Иногда единственным выходом из ситуации становится выжидание. Попробуйте подождать, пока проблема не разрешится сама по себе или пока вы не найдете способ уйти от нее в сторону.
16.4. Чудеса, конечно, случаются, но лучше всё же на них не рассчитывать.
17. Злоба и скупость
17.1. Злоба и скупость — вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.
17.2. Злоба и скупость прямо противоположны истинным целям любой хорошей компании — быть щедрыми и заботливыми по отношении к своим сотрудникам.
17.3. Когда вы подмечаете в компании проявления злобы и скупости, знайте, их настоящая причина — страх и боязнь провала.
18. Основы здравого смысла
18.1. У проекта должно быть два срока сдачи — запланированный и желаемый.
18.2. Эти сроки должны быть разными.
Рецензия на книгу — Том ДеМарко: «Крайний срок: Роман об управлении проектами» или начало PM для новичков | by Horizon
5 мин чтения·
3 мая 2019 г.
Рано или поздно каждый человек получает ряд так называемых «рабочих» вопросов. Работаю я там или нет, что для меня важнее: деньги или саморазвитие, готов ли я посвятить всю свою жизнь именно этому делу — эти и многие другие болезненные моменты застревают у нас в голове. Большинство из нас просто терпит и в итоге выгорает, кого-то все устраивает. Но есть часть нас, которая твердо верит в возможность найти свое место.
Не так давно узнал себя в прошлой части. Окончив учебу и проработав два с половиной года экспедитором, я понял, что офисная рутина меня убивает, и так начался путь «самопоиска». Мое внимание через некоторое время остановилось на «Менеджере проектов», огромном количестве сайтов, советах знакомых и множестве внутренних ссор. Но как только IT-сфера стала для меня луной, пришло время учиться.
Вот и возникает главный вопрос: с чего начать? Сотни статей, несколько книг, «ИТ-лексикон» и страхи. Позже я начал читать книгу к Том ДеМарко: «Крайний срок: Роман об управлении проектами».
Как по мне, эта книга как раз для начинающего PM, если он не хочет утонуть в море информации, задать впечатление от работы и структурировать понимание своих задач.
Том ДеМарко — выдающийся американский программист, умевший спрятать в легком чтении простую, лаконичную и понятную бизнес-книгу. Эта книга с первых страниц заставляет забыть, что де-факто читаешь серьезную литературу: следишь за развитием сюжета, где-то сопереживаешь главному герою, где-то умиляешься его наивности как руководителя, но всегда интересно .
В то же время «Крайний срок: Роман об управлении проектами» полезен новичку именно из-за стиля написания. В каждой главе в иронической форме описываются различные ситуации, как положительные, так и отрицательные. Каждый ПМ может попасть в них в будущем. Здесь можно найти разные примеры: процесс подбора команд и интересных проектов, конфликтные ситуации в процессе работы и ультиматум бизнесмена-министра, постоянно вставляющего палки в колеса.
При этом Том ДеМарко не дает новичку забыть о том, что в первую очередь его книга — это учебное пособие. Он резюмирует каждую главу основными тезисами: «Г-н. Журнал Томпкинса». На мой взгляд, каждый начинающий PM должен их записать и выучить наизусть. Именно из-за этих правил вы должны прочитать эту книгу — они помогают вам сформировать четкую последовательность действий, понять всю гибкость и изменчивость в сфере проектов и особенно в сфере человеческих отношений, научиться гармонировать и находить общее. знаменатель «реальных» и «желаемых» результатов. Ниже я привел три примера этих правил, которые пригодились мне в реальной жизни.
- «Никто не скажет вам, если спецификация плохая. Люди склонны винить себя, а не его».
И это правда, все боятся выглядеть глупо, особенно перед своим начальником. Я никогда не был на ведущей стороне в таких ситуациях, но я уже был молчаливым человеком. При разработке приложения для охотников я заметил разницу между зверем и его криками из-за моего интереса к животному миру в целом.
Обратив на это внимание моих коллег, мы смогли вовремя сообщить об этом нашему клиенту и заменить звонки на правильные. Так что не нужно бояться что-то сказать. Думаю, лучше несколько раз сказать глупости и один раз сделать дельное замечание, чем совсем промолчать и упустить что-то важное.
2. «У проекта должно быть два срока: запланированный и желаемый. Эти два срока не должны совпадать».
Во время работы над моим первым проектом мы столкнулись с невозможностью выпустить его в срок. Задержка произошла по вине заказчика, он вовремя не предоставил нам необходимую информацию. Вот почему мы не смогли обработать дальнейшее развитие.
Хотя эта пауза не была нашей ответственностью, мы допустили ошибку. Мы не обратили внимание на возможность возникновения такого риска, как и на некоторые другие риски. Они могут быть разными, начиная с экзамена разработчика, семейных обстоятельств или даже простой халатности. Из этого я сделал вывод, что в дальнейшем необходимо назначить 2 срока: первый для идеальных условий и второй — с учетом всех рисков.
Как по мне, вам стоит ориентироваться на третью оценку — среднее между этими двумя сроками.
3. «Объедините команду и пусть она будет довольна. Для руководства нам нужны сердце, нутро, душа и нюх (управлять сердцем, чувствовать нутром, вкладывать душу в команду и проект, иметь чутье, чтобы отличать полезное от бессмысленного)».
Я никогда раньше не был начальником, но было много ситуаций, когда приходилось становиться руководителем. Я долгое время был капитаном волейбольной команды, и бывают ситуации, когда приходится становиться «плохим копом». Давлением в неординарных ситуациях можно добиться более быстрой реакции и мозговой активности, но это полный бред, если вы считаете, что это единственно верный способ руководства. Спорт жесток, поэтому все спортсмены достаточно сильные личности. Они никогда не сделают что-либо под давлением, кроме как если будут уважать вас, влиять на вас и доверять вам.
Человек гораздо охотнее согласится помочь вам, проявить чуточку больше внимательности и усердия, если вы не будете вытаскивать его из зоны комфорта.
Вы должны показать, что он не один и быть готовым помочь ему. Я думаю, что дружеские отношения были основной причиной того, что два ленивых человека (я и мой коллега) заканчивали один экран в 21:55, хотя рабочий день давно закончился.
Лично по своему опыту могу сказать, что очень сильно влияет желание делать все качественно, добросовестно и не подводить, когда к сотрудникам относятся по-человечески. Однажды я пропустил звонок с нашим разработчиком. Мой начальник отругал меня за это. По сравнению с тем, как меня ругали раньше, я не сразу это понял, но когда понял… Ну, я чувствовал себя виноватым, может быть, еще 4 дня.
В итоге хочу сказать, что эта книга действительно помогла мне не только осветить базовый костяк профессии, но и встать на ноги. Я надеюсь, что это поможет и вам. Наслаждайся чтением!
«Вот книга по менеджменту, которую просто интересно читать. «Крайний срок » — это инновационная и увлекательная история с проницательным бизнесом. Atlantic Systems Guild «Поскольку большинство менеджеров программного обеспечения
ряды программистов и, следовательно, не имеют ни малейшего представления об управлении проектами,
ситуация созрела для обучения на примере. Вот к чему обращается Том ДеМарко
с Уоррен Койфель « Крайний срок мертв на. Это обязательное чтение, веселое чтение для всех, кто когда-либо был или когда-либо будет, участвует в программном проекте. Том Демарко упаковал коллективный разум и упорные уроки, полученные от ведущих пророков программного обеспечения, гуру и оракулов в этот дразнящий, проницательный и откровенно занимательный «роман»».0003 ACM Software Engineering Notes «Вот книга по менеджменту, которую просто интересно читать. Джон Скалли «Когда люди решили поделиться тот вид здравого смысла, который слишком часто отсутствует в бизнесе программного обеспечения, обычно они звучат проповеднически и самодовольно. Том избежал этой ловушки благодаря искусное использование историй. Он также завязал достаточно конфликтов и напряженности, чтобы получить читательский интерес. В целом, это расслабляющее и информативное чтение». Вт С. Хамфри «Книга интересная и долговечная, как разработчики признают большинство своих проблем развития. . . «Не только это интересно, но в процессе вы даже можете освоить некоторые управленческие навыки.» Чарльз
Ashbacher «… это технологический тур по сила. Он охватывает широкий спектр тем, от оценки проекта до метрик, от разрешение конфликтов при работе с неоднозначными спецификациями. . . . пуля одни только баллы стоят цены книги. . . . Крайний срок почти такой же забавный, как книга, полная карикатур на Дилберта, но гораздо менее циничный. Более важный, в нем есть и глубокая мудрость, и несколько практических, положительных советов для повышение шансов уложиться в сроки вашего следующего проекта. я очень рекомендую это.» Эд Юрдон «Том
Демарко снова радостно снимает луковицу проблем управления
с человечностью и проницательностью, которые так же легко переходят в корпоративное общее управление
так же, как и в управлении программными проектами и командами. В Крайний срок ,
он посмеивается над книгой, изобилующей нелепостями нашей повседневной работы
жизнь и с метрическими устройствами, которые могут помочь нам управлять и работать лучше. Брюс Тейлор «A юмористический, вымышленный взгляд на разработку программного обеспечения. . . предлагает сбалансированный подход к управлению проектами. Автор справедливо указывает на людей как на важнейшую основу всех успешных проектов». Дайджест качества «Я прочитал эту книгу… и был сразу же впечатлен тем, как ДеМарко успешно объединяет управление программными проектами и качество программного обеспечения в увлекательной способ. Я мог видеть актуальность как для нынешних специалистов по программному обеспечению, так и для желающих работать в этой сфере. Как профессор, я решил включить это в мой класс управления качеством программного обеспечения. . . «Эта рецензия на книгу
отличается от других тем, что большая часть обзора состоит из комментариев
от моих учеников. «‘Эта книга очень ценный. Это дает реальное представление о проблемах, которые могут возникнуть в большом проекте. . . . Демарко проделывает фантастическую работу, показывая читателю, как решать проблемы. Он охватывает множество аспектов, таких как размер команды, разрешение конфликтов, дизайн, эмоции, патологическая политика, метрики и т. д., чтобы научить читателя наиболее эффективным способы правильного запуска проекта. Эта книга многому меня научила, и мне было интересно читать.’ «‘Эта книга помогла мне осознать множество важных концепций и заставила меня тоже много думаю. Я не просто прочитал это я бы подумал о том, как бы я реагировать в некоторых из данных ситуаций. . . «‘… Эта книга является новаторским способ подхода к управлению проектами, и Демарко превращает то, что могло быть болезненным высушить тему во что угодно, только не это». Доктор Патриция
McQuaid «In
Во многих отношениях эта книга дополняет книгу «Мифический человеко-месяц ». «Короткие главы, быстрое чтение, много смеха, уроки без цинизма Дилберта или UserFriendly , сводные баллы для обзора. Многое, чтобы рекомендовать его, для принципы применимы к любому управлению, а не только к разработке программного обеспечения. . . . «Что нового, так это использование Демарко юмора и повествования евангелизировать концепции (и вознаграждения) хорошего управления. Когда ты сможешь вспомнить громко смеетесь, читая книгу по менеджменту? Только для этого книга достойное дополнение к библиотеке любого менеджера». Кэти
E. Gill «Для
всем вам, кто искал роман о разработке программного обеспечения, который
действительно проникает в суть бизнеса, вот и все. «У нас осталось ощущение, что возможность существует только в данный момент, и что настоящая причина, по которой мы работаем, заключается только в том, чтобы учиться потому что обучение — это то, что наполняет смыслом каждый наш опыт».0003 Майкл
Гуахардо «. . . Мне понравился выпуск The Deadline , и я узнал из него кое-что интересное. . . . Крайний срок, как метод обучения, работает для меня. Подобно басням Эзопа, дает мне зацепку памяти для каждого из пунктов о людях, проектах и управлении которую ДеМарко хочет сделать.» Сью Петерсен «Это абсолютно
другой взгляд на управление проектами, который нельзя назвать ни сухим, ни
скучный.  |
Принципы командного управления проектами в конце каждой главы».
Крайний срок это инновационная и занимательная история с проницательными бизнес-принципами для
групповое управление проектами в конце каждой главы.»
Его
Функциональные очки, тупица!»
. . . Ниже приведены их ответы.
Например,
Г-н Томпкинс тестирует «привлекать людей к проекту, чтобы уложиться в ускоренный график».
теория (есть предположения относительно исхода?). И вроде ТМММ , Крайний срок ,
позиционируется как книга по технологиям, но содержит уроки для всех менеджеров. Оба
проповедовать важность планирования. . . .
