Календарная дата нужна заказчику, производству и самой инженерной команде. Но за ней должны стоять определённый результат, последовательность работ и понятные условия. Иначе испытания, закупки и повторное изготовление превращаются в неожиданности, хотя являются частью разработки.
Представим разговор о новом электронном устройстве. Заказчик спрашивает, когда оно будет готово. Разработчик отвечает: «К концу месяца». Кажется, стороны договорились.
В назначенный день на столе действительно лежит работающая плата. Однако заказчик ожидал изделие в корпусе, с документацией и подтверждёнными характеристиками. Разработчик имел в виду первый образец, на котором ещё предстоит проверить основные решения. Дата совпала. Ожидаемые результаты — нет.
Это одна из причин, по которым срок разработки нельзя содержательно описать единственной записью в календаре. Назначить дату можно. Чтобы управлять её достижением, нужно понимать, что именно должно быть завершено, от чего это зависит и какие вопросы ещё остаются открытыми.
Сначала договориться о значении слова «готово»
У разработки несколько важных результатов: согласованные требования, проверенная концепция, изготовленный прототип, завершённые испытания, подготовленная документация, установочная партия. У каждого — свои критерии завершения.
Работающий макет может подтвердить принцип действия, но не пригодность конструкции к длительной эксплуатации. Полученный комплект плат позволяет начать сборку, однако ничего не говорит о результате будущих испытаний. Подготовленная спецификация не означает, что все позиции уже закуплены.
Поэтому срок полезно связывать с проверяемым событием. Например: изготовлены образцы определённой версии, выполнена согласованная программа испытаний, оформлены результаты и устранены замечания, препятствующие передаче. Конкретный состав зависит от задачи.
Без этого стороны могут добросовестно обсуждать разные объёмы работы. Один планирует закончить проектирование, другой — начать эксплуатацию. Чем позже обнаруживается разница, тем меньше времени остаётся на её устранение.
Часы работы и календарное время — разные величины
Инженер может оценить корректировку схемы в несколько часов. Но готовое устройство появится после того, как изменения попадут в плату, плата будет изготовлена, доставлена, собрана и проверена.
В календарном сроке участвуют и действия команды, и ожидание. Причём ожидание может быть связано с необходимой работой: производственным циклом подрядчика, доставкой комплектующих, доступностью испытательного оборудования или рассмотрением технического решения заказчиком.
Предположим, программная часть готова раньше, чем поступили платы. Это полезный результат, но проверить все взаимодействия программы с реальным устройством пока невозможно. Команда может продолжать доступные проверки, однако часть вопросов останется до сборки.
Поэтому оценку трудоёмкости нельзя автоматически превращать в дату делением часов на количество сотрудников. Дополнительный специалист поможет там, где работу можно разделить или где не хватает компетенции. Его появление само по себе не сократит уже согласованный производственный цикл подрядчика.
Хороший календарный план отражает зависимости
Сам по себе календарный план не противоречит реальному процессу. Его задача как раз состоит в том, чтобы показать этот процесс: какие работы идут одновременно, что должно завершиться до начала следующего этапа и какие ресурсы нужны в определённый момент.
В GAO Schedule Assessment Guide среди основ надёжного расписания названы полнота состава работ, их логические связи, доступность ресурсов, оценка длительности и анализ рисков. Руководство также предусматривает обновление прогноза по фактическому ходу выполнения и сохранение утверждённого базового плана для сравнения.
Важен и критический путь — последовательность работ, определяющая ближайшую возможную дату завершения в принятой модели расписания. Если задерживается работа на таком пути, без компенсирующих действий сдвигается и результат. При изменении условий критический путь может измениться.
Для команды это означает необходимость искать конкретное ограничение. Если завершение проекта сейчас зависит от получения специального разъёма, ускорение подготовки презентации не приблизит сборку. Если всё оборудование доступно, но решение по интерфейсу не согласовано, закупка дополнительного инструмента не устранит эту задержку.
Общая просьба «работать быстрее» становится полезной только после ответа на вопрос: какую именно зависимость нужно изменить?
Испытание может открыть следующий цикл работы
Испытания нужны для получения данных о свойствах устройства. Их результат заранее не гарантирован. Может подтвердиться правильность решения, а может обнаружиться необходимость изменения схемы, программы, конструкции или условий применения.
В руководстве NASA по системной инженерии проектирование описано как взаимосвязанный итерационный процесс: требования и решения уточняются, пока не достигается их согласованность с ожиданиями и ограничениями проекта. Возможность возврата к предыдущим решениям входит в логику разработки.
Предположим, испытание выявило проблему в электронной плате. На внесение изменений нужно два рабочих дня. Это ещё не означает, что через два дня появится проверенное исправленное устройство.
В условном примере весь цикл выглядит так. Все значения иллюстративные, этапы выполняются последовательно, необходимые компоненты доступны.
| Этап | Длительность, рабочих дней |
|---|---|
| Корректировка схемы и платы | 2 |
| Изготовление и доставка новой платы | 10 |
| Сборка и первичная проверка | 2 |
| Повторные испытания и оформление результатов | 3 |
| Итого | 17 |
Два дня на исправление превращаются в семнадцать дней до завершения повторной проверки. В конкретном проекте числа будут другими, но учитывать необходимо всю цепочку. Возможное совмещение операций должно быть технически обосновано.
При этом любой повторный выпуск нельзя автоматически объявлять нормой и переставать разбирать причины. Одно дело — проверка новой технической гипотезы. Другое — перепутанные соединения, которые можно было выявить предусмотренным контролем до заказа платы. В обоих случаях срок меняется, но управленческие выводы различаются.
Закупки начинаются с инженерных решений
Пока ключевой компонент существует только в спецификации, его доступность остаётся условием плана. Нужно выяснить, подтверждена ли поставка, в какой комплектации придёт заказ и что произойдёт при невозможности получить выбранную позицию.
Замена недоступного компонента может затронуть посадочное место, питание, программное обеспечение или методику проверки. Даже если подходящий аналог найден, это не всегда завершает работу: его применимость ещё требуется подтвердить.
Проверять такие зависимости полезно до окончательного выпуска документации. Это не означает, что всё следует немедленно покупать. Ранний заказ также несёт риск: конструкция может измениться. Решение принимают с учётом срока поставки, вероятности изменения и стоимости неиспользованных деталей.
В плане должны быть видны не только обещания поставщиков, но и действия самой команды: когда сформирован заказ, кто подтвердил его размещение и к какому этапу нужны материалы. Ожидание поставки и ещё не отправленная заявка — разные ситуации.
Изменение требований меняет предмет обещания
Просьба добавить один канал измерения выглядит небольшой, пока рассматривается отдельно. Но для устройства она может означать новый разъём, изменение платы, переработку корпуса, дополнительные функции программы и расширение испытаний.
Поэтому изменение требований нужно оценивать по затронутым работам. Важно понять, какие результаты сохраняют силу, какие придётся пересмотреть и повлияет ли это на завершение проекта.
Не всякое изменение обязательно сдвигает конечную дату. Часть работ можно выполнить параллельно, часть укладывается в предусмотренный резерв. Но вывод об отсутствии влияния должен иметь основания, как и предложение переноса.
Полезно отдельно фиксировать исходный объём и согласованные дополнения. Тогда обсуждение срока опирается на содержание работы. Заказчик видит последствия нового пожелания, а разработчик может показать, где изменился объём и почему требуется повторная проверка.
Целевая дата и прогноз отвечают на разные вопросы
Целевая дата показывает, когда результат нужен бизнесу. Текущий прогноз показывает, когда он может быть получен при имеющихся данных, ресурсах и оставшихся работах. Их расхождение требует решения.
На раннем этапе прогноз может быть диапазоном с указанными допущениями. Например, отдельно рассматриваются варианты с успешным первым циклом испытаний и с повторным изготовлением. По мере закрытия технических вопросов оценку уточняют. Если появляются новые риски, диапазон может и расшириться.
В руководстве GAO анализ рисков расписания используется для оценки вероятности завершения к определённой дате и необходимого временного резерва. При этом любая такая оценка зависит от исходных данных и модели; произвольный процент уверенности не делает обещание обоснованным.
Резерв имеет смысл связывать с рисками: возможной доработкой, неопределённостью поставки, доступностью лаборатории. Обычные, заранее известные работы следует включать в план непосредственно. Резерв не должен скрывать отсутствующие этапы.
Если прогноз выходит за целевую дату, обсуждают конкретные варианты: дополнительный ресурс на ограничивающем участке, изменение последовательности, согласованное сокращение объёма первого выпуска или пересмотр срока. Исключение необходимой проверки означает изменение подтверждённого уровня готовности — это нужно прямо учитывать в решении.
Неопределённость не отменяет ответственности
Разработка действительно содержит неизвестное. Но этим нельзя одинаково объяснять любой перенос.
Неожиданный результат корректно подготовленного эксперимента, несвоевременный заказ деталей и отсутствие решения по давно известному вопросу требуют разных действий. В одном случае нужно пересмотреть техническую гипотезу, в другом — исправить организацию закупок, в третьем — обеспечить принятие решения.
Для разбора полезно сохранять исходный план, текущий прогноз и причины изменений. Простое переписывание даты лишает команду возможности понять, где оценка была обоснованной, где не хватало информации, а где работу организовали плохо.
Отчёт о ходе проекта тоже стоит связывать с результатами. Фраза «готово на 90 процентов» мало помогает, если оставшаяся часть включает ещё не проведённое испытание, способное потребовать изменения конструкции. Информативнее назвать, что уже подтверждено, что препятствует следующему этапу и когда появятся данные для уточнения прогноза.
Что должно стоять рядом с датой
Обоснованное обещание срока включает как минимум пять вещей:
- конкретный результат и критерии его готовности;
- последовательность зависимых работ и доступность ресурсов;
- статус закупок и условия выполнения внешних работ;
- существенные риски, допущения и предусмотренный резерв;
- ближайший момент пересмотра прогноза по новым данным.
Для небольшого проекта это может быть короткий документ. Его ценность определяется тем, помогает ли он принимать решения до того, как наступила обещанная дата.
Срок становится управляемым, когда команда может объяснить, какой результат будет получен, на каких основаниях рассчитана дата и что способно её изменить. Одна запись в календаре такой информации не содержит.
