SRS не нужен: объясняем, почему ТЗ — это прошлый век

SMS? BTS? CMS? SRS!

SRS (software requirements specification, спецификация требований к программному обеспечению) — документ с требованиями к приложению, по-нашему — техническое задание. В эсэрэску входят требования и ограничения по функциональности и производительности SRS составляют для прозрачного взаимодействия заказчика и подрядчика. 

SRS обычно пишут простым «клиентским» языком, потому что и составляется он на основе мнения клиента. Чтобы начать сотрудничество, подрядчику необходимо узнать, чего хочет заказчик, понять желания и бизнес-цели. На основе информации с нескольких созвонов на стороне подрядчика составляют SRS документ.

У SRS документа есть ряд особенностей. 

Структура

Выглядит пугающе. С одной стороны, удобно, когда любой проект можно поместить в понятный шаблон, с другой — есть риск попасть в жесткие рамки, внутри которых пропадет индивидуальность продукта. 

Структура SRS документа включает в себя детальное описание каждой части будущего приложения. Проблема в том, что 90% информации в таком документе — вода; настоящую пользу несут разве что картинки — примеры дизайна и описания работы сложных алгоритмов. Допустим, если бы у Tinder был SRS, то там бы был алгоритм мэтчинга. И еще 37 страниц ненужной инфы.

Структура спецификации требований к программному обеспечению выглядит так:

• Введение
  • Цели 
  • Соглашения о терминах
  • Предполагаемая аудитория и последовательность восприятия
  • Масштаб проекта
  • Ссылки на источники
• Общее описание
  • Видение продукта
  • Функциональность продукта
  • Классы и характеристики пользователей
  • Среда функционирования продукта (операционная среда)
  • Рамки, ограничения, правила и стандарты
  • Документация для пользователей
  • Допущения и зависимости
• Функциональность системы
  • Функциональный блок X (таких блоков может быть несколько)
    • Описание и приоритет
    • Причинно-следственные связи, алгоритмы (движение процессов, workflows)
    • Функциональные требования

• Требования к внешним интерфейсам
  • Интерфейсы пользователя (UX)
  • Программные интерфейсы
  • Интерфейсы оборудования
  • Интерфейсы связи и коммуникации
• Нефункциональные требования
  • Требования к производительности
  • Требования к сохранности (данных)
  • Критерии качества программного обеспечения
  • Требования к безопасности системы
• Прочие требования
  • Приложение А: Глоссарий
  • Приложение Б: Модели процессов предметной области и другие диаграммы
  • Приложение В: Список ключевых задач

Релевантность

Как бы ни хотелось рассказать в SRS документе о преимуществах компании или идеях, которые пришли в голову уже в процессе разработки, делать это запрещено. У документа — четкая цель, а значит, такое же четкое содержание. SRS всегда отражает функциональность и технические характеристики продукта.

Прозрачность

Здесь речь о терминах и языке. Используйте язык клиента, но не переборщите с упрощением, эвфемизмами и литературными приемами. Не стоит писать о волшебном труде мастеров кода и гениальных выдумках повелителей картинок. Лучше быть излишне конкретным, чем двусмысленным. Спецификация требований к программному обеспечению  — не шедевр мировой классики, поэтому даже самые элементарные стилистические правила можно игнорировать во имя ясности.

Точность

Сокращения, аббревиатуры, названия — в документе они должны не должны отличаться. На первый взгляд — мелочь, но поскольку документ носит официальный характер, ошибаться в подобных моментах не стоит. Вот так надо и не надо: 

Рейтинг по важности

Никаких «два пишу, четыре в уме»! Если на исполнение того или иного требования уйдет много времени, стоит поставить для него высокий приоритет. В целом ранжирование требований по важности и стабильности — хорошая идея. Под стабильностью мы понимаем, насколько точно поставили задачу, и придется ли что-то менять в процессе исполнения.

Изменения

