Важно
Фреймворки для ТЗ или предпроектной подготовки нужны, чтобы понять, какие задачи взять в спринт. Если на стороне клиента подготовили достаточно проработанное ТЗ или расписали спринты до того, как обратиться в Skipp, мы не будем дублировать работу и заново заниматься предпроектной подготовкой. Мы оценим задачу и начнём разработку.
Описание задачи, которое мы используем в Skipp, эволюционирует с каждым проектом. В статье рассказываем, как работаем сейчас: возможно, в будущем мы доработаем подход и будем ставить задачи по-другому.
Была бы интересная статья, если бы не безумная сео заряженность. Бросил читать на середине из-за количества упоминаний названия конторы.
Александр, спасибо, что нашли возможность написать, что вам не зашло.
На тему ТЗ написано тонны материалов, поэтому мы намеренно акцентируем внимание на каждом пункте процесса именно в Skipp, чтобы подчеркнуть, что это наш эмпирический опыт, а не вещание в стиле универсальной истины.
В любом случае информацию приняли, будем учитывать чувствительность к упоминаниям в будущем :)
Забыли про правило #0 — не раздувать ТЗ дальше 1 функции, за которую пользователь и будет платить.
Если в ТЗ больше 1 функции — ТЗ плохое. Если пользователю нет профита от описанного в ТЗ — ТЗ плохое.
Никита, спасибо за мощный комментарий. Добавили UPD в начале статьи с отсылкой на вас.
А есть ссылка на такое исследование на пабмеде?
Тоже интересно про инструменты для анализа. Подписался на статью)
Хорошая статья. Тоже писали про техническое задание, но под специфику разработки мобильного приложения.
И всё-таки главный секрет хорошего ТЗ — хороший аналитик :)