Скотт Беркун. Искусство управления IT проектами

Когда вышла книга «Искусство управления IT-проектами»  Скотта Беркуна, я случайно прочитал об этом событии где-то в новостях. Запомнил имя автора и попытался ее купить. Но ничего не вышло, ни в одном магазине Санкт-Петербурга ее не было, даже в «Доме книги»!  Правда, там они обещали ее заказать. В интернете мне тоже не удалось ее найти. Потом как-то забыл, но вот теперь случайно она попала ко мне в руки. Сейчас книгу Скота Беркуна «Искусство управления IT-проектами» можно найти и в интернете, т.к. она распространилась очень хорошо. Да и купить без проблем. И на то есть причины, книга интересная! Но читал я ее долго. Даже не знаю почему. Вроде и написано легко, но иногда утомляет погружение в основы общего менеджмента (хотя для многих эти погружения могут быть весьма полезными). Все-таки я осилил ее до конца, и могу рассказать о самых интересных частях.

Вообще, на протяжении книги у меня сложилось мнение, что автор немного обижен сам на себя за то, что не обладал теми знаниями и опытом, о которых рассказывает в книге, в тот период своей карьеры, когда ему это было особенно нужно: в период войны браузеров, еще в 90-х годах. Ведь мы-то помним, какая была конкуренция у IE и Netscape. Да, Скотт Беркун был руководителем проекта  по разработке Internet Explorer в тот нелегкий период. И мы также помним, что IE терял популярность так же быстро, как ее набирал Netscape. Однако, проект был действительно сложный, и у человека, который стоял у истоков такого проекта однозначно есть чему поучиться.

Как представил автора издатель книги, Скотт Беркун — это такой человек, который «ушел из microsoft и живет в лесах, где пишет книги».

Итак, теперь по существу. В самом начале описываются различные мысли по поводу управления проектами. Сам стиль изложения выбран так, что сделать краткий конспект, который потом можно будет использовать практически нереально. Скорее, это свод наблюдений и рекомендаций, полезных на практике. По моему мнению, если человек не имеет опыта управления IT-проектами вообще, понять практическую пользу описанного в книге ему сложнее. Я бы сказал, она предполагает наличие первоначального опыта.

 Вот так автор характеризует успешный проект:

 «Я полагаю, что лучшие проекты являются результатом правильно подобранной команды, правильного применения навыков, привычек и приемов работы ее членов независимо от того, откуда эти люди пришли и где получили свои знания»

О некоторых полезных качествах руководителя проекта:

  • Для самосовершенствования необходимо быть любопытным, открытым к восприятию новых знаний, а это требует постоянной практики. Чтобы иметь возможность постоянно постигать что-то новое, не следует направлять все свои мозговые усилия на узкие, специфические задачи.
  • Они должны быть готовы к передаче важных и просто интересных заданий тем, кто сможет выполнить их быстрее и качественнее. Принимая похвалы и благодарности, следует всегда относить их на счет всей команды. Эгоизм руководителя проектов может быть как движущей силой, так и помехой, и важно вовремя распознать, когда он начинает мешать работе.
  • Надо обладать определенной мудростью, чтобы правильно распознать, когда необходимо требовать совершенства, а когда можно обойтись быстрым и приблизительным решением
  • Многие становятся жертвами сложности. Когда человек сталкивается с трудной организационной или инженерной задачей, он теряется в деталях и забывает о том, что представляет собой задача в целом. Некоторые, впрочем, напротив, не хотят признавать сложность и выносят неверные решения лишь потому, что не понимают до конца всех тонкостей. Уравновешивающим действием в данном случае являются трезвый взгляд на сложность или простоту задачи в каждой конкретной ситуации, умение переключаться между двумя мнениями и постоянно держать их в голове. Руководители проектов должны добиваться от команды простоты и ясности в работе, не умаляя при этом сложности написания хорошего, надежного кода.
  • Нетерпимость или терпение. Большую часть времени руководитель проектов занят тем, что настаивает на выполнении заданий, принуждает сотрудников работать аккуратно и сосредоточенно. Но иногда нетерпимость оказывает негативное влияние на проект. Некоторые политические, организационные и бюрократические действия неизбежно влекут за собой потерю времени — обязательно кого-нибудь нужного не будет на месте. Относитесь к этому по возможности спокойно и философски. Руководители проектов должны развивать в себе чутье, подсказывающее, когда следует надавить, а когда лучше пустить некоторые процессы на самотек.
  • Общий подход. В конечном счете, основная идея, в которую я уверовал, состоит в том, что пока вы никому не причиняете боли (кроме возможных конкурентов) и ведете людей в правильном направлении, ничто, кроме того, что вы делаете благое дело, не имеет значения. Пока результат положителен, неважно, сколько идей исходит от вас, а сколько — от кого-то другого. Руководство проектом оправдывает любые средства, необходимые для повышения вероятности и сокращения сроков наступления благополучного исхода.
  • Остерегайтесь претенциозности и излишней вовлеченности во все дела в процессе своей управленческой деятельности. Процесс должен содействовать работе команды и никак иначе.
  • Некоторые руководители проектов прибегают к количественной оценке того, что в оценке не нуждается. Испытывая сомнения насчет своих дальнейших действий или опасаясь решения самых насущных вопросов, они тратят время на какие-нибудь второстепенные занятия. И по мере роста пропасти между руководителем и целями проекта, все больше внимания уделяется составлению ненужных диаграмм, таблиц, табелей и отчетов. Вполне возможно, что в какой-то момент времени руководитель проекта начинает верить в то, что эти данные и процесс их обработки — это и есть проект. Его внимание концентрируется на менее значимых вещах, с которыми проще работать (на электронных таблицах или отчетах), а не на чем-то более важном, с чем приходится сталкиваться в процессе работы (связанном с программированием или с календарным планом работ). Может выработаться убеждение, что достаточно лишь следовать определенным процедурам улучшения работы и правильно проставлять табельные данные, чтобы успех проекту был обеспечен (или, если быть более циничным, чтобы любой просчет, который может произойти, не мог быть технически отнесен на счет такого руководителя).
О планировании

Тема планирования в книге всплывает несколько раз, я постарался собрать все мысли автора в одном месте:

  • Людям свойственно опаздывать
  • Календарные планы являются фактором принуждения, играющим существенную роль в реализации проектов.
  • Одна из целей разработки календарных планов состоит в предоставлении команде средства контроля за ходом работ и в разделении всей работы на поддающиеся управлению этапы. Разбиение на одно- или двухдневные задания на самом деле помогает исполнителям осознать объем предстоящих работ
  • Планы не могут исправить неудачный проект или его техническое воплощение, не могут защитить проект от слабого руководителя, нечетко сформулированных целей и плохо организованного взаимодействия. Поэтому, сколько бы времени не было затрачено на создание календарных планов, они все равно останутся лишь набором слов и цифр. А вот будут ли они использованы в качестве инструмента управления проектом для его успешного продвижения — зависит от конкретных людей.
  • Наипростейшая модель составления календарного плана работает следующим образом: любой проект разбивается по отпущенному на него времени на три части: проектирование, разработку и тестирование
  • Если позволяют сроки, правило трех частей допускает некоторый дисбаланс, при котором считается нормальным отводить на тестирование на двадцать и более процентов времени больше, чем на разработку.
  • Чем больше ожидаемых изменений и неточностей закладывается в проект, тем короче должен быть каждый этап. Таким образом снижается степень суммарного риска, связанного с выполнением календарного плана, поскольку общий план оказывается поделенным на управляемые фрагменты
  • Как только что-нибудь идет не так, обычно винят во всем календарный план проекта. Если кто-нибудь допускает просчет, не выполняет требование или попадает под автобус, критике подвергается календарный план (или сотрудник, ответственный за его разработку).
  • До тех пор пока не будут осмыслены требования и не пойдет полным ходом планирование высокого уровня, руководитель проекта практически слеп и не имеет достаточной информации для построения реалистичных прогнозов.
  • Зачастую люди попадают в ловушку, где точность подменена скрупулезностью: впечатляющий календарный план с определенными датами и сроками (скрупулезность) совсем не обязательно отражает реальность (точность). Проще достичь скрупулезности, точность дается намного сложнее.
  • если в основу календарного плана легли непроверенные и неисследованные поверхностные предположения, к тому же не подвергающиеся дальнейшему уточнению, степень риска весьма высока. Совершенно очевидно, что в начале проекта оценить требуемое время не под силу никому.
  • только когда проект достигает стадии реализации, диапазон расчетов календарного плана приобретает разумные очертания, но даже тогда остается 20-процентный разброс вероятности планирования.
  • Я думаю, вполне разумно широко привлекать к расчетам команду тестировщиков и контролеров качества продукции, позволяя им участвовать в обсуждении проекта, задавать вопросы или делать комментарии. Как минимум, это поможет им в собственных оценках работ по тестированию, которые могут никак не соотноситься с расчетами на работы программистов. Зачастую тестировщики обладают лучшим видением недостатков проекта и потенциальных причин сбоев, которые другими специалистами могут быть упущены.
  • Хорошие инженерные расчеты достижимы лишь при наличии двух вещей: хорошей информированности и хороших специалистов. Если специалисты никудышны и просят программиста получить нечто реальное из малопонятных каракулей, нарисованных мелом на доске, все должны четко осознать, что результатом будут крайне приблизительные и малопонятные расчеты. Это означает, что качественные расчеты — дело всех и каждого, коллективные усилия всей команды, всех руководителей и проектировщиков, направленные на то, чтобы сделать все возможное в помощь специалистам при производстве расчетов
  • Иногда давление должно применяться, чтобы заставить людей не врать, но только как мера весьма сбалансированная (как правило, необходимость в этом возникает по отношению к программистам, завышающим расчеты на нелюбимые работы и затем снижающим их на любимые). При случае, получение нескольких оценок (от двух разных разработчиков) может стать одним из способов проверки.
  • Неплохо, если в привычку программистов войдет сохранение преемственности расчетов от проекта к проекту. Эта тема должна стать частью их дискуссии с руководителем проекта; в интересах руководителя выяснить, кто из команды преуспел в тех или иных расчетах. В экстремальном программировании в соответствии с понятием скорости, заложенным в сам термин, вероятная производительность программиста (или команды) определяется на основе предыдущих достижений.
  • Посвящайте команду в философию планирования. Какие бы технологии и подходы к планированию не использовались, их нужно доводить до команды. Если каждый программист и тестировщик сможет в общих чертах разобраться в принципах работы календарных планов и конкретной стратегии управления, применяемой в данном проекте, у него появится возможность задавать продуманные вопросы, понять общий замысел и поверить во все то, что планируется сделать.
  • Календарные планы выполняют три функции: позволяют зафиксировать обязательства, стимулируют каждого на отношение к своей работе как к вкладу в общее дело и дают возможность отслеживать процесс реализации проекта. Даже если календарные планы срываются, польза от них все равно остается.
  • Чем раньше сделаны оценки, тем менее они точны. Но несмотря на это, приблизительные расчеты — единственный способ построения фундамента для более точных расчетов.
  • Календарные планы должны составляться не с оптимистических, а со скептических позиций. Чтобы пролить свет на предположения и приобрести уверенность в успехе, нужно вложить достаточные силы и средства в проектирование.
