Читаем Deadline полностью

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

Мистер Томпкинс вскочил на ноги.

— Теперь я понимаю, о чем ты. Сдается мне, нам пора прогуляться по Айдриволи-7 и самим поинспектировать команды Б и В. Интересно, сколько из них догадалось сэкономить время на требованиях?

— Руководства пользователя и есть спецификация требований, — сказала им Молли Макмора. — Конечно же, мы не стали их копировать в стандартную форму. Это означало бы впустую тратить время.

— Точно, — согласился с ней Элем Картак. Все остальные руководители команд Б и В согласно закивали головами.

И тут подняла руку Аврил Альтербек, руководитель команды В, которая разрабатывала PShop:

— Руководства пользователей по Photoshop, которые выпустила Adobe, настолько полные и всеобъемлющие, я никогда не встречала лучшего описания требований к программе. Никогда раньше мне и в голову не приходило, что руководство пользователя можно рассматривать в таком качестве. Но теперь все по-другому. Более того, я думаю, почему бы нам вообще не писать руководство пользователя или хотя бы его основу в самом начале проекта? Тогда бы сначала оно выполняло роль спецификации, а потом постепенно превратилось в настоящее руководство пользователя. Я знаю, что все остальные со мной согласятся, потому что мы уже обсуждали свои мысли по этому поводу, — она обвела взглядом собравшихся. Те дружно кивнули.

— Однако даже при том, что руководство пользователя является замечательным описанием функциональности продукта, мы не должны отказываться от работы по написанию требований, — продолжала Аврил. — Существуют ведь требования, не относящиеся к функциональности программы, например, время отклика, объем файлов, диапазон чисел, точность переменных и допустимые расширения…

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

Мистер Томпкинс перевел дух. Благодаря столь нестандартному подходу к описанию требований они экономили довольно времени. А это значит, что все команды Б и В, почти не затратив времени на документирование требований, сейчас уже вовсю занимались проектированием своих продуктов. И разумеется, это значит, что группа инспекторов аннулирует СММ-сертификацию всех команд, как только доберется до Айдриволи-7. Но это его проблема, а не руководителей команд Б и В.

«Подходящий момент для того, чтобы похвалить ребят за то, что они сделали», — подумал мистер Томпкинс.

— Я рад видеть, что вы проявили нестандартный подход к работе, — сказал он собравшимся. — Мы должны использовать каждую разумную возможность сократить время разработки. И вам это удается. Это доказывает, что вы можете анализировать ситуацию и принимать правильные меры, а это все, чего я от вас хочу. Одно меня удивляет — почему руководители команд А не догадались поступить с требованиями таким же образом?

Сначала все молчали, потом раздался голос Аврил:

— Кажется, я знаю, почему.

— Так объясните мне, пожалуйста.

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

— И что?

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

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

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

Перейти на страницу:

Похожие книги

100 абсолютных законов успеха в бизнесе
100 абсолютных законов успеха в бизнесе

Почему одни люди преуспевают в бизнесе больше других? Почему одни предприятия процветают, в то время как другие терпят крах? Известный лектор и писатель по вопросам бизнеса нашел ответы на эти очень трудные вопросы. В своей книге он представляет набор принципов, или `универсальных законов`, которые лежат в основе успеха деловых людей всего мира. Практические рекомендации Трейси имеют вид 100 доступных для понимания и простых в применении законов, относящихся к важнейшим сферам труда и бизнеса. Он также приводит примеры из реальной жизни, которые наглядно иллюстрируют, как работает каждый из законов, а также предлагает читателю упражнения по применению этих законов в работе и жизни.

Брайан Трейси

Деловая литература / Маркетинг, PR, реклама / О бизнесе популярно / Финансы и бизнес