ПРИЧИНА ПРОВАЛА ПРОЕКТОВ В Magic Battle Arena мы с партнером привлекли pre-seed раунд с runway на 1 год 2 месяца. Я уже рассказывал об этом: раз, два, три Думали — хватит. Рассчитывали 8 месяцев на MVP, 4 месяца на итерации. По факту 4 месяцев хватило только начать улучшать метрики. Нужно было runway минимум в 2 раза больше. Неверная оценка сроков стала краеугольной ошибкой, которая привела к закрытию компании. А вот смотрите что говорит наука. 🔸Исследование 2019 года: качество кода не при чем В 2019 году исследователи проанализировали 2171 публикацию с 1990 по 2017 год по теме провала ПО. Из них отобрали 68 наиболее релевантных и тщательно изучили. Задача: выявить и ранжировать факторы провала IT проектов. Как думаете, насколько техническое качество кода оказалось важным? 🤓 Insignificant — ничтожно малым. Из 13 выявленных факторов technology illiteracy попала в самый низ. А вот главный фактор: ▫️ Wrong estimation of time and cost — неверная оценка времени и стоимости ▫️ 43 из 68 исследований указали на это как основную причину провала 🔸Другое исследование: откуда берется неверная оценка? Исследователи из Aalto University в 2014 году провели анализ корневых причин 4 случаев провала в продуктовых компаниях. Для каждого кейса строили диаграмму причинно-следственных связей — от 130 до 185 причин. Три основные связи повторялись в 3 из 4 кейсов: ▫️ Weak Task Backlog — расплывчатые требования, неверные приоритеты ▫️ Lack of Cooperation — между отделами теряется информация, нужная для реализации и тестирования ▫️ Lack of Software Testing Resources — менеджмент недовыделяет ресурсы на тестирование И две из трех цепочек как раз проходят через Sales & Requirements. ▫️Расплывчатые спецификации → слабый backlog → неверные приоритеты. ▫️Недостаток коммуникации → потеря информации → разработчики и тестировщики не понимают что делать. Требования — точка, где теряется критическая информация. 🔹На Combat Quest я это ощутил на себе. Настраивал процессы с нуля. В GD-документах постоянно пропускали краевые случаи — альтернативные сценарии использования, граничные случаи, обработку ошибок. Результат: расширение сроков, переработки, выгорание команды 😵 Код был нормальный. Проблема была в том, что мы не прогоняли сценарии использования. ▪️Тут окно нужно добавить — плюс 10 дней. ▪️Там забыли что игра делает мягкую перезагрузку при исключении. ▪️Не учли что игрок в метро и запрос обрабатывается с задержкой. ▪️Где-то просто не прописали полный список фичей и срочно добивали потом. Именно 👆 поток нескончаемых доработок, на моем опыте, в итоге постоянно двигал deadline'ы. 🔸Сначала требования, потом диаграммы В комментариях к статьям про проектирование правильно подмечали — первыми идут требования. Исследования это подтверждают — 43 из 68 указали на размытые требования как корень неверной оценки. Посмотрите на картинку из поста с определением архитектуры — именно видение заказчиков (= требования) формирует описание архитектуры и финальную систему. Модель C4 — система и контейнеры — помогает зафиксировать требования визуально. Показать заинтересованным сторонам что будет построено, какие элементы задействованы, как они связаны. Но диаграмма без требований — просто картинка. 🔻 Потому оч важно выработать привычку: При чтении документов прокручивать варианты, когда что-то идет не по плану. Проговаривать их с командой и закладывать буфер при оценке. Ну или прогонять сценарии через GPT — ТОП вариант 😅 А о том, что должно быть в документе с требованиями — обсудим в следующей статье серии. Ставь 👍 если тебе заходит такого рода контент! #проектирование@UniArchitect