О методологиях

С мнением автора по вопросу методологий я полностью согласен. Нельзя слепо следовать процедуре лишь потому, что «так принято», если это не приближает нас к результату. Хотя… думаю многие опытные руководители проектов могут припомнить случай, когда на первый взгляд формальные действия защищали команду от потенциальных претензий со стороны Заказчика. Мне кажется, тут дело еще и в менталитете. Вот что говорит Скотт о методологиях:

  • Любая методология нуждается в корректировке и адаптации под особенности команды и проекта, а такая адаптация достижима только при наличии базовых знаний, более глубоких, чем знание самой методологии
  • Нет ничего хуже, чем слепо следовать наборам абсолютно несостоятельных правил или процедур только потому, что они изложены в популярных книгах или проповедуются многоуважаемыми гуру. Очень часто я убеждаюсь, что одержимость процессом — весьма тревожный знак, свидетельствующий о затруднениях в руководстве: это может быть попыткой переложить обычные проблемы и ответственность, с которыми сталкиваются руководители, на систему процедур и бюрократических приемов, подменяющих необходимость осмысленных действий
  • Том Демарко (Tom DeMarco) в своей книге «PeopleWare» («Человеческий фактор в программировании») отмечал: «Навязчивая идея применения методологий на рабочем месте — еще один пример высокотехнологичной иллюзии. Она берет начало из веры в то, что технология — это единственное, что на самом деле имеет значение… Какие бы преимущества не давала применяемая технология, они могут быть получены только за счет существенного ухудшения социального климата в команде разработчиков».
  • Сосредоточенность на приемах и методах, подменяющая организацию процесса, направленного на поддержку и усиление человеческого фактора, приводит к тому, что планирование проектов начинается с наложения ограничений на вклад каждого из участников в его реализацию. При этом может быть установлена уйма правил и инструкций, вместо того чтобы подумать о корректировке или совершенствовании этих правил. Поэтому будьте очень осторожны в применении любой методологии: она не должна подавлять инициативу команды.

Кстати, если кто не знает: Том Демарко — гениальный автор. Советую.

 

О  требованиях к системе, идеях и концепциях.

Очень важный момент, который часто приходится наблюдать на практике:

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

Для иллюстрации хорошо подходит приведенная диаграмма Венна:

Диаграмма вена

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

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

  • Наиболее важная часть процесса — распределение ролей. Кто получит полномочия на выдвижение требований? На проектирование? Если в процесс вовлекается много людей, как будут приниматься решения?
  • Нужно почаще проводить обсуждения каждого из взглядов на проект. Должна сообщаться новая информация или доводиться замыслы, подниматься новые вопросы или делаться выводы. Специалисты из других подразделений вашей организации или команды должны привлекаться на эти обсуждения, если у них имеется полезный опыт работы или их мнение представляет ценность для группы.
  • Руководитель проекта, как правило, несет ответственность за объединение усилий всех участников встреч и обсуждений на решении ключевых вопросов и за фиксацию достигнутых итогов в понятном для всей группы виде. Поднятые вопросы или проблемы должны быть соответствующим образом распределены и обсуждены на следующей встрече.
  • Необходимая степень детализации структуры и вида документов плана зависит от характера проекта. Нужно избавиться от догмы, что документы плана — это нечто жестко заданное. В конце концов, это всего лишь документы. Степень их подробности или своеобразия зависит от сущности проекта и культуры проработки документов плана, присущей той или иной команде. Тем не менее, качественно разработанные концептуальные документы, хотя и охватывают по сути одни и те же вопросы, отличаются глубиной и серьезностью подхода.

Автор выделяет 5 параметров концептуальных документов:

  • Простота
  • Целеноправленность (SMART (Specific, Measurable, Action-oriented, Realistic, Timely — точность, измеряемость, действенность, реалистичность, своевременность).)
  • Консолидация идей (ключевые мысли исследователей, аналитиков, специалистов)
  • Способность вдохновлять
  • Запоминаемость

Зачастую наиболее ответственной частью этого процесса в средних или крупных организациях является работа с генеральным директором или с представителями других команд по координации взглядов на конечный результат проекта. Нужно узнать, нет ли у генерального директора или у руководства планов в масштабе всей организации, которые могут повлиять на задуманный проект? Есть ли толковые специалисты, у которых обязательно следует проконсультироваться? Есть ли в организации представители руководящего звена (на уровне команд или организации в целом), обладающие нужным опытом или политическим влиянием, с которыми стоит наладить взаимоотношения? Ожидают ли от нас выработки каких-нибудь существенных идей или, по крайней мере, принимают ли во внимание такую возможность? Нужны ли мы для выработки чего-либо подобного в интересах других проектов, осуществляемых организацией, что могло бы способствовать успеху в их реализации?

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

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

  • Частью этого процесса может стать презентация ключевых идей и проекта концепции перед всей командой (так называемое общее совещание), проводимая на достаточно ранней стадии, для того чтобы не превратить все в пустую формальность, но и не раньше, чем можно будет уже вести разговор по существу. Несмотря на то, что новых руководителей часто охватывает чувство страха перед подобным мероприятием, если совещание проводится в тот момент, когда основные идеи уже сформированы, но вопросы еще остаются, каждому участнику проекта представиться возможность воспринять концепцию как нечто живое и доступное. Никто не станет ее отвергать, если еще осталось что-то, на что можно повлиять или что можно подвергнуть сомнению. Если концепция возникла в результате многократных обсуждений с учетом сделанных критических замечаний, то ее презентация в команде будет выглядеть естественным событием для всех присутствующих.
  • Плохо составленные концепции не имеют целостности, не предлагают никакого плана и не выражают совокупности мнений. Вместо этого в них излагаются размышления и прописные истины. Если в концепции нет четкой точки зрения на результаты работы, руководители команд никогда не станут работать с душой, обрекая проект на провал

Типичные примеры неудачных концептуальных положений

Слабость Пример Источник слабости
Банальность Предоставить пользователям изделия максимальные возможности Слишком расплывчатая и бесполезная формулировка. Это общая цель организации, а не концептуальное положение проекта
Тарабарщина Разработать набор стратегических, управляемых базой знаний инструментальных средств широкого назначения с их последующим развертыванием и управлением их работой в целях улучшения уровня обслуживания наших подразделений, партнеров и сотрудничающих с нами организаций для наиболее полного удовлетворения потребностей различных клиентов Коллегиально сформулированное положение с использованием специфических выражений. Отсутствие смысла прячется за витиеватостью самой фразы. Никто не знает, что это все означает на самом деле, поэтому от данного положения нет ни малейшей пользы
Расплывчатость Мы можем в конечном счете рассмотреть попытку создания чего-нибудь более совершенного, чем ранее созданные нами изделия, что, по крайней мере, будет отвечать нашим нынешним представлениям, но при этом не забегая вперед, поскольку ситуация в скором времени может опять измениться Совершенно неопределенная формулировка, не дающая команде никаких ориентиров по сосредоточению усилий
Исполнение желаний вице-президента Вице-президент считает, что нашей корпорации нужно стать лучшим производителем устройств на средних по объему рынках сбыта, и мы приложим все усилия для достижения намеченного им уровня, используя для решения задачи все имеющиеся в нашем распоряжении ресурсы «Я так сказал» — не слишком подходящий аргумент. Вице-президент обязан обосновать важные решения, для этого и создается концепция проекта

