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

— А что бы на твоем месте сделал принципиальный руководитель? Кажется, ты так ставил вопрос еще совсем недавно? Принципиальный, честный руководитель ставит интересы проекта выше собственных. Ты должен сделать все от тебя зависящее, чтобы люди справились со своей работой и как можно быстрее. Пока ты руководствовался только этими принципами, насколько мне известно. А теперь пришло время распустить команды А и укомплектовать этими разработчиками команды Б и В. Это же очевидно!

— Бэллок нас заживо съест, — мрачно объяснил мистер Томпкинс. — Тот трехдневный выходной был перчаткой, которую он мог и не поднимать. (И не поднял.) А вот на роспуск команд А он просто не может не прореагировать. Мы сами заставляем его принимать меры.

— Что ж. Рано или поздно это должно было случиться.

— Рано или поздно, да. Только не на этой неделе. Аврил сказала, люди понадобятся ей через два месяца. Дай мне два месяца, и я распущу все команды А, обещаю.

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

— Да знаю я! И все же мы должны подождать. Я очень надеюсь, что через месяц-другой… — мистер Томпкинс замолчал и с тоской поглядел в окно. Может быть, не пройдет и месяца, как вернется Лакса или хотя бы ВВН, который найдет управу на Бэллока и отправит его туда, где тот был раньше.

Белинда нахмурилась. Такие слова явно были ей не по душе.

— Команда Аврил — только часть проблемы. Ее проект — один из самых крупных. Если ее ребята так далеко продвинулись, то как далеко ушли остальные команды Б и В, которые работают над проектами поменьше? Им тоже понадобятся люди, причем не через два месяца, как Аврил, а гораздо, гораздо раньше! Вебстер, мы просто должны распустить команды А. И сделать это надо прямо сейчас.

Мистер Томпкинс какое-то время молча рассматривал свои руки.

— Я знаю, — наконец мягко сказал он.

— Смотри, — Белинда опять оказалась у доски. — Когда работа по созданию архитектуры закончена, весь проект можно легко разбить на множество частей. Это справедливо не только для наших проектов, но и для всех проектов вообще. Мы нашли то, что вся наша отрасль не могла найти в течение тридцати лет, мы нашли главный принцип успешной разработки программ! Вот, гляди, подбор персонала в команду всегда осуществлялся вот так. А в идеале все должно быть совсем по-другому!

Мистер Томпкинс честно пытался сосредоточиться на том, что рисовала Белинда, а не на мрачных мыслях о том, как можно забрать людей из команд А.

— Ага… идеальная схема подбора персонала… ну да… конечно, ты права. Это то, что мы чувствовали на уровне подсознания. Только это совершенно противоречит сложившейся схеме, поэтому я до сих пор никогда не набирал людей таким образом.

— А я набирала. Правда, только сейчас понимаю, почему это правильно и хорошо. Тогда это был просто эксперимент в одном не очень важном проекте. Я бы никогда не решилась сделать такое в разработке одного из ключевых проектов компании. А надо было…

— М-да…

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

— Нужно провести эксперимент! — улыбнулся мистер Томпкинс. — Сравнить два совершенно одинаковых проекта, только перед одним поставить малореальные сроки, а перед вторым — вполне выполнимые.

— И второй обязательно победил бы! Я уверена.

О персонале

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

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

3. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.

4. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).