И хотя SRS — это документ с жесткой регламентацией, систематически в него можно и нужно вносить изменения. Правда, это не так легко, как кажется — SRS документ далеко не гибкая форма. Больше всего от этого страдают стартапы: в MVP приложения часто нужно вносить правки, а спецификацию требований к программному обеспечению менять забывают. Даже в крупных компаниях, которые любят бумажки и бюрократию, можно часто найти Confluence с документацией 5-летней давности. Зачем делалось? Конечно, для галочки!

SRS в России и за рубежом

За семь лет работы мы заметили, что отношение к SRS документам в России и за рубежом значительно отличается. Пытаемся понять, почему в России так любят бумажки, и как «продать иностранцу дизайн-концепт по цене SRS».

 5 причин отказаться от SRS

Мы в Purrweb не делаем SRS документы. Это принципиальная позиция, от которой мы отступали всего пару раз — напоминаем, что количество наших проектов перевалило за 250. Мы не тратим время на бумажную волокиту и бюрократию и сохраняем ресурсы клиента. Выделили пять основных причин, почему SRS не нужен. 

Время

SRS сожрет ваше время и не поперхнется косточкой менеджера по продажам. Сколько времени уйдет на составление документа? Мы попросили нашего операционного директора оценить эту задачу. Цифры говорят сами за себя:

Все дело в высокой детализации SRS документа. Сбор нужной информации может затянуться — бизнес-аналитикам придется подойти к дизайнерам, разработчкам, тестировщикам, тимлидам. Внутри спецификации требований к программному обеспечению много технических моментов, которые тяжело осмыслить человеку, далекому от разработки. За время, которое тратится на SRS, мы успеваем провести один спринт и прийти к заказчику с первыми результатами. Мы уверены: это лучше, чем бумажка. 

Неэффективность

Как бы хорошо и подробно менеджеры не прописали требования на старте проекта, буквально ВСЁ может пойти не так в ЛЮБОЙ  момент. Так что время + силы, затраченные на составление SRS мягко говоря «не окупятся». Скорее всего, ваши бизнес-аналитики почувствуют себя бесполезными. Из всего документа, на который они потратят 80 часов рабочего времени, клиенту пригодится 15-20%. 

Все остальное в SRS документе — вода, налитая в угоду бюрократии. Такие документы составляют в крупных компаниях для эффекта «создания бурной деятельности» и отчета ради отчета, который в 9 из 10 случаев даже не откроют.  

Не по agile 

SRS не совместим с гибким подходом к разработке. Невозможно смотреть на пустой экран и видеть будущее приложение с точностью до кнопки. Однако методика составления SRS документа утверждает обратное: нужно составить подробный план действий с детальным описанием каждого шага еще до того, как команда приступит к работе.

Подобный подход неплохо мэтчится с моделью Waterfall —  «каскадной разработкой». Особенность ватерфола в том, что все стадии создания проекта идут по порядку. Сначала делают весь дизайн, потом всю разработку, затем все тестируют, и если находят баги, исправляют в уже готовом приложении. Возвращение к предыдущему шагу не предусматривают, поэтому каждый этап важно сделать «на отлично». На наш взгляд, крайне идеалистическая модель. Никакой SRS не спасет от ошибок или срочных задач, которые не предусмотрели в спецификации требований к программному обеспечению.

Так что компании, которые используют agile и SCRUM-методологии, отказываются от SRS документов. Там (и здесь) работают спринтами. Тестирование проходит в конце двухнедельной итерации, поэтому баги находятся сразу. Так разработчику не приходится перелопачивать весь код, чтобы найти поломку.

Такая модель удобна не только для компании разработки, но и для клиента. С agile подходом вы всегда на связи с проектным менеджером, а значит, владеете актуальной информацией по проекту. Не приходится все время обращаться к SRS документу, данные в котором могут устареть на первой же итерации. 

Мы в Purrweb поддерживаем коммуникацию с каждым клиентом, особенно если на проекте специфические условия. Например, в кейсе Headcount у клиента были ограниченные сроки, поэтому он сильно вовлекался в разработку и микроменеджерил все наши шаги. Подробнее про скоростную разработку приложения для финтех сферы читайте тут 👇

Компании разработки SRS не нужен

