Утопия ФФФ
Почему подход Бюро Горбунова считаю полезным для бизнеса, при этом сомневаюсь в его универсальности. Рассуждаю о функциональности, фиксированных обязательствах и полномочиях проджектов.
ФФФ или FFF (Fix Time, Fix Budget, Flex Scope) — это принцип управления проектами Бюро Горбунова. Они как отче наш поют про фиксацию сроков и бюджета, сохранение качества и уверяют, что при необходимости можно флексить и функциональность.
На первый взгляд, охренительная модель. Бизнес получает предсказуемые расходы и дату запуска, клиент забирает работающий продукт, команда знает ограничения. Весь бизнес обожает ФФФ, и я прекрасно понимаю почему. Когда он работает, это позволяет избежать переносов сроков и функциональности сомнительной ценности. Но у меня накопилось несколько вопросов к практическому применению этого подхода. Особенно в заказной разработке, где условия сотрудничества определяет не исполнитель.
Флексить можно не всё
Главное допущение ФФФ = возможность изменять объём работ без потери основного полезного действия продукта. Для нового сервиса или MVP это разумно: откажемся от второстепенных функций, запустим первую версию и проверим гипотезы на пользователях. Сложнее с корпоративными системами, обязательными интеграциями и функциональностью, что высечена в договоре. Например, система должна передавать данные в государственный сервис, соответствовать требованиям безопасности или обеспечивать конкретный бизнес-процесс. Если убрать обязательное, оставшийся продукт будет бесполезным.
Возникает принципиальный вопрос: кто определяет, чем допустимо пожертвовать? Если решение требует пересмотра согласованного ТЗ, бюджета закупки или критериев приёмки, менеджер не может сам исключить функциональность. Тот же клиент, который прекрасно флексил на предыдущем проекте, может отказаться от этого на следующем.
Условия, о которых удобно забывать
Бюро Горбунова открыто указывает, что работает непосредственно с ЛПР напрямую и не берётся за проекты с несколькими независимыми центрами управления. Это приятно упрощает согласование изменений. В заказной IT-разработке такой возможности может не быть. На стороне клиента присутствуют владелец продукта, IT-директор, служба безопасности, закупки и другие заинтересованные стороны. Решение, которое один представитель готов согласовать за пять минут, у остальных может потребовать недели.
Бюро использует ФФФ вместе с определённой моделью клиентских отношений, но в других компаниях боссы в глубоком вдохновении требуют того же результата без аналогичных полномочий. При этом право выбирать клиентов, менять договорные условия или отказываться от проекта у PM обычно отсутствует. И вот здесь я бы уже обсуждала применимость методологии, а не квалификацию конкретного специалиста.
Фиксированный бюджет
С финансовой точки зрения ФФФ чертовски привлекателен. Фиксированный срок ограничивает продолжительность работ, а гибкий объём помогает сохранить экономику проекта. При грамотной организации выигрывают обе стороны. Но возможность сокращать функциональность необходимо предусмотреть ещё на этапе заключения договора. И желательно определить, кто принимает такие решения, как меняются критерии приёмки и что происходит с исключёнными задачами.
Представим проект с фиксированной стоимостью и небольшой маржинальностью. Оценка оказалась оптимистичной, часть бюджета уже израсходована, а клиент настаивает на первоначальном объёме. При этом пересогласование контракта невозможно без новой закупочной процедуры. Какой бы прекрасной ни была методология, дополнительные ресурсы и деньги она не создаст. Остаются переговоры о пересмотре ограничений, изменение плана или решение на уровне руководства компаний. Всегда можно обвинить проджекта, который не предусмотрел такой сценарий заранее. Но предварительно согласованные условия не гарантируют, что в критический момент клиент будет готов их соблюдать.
Кстати, само бюро признаёт, что предварительное согласие клиента на ФФФ ещё не означает готовности принять конкретный флекс. В их опубликованном разборе конфликта из-за исключённой кнопки оно прямо показывает, насколько болезненным бывает такое решение. А значит, даже при соблюдении исходных принципов переговоры могут закончиться отказом. Это нормальный коммерческий риск, который нельзя автоматически записывать в профессиональные ошибки менеджера.
Где заканчивается ответственность PM
Вот здесь мне не нравится попытка превратить ФФФ в истинный критерий качества проектного управления.
Менеджер обязан контролировать ограничения, предупреждать о рисках, предлагать варианты сокращения объёма и аргументировать последствия каждого решения. Но он не может гарантировать согласие клиента, если тот связан контрактом, внутренними регламентами или объективными требованиями к продукту. Невозможность согласовать флекс ещё не означает, что проджект плохо управляет проектом. Чаще это означает, что для конкретного контракта изначально выбрали неподходящую модель управления.
Мне откликается ФФФ: фиксированные ограничения дисциплинируют, короткие итерации позволяют раньше получать результат, а необходимость выбирать главное помогает избегать бессмысленного разрастания функциональности. Но их применение требует соответствующих условий на уровне бизнеса и договора. Если этих условий нет, требовать от менеджера исполнения всех принципов ФФФ уже полная хрень.
Это моё субъективное мнение
У Бюро Горбунова и Николая Товеровского есть обучение проектному управлению, которое я так и не прошла, ну то есть я не претендую на знание всех нюансов этой практики. Но опубликованных принципов достаточно, чтобы обсуждать ограничения применения метода в заказной разработке. Если эту статью прочитает Артём Горбунов, Николай Товеровский или кто-нибудь из коллег бюро и захочет меня переубедить, найдите меня по имени и фамилии, с удовольствием отвечу и обсудим. От бесплатного обучения, разумеется, отказываться не стану.
Флексить функциональность — отличная идея. Но вместе с ней флексить договорные обязательства получается редко. И это уже антиутопия, которую мы видим ежедневно.
Сверим показания
Я показала статью опытным коллегам из других агентств. Все они не первый год работают с заказной разработкой. Ниже анонимные мнения спецов, которым регулярно приходится принимать подобные решения на собственных проектах. Список будет пополняться.
За все годы сколько работаю, везде была такая схема, но честно, мне ни разу не удалось довести ее до конца, потому что я не имею власти над всеми переменными, которые возникают в процессе.
Мне всегда казалось, что это слишком странный метод ведения экономики. На бытовом примере: пришел в магазин, говоришь: мне то, мне сё, мне пятое и десятое. Продавщица говорит: с вас тысяча рублей. Забирает и скрывается под прилавком. А дальше у нее не оказалось того, осталось лишь половина сего, пятое какое-то немножко не такое, как я хотел, но десятое идеальное. А тыщи уже нет.
ФФФ требует четко распределенной зоны ответственности и стоимости за конкретику. то есть фактически: Этап 1 — обязательно, Этап 2 — обязательно, Этап 3 — нужно конкретно вот. Эти 35% обязательно, остальное опционально. Этап 4 — опционально. И тогда Исполнитель честно говорит: вы нам рубль, а мы вам этап 1, 2 и 35% 3-го, но если вдруг останутся силы/время/бюджеты (все лимиты не сожрет клод), мы вам и остальные 65% наваяем, и 4 этап сделаем, и бантик привяжем. Только сразу согласуйте ПМИ, в которых не будет всего того, что мы вам не обещаем железно. Тогда можно контрактоваться и делать.
А еще проблема этой экономики в том, что нельзя изменить вообще все, как например в ТМ. Заказали велосипед, потом попросили из него сделать мопед, а велосипеду уже сделали раму без возможности закрепить там бензобак. Мой любимый формат это фикс бюджет — фикс скоуп, отход от согласованного через ДС или расстрел. Если я заложил и согласовал 10 часов разработчика на кнопку, а он сделал за 8, то мы эти два часа не будем завязывать бантик, скорее всего их либо съест другая работа, либо в конце концов пива куплю себе на эти деньги .
Я менеджерка проектов. Пишу о работе с клиентами и командами, делюсь опытом и наблюдениями.