оформляете ТЗ для разработчиков в вашем продукте?
Интересует как формат (будь-то файл/презентация prd/doc/...), так и содержание документа (основные разделы/требования: как они сформулированы? Текст или визуализация? Какие требования чаще всего выкладываете?)
Буду очень благодарен! Очень ннада )🙏🏻
Привет. Описываю задачу в CRMке внутренней. Мы про каких разработчиков речь ведем? Из 1000 видов. Для мобилок одно, для сайтов другое, для бэка третье
Задачей в джире - какая проблема, зачем делаем, что делаем. Разработчики достаточно профессиональны, чтобы я им не писал какую строчку кода куда нужно вписать и когда какую ручку дернуть.
https://docs.google.com/document/d/1FvnnZAdaNkKwEXu4PrQRAvO0BKPn2LtHk76-QiYioRY/edit?usp=sharing
Добрый вечер. Я оформляю ТЗ в Notion. Как коллеги уже ответили для разных разрабов разные ТЗ. Однако всегда определяется цель, из нее следуют задачи, тут в помощь идут UserStory. Далее выписываются функциональные/нефункциональные требования (какой триггер, как часто, для каких пользователей срабатывает та или иная ситуация) для более подробного объяснения добавляются блок-схемы (UML, BPMN, последовательности). Если ты считаешь, что информации много, лучше данное ТЗ закрепить объясняя разработчику на созвоне.
Не оформляем. Фиксируем только что-то важное, чтобы не забыть. Разработчики участвуют в проработке, поэтому хорошо в теме того, что надо сделать.
У нас в команде пока лучший вариант - делать это вместе в паре с техлидом. Техлид сильно помогает конкретно сформулировать что хочет продакт и сразу переведет на язык архитектуры и железа. Огромный плюс работы в паре, что сразу можно понять где ТЗ ушло в нереализуемые фантазии🗿 Если под рукой техлида нет, то сильно помогают блок-схемы, чтобы избежать неправильного толкования текста. Обычно круто заходит работа в FigJam. Мы там строим UML-ки, храним референсы, скриншоты, ссылки. Одна доска - один проект
Задача начинается с процесса discovery: 1. Описываю ключевую идею (story) 2. Перечень стейкхолдеров 3. Боль (какую боль решаем) 4. Гипотеза 5. Эксперимент все этапы 6. Метрики, аналитика 7. Критерии успешности 8. User story Job story Уже на этапе discovery со мной работает системный аналитик. При передаче, если есть фронт прикладываю макеты, к ним пояснения. Описываю подробнее пользовательский путь. Передаю в delivery системному аналитику и продуктовому аналитику. Системный описывает задачу для разработки, продуктовый готовит ТЗ на логирование и дизайн АВ теста. На проектирование сразу берём спринт (у нас 10 дней) Далее когда всё готово передаем в разработку, можем ещё с разработкой синкануть всё ли ясно по бизнес логике.
у вас тайм ту маркет - год?)
Имхо слишком много времени теряется на аналитиков
Они параллельно работают, а не последовательно. Спринт зафиналить, описать, передать это не много
А как часто вам приходится переделывать продукт потому что "заказчик хотел не совсем это"?
Тут еще вопрос это продукт в топ 10 приложений в стране?)
М. Тогда в чем у вас отличие в процессе? Я просто процесс описанный выше вижу верным, потому как финалить требования до разработки правильнее и дешевле, чем потом переделывать. Как у вас?
ахринеть, прям по методичке. я думал в жизни такого не бывает. Накидал примерно так, как на картинке, с другой стороны колбаса полезла)))
По методичке гораздо больше всего, это оптимизированный 😃
Обсуждают сегодня