Новое Распределяем каналы MAX по категориям и территориям. Читать новость
Загружаем изображение…

⭐️ Идеальная задача



Лучшее начало недели — это идеально поставленная задача! 🚀

Составила общий чек-лист, что спросить у заказчика нового документа. Можно скинуть ему перед встречей или попросить заполнить онлайн, а затем обсудить.

Для небольших задач пунктов будет значительно меньше, но в любом случае всегда остаётся формулировка по SMART, плюс добавляются другие требования в зависимости от контекста.

1️⃣ Цель и содержание


* Какой тип документа нужен? (Инструкция, описание функциональности, спецификация и т. д.).
* Зачем нужна документация? Какую проблему решает или какой процесс описывает?
* Как мы поймём, что проблема решена? По каким критериям будем оценивать результат?

2️⃣ Аудитория и формат

* Для кого пишем? (Разработчики, клиенты, поддержка, юристы).
* Куда это поедет? Документация внутренняя или будет передаваться вовне?
* Где опубликуем? (Confluence, публичный сайт, сайт партнёра, FAQ).
* А если не публикуем? Как будем передавать и в каком формате?
* Нужен ли перевод? На какие языки и для какого масштаба аудитории?

3️⃣ Жизненный цикл и поддержка

* Документ разовый или требуется регулярное обновление?
* Как техписатели будут узнавать об изменениях в продукте, чтобы поддерживать актуальность?
* Как пользователи узнают об изменениях в продукте и документации?
* Есть ли влияние на другие доки?

4️⃣ Детализация и референсы

* Что хотелось бы видеть внутри? Опиши желаемый образ результата, структуру. Если есть примерное понимание или референсы — приложи их.
* Нужно дополнить FAQ?

5️⃣ Сроки и этапы

* Когда нужно отдать черновик на согласование?
* Когда deadline финальной версии?
* Что делаем, если сроки горят? Какой MVP документа?
* Какие есть риски по срокам? От чего зависим, кого ждём и где можно это отследить?

6️⃣ Ревью и консультации


* Кто должен проверить документ перед публикацией? (Разработчик, PM, редактор, дизайнер, тестировщик, юрист, PR, ИБ и др.).
* Кто сможет консультировать техписателя? Как часто и в каком формате?
* Кого нужно оповестить об изменениях кроме ЦА, например, смежные подразделения?

7️⃣ Технические ресурсы


* Есть ли доступ к тестовому стенду или репозиторию?
* Какие исходные материалы уже есть (тех. решение, спецификации, макеты)?

8️⃣ Контекст продукта, если о нём пока мало информации

* Название и направление (B2B, B2C, IT2IT).
* Стадия разработки.
* Основные функции и назначение.

🎯 В результате должна появиться задача по принципу SMART

__S__pecific (конкретная),
__M__easurable (измеримая),
__A__chievable (достижимая),
__R__elevant (актуальная для бизнеса),
__T__ime-bound (ограниченная по времени).

💡 Пример

Написать пошаговую инструкцию для сценария первичного платежа с примерами и UML-диаграммами. Опубликовать в Confluence (раздел «Платежи»). Первый черновик показать разработчику. После согласования отдать на ревью PM и техподдержке. После их согласования — опубликовать.

Срок готовности черновика: 10.04.26
Deadline публикации: 15.04.26

За консультациями обращаться:
Тестовый стенд и доступы:
Полезные материалы:
Просмотры: 17
Открыть в MAX Сообщить о неточности

Сообщить о неточности

Опишите, что нужно исправить. Если есть источник, добавьте ссылку.

Вы покидаете datool.ru

Ссылка ведёт на внешний сайт. datool.ru не отвечает за его содержимое — проверьте адрес, прежде чем вводить пароли или платёжные данные.

Переход через 10 с

Перейти