Дальше речь пойдет о том, как следует обосновывать концептуальные положения:

  • Требования, изложенные в концептуальных положениях или в целях проекта, должны быть раскрыты и объяснены в других разделах документа. Значение этих положений для пользовательских нужд, облегчения работы, надежности или учета наиболее распространенных претензий должно быть в достаточной степени разъяснено, чтобы можно было принять вполне обоснованные решения. Если важность данных положений позволяет им стать частью концепции, стало быть, их целесообразно сопроводить конкретными разъяснениями специалистов с такой степенью детализации и определенности, которая позволит точно сформулировать технические задачи. Если поставлена цель добиться «простоты использования», но по этому поводу никем не предоставлено никаких разъяснений, команда окажется не настроенной на достижение этой цели. При выработке концепции руководство должно оценивать потребности в ресурсах для успешной реализации проекта и определять способы заполнения имеющихся пробелов в ресурсах и мастерстве разработчиков (для этого на выбор имеется несколько приемов, включая обучение персонала, поднаем специалистов, корректировка самой концепции или скрещивание пальцев на удачу).
  • Чтобы концепция всегда была на видном месте, несколько ключевых целей проекта должны быть оформлены в виде плакатов, расположенных в наиболее людных местах. Их открытое обсуждение должно вестись на еженедельных или ежемесячных совещаниях после предварительной публичной зачитки. Если командой используется демонстрационный экран или другие вспомогательные средства визуализации, то должен быть высвечен первый слайд (или открыта первая страница) с ключевыми целями. Большинство сотрудников в любое время должны быть в состоянии назвать основные цели проекта, по крайней мере, те из них, к которым они имеют непосредственное отношение или за реализацию которых несут личную ответственность.
  • Цели команды разработчиков должны быть производными от целей, определенных в концепции, а индивидуальные цели, в свою очередь, от целей, поставленных перед командой.
  • Хорошая концепция отличается простотой, запоминаемостью, целенаправленностью, способностью консолидировать усилия участников проекта и вдохновлять их на его реализацию.
  • Объем не является эквивалентом качества. А краткость дается намного сложнее объемистости.
  • Концепция должна сохранять актуальность за счет ее повседневной сверки с решениями, принимаемыми в ходе реализации проекта.

Затем логично рассматривается тема создания прототипов. Автор называет прототипы «опорой программистов». Прототип в случае программного продукта – это некий пример того, в каком виде продукт предстанет перед пользователем. Это могут быть экранные формы, текстовое описание, схемы и пр., в общем все, что может придать ясности для конечных пользователей о том, что они увидят. Это очень важный этап работ! Автор рассказывает о прототипах по примеру аналогий их других сфер деятельности:

  • Архитекторы небоскребов и конструкторы автомобилей создают множество физических макетов и прототипов, помогающих им осмыслить идеи, над которыми они работают, и получить на них отзывы со стороны. Создатели кинофильмов для тех же целей используют доску с эскизами, на которых изображаются сцены из фильма
  • Если конечный результат работы не может быть наглядно представлен даже в виде эскиза, макета или схемы, я готов утверждать, что концепция вряд ли будет правильно истолкована. Если вы не в состоянии найти какое-нибудь визуальное представление о том, что изменится в этом мире под влиянием проекта, стоит призадуматься, не направлен ли этот проект на создание совершенно бесполезных вещей или достаточно ли он понятен, чтобы быть успешно претворенным в жизнь.
  • Удачно созданные прототипы значительно повышают вероятность взвешенности и высокого качества продуктов, моделируемых с их помощью. Полной гарантии, конечно, не существует, но шансы повышаются. Возможно, для руководителя проекта более важным является то обстоятельство, что в период разработки прототипов у программистов появляется время на исследование новых технических подходов, которые необходимо будет применить. Если они разумно распорядятся временем, отведенным на проектирование, качество произведенного ими программного кода значительно возрастет.
  • Я по собственному опыту знаю: независимо от того, насколько реально впечатление взаимного согласия, если все люди не смотрят на одно и то же изображение, ни о какой согласованности не может быть и речи. Каждый человек может иметь собственное, совершенно отличное от других представление, и когда он соглашается с другими, на самом деле он думает о чем-то своем. Позже в создавшейся неразберихе, скорее всего, будет обвинен проектировщик или руководитель проекта.

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

  • Если проблемы простотой не отличаются, команде потребуется время для оценки различных подходов и изучения наилучших из них перед тем, как полностью перейти к их реализации.
  • Мудрые путешественники выискивают тот путь, который меньше всего похож на тупик. Возможно, они пройдут немного по каждому из путей или найдут лучшую точку обзора (холм, гору или дистанционно-управляемый спутник-шпион, находящийся на геостационарной орбите), чтобы получить побольше информации. Чем протяженнее предстоящее путешествие, тем больше времени потребуется потратить на разведку маршрута.
  • Качественные требования могут не определять способов решения проблемы, но должны содержать ее четкую формулировку, чтобы кто-нибудь, обладающий достаточным опытом, смог уверенно работать над ее решением.
  • Требования имеют решающее значение. Они являются отправной точкой для зарождения идей и потенциальных решений. Если в требованиях определено, что «это будет сарай зеленого цвета», то все задействованные в проектировании специалисты будут думать о разнообразных зеленых сараях. Польза от этого двояка. Во-первых, из рассмотрения исключается масса ненужных идей (можно будет с легкостью поставить на место тех, кто уже заготовил эскизы голубых космических кораблей). Во-вторых, проектировщики получают возможность задавать вопросы, ведущие к дополнительным исследованиям требований. Эти вопросы могут быть вполне конкретными, например: «Подойдут ли светлые оттенки зеленого или нужен только темно-зеленый цвет? Какова должна быть площадь сарая?», или более общими, например: «Для чего будет использоваться сарай? Предусматривается ли чердак? Он и обойдется недорого, и в хозяйстве пригодится».

Если Вы заметили, уважаемый читатель, выше сказано, что «качественные требования могут не содержать способов решения проблемы». А именно это часто приходится наблюдать в документах по IT-проектам — попытки описать пути решения еще на уровне требований. Никто не говорит, что этого делать не нужно, но это лучше делать в разных документах. Впрочем, ниже данный вопрос еще будет раскрыт.

Предлагаются конкретные рекомендации по улучшению требований:

  • Обязательно планируйте обсуждения и пересмотры требований. Поскольку требования вызывают вопросы у проектировщиков, вполне вероятно, что некоторые из этих вопросов окажутся настолько существенными, что потребуют частичного пересмотра самих требований. Кто бы ни нес ответственность за выработку требований, он должен запланировать подобные мероприятия, предусмотрев начало обсуждений с проектировщиками на достаточно ранней стадии, позволяющей учесть их мнения или создать условия для корректировки требований на более поздней стадии, после того как уже будет предложен ряд ценных идей. Требования должны формироваться вокруг сути решаемых проблем, а не вокруг путей их решения, чтобы в дальнейшем меньше приходилось подвергать их корректировке.
  • Постарайтесь отыскать все ошибочные предположения. Требования нередко основаны на мнимых предположениях о потребностях или желаниях заказчиков или пользователей. Формирование списка возможных требований может вестись по электронной почте или в виде неформальных списков, и каждый может предположить, что их тщательное исследование и всестороннее рассмотрение проведено кем-то другим. Если вы руководите проектом, вам подобных предположений делать не стоит. Вы должны настойчиво задавать уточняющие вопросы, такие как «К чему нам это требование?», «Какую проблему с помощью этого требования можно решить?», «Кто выдвинул это требование?». Подобные вопросы помогают высветить истинную суть выдвинутых требований. Помните, что людям свойственно заблуждаться или неосознанно распространять ложную информацию.
  • Постарайтесь выявить все упущения. Самые явные ошибки в составлении требований связаны с упущениями. Они могут носить как частичный, так и общий характер. Частичные упущения заключаются в пропуске одного из аспектов требования (например, при указании поля данных пропущен его формат), а общие — в пропуске какого-нибудь требования целиком (веб-сайт должен быть на греческом языке и поддерживать работу в Netscape 2.0). Упущения могут допускаться по двум совершенно разным причинам: либо заказчику безразличен данный аспект проблемы, либо этот аспект важен для него, но как следует не продуман или забыт. Тут, как и в случае с ложными предположениями, именно руководитель проекта должен выявить все информационные пробелы и определить одну из двух причин их возникновения.
  • Определите относительный приоритет каждого требования. Поскольку всем нам свойственно включать в список покупок все, что только нужно и не нужно, то по отношению к требованиям весьма существенно определить важность каждого из них относительно всех остальных (хотя бы предположительно). После установки относительной ценности переговоры между специалистами, отвечающими за выработку требований, и теми, кто отвечает за разработку конечного продукта, пойдут намного легче.
  • Постарайтесь уточнить или исключить случайно допущенные неоднозначные понятия. Такие слова, как быстрый, большой, маленький, хороший, красивый и удобный, понятны лишь в сравнении. Они могут оставаться неопределенными при условии, что все участники выработки требований (заказчиков, начальников, программистов и т. д.) согласны отложить внесение ясности до следующих переговоров. В противном случае каждый, кто вовлечен в выработку требований, не захочет вносить уточнения там, где это ему не выгодно. Зачастую простейшим способом устранения неясных моментов является установка определенных границ
  • Даже наилучшая в мире архитектура, основанная на лучших объектных моделях, на самых замечательных алгоритмах и самом быстродействующем и надежном программном коде окажется абсолютно бесполезной, если пользователи, для которых все это создавалось, так и не смогут разобраться, как это можно применять по назначению

