Читаем Как пасти котов полностью

Находясь под влиянием рыночной конъюнктуры, компании нередко устанавливают сроки сдачи продуктов, не советуясь с руководителями вашего уровня. Ситуации, когда утверждение бизнес-плана предшествует окончательной формулировке коммерческих требований, случаются сплошь и рядом. В главе 3 я уже говорил о различиях между реалистичными и нереалистичными планами проектов. Полагаю, соответствующие принципы следует воспроизвести и здесь. В идеале планирование должно осуществляться в такой последовательности:

1. Утверждение коммерческих требований.

2. Создание проектного решения, допускающего успешную реализацию в продукте всех требований.

3. Макетирование проектного решения с целью выявления его недостатков и последующей корректировки проектного решения или требований.

4. Планирование проекта с учетом сроков разработки и тестирования.

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

Как известно, мир, в котором мы живем, несовершенен; иначе вряд ли было бы столько разговоров о программистах, у которых под столами спальные мешки. У вас, таким образом, есть единственный выход – научиться выживать в реальных условиях[93]

. При чем тут честность, спросите вы? При том, что вы должны осознавать нереалистичность поставленных перед вами задач в свете реальных условий, примеры которых перечислены ниже:

• несмотря на то что коммерческие требования сформулированы еще не полностью, в погоне за соблюдением неизвестно кем установленной даты выпуска вы вынуждены приступать к проектированию немедленно;

• из-за неразберихи с требованиями вам приходится постоянно корректировать проектное решение;

• у вас не остается времени на макетирование, или, что еще хуже, недоработанный макет превращается в код;

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

В любом случае вопреки объективной реальности вы должны всеми силами стремиться к тому, чтобы закончить работу в срок. Юность нашей индустрии и давление рыночных факторов заставляет нас совершать героические поступки. Таким образом, честностью я называю способность признаться самому себе в трудности задачи, но все-таки попытаться ее решить. Вы со мной согласны? Если согласны, присылайте резюме на мой адрес – такие, как вы, мне необходимы.

Еще пара слов насчет геройства[94]. В начале карьеры идея стать героем воодушевляет, однако реализуют ее немногие. На самом деле стремиться нужно к балансу между ожиданиями и реальными действиями, исходя при этом из соображений честности. Иначе говоря, если вы пару раз сорвете сроки, никто не удивится. Это исправимые вещи. Значительно труднее справиться с привычкой давать невыполнимые обещания. Если вы уж обещаете что-то, не забывайте в полной мере доносить до сведения начальства все те факторы, которые могут воспрепятствовать реализации плана. Любые обязательства должны быть подтверждены в проекте с некоторой долей уверенности, которая варьируется в зависимости от ситуации. Восстановить репутацию значительно сложнее, чем исправить ошибки в выпущенном продукте.


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


Обратной стороной геройства является фатализм. Фаталист – это человек, который неудачно пытался стать героем, а потом в ситуации, которую он создал сам, начинал винить судьбу. Если вам приходится иметь дело с нереальным проектом, необходимо отдавать себе отчет в том, что фактически вы и ваша команда попадаете в условия, приближенные к боевым. Регулярная работа по ночам изматывает разработчиков, в результате страдает код. Не стоит вводить в проект новых программистов – если это случится на поздней стадии разработки, вы рискуете в очередной раз подтвердить закон Брукса[95]. Именно по этой причине на начальных этапах планирования проекта так важна честность (если, конечно, у вас есть план).

Честность зависит от тщеславия и чувства собственного достоинства. Я уже в том возрасте, когда каждое утро для удовлетворения тщеславия мне нужны лак для волос, зеркало и время. Признаться, я лысею, и это – горькая правда. Я могу пытаться это скрывать, но ведь все равно окружающие узнают![96] Аналогичным образом лучше высказать голую правду о сроках, чем сочинять сказки.

Как помочь начальнице удачно спланировать процесс

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

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

C# 4.0: полное руководство
C# 4.0: полное руководство

В этом полном руководстве по C# 4.0 - языку программирования, разработанному специально для среды .NET, - детально рассмотрены все основные средства языка: типы данных, операторы, управляющие операторы, классы, интерфейсы, методы, делегаты, индексаторы, события, указатели, обобщения, коллекции, основные библиотеки классов, средства многопоточного программирования и директивы препроцессора. Подробно описаны новые возможности C#, в том числе PLINQ, библиотека TPL, динамический тип данных, а также именованные и необязательные аргументы. Это справочное пособие снабжено массой полезных советов авторитетного автора и сотнями примеров программ с комментариями, благодаря которым они становятся понятными любому читателю независимо от уровня его подготовки. Книга рассчитана на широкий круг читателей, интересующихся программированием на C#.Введите сюда краткую аннотацию

Герберт Шилдт

Программирование, программы, базы данных
Разработка приложений в среде Linux. Второе издание
Разработка приложений в среде Linux. Второе издание

Книга известных профессионалов в области разработки коммерческих приложений в Linux представляет СЃРѕР±РѕР№ отличный справочник для широкого круга программистов в Linux, а также тех разработчиков на языке С, которые перешли в среду Linux из РґСЂСѓРіРёС… операционных систем. РџРѕРґСЂРѕР±но рассматриваются концепции, лежащие в основе процесса создания системных приложений, а также разнообразные доступные инструменты и библиотеки. Среди рассматриваемых в книге вопросов можно выделить анализ особенностей применения лицензий GNU, использование СЃРІРѕР±одно распространяемых компиляторов и библиотек, системное программирование для Linux, а также написание и отладка собственных переносимых библиотек. Р

Майкл К. Джонсон , Эрик В. Троан

Программирование, программы, базы данных