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