В 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