A можно без ТЗ? Пишем идеальную заявку в студию разработки
«Сделайте сайт, который будет приносить 10 баксов в день» — с такой просьбой к нам пришел клиент, когда Purrweb еще не было, а наши пуррбоссы, Саша и Антон, работали как кооператив фрилансеров. Больше деталей не было. И, знаете, иногда такой запрос лучше, чем ТЗ на 75 страниц.
Хороший вопрос. Понимание бизнес-задач помогает предложить решение, а уже потом оценку.
Часто заказчики приходят с ТЗ, которое не решает их бизнес задачи -> в итоге получается продукт по ТЗ, но не очень полезный :)
Это не наш подход: мы понимаем, вникаем и предлагаем, исходя из общего контекста. При таком раскладе, мы можем предложить решение по функциональности (как реализовать) сами.
К примеру, есть задача - оптимизировать временные затраты сотрудников на обоработку заявок. Клиент уже на старте вбрасывает ТЗ с кучей фич, которые эту задачу не решат и только увеличат стоимость продукта. Если мы уже на старте оценим проект по "хотелкам", то получится астрономическая сумма. Что получим на финише: расстроенного клиента и проект, который так и не стартовал.
Понимая задачи бизнеса, мы можем просчитать, какие инвестиции в разработку будут соразмерными. Можем управлять бэклогом: отсеивать лишнее, стартуя лишь с тем, что напрямую решает задачу и помогает быстрее окупить вложения. Именно по этой причине, мы погружаемся в контекст на старте и не кидаемся оценивать #всечтодали.