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

Демарко Том

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

Мистер Томпкинс откинул голову на подушку сиденья и уставился в серую ткань потолка. Так в чем же он абсолютно уверен сейчас? Где находится «мертвая зона», которая не дает ему увидеть истинное положение вещей? У него было ощущение, что он не замечает чего-то главного, чего-то, что коренным образом могло бы изменить работу над проектами в Айдриволи. Если бы он только догадался! Среди всех его знаний и

наработок было что-то неправильное. Что-то, что мешало ему найти правильный подход к проектам. Мистер Томпкинс прикрыл глаза и сосредоточился. Какие же у него есть непререкаемые убеждения? Он попытался перебрать их по одному, заставляя себя сомневаться в каждом из них. Вдруг он вспомнил слова Аристотеля Кенороса: «Думай не о том, чтобы добавить, а о том, чтобы убавить…» Что же можно выкинуть из процесса разработки проекта, чтобы работа стала более эффективной? Да где же это «неправильное знание», эта уверенность, которая мешает ему увидеть все в нужном свете?

Мистер Томпкинс очнулся и поглядел вокруг. Он остановился здесь случайно, но место оказалось просто чудесным. С одной стороны дороги тянулся невысокий горный кряж. За ним простиралась по-осеннему яркая долина. В долине текла речушка, вдоль которой шла узкоколейка. Дальше речушка образовывала блестевшее на солнце озерцо. Отличное место для пикника. Мистер Томпкинс вытащил из машины корзинку с ленчем, одеяло и зашагал вниз по склону, в долину.

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

Перед тем, как снова двинуться в путь, мистер Томпкинс вытащил свою записную книжку и быстро записал всего пару фраз.

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

Человеку свойственно ошибаться

1. Нам кажется, что самое страшное — не знать чего-то. На самом деле гораздо хуже быть уверенным, что знаешь, когда на самом деле это не так.

Глава 19

Часть и целое

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

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

Мистер Томпкинс сел за стол и стал рассматривать таблицу, прихлебывая кофе.

— Пожалуйста, скажи еще раз, что значит единица?

— Как правило, это означает, что команда произвела на свет некий политический документ и назвала это «дизайном системы». На самом деле такие тексты не содержат в себе ничего, кроме первоначальных соображений о том,

какой в принципе может быть архитектура приложения.

— То есть, по твоей терминологии, это вообще не дизайн.

— Да. Разумеется, потом, в процессе написания кода, дизайн обязательно появится. Но суть в том, что за время, отведенное на продумывание архитектуры, команда не сделала ничего. За это они и получили единицу.

— Хм. А маленькие команды получили пятерки и четверки. В то время как среди больших нашлась только одна, которая получила не единицу, а хотя бы тройку. Отчего же так?

— А вот попробуй догадайся. Эту загадку я специально припас для тебя.

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

— Очень хорошо. Продолжай!

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

— Именно. А если еще точнее, то они и не собираются работать по методу кодирования в последнюю минуту. Все шесть команд А уже давным-давно пишут код. Я пытался было убедить их отложить кодирование на последний момент, но у меня ничего не получилось.

— А остальные?

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

— Но ни одна команда А так поступать не стала?

— Ни одна.

— Ладно. Я сдаюсь. В чем же дело?

Кенорос плюхнулся на стул около мистера Томпкинса. Он широко улыбнулся, но ничего не ответил. Мистер Томпкинс попробовал еще раз:

— Так почему же команды А не захотели заниматься детальной проработкой дизайна?

— Они слишком большие.

— Кто? Что?

— У меня есть теория. Эти команды слишком большие. Когда приходит время заниматься дизайном, команда оказываеся слишком большой. Продумывать архитектуру системы хорошо вдвоем, втроем. Ну, в крайнем случае, можно поручить это четверым или пятерым. Пять человек могут собраться вокруг доски для записей и вместе придумать хорошее решение. Но двадцать человек вокруг доски для записей уже не соберешь.

— И все равно я не понимаю, почему это должно мешать работе. Четверо или пятеро занимаются дизайном, а остальные сосредотачиваются на чем-нибудь другом. Почему бы и нет?

— На чем же еще им сосредоточиться?

— Ну не знаю. На чем-нибудь другом.

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

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

— Конечно. Я полагаю, что что-то подобное произошло в команде Quicker Still — А. Но посмотри на свое «решение проблемы» глазами руководителя проекта. Допустим, тебе доверили управлять большим и сложным проектом. С первого дня у тебя работают тридцать программистов. Много? Конечно, но ведь у вас такой напряженный график! А теперь представь, что тебе надо сказать двадцати пяти программистам из тридцати, чтобы они сидели два месяца и ничегошеньки не делали. Легко, не правда ли?