Заказчик идёт навстречу команде и упрощает требования. Теперь не нужно выводить отчёт на экран, а можно просто обработать данные в фоне и выслать пользователю готовый отчёт в формате PDF. Да, отчёт будет выполняться по-прежнему долго, но приложение не будет выглядеть “зависшим” и им можно объяснить, что происходит. Генерация PDF уже реализована, добавить рассылку по почте можно быстро. Команда быстренько допиливает систему, баг закрыт, все счастливы. Ведь так?
Нет, совсем не так. Мы получили дополнительные требования и реализовали их. Объём работ вырос, бюджет не вырос. Мы проморгали scope creeping. И самое плохое тут, что заказчик не осознаёт, что добавились требования. Ведь он же наоборот, упростил задачу для команды. Как могла его помощь увеличить объём работ?
Ключевое здесь не то, что scope добавился, а то, когда он добавился. Многие, не задумываясь, скажут, что объём добавился, когда заказчик явно предложил заменить отчёт на рассылку PDF. Это не так. Заказчик в тот момент уменьшил объём работ, предложив упрощённое решение. А добавился scope тогда, когда команда начала работу над багом по производительности.
Требований по производительности нет, поэтому баги по производительности сразу оказываются вне рамок проекта. Да, разработчик должен потратить немного времени, чтобы удостовериться, что эта проблема с производительностью не является следствием ошибки кодирования. Но эти затраты невелики и должны покрываться другим важным навыком менеджера, навыком работы с рисками. А вот оптимизация и реализация упрощённых решений должна быть сделана только по отдельному согласованию с заказчиком и за отдельные деньги.
Многим кажется, что такое ведение дел очень агрессивно и нечестно по отношению к заказчику. Мы написали нерабочий отчёт, а потом ещё и требуем дополнительные деньги с него, чтобы исправить явный баг. Но на самом деле подобное отслеживание объёмов работы является показателем высокой квалификации менеджера и уважения к заказчику.
Гораздо правильней прозрачно и заранее объяснить заказчику, что происходит, чем через несколько месяцев сообщить ему, что деньги закончились и нужно ещё. Когда команда начинает несогласованную оптимизацию производительности, она тратит деньги заказчика (или своей компании, тут бывает по-разному). Возможно, эти траты не нужны. Возможно, отсутствие требований по производительности не является упущением, а является следствием продуманной политики заказчика.
Если заказчику сказать, что ускорение отчёта (или даже просто детальное исследование проблемы) будет стоить денег, то, возможно, заказчик выберет оставить отчёт “как есть”. Я видел немало Enterprise систем, в которых отчёты запускались в пятницу вечером с тем, чтобы посмотреть их результат в понедельник утром. Не надо принимать решение за заказчика. Надо дать ему информацию и возможность подумать над проблемой самому.
Бывают менее выраженные ситуации. Например, на демо заказчик принимает экран с парой мелких замечаний, которые разработчик тут же правит. А на следующем демо заказчик смотрит эти исправления, принимает их и добавляет, что он поработал с этим экраном и хорошо бы внести минимальные правки: увеличить пару полей, расширить всплывающую подсказку. А потом через пару недель заказчику хочется добавить текущее время в каком-то другом часовом поясе на этот экран, или выделить пару слов жирным шрифтом, или скрыть пару полей.
Разработчику эти правки не стоят ничего. Он говорит: “Да я их внёс прямо сейчас, пока мы разговариваем”. Оценка на них ровно 0. То есть если даже это и добавленная работа, но это работа с нулевой оценкой. Она же не может влиять на бюджет, правда?
Нет, не правда. Одновременно с радостным замечанием разработчика о том, что он уже изменил экран по просьбе заказчика, можно услышать тяжёлый вздох тестировщика, которому нужно теперь проводить регрессию (хотя бы небольшую) этого экрана. А у него есть более важные, причём заранее запланированные дела. Например, exploratory testing, которое позволяет найти неочевидные и очень неприятные баги и значительно снижает риски. Или автоматизацию тестирования, или обновление тест дизайна. В общем, как раз все те вещи, на которые времени почему-то не хватает, и которые очень снижают риски.
А риски, как мы помним, выражаются в тех же деньгах. То есть если вы, как правильный менеджер, заложили 3 раунда регрессии, а провели всего 2, то это вы не классно сэкономили так бюджет, а увеличили риски. А увеличение рисков – это рост бюджета, они денег стоят. Теперь у вас в проекте есть бомба, которая может сработать и вы вылетите за бюджет. Причём, даже не будете понимать, почему так произошло. Просто сработал риск, бывает.