ГЛАВА ПЯТНАДЦАТАЯ

СТРАТЕГИЯ ЗАВЕРШАЮЩЕГО ЭТАПА

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

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

То, как вы берете ноту, не менее важно, чем то, какая это нота.

Генри Кайзер

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

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

Хуже того, придется выплачивать проценты: соотношение времени на восстановление и времени на максимальные усилия не составляет 1:1. На восстановление требуется больше времени, чем на то, чтобы выложиться по максимуму (например, если хотите догнать поезд, придется бежать максимально быстро, но недолго, всего 20 секунд, а чтобы восстановить дыхание после этой погони, понадобится не меньше минуты.) Иногда приходится жертвовать личной и семейной жизнью, а это противоречит долгосрочным интересам индивида, команды и организации ().

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

БОЛЬШИЕ ДЕДЛАЙНЫ — ЭТО ВСЕГО ЛИШЬ НЕСКОЛЬКО ВТОРОСТЕПЕННЫХ ДЕДЛАЙНОВ

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

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

Рассмотрим три основные точки пересечения на любом этапе.

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

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

КАК ОПРЕДЕЛИТЬ КРИТЕРИИ ЗАВЕРШЕНИЯ

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

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

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

Как правило, критерии завершения охватывают следующие моменты:

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

Без критериев завершения команде придется зависеть от субъективного мнения, а это чудовищная трата времени. Каждый по-своему понимает, что значит «достаточно хорошо». Даже если один человек вправе принимать это решение, без ориентировки на конкретные требования всегда будут возникать споры.

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

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

Примерный список критериев завершения по рабочему этапу небольшого проекта:

• выполнить рабочие элементы 1–10 в соответствии с их специфика­циями;
• выполнить 80% задач по простоте использования по приоритету № 1;
• пройти все автоматизированные и ручные тесты по приоритету № 1;
• пройти 80% автоматизированных тестов по приоритету № 2;
• провести триаж всех активных ошибок;
• исправить все ошибки приоритетов № 1 и 2;
• получить одобрение отдела маркетинга и бизнес-команды.

ПОЧЕМУ УЛОЖИТЬСЯ В СРОК — ЭТО КАК ПОСАДИТЬ САМОЛЕТ

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

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

«Угол снижения»

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

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

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

1. Изменить график. Передвинуть конечную дату, чтобы отразить новое понимание темпов работы.
2. Изменить угол. Каким-то образом убедить себя, что можно работать больше и быстрее и наверстать упущенное время (например, подготовиться к аварийной посадке). Можно, конечно, попытаться, но у всего есть своя цена. Возрастет риск ошибок, и в начале следующего цикла команда будет вялой и уставшей.
3. Завершить этап как есть. Подумайте, по каким функциям или рабочим элементам осталось больше всего работы или какие из них связаны с наибольшим риском. Либо распрощайтесь с ними, либо отложите на следующий этап, либо снизьте планку качества и выпустите их такими как есть (сглотните).

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

Почему «изменение угла» не сработает

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

ПОЧЕМУ СТАНОВИТСЯ ХУЖЕ

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

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

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

СХЕМАТИЧНЫЙ ПЛАН КОРРЕКЦИИ УГЛА ПОДХОДА

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

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

ЭЛЕМЕНТЫ ОЦЕНКИ

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

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

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

ПОВСЕДНЕВНАЯ СБОРКА

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

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

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

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

УПРАВЛЕНИЕ ОШИБКАМИ И ДЕФЕКТАМИ

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

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

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

