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

Но мистера Томпкинса было не так-то просто переубедить:

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

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

— Самое печальное? Что же это?

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

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

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

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

— Одно дело, когда речь идет о «не самом лучшем». Другое — когда дизайна нет вообще.

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

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

Белинда расчистила себе часть доски для записей.

— Вот, смотри, — и начала быстро водить по ней фломастером. — Вот это вся система, а это — ее части.

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

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

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

— Мы должны выбрать рисунок справа, — произнес мистер Томпкинс голосом прилежного ученика.

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

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

Остановившись на полуслове, Белинда вдруг замолчала и села в кресло.

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