Откроем страшную тайну: мы бы не пользовались SRS, даже если бы клиент настаивал его подготовить. Документ лежал бы мертвым грузом на рабочих столах разработчиков. Когда нас впервые попросили составить SRS документ, мы просто скачали шаблон из интернета и кастомизировали под заказчика. Спойлер: стартапер этого даже не заметил. Думаем, он его и не открывал. Да и мы не открывали.

Если у вас стартап, то тем более

«А что не так со стартапом?», — спросит владелец стартапа. Со стартапом все в порядке, а вот с SRS документом все еще нет. Пока другой подрядчик будет составлять документ с подробным описанием функциональности будущего приложения, мы уже сделаем первую версию дизайна и покажем его клиенту.   

Purrweb выбирает такой подход исходя из целевой аудитории — у нас это стартапы, которые приходят за MVP (минимально жизнеспособным продуктом). Вместо того, чтобы тратить время и деньги заказчика и наши людские ресурсы на некрасивый SRS, мы предлагаем клиенту сэкономить и сразу начать дизайн.

Работа с клиентом в Purrweb начинается с созвона с аккаунт-менеджером. На звонке мы обсуждаем идею проекта и обещаем клиенту несколько практических результатов (deliverables) нашей работы — концепт, пользовательские истории, структура баз данных. Мы даже не предлагаем составить SRS документ.

Кристина Спиридонова, 
менеджер по работе с клиентами в Purrweb

Почему дизайн — first, расскажем в следующем блоке.

Инсайты из мира разработки и экспертный взгляд на цифровые продукты в нашем Telegram-канале Стартап-пикап.

Подписаться

Вместо тысячи слов: альтернатива SRS

Вместо тысячи слов и десятков страниц ненужной информации мы предлагаем заказчикам подход design first. Это значит, что сразу после того, как мы подтверждаем сотрудничество, начинает работать дизайн-команда. Не бойтесь, дизайнеры не надизайнят «что надо и не надо» — все детали аккаунт менеджер и заказчик обсуждают на созвонах, бизнес-аналитик оценивает стоимость проекта. Мы получаем от клиента антиреференсы, иногда наработки по дизайну — так что всегда есть от чего оттолкнуться.

Почему хорошо начинать с дизайна?

Потому что дизайн — это часть будущего продукта, а SRS документ — всего лишь набор слов, собранный в строгую структуру. 

Ни в одном техническом задании или в спецификации требований к программному обеспечению не получится прописать все сразу. По ходу проекта все может измениться (и 100% изменится) — никто не вернется в ТЗ, чтобы что-то исправить или обновить.

Кристина Спиридонова, 
менеджер по работе с клиентами в Purrweb

Как делаем мы: вместо больших документов прописываем пользовательские истории. По юзер сториз делаем дизайн, на основе дизайна оцениваем разработку, делаем архитектуру и структуру базы данных. И только на этапе разработки делаем небольшой документ — описываем, как работает логика на бэкенде или какой-то сложный алгоритм. Важно: это не официальный документ. Мы можем даже не передать его клиенту, а сделать «чисто для себя» и хранить в readme в репозитории. 

С таким подходом легко вносить изменения на любом этапе. Даже если к концу разработки отвалится, например, админка, которую делали в середине проекта, разработчику ничего не стоит вернуться и все «поднять». И главное — никаких сложных документов, волокиты, бюрократии и прочих страшных вещей из мира отчетов.

Заключение

Мы лояльно относимся к любым хотелкам заказчика: хочет кастомные чат, календарь и видеозвонки? Пожалуйста! Нравится следить за каждым шагом разработки? Без проблем, будем созваниваться чаще. Но если речь заходит о спецификации требований к программному обеспечению, мы до последнего будем предлагать клиенту альтернативные решения. 

SRS документ не соответствует ценностям agile-подхода, не несет пользы клиенту и отнимает как наши, так и его ресурсы. Мы в Purrweb давно делаем все иначе: работаем по SCRUM, не морочим заказчикам голову огромными ТЗ, а разрабатываем понятные интерфейсы с удобным дизайном.

Хотите заказать приложение в Purrweb? Ниже есть форма для e-mail 👇