Обреченный на успех StartUp. Глава 4
Введение
Наш The Startup со ставками мы оставили в состоянии, когда завершился Чемпионат Мира по футболу - 2018.
Ссылка на предыдущие главы тут
В новой главе нашего цикла вы, дорогие читатели, узнаете о "дворцовом перевороте" против CEO, установлении нетипичного для современного IT процесса и последствиях, которые возникли из-за всего этого.
Бедный CEO, богатый CEO
В предыдущей главе мы познакомились с CEO, большим поклонником Agile-подхода и многочисленных встреч. По доступной нам информации, именно встречи крайне раздражали коллег, потому что мешали им работать работу.
Коллеги, а именно CTO, CPO и арт-директор, имея доступ к телефонным и личным встречам с владельцем бизнеса, пытались донести до него, что CEO не удовлетворяет требованиям классного менеджера и не выполняет свои обязанности.
Когда появится больше достоверной информации о том, что еще смущало коллег в работе CEO, напишем дополнительную главу.
После нескольких месяцев методичного давления владелец бизнеса принял решение уволить СЕО.
Цифры заоблачной суммы "золотого парашюта" для CEO до сих пор известны только трем людям, к которым я не отношусь. Поэтому, без лишних спекуляций, просто примем к сведению, что он не остался обиженным.
Вот так свершился "дворцовый переворот", и первый CEO покинул проект.
Бизнес и его новая дифференцированная команда
После свержения CEO началась новая эра для всех участников проекта. СТО стал фаворитом основателя, арт-директор остался важной, но не основной фигурой в команде менеджеров, а CPO испытывал на себе сложности корпоративной политики.
Бизнес все еще недоволен командой
Показы конечного продукта бизнесу заканчивались скандалами и угрозами увольнения всех, кто был виновен в неудачах демо.
Увольнений не происходило, но все же это было крайне изматывающе!
Будучи внутри, казалось, что вокруг царит хаос, и только ты знаешь, как правильно: "Только так и никак иначе" — ведь это ты придумал.
Все попытки принять решение в одиночку и анализировать проблему, на практике приводили к повторению ситуации или её ухудшению.
Я приведу примеры проблем, которые участники пытались решить в одиночку, а затем попробуем проанализировать, какие заблуждения не позволяли вырваться из порочного круга неудачных демо.
Итак, проблемы и попытки их единоличного решения:
Проблема 1: Бизнес недоволен скоростью разработки и отсутствием понятных сроков.
CTO, пытаясь удовлетворить потребность бизнеса в сроках, озвучивал нереальные сроки, которые не могли быть выполнены.
Проблема 2: Недовольные потенциальные клиенты, которым не хватало всего "одной функциональности".
Бизнес без лишнего промедления после очередной перезентации продукта клиенту отправлял задачу менеджерам, передвигал RoadMap, функциональность разрабатывалась, а клиент всё равно не приходил…
Глобальные заблуждения команды
Давайте попробуем разобраться, какие глобальные заблуждения были у команды и к чему они приводили, кроме озвученных выше проблем.
Первое: команда решает задачи бизнеса
Проблема, возникающая из-за этого заблуждения: разное понимание ролей в команде.
Для команды бизнес был автором проблемы, которую команда, как большой коллективный мозг, должна была решать, а для бизнеса он был мозгом, а команда — руками, то есть исполнителями задач.
Все попытки предложить более оптимальное решение приводили к диалогу: "Я в бизнесе ставок 30 лет, а вы?"
На протяжении примерно двух лет лучшие умы IT-мира занимались поиском оптимальных решений для проблемы, озвученной бизнесом. Но каждое демо заканчивалось вердиктом: "Очень долго делали, и всё надо переделать."
Второе: у каждого есть своя зона ответственности
Внутри IT-команды казалось, что у менеджеров есть свои роли, однако CTO диктовал аналитикам, как писать требования; дизайнер, благодаря особым отношениям с бизнесом, вмешивался в технические решения, а продакт фактически не влиял на приоритеты.
Почему так происходило? На встречах с бизнесом менеджерские роли были формальными: для бизнеса никто не отвечал за конкретную часть продукта, но каждый должен был объяснить, "почему эта фича была сделана именно так, почему за такой срок", чтобы владелец мог найти виноватых и их уволить. Однако, в итоге, никто не нёс ответственности ни за что. Все расходились с новыми задачами и порцией "мотивации".
“Мотивация” - наставления, в которых каждый менеджер, вся команда и конечный результат подвергались критике и стимулировались порцией санкций. Пример красочной мотивации: “Если в следующий раз снова получится плохо, закрою самого сильного бэкендера в кабинете, пока он не перепишет всё, как мне надо…"
Третье: план бизнеса = стратегические цели
Примерно раз в квартал бизнес проводил неформальные встречи с менеджерами, на которых формировался новый список приоритетных задач. Эти задачи подавались как ключевые: их реализация обеспечит полноценный релиз на прод и компания начнет получать ненулевой доход.
Менеджеры на основе этих задач составляли стратегический план — RoadMap на 3–12 месяцев, который представляли команде. Вооружившись этим планом, команда начинала работу.
Однако на следующей встрече с бизнесом (которая могла пройти через месяц или полгода) выяснялось, что:
- часть задач RoadMap уже потеряла актуальность, так как их нужно было реализовать сразу после первого обсуждения, а не спустя месяцы;
- другие задачи откладывались на неопределённое будущее, «когда будет свободное время»;
- приоритет смещался на новые задачи.
Цикл повторялся: команда каждый раз принимала новый RoadMap как устойчивый план, но он неизменно менялся.
Последствия
- Затраты на переделывания: технические решения, подвергавшиеся постоянному изменению, были затратными и не приносили ожидаемого эффекта.
- Гонка приоритетов: пока команда только начинала разбираться с задачами, бизнес уже ожидал готового результата.
- Недовольство и непонимание: бизнес не получал того, что хотел, а команда не имела чёткого понимания истинных потребностей бизнеса.
- Отсутствие роста: новые клиенты не появились, и финансовые ожидания не оправдались.
Заключение
Стало ли лучше, когда команда начала осознавать свои заблуждения? Нет, потому что глобальная проблема — отсутствие открытого диалога — осталась с проектом навсегда.
В следующих главах мы разберем детально проблемы, постараемся проанализировать предложенные командой решения и посмотрим на результаты.
Непрошенный совет
Давайте определять границы ответственности и доверять друг другу. Давайте согласовывать все ожидания заранее.
А главное — давайте постоянно сверять часы, чтобы не пришлось всё начинать сначала.
А специально для тех, кто дочитал и это, здесь я подготовила RoadMap следующих глав (там же можно найти ссылочки на предыдущие), чтобы вы понимали, а что еще захватывающего вас ждет.