Глава 13
QuickerStill
С самого начала ВВН постановил, что продукт — аналог Quicken — будет называться QuickerStill. Название разработчикам понравилось. Естественно, все понимали, что такое имя надо оправдать, поэтому требования к производительности программы изначально были очень высокими. Мистер Томпкинс не имел ничего против такого развития событий. Ему тоже понравилось имя нового продукта. Более того, ему нравилась идея делать проекты «еще быстрее», может быть, даже быстрее, чем в идиотские сроки, установленные непреклонным министром Бэллоком. Сейчас Вебстер Томпкинс уныло обернулся, чтобы посмотреть на счетчик, висевший у него за спиной:
Осталось всего 345 дней до «дня Д»!
До 1 июня — немногим меньше года. Все шесть проектов за такой срок не сделать, это было абсолютно ясно. Сейчас они уже знали, что средняя производительность в Айдриволи за последние пять лет варьировалась в пределах пяти функциональных единиц на человеко-месяц. Причем все это подсчитывалось на «домашних» проектах. А как изменится производительность при работе над продуктами высочайшего качества, которым придется конкурировать на мировом рынке? Наверняка не больше трех единиц. А это означает, что на разработку проекта размером с PShop понадобится не менее трех лет. Учитывая, что начали они зимой, сейчас им еще предстоит около шестисот дней работы. Да, у больших проектов нет ни единого шанса уложиться в установленные Бэллоком сроки.
Мистер Томпкинс не надеялся успеть сдать большие проекты — PShop, Paint-It и Quirk, но у него все еще теплилась надежда завершить в срок хоть какой-то из мелких проектов, объемом с QuickerStill. Даже это было маловероятно, но все же он хотел принять вызов и бороться. И если бы у него получилось, то он мог бы считать, что его миссия в Моровии окончилась успешно.
Эта тайная надежда грела ему душу. Да, он сможет добиться успеха, невзирая на идиотизм ситуации и зловредность Бэллока! Чем больше он об этом думал, тем оптимистичнее смотрел в будущее. В конце концов, худшее уже позади. Что еще может придумать Бэллок после своей эскапады со сроками?
Миссис Бирцих, заботливая и толковая ассистентка, которую ему подыскали на место Вальдо, вбежала в его кабинет в явном расстройстве, если не сказать — в отчаянии.
— Босс, босс! Скорее идите, посмотрите на это! К вам делегация от Моровийского Института программирования. Они утверждают, что пришли проверять работу наших проектов!
— Мы следуем прямым указаниям министра Бэллока, — пояснил мистеру Томпкинсу руководитель группы проверки — Он только что распорядился, чтобы все команды разработчиков предоставили свидетельства улучшения процесса разработки. Все без исключения. Сейчас они сертифицированы как СММ второго уровня. Министр настаивает, чтобы все прошли сертификацию следующего уровня еще до конца года. Это его категорическое требование. Уж не знаю, насколько это реально, но он говорит, что мы должны успеть
— Вот это меня, честно говоря, не очень беспокоит, — отрезал Томпкинс. — Меня больше беспокоит, сколько мои люди потеряют времени из-за этой вашей программы по улучшению процесса разработки. Перед нами поставлены очень жесткие сроки — на случай, если мистер Бэллок забыл сообщить вам об этом.
— О, об этом можете не беспокоиться, — уверенно заявил руководитель группы проверки — Улучшение процесса разработки немедленно скажется на производительности ваших сотрудников. Мы это знаем на примере американцев. Даже один-единственный уровень СММ даст вам не меньше двадцати четырех процентного увеличения производительности.
— Во-первых, я сильно в этом сомневаюсь. Во-вторых, даже если это так, то все равно это самое двадцатичетырехпроцентное увеличение производительности случится уже тогда, когда мы должны будем закончить работу над проектами.
Мистер Томпкинс говорил это, а про себя думал о том, что ему сказал Гектор Риццоли: «Нет на свете ничего, что могло бы быстро поднять производительность».
— Мы все знаем, что работа над процессом дает положительный эффект только через весьма и весьма продолжительное время. Следовательно, сейчас мы его просто потеряем.
Гость только пожал плечами: «Да, но через какое-то время окажется…»
— Разумеется, разумеется. Возможно, это будет через год после того, как мы закончим проекты. Через год мои люди начнут работать немного лучше благодаря тому, чему вы их сейчас обучите. Кстати, как долго будет длиться ваша программа?
— Думаю, около десяти месяцев. Обучение не займет у ваших сотрудников больше, чем один день… или даже половину дня раз в неделю.
Мистер Томпкинс застонал. Эту ситуацию можно было не моделировать, и без того ясно, что произойдет с графиком работы.
— А каковы ваши планы? Вы собираетесь работать только над этими шестью проектами, или же вы должны поднять уровень СММ во всей организации?
— Во всей организации. Именно этого требует министр Бэллок.
— Понятно.
— Мне очень жаль, мистер Томпкинс. Я понимаю, наше появление вас не обрадовало, но постарайтесь думать о том, какие выгоды вы получите в будущем…
Мистер Томпкинс только головой покачал.
— Ну, может быть, хоть это вас немного утешит: честно говоря, мы еще не готовы начинать обучение ваших сотрудников. Я думаю, на подготовку программы уйдет не менее шести недель.
— А что вы собираетесь делать здесь сегодня? К чему тогда столько людей?
— Мы всего лишь группа проверки. Сейчас мы должны удостовериться, что все ваши проекты остались на втором уровне СММ. Поэтому мы должны всех обойти и проверить, какому процессу они следуют при разработке.
— Понятно.
— Как видите, наша группа довольно большая, и тем не менее нам потребуется не меньше целого дня работы, чтобы провести проверку тех, кто работает в этом здании, в Айдриволи-1. На проверку остальных уйдет остаток этой недели и, пожалуй, вся следующая.
В конце дня руководитель группы проверки и несколько его помощников собрались в кабинете мистера Томпкинса. С собой они привели застенчивого менеджера проекта QuickerStill, Бигсби Гроша. Тут же в кабинете сидел и генерал Марков.
Руководитель группы проверки огласил вердикт:
— Вот и все на сегодня, мистер Томпкинс. В целом, конечно, все довольно неплохо, за исключением разве что мистера Гроша и его группы разработчиков. По сути, они — единственное досадное отклонение от принятого процесса разработки.
— Уверен, у него были на то веские причины, — начал было мистер Томпкинс.
— Ну, знаете ли, любой может найти веские причины, чтобы не следовать установленной процедуре разработки. Когда наш институт сертифицировал эту группу разработчиков, как СММ второго уровня, мы особо подчеркивали тот факт, что процесс — некоторая последовательность шагов разработки — не должен изменяться. Что бы кто бы ни разрабатывал — процесс остается неизменным. В этом и состоит суть второго уровня СММ. Главное в нем — неизменность. Неважно, хорош ваш процесс или плох, идеален или отвратителен, главное — что вы, по крайней мере, ничего в нем не меняете. И большинство всех работающих в Айдриволи-1 разработчиков поступают именно так! Мы проинспектировали шесть проектов — все находятся на стадии написания требований, причем пять именно этим и занимаются: фиксируют требования и составляют документацию, как того требует принятый здесь процесс. И никакой самодеятельности. Все, кроме мистера Гроша с его проектом. Мистер Грош вообще решил отказаться от любых правил! Его группа даже и не думала заниматься требованиями — вместо этого они сразу приступили к проектированию! — голос инспектора дрожал от возмущения.
— Я уверен, у него были на то причины, — повторил мистер Томпкинс.
— Конечно, — отозвался Грош. — Все очень просто. Наш проект не похож ни на один из тех, которые мы делали до сих пор. Сейчас нам надо практически создать аналог известного на рынке, хорошо документированного и описанного продукта — Quicken. У нас уже есть вся документация. Нам не нужно описывать требования, потому что это простое копирование…
— Не нужно писать требования! — взвизгнул руководитель группы проверки. — Никогда в жизни мне не доводилось видеть проект, для которого не нужно писать требований. Никогда! Каждый проект должен быть тщательно документирован. Если вы были сертифицированы на СММ второго уровня, вы обязаны описывать требования, используя известные и утвержденные методики. Только так и никак иначе.
— Но наш проект абсолютно другой! — завопил Грош.
— Все проекты другие, — неумолимо парировал руководитель группы проверки. — Каждый проект другой, потому что отличается от прочих. И тем не менее процесс разработки должен оставаться неизменным.
— А если проект отличается настолько, что использование данного процесса становится нецелесообразным? — вмешался в разговор мистер Томпкинс.
— Процессу нужно следовать в любом случае, — ответил инспектор. — Только так и никак иначе. Если мы начнем делать исключения для тех проектов, которые отличаются от других, то каждый начнет делать, что ему на ум взбредет, а о слаженном и постоянном процессе можно будет вообще забыть.
— Значит, нужно одинаково подходить ко всем проектам?
— Совершенно верно, — подтвердил инспектор. — А если этого не делать, то ни о какой сертификации на второй уровень СММ и речи быть не может. И это не только мое мнение. Это мнение всего нашего института.
— …сертификация на второй уровень СММ… — задумчиво произнес мистер Томпкинс. — Ну что ж, может быть, это и есть ответ. Не надо сертифицировать проект QuickerSlill на второй уровень СММ, вот и все.
— Боюсь, вы нашли неверное решение, мистер Томпкинс. Институт программирования едва ли допустит такое. Я хочу сказать, достаточно позволить этому произойти хотя бы единожды…
— А что, если нам не предавать наше соглашение огласке? Пусть это останется только между нами…
— Думаю, это невозможно, — твердо возразил неприступный инспектор. — И не думаю, что такой поворот событий порадует министра Бэллока. Он требует, чтобы вся организация перешла на следующий уровень СММ еще до конца года, а тут вдруг окажется, что один из центральных проектов вместо этого вдруг откатывается на один уровень назад. Нет, сэр. Я собираюсь написать сегодня представление лично мистеру Грошу и его группе. Мы дадим им семь дней на то, чтобы они исправились и написали все необходимые спецификации по стандартной форме…
— Скопировали требования из одной формы в другую! — горько воскликнул Грош.
— …по стандартной форме, как я уже говорил. По форме, которая соответствует процессу СММ второго уровня. Если же через семь дней они не представят комиссии необходимую документацию, сертификация всей группы будет официально и публично аннулирована. Я достаточно ясно все объяснил? — в голосе инспектора звучала угроза.
— О, да, — ответил мистер Томпкинс. — Вы объяснили все предельно ясно. Но эта проектная группа — всего лишь крохотная часть всей организации. Если я правильно вас понял, то завтра вы продолжите работу в других зданиях?
— Да. Судя по сегодняшним темпам, у нас будет уходить по одному дню на каждое здание, не меньше.
— Не окажете ли мне услугу, начав завтра проверку Айдриволи-2? А потом, послезавтра, Айдриволи-3 и так далее, по порядку? Тогда через неделю вы сможете закончить всю процедуру на Айдриволи-7, — говорил мистер Томпкинс, а сам думал, что это даст ему по крайней мере несколько дней отсрочки. — Вы не могли бы проводить проверку именно в такой последовательности?
— Конечно, мистер Томпкинс. Мы же здесь, чтобы помочь вам. Итак, завтра мы займемся Айдриволи-2. Я так понимаю, что у вас там сосредоточены особо важные проекты, раз вы просите проинспектировать их в первую очередь.
— Э… о… да, вы абсолютно правы. И в Айдриволи-3, и в Айдриволи-4. Там тоже идет очень важная разработка. Мы особо заинтересованы в вашей оценке этих трех групп. Айдриволи-5 и Айдриволи-6 уже далеко не так важны. Было бы замечательно, если бы вы сначала проверили самые важные проекты.
— Разумеется. Я вас прекрасно понимаю. Мы сделаем все возможное, чтобы помочь вам. Можете положиться на нас, мистер Томпкинс.
— Спасибо. Я не сомневался.
Вскоре все, кроме Габриела Маркова, покинули кабинет.
— Кажется, мы отстаем даже больше, чем предполагали, — мрачно заметил он.
— Ну, конечно же, какое-то время сожрет это «улучшение процесса разработки».
— Да нет же, все еще хуже.
— Да почему же?
— Ну это же должно быть так естественно для руководителя — сэкономить время на написание документации в то время, как по каждому проекту есть прекрасная документация от конкурирующего коммерческого продукта! И тем не менее догадался об этом только Грош. Все остальные пошли по проторенной дорожке и стали писать спецификацию требований, как они всегда делали до этого. Никто больше не подумал о том, что эти шесть проектов кардинальным образом отличаются от всех, которые они делали раньше.
Мистер Томпкинс вскочил на ноги.
— Теперь я понимаю, о чем ты. Сдается мне, нам пора прогуляться по Айдриволи-7 и самим поинспектировать команды Б и В. Интересно, сколько из них догадалось сэкономить время на требованиях?
— Руководства пользователя и есть спецификация требований, — сказала им Молли Макмора. — Конечно же, мы не стали их копировать в стандартную форму. Это означало бы впустую тратить время.
— Точно, — согласился с ней Элем Картак. Все остальные руководители команд Б и В согласно закивали головами.
И тут подняла руку Аврил Альтербек, руководитель команды В, которая разрабатывала PShop:
— Руководства пользователей по Photoshop, которые выпустила Adobe, настолько полные и всеобъемлющие, я никогда не встречала лучшего описания требований к программе. Никогда раньше мне и в голову не приходило, что руководство пользователя можно рассматривать в таком качестве. Но теперь все по-другому. Более того, я думаю, почему бы нам вообще не писать руководство пользователя или хотя бы его основу в самом начале проекта? Тогда бы сначала оно выполняло роль спецификации, а потом постепенно превратилось в настоящее руководство пользователя. Я знаю, что все остальные со мной согласятся, потому что мы уже обсуждали свои мысли по этому поводу, — она обвела взглядом собравшихся. Те дружно кивнули.
— Однако даже при том, что руководство пользователя является замечательным описанием функциональности продукта, мы не должны отказываться от работы по написанию требований, — продолжала Аврил. — Существуют ведь требования, не относящиеся к функциональности программы, например, время отклика, объем файлов, диапазон чисел, точность переменных и допустимые расширения…
— Каждый из нас описал все эти нефункциональные требования отдельным документом, — вставил Картак. — Теперь, кроме руководств пользователя, у нас есть полный набор спецификаций. В них есть все требования к системе — и функциональные, и нефункциональные. При этом все прекрасно изложено ясным, доступным языком, со множеством примеров и иллюстраций. Мне кажется, ничего лучше и быть не может!
Мистер Томпкинс перевел дух. Благодаря столь нестандартному подходу к описанию требований они экономили довольно времени. А это значит, что все команды Б и В, почти не затратив времени на документирование требований, сейчас уже вовсю занимались проектированием своих продуктов. И разумеется, это значит, что группа инспекторов аннулирует СММ-сертификацию всех команд, как только доберется до Айдриволи-7. Но это его проблема, а не руководителей команд Б и В.
«Подходящий момент для того, чтобы похвалить ребят за то, что они сделали», — подумал мистер Томпкинс.
— Я рад видеть, что вы проявили нестандартный подход к работе, — сказал он собравшимся. — Мы должны использовать каждую разумную возможность сократить время разработки. И вам это удается. Это доказывает, что вы можете анализировать ситуацию и принимать правильные меры, а это все, чего я от вас хочу. Одно меня удивляет — почему руководители команд А не догадались поступить с требованиями таким же образом?
Сначала все молчали, потом раздался голос Аврил:
— Кажется, я знаю, почему.
— Так объясните мне, пожалуйста.
— А вы попробуйте представить себя в шкуре Томаса Орика, руководителя команды А, которая тоже делает PShop. У него в команде шестьдесят человек, к тому же поговаривают, что за проектом присматривает сам министр внутренних дел, потому что хочет, чтобы PShop был закончен вовремя.
— И что?
— А то, что Томас просто обязан сделать так, чтобы все были завалены работой. Более того, он даже должен применять метод кнута и заставлять свою команду работать сверхурочно. Если он этого не сделает, то его сочтут плохим руководителем, который не понимает ситуации и не принимает должных мер. И что ему, спрашивается, делать?
Мистер Томпкинс задумался. Плохи дела, в самом деле. Конечно, надо бы поговорить с Томасом, но все же Аврил пыталась донести до него другую мысль. Да, переводить спецификации из одной формы в другую было совершенно бесполезным занятием, но зато оно давало Томасу возможность загрузить работой всю свою огромную команду. И — что, возможно, еще важнее — это давало команде возможность выглядеть занятой.
Получается, что они преднамеренно выбрали наименее эффективный путь, просто чтобы у всей команды было достаточно работы.
Было еще рано, но мистер Томпкинс решил пойти домой. Его охватило уныние. По обочинам тропинки росли причудливые тропические цветы и деревья, за которыми скрывалось здание Института программирования, но сейчас даже цветы не радовали взгляд. Единственным его достижением за сегодняшний день была отсрочка, которую получили команды, работающие в здании Айдриволи-7. До них доберутся только через неделю, так что у него еще есть время, чтобы что-то сделать. Но что?
Из дневника мистера Томпкинса
Процесс разработки и его улучшение
1. Хороший процесс разработки и его постоянное улучшение — весьма достойные цели.
2. Но существуют еще и рабочие цели и задачи: хороший работник сконцентрирует внимание как раз на них, даже если вы его об этом не просили.
3. Формальные программы, направленные на улучшение существующего процессе разработки, будут дорого стоить команде — и во временном, и в денежном отношении. Даже отдельные усилия по улучшению процесса могут отбросить команду далеко назад. Что касается возможного повышения производительности, то даже если это и произойдет, то едва ли выгоды от этого повышения покроют затраты.
4. Можно надеяться получить положительный результат от одного какого-нибудь хорошо взвешенного и тщательно выбранного усовершенствования в методике работы. В этом случае оно может покрыть деньги и время, потребовавшиеся на его внедрение.
5. Попытка внедрить более одного усовершенствования методологии — гиблое дело. Программы, направленные на улучшение многих приемов и навыков (например, переход на следующий уровень СММ), скорее всего приведут к тому, что сроки только увеличатся.
6. Опасность стандартизированного процесса разработки состоит в том, что за рутинными операциями люди могут не заметить возможность сэкономить время и усилия по разработке проекта.
7. Что касается чрезмерно больших команд, то там стандартизированный процесс будет неукоснительно соблюдаться до тех пор, пока он позволяет всем чувствовать себя при деле (не важно, с пользой для проекта или нет).
