В программировании есть старая шутка, которую приписывают Тому Каргиллу из Bell Labs: первые девяносто процентов кода занимают первые девяносто процентов времени разработки, а оставшиеся десять процентов кода занимают ещё девяносто процентов времени. Смешно ровно до тех пор, пока это не Ваш проект. Потому что в жизни это выглядит так: на каждой встрече Вам говорят «почти готово, процентов девяносто», и так три недели подряд. А потом ещё три.
Я много раз наблюдал эту картину, иногда, признаюсь, изнутри собственных проектов. И пришёл к выводу, что проблема почти никогда не в ленивых разработчиках. Проблема в том, как мы измеряем прогресс. Если измерять неправильно, честные люди будут честно называть неправильные цифры.
Проценты врут, вехи нет
«Готово на девяносто процентов» это оценка ощущения, а не факта. Разработчик сделал основную часть работы, видит, что осталось немного, и называет цифру. Он не врёт. Он просто ещё не знает, что в оставшемся «немного» спрятаны интеграция, которая не заработает с первого раза, крайние случаи, о которых никто не подумал, и правки после показа клиенту.
Поэтому первое правило контроля сроков: заменить проценты на вехи. Веха это не «работа над модулем оплаты идёт», а «оплата картой работает на тестовом сервере, и её можно попробовать». У вехи два состояния: достигнута или нет. Никаких «почти». Её можно показать, потрогать, проверить. Это как станции на железной дороге: поезд либо прошёл станцию, либо нет. Никто не говорит, что поезд на девяносто процентов в Харькове.
Прогресс, который нельзя показать, это не прогресс, а надежда. Измеряйте то, что можно открыть и потрогать.
Ритм контрольных точек
Второе правило: вехи должны быть частыми. Если первая проверяемая точка проекта через три месяца, Вы три месяца летите вслепую. Когда наконец выяснится, что что-то пошло не так, исправлять будет поздно и дорого.
Я предпочитаю ритм в одну-две недели. Каждые одну-две недели должен быть показ работающего результата, пусть маленького. Это дисциплинирует всех. Команда не может месяц делать что-то в стол. Клиент видит, куда движется проект, и может скорректировать курс, пока это дёшево. Менеджер получает реальные данные о скорости, а не впечатления.
Удобно, когда вехи вырастают из декомпозиции проекта. Если Вы читали мою статью про WBS, то знаете, что проект раскладывается на пакеты работ. Вехи ставятся там, где закрывается логически законченная группа пакетов, которую можно показать как результат.
Диаграмма Ганта и критический путь
Диаграмму Ганта многие не любят за то, что она выглядит как бюрократия из прошлого века. Полоски на временной шкале, стрелочки, зависимости. Но у неё есть одно незаменимое свойство: она показывает, что от чего зависит. И из этого вытекает понятие критического пути, цепочки задач, задержка в любой из которых сдвигает весь проект.
Знать критический путь важно, потому что не все задержки одинаковы. Если на неделю опоздала задача, у которой есть запас, проект этого даже не заметит. Если на день опоздала задача на критическом пути, на день опоздает всё. Менеджер, который это понимает, распределяет внимание правильно: следит за критическими задачами как ястреб и не дёргает людей по остальным.
Где держать запас
Любой опытный менеджер закладывает в план запас времени. Вопрос в том, где его держать. Интуитивно хочется добавить немного к каждой задаче: здесь пару дней, там пару дней. Проблема в том, что работа имеет свойство заполнять всё отведённое время, это давно подмечено и называется законом Паркинсона. Если на задачу дали пять дней вместо трёх, она займёт пять. Плюс люди склонны начинать по-настоящему работать ближе к дедлайну, так называемый синдром студента.
Поэтому запас лучше держать отдельно, общим буфером в конце этапа или проекта. Задачи оцениваются честно, без подушек, а буфер расходуется только тогда, когда что-то действительно пошло не так. И скорость расхода буфера сама по себе становится отличным индикатором здоровья проекта: если половина буфера ушла в первой трети пути, пора бить тревогу.
Самое важное: ранние сигналы
Всё перечисленное это инструменты. Но главное в контроле сроков не инструменты, а культура, в которой о проблемах говорят рано. Сорванный срок почти никогда не бывает сюрпризом для того, кто непосредственно делает работу. Он знает о риске за недели. Вопрос только в том, скажет ли он об этом вслух.
Люди скажут, если знают, что за плохую новость их не накажут, а помогут. Если же гонца с плохими вестями традиционно казнят, Вы будете узнавать о проблемах в последний день, когда уже ничего нельзя сделать. Поэтому я всегда благодарю за ранние предупреждения, даже если новость неприятная. Это самая дешёвая информация в проекте.
Что сделать завтра
Посмотрите на текущий проект и замените все процентные статусы на вехи с двумя состояниями. Для каждой ближайшей вехи ответьте: что именно можно будет открыть и проверить, когда она будет достигнута, и когда это произойдёт. Если ближайшая веха дальше чем через две недели, разбейте путь до неё на более мелкие. И на ближайшей встрече с командой спросите не «на сколько процентов готово», а «что мешает дойти до следующей вехи вовремя». Ответ на этот вопрос стоит больше любого отчёта.
