Том ДеМарко - Deadline. Роман об управлении проектами
Мистер Томпкинс сел за стол и стал рассматривать таблицу, прихлебывая кофе.
— Пожалуйста, скажи еще раз, что значит единица?
— Как правило, это означает, что команда произвела на свет некий политический документ и назвала это «дизайном системы». На самом деле такие тексты не содержат в себе ничего, кроме первоначальных соображений о том, какой в принципе может быть архитектура приложения.
— То есть, по твоей терминологии, это вообще не дизайн.
— Да. Разумеется, потом, в процессе написания кода, дизайн обязательно появится. Но суть в том, что за время, отведенное на продумывание архитектуры, команда не сделала ничего. За это они и получили единицу.
— Хм. А маленькие команды получили пятерки и четверки. В то время как среди больших нашлась только одна, которая получила не единицу, а хотя бы тройку. Отчего же так?
— А вот попробуй догадайся. Эту загадку я специально припас для тебя.
— Прежде всего, если я правильно помню, наша концепция написания кода в последний момент невозможна без отлично проработанного дизайна.
— Очень хорошо. Продолжай!
— И все равно я не понимаю, почему команды А дружно провалили эту фазу. Ведь они не смогут проделать всю работу, которая необходима для того, чтобы перейти к написанию кода.
— Именно. А если еще точнее, то они и не собираются работать по методу кодирования в последнюю минуту. Все шесть команд А уже давным-давно пишут код. Я пытался было убедить их отложить кодирование на последний момент, но у меня ничего не получилось.
— А остальные?
— В разной степени. Впрочем, так или иначе, все они пытаются применить этот подход. Все решили отложить код на последний момент, а до этого постараться как можно точнее описать все внутреннее устройство системы. Некоторые даже отвели на кодирование всего шестую часть времени разработки.
— Но ни одна команда А так поступать не стала?
— Ни одна.
— Ладно. Я сдаюсь. В чем же дело?
Кенорос плюхнулся на стул около мистера Томпкинса. Он широко улыбнулся, но ничего не ответил. Мистер Томпкинс попробовал еще раз:
— Так почему же команды А не захотели заниматься детальной проработкой дизайна?
— Они слишком большие.
— Кто? Что?
— У меня есть теория. Эти команды слишком большие. Когда приходит время заниматься дизайном, команда оказываеся слишком большой. Продумывать архитектуру системы хорошо вдвоем, втроем. Ну, в крайнем случае, можно поручить это четверым или пятерым. Пять человек могут собраться вокруг доски для записей и вместе придумать хорошее решение. Но двадцать человек вокруг доски для записей уже не соберешь.
— И все равно я не понимаю, почему это должно мешать работе. Четверо или пятеро занимаются дизайном, а остальные сосредотачиваются на чем-нибудь другом. Почему бы и нет?
— На чем же еще им сосредоточиться?
— Ну не знаю. На чем-нибудь другом.
— Определение архитектуры приложения — это, по сути, деление целого на части, очень важный этап в разработке программы. Как только вы его прошли, части можно раздавать для выполнения различным людям или командам. Пока вы этого не сделали, у вас нет никаких частей и раздавать вам нечего. Следовательно, вся команда должна работать вместе.
— И все равно это не извиняет отсутствие продуманной архитектуры. Если это должно быть сделано, значит, нужно поручить эту работу четверым или пятерым, а остальные пусть потерпят и подождут. Пусть сидят и ничего не делают, в конце концов, если другого не остается.
— Конечно. Я полагаю, что что-то подобное произошло в команде Quicker Still — А. Но посмотри на свое «решение проблемы» глазами руководителя проекта. Допустим, тебе доверили управлять большим и сложным проектом. С первого дня у тебя работают тридцать программистов. Много? Конечно, но ведь у вас такой напряженный график! А теперь представь, что тебе надо сказать двадцати пяти программистам из тридцати, чтобы они сидели два месяца и ничегошеньки не делали. Легко, не правда ли?
— Понятно. И программисты устраивают своему менеджеру суд Линча.
— Непременно. К тому же представь, как ты будешь смотреть в глаза начальству. Тебе надо закончить проект к 1 июня. А что делают почти все твои программисты? Правильно — мух на потолке считают. Так как бы ты поступил?
— Если честно… если честно, я попробовал бы следующее: раз мне надо занять мою команду какой-то полезной работой, я бы просто постарался как можно раньше выделить какие-то части и раздать их разработчикам.
— Вот-вот, а поскольку вся работа по определению архитектуры состоит как раз в выделении отдельных частей из целого — но прошу заметить, наиболее разумным и эффективным образом, — то вся твоя деятельность сведется к попытке ускорить этот процесс. Верно?
— Понял. Это будет уже не дизайн, а ерунда какая-то. Но разве у меня обязательно все получится так плохо?
— Не обязательно. Но в большинстве случаев почему-то получается как раз так. Действительно, почти во всех проектах есть некоторые задачи, которые можно выделить с самого начала. Однако если у тебя здоровенная команда, то этих задач надолго не хватит.
— Но ведь чтобы дать команде действительно важные и нужные задачи, я могу поделить на части саму работу по дизайну системы!
— А вот тогда ты встанешь на скользкую дорожку, которая сведет на нет все усилия по разработке архитектуры приложения, — заметил Кенорос. — Тебе придется разбить всю работу на пять или даже десять частей, чтобы распределить ее между всеми своими сотрудниками. Но такое грубое деление должно само по себе стать частью дизайна системы. А ты подходишь к задаче не как архитектор, а как менеджер по персоналу, которому надо занять людей работой.
— Но ты говоришь, что даже грубо приблизительное деление проекта на части — уже дизайн.
— Так и есть. И поскольку никто не берет на себя ответственность за сведение воедино всех кусочков дизайна, в результате получится сущая ерунда. К тому же эффективнее всего использовать людей для написания кода и тестирования, поэтому с первых дней проекта у руководителей возникает непреодолимое желание засадить всех за код, даже несмотря на то, что архитектура системы еще до конца не определена.
Но мистера Томпкинса было не так-то просто переубедить:
— Если все так, как ты говоришь, то в большинстве случаев ни одна команда не сможет создать хорошо продуманную архитектуру просто потому, что в большинстве проектов даже на начальной стадии работает больше пяти человек.
— Боюсь, это суровая правда жизни, — ядовито усмехнулся Кенорос. — Сейчас даже в самом начале над проектами работает куда больше людей, чем требуется. Команда проходит все этапы разработки, предусмотренные процессом, вот только дизайна системы в результате не получается. Внутренняя структура развивается вместе с продуктом, и ни у кого нет ни времени, ни возможности хотя бы окинуть ее взглядом и подправить. Проходит несколько лет, систему надо менять. И вот наконец появляется человек, в обязанности которого входит изменение дизайна старой системы. И тут происходит самое печальное.
— Самое печальное? Что же это?
— А то, что этот человек, который появится в проекте через несколько лет, будет первым, кто увидит и оценит настоящую архитектуру системы.
Весь день мистер Томпкинс обдумывал то, о чем они говорили с Аристотелем. Если Кенорос прав, то последствия слишком раннего роста команд разработчиков можно заметить не только у них в Айдриволи, но и во всей отрасли, по всему миру. В большинстве случаев вместо самой ответственной части работы получался пшик: никому не нужный документ вместо подробного и продуманного плана разработки.
После обеда пришла Белинда, и мистер Томпкинс тут же подробно изложил ей всю идею. Вопреки его ожиданиям, она ничуть не удивилась.
— Не вижу ничего нового и из ряда вон выходящего. Управление — это всегда поиск компромиссов. Дизайн — тоже некий компромисс. Тебе нужно занять команду работой, поэтому ты соглашаешься на не самый лучший дизайн.
— Одно дело, когда речь идет о «не самом лучшем». Другое — когда дизайна нет вообще.
— Вебстер, какой-то дизайн есть всегда. Просто он не так хорош, как тебе бы хотелось. Даже если все время, отведенное на дизайн, потрачено впустую, все равно у системы будет внутренняя архитектура. Иначе этот твой будущий специалист, который придет в проект через несколько лет, не сможет ничего в ней поменять.
— Ну, пусть так. Я согласен, какой-то дизайн есть всегда. Мы говорим сейчас не об этом, а о том, что качество «стихийного» дизайна куда хуже, чем у продуманного заранее.
Белинда расчистила себе часть доски для записей.
— Вот, смотри, — и начала быстро водить по ней фломастером. — Вот это вся система, а это — ее части.
— Здесь изображен только один способ, как можно поделить целое на части. На самом деле таких способов очень много. Вот еще один, — и она быстро пририсовала вторую картинку рядом с первой. — Чтобы понять, какой из способов лучше и правильнее, мы должны оценить возникшие в результате деления взаимодействия. Если их много и они сложные, то деление было сделано не лучшим образом.