О том, как подготовить хорошие технические условия и создавать понятные документы по проекту

Самое поучительное в этой истории заключается в том, что при составлении технических условий или документировании работы, как и при любом виде человеческой деятельности, не существует единственно верного пути. Технические условия, как и многие другие задачи, стоящие перед командой, должны отвечать потребностям текущего проекта и интересам тех людей, которым предстоит их составлять и выполнять. Так же как разработка веб-сайтов и программных продуктов нуждается в проектировании для поиска наилучших подходов, так и технические условия нельзя грамотно подготовить без размышлений и многочисленных прикидок. Тем не менее, многие известные мне опытные специалисты попадались в ловушку, будучи уверены, что подготовка технических условий (как бы они их ни называли) может проводиться только одним способом: использованием ранее накопленного опыта. Иногда эта цепочка повторений уводила их к самым первым разработкам. Они считали, если эти проекты полностью не провалились, стало быть, способ составления технических условий положительно повлиял на конечный результат.

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

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

Вот о каких четырех документах идет речь:

  • Технические требования. В целях документирования всего, что ожидается получить от реализации проекта, в технических требованиях в общих чертах намечаются все запросы и обязательства, которым должна соответствовать работа. В них объединяются всевозможные рабочие требования и обеспечиваются ориентиры для всего проекта. В лучшем случае это должен быть список победных достижений, описывающий, как должен выглядеть конечный результат причем без слишком подробных объяснений того, какими способами всего этого достичь. Во всяком случае, технические требования должны быть определены до начала проектирования (хотя позднее они могут подвергаться уточнениям и дополнениям) и сделано это должно быть на основе положений концептуального документа. Технические требования вместе с функциональной спецификацией должны быть включены в документацию для внесения ясности в суть проекта и помощи в оценке текущей обстановки (будет ли данный план удовлетворять требованиям?).
  • Функциональная спецификация. В функциональной спецификации, или списке характеристик, описываются поведение и функциональные особенности продукта в соответствии с конкретным сценарием или набором сценариев с точки зрения потребителя. Список характеристик — это первый документ, вырабатываемый в процессе проектирования. В нем описывается функциональность создаваемого продукта через призму пользовательского интерфейса (если его создание предусматривается) и приводится детальный порядок функционирования компонентов с нетехнологической точки зрения. В нем должно быть также описано, как изменится характер работы пользователя, когда работа над проектом будет завершена. Туда же должно быть включен простой список работ, проводимых для осуществления общего замысла; такой список создается усилиями разработчиков. Отличие этого документа от технических требований состоит в том, что в нем определяются соответствующие требованиям конструктивные особенности, включая пользовательский интерфейс или другие не столь очевидные элементы проекта.
  • Техническая спецификация. В технической спецификации детализируются инженерные подходы, необходимые для реализации характеристик, представленных в функциональной спецификации. Степень детализации должна быть достаточной для описания самых сложных или многократно используемых компонентов, которые могут повторно задействоваться другими программистами и служить основой для определения работ по реализации заданных характеристик. Иногда глубина проработки и техническая направленность функциональной спецификации позволяют вообще отказаться от технической спецификации.
  • Списки работ. Список работ — это примерный эквивалент результата структурной декомпозиции работ (WBS). Пункты этого списка соответствуют распределению программных работ, выполняемых для реализации характеристик, перечисленных в функциональной спецификации. Список должен быть разбит на уровни по степени важности работ с подсчетом затрачиваемых дней на их выполнение (возможно, продолжительность некоторых работ должна быть определена с точностью до дня или до полудня, но все это — прерогатива программистов). Создание списка работ всецело возлагается на программистов, а ведущий программист или руководитель проекта должен его просмотреть и провести окончательное редактирование. (С технической точки зрения списки работ не относятся к техническим условиям, а представляют собой план реализации этих условий. Однако степень их важности и взаимосвязь с техническими условиями не позволила мне найти лучшего места для их представления)

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

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

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

Проще всего продумывать все четыре вида технических условий в простом хронологическом порядке: требования, функциональность (характеристики), техническое воплощение, работы. Как и многие другие проектные задания, каждая из этих четырех спецификаций обеспечивает основу для последующих действий. Чем многочисленнее команда и сложнее проект, тем, возможно, более формальным должен быть подход к разделению видов технических условий.

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

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

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

  • Перенимайте удачные объяснения, встреченные в других технических условиях (даже если их придумали другие люди). Применяйте в разумных пределах гипертекст и, если нужно, заимствуйте полезные обзоры из Интернета после получения соответствующей санкции от руководителя команды. Совсем не обязательно самому все изобретать и описывать.
  • Постарайтесь обойтись без жаргонных и туманных фраз. Не используйте их, если не уверены, что поможете тем самым читателю, что случается крайне редко.
  • Придерживайтесь наработок, содержащихся в старых технических условиях. Если вы застряли, пытаясь получше преподнести концептуальное положение или выразить что-то в виде диаграммы, хорошую подсказку всегда можно найти в старых технических условиях. Если вам попадутся удачные технические условия, написанные кем-то другим, воспользуйтесь ими.
  • При составлении технических условий постоянно думайте о специфике восприятия тех людей, которые будут все это читать. Даже если команда состоит всего лишь из десяти человек, то наиболее зависимыми в своей работе от технических условий окажутся, скорее всего, четверо или пятеро их них. Прибавьте для разнообразия какого-нибудь неглупого знакомого, не состоящего в команде и не знающего той технологии, которую вы используете. Как бы вы объяснили ему вашу малопонятную концепцию?
  • Не демонстрируйте свою влюбленность в Visio или Flowcharts. Относитесь ко всему доступному инструментарию с платонической любовью. Обычно диаграммы представляют интерес только для их создателя, и зачастую от них значительно меньше проку, чем он себе это представляет. Иногда удачно написанный абзац или небрежный нарисованный от руки эскиз дают больше, чем UML-диаграмма из пятисот блоков. (Только то, что диаграмма является единственным средством авторского понимания какого-нибудь положения, не дает никаких гарантий, что ее использование является лучшим способом объяснения этого другому.) Однако разумное применение инструментария и диаграмм может быть вполне оправдано.
  • Что это, справочник или технические условия? Вообще-то технические условия не должны быть полным справочником по API-функциям или описанием каждого возможного варианта поведения продукта. Разумнее сосредоточиться на объяснении десяти-пятнадцати наиболее общих или важных положений и создать отдельный документ с исчерпывающим перечнем всего остального (с меньшей степенью детализации).
  • Перед тем, как с головой уйти в работу, опишите на высоком уровне все сложные алгоритмы, воспользовавшись псевдокодом или обычным языком. И, как уже ранее упоминалось, следует учесть, что распределение объяснений по уровням поможет быстрее усвоить материал даже интеллектуалам. Как минимум, важную роль могут сыграть удачно составленные резюме и краткие обзоры.

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

Чем лучше технические условия, тем выше вероятность получить конечный результат в установленные сроки. Вопрос в том, какая степень вероятности вам нужна. Стоит ли тратить время на улучшение технических условий на 5 %? Сумеют ли программисты или руководитель проекта обдумать некоторые детали по ходу работы над реализацией проекта? На эти вопросы ответить не легко. Просматривая какие-либо технические условия, я должен был составить о них собственное мнение. Я думаю, что для принятия решения в большей степени нужен опыт управления проектами, а не мастерство программиста или технического писателя.

Про список проблем:

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

  • Когда требуется решить эту проблему? Какая кандидатура лучше всего подходит для ее решения?
  • Нельзя ли как-то изолировать проблему, может быть с помощью специфического компонента или сценария? Влияет ли она на общую функциональность или на весь проект?
  • Чем может разрешиться проблема в случае выбора каждого из вариантов, которые еще находятся в стадии рассмотрения? (Например, если мы решим использовать технологию ASP или PHP вместо JSP.) Как выбор каждого из вариантов повлияет на технические условия?
  • Нельзя ли вообще проигнорировать эту проблему? Как это реально повлияет на пользователя, забота о котором стоит на первом месте в списке приоритетов?
  • Можно ли разбить проблему на более мелкие и передать их для решения другим специалистам?
  • Кто или что мешает решению проблемы и были ли предприняты усилия для устранения этой помехи? (Ответ может скрываться в технической или политической сфере.)

