Том Демарко Deadline. Роман об управлении проектами


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

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

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

Главного героя книги – руководителя проекта похищает шпионка Анна Чапмэн Ласка Хулигэн которая вывозит его тайно в страну 3его мира, где его добровольно-принудительно заставляют создать экспериментальный центр по разработке софта, создав 6 команд общей численностью в 1 000 человек, наблюдение за которыми должно позволить выявить как осуществлять менеджмент проектов по разработке софта лучше всего.

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

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

Процесс разработки и его улучшение

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

О вводе новеньких в команду. Новички – отталкивают проект назад, а текучка просто яд для проекта

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

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

Доктор Джамид посмотрел на схему. Он еще пару раз щелкнул мышкой и что-то ввел с клавиатуры — и схема была внесена в модель.

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

— Ну-ка, напрягитесь еще раз. Нарисуйте мне график того, что вы только что описали.

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


— То есть отклонение от идеального графика, или разница между действительностью и недостижимым идеалом, и есть «поправка на рост».

23.07.2010 опубликовал
в рубрике знания.



Get Adobe Flash player



Предыдущая статья: «

Следующая статья: »