Документация и виды требований

На прошлой неделе организаторы Flow начали выкладывать доклады с весенней конференции и начали с Сожгите ваши системные требования. Пользовательские требования — ключ к успешному продукту. Когда-то я писала об этом докладе в посте с впечатлениями о Flow

Тема документирования завела меня в список недавно отмеченных статей на близкие темы. Делюсь статьями и мнением

📍Как писать требования и документацию к проекту. Полный гайд с шаблоном документации и примерами заполнения Автор поясняет, что это статья в помощь начинающим. Всегда интересно посмотреть примеры чьих-то задач, здесь это как раз есть: примеры документов и как они заполнены. К этой статье мне не хватило пояснения к процессу производства, на каких шагах и для какой аудитории рождаются эти документы. Если вы делаете первые шаги в анализе, то учитывайте, что в статье изложена не общая практика, а подход конкретной команды

📍Нужно ли писать документацию? Это в основном сторителлинг с описанием сценариев, когда даже не самая лучшая документация может сберечь время команды. Не думаю, что опытные аналитики найдут что-то новое, описаны известные боли

📍Технические задания и IT-системы: разбираемся, как ожидания мэтчить с реальностью Еще один пример опыта конкретной команды, где информацию оформляют в некоей смеси каркасного макета и слайдов презентации. Не советую считать такой формат гарантией полного понимания требований всеми участниками, тем не менее в индустрии такие варианты встречаются. Мне приходилось в таком участвовать и получать нечто похожее на согласование

📍Уж послала, так послала: словосочетания-паразиты в технических текстах и 17 вредных советов для тех, кто проверяет документацию и технические тексты Две статьи одного и того же автора о стиле высказываний в комментариях и текстах технической документации. Местами выглядит перфекционизмом, но мнение интересное

#что_почитать