Тема доклада
Как не бесить разработчика своей аналитикой?

Тезисы доклада
1. Лаконичность и структура
- Не пишите ТЗ как «Войну и мир»
- Используйте шаблоны*и логичные блоки.
- Убирайте «воду», повторения и общие фразы.
- Перед отправкой перечитывайте ТЗ на предмет логики и противоречий.
2. Конкретика вместо «и так понятно»
- Избегайте размытых формулировок
- Прописывайте негативные сценарии: ошибки, пустые массивы, отсутствие данных.
- Фиксируйте все устные договорённости.
- Учитывайте производительность: кэши, индексы, пагинацию.
3. Не диктовать, а обсуждать
- Не превращайтесь в диктатора с позицией «только так и не иначе».
- Слушайте разработчиков.
- Привлекайте команду к обсуждению технологий и архитектуры.
- Критика решения — нормально.
4. Управление изменениями
- Не вносите правки «тихо» и после старта разработки.
- Не добивайте логику по кусочкам и не добавляйте хотелки «заодно».
- Сразу уведомляйте о любых изменениях.
- Присылайте, что именно поменяли

5. Не перекладывайте ответственность
- Не отвечайте «не знаю, реши сам» — это безразличие.
- Глубже погружайтесь в логику и детали.
- Повышайте техническую грамотность, чтобы учитывать особенности реализации.

О себе
6 лет работал в роли Java backend разработчик
2 года в роли системного аналитика