4 недели, $5500, CRM-система для автосервиса с 10-15 пользователями, и неясные требования на старте. Начал с минимального функционала: учёт заявок, расписание приема, интеграция с календарем. Заказчик хотел быстрый результат, но не уточнил, как обрабатывать приоритеты заявок, через цвета, иконки, или отдельные поля. В итоге три недели ушло на уточнения, потому что я не потребовал письменное ТЗ. Ошибся в оценке времени на интеграцию с системой оплаты, считал 6 часов, реально ушло 32.

80% успешных проектов начинаются с четкого техзадания. Теперь всегда требую его в Notion, с разделами: «цель», «пользователи», «сценарии», «ограничения». Завершаю проекты на 25% быстрее. Все, что не укладывается в задачи, становится источником срыва сроков.

• Плюсы: высокая прозрачность, прозрачные цели, четкие сроки, прозрачные ожидания
• Минусы: риск переоценки объема, зависимость от качества ТЗ, риск недопонимания в коммуникации

Использование GitHub вместо email-пересылки кода повышает доверие в 2,3 раза, это не шутка. Показал публичный репозиторий, и заказчик сразу почувствовал стабильность. Плюс: разработчики с GitHub-портфолио получают на 40% больше заказов. Я уже три года веду свой паблик, и это реально работает

Средняя продолжительность проекта, 3–6 недель. Мой был в середине диапазона. Удаленка, нормально, но без регулярных статус-обновлений, провал. Даже если все идёт по графику, надо писать раз в три дня. Иначе начинается сомнение.

Результат: проект завершен, заказчик доволен, повторный заказ, в планах. slon2 to подходит, но только при условии дисциплины и четкого ТЗ.

Вопрос–ответ

• Почему такой проект оказался рискованным? Из-за отсутствия технического ТЗ и неопределённых требований, что привело к переработке на 30% и срыву графика.
• Как избежать подобного? Требовать чёткое ТЗ, фиксировать требования в письменном виде, использовать этапы прототипирования

slon2 at