Интересная идея о психологии проектировщиков:

Возможно, многие стараются уклониться от участия в проектировании, опасаясь проводить исследования под пристальным взглядом других. Когда мы исследуем собственную работу (например, пытаемся оптимизировать алгоритм или подправить документ), то делаем это без свидетелей. Мы можем свободно проверять самые сомнительные или странные идеи, самостоятельно оценивая собственные действия. А занимаясь проектированием в составе команды согласно графика общей работы, каждый проектировщик будет проводить исследования на виду у массы людей. Все создаваемые им эскизы или прототипы придется публично демонстрировать и открыто обсуждать. Если люди не верят в конструктивность высказываемых им критических замечаний, то не удивительно, что они боятся участвовать в процессе проектирования.

О том, как следует задавать вопросы:
  • Зачастую люди упорно говорят совсем не о тех вещах, которые вас интересуют. Но согласно приобретенному мной опыту изучения логики, четко и уверенно заданные вопросы способствуют направлению разговора в нужное русло.
  • Творческое решение проблем предполагает три вида вопросов: концентрирующие внимание (хорошие), относящиеся к творческому процессу (тоже хорошие) и риторические (вредные). Хорошие вопросы выступают в роли катализатора: они заново объединяют знания и энергию участников дискуссии, придавая ей глубину, повышая ее качество и направленность, снова выплескивая всю их энергию на уже более благодатную почву.  Обсуждения конструктивных особенностей строятся обычно на обмене вопросами подобного рода между сотрудниками одной команды. Этот обмен сопровождается массой рассуждений, демонстрацией эскизов и попутными исследованиями ответов. Хорошие креативные вопросы обычно повышают количество альтернативных вариантов и расширяют область дискуссии. Будьте осторожны с вредными двойниками креативных вопросов — так называемыми риторическими вопросами. Они расплывчаты и не требуют буквальных ответов. Они похожи на те, которыми родитель, ругает своего ребенка («О чем ты думал, когда съел целую коробу Фрут Лупс?» или «Как ты мог позволить Салли намазать экран телевизора арахисовым маслом?») и ведут к завершению дискуссии. Они намекают на чью-то вину или дают отрицательную оценку. Предполагается, что человек, задающий риторические вопросы, знает больше, чем тот, кто их выслушивает, и они незаслуженно подрывают репутацию слушателя. Люди, обладающие властью, но не умеющие правильно ею распоряжаться (к примеру, бездарные начальники или учителя), часто задают риторические вопросы.
    • Технические условия должны принести проекту тройную пользу: гарантировать создание задуманного продукта, обеспечить контрольные точки, определением которых завершается стадия планирования проекта, и предоставить возможность для углубленного обсуждения и получения отзывов от различных людей относительно направленности проекта.
    • Технические условия призваны решать конкретные проблемы. Руководители команды должны ясно осознавать, какие именно проблемы они стараются решить с помощью технических условий и какие проблемы должны быть решены другими средствами.
    • Удачно составленные технические условия отличаются простотой. Прежде всего они являются формой организации взаимодействия всех специалистов при работе над проектом.
    • Составление технических условий в корне отличается от проектирования как такового.
    • Полномочия по составлению технических условий и контролю над этим процессом должны быть четко определены.
    • Устранение пробелов — один из подходов к управлению списком открытых проблем и к ускорению завершения процесса составления технических условий.
    • Проведение обсуждения — простейший способ определения уровня технических условий и контроля их качества.
Об изменениях:

Ни одна из битв не была выиграна в точном соответствии с планом, но не было и ни одной битвы, выигранной без него.

Дуайт Д. Эйзенхауэр

Механизм контроля изменений (с использованием запросов на изменение замысла) позволяет регулировать внесение в проект изменений среднего и низкого уровня

Не следует бояться вносить изменения в обсуждаемые решения, как и в уже принятые, если это идет на пользу. Это хорошо отражает приведенная цитата Эрнеста Хемингуэйя:  «На одну страницу шедевра у меня приходится 99 страниц мусора». Автор выделяет следующие основные причины изменений:

  • Открывается доступ к новой информации. Мировое развитие не останавливается из-за того, что вы разрабатываете свой проект. Компании могут оставлять целые сферы бизнеса. Технологии могут быть бесперспективными. Бюджет может корректироваться. Изучение потребительских интересов или проведение опроса пользователей может привести к новому пониманию проблемы («Распечатывать документы приходится чаще, чем мы думали» или «Созданный нами прототип домашней страницы не соответствует даже типовым задачам пользователей»).
  • План разработчиков становится яснее, уточняются примерные расчеты объема возможных работ. На смену первичному осмыслению приходит более глубокое вторичное. Иногда оно идет на пользу проекту, а иногда — во вред. Например, программист может найти новую стратегию реализации продукта: «Если мы выполним эту работу, используя новый способ, мне не придется заниматься пятью другими работами — так мы выкроим дополнительное время для оставшихся работ или сможем завершить весь проект раньше срока». Или: «Поскольку мы не сможем сделать данную работу первоначально задуманным способом, нам придется заниматься пятью дополнительными работами, а значит, для других работ останется меньше времени или завершение всего проекта будет отложено на более поздний срок».
  • Обнаруживается конфликт двух решений двух разных проблем, и эти решения при объединении идут во вред друг другу. Это может произойти по разным причинам, касающимся потребительских качеств, деловых интересов или конструкторской несовместимости. У Джо может быть фантастическая конструкция автомобильного двигателя, а у Салли — великолепная конструкция трансмиссии, но когда все это объединяется в единую конструкцию, они видят, что по некоторым показателям их создания конфликтуют друг с другом, например, трансмиссия вместе с двигателем не помещается в отведенное для них пространство.

 

Принятие решений в процессе проектирования, даже, если они окажутся неверными, — единственный способ вывести проблемные вопросы на поверхность. Если вы все правильно спланируете, то все равно будете многократно спотыкаться при проектировании, но, пройдя все это, вы значительно повысите свои шансы на успех. Большинство инженерных, конструкторских и научных изысканий следуют тому же принципу, выраженному следующей цитатой Джошуа Ледерберга (Joshua Lederberg), лауреата нобелевской премии 1958 года:

Количество проб и ошибок огромно… Вы продвигаетесь вперед и назад от наблюдения к теории. Без теории вы не знаете, что именно нужно искать, а проверить теорию, не изучив факты, вы тоже не можете… Я думаю, что в ходе отдельного исследования движения вперед и назад происходят тысячи, и даже миллионы раз.

 

Чтобы наилучшим образом распорядиться идеями, нужно начинать любой серьезный проект с расстановки четких контрольных точек, задающих распределение времени. Перед тем как творческий процесс пойдет в полную силу, в дополнение к двум контрольным точкам, моменту окончания выработки требований (формулировки проблем) и моменту выдачи технических условий, нужно определить еще ряд промежуточных точек. Расставить эти точки во времени (и убедить всех в их пользе) — задача руководителя проекта, хотя, может быть лучше, чтобы проектировщики и разработчики определили, где именно их следует расставить и какими должны быть критерии их достижения

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

 О том, как  принимать хорошие решения

Гэри Клейн (Gary Klein) в своей книге «Sources of Power: How People Make Decisions» (MIT Press, 1999) написал: «…к курсам по формальным методам принятия решений нужно относиться скептически. На них преподаются методы, которые людьми используются крайне редко».

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

Два основных подхода к принятию решений

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

Хорошие специалисты по принятию решений не тратят время понапрасну на оптимизацию тех вещей, которые в этом не нуждаются. Как сказал Тайлер Дерден (Tyler Durden): «Не стоит уделять внимание тому, что не имеет значения».

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

О том, что нам действительно не хватает простоты:

Другим инструментом, помогающим сузить количество возможных вариантов, является принцип, известный как «бритва Оккама». Уильям Оккам был средневековым философом, жившим в 12 веке. Ему приписывают использование понятия простоты для управления решениями. Он верил, что люди зачастую склонны усложнять ситуацию, даже если это не помогает им в решении проблем. Он предложил считать лучшим способом осознания вещей поиск простейших объяснений, которые нужно использовать в первую очередь, поскольку, в большинстве случаев, такие объяснения бывают верными (то есть, выражаясь современным языком, чем проще, тем лучше). Принцип бритвы Оккама представляет собой попытку избавиться от всех ненужных, мешающих деталей и обратиться к сути проблемы. В нем также содержится предположение, что решение, имеющее самые высокие шансы на то, чтобы стать лучшим, базируется на простейшей логике. Список может содержать весьма перспективный вариант, требующий сложной и рискованной технической проработки или как-то по-новому зависящий от ненадежных людей или технологий. Применяя принцип бритвы Оккама, можно рассматривать недостаток простоты и ясности как критерий, достаточный для отказа от варианта, как не имеющего шансов на успех, и остановиться на обсуждении более простого и надежного выбора.

