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

— Мне уже кажется, что да.

В дверь постучали, и миссис Бирцих объявила, что пришла Аврил Альтербек, руководитель команды PShop-B. Мистер Томпкинс радостно приветствовал ее.

— Привет. У меня есть шанс заполучить минутку вашего драгоценного времени?

— Сколько угодно, — улыбнулся мистер Томпкинс и указан ей на стул возле Белинды. — Что у тебя случилось?

— Мне нужна помощь высшего руководства. Предупреждаю сразу: это вам будет дорого стоить.

— И что же ты просишь? — спросил мистер Томпкинс. «Лишь бы не время, лишь бы не время…»

— Нам необходима куча народу.

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

— Ох, Вебстер, я это все знаю, — остановила его девушка. — Я знаю, чем опасны большие команды. Но у нас совсем другой случай. Ситуация изменилась. У нас уже есть готовый дизайн системы — отличный, продуманный до мельчайших подробностей. Аристотель говорит, что даже он редко встречал такие. Впрочем, он сам очень много помогал нам и подсказывал хорошие решения. Теперь мы тестируем его, а скоро нужно будет браться и за реализацию! Для этого я и прошу у тебя людей, Вебстер. Сейчас нас семеро — пятеро разрабатывают дизайн, а двое работают в группе поддержки. Но через два месяца нам нужно будет еще двадцать человек, которые бы писали код.

Белинда радостно вскочила со стула:

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

— Да, так и есть. Я как раз хотела рассказать вам, что именно у нас получилось…

— Сколько, сколько их, Аврил? — не смогла сдержать интерес Белинда.

— Э-э, тысяча шестьсот семьдесят семь модулей, около тысячи трехсот элементов данных, восемнадцать файловых структур, двадцать элементов-модулей…

— Слушай, похоже, тебе нужно больше, чем двадцать программистов?

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

Белинда просто не могла усидеть на месте.

— Вебстер, ты просто обязан дать ей людей. Тридцать пять, столько, сколько ей на самом деле нужно. Вот оно! Мы на правильном пути!

— Погоди. Погоди минутку. Не можем же мы вот так взять и привести в команду к Аврил тридцать пять человек. Да у них работа вообще остановится! Ей придется только и делать, что вводить новичков в курс проекта и объяснять задачи.

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

— Тридцать пять человек, которые прекрасно знают всю подноготную PShop’a?! Да откуда же я их возьму?

— Разгонишь команду А, — ответила Белинда.

Аврил ушла, а Белинда и Вебстер стали обсуждать сложную политическую проблему, связанную с переносом стольких людей в другую команду.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

— М-да…

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

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

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

Из записной книжки мистера Томпкинса

О персонале

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

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

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

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

5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!