Deadline. Роман об управлении проектами. Том ДеМарко | by Tigran Baseyan
Сначала книга воспринимается как триллер, и только спустя какое-то время читатель понимает, что перед ним вполне четкие рекомендации и дельные советы по управлению проектами в яркой художественной оболочке.
Если вкратце, то «Дедлайн» — книга об управлении проектами и людьми.
Том ДеМарко — американский инженер-программист, писатель и консультант по программной инженерии.Про автора
Обладатель множества научных званий и наград Том ДеМарко возглавляет консалтинговый центр Atlantic Systems Guild с офисами в США, Германии и Великобритании. Инженер-программист и бакалавр электротехники, лауреат премии Жана-Доминика Варнье «За пожизненный вклад в информационные науки», ДеМарко проявил себя как талантливый писатель — автор девяти книг по управлению, организационному проектированию и системным разработкам, а также четырех произведений художественной литературы.
Плюсы
К достоинствам книги относятся ее искренность и теплота, с который ДеМарко рассказывает о работе с людьми. В этой работе есть немало тонкостей, не затронутых авторами других бизнес-романов. У автора прекрасное чувство юмора, хороший язык, писательский талант (недаром в последнее время он окончательно перешел к художественной литературе, заслужив похвалы критиков). Иногда в книге появляются черты социальной сатиры, иногда — романа-утопии, что слегка отвлекает от основной линии, но не портит ее.
В конце каждой главы собраны выкладки о том, как и почему, а главное — в каком порядке — стоит каталогизировать структуру компании, куда и почему перебрасывать человеческие ресурсы. Важнейшим для меня было не столько выгодное распределение ресурсов или наглядные таблицы, а хронология!
В каждом разделе идут акценты на времени — в каком порядке и почему стоит разрабатывать структуру компании, компьютерной программы или другого проекта. В конце каждой главы — список-вердикт подается в виде «записок Томпкинса», где четко и тезисно сделаны выводы.
Минусы
К недостаткам можно отнести огромное количество второстепенных действующих лиц. Некоторые персонажи появляются только для того, чтобы сказать несколько слов и исчезнуть навсегда. Возможно, у автора были свои соображения (как у противника любого сокращения кадров), но читателю они не очень понятны.
Кроме того, следует делать скидку и на время издания романа — 1997 год. С тех пор появились новые подходы к управлению проектами, основанные на гибкости («agile»), так что исчерпывающей и современной информации по управлению проектами читатель в книге не найдёт.
Для кого написана
Книга просто и понятно объясняет азы теории управления, принципы работы с персоналом, поскольку, по мнению автора, без людей нет проектов, что не всегда понимают руководители. Она учит бороться с конфликтами и укладываться в дедлайн. В то же время она помогает вовремя распознать признаки «извращенной политики» и шаткости положения организации, когда покинуть ее ряды куда разумнее, чем бороться с вздорностью и некомпетентностью руководства.
В целом книга будет полезна как руководителю, так и рядовому сотруднику. И конечно, книга давно стала обязательным чтением для тех, кто создает программные продукты.
Основные идеи и постулаты книги?
✅Залог успеха любого проекта — не в капиталах или технологиях, а в людях;
✅Правильный подбор персонала основан не столько на выборе впечатляющего резюме, сколько на интуиции менеджера по персоналу;
✅Мотивация персонала не должна быть отрицательной. Угрозы и давление убивают инициативу, а не ускоряют работу;
✅В любой организации может внезапно возникнуть «извращенная политика», когда руководители любого уровня забывают об общих интересах и заботятся только о личных целях, даже если они прямо противоположны общим;
✅В командах, занимающихся разработкой программного обеспечения, неизбежно возникают конфликты интересов, от которых нужно избавляться с помощью посредника-катализатора;
✅Управление проектом — это управление его рисками;
✅Процесс разработки программ и управление проектами удобно моделировать с помощью рисунков;
✅Одна из основных целей любого проекта по разработке программного обеспечения — слаженная команда, готовая работать вместе и дальше.
Книгу можно скачать по ссылке — в книге 188 страниц: http://bit.ly/2XsVgF6
отзывы о книге — IT-Agency
Аннотация от издателя
Если некие люди, оценив вас как гениального руководителя, выкрадут вас, увезут в чужую страну и предложат вести интереснейший проект на весьма выгодных условиях, то вы пройдете путь главного героя этой книги в точности. Но если вы менеджер, то всё, кроме шпионских деталей, — ваша повседневная реальность.
Расчет численности команды на разных стадиях проекта, муки выбора при найме сотрудников и тягостные ощущения при их увольнении, работа в условиях цейтнота, арбитраж во внутренних конфликтах, защита подчиненных от необдуманных действий вышестоящего руководства — все это до боли знакомо многим менеджерам. Потому что управление проектами — это всегда работа с людьми.
Под выводами, которые заносит главный герой в свою записную книжку, могут подписаться тысячи руководителей. Однако сформулировать их в повседневной текучке самостоятельно удаётся не всегда. Поэтому наибольшую пользу эта книга принесет руководителям проектов любого масштаба.
«Это классика. Том Демарко рассказывает основы управления проектами, но не схемы и процессы, а правила работы с людьми.» Всеволод Устинов, руководитель IT-Agency
«Что можно сказать? Содержание „цепляет“ с первых страниц! Примерно как любовь с первого взгляда, когда смотришь и понимаешь: „Ну всё, попал!“ Так и я — каждую свободную минуту тянулась к книге, чтобы узнать, что дальше. Дневник мистера Томпкинса — практика, которую должен взять на вооружение каждый руководитель. Да и не только — вообще любой человек! Ведь мы столько передумываем за день различных мыслей, столько идей нам приходит в голову, столько полезного узнаём, что без „дневника полезностей“ точно не обойтись! Кстати, именно благодаря этой книге я стала фиксировать всё, чему научилась за день и с какими людьми познакомилась!» Galchonok, Живой Журнал, сообщество Must Read «Честно говоря, книга Тома ДеМарко „Deadline.
«Deadline. Роман об управлении проектами» Том Демарко
О книге
Все принципы хорошего менеджмента описаны здесь в интересной и ненавязчивой форме бизнес-романа. Автор — Том Демарко — написал уже 13 книг, но Deadline считает своей самой сильной книгой. Он уверен — ее чтение добавит вам целых два года великолепного управленческого опыта, а захватывающий сюжет и наглядные примеры будут полезнее любого учебника.
Неслучайно эта книга стала настольной для сотен тысяч менеджеров на всем земном шаре. Она входит в список обязательного чтения по курсу «Управление проектами» во многих бизнес-школах по всему миру.
Председатель совета директоров Сбербанка отметил ее как одну из лучших бизнес-книг и добавил ее в библиотеку Сбербанка.
Если вы хотите прочесть только одну книгу по управлению проектами — прочтите эту.
Почему мы решили издать эту книгу
Это просто находка для менеджера, который устал от чтения навязчивых руководств и историй успеха, а дзен-притчи о менеджменте не близки ему по духу.
Для кого эта книга
Для всех, кто управляет проектами (особенно в области ИТ).
И для тех, кто участвует в проектах.
От автора
Глаза мистера Томпкинса загорелись:
— Эксперимент… Одна команда работает под жестким контролем, другая — под слабым, третья — практически свободно, и все три работают над одной и той же задачей. А мы смотрим, какая из них быстрее закончит.
Всю жизнь мечтал сделать что то подобное. В одну команду можно набрать слишком много людей, в другую — слишком мало, в третью — как раз столько, сколько, по моему мнению, нужно…
— В одну команду набрать только опытных специалистов, в другую — опытных и новичков, — продолжила Лакса.
Но мистер Томпкинс уже и сам проникся идеей и не собирался останавливаться.
— В одну набрать людей, которые уже работали вместе, и посмотреть, как они будут соревноваться с командой, где никто раньше друг друга не знал. Лакса, если мы это сделаем, то сможем разгадать одну из величайших загадок менеджмента. Мы могли бы понять, почему одним проектам сопутствует успех, а другим — нет.
— Все в ваших руках, Вебстер. Можете экспериментировать над всей Моровией, — Лакса кивнула в сторону Силиконовой поляны. — Вот она, первая в мире Лаборатория по управлению проектами.
Том Демарко — Deadline. Роман об управлении проектами (2014) pdf / Consense Library /
Том Демарко — Deadline. Роман об управлении проектами (2014) pdf / Consense Library /| Автор(ы): | Том Демарко |
| Формат файла: | |
| Год издания: | 2014 |
| Издательство: | Вершина |
| Язык книги: | RU |
| Скачано раз: | 61 |
| Добавлено: | 2018-09-25 |
| Размер файла: | 1 890 725 |
Возможно, встречаются еще менеджеры, которые полагают, что управление — это собрания, программы обучения и повышения качества продукции и разнообразные отчеты. Однако в наше время стало очевидным, что управление проектами — это прежде всего работа с людьми.
Как выбрать из множества кандидатов нужного вам человека? Каково оптимальное число людей в команде на разных этапах проекта? Как можно оптимизировать работу, если перед вами поставлены жесткие сроки? Как определять и решать конфликты? Как уволить человека, не обидев его? Какими качествами должен обладать хороший руководитель?
Обо всем этом вы узнаете из данной книги, которая к тому же представляет собой не сухой научный труд, а… увлекательный приключенческий роман!
Это просто находка для менеджера, который устал от чтения навязчивых руководств и историй успеха, а дзен-притчи о менеджменте не близки ему по духу.
Об авторе
Том ДеМарко — глава международной консалтинговой компании Atlantic Systems Guild, специализирующейся на построении сложных бизнес-систем, управлении рисками, реинжиниринге, построении здоровой корпоративной культуры. Также она оказывает помощь в судебных разбирательствах, связанных с программным обеспечением. Член Ассоциации по вычислительной технике (Association for Computing Machinery) и Института инженеров по электротехнике и электронике (Institute of Electrical and Electronics Engineers).
https://habr.com/post/159589/
Без оплатыБез регистрацииБез рекламыБез вирусов
Все представленные в библиотеке материалы взяты из открытых источников и являются собственностью соответствующих правообладателей и/или авторов. Скачивая их, Вы соглашаетесь с тем, что получаете их для личного ознакомления.
Том ДеМарко. «Deadline. Роман об управлении проектами»: nika2201 — LiveJournal
И все же хотелось бы представить, что где-то на земле есть место, где цель проекта — качество, а не сроки. Но, наверное, такого не бывает.«Deadline. Роман об управлении проектами» – самая популярная книга американского программиста Тома ДеМарко, написанная в 1997 году и переведенная на русский язык в 2006. Несмотря на то, что с момента ее написания прошло 20 лет, она не устарела и содержит много важных мыслей. Многие из них просты и очевидны, но, как показывает практика, зачастую они оказываются недоступны пониманию высшего руководства.
Книга считается одной из лучших книг по управлению проектами «для начинающих» в сфере ИТ, легко и в форме художественного произведения рассказывает о серьезных вещах. В каждой главе главный герой борется с какой-то проблемой, а в конце главы — записывает в блокнот свои мысли, которые смело можно брать на вооружение, использовать в работе и других сферах жизни (для удобства выписала все эти мысли в файл, прочитать можно тут: Роман об управлении проектами. Записная книжка). «Дедлайн» напомнил мне «Тестирование Дот Ком» Романа Савина, книгу, которую обязан был прочитать каждый начинающий тестировщик, написанную так же легко, доступно, с шутками и примерами.
Основная идея романа в том, что основа любого проекта — люди. Именно они способны совершать чудеса, если цель значительна и вера в свои силы велика. Именно они способны привести к краху любые начинания, если личные мотивы идут вразрез с целями проекта. Для проектного менеджера главное – не мешать людям выполнять ту работу, которая им нравится. Основная его задача – оберегать таких людей от внешних факторов, мешающих этой работе.
Сюжет книги простой и незамысловатый, но довольно-таки странный: в компании главного героя, Вебстера Томпкинса, талантливого менеджера проектов, происходит сокращение. Его увольняют, и на лекции для таких же уволенных сотрудников он встречает шпионку Лаксу из выдуманной коммунистической страны Моровии (находящейся где-то в районе Албании), которая к 2000 году (сейчас — 1997) хочет стать мировым лидером по производству ПО. Девушка давно следила за Томпкинсом, и после его фразы о том, что главное в работе менеджера — это
1. Найти нужных людей.
2. Дать им ту работу, для которой они больше всего подходят.
3. Не забывать о мотивации.
4. Сплотить команду и поддерживать ее в состоянии сплоченности.
(Все остальное – административная ерундистика.)
она понимает, что Вебстер как нельзя лучше подойдет на роль человека, который выполнит эту задачу.
Лакса накачивает Томпкинса наркотиками и перевозит в Моровию. В Моровии находится полторы тысячи первоклассных ИТ-специалистов, прекрасно владеющих английским языком и работающих в одной крупной корпорации.
Цель ВВН (Великого Вождя Народа, молодого американского миллиардера-программиста, купившего Моровию) – за 2 года написать 6 продуктов-аналогов имеющегося на рынке ПО: Photoshop, Color Painter и еще 4 уже непопулярных в наше время продуктов. Задача Томпкинса – отобрать из 1500 человек подходящих для этого сотрудников и управлять ими. Подкупает главного героя то, что ВВН предлагает ему провести эксперимент: для каждого продукта набрать по 3 команды с разным количеством людей, с разной степенью контроля, использующих разные методологии и т. д. и оценить, как это повлияет на разработку. Лучшие продукты попадут на рынок. Проблема в том, что эксперимент так и не завершился – ВВН вместе с Лаксой уехали на год по делам, и Моровией в это время управлял министр внутренних дел мистер Бэллок: неприятный, грубый, некомпетентный человек, который постоянно сокращал сроки и ставил палки в колеса главному герою. Он потребовал перенести дедлайн на полгода назад, объединив группу из 3 команд в одну для каждого продукта. В огромных переполненных командах разработчики не могли работать, их менеджеры срывались, но Вебстер набрал еще по 2 команды из оставшихся сотрудников, передал им разработки прежних команд Б и В и, в итоге, новые команды Б и В, сформированные без уведомления других и использующие свои оригинальные методы, закончили разработку быстрее и качественнее переполненных команд А.
В каждой главе мистер Томпкинс встречает рояли в кустах: компетентных специалистов, помогающих ему и дающих советы. Герои утрированные, но живые — сразу же пытаешься подобрать им аналог из своего опыта. Разумеется, в жизни все происходит не так, но благодаря удачному стечению обстоятельств, герой делает полезные выводы. Книга, в основном, рассказывает об управлении очень большими командами и проектами, но и менеджер небольших команд сможет подчеркнуть многое.
В романе рассказывается, как создаются продукты, как нанимают персонал, как решать конфликты, как работать с трудным руководством и вредными подчиненными, как правильно относиться к своим работникам и многое другое. Некоторые советы (мотивация, разрешение конфликтов, поведение в коллективе) пригодятся и в повседневной жизни.
Перед началом работы главный герой сразу же говорит, что все его сотрудники должны работать вместе, что невозможно создать продукт, когда между работниками нет дружеских отношений и возможности быстрого общения. Сейчас мы имеем возможность общаться с любым человеком на расстоянии, но отношения в коллективе тоже очень важны. Команда, участники которой готовы и дальше работать вместе, – это одна из основных целей любого проекта.
Мне понравилась описанная в книге техника проведения больших и нудных совещаний (на которых, скорее всего, был каждый из нас). Для каждого собрания должна быть опубликована повестка (и ее нужно строго придерживаться!), чтобы сотрудники знали, действительно ли обсуждаемая проблематика для них важна или интересна. В начале митинга руководитель должен выбрать по меньшей мере одного человека, чья работа настолько важна для проекта, что ему лучше покинуть совещание. Если на собрании обсуждаются вопросы проекта, уходящий сотрудник просит оставшихся решить определенные вопросы. Далее группа выражает согласие и человек уходит.
Из записной книжки мистера Томпкинса я вынесла и дополнила мысли, посвященные двум важным темам: производительность и конфликты, на которые я бы хотела обратить ваше внимание:
Повышение производительности:
1. Не существует никаких краткосрочных мер, которые позволили бы быстро повысить производительность работы (например, добавление в команду новых работников. Чем больше людей, тем сложнее им стать единой командой, тем больше времени у них уходит на взаимодействие и общение.) Повышение производительности – результат долгосрочных усилий.
2.
Формальные программы (например, сертификации, повышение квалификации), направленные на улучшение существующего процесса разработки, будут дорого стоить команде – и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то, даже если это и произойдет, едва ли выгоды от этого повышения покроют затраты.
3. Можно надеяться получить положительный результат от какого-либо одного хорошо взвешенного и тщательно выбранного усовершенствования (но не более одного за раз) в методике работы. В этом случае оно может окупить себя.
4. Успех проекта можно скорее обеспечить сокращением ненужных усилий, чем стремлением к новым победам. Чем раньше вы прекратите ненужную работу, тем лучше это отразится на проекте в целом. Не нужно добавлять в процесс новое, нужно убирать лишнее.
5. Есть только один способ сократить время на разработку, когда его и без того мало, – уменьшить сроки отладки программы. В детально спроектированных проектах на написание кода уходит примерно в 2 раза меньше времени, чем на проектирование.
6. Мотивация персонала не должна быть отрицательной. Угрозы и давление убивают инициативу, а не ускоряют работу. Какими угрозами не запугивать сотрудников, они не смогут выполнить задачу, если изначально были поставлены нереальные сроки.
7. Люди не станут быстрее соображать оттого, что руководство начнет давить на них. Чем больше сверхурочной работы, тем ниже производительность. Это происходит потому, что люди знают, что им все равно придется работать допоздна и больше времени тратят на перерывы, работают менее эффективно. Результатом сверхурочной работы становятся усталость, отсутствие творческой энергии, ошибки, нервное напряжение. Люди начнут выдыхаться, терять веру в проект.
8. Немного давления и сверхурочной работы могут помочь сконцентрироваться на проблеме, понять и почувствовать ее важность, но длительное давление всегда дает отрицательный результат.
Возможно, руководство просто не знает других способов повлиять на ситуацию.
Конфликты:
1. Главный признак извращенной политики: во главу угла ставятся личные цели и влияние, а не общие интересы компании. Вследствие этого появляются злоба плюс скупость (сокращение сроков, финансирования…) – вот формула, которую начинают применять в плохих компаниях те, кто несет ответственность за неудачи в бизнесе.
2. Неуважение и злоба, по мнению некоторых руководителей, должны заставить подчиненных лучше работать. Но это никогда не сподвигнет людей работать лучше. Если начальник демонстрирует неуважение к подчиненным, это признак того, что он не может больше занимать свою должность. Нужно уважать каждого, даже самого вредного из своих подчиненных.
3. В работе страх = гнев. Страх в нашем обществе почему-то нельзя демонстрировать. А вот злость можно. Но когда ты испытываешь сильную эмоциональную перегрузку, тебе просто необходимо выплеснуть свои чувства. Именно поэтому люди, испытывающие страх, чаще всего демонстрируют на людях злость и презрительное отношение к другим. Скорее всего, они просто чего-то боятся: вышестоящего начальства; подвести свою команду; того, что они не справятся с поставленной задачей.
4. Проект, в котором участвуют несколько сторон, не избежит конфликта интересов. Конфликт заслуживает понимания и уважительного отношения. Конфликт не имеет ничего общего с непрофессиональным поведением.
5. Любую сложную вещь можно описать простыми словами. Если это не удается, значит, нужно либо развивать в себе способность четко излагать мысли, либо учиться решать конфликты.
6. В большинстве компаний, где создается программное обеспечение, никто специально не занимается вопросом решения конфликтов. Объявите заранее, что если интересы конфликтующих сторон полностью или частично противоположны, то поиск решения будет переложен на посредника. Первым шагом в деле посредничества при решении конфликта должна быть маленькая церемония.
Например, можно произнести фразу «Можно я попробую рассудить ваш спор?»
7. Не забывайте: все участники ситуации находятся по одну сторону баррикад. По другую сторону находится сама проблема.
Tl;dr. «Deadline. Роман об управлении проектами» будет интересен и тем, кто работает с людьми, и тем, кто работает в IT, а в особенности — менеджерам проектов. Каких-то глубоких изречений и серьезных исследований от книги ждать не стоит, но то, что лежит на поверхности, и то, что многие не замечают, — особенно важно. Конечно, можно прочитать и просто выводы (еще раз даю ссылку), но куда интереснее знать, как главный герой к этому пришел, да и с жизненными примерами все намного лучше запоминается (а еще у книги интересный финал — не спойлерю)). В реальной жизни события не складываются так удачно, как у мистера Томпкинса, поэтому у некоторых людей, не связанных с IT, может возникнуть неправильное представление о сфере. Но начинающим менеджерам книга даст понять, нравится ли им то, во что они ввязались много полезных советов. Также минусом «Романа» могу назвать то, что после него тяжело читать «правильную» профессиональную литературу, после легкого и интересного сюжета она кажется нудноватой. В целом, «Роман об управлении проектами» заслуженно получает от меня 9 ВВН из 10.
Читать онлайн «Deadline. Роман об управлении проектами» автора Марко Том Де — RuLit
Том ДеМарко
Deadline. Роман об управлении проектами
В 1930-е годы прошлого века физик Джордж Гамоу из университета штата Колорадо начал публиковать мини-сериал рассказов о неком мистере Томпкинсе, банковском клерке средних лет. Мистер Томпкинс, как явствовало из этих историй, интересовался современной наукой. Он регулярно посещал вечерние лекции местного университетского профессора и, разумеется, всегда засыпал на самом интересном месте.
В одном из этих рассказов, например, мистер Т. проснулся во Вселенной, где скорость света составляла всего лишь пятнадцать миль1 в час, и мог наблюдать эффекты теории относительности, совершая велосипедные прогулки. Когда он начинал быстрее крутить педали, приближающиеся здания уменьшались в размерах, а стрелки часов на здании почты замедляли свой бег. Сюжет другого рассказа заключался в том, что мистер Томпкинс побывал в мире, где постоянная Планка была равна единице, и наблюдал квантовую механику в действии, стоя у бильярдного стола: шары не катались плавно по поверхности, как обычно, а принимали непредсказуемое положение, как квантовые частицы.
С рассказами Гамоу я познакомился еще в подростковом возрасте. Как и мистер Томпкинс, я интересовался современной наукой, к тому времени уже прочел немало книг о квантовой механике и теории относительности. Но только после того, как мне в руки попали истории о незадачливом банковском клерке, начал наконец-то понимать, о чем вообще идет речь.
Меня всегда восхищало, как Гамоу сумел в столь интересной и ненавязчивой форме описать сложные научные постулаты. Мне показалось, что в такой же форме можно описать и некоторые принципы управления проектами. И я решил рассказать вам, уважаемый читатель, историю об опытном руководителе, который попал в некую воображаемую страну, где в различные правила управления вносились изменения «сверху». Так родилась (приношу свои глубочайшие извинения Джорджу Гамоу) идея этой книги — истории о менеджере по фамилии Томпкинс, который оказался в бывшей социалистической республике Моровии2 и был назначен руководителем проектов по созданию программного обеспечения.
Камден, штат Мэн,
май 1997 года
Посвящается Салли (а кому же еще!)
Глава 1
Широчайшие возможности
Мистер Томпкинс устроился в последнем ряду Больдридж-1, главной аудитории «Крупной телекоммуникационной корпорации» (отделение в г.
Пенелопа, штат Нью-Джерси). За последние несколько недель он провел тут довольно много времени на лекциях для увольняемых. Мистеру Томпкинсу и еще нескольким тысячам таких же, как он, профессионалов и менеджеров среднего звена, попросту указали на дверь. Ну, разумеется, никто не выражался столь грубо и прямолинейно. Обычно использовались фразы вроде: «сокращение штатов», или «в результате уменьшения размеров компании», или «оптимизация размеров компании», или же — и этот вариант был самым замечательным из всех — «предоставляем свободу выбора другой работы». Для этой последней фразы сразу же изобрели аббревиатуру: СВДР. Томпкинс и был одним из таких СВДР.
Сегодня в Больдридж-1 должна была состояться очередная лекция на тему «Широчайшие возможности прямо перед нами». Как говорилось в программке, данный цикл лекций представлял собой «более ста часов крайне увлекательных тренингов, пьесок, музыкальных интерлюдий и прочих мероприятий для новоиспеченных СВДР» — и все за пять недель. Сотрудники отдела по работе с персоналом (которых никто не увольнял) были убеждены, что стать СВДР — величайшее счастье, только вот остальные почему-то этого не понимают. Конечно же, им самим очень хотелось стать СВДР. Честное слово. Но, увы, пока не везет. Нет-нет, сэр, пока еще им предстоит нести свое бремя: регулярно получать зарплату и продвигаться по службе. А сейчас они поднимутся на сцену и мужественно продолжат свой нелегкий труд.
Последние несколько рядов в аудитории попадали в зону, которую инженеры-акустики называют «мертвой». По какой-то загадочной причине, которую никто пока не сумел объяснить, звук со сцены сюда практически не проникал, поэтому тут можно было замечательно вздремнуть. Томпкинс всегда только здесь и сидел.
На сиденье напротив он выложил сегодняшний набор подарков от фирмы: две толстые записные книжки и прочие мелочи были упакованы в красивую матерчатую сумку с логотипом компании и надписью: «Наша компания худеет, поэтому все остальные могут набирать вес».
Поверх сумки легла бейсболка с вышивкой: «Я — СВДР и горжусь этим!» Томпкинс потянулся, нахлобучил бейсболку на глаза и уже через минуту мирно спал.
В это время хор сотрудников по работе с персоналом громко пел на сцене: «Широчайшие возможности — распахнем перед ними дверь! Распахнем!» По замыслу исполнителей, слушатели должны были хлопать в ладоши и подпевать: «Распахнем!» Слева от сцены стоял человек с громкоговорителем и подбадривал публику воплями: «Громче, громче!» Несколько человек вяло хлопали, но подпевать никто не хотел. Однако весь этот шум начал пробиваться даже в «мертвую зону», где спал мистер Томпкинс, и, наконец, разбудил его.
Он зевнул и огляделся. Всего через кресло от него, в этой же «мертвой зоне» кто-то сидел. Настоящая красавица. Тридцать с небольшим, черные гладкие волосы, темные глаза. Она смотрела на беззвучное представление на сцене и слегка улыбалась. Одобрения в этой улыбке вроде бы не было. Ему показалось, что они уже где-то встречались.
— Я ничего не пропустил? — обратился он к незнакомке. Та продолжала наблюдать за сценой.
— Всего лишь самое важное.
— Может быть, вы мне вкратце обрисуете?
— Они предлагают вам убраться, но при этом просят не менять телефонную компанию, через которую вы звоните по межгороду.
— Еще что-нибудь?
— Ммм… вы проспали почти что целый час. Дайте-ка я вспомню. Нет, пожалуй, больше не было ничего интересного. Несколько забавных песенок.
— Понятно. Обычное торжественное выступление нашего отдела по работе с персоналом.
— Ооо! Мистер Томпкинс проснулся… как бы поточнее сказать?… в состоянии легкой озлобленности.
— Вы знаете больше, чем я, — мистер Томпкинс протянул ей руку. — Очень приятно, Томпкинс.
— Хулигэн, — представилась женщина, отвечая на рукопожатие. Теперь, когда она повернулась к нему, он мог рассмотреть ее глаза: не просто темные, а практически черные.
И смотреть в них ему очень понравилось. Мистер Томпкинс обнаружил, что краснеет.
— Ээээ… Вебстер Томпкинс. Можно просто Вебстер.
— Лакса.
— Какое забавное имя.
— Старинное балканское имя. Моровийское.
— А Хулигэн?
— Хм, девичья неосмотрительность моей мамочки. Он был ирландцем с торгового судна. Симпатичный палубный матрос. Мама всегда была неравнодушна к морякам. — Лакса усмехнулась, и Томпкинс вдруг почувствовал, что его сердце забилось сильнее.
— А, — наконец нашелся он.
— Ага.
— Мне кажется, я вас уже где-то встречал, — это прозвучало как вопрос.
— Встречали, — подтвердила она.
— Понятно, — он все равно не мог вспомнить, где же это могло быть. Мистер Томпкинс взглянул в зал — рядом с ними не было ни одной живой души. Они сидели в переполненной аудитории и вместе с тем могли спокойно общаться «с глазу на глаз». Он опять повернулся к своей очаровательной собеседнице.
— Вам тоже предоставили свободу выбора?
— Нет.
— Нет? Остаетесь в этой компании?
— Опять не угадали.
— Ничего не понимаю.
— Я здесь не работаю. Я шпионка.
Он засмеялся.
— Скажете тоже!
— Промышленный шпионаж. Слыхали о таком?
вернутьсяПримерно двадцать восемь километров — Примеч. ред.
вернутьсяВозможно, результат «скрещивания» Моравии (Чехословакии) и Мордовии. Кроме того, существует интернет-сообщество под названием «Королевство Моровия» (образовалось в 1996 году) и корпорация «Моровия», производящая программное обеспечение, а также одноименный город в Коста-Рике. — Примеч. ред.
Том ДеМарко Deadline: Роман об управлении проекта…
Том ДеМарко Deadline: Роман об управлении проекта.
.. | MindMeister Mind Map
Том ДеМарко Deadline: Роман об управлении проектами
by Всеволод Устинов1. Руководство ИТ-проектами:
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. Эти сроки должны быть разными.
Роман Тома ДеМарко об управлении проектами
Книга в 3 предложенияхМистер Томпкинс теряет руководящую должность в большой телекоммуникационной компании. Затем он оказывается в более важном проекте, рассчитанном на год, с различными проблемами, мешающими работе и не позволяющими ему уложиться в срок. Книга написана как художественная литература и наполнена знаниями, полученными мистером Томпкинсом, когда он берется за этот большой проект.
Impressions
Изначально опубликовано в 1997 году, к счастью, многие из привычек, предложенных главными героями, теперь являются стандартом в индустрии высоких технологий.Это номер
Мистер Томпкинс теряет руководящую должность в крупной телекоммуникационной компании. Затем он оказывается в более важном проекте, рассчитанном на год, с различными проблемами, мешающими работе и не позволяющими ему уложиться в срок. Книга написана как художественная литература и наполнена знаниями, полученными мистером Томпкинсом, когда он берется за этот большой проект.
Impressions
Изначально опубликовано в 1997 году, к счастью, многие из привычек, предложенных главными героями, теперь являются стандартом в индустрии высоких технологий.Приятно лучше понять, почему мы разработали такие методы и что может произойти, если мы не будем следовать лучшим практикам. Книга объединяет то, что я уже знаю, и иногда предлагает новые идеи, которые я могу опробовать на своем рабочем месте.
Примером объединения моих знаний является совет свести количество участников к минимуму, чтобы убедиться, что они эффективны, перед проведением собрания с четкими целями и в конце собрания, убедившись, что есть пункты действий. Там, где я работаю в настоящее время, они известны, но они часто могут ускользать, поэтому эта книга предлагает напоминание о передовых методах работы.
Мистер Томпкинс использует свою новую роль как шанс провести над командой эксперименты, которые иногда кажутся жестокими. Потенциальное беспокойство, связанное с изменением направления, изменением правил и дублированием усилий, подорвет мораль. Я, вероятно, должен помнить, что события — всего лишь средство передачи мудрости читателю. Большинство разговоров в книге ведется между людьми из руководства, при этом отсутствует важная часть передачи информации об изменениях и планах команде инженеров, но, возможно, г-н Томкинс слишком высок в пищевой цепочке, чтобы сделать это.
Книга содержит фантастических персонажей; местами это карикатуры, их животы намеренно служат цели, чтобы еще больше усилить аллегории, содержащиеся в книге. В книге много юмористических моментов и шокирующих поворотов сюжета. Многие события, которые вызывают проблемы мистера Томпкинса, безумны, но связаны; большинство решений практичны и могут быть уроком для читателей. За исключением того, что он нашел в своем распоряжении запасную команду инженеров. Иногда может показаться абсурдным, сколько богатства находится в распоряжении мистера Томпкинса, его способность привлекать лучших экспертов, чтобы посоветовать ему проблемы, с которыми он сталкивается, но, конечно, это помогает темпам книги.Я полагаю, что в нашем распоряжении также есть эксперты, судя по содержанию этой книги, а также по тысячам книг и выступлений, имеющихся в нашем распоряжении в Интернете.
Кто должен это прочитать
Мне трудно читать книги по менеджменту, но это было написано невероятно увлекательно. Если бы в этом стиле было написано больше книг по управлению продуктами, я бы их все время читал. Я бы порекомендовал эту книгу всем, кто занимается разработкой продуктов, вне зависимости от стажа работы, поскольку ее содержание легко потреблять.Книга идеально подходит для компаний, у которых отсутствует структура, или для новых компаний, пытающихся развить свою культуру. Эта книга также подходит для людей, начинающих работу в отрасли, чтобы помочь им выявить хорошие привычки.
Как книга изменила меня
К сожалению, я не думаю, что книга была настолько впечатляющей по содержанию, но очень хорошо сделана в плане исполнения. Я бы хотел, чтобы больше книг по менеджменту было написано в такой очаровательной манере.
Мои три основные цитаты
Многие из этих цитат не находят отклика, поскольку в них нет аллегории, которая их вдохновляла.Вот несколько моих любимых цитат.
«Lean and Mean» — это формула, разработанная в неудачных компаниях людьми, ответственными за неудачу. Она противоположна естественной цели любой организации: быть процветающей и заботливой. Когда вы слышите фразу «бережливое и экономное», замените ее тем, что это действительно означает: «Неудачник» и «Напуган».
«Конфликт заслуживает уважения. Конфликт не является признаком непрофессионального поведения».
«Помните: гнев = страх. Менеджеры, которые оскорбляют своих подчиненных, почти всегда делают это, потому что боятся.»
Основные уроки из книги Deadline Тома ДеМарко. | Стэн Халауко
В прошлом году я принял идею, что все цели должны быть записаны. Много времени в конце каждого декабря в facebook-профиле моего друга Я видел списки «что нужно сделать в следующем году». На мой взгляд, создание таких списков имеет смысл, но выкладывать их в публичное пространство — нет. Тем не менее, я делюсь с вами одним баллом из моих целей каждый год. Я поставил цель: прочитать / послушать и понять 12 книг в 12 форматах.К сожалению, мне этого не удалось. Я читаю / уменьшаю только 8 книг, и поэтому в этом году я поставил цель: прочитать / уменьшить и понять 9 книг за 12 подходов.
Вторая книга, которую я прочитал в 2018 году, — это «Крайний срок: роман об управлении проектами» Тома ДеМарко. Я много раз встречал это название в списках типа «N книг, которые должен прочитать каждый», но сначала я не хотел читать эту книгу, потому что это роман. Я думал, что лучший способ узнать информацию — это справочники, а не романы с рассказом и главными героями… Я ошибался.«Крайний срок» — отличная книга, и на самом деле она может «… добавить вам несколько лет опыта управления проектами… », как было упомянуто во введении к книге.
В каждой части книги автор перечисляет несколько кратких основных идей части. Как правило, в книге можно насчитать более 50 итоговых баллов. А всех из них не запомню и пишу здесь свои 15 основных идей, которые я понял и запомнил после прочтения книги.
- Самое главное — народы.
Нет комментариев… Найдите нужных людей и дайте им работу, которую они любят и умеют делать наилучшим образом. Точка. - Если кто-то уродлив и агрессивен, это означает, что он / она просто боится не сдать свою работу.
Вся нервная ситуация возникает от незнания. Вы начинаете бояться, потому что у вас недостаточно знаний по определенной теме. Вы не знаете, как выполнять свою работу -> вы начинаете бояться и нервничать -> вы агрессивно относитесь к своему окружению. - Если вы хотите управлять проектом — управляйте рисками проекта и отслеживайте симптомы, когда риск превратится в проблему и блокиратор.
Вы должны знать, что и когда может пойти не так, и иметь план Б в этой ситуации. - Если ваш начальник и ваше руководство идиоты, вы ничего не можете с этим поделать … и не пытайтесь проверить это на своей шкуре.
Это просто болезнь … ее не вылечишь. - Будьте сильными и профессиональными. Выполняйте свою работу правильно и с большим энтузиазмом, даже если из-за этого вы можете потерять свою позицию.
Чтобы быть хорошим профессионалом — вы должны быть уверены, что у вас хорошая работа.Если кто-то говорит, что вы должны сделать что-то по-другому, и вы уверены, что это будет «плохая работа», вы должны иметь смелость не делать этого. - Угрозы — плохой способ повысить качество и ускорить работу ваших сотрудников.
Как в голливудских фильмах — всегда побеждает хорошее. - Сверхурочная работа не повышает эффективность работы.
Чем больше человек устает, тем больше он непродуктивен. Не столько философии. - Повышение производительности — вопрос долгосрочный.Все методы быстрого улучшения производительности — ложь.
Люди должны работать вместе и работать над синергией. Вы не можете сделать это быстро — это вопрос опыта. - Принимайте KPI и отслеживайте их. Также, чтобы сохранить историю достижения KPI в других проектах. Он может предсказать время для достижения ваших целей.
Когда вы не знаете, куда идете, вы будете там. Один пункт стратегии SMART — работа должна быть измерена. - Архитектура проекта — самая важная работа в вашем проекте.Разделите всю работу над блоками и спроектируйте, как эти блоки должны взаимодействовать друг с другом.
Непосредственно работа (прототипирование, кодирование и т.д.) должна занимать около 1/5 всего проекта. 4/5 создает архитектуру и создает план, как она должна работать. Это не отменяет бережливого подхода. Когда вы исправляете или создаете решение, вся команда должна знать, что и как вы делаете… см. ↓ - Чаще всего ошибки появляются на границах блоков, а не внутри них .
… и работа PM состоит в том, чтобы заботиться о том, чтобы ввод и вывод каждого блока были очень точно определены.Выход из одного блока — это вход в другой. Это означает, что проблема возникает не потому, что команда работает неправильно, а просто потому, что они не могут согласиться друг с другом. Для меня это было большим открытием, как для человека с техническим образованием. У меня была точка зрения, что разговоры теряют время, и, судя по моему опыту, многие «технические» люди придерживаются аналогичной точки зрения. Общайтесь друг с другом до тех пор, пока вы решите все вопросы по теме работы. И только после этого приступайте к работе. - Непонятная спецификация означает, что в команде существует конфликт интересов.
Никто не любит конфликтов. Спецификация должна быть подробной и конкретной. Когда существуют две точки зрения на одну деталь и вы не хотите показывать этот конфликт извне, легко вообще не упомянуть об этой детали. Если все детали не совпадают — все спецификации нечеткие… вы можете выбросить этот документ в корзину. - Относиться ко всему критически … даже если вы уверены на 100% в этом факте.
Отправная точка любого мышления — быть критичным и всегда задавать вопросы. - Людям лучше работать без жестких сроков.
Да, у проектов должны быть сроки, но психологически легче, когда есть свобода. Задача PM — найти золотую середину. - У любого собрания должна быть повестка дня. На собрании должны присутствовать только требуемые лица — постарайтесь сделать эту группу как можно меньше .
Три человека согласятся быстрее, как пятеро. Пятеро согласятся быстрее десяти. И для того, чтобы это было правдой, у вас должны быть конкретные моменты для обсуждения.
Роман об управлении проектами
Тома ДеМарко, американское оригинальное издание, опубликованное в 1997 году.
Вы когда-нибудь хотели знать, что такое управление проектами? Том ДеМарко раскрывает все в этой восхитительной фантастике о похищенном менеджере проекта. Подобно тому, как Джордж Гамов использовал персонажа мистера Томпкинса для объяснения современных научных теорий, ДеМарко использует своего персонажа — Вебстера Томпкинса — для определения правил и методов управления проектами.
История начинается с похищения Вебстера Томпкинса, доставленного в вымышленную страну Восточного блока Моровию, недавно преобразованную в публичную компанию.
Там нашему главному герою дается задание выполнить шесть масштабных проектов по разработке программного обеспечения с огромной командой разработчиков и значительным давлением сроков.
Имея много сотрудников, он создает лабораторную среду для экспериментов по управлению проектами. Идея состоит в том, чтобы разделить проекты на 18 команд, по 3 на каждую из 6 проектов.Команды бывают разного размера, с разным опытом, возрастом и составом, а также по-разному управляются. Когда команды соревнуются друг с другом, Webster Tompkins может оценить различные методологии управления проектами. Как и в любом реальном сценарии, во время проекта команды сталкиваются с проблемами, такими как изменение сроков, содержания и многого другого.
В конце каждой главы Вебстер Томпкинс резюмирует свои мысли и понимание трудностей современной науки об управлении на примере разработки программного обеспечения.
DeMarco описывает не просто проект, а сложную программу.
Автор следует стилю типичного триллера, но в то же время сумел легко и понятно включить элементы управления проектами. Вам не нужно быть опытным менеджером проекта, чтобы следить за контентом, новичкам или юниорам быстро покажут, в чем могут заключаться подводные камни проектов. В увлекательной и увлекательной форме автор дает легко доступное понимание управления проектами.
Давайте подведем итог того, что говорит ДеМарко, в четырех разделах:
1.- Четыре принципа хорошего управления (все остальное — административное)
- Выбирайте правильных людей.
- Доверьте правильные задачи нужным людям.
- Мотивируйте сотрудников.
- Помогите командам стартовать и взлететь.
Это очевидные моменты, но наблюдается, что особенно в крупных компаниях часто уделяется мало внимания. Персонал проекта часто выбирается по его доступности, а не по опыту.Будь то отсутствие необходимых специальных знаний, потому что в команду был назначен «босс», а не сотрудник, который мог бы внести ценную информацию, или носители ноу-хау отправляются без полномочий на встречи, важные для принятия решений. Также не раз недооценивается мотивация сотрудников проекта. Мысль о том, что «сотрудничество в проекте — достаточная мотивация», — это еще не значит!
Том ДеМарко или его главный герой правильно понимают, что успех проекта решающим образом зависит от человеческого фактора — его выбора — а также от распределения задач, а не только от мотивации и лидерства.Недаром автор использует метафору «командование битвой» применительно к менеджменту, заявляя: «В начале битвы реальная работа менеджера уже сделана: собеседование и подбор персонала».
2.- Управление рисками
- Управляйте проектами, управляя их рисками.
- Тщательно фиксируйте риски каждого проекта.
- Изучите причинные риски, а не просто приведите к нежелательным последствиям.
- Оцените вероятность его возникновения и предполагаемые затраты по каждому риску.
- Для каждого риска ожидайте самого первого симптома, при котором он может появиться.
- Назначьте сотрудника по рискам, сотрудника, который избавит вас от позиции «Мы можем-делать».
- Установите неформальные (возможно, даже анонимные) каналы, по которым плохие новости могут передаваться до самых высоких иерархических уровней.
Любой, кто уже руководил проектом, знает о важности управления рисками, но также и о том, насколько велика возможность решить эту проблему без должного внимания.Никогда не кажется подходящим временем. В начале каждого проекта на первом месте стоит анализ целей проекта, планирование и организация ресурсов. Если проект уже запущен и работает, изменения сроков, сдвиги целевых показателей и расширение бюджета настолько требовательны с точки зрения времени, что почти не остается места для управления рисками. Том ДеМарко справедливо отмечает, что проектами можно успешно управлять через риски, поскольку они являются основной причиной значительных отклонений в заранее определенном треугольнике проекта (цель / срок / бюджет).Подробное заявление о риске, по крайней мере в начале, в основном дает четкий обзор возможных опасностей, которым можно противодействовать на ранней стадии. Четкий анализ риска с вероятностью возникновения, оценочными затратами, ведущими к величине риска, считается важным.
Однако ДеМарко выходит за рамки инструкций в учебниках и дает полезные советы о том, как решать проблемы реализации риска, «распознаваемости ущерба» и «эскалации» на практике. Во-первых, прогнозирование реализации риска может быть полезным индикатором возникновения риска.Специалист по рискам, которому просто НЕ следует верить в успех проекта или, скорее, должен быть против него, является большим подспорьем для раннего распознавания ущерба. В проектах часто случается, что чем выше проблема или риск, тем меньше критичность. Так называемый «красный» риск может оказаться «зеленым» на доске или на самом высоком уровне. Следовательно, предложение неформального или анонимного общения до самого высокого иерархического уровня заслуживает всяческого одобрения.
3.- Метрики
- Размер каждого продукта должен быть измерен.
- Над единицами измерения надо ломать голову — пока у них нет объективной массы, выбирайте единицы измерения субъективные.
- Сделайте синтетическую массу из всех доступных примитивов (счетные программные свойства).
- Собирайте археологические данные для определения тенденций продуктивности по завершенным проектам.
- Продолжайте экспериментировать с формулировкой синтетической метрики, пока ваши значения не будут оптимально соотнесены с усилиями по разработке проектов, изучаемых в вашей археологической базе данных.
- Проведите линию тренда в базе данных, показывающую ожидаемые усилия по разработке как функцию синтетических значений метрики.
- Теперь, чтобы оценить стоимость каждого нового проекта, вычислите значение синтетической метрики и используйте ее для определения ожидаемых усилий по разработке по линии тренда.
- Примите величину отклонения от тренда производительности как показатель допусков, которые вы должны ожидать при экстраполяции.
Использование метрик дает несколько преимуществ в процессе разработки программного обеспечения.Решающим моментом является улучшение безопасности планирования при анализе трудозатрат. Часто обычная оценка усилий опытным программистом на основе «ощущений» может быть улучшена с помощью показателей, особенно для очень сложных проектов. При дальнейшем исполнении проект становится управляемым, но, прежде всего, контролируемым для руководителя проекта. В «Назначении» справедливо подчеркивается, что без определенного количества данных полученные результаты не являются окончательными, возможность сравнения еще не дается.В идеале эта масса данных получается от отдельной проектной группы. Однако значения от других команд или других компаний (археологические данные) также могут использоваться в качестве начальных значений. Однако они не могут отражать конкретные обстоятельства отдельной команды или ее окружения.
Однако следует отметить, что синтетическая метрика, используемая в качестве метода оценки и измерения, основанная на большем объеме данных, не всегда проста и визуально представима. По сути, не программисты или менеджеры проектов решают, сколько денег на что потратить, а менеджмент среднего и высшего звена, и именно поэтому результат метода графически и не должен быть представлен слишком сложно, что может привести к дальнейшие проблемы.
4.- Неоднозначные характеристики
- Неопределенность в спецификации указывает на конфликт между различными заинтересованными сторонами в системе.
- Спецификация, не содержащая полного списка входов и выходов, является провалом; он даже не соответствует требованиям спецификации.
- Никто не говорит вам, что спецификация паршивая. Люди склонны винить себя, а не спецификацию.
Качество или минимальные требования спецификации (в данном случае спецификации или спецификации) снова и снова вызывают споры.ДеМарко дает относительно простую формулу, с помощью которой можно проверить хотя бы минимум, а именно затраты и затраты. Предполагается, что каждая спецификация состоит из двух частей: набора всех процедур, которые определяют, как поведение системы зависит от событий (процессов), и набора всех входов и выходов (данных), от которых зависит поведение. Поскольку это потоки данных или управления, их можно перечислить в форме списка. В этом случае сложность системы определяется методом, а не данными.Однако, если они отсутствуют, отсутствует «простая» основа.
Неопределенность в спецификации — если это необходимо — ДеМарко справедливо определяет как конфликт между группами интересов. Это переносит решение проблемы к аналитикам или программистам, которые затем должны выбрать сторону, или к фазе тестирования, где неоднозначность проявляется в однозначности, но только для одной стороны.
«Крайний срок» — увлекательная книга, которая держит в напряжении до конца и утоляет жажду знаний читателя, интересующегося управлением проектами.Несмотря на концентрированную передачу знаний, принципы управления проектами говорят сами за себя, а дневниковые сводки после каждой главы позволяют успешно повторить ранее прочитанное. Таким образом, ДеМарко удалось не только рассказать забавную историю, но и передать базовые знания. Если его передача знаний поначалу кажется очень простой, нужно скоро понять, что его выводы и советы выходят за рамки обычной научно-популярной литературы.
Итак, немного тяжеловато для читателя без опыта работы с PM, но, учитывая его беззаботный подход, я рекомендую вам продолжать.Управление проектами заключается в знании действующих переменных и, где это возможно, их контроле для достижения наилучшего результата.
Хотите оставить комментарий? Безусловно, пожалуйста, сделайте это.
Я могу только порекомендовать всем присоединиться к Вебстеру Томкинсу в его приключении в Моровии и вдохновиться им и его дневниковыми записями.
идей из «Крайнего срока» Тома ДеМарко — karneliuk.com
Привет, мой друг,
Недавно я нашла в Интернете интересную книгу, описание которой меня очень заинтриговало.Книга называется «Крайний срок», написанная Томом ДеМарко. Его рекламировали как роман об управлении проектами, поэтому я решил купить и прочитать его. Одним словом, оно того стоит.
О чем это?
Книга действительно хорошо написана. Мне очень приятно читать «Крайний срок» в первый раз, и я собираюсь прочитать его еще раз, чтобы еще раз обдумать некоторые детали. На самом деле он написан как роман, где есть хорошие и плохие персонажи, которые играют определенные роли, пейзажи, где происходит история, и сами действия.Поэтому читать «Дедлайн» очень легко и интересно, по крайней мере, на мой взгляд. С другой стороны, это не просто роман, это роман об управлении проектами. Вот почему каждая глава заканчивается коротким тезисом, который содержит ключевые идеи из главы, которые применимы к управлению проектами. Если вы, как и я, были очень увлечены чтением содержания главы, этот тезис напомнит вам о результатах, которые вы должны понять и запомнить.
Я искал информацию об авторе, потому что у меня не было желания читать что-то от тех современных ребят, которые сами не руководили никакими проектами.К сожалению, я видел в своей жизни таких «консультантов» или «инструкторов» (и такой пример тоже хорошо описан в этой книге), и они меня совсем не вдохновляют. Wiki сообщает, что Том ДеМарко имеет очень большой опыт в разработке программного обеспечения и управлении этим процессом. Эта информация также (помимо хорошей рекламы) убедила меня прочитать эту книгу.
Ключевые моменты для меня
Основная идея, которую я ставлю на первое место в своей лестнице, заключается в том, что самая важная часть любого проекта — это команда и люди.Как говорит главный герой в одной из первых глав, «люди делают проекты», а затем он продолжает подробное объяснение. По его словам, основными задачами руководителя проекта являются:
- Найдите нужных людей
- Дайте каждому самую подходящую работу
- Развивайте и вдохновляйте команду
- Держать команду вместе в критической ситуации
Хотя эти утверждения кажутся очень простыми и очевидными, я сам раньше не уделял им столько внимания.Я сравнил это с тем, что есть в PMBOK. На самом деле у нас есть область знаний по управлению человеческими ресурсами проекта, но в ней кратко обсуждаются 4 процесса (планирование управления человеческими ресурсами, сбор команды, разработка команды и управление командой). Конечно, «один размер не подходит всем», поэтому «Крайний срок» Тома ДеМарко предоставляет много интересной информации (и практических советов) об управлении командой и общих межличностных отношениях.
Последнее для меня — второй ключевой момент книги.Есть много общих (к сожалению) примеров взаимоотношений внутри команды, между менеджером и командой, заинтересованными сторонами и командой, когда эти отношения далеки от продуктивных, эффективных и уважительных. Эти примеры содержат практический подход к действию в конкретной ситуации и объяснение возможных коренных причин такого поведения людей.
Третья идея, о которой я хочу рассказать в этом посте, — это моделирование и симуляция. В этой книге в общих чертах описано, как такие методы помогают определить будущее проекта.На мой взгляд, приведенный пример представляет собой красочную презентацию параметрической оценки и метода Монте-Карло, оба из которых описаны в PMBOK и которые мы довольно часто используем на начальных этапах и этапах планирования проекта. Причина, по которой я изложил эту информацию, заключается в особой важности и помощи, которую может принести этот инструмент при правильном использовании. Обычно я видел, что люди не собирают достаточной статистической информации, и в результате эта параметрическая оценка дает неточный результат.Но если вы соберете достаточный объем информации и обновите свою модель новой информацией из текущего проекта, то вы получите действительно полезный инструмент. Такой инструмент значительно повысит уровень точности вашего прогноза.
Извлеченные уроки
PMBOK — очень хорошая книга, охватывающая практически все темы, связанные с управлением проектами. Но без необходимого опыта (или хотя бы объяснения с красочными примерами) эту информацию будет сложно понять.Есть много интересных книг, видео и статей, которые, вероятно, не помогут вам сдать экзамен PMP (Project Management Professional), но наверняка помогут вам стать лучшим менеджером проекта.
Заключение
«Один размер не подходит всем», и это также применимо к этой книге. Я нашел в этой книге информацию по наиболее актуальным для меня темам. Я почти уверен, что вы найдете что-то другое, актуальное для вас. Даже если вы очень опытный руководитель проектов, вы найдете в этой книге интересные истории.И в чем я абсолютно уверен, так это в том, что эту книгу стоит прочитать и она станет хорошим дополнением к вашей библиотеке управления проектами.
Поддержите нас
Поддержите новые статьи о взаимодействии и автоматизации на karneliuk.comевро Я хочу поддержать:
9,99 евро 4,99 евро 24,99 евро 49,99 евро 99,99 евро199,99 евро
BR,
Карнелюк Антон
Dorset House Publishing — Крайний срок
«Вот книга по менеджменту, которую очень интересно читать. Deadline — это новаторская и увлекательная история с проницательным бизнесом. принципы командного управления проектами в конце каждой главы.«
— Атлантика Системная гильдия
«Поскольку большинство менеджеров программного обеспечения вышли из ряды программистов и, соответственно, понятия не имеют об управлении проектами, ситуация созрела для обучения на собственном примере. Вот к чему обращается Том ДеМарко с The Deadlne. . . . развлекательно — и одновременно поучительно. . . . много ценных техник.
—Уоррен Койфель
Разработка программного обеспечения
« Срок истек на.Это обязательное к прочтению и увлекательное чтение для всех, кто когда-либо был или когда-либо будет участвует в программном проекте. Том ДеМарко упаковал коллективную мудрость и тяжелые уроки, извлеченные ведущими пророками, гуру и оракулами программного обеспечения в этот дразнящий, проницательный и откровенно развлекательный «роман» ».
— Будет
Tracz
Примечания по разработке программного обеспечения ACM
«Вот книга по менеджменту, читать которую просто интересно. Срок новаторская и увлекательная история с проницательными принципами ведения бизнеса для командное управление проектами в конце каждой главы.»
— Джон Скалли
«Когда люди решили поделиться тот вид здравого смысла, который слишком часто отсутствует в бизнесе программного обеспечения, они обычно звучат проповеднически и самодовольно. Том избежал этой ловушки благодаря хитрое использование рассказов. Он также был вовлечен в достаточно конфликтных ситуаций и напряжений, чтобы получить читательский интерес. В целом, это расслабляющее и информативное чтение. «
— Вт С. Хамфри
«Книга интересна и долговечна, как разработчики распознают большинство проблем их развития.. .
«Не только это занимательно, но в процессе вы даже можете научиться некоторым управленческим навыкам ».
— Charles
Ashbacher
Charles Ashbacher Technologies
размещено на Amazon.com
«… это технологический тур де сила. Он охватывает широкий круг тем, от оценки проекта до метрик, от разрешение конфликтов для работы с неоднозначными спецификациями. . . . пуля одни только очки стоят цены книги.. . . Срок почти смешно, как книга, полная мультфильмов Дилберта, но гораздо менее цинична. Более важный, в нем содержится некоторая глубокая мудрость и несколько практических, положительных советов для повышение шансов уложиться в срок вашего следующего проекта. я очень рекомендую it. »
— Эд Йордон
Американский программист
«Том Демарко снова радостно снимает луковичные слои проблем управления. с человечностью и проницательностью, которые так же легко трансформируются в общее корпоративное управление как они это делают в управлении программными проектами и командами.В Срок , он насмехается над книгой, полной абсурдности нашей повседневной работы жизнями и с метрическими устройствами, которые могут помочь нам управлять и работать лучше. Это Функциональные очки, тупица! »
— Брюс Тейлор
Издатель-учредитель
Imaging World Magazine
«A юмористический, художественный взгляд на разработку программного обеспечения. . . предлагает сбалансированный подход к управлению проектами. Автор справедливо указывает на людей как на основную основу всех успешных проектов.»
— Дайджест качества
» Я прочитал эту книгу. . . и был сразу впечатлен тем, насколько успешно ДеМарко связывает управление проектами программного обеспечения и качество программного обеспечения в увлекательной манера. Я видел актуальность как для нынешних профессионалов в области программного обеспечения, так и для тем, кто стремится работать в поле. Как профессор я решил включить это в мой класс управления качеством программного обеспечения. . .
«Рецензия на эту книгу отличается от других тем, что большая часть обзора состоит из комментариев от моих учеников.. . . Ниже приведены их ответы.
«‘Эта книга очень ценный. Это дает реальный взгляд на проблемы, которые могут возникнуть в большом проекте. . . . ДеМарко отлично показывает читателю, как решать проблемы. Он охватывает множество аспектов, таких как размер команды, разрешение конфликтов, дизайн, эмоции, патологическая политика, метрики и т. д., чтобы научить читателя наиболее эффективным способы правильно запустить проект. Эта книга многому меня научила, и читать.’
«‘Книга заставила меня осознать множество важных концепций и заставила меня тоже много думаю.Я не просто читал это — я думал о том, как бы я реагировать в некоторых из данных ситуаций. . . «
» … Эта книга является новаторской подход к управлению проектами, и ДеМарко решает, что может быть болезненно сухой предмет во что угодно, кроме этого. »
— Доктор Патриция
Маккуэйд
Доцент кафедры информационных систем управления,
Калифорнийский политехнический государственный университет
Специалист по качеству программного обеспечения
«In Во многих отношениях эта книга является спутником книги «Мифический человеко-месяц ».Например, Мистер Томпкинс тестирует «бросить людей в проект, чтобы уложиться в ускоренный график». теория (есть ли предположения относительно результата?). И как TMMM , The Deadline , позиционируется как технологическая книга, но содержит уроки для всех менеджеров. Оба проповедуйте важность планирования. . . .
«Краткие главы, быстрое чтение, много смеха, уроки без цинизма Dilbert или UserFriendly , итоги обзора. Сильно рекомендовать это для принципы применимы к любому менеджменту, а не только к разработке программного обеспечения.. . .
«Новым является то, что Демарко использует юмор и рассказывание историй. проповедовать концепции (и награды) хорошего управления. Когда ты можешь вспомнить громко смеяться, читая книгу по менеджменту? Только для этого книга достойное дополнение к библиотеке любого менеджера ».
— Кэти
E. Gill
Информационный бюллетень ITG
«Для все вы, которые искали роман о разработке программного обеспечения, действительно затрагивает бизнес, вот и все. The Deadline Том ДеМарко — это редкая порода художественной литературы, которая содержит не только рассказ, но и диаграммы и диаграммы. . . .
«У нас осталось ощущение, что возможность существует только в данный момент, и настоящая причина, по которой мы работаем, — это только учиться потому что обучение — это то, что наполняет каждый наш опыт смыслом ».
— Майкл
Гуахардо
Agile Alliance
«. . . Мне понравился The Deadline , и я узнал из него несколько интересных вещей.. . . Дедлайн как метод обучения мне подходит. Как басни Эзопа, он дает мне воспоминания по каждому пункту о людях, проектах и управлении что DeMarco хочет сделать «.
— Сью Петерсен
Visual Developer
» Это полностью другой взгляд на управление проектами — тот, который не является ни сухим, ни скучный. И хотя история оформлена как забавный роман, есть еще много чего. учиться. Вкратце: The Deadline — это книга, в которой автор Том Демарко без труда преодолевает границу между развлекательным и профессиональным содержание.. . .
«После каждой главы Том Демарко использует основы управления, чтобы подвести итоги событий. Благодаря этому и легко читаемому, новая платформа, различные термины легче визуализировать и понять, чем они будет в книгах, которые касаются только технических аспектов управления проектами ».
—inGenics Новости будущего
Срок
от Томас Хюн
The Deadline Тома ДеМарко — настоящая классика управления проектами.Я купил это довольно давно, но он пылился на полке, несмотря на то, что Мне понравилась его книга «Peopleware». Оказывается, это была ошибка. Собирающая пыль, не чтение, заметьте.
Это книга по управлению программными проектами, замаскированная под роман. И пока это читать приятно, иногда даже смешно, как роман, он не стоит многого. Но эта продуманная упаковка значительно упрощает освоение.
Наш главный герой, менеджер проекта, который недавно потерял работу из-за того, что высказал свое мнение: одурманен наркотиками и похищен очаровательной молодой женщиной, которая «обретает» талант для развивающейся индустрии программного обеспечения Монровии, вымышленной страны бывший Восточный блок.
У них много-много разработчиков программного обеспечения, несколько менеджеров и желание стать крупнейшим поставщиком программного обеспечения в мире. Шесть программных продуктов уже было запланировано (все подделки хорошо продаваемых программ, таких как Photoshop), и теперь это время реализовать это видение.
Кроме того, наш главный герой и его доверенные старшие сотрудники намерены провести несколько реальных съемок. эксперименты: создание трех разных команд для этих шести продуктов, чтобы разные подходы можно сравнивать и количественно оценивать.
Роман вводит проблему (например, личные конфликты между разработчиками или сжатые сроки). в каждой главе, как правило, с новым персонажем, имеющим отношение к рассматриваемой проблеме. Этот новый персонаж часто является всемирно известным экспертом в этой области, его прилетают (или посещают) и дает ключевую информацию днем. Очевидно, эта повторяющаяся тема — одна из причин, почему книга не является романом как таковым.
Читатель должен четко осознавать, что эти эксперты не настоящие эксперты, а направляя убеждения Тома ДеМарко.Это нормально, потому что это презентация Тома ДеМарко, но читатель не должен запутаться, так как персонажи книги понимают каждое слово этих экспертов как Евангелие, никогда не ставя его под сомнение, никогда не находя противоречий или прямых противоречий с другими мнения экспертов. Читатель не должен успокаиваться и делать то же самое.
Каждая глава заканчивается несколькими короткими заметками о том, что узнал наш главный герой. И их довольно много настоящие самородки там. Они никогда не бывают слишком подробными, это пища для размышлений.Мне это нравится, потому что это избавляет книгу от рутинной работы, которую делает большинство книг по управлению проектами. Помните, никаких доказательств обоснованность даны, это прямой совет автора. Возьми это или оставь.
Хотя большинство из этих моментов были довольно очевидными, иногда даже тривиальными, я хотел бы повторить некоторые другие здесь. Некоторые из них важны и, по крайней мере, в некоторой степени новы для меня. В некоторых не было ничего нового, но они говорили со мной, потому что у меня есть личные воспоминания, относящиеся к ним.Другие просто вызвали у меня какие-то мысли, которые я не хочу терять. Так что вместо того, чтобы перечитывать книгу позже, я надеюсь, что эти заметки могут послужить напоминанием о мясе. об этом, как я это видел.
Анонимные признания
Один из первых уроков заключается в том, что должен существовать анонимный способ сообщения о проблемах вверх по иерархии. В романе он представлен как настоящая исповедальня, завершенная церемонией, основанной на католическая верность.
Конечно, этот механизм не ограничивается сообщением о собственных сбоях и проблемах.На самом деле это больше вероятно, что это приведет к сообщениям о проблемах в областях, которые репортер не контролирует, Я думаю.
Один интересный поворот заключается в том, что духовник в романе всегда очень хорошо знает личность кающийся (на самом деле, я думаю, есть не так много людей, обладающих как знанием какого-то предмета, и нет лучшего способа сообщить об этом), но никогда не позволяет это показать. Это, наверное, важно, потому что как только чем выше будет эта иллюзия анонимности, тем больше иссякнет.
Риск-офицер
Управление рисками в проекте чрезвычайно важно. Хотя всем поручено управлять рисками, должен быть назначенный специалист по рискам. Кроме того, этот риск-офицер (конечно, при поддержке команды) должны выявлять ранние признаки важных рисков задолго до того, как они могут материализоваться, а затем постоянный поиск этих индикаторов.
Опасности Can-Do
Хотя многие менеджеры рассматривают умение делать все как можно лучше, это создает опасность подстегнуть команду. для предотвращения сообщения о рисках и проблемах по служебной лестнице.
Повышение производительности
Нет возможности для краткосрочного повышения производительности, потому что каждый здравомыслящий член команды справляется с этими низко висящими фруктами самостоятельно, чтобы устранить источники разочарования.
Я думаю, это может быть преувеличением, потому что иногда руководство может помочь устранить эти убийцы времени. Например, босс однажды ввел политику, согласно которой члены команды явно разрешено указывать время дня, когда они не отвечают на телефонные звонки (и объявлять это время), а также повесить табличку «Не беспокоить» на своем столе в офисе открытой планировки.Эффектов тоже не было большой, насколько я помню, главным образом потому, что это были неадекватные средства устранения основной причины.
Моделирование догадок
В очень интересной первой главе высшее руководство зарождающейся новой индустрии программного обеспечения Монровии явным образом моделируйте их «интуицию» или внутреннее чутье относительно того, насколько эффективны тренировки и персонал колебания имеют по завершаемым работам. Это означает не просто рисование диаграмм, а собственно используя инструмент моделирования на компьютере и количественно оценивая переходы внутренних состояний.
Это служит не только инструментом для передачи своих догадок другим членам управленческой команды, и, следовательно, для сравнения и уточнения этих догадок. Это также позволяет подключать реальные измерения, таким образом улучшая понимание эффектов на работе.
Возможно, это был для меня самый удивительный урок из книги. У меня есть постоянные сомнения относительно его практичность, не только количественная часть, но и способность вызывать в воображении полуреалистичный модель, но похоже, что на самом деле инструменты для этой цели продаются и используются.
Нравится
На самом деле симпатия к людям, с которыми вы работаете (или особенно «против»), а не только притворство, облегчает задачу. найти точки соприкосновения и убедить их в том, что вам очень нужно.
Давление
Давление часто используется как способ добиться большего результата в работе и еще большей производительности. Нет жизнеспособное средство для этого. Но давление, применяемое разумно и не слишком долго, может сигнализировать об усилении важность какой-то работы для команды.Поэтому сам по себе это неплохо, но обычно применяется деструктивно (не в фокусе: слишком много, слишком долго).
Кроме того, люди используют давление на своих подчиненных, чтобы продемонстрировать начальству, что они сделали все, что в их силах, для достижения (возможно, упущенной) цели.
Внутренние сомнения
У большинства людей есть внутренние сомнения относительно своих способностей или интеллекта. Вот почему они не смеют высказываться, когда какой-то документ непонятен, потому что все остальные, кажется, прекрасно его понимают.На самом деле, у всех могут быть похожие мысли, но этот эффект самоподдерживается, и поэтому проблема скрыто.
Спецификация
Минимальное требование для того, чтобы документ считался спецификацией, состоит в том, чтобы иметь и то, и другое:
- Политика: как система реагирует на события? Это сложная часть.
- Входы и выходы. Их можно определить кратко и точно.
Лично я бы добавил по крайней мере третью часть: данные и (внутреннее) состояние.Начиная со структур данных и только тогда определение операций над ними обычно бывает выгодным.
Неопределенность скрывает конфликты
Двусмысленные формулировки в спецификациях обычно возникают из-за нерешенного конфликта между заинтересованными сторонами. назревает, и автор не может быть ясным и точным, потому что это решило бы продолжающийся конфликт.
Это открытие было для меня новым. Тем не менее, я думаю, что множество двусмысленностей в спецификациях не из-за неразрешенных конфликтов, а из-за отсутствия информации.Почему автор не может просто спросить до тех пор, пока он не узнает ответ? Часто потому, что решения, относящиеся к проблеме, еще не приняты, и ответственность какой-то другой группы. В известном смысле это можно назвать конфликтом расписания, я полагаю, но Я бы не стал разбирать это по рубрике «конфликт».
Персонал
Начните проект с несколькими людьми и сделайте правильный дизайн. Не более чем горстка членов команды может внести свой вклад значимым образом, потому что на этом этапе каждый должен иметь представление о большой картине, без специализации возможно.
Когда проект переходит в этапы, когда над четко определенными рабочими пакетами можно работать индивидуально (например, кодирование), массово расширить команду.
Как опоздавший в моем бывшем проекте, коллеги рассказали мне, как это было вначале. Небольшая команда дизайнеров яростно разрабатывал спецификации для (дюжины или около того) полностью укомплектованных команд, над которыми нужно было работать, но они были безнадежно затоплено, конечно. Так что команды в основном сидели сложа руки.
С другой стороны, я очень сожалел, что меня не было в самом начале.Столько решений было не только укоренились в дизайне (и в исходном коде!), но это также своего рода фольклор. Первоначальная команда дизайнеров переехала по некоторым вопросам никто в компании больше не знал, почему были взяты определенные направления. Некому было спросить.
Гнев = страх
В деловом контексте никто не боится, потому что потеряет лицо. Гнев — это полу-приемлемая замещающая эмоция, поэтому люди набрасываются, когда боятся.
Но когда все узнают об этой замене, та же самая тенденция к предотвращению потери лица будет подавлять вспышки гнева.
Обзор: крайний срок
- Название
- Срок
- Автор
- Том ДеМарко
- Издатель
- Нью-Йорк: издательство Дорсет Хаус, 1997
- ISBN
- 0-932633-39-0
Обзор Copyright © 2000 Garret Wilson — 8 сентября 2000 г., 14:26
Когда изменчивый, избитый художественный материал о международных интригах — это то, что нельзя упускать? Три причины: когда это весело, когда это раскрывает правду, и когда это весело, потому что раскрываемые истины настолько знакомы.
Роман Тома ДеМарко « The Deadline » вызывает в воображении забавную историю о Вебстере Томпкинсе, менеджере проекта в крупной компании, которого похитил секретный агент из национального штата Моровия. Morovia хочет стать международной державой в области программного обеспечения и считает, что Вебстер — именно тот человек, который ей нужен, чтобы возглавить эту работу. Да, набор функций слишком велик. Да, в расписании не хватает времени. По крайней мере, с боссом Вебстера легко работать — до тех пор, пока, конечно, его босс не будет заменен каким-нибудь упрямым маньяком, который сокращает графики и создает всевозможные препятствия, делая невозможное еще менее вероятным.
Однако с самого начала очевидно, что роман предназначен для развлечения, чтобы все в корпоративной Америке узнали об этом из первых рук. Когда Вебстер подозревает, что Лакса, подлый шпион из Моровии, намеревается попытаться навредить своей компании, похитив сотрудника, он пытается угадать, кто это будет:
«Я полагаю, вы могли бы просто выбрать самых выдающихся человек в организации. Разве это не было бы так просто?»
«Станьте серьезным. Если бы я действительно хотел причинить вред этой организации, например, выбрал бы я самого известного человека? Например, генерального директора?»
«О.Ну, конечно, не в этом случае. Думаю, если вы уберете генерального директора, акции компании, вероятно, вырастут примерно на двадцать пунктов ».
«Совершенно верно. Это то, что я называю эффектом Роджера Смита в честь бывшего председателя General Motors. Я был тем, кто решил саботировать GM, не сместив Смита» (8).
Похищение Вебстера Лакса не для того, чтобы навредить своей компании, а чтобы помочь своей стране, и Вебстер быстро соглашается выполнить свою трудную задачу. Вебстер, конечно, не всезнающий, поэтому по пути на помощь Вебстеру приходят другие эксперты со всего мира (или их похищают, хотя бы временно).В качестве всего лишь одного примера доктор Виннипег описывает, как дипломатично сокращать группы, когда присутствует слишком много людей.
«Если люди чувствуют себя небезопасно и созывается собрание без повестки дня, они должны присутствовать», — говорит д-р Виннипег (270). Даже имея повестку дня, иногда необходимо собрать меньшую группу. Его совет — заявить о ценности освобождения одного или нескольких человек из группы, получить одобрение группы, а затем указать причины, по которым этим людям не следует тратить свое время на собрание.«Они могли бы встретиться в одиночку, чтобы выработать некоторые из наших ключевых протоколов. Освобождение их от этой встречи было бы бесценным», например (272). Затем человек (а), уходящий, делает прощальное заявление, а затем группа выражает свое одобрение.
Вебстер хранит все эти советы в записной книжке, которую он обновляет на протяжении всей книги — причудливый способ поместить резюме в конце каждой главы. Некоторые из его советов продвигаются многими другими в индустрии программного обеспечения:
Управление рисками
- Управляйте проектами, управляя их рисками.