Как и в последнем замечании об информации и данных, многие из нас забывают, в чем различие между точностью и достоверностью. Точность характеризует качество отдельного измерения, а достоверность показывает, насколько близко к реальности оказалось это измерение. То, что нам просто предлагают точное число (скажем, работа займет 5,273 дня), еще не означает, что оно окажется достовернее неточного числа (4 или 5 дней). Мы склонны путать точность и достоверность, поскольку допускаем, что если кто-то потратил время на вычисление столь конкретного числа, анализ лишь повысит шансы на то, что его расчеты верны.

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

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

Принимая сложные или трудные решения, невозможно охватить все обстоятельства и рассмотреть каждую возможность развития ситуации (хотя некоторые и попытаются это делать). Чем больше времени тратится на попытки учесть все непредвиденное (довольно распространенная привычка менеджеров низшего звена), тем меньше его остается на прогнозирование возможных результатов. Стоит ли беспокоиться о поражении молнией, если у вас проблемы с сердцем, плохой аппетит и вы не выходите из дома, поскольку упражняетесь в скоростной печати на машинке.

Выводы о принятии решений:

  • Нужно оценить важность искусства принятия промежуточных решений, то есть решений о том, каким решениям следует уделять время.
  • Оцените решения, прежде чем тратить на них время.
  • Найдите область безразличия и возможности для эффективного использования исключительной оценки.
  • Выполняйте сравнительную оценку решений, заслуживающих большего приложения сил.
  • Признаем мы это или нет, но все решениям присуща эмоциональная компонента.
  • Списки всех аргументов «за» и «против» являются наиболее гибким средством сравнительной оценки. Они облегчают привлечение других специалистов и придают решениям дополнительные перспективы.
  • Информация и данные не примут решения за вас.
  • Мастерство в деле принятия решений растет при исследовании прошлых решений с целью извлечения уроков и изучения возможностей совершенствования тактики.
 Общение и коммуникации

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

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

Простейшим средством преодоления трудностей станет совместное распределение ролей с любым авторитетом из среды программистов, тестировщиков, специалистов по маркетингу, представителей заказчика или даже ваших помощников. Уединитесь где-нибудь со своим новым коллегой и составьте на классной доске три списка. В первом списке перечислите все свои основные обязанности. Во втором — то, за что вы несете совместную ответственность. В третьем — то, за что несут исключительную ответственность все остальные. Поскольку над списком вы трудитесь вместе, обсуждая каждый его элемент, вы быстро поймете, чего следует ожидать друг от друга (см рис.). Распределение ролей высвечивает все предположения и накопившиеся у людей предрассудки относительно руководителей проекта, генеральных директоров, разработчиков, тестировщиков или кого-нибудь еще, имеющего отношение к делу.

  • Следуйте советам. Одно дело — прислушиваться к предложениям и совсем другое — что-нибудь предпринимать в соответствии с ними. Когда вас просят выделить для конкретных задач больше времени, лучше уступите этой просьбе. Если вам намекают, что вы проводите слишком много совещаний, позвольте предложить способ сокращения их количества. Относитесь к предложениям со всей серьезностью. Следуйте советам людей, вкладывая в это реальные усилия. Даже если в результате ничего не выйдет, но вы всерьез воспримете и выполните предложение работников, они это отметят. Эффект выразится в качестве их работы, что сродни успеху. Но не должно быть никакой фальши. Люди сразу же ее заметят (они в этом вопросе обладают богатым жизненным опытом).
  • Предъявляйте (или не предъявляйте) требования. Для человека, обладающего властью, самый очевидный и стереотипный способ заставить людей работать — предъявить требование («Упал, отжался!»). Чем умнее, независимее или квалифицированнее люди, с которыми вы работаете, тем менее вероятно, что такой подход сработает. Если есть хорошая концепция, интересная работа и люди справляются с делом, то необходимости предъявлять какие-то требования практически нет. Мотивация возникает естественным образом. Когда вам нужно закрутить гайки, найдите способ поумнее. Заключите приятельское соглашение: «Если мы успеем в срок, я выкрашу голову в синий цвет» или «Та команда программистов, которая первой устранит все ошибки, получит вечернее барбекю на моей яхте». Требования имеют право на существование, но не становитесь недоброжелательным, будьте проще. «Послушайте, это надо сделать. Обсуждать это уже поздно, я прошу прощения, если не объяснил этого раньше. Пожалуйста, просто сделайте это для меня, хорошо?».
  • Вдохновляйте людей на работу. Сымитировать вдохновение весьма трудно. Либо вы верите в то, что делаете, либо нет. Если вера присутствует, то вы должны найти некий способ выразить ее в позитивной форме, чтобы другие люди могли этой верой вдохновиться. «Послушайте, мне нравится этот проект. Нам платят за то, что мы изучаем и внедряем новые технологии. Случай особенный, такое происходит не часто, поэтому я с радостью каждый день иду на работу». Не нужно что-то усложнять или блистать красноречием. Если сказано от души, это сработает. Людям свойственно обмениваться положительными эмоциями, и когда вы выплескиваете свои эмоции наружу, вы делитесь ими с другими. Более простые способы включают опрос людей на тему, что им нравится в программировании, и помощь в установлении связи между этими чувствами и работой, которая им предстоит.
  • Расчищайте завалы. В Американском футболе каждый прославленный бегущий имел своего невоспетого героя, который прокладывал ему дорогу. Этот безвестный герой называется блокирующим. Он выскакивает впереди бегущего и сбивает с ног всякого, кто пытается остановить бегущего (даже если тот превосходит блокирующего по комплекции). Если вы повнимательнее присмотритесь к повтору любого момента игры, в котором бегущий преодолевает 70 ярдов, то всегда обнаружите другого парня, лежащего ничком на земле под грудой здоровяков. Именно этот парень и является главным соавтором успеха бегущего. Хорошие руководители проекта тоже являются такими соавторами. Они выискивают и устраняют проблемы, тормозящие работу команды. Спросите у людей: «Вам что-нибудь мешает?» Если они скажут, что ждут решения или пытаются отследить информацию, ваша задача выяснить, нет ли способов, с помощью которых вы могли бы ускорить процесс. Они должны знать, что вы всегда придете на помощь, если они встретят преграду.
  • Напоминайте людям о своей роли. Самый распространенный способ содействия улучшению работы заключается в напоминании людям о распределении ролей в команде. Когда программист жалуется, что к нему поступило слишком много запросов на реализацию новых характеристик, ответ должен состоять в том, что отклонять эти запросы он, скорее всего, не вправе, а при необходимости людей нужно направлять к вам как к руководителю проекта. Он может взять все на себя, если чувствует, что справится, но если новая задача не вписывается в график работы, ему следует обратиться к руководителю проекта, чтобы тот вмешался в происходящее. Иногда люди, в особенности программисты, настолько сосредоточены на своей работе, что забывают о том, что вместе с ними работают тестировщики, проектировщики и руководители, которые зачастую подготовлены для решения некоторых задач намного лучше программистов.
  • Напоминайте людям о целях проекта. Как у руководителя проекта или лидера, у вас более широкий взгляд на проект, чем у кого-либо другого. Людям нетрудно затеряться в дебрях их более узких зон ответственности и потерять ориентацию в том, какие вопросы представляют истинную важность. Короткий разговор, в ходе которого вы напомните, чего именно они добиваются и зачем, поможет восстановить направление работы, ее мотивацию и эффективность. Хороший руководитель проекта освещает путь подобно посадочным огням ночного аэропорта, которые обозначают взлетно-посадочную полосу и облегчают пилотам поиск безопасного направления.
  • Обучение. Если вы обладаете навыком или знаете прием, который могут использовать работающие вместе с вами люди, почему бы вам не предложить им научиться тому же? Передавая им новый прием или совет по использованию старого, вы удваиваете ценность своих знаний. Обучая людей, вы открываете перед ними возможность увеличить объем, сократить сроки и повысить их шансы на выполнение хорошей работы, а, возможно, заодно и повысить ее качество, в чем и заключается работа с полной отдачей. Ноэль Тичай (Noel Tichy), автор книги «The Leadership Engine» (Harper, 2002), высказался по поводу важности обучения следующим образом: «Если говорить о морском тюлене [после того, как он чему-нибудь научился], то первое, что он делает — учит своего приятеля, поскольку это спасет ему жизнь. Если я чему-нибудь научусь… побегу ли я к другим людям, чтобы научить их этому? А потом, смогу ли я сделать это в более широком масштабе? Вот в чем наша слабость».
  • Просьба. Казалось бы, очевидный, но редко применяемый прием. Просто попросите людей поработать с полной отдачей. Вам не нужно объяснять, зачем, или предлагать что-либо взамен. Просто скажите: «Послушайте, я хотел бы чтобы вы показали в этой работе все, на что способны. Она крайне важна для нас и если у вас есть резервы, я хотел бы, чтобы вы их теперь подключили».

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

  • Повышает качество создаваемого продукта.
  • Увеличивает шансы на своевременное завершение работы над проектом.
  • Помогает сделать продукт (веб-сайт, программу) более удобным для потребителя
  • Увеличивает шансы на прибыль от продукта (веб-сайта, программы) или на его продвижение
  • Освобождает людей от напрасной работы, защищает их от бестолковой политики или бюрократии.
  • Позволяет упростить поддержку разработки.
  • Повышает настроение или создает ощущение подъема у членов команды.
  • Помогает команде работать толковее и быстрее, применять (или изучать) новые приемы работы.
  • Пресекает поведение, если оно наносит вред проекту или команде, либо разъясняет ошибочность такого поведения.

 