• Приоритет. Чем он проще, тем лучше. Приоритет № 1 — нужно исправить. Приоритет № 2 — исправим по необходимости. Прио­ритет № 3 — желательно, но маловероятно. Приоритет № 4 — до смешного невероятно.
• Опасность. Насколько серьезна эта ошибка? Опасность 1-го уровня — утеря данных, системный сбой или нарушение надежности. Опасность 2-го уровня — важные функции не работают, как ожидалось (должны быть обозначены критерии). Не путайте опасность с приоритетом — эти понятия отличаются. К примеру, ошибка сценария может поломать браузер, и это опасно (опасность 1-го уровня). Но если такое происходит, только когда вы набираете слово «ПАПАЙЯ!» семь раз большими буквами в поле электронной почты на странице регистрации, то приоритет низкий (опасность 1-го уровня, но приоритет № 4).
• Кому поручено. Все ошибки следует поручить одному человеку. Можно создать псевдоним для новых ошибок, однако одна из целей триажа (о котором мы вскоре поговорим) — поручить ошибки определенному сотруднику как можно раньше. Чтобы ошибки поступали из альфа- и бета-релизов, создайте группу под названием «Активные» или «Вечеринка», куда можно их направить. Эти ошибки можно сначала триажить, а потом поручать реальным людям.
• Воспроизведение (копия). Последовательность действий, которая позволяет кому-то другому воспроизвести ошибку. Это, вероятно, самое важное поле. Плохие сценарии воспроизведения — пустая трата времени команды, они вынуждают программистов вкладывать больше сил, чем необходимо для поиска ошибки. У качественных ошибок короткие и простые шаги воспроизведения .
• Область. В крупных проектах ошибки следует классифицировать по месту их происхождения в проекте (по области). Это позволяет отслеживать их по компонентам, а не только по разработчикам.
• Кто нашел. Имя и контактные данные человека, нашедшего ошибку.
• Статус. Ошибка должна иметь всего четыре статуса: активный, исправленный, решенный и закрытый. Активный — значит, что ошибка еще не исправлена и находится на рассмотрении. Исправленный — программист считает, что он устранил ошибку. Однако решенной ошибка становится, только когда нашедший ее сотрудник подтверждает, что ошибка устранена, или соглашается отложить этот вопрос. Закрытая ошибка означает, что тестовая команда подтвердила ее кончину.
• Как решен дефект. «Решенность» ошибки означает, что она уже не активная. Это можно сделать несколькими способами: исправить, отложить на следующий этап или релиз, воспроизвести или вообще не исправлять.
• Тип. Есть два важных типа ошибок: дефекты и регрессы. Дефект — это старая добрая ошибка. Регресс — это ошибка, которую уже исправили, но она снова всплыла как негативный побочный эффект других изменений.
• Триаж. Это поле показывает, рассмотрели ли ошибку и отсортировали и каковы результаты. Иногда исправлять нужно только те ошибки, которые были отсортированы и одобрены. Итак, в этом поле обычно три группы: одобрено, отвергнуто и на рассмотрении.
• Название. Все ошибки следует сопроводить кратким описанием (всего одно предложение), чтобы любой человек при необходимости мог получить базовое представление о сути проблемы.

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

ГРАФИК АКТИВНОСТИ

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

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

1. На какие вопросы можно ответить, глядя на сделанный график?
2. Как ответы на эти вопросы помогут завершить проект вовремя с нужным качеством? Как помогут выполнить конкретные критерии завершения или задачи проекта?
3. Если цифры растут, что это значит? А если они снижаются? Или остаются неизменными?
4. В конце каждого дня или недели как это поможет нам понять, насколько мы приблизились к цели?

Чем проще, тем лучше

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

• Активные ошибки. Общее количество активных ошибок, которые еще не исправили.
• Входящие. Общее количество ошибок, выявленных в конкретный день (до триажа).
• Исправленные. Общее количество ошибок, устраненных в конкретный день.

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

ОЦЕНКА ТРЕНДОВ

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

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

ЭФФЕКТИВНЫЕ МЕТОДЫ ОЦЕНКИ ОШИБОК

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

