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

ОглавлениеДобавить в закладки К обложке

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

— Понятно. И программисты устраивают своему менеджеру суд Линча.

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

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

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

— Понял. Это будет уже не дизайн, а ерунда какая-то. Но разве у меня обязательно все получится так плохо?

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

— Но ведь чтобы дать команде действительно важные и нужные задачи, я могу поделить на части саму работу по дизайну системы!

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

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

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

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

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

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

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

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

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

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

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


-= 96 =-
Регистрация.
Забыли пароль?
Логин
Пароль
Запомнить меня