Выводы:
  • Проект осуществляется только посредством общения. В наше время узким место общения является не скорость, а качество.
  • Хорошие взаимоотношения улучшают и ускоряют общение.
  • Существует несколько структур, объясняющих, как люди строят свое общение друг с другом. Руководители проектов должны быть знакомы с ними, чтобы уметь выявлять причины кризисов в общении и устранять их.
  • Существует ряд наиболее типичных проблем общения, в том числе неверные предположения, отсутствие ясности изложения, нежелание слушать, диктат, подмена понятий, персональные нападки, упреки.
  • Распределение ролей — самый простой способ улучшения взаимоотношений.
  • Спрашивайте людей, в чем они нуждаются для работы с полной отдачей. Добиться желаемого результата можно, прислушиваясь к людям, расчищая завалы, обучая людей и напоминая им о целях проекта.
  • Взаимоотношения и общение не относятся к низкоприоритетной работе. Они являются основой всей индивидуальной деятельности, осуществляемой в рамках проекта.

 

Глава   10. «Как не раздражать людей на работе, в ходе электронной переписки, на совещаниях»  очень интересная, хотя относится к менеджменту в целом, а не к специфики IT-проектов. Советую прочитать ее полностью в оригинале.

 

Что делать, если все идет не так

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

Угроза мятежа. Это экстремально резкая форма выражения неверия в успех. Такой момент наступает, когда командой уже пройден порог крушения всех надежд, и люди практически не реагируют на любую вновь вскрывшуюся проблему, какой бы значительной она ни была. Более того, люди больше жалуются на мнимые проблемы (к примеру, «Почему руководство, или тестировщики, или маркетологи, продолжают работать в прежнем направлении?»), а не решают проблемы насущные. Если ничего не предпринимается, недовольство могут поддержать старые сотрудники, и начнется мелкий или символический саботаж (например, устранение некоторых ошибок может внезапно усложниться). Кто-то должен прямо выступить против сложившейся ситуации и разрядить обстановку. Нужно публично признать факт кризиса, составить список всех жалоб и открыто заняться рассмотрением некоторых жалоб из этого списка.

Многое из того, что может усложнить ситуации такого рода, относится не к ситуации как таковой, а к обстановке, в которой она происходит. Чем позже в рабочем графике возникнут проблемы и чем слабее моральный дух команды (или руководителя проекта), тем сложнее будет справиться с ситуацией. Ближе к концу вариантов возможных действий по решению проблемы становится все меньше, а ставки в игре все выше.

Стюарт Брэнд (Stewart Brand) как-то сказал: «Бестолковая суета ведет к наслоению ошибок, а продуманное поведение позволяет на них учиться»

Про ответственность.
  • Возложив на себя ответственность, особенно в провальных или сложных ситуациях, вы неизменно получаете возможность профессионального роста. Подставляя собственное плечо, вы облекаете себя определенной властью, поскольку оказываетесь в самом центре событий. Отрицание вины или уклонение от ответственности дадут вам возможность избежать кратковременных проблем, связанных с неразберихой, или дать ответы старшему руководству на сложные вопросы, но не позволят извлечь уроки или совершенствовать и демонстрировать свои возможности. Если вы хотите развить навыки выхода из критических ситуаций, вы непременно сами должны гореть желанием принять огонь на себя.
  • Когда в чем-то очень важном происходит серьезный сбой, эта новость моментально распространяется по всей команде. Чем дольше вы будете затягивать свое обращение к народу, тем больше будет в команде разброда и шатаний на момент объявления аврала. Берите быка за рога и созывайте совещание или разошлите по электронной почте сообщение с наивысшим приоритетом. Коротко обрисуйте ситуацию и предпринимаемые действия. По возможности объясните свои действия за последние сутки (см. ранее раздел «Элементарные принципы руководства») и назначьте следующее время для новостей. Не скрывайте серьезных проблем: команда почувствует неладное, как бы хорошо вы все не скрывали.
  • Нельзя ли изолировать проблему? Подумайте о корабле, охваченном огнем. Может ли пожар распространиться дальше? Нельзя ли защитить от огня те части корабля, от которых зависит его живучесть? Подумайте, как локализовать проблему и предупредить ее влияние на наиболее критичные части вашего проекта. Возможно, потребуется пожертвовать какими-то менее важными обязательствами или перекинуть часть ресурсов от одной группы к другой. Может, понадобиться кратковременная поддержка со стороны специалистов из других областей, чтобы помочь изолировать или сдержать проблему, поскольку обеспечение стабильности проекта того стоит
Про роли

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

  • Комплекс героя. Существует особый тип людей, проявляющих себя в критических ситуациях. Эти люди с комплексом могут провоцировать опасные ситуации только потому, что в состоянии с ними справляться. Их зависимость от острых ощущений и трудностей, присущих чрезвычайным ситуациям, непомерно высока. Людям с начальной формой комплекса героя просто нравится работать в критических ситуациях и находить из них выход. Человек с крайней формой комплекса героя способен поставить «на кон» все, даже пойти на саботаж. Комплекс героя чаще всего развивается у тех, кто начинал свою карьеру с только что организованных или с очень мелких (временных) фирм. Поскольку у таких организаций нередко наблюдается дефицит ресурсов на реализацию своих амбиций, завершение работы зачастую требует героических или сверхчеловеческих усилий. Если все получится, триумфаторы начинают считать героизм весьма значимым фактором своего успеха. В данном конкретном случае они будут правы. Однако в их логика некорректна: если героизм был нужен в ситуации А, это еще не значит, что он понадобиться или будет полезен в ситуациях Б, В и Г.
  • Я работаю только на себя. Это самая эгоистичная мотивация героического поведения — герою просто нравится быть героем. Он настолько увлечен этим, что в процессе игры в героя совершенно не боится что-нибудь разрушить или поставить на грань риска. Признаками такого поведения могут стать бессмысленные состязания со своими коллегами или проявление безразличия к работе других (и даже к целям проекта). Герой может не понимать, что его стремление стать героем чревато последствиями для других, а не для него самого. Иногда он даже может не понимать, почему его героические усилия воспринимаются не так, как ему бы хотелось. («Неужели я не спас этих симпатичных, пушистых зверьков от огня, ворвавшись в горящее здание?» — «Да, но ты сам его и поджег».)
  • Псевдогерой. Это явление я наблюдал не так уж и часто. Его суть состоит в том, чтобы обрисовать руководству ситуацию намного хуже, чем она есть на самом деле, а затем, как по мановению волшебной палочки, выставить ее в куда более привлекательном свете, чем она казалась до этого, приписав себе заслуги во всем случившемся (надо же, герой!). Чем более несведущими или безразличными будут руководители, тем проще проделать этот трюк. Он может сработать всего пару-тройку раз, пока коллеги или другие специалисты не схватят «героя» за руку. Подобное нельзя назвать комплексом героя в чистом виде, поскольку человек, о котором идет речь, даже не пытался делать что-либо героическое, он просто хочет выглядеть героем.

Следующая мысль представляется мне сомнительной:

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

Про лидерство

Хотя в кино и на телевидении лидерство изображается с высокой степенью драматизма — герои врываются в горящие здания или в одиночку сражаются с ордами врагов — настоящее лидерство заключается в весьма простых и практичных делах. Делайте то, о чем говорите, и говорите то, о чем думаете. Признавайте свою неправоту. Используйте мнения и идеи других людей в тех решениях, которые влияют на их работу. Если чаще всего у вас именно так и получается, вы непременно завоюете доверие людей, с которыми вместе работаете

 Про власть

Если на первый план в руководстве выходит власть предоставленная, взаимоотношения носят ограниченный характер. Эта власть исключает возможность обмена идеями и концентрируется на принуждении, а не на разумном подходе. Хотя бывают и такие ситуации, которые требуют применения авторитарной власти, хорошие лидеры до последнего держат этот меч в ножнах. Как только вы его достанете, слушаться будут уже не вас — главным аргументом станет этот меч. Хуже того, в ответ все ваши приближенные тоже достанут свои мечи. Они не станут вам объяснять, почему вы не правы, а воспользуются предоставленной им властью, противопоставив ее вашей власти.

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

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

О том, как осуществить задуманное

Про приоритеты:

Для большинства проектов используются три наиболее важных типовых списка, содержащих расставленные по приоритетам цели, характеристики и работы (рис. 13.1). Списки характеристик и работ появляются в результате проектирования

