#кейс_стади
Разбор с СEO, вайбкодом и Едрит

Многие ответили на задачу с позиции мидл-менеджера: провести ретро, спросить архитектора, поправить процессы, не лезть в чужую работу. Но CEO здесь вообще в другой позиции. У него сорван крупный контракт, под риском следующий рейз, потеряно доверие к инженерным оценкам и появился контрпример. Его задача быстро вернуть управляемость

Первое
Показать свою ветку CTO и поставить задачу ее опровергнуть. И не с позиции "я сделал лучше вас", а "вот решение, которое по моей текущей оценке закрывает то же самое за две недели 1 человеком". Можно остановить менее важные задачи, подключить сильных инженеров и прогнать тот же набор проверок. Если решение развалится -> отлично, CEO получит конкретные причины, чего он не понимал. Если после недели допила оно сравнимо -> вопрос становится очень неприятным

Второе
CTO должен объяснить не код, а управленческое решение. Что из вот этого platform наворота было еально необходимо для Дастархана, что строилось на будущее, кто принял вообще сравнивал варианты и какая экономика у них. Критичный бизнес-дедлайн был известен заранее. Если инженерка сознательно обменяла его на красивую платформу, бизнес должен был участвовать в этом решении, а не узнать о последствиях через пять месяцев

Третье
С этого момента подобные решения принимаются иначе. Есть жесткое внешнее ограничение -> CTO приносит несколько вариантов со сроками, рисками и стоимостью: быстро закрыть потребность, сделать нормально, строить платформу. Какой риск купить -> решает CEO. Архитектура не существует отдельно от экономики, особенно когда на другой стороне контракт и инвестиционные деньги

Четвертое
CTO должен принести отчет, причем не нейрослоп HTML-бандл от клодкода, а понятные 2 странички с хронологией проекта, где были проблемы, что для них делали и почему не уложились в сроки. Отдельно информация как им управляли и контролировали. По отчету станет прозрачно осознавал ли техдир важность проекта и делает ли менеджмент в компании полезную нагрузку

Отдельно меня удивило, сколько людей вообще начали обсуждать, правильно ли CEO втихаря вайбкодит и должен ли он лезть в работу разработчиков. Это взгляд из своей профессиональной колокольни. В условиях кейса CEO уже вайбкодит, уже достаточно погружен и получил новую информацию о собственной компании. Спорить с условиями задачи вместо принятия решения -> уходить от самой задачи. Тем более я постоянно общаюсь с C-level продуктовых компаний и это уже совсем не экзотика, когда даже фаундер собирает себе что-то

И дальше самое важное -> реакция CTO. Ошибка в архитектуре допустима. Сорванный срок тоже иногда допустим. Недопустимо, когда критичный для бизнеса срок сорван, последствия воспринимаются как данность, альтернативное решение никто не хочет проверять, а объяснение заканчивается на вам не понять разработку. Если CTO сам разбирает ситуацию, показывает где ошибка CEO и меняет систему -> доверие можно восстановить. Если защищает статус-кво -> я бы ставил CTO испытательный срок