• Скорость исправлений — то есть с какой скоростью команда исправляет ошибки. Поскольку не все они одинаковы, здесь имеется в виду время, необходимое для исправления ошибки средней сложности. Если скорость исправлений меньше скорости поступления и нужно исправить все входящие ошибки, есть опасность, что вы так и не закончите проект: новые ошибки будут всегда.
• Соотношение входящих и одобренных. Сколько новых ошибок нужно исправить из числа тех, что не дублируют другие ошибки и не являются приоритетом № 3 или 4? Зная соотношение входящих и отфильтрованных ошибок, можно оценить количество неотфильтрованных. В целом их качество должно снижаться со временем: скорость поступления ошибок приоритета № 1 и 2 замедлится. Но по скорости входящих ошибок определить это невозможно.
• Время активных ошибок. Среднее время активности ошибок. Оно показывает быстроту реагирования команды и уровень ее возможности справиться с такой рабочей нагрузкой. Время реагирования возрастает по мере приближения к дедлайну, потому что команде приходится исправлять меньше ошибок. Она должна более агрессивно триажить и атаковать входящие дефекты. Низкое время реагирования говорит о том, что сотрудники заняты.
• Количество ошибок на разработчика. Чтобы сбалансировать нагрузку разработчиков, нужно отслеживать, сколько активных ошибок обрабатывает каждый из них. Кроме того, стоит отметить, какой процент активных ошибок поручается разработчикам, тестировщикам или МП. Ошибки, порученные двум последним категориям, не входят в конвейер, и их нужно периодически триажить.
• Коэффициент чувствительности системы (fault feedback ratio, FFR). Вайнберг называет скорость регресса, вызванного исправлением ошибок, коэффициентом чувствительности системы . Если каждое исправление ошибки порождает две дополни­тельные, FFR составляет 2,0. Согласно Вайнбергу, FFR в размере 0,1–0,3 — приемлемый уровень; если показатель выше, то нужно пора­ботать над качеством (и / или снизить темпы). Большинство баз данных позволяют связывать новые ошибки с существующими, то есть отслеживать FFR. Однако я никогда не видел, чтобы данный процесс был автоматизирован — это всегда субъектив­ное суждение тех, кто проводит триаж по проекту. (Обратите внимание, что иногда исправление одной ошибки может выявить другие, скрытые. Это не следует учитывать в FFR.)

ЭЛЕМЕНТЫ КОНТРОЛЯ

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

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

ОБЗОРНОЕ СОВЕЩАНИЕ

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

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

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

Обзоры клиентов

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

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

ТРИАЖ

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

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

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

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

Ближе к завершающему этапу, когда каждое решение по ошибкам подвергается тщательному рассмотрению, по всему проекту нужно провести общий триаж. Его целесообразно поручить основной группе лидеров команды (рис. 15.8; мы обсудим это в разделе ). А сейчас важно определить два основных типа триажа: ежедневный и целевой.

Ежедневный и еженедельный триаж

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

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

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

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

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

Целевой триаж

Целевой триаж — выполнение конкретной задачи. Его проводят в дополнение к ежедневному триажу. Целевой триаж позволяет на уровне проекта осуществлять прогресс и улучшать качество графика ошибок и анализа трендов. Перечислим основные причины целевого триажа.

• Когда соотношение отсортированных и активных ошибок низкое. Если у вас 500 активных ошибок, а триаж прошли всего 200 из них, невозможно оценить значимость оставшихся 300. Они все могут быть приоритетом № 1 (системным сбоем) или все могут быть «двойниками»: у вас нет ни малейшего представления. Целевой триаж направлен на то, чтобы устранить все неотсортированные ошибки к определенному времени (к полудню завтрашнего дня). Если это хроническая проблема для команды, нужно поставить цель — никаких активных неотсортированных ошибок старше, чем определенный период времени (24 часа).
• Когда критерий завершения меняется. Если лидеры команды решили изменить критерии завершения, триаж — единственный способ подтянуть проект к этим изменениям. Новые критерии завершения обычно используют как способ изменить угол снижения, исключая из рассмотрения определенные виды ошибок, чтобы повысить безопасность угла (снизив при этом качество).
• Много незакрытых ошибок. Когда ошибка исправлена, ей можно присвоить статус «решено» и отправить нашедшему на одобрение. Определенный процент этих ошибок наверняка исправлен некорректно. Если они остались незакрытыми, у вас набирается целая группа ошибок, нуждающихся в исправлении, но не указанных в списке активных ошибок. В зависимости от вашей системы баг-трекера ошибки могут скрываться и в других местах. Периодически нужно наседать на команду, чтобы она занялась чисткой.

ОПЕРАТИВНАЯ ГРУППА

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

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

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

