Раскрыть

SPL
Как читают Feature Description?

Каждая категория пользователей может почерпнуть из требований полезную информацию для себя. И поэтому очень важно иметь в виду, что требования будут читать разные люди
● Разработчики — Им важно знать, зачем нужна фича, какой вопрос она решает. Для того, чтобы не тратить потом время на исправления, разработчикам нужно предоставить полный список всех сценариев, а также обратить внимание на Corner cases. Если вовремя сообщить разработчику о том, что мы потом добавим, например, платежи картой МИР, он сможет предусмотреть эту возможность на уровне архитектуры. Таким образом, можно значительно сократить затраты, избежав переделок.
● Тестировщики, QA — Ожидают от вас получить данные о частотности сценариев, чтобы проверять в первую очередь самые критичные. Также им важны четко описанные Corner Cases. Для проверки нужно указать различия сценариев в зависимости от локализации, а также четко определить все пределы — максимальную длину имени, максимальное количество машин в заказе и т.д. Для инженеров нужно описать реакцию на возможные внешние изменения (пользователь переключился, вышел, закрыл окно) и принять базовое состояние для работы приложения. Это необходимо, чтобы не сломалась логика бизнес процесса. Также очень важны требования к производительности и отказоустойчивости.
● DevOps и Datacenter Operations— Им нужно знать, с какими компонентами работает продукт, какая инфраструктура для него требуется, сколько ресурсов будет использовать софтом от серверных мощностей. DevOps должны знать, какие метрики мониторинга важнее других, как убедиться, все ли работает с их стороны
● Технический писатель — Он должен четко понимать, какая проблема может возникнуть у пользователя, и как ее решить. Поэтому писатель тоже будет изучать сценарии использования, частотность сценариев, характеристики мокапов и тексты ошибок.
Если вы пишете требования к разработке, обязательно задайтесь вопросом — кто ваш пользователь, что он делает (или может делать), в каких условиях находится. Создайте схему его поведения, она поможет описать все аспекты требований.
При составлении документа нужно быть максимально краткими и не оставлять непонятных мест. Requirements в любом случае будут занимать несколько страниц. Его должно прочитать много человек, и нужно чтобы он был читабельным.
Руководствуйтесь простым правилом: начинайте с главного и только потом добавляйте детали. Кроме этого нужно получить обратную связь от QA, Developers, DevOps и других заинтересованных лиц. Скорее всего, Feature Description обрастет новыми деталями после общения со стейкхолдерами.
Постарайтесь подумать над неочевидными сценариями. Желательно сразу определить, что должно делать ваше приложение в нештатных ситуациях. Подумайте, какие внешние компоненты влияют на вашу фичу. А когда все уже будет готово, еще раз задайтесь вопросом: “Что еще можно протестировать кроме шагов, описанных в пользовательских сценариях?”
Заключение
В следующем материале мы поговорим о бизнес-плане и ценообразовании для нового продукта.
А пока делитесь в комментариях вашим опытом работы с требованиями, как со стороны менеджера, так и исполнителя. Расскажите, был ли в вашей практике пример, когда функциональный заказчик хотел одного, а в итоге получилось совсем другое из-за непонимания?
→ Видео-запись всех лекций курса доступна на YouTube
Лекция про дорожную карту и требования для разработки:
Извините, данный ресурс не поддреживается. :(
===========
Источник:
habr.com
===========
Похожие новости:

• [Карьера в IT-индустрии, Управление персоналом, Читальный зал] Почему 97% программистов 1С мало платят и так будет всегда
  
• [IT-эмиграция, Карьера в IT-индустрии] Германия, или Туда и Обратно — 3
  
• [Data Mining, Big Data, Визуализация данных, Управление проектами, Управление продуктом] Анализ расписания и загрузки в Tableau
  
• [Конференции, Информационная безопасность, Резервное копирование, Антивирусная защита] Безопасность, автоматизация и сокращение издержек: Виртуальная конференция Acronis о новых технологиях киберзащиты
  
• [Карьера в IT-индустрии, Учебный процесс в IT] Действительно ли в России вырос спрос на инженерные специальности?
  
• [C++, Учебный процесс в IT, Карьера в IT-индустрии] CRM, мессенджер и штрих-коды: продолжаем рассказывать об учебных проектах Технопарка
  
• [Карьера в IT-индустрии, Мозг, IT-компании] Планка найма для инженеров: что это за зверь? (перевод)
  
• [Карьера в IT-индустрии, IT-эмиграция] [Личный опыт] Работа в Uber в Амстердаме: как устроена разработка, карьерный рост, подготовка к интервью
  
• [Управление проектами, Управление продуктом] Пользовательские истории – это не требования
  
• [Программирование, Учебный процесс в IT, Карьера в IT-индустрии, Конференции] Бесплатные онлайн-мероприятия по разработке (15 сентября – 23 сентября)

Теги для поиска: #_karera_v_itindustrii (Карьера в IT-индустрии), #_razvitie_startapa (Развитие стартапа), #_upravlenie_produktom (Управление продуктом), #_upravlenie_razrabotkoj (Управление разработкой), #_acronis, #_mfti (МФТИ), #_product_management, #_upravlenie_produktom (управление продуктом), #_menedzher_produkta (менеджер продукта), #_trebovanija (требования), #_requirements, #_blog_kompanii_acronis (
Блог компании Acronis
), #_karera_v_itindustrii (
Карьера в IT-индустрии
), #_razvitie_startapa (
Развитие стартапа
), #_upravlenie_produktom (
Управление продуктом
), #_upravlenie_razrabotkoj (
Управление разработкой
)