К проведению черты, отделяющей первоочередные приоритеты, нужно подходить очень серьезно. Следует всеми силами бороться за то, чтобы верхняя часть перечня была как можно короче и компактнее (такое же правило применимо к любому перечню задач концептуального документа). Пункт списка, относящийся к первоочередным приоритетам, означает: «Без этого мы просто не сможем жить». Это не должны быть задания, которые неплохо было бы иметь в верхней части перечня или которые очень хотелось бы там иметь: подобный подход слишком слабо отвечал бы задачам проекта. К примеру, при сборке автомобиля к первоочередным приоритетам можно было бы отнести установку двигателя, колес, трансмиссии, тормозов, рулевого колеса и педалей, а к приоритетам второй очереди — установку дверей, ветрового стекла, системы вентиляции и радиоприемника, поскольку ездить на машине можно и без всего этого. Функциональность автомобиля сохраняется, эти элементы можно убрать, а то, что осталось, все равно будет называться автомобилем.

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

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

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

Побочным эффектом от наличия списка приоритетов является частое использование слова «нет», которое многим дается совсем не легко. Однако, не научившись говорить «нет», невозможно следовать каким бы то ни было приоритетам. Мир велик, а перечень первоочередных приоритетов краток. Поэтому большая часть из того, что в мире (или в вашей команде) многим представляется грандиозным, должно быть отклонено из-за несоответствия целям проекта. Это совсем не значит, что идеи сами по себе плохи, суть в том, что они плохи в данном конкретном проекте. Итак, для руководителей проектов действует следующий основной закон: если вы не можете сказать «нет», значит, вы не в состоянии управлять проектом.

Лучшие ведущие специалисты и руководители команд знают, что всему не вписывающемуся в рамки приоритетов нужно говорить «нет», устанавливая ту же норму и для всей команды.

Простые советы при выполнении проекта:

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

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

Критерии выхода на каждом этапе не должны быть слишком сложными (хотя и могут быть таковыми). Тем не менее, в наборе критериев выхода должны содержаться следующие элементы:

  • Перечень завершаемых работ.
  • Показатели качества, с которым должны быть завершены эти работы (взятые, возможно, из параметров тестовых испытаний, планов тестирования  и технических условий).
  • Перечень необязательных дел, о которых у некоторых сотрудников сложилось мнение, что их обязательно нужно сделать.
  • Перечень всего, чего допускать не следует, даже если у кого-то сложилось иное мнение (санитарная проверка).

Обычно критерии выхода означают, что сделано следующее:

  • Составлены списки технических условий, проектных решений, работ. Как правило, эти списки полезны только как критерии завершения проектирования. Этапы проектирования должны иметь соответствующие критерии выхода независимо от того, какие инструменты или процессы применялись для их выполнения. Возможно, условием выхода их этой стадии станет принятие 90 % общего объема технических условий или создание прототипа с определенной функциональностью.
  • Выполнены текущие работы. Имеется в виду список работ, определенный в начале этапа или фазы проекта. Как только работы будут выполнены в соответствии с требованиями технических условий, этап (фаза) завершится.
  • Подсчитаны все ошибки по уровням их значимости. Ранее уже шла речь о том, что для выявления и оценки значимости ошибок применяется множество различных способов. Обычно критерии выхода включают создание детального описания обнаруженных ошибок конкретного типа.
  • Пройден определенный набор тестов. Определение факта завершения этапа может обусловлено прохождением некоторых тестов. Если результаты тестирования используются в качестве критерия, на их основе принимаются решения о том, какие ошибки или дефекты подлежат устранению до завершения этапа. Возможно, будет вполне достаточно использовать критерии выхода на основе определенного порога прохождения тестовых испытаний, к примеру: «должны быть пройдены 80 % тестовых испытаний по сценариям, относящимся к приоритетам первой очереди».
  • Достигнуты определенные показатели производительности или надежности. Если команда производит замеры производительности определенных компонентов (скажем, базы данных или поисковой машины), то критерии выхода должны быть основаны на ее показателях. Если критерии выхода заключаются в увеличении скорости на 10 % по сравнению с показателями предыдущей версии, значит, этап не может считаться завершенным до тез пор, пока не будет достигнуто 10-процентное увеличение.
  • Потрачено определенное время или деньги. Время является самым простым в мире критерием выхода. Этап завершается по прошествии определенного времени. И все. Лучше всего измерять этап месяцами, тогда не будет никаких сомнений насчет времени его начала, времени окончания и продолжительности. (Ведь меряют же люди остаток своей жизни месяцами и неделями, так почему же не построить на той же основе график разработки проекта?) Все наполовину или частично реализованные характеристики отбрасываются, чтобы учитываться уже на следующем этапе (если он предусмотрен). Деньги тоже могут стать критерием выхода: когда бюджет исчерпан, энергия иссякает, и работа останавливается.

Запомните, что цель заключается не только в том, чтобы уложиться в указанный срок, но и в том, чтобы подвести проект к определенной дате в определенном состоянии. Чем скорее команда поймет, в чем заключается это состояние, тем выше будут шансы на успех. Если критерии известны на ранней стадии, они отражаются на всех решениях, принимаемых в ходе выполнения этапа. Даже если в процессе работы критерии претерпят какие-то изменения, команда будет перестраивать свою работу в едином направлении, дружно подводя проект к легкому эндшпилю.

Представьте себе посадку самолета. Удачное приземление облегчает повторный взлет самолета: крылья на месте, шасси исправно, экипаж жив. Все, что нужно — это дозаправка, план полета и сэндвич для пилота. Завершение этапа должно рассматриваться в этом же ключе. Чем круче закладывается вираж для завершения этапа, тем вероятнее, что по его окончании проект окажется не в самом лучшем состоянии.

К концу этапа люди становятся усталыми, унылыми и раздражительными, что отрицательно сказывается на производительности труда. Сложные и разноплановые ошибки имеют особенность появляться максимально близко к концу этапа. Программист глядит на одну из таких ошибок, понимает, что она не из легких, и под гнетом других навалившихся на него забот сваливает ее на кого-нибудь другого, кого можно назначить ответственным за ее устранение. Как писал Вейнберг (Weinberg): «… проблемы не решаются, а просто переходят их рук в руки». Этому естественному искушению поддаются время от времени даже самые лучшие программисты.

Про отслеживание ошибок:

Возьмите себе в привычку задавать в подобной ситуации следующий вопрос: «Какой номер присвоен данной ошибке?». Если услышите в ответ, что пока никакой, прервите разговор до тех пор, пока ошибка не получит свой номер. Возможно, кому-то это покажется самодурством, но в данном случае такой шаг продиктован интересами проекта.

Серьезность ошибки отличается от приоритета. Например, может быть серьезная ошибка сценария, приводящая к отказу в работе браузера (серьезность 1), но поскольку она проявляется лишь при семикратном наборе в поле ввода почтового адреса на странице регистрации слова «PAPAYA!», причем только прописными буквами, у нее низкий приоритет (серьезность 1, приоритет 4).

Проектная постпрограмма

Поскольку приближается завершение этапа или всего проекта, кто-то должен настроить команду на извлечение уроков из всего только что сделанного. Эту работу часто называют описанием ретроспективы проекта, или постпрограммой. На эти действия наталкивает желание зафиксировать информацию, пока она еще свежа в памяти людей, а когда люди соберутся отпраздновать успех и отложить все дела, им вряд ли захочется возвращаться назад и вспоминать обо всех проблемах, с которыми они недавно имели дело. Большинство людей желает двигаться вперед, оставляя позади свое прошлое. И тут снова на первый план выступает руководитель. Руководитель команды должен внести свой вклад в процесс выполнения постпрограммы. Поскольку дел становится все меньше, руководитель должен попросить людей подумать над тем, что удалось, а что нет, и оформить это хотя бы в виде списков на отдельных листках бумаги. Руководитель проекта должен составить план по сбору этих записей и составлению постпрограммного отчета.

Вот и все. Надеюсь, что проделанный труд принесет кому-нибудь пользу.

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Одноклассники

Скотт Беркун. Искусство управления IT проектами: 4 комментария

  • 18.09.2012 в 12:28 дп
    Permalink

    Александр!
    Спасибо за работу по конспектированию!
    Есть много полезных мыслей по управлению программными проектами.
    Правда, объем поста большой, поэтому вряд ли кто все прочитает полностью;)
    Порекомендовал студентам кафедры САПР и ПК ВолгГТУ ряд материалов Вашего сайта.

    Ответ
    • chavalah
      18.09.2012 в 10:30 дп
      Permalink

      Спасибо за комментарий, Алексей! Будут вопросы, пусть обращаются.

      Ответ
  • 11.10.2012 в 10:34 пп
    Permalink

    Действительно, хороший материал. Для проект-менеджеров (и не только ит-направлений) такая информация очень полезна. Спасибо за статью.

    Ответ
    • chavalah
      12.10.2012 в 12:06 дп
      Permalink

      Спасибо, Дмитрий! Рад, что Вам пригодилось.

      Ответ

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *