Мысли по поводу Deadline

Выдалось немного свободного времени и я решил перечитать замечательную книгу по управлению проектами - Deadline от Тома Демарко.

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

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

Да, конечно, книга по управлению проектами, т.е. таргет-группа прежде всего менеджеры, однако разработчики вынесут для себя много полезной информации. Я для себя вынес следующее (в скобках - мои субъективные комментарии):


1. Необходимо оценивать и учитывать риски. Риски бывают всегда и хорошо, когда есть время на устранение их последствий. (У меня этот пункт очень хромает - мои оценки задач часто бывают очень заниженными. Есть простое правило - спроектируй, оцени, умножь на 1.5 - надо научиться ему следовать).

2. Если хочешь успеть - убирай лишнее. Желание все переделать - это хорошее, но малополезное для бизнеса желание. (Лучше система без некоторых заявленных фич, чем система, где эти фичи глючат или работают совсем неправильно. По этому пути в свое время пошли в Microsoft, когда не стали делать WinFS в Vista. Лучше выпустить ОС без новой файловой системы, чем эта файловая система будет падать и терять данные.)

3. Но нельзя забывать о рефакторинге. Иногда, потратив X (а лучше - Y, Y - больше) часов на рефакторинг, можно сэкономить 10*X часов при добавлении фичи. Но, необходимо помнить, что рефакторинг сложной подсистемы за 2 недели до релиза - как правило является злом.

4. Больше всего времени тратится на отладку (и это действительно так, правда в последнее время у нас в DMS ситуация несколько улучшилась). Следовательно, необходимо ее сокращать или убрать совсем. Но как это сделать, не потеряв в качестве? Вывод - проектирование. Чем детальнее будет спроектирована система, тем меньше времени займет написание кода и отладка. Однако возрастают риски. Т.к. если система спроектирована не правильно, мы не успеем вовремя. (Здесь очень может помочь Design Review).

5. Проектируйте малой группой! На этапе проектирования, пока оно не завершено досконально должно работать максимум 4 человека. Только потом необходимо набирать основную массу программистов. (Иногда этот метод называют методом фреймворка - группа высококвалифицированных программистов разрабатывает ядро и системные интерфейсы, а остальные затем пишут бандлы/плагины/dll-ки и прочий код, который уже реализует основные фичи).

6. Нельзя давить на разработчиков (мне кажется это - самый важный пункт). Такое давление не приносит положительного эффекта, а ведет к тому, что люди будут вас обманывать.

7. Конфликт - это не следствие непрофессионализма, а нормальное явление. Основное правило - договариваться тяжело, легче стать посредником. Главное - понять, что спорщики находятся не по разную сторону баррикад, они на одной стороне, на другой стороне - проблема. Но улаживать конфликты - это искусство. (Добавлю, что любой выявленный конфликт - это хорошо. Он уменьшает количество невыявленных).

8. Сверхурочная работа - зло. Чем больше сотрудники работают сверхурочно, тем ниже их производительность, причем не на уровне часа, а вообще. Вот такой вот парадокс, который на самом деле не парадокс. (Де Марко объясняет это тем, что люди просто начинают филонить, мол, я все равно до 22:00 сегодня, поэтому сейчас часик посижу в инете, а потом все успею).

9. Иногда разумно выкидывать некоторые этапы разработки. Например, если приложение хорошо спроектировано и код пишется грамотно, можно выбросить этап Code Review (у нас - в Naumen DMS - Code Review делается только, если ты коммитишь код другого разработчика, который не имеет соответствующих прав).

10. На финишной прямой, если все идет нормально, руководителю делать нечего. Но, если что-то пошло не так, он обязан вмешаться!

Ну и для затравочки укажу еще несколько интересных книг о том же:
- Фредерик П.Брукс Мифический человеко-месяц...
- Том Демарко и Тимоти Листер Человеческий фактор: успешные проекты и команды
- Том Демарко Вальсируя с медведями
- Эдвард Йордон Путь камикадзе.

Приятного прочтения!

Понравилось сообщение - подпишитесь на блог или читайте меня в twitter