Вовремя и в рамках бюджета. А так вообще, бывает? У меня было ровно один раз. Руководство попросило сделать индивидуальную доработку (кастомный отчёт на Microsoft Reporting Service) прям образцово, чтобы можно было показывать коллегам как пример. Отчего же не сделать? Какими принципами я руководствовался, чтобы это сделать? Какие ходы провёл?
Принцип простой — надо сначала сделать хорошо, а потом искать закономерности. Если сначала написать правила, а потом по ним пытаться создать что-либо, мы получим рабочую модель Прокрустова ложа.
Артемий Лебедев
Ководство, § 178
Менеджер давно в компании. Я тогда работал третий год и детально разбирался, к кому с каким вопросом идти. Это прям основа, без этого ничего не выйдет.
Первичная оценка (пресейл). На входе даём заказчику только порядок цифр, чтобы он принял решение, влезает ли доработка в его бюджет. Тратим на эту оценку буквально три часа. Час созвониться с заказчиком, час подумать и поговорить с разрабом, час оформить. Заказчик на выходе получает небольшую табличку с разбиением трудозатрат по статьям. И всё.
Только после того, как заказчик принял первичную оценку и сказал «делаем», приступил к точной оценке. Или фазе планирования. Оценивают те, кто будут делать. Я сам выступаю в роли аналитика, разработчиком будет опытный чувак, который ранее делал такие вещи. Он же делал первичную.
Сбор требований. Созваниваюсь с заказчиком, выясняю бизнес-проблему, чего он хочет добиться этим отчётом, почему именно на RS. Разбираемся с входными параметрами, показателями, агрегацией итогов.
Прототипирование. Открываю Excel и прям рисую отчёт, максимально приближённый к реальности. Показываю разработчику, он указывает на вещи, которые будет невозможно или трудно реализовать. Ещё несколько раундов созвонов, расспрашиваю разные детали про отчёт.
Написание ТЗ. Максимально аккуратно, «сверху вниз» фиксирую всё собранное в ТЗ. Согласую ТЗ с заказчиком. Увидев ТЗ они добавляют ещё хотелок. Обсуждаю их с разработчиком, вношу в ТЗ. Это был самый длительный этап. Из-за того, что заказчик не спешил, мы созванивались пару раз в неделю по часу-полтора и не спеша формировали ТЗ. Этап вышел месяца полтора.
Точная оценка. Вместе с разработчиком пилим ТЗ на таски, оцениваем эти таски. Получаем чистую оценку разработки. Применяю корпоративные «волшебные формулы», по которым рассчитываю оценку тестирования, накидываю другие накладные затраты. Накидываю время, которое ранее потратил на прототипирование, требования и ТЗ.
Работа с рисками. Накидываю к оценке дополнительные часы на возможные технические трудности (по минимуму, задача понятная), затем на возможные дополнительные хотелки заказчика, которые вылезут в ходе приёмки, чтобы не пришлось пересогласовывать оценку (уже побольше).
Формирую итоговое ТЗ и точную оценку, засылаю заказчику. И только после того, как заказчик мне отвечает на имейл, что согласен, мы рассчитываем сроки с учётом реальной загрузки разработчика.
На этом основная часть работы пиэма-аналитика заканчивается. Нужно мониторить и контролить разработчика в процессе кодирования. Я также провёл приёмочное тестирование, мы немного подправили макет. Отдали в полноценное тестирование тестерам, они пошатали отчёт, нашли ошибки, мы их поправили.
Приёмка. Провели демонстрацию отчёта заказчику. Получили замечания и парочку новых идей, но так как несколькими шагами ранее заложили такие риски, пересогласовывать оценку не пришлось. Доделали, накатили на контуры заказчика.
Разработчик написал пояснительную записку о деталях функционирования отчёта, а я пользовательскую инструкцию. Штатный техпис отрецензировал и навёл на эти документы красоту.
Провели мини-ретроспективу, оценили с командой сложность доработки, определили размер премии, полагающейся разработчику (мне премий не платили, у тестеров своя система мотивации).
Вовремя, с затратами в рамках бюджета. Близко к идеалу. Правда, работает только на небольших проектах. Потом количественные изменения превращаются в качественные, тогда на первое место выходит метод набегающей волны.
К сожалению, в большинстве проектов так не получается. В некоторых компаниях пытаются подменять фазу планирования пресейлом и выкатывать очень точную оценку с дизайном команды и сроками на этапе пресейла. В других забивают на риски, делая оценку вплотную, чтобы смета вышла не слишком дорогой. В третьих проект делает команда людей, устроившихся в компанию две недели назад.