Команду следует заранее предупредить о том, как и когда будет задействована оперативная группа. На рисунке 15.9 показана основная схема — какие темы требуют ее одобрения. Цель — организовать по­степенную централизацию полномочий с публичными датами, которые показывают эти перемены. Одобрение DCR — зачастую первый шаг оперативной группы, потому что это можно сделать на раннем этапе, еще на «середине игры». Позже, когда нужно жестко отслеживать количество ошибок, одобрение на их поступление на конвейер программистов становится прерогативой оперативной группы (ранее одобренные ошибки становятся унаследованными). Наконец, в заключительные недели или дни оперативная группа анализирует все входящие ошибки и централизованно контролирует проект.

Собрания оперативной группы можно сначала проводить раз в неделю, а затем перейти на ежедневный получасовой или часовой формат. Задача группы — проследить, чтобы эти собрания начинались и заканчивались вовремя (кто-то должен определиться с повесткой собрания до его начала). Если ваша цель — принять грамотные решения в соответствии с критериями завершения и задачами проекта, можно проанализировать множество DCR и провести триаж множества ошибок за 60, а то и 30 минут. Секрет в том, чтобы избежать микроменеджмента — частого явления на завершающем этапе.

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

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

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

КОНЕЦ «КОНЦА ИГРЫ»

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

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

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

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

• Период времени без открытия новых ошибок. Когда количество активных и одобренных (оперативной группой) ошибок достигает нуля, говорят, что команда дошла до этапа работы без открытия новых ошибок (zero bug bounce, ZBB). Однако как только появится очередная ошибка, статус команды изменится. Есть несколько теорий относительно дистанции между ZBB и релизом продукта, но ни одна из них не обоснована настолько, чтобы уделить ей здесь внимание.
• Все ошибки решены. Разрешенные ошибки могут скрывать проблемы, о которых команда и не подозревает. Пока ошибка не будет закрыта (и подтверждена), нет уверенности, что ее исправили так, как нужно. Если все ошибки решены и активных ошибок нет, то проект близок к завершению.

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

КАНДИДАТ НА РЕЛИЗ (КР)

Первый билд проекта, соответствующий всем критериям завершения, называют кандидатом на релиз. Как только он будет готов, нужно добавить новый критерий завершения: какие проблемы, найденные в этом КР, станут основанием для создания второго кандидата на релиз? Если критериев нет, то есть КР прошел все проверки и тесты на качество, билд отправляется в сеть или на CD и доставляется клиенту.

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

В мире программных продуктов, особенно «коробочного ПО», кандидаты на релиз — дорогое удовольствие. Часто проводятся дополнительные тесты и процедуры, через которые должен пройти билд, чтобы проверить настройки, локализацию, брендинг и другие вопросы. Для сетевых продуктов все зависит от того, как данный проект интегрируется в другие. Возможно, есть сложное дерево зависимостей, с которым предстоит разобраться.

ОКОНЧАТЕЛЬНАЯ ВЕРСИЯ И ЭКСПЛУАТАЦИЯ

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

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

РАЗБОР ПОЛЕТОВ

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

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

Имеет смысл нанять профессионала, который проведет для вас итоговый анализ (или пригласить сотрудника из вашей организации, но из другой команды) . Он проведет неделю, интервьюируя членов команды, и составит отчет по собранной и отфильтрованной информации. Это даст объективный взгляд, так как приглашенный консультант заметит и озвучит то, что не заметили другие . А главное — привнесет свое экспертное мнение применительно к потребностям конкретного проекта или команды.

ПОРА ПРАЗДНОВАТЬ

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

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

РЕЗЮМЕ

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

УПРАЖНЕНИЯ

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

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

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

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

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

Е. Осталось два дня до выпуска масштабного обновления вашего нового сайта, которым пользуются миллионы людей. Шампанское уже ждет. И вдруг разработчик обнаружил серьезную проблему, устранение которой займет три дня. Но $10 млн на рекламу конкретного дня запуска уже потрачены. Что вы будете делать?

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

З. Представьте: вы только что выпустили самый важный программный продукт в истории Вселенной. Фото вашей команды попало на обложку журнала Time, и вы стали знамениты. Как вы это отпразднуете? Сколько денег потратите? Где устроите мероприятие? Теперь вернемся к вашему сегодняшнему проекту. Это наверняка лучший релиз программного продукта в вашей компании: разве команда не заслуживает особого праздника в честь такого достижения?

Отправить