Без числа «до», подписанного клиентом, число «после» остаётся заявлением. Track снимает тот единственный замер, по которому судят всю работу.
Содержание5 разделов
Вопрос, на который обязан отвечать любой результат автоматизации
По сравнению с чем?
Вопрос скучный, и почти ни один результат на него не отвечает. Процесс теперь идёт четыре часа. Раньше он шёл - и тут фраза обычно замедляется, потому что старое число никто не записал, и следующую цифру назовут по памяти люди, которым хотелось бы, чтобы проект сработал.
Это не жульничество. Так устроена память. Спросите кого угодно, сколько раньше занимала задача, и получите ту версию, которая запомнилась ярче всего, то есть худшую.
Что меряет Track
Четыре вещи на процесс, и не больше, потому что базовый замер из двадцати метрик никто не будет ни поддерживать, ни защищать.
- Время цикла от момента, когда работа входит в процесс, до момента, когда выходит.
- Пропускная способность в неделю, включая проходы, которые бросили.
- Доля ошибок, определённая как работа, которую пришлось переделать, а не работа, которая кому-то не понравилась.
- Стоимость прохода по полной стоимости часа, а не по окладу.
Окно замера должно быть достаточно длинным, чтобы в него попала плохая неделя, и выбирают его до того, как увидели данные.
Подпись
Подписывает клиент, а не подрядчик.
Это единственный этап, на котором нужна подпись, и причина у этого конкретная. Число «до» от стороны, которую по нему будут судить, - это переговорная позиция. Подписанное клиентом, оно становится неподвижной точкой, из-за которой число «после» что-то значит, причём в обе стороны: подрядчик не подправит его вниз, когда результат разочарует, а клиент не подправит вверх, когда захочется истории получше.
А ещё подпись заставляет договориться, что считать успехом, ровно тогда, когда ни одна сторона не знает, понравится ли ей результат.
Что ломается без этого этапа
Работа всё равно идёт. В этом и проблема.
Сборка запускается, новое время цикла настоящее, а улучшение считают от числа «до», собранного задним числом. Квартал все довольны. Потом кто-то в финансовом отделе спрашивает, как считали окупаемость, ответ упирается в величину, которую никогда не измеряли, и в эту секунду весь результат становится непригодным - не обязательно неверным, но непригодным, а для решения о капитале это одно и то же.
Арифметика, обосновывающая сборку, не лучше своего первого слагаемого. Track и есть первое слагаемое.
Место Track в протоколе
Track - третий из шести этапов, и он работает, только если процесс сначала стабилизировали; почему - в тексте зачем замораживают границы. Следом из измеренного процесса удаляют лишние шаги, пока их не зашили в код, а почему аудит вообще идёт раньше сборки, объясняет текст аудит процессов до автоматизации.
Часто задаваемые вопросы
Почему базовый замер подписывает клиент, а не подрядчик?
Потому что подпись и есть весь механизм. Число от той стороны, которую по нему потом будут судить, - это не измерение, а переговорная позиция, и все в комнате это понимают, даже когда вслух не говорят. Когда подписывает клиент, разом достигаются две вещи: подрядчик не сможет тихо подправить число «до» вниз, когда число «после» разочарует, а клиент не сможет подправить его вверх, когда для совета директоров понадобится история получше. Кроме того, подпись заставляет провести разговор, которого большинство проектов избегает, - что считать успехом, - ровно в тот момент, когда ни одна из сторон ещё не знает, понравится ли ей ответ.
А если процесс слишком нерегулярный, чтобы измерить его за две недели?
Тогда окно удлиняется, или этот процесс был плохим первым кандидатом. Некоторым процессам действительно нужен квартал, чтобы показать своё распределение, и сверка на закрытии месяца - очевидный пример: измеренная в первой половине месяца, она выглядит пустяком, а если окно захватывает конец месяца, оказывается совсем другой работой. Правильная реакция - удлинить окно для этого процесса, а не выбрать удобные две недели и назвать их типичными. Если из-за удлинения сборка уезжает так далеко, что перестаёт окупаться, это настоящий вывод о порядке работ, а не повод померить плохо и пойти дальше.
Зачем намеренно включать плохую неделю?
Потому что автоматизации предстоит справляться с исключениями, а базовый замер, снятый на чистой неделе, измеряет ту версию процесса, которая никогда не доставляет хлопот. Деньги теряются не там, где всё идёт гладко, а в проходе, который пришёл без заполненного поля, в клиенте, ответившем в неожиданном формате, в согласовании, пролежавшем два дня, потому что согласующий был в поездке. Окно, из которого всё это выброшено, даёт льстивое число «до» и, что хуже, техзадание, написанное под процесс, которого не существует: так и получается процесс, работающий на демонстрации и отваливающийся на второй неделе эксплуатации.
Пригодится ли базовый замер, если проект не состоится?
Да, и это сделано намеренно. Базовый замер в письменном виде остаётся у клиента, независимо от того, будет ли сборка. Это тот документ, который делает следующую попытку дешевле, кто бы её ни вёл, потому что дорогая часть любого проекта автоматизации - выяснить, как работа движется на самом деле и во что она сейчас обходится, а не написать код, который двигает её иначе. Он же даёт клиенту точку отсчёта, по которой можно спросить и со следующего подрядчика. Если консультант считает свои замеры внутренними рабочими материалами, он тем самым сообщает вам, для чего собирается их использовать.
