Один кейс. Два автора. Две правдыСегодня мы решили немного поэкспериментировать вместе с Алексеем Поперлюковым,
автором «Цифрового барреля».
Взяли один спорный IT-кейс и договорились посмотреть на него с разных сторон. Алексей — глазами руководителя и заказчика. Я — глазами Customer Success и поставщика.
И заранее договариваться, кто из нас прав, не стали :)
Итак. Проект провален. Версия поставщика. Срок — 9 месяцев. Бюджет — 500 млн рублей. Через год система не запущена. Бюджет вырос на 35%.
Алексей говорит: профессиональный поставщик должен был вовремя остановить заказчика.
Если требования убивают проект — скажите «нет». Если новая интеграция меняет сроки — предупредите. Если невозможно сохранить одновременно сроки, бюджет и объём — заставьте заказчика выбрать.
Звучит справедливо. Но здесь я хочу добавить важную деталь. За 9 месяцев заказчик
47 раз существенно менял требования. И это не означает, что поставщик просто молча принимал всё в работу.
Каждый существенный change request мы формировали отдельно и выносили на операционный совет.В нём показывали, что именно изменилось и как это влияет на проект. И дальше возникала вполне понятная управленческая развилка. Если новые требования нужно реализовать
в первоначальные сроки — нужны дополнительные ресурсы, а значит, потребуется увеличение бюджета. Если бюджет остаётся прежним — нужно увеличивать сроки. То есть в какой-то момент выбор становится довольно простым:
либо деньги, либо время, либо отказ от новых требований.И здесь, думаю, многие узнают знакомую enterprise-реальность :)
В крупной компании бюджет проекта — это не цифра, которую можно просто взять и поменять в любой момент, ведь он заложен в годовые планы, проходит бюджетный цикл…. Поэтому, «давайте просто увеличим бюджет» — это не решение, которое можно принять на уровне проектной команды. Но и менять срок проекта заказчик заказчик также не готов. В результате возникает классическая ситуация:
новые требования появляются, а исходные бюджет и срок остаются зафиксированными.И именно в этот момент change request должен становиться не просто документом, а предметом управленческого решения. Но ни один из этих change request-ов так и
не был принят к рассмотрению на управляющем совете.
Знакомо? :)
А на одном из совещаний прозвучала фраза:
— Мне неинтересно слушать, почему вы не можете. Вы за это деньги получаете. Приходите не с проблемами, а с решениями.
И далее самое интересное.
Алексей пишет:
«Если нужно — скажите мне “нет”. Я именно за это вам плачу».А я отвечу:
«Нет» тоже должен быть готов услышать заказчик.За три месяца до запуска руководитель проекта со стороны поставщика уже понимал, что срок практически нереален. Но красный статус не поставил.
Ошибка? Возможно. Но он пытался добиться управленческого решения теми инструментами, которые у него были.
А если на каждый сигнал команда получала
«Мне неинтересно слушать, почему вы не можете. Вы за это деньги получаете
», — то возникает вопрос: что изменит ещё один красный статус?
Если система не готова принять решение, красный цвет сам по себе проект не спасёт.И в какой-то момент это перестало быть ошибкой одного руководителя проекта и стало результатом отношений между заказчиком и поставщиком.
Вот поэтому
Customer Success для меня — не про то, чтобы всегда соглашаться с клиентом. И не про то, чтобы просто сказать ему «нет».
Это про создание условий для настоящего партнёрства. Чтобы заказчик и поставщик работали как единая команда. Поэтому, для меня главный вопрос этого кейса:
в какой момент заказчик и поставщик перестали слышать друг друга?Я бы не стала искать виноватого только по одну сторону стола. Алексей считает, что сильный поставщик должен уметь остановить заказчика. Я считаю, что сильный заказчик должен создать условия, в которых его действительно можно остановить.
И, кажется, именно между этими двумя утверждениями чаще всего и проваливаются большие IT-проекты.
Теперь ваша очередь. Кто всё-таки провалил проект?
Заказчик — 👍
Поставщик — 🔥
