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