Comments 6
Как показывает практика, лучшие решения появляются на стыке двух и более подходов. Перекладывая на документацию (ИМХО) - круто, когда писателя подключают на двух этапах:
Согласование ТЗ от аналитика. Писатель узнает изначальную проблему, предложенное решение, а также ревьюит макет от дизайнера. Можно вовремя заметить кривой воркфлоу и непонятные названия кнопок (в случае, если нет UX-писателя).
Внутренняя приемка. Писателю не стоит вовлекаться в весь процесс разработки - слишком времязатратно. Но так как в середине проекта что-то могут поменять, эти изменения здорово заметить на этапе приемки, когда разработчики демонстрируют результат аналитику и PO. Тогда и у разработчиков будет время что-то исправить, и у писателя оценить объем своей задачи.
Интересно, а как это в confluence оформлять без доп плагинов?
На проекте изначально планировалось сделать основу приложения за небольшие сроки, выпустить и расширять уже по отзывам и требованиям. В небольшой команде с давящими сроками документацию отбросили, как трату ресурсов. Когда проект стал заметно разрастаться и документация стала уже необходимостью, идею ввести хотя бы минимальное документирование все равно не поддержали, как трату времени. И сейчас при попытке ввести в команду нового человека, приходится на коленке все расписывать и рассказывать :(
Лучше сразу писать и снимать короткие видео, иначе потом knowledge transfer превращается в попаболь.
Типичные модели, которые я встречал,
@Bright_Translate, автор оригинала — женщина Sarah Moir. Почему тогда глагол в мужском роде?
В остальном — интересный и полезный перевод, спасибо.
Как эффективно добавлять документацию при разработке продукта?