— Бэллок нас заживо съест, — мрачно объяснил мистер Томпкинс. — Тот трехдневный выходной был перчаткой, которую он мог и не поднимать. (И не поднял.) А вот на роспуск команд А он просто не может не прореагировать. Мы сами заставляем его принимать меры.
— Что ж. Рано или поздно это должно было случиться.
— Рано или поздно, да. Только не на этой неделе. Аврил сказала, люди понадобятся ей через два месяца. Дай мне два месяца, и я распущу все команды А, обещаю.
— Она сказала, что люди понадобятся ей через две недели, но на самом деле ей нужно дать сейчас человек пять, которые станут ядром будущей большой команды.
— Да знаю я! И все же мы должны подождать. Я очень надеюсь, что через месяц-другой… — мистер Томпкинс замолчал и с тоской поглядел в окно. Может быть, не пройдет и месяца, как вернется Лакса или хотя бы ВВН, который найдет управу на Бэллока и отправит его туда, где тот был раньше.
Белинда нахмурилась. Такие слова явно были ей не по душе.
— Команда Аврил — только часть проблемы. Ее проект — один из самых крупных. Если ее ребята так далеко продвинулись, то как далеко ушли остальные команды Б и В, которые работают над проектами поменьше? Им тоже понадобятся люди, причем не через два месяца, как Аврил, а гораздо, гораздо раньше! Вебстер, мы просто должны распустить команды А. И сделать это надо прямо сейчас.
Мистер Томпкинс какое-то время молча рассматривал свои руки.
— Я знаю, — наконец мягко сказал он.
— Смотри, — Белинда опять оказалась у доски. — Когда работа по созданию архитектуры закончена, весь проект можно легко разбить на множество частей. Это справедливо не только для наших проектов, но и для всех проектов вообще. Мы нашли то, что вся наша отрасль не могла найти в течение тридцати лет, мы нашли главный принцип успешной разработки программ! Вот, гляди, подбор персонала в команду всегда осуществлялся вот так. А в идеале все должно быть совсем по-другому!
Мистер Томпкинс честно пытался сосредоточиться на том, что рисовала Белинда, а не на мрачных мыслях о том, как можно забрать людей из команд А.
— Ага… идеальная схема подбора персонала… ну да… конечно, ты права. Это то, что мы чувствовали на уровне подсознания. Только это совершенно противоречит сложившейся схеме, поэтому я до сих пор никогда не набирал людей таким образом.
— А я набирала. Правда, только сейчас понимаю, почему это правильно и хорошо. Тогда это был просто эксперимент в одном не очень важном проекте. Я бы никогда не решилась сделать такое в разработке одного из ключевых проектов компании. А надо было…
— М-да…
— Кстати, может быть, в этом кроется ответ еще на один вопрос. Этот вопрос всегда меня мучил. Я всегда подозревала, что проекты, перед которыми ставят жесткие сроки, всегда заканчиваются позднее, чем те, которые развиваются в более-менее спокойных условиях.
— Нужно провести эксперимент! — улыбнулся мистер Томпкинс. — Сравнить два совершенно одинаковых проекта, только перед одним поставить малореальные сроки, а перед вторым — вполне выполнимые.
— И второй обязательно победил бы! Я уверена.
О персонале
1. Если в самом начале проект делает большая команда, это снижает эффективность самой ответственной части работы — определения архитектуры системы (потому что всем разработчиком надо скорее дать какую-то работу).
2. Если работу раздать людям и командам еще до того, как завершится стадия дизайна продукта, не получится создать простые и эффективные модели взаимодействия между людьми и рабочими группами.
3. Это приведет к потере независимости, увеличению числа собраний и совещаний, общему недовольству.
4. В идеале было бы хорошо сначала набрать маленькую команду, которая создала бы продуманную архитектуру системы, а уже потом, на последнюю, шестую часть времени разработки в эту команду можно было бы добавить новый персонал (который работал бы непосредственно над кодированием).
5. Ужасное предположение: кажется, те команды, перед которыми не ставят жестких сроков, заканчивают работу быстрее!
Глава 20
Необходимые церемонии