Документация проекта и быстрый onboarding
Как tech lead должен поддерживать README, Confluence и проектную документацию, чтобы новые разработчики быстрее входили в Python/backend проект?
Короткий ответ
Документация должна отвечать на вопросы запуска, архитектуры, ownership, контрактов, типовых операций и troubleshooting. Ее стоит держать рядом с изменениями и проверять через onboarding новых людей.
Полный разбор
Для backend-проекта минимум документации: как поднять окружение, какие сервисы есть, какие зависимости нужны, где схемы API/event contracts, как устроены миграции, как прогонять тесты и что делать при типовых инцидентах. README должен помогать запустить проект, а более длинные решения можно выносить в ADR или Confluence.
Tech lead отвечает не за "красивую wiki", а за актуальность критичного знания. Хорошая практика - обновлять docs вместе с MR, добавлять checklist для onboarding и регулярно смотреть, где новичок застревает. Если человек не может локально поднять сервис без устных объяснений, это сигнал, что документация не работает.
Для быстро меняющихся проектов полезны owners по разделам и короткие architecture decision records: почему выбрали такой подход, какие альтернативы отклонили и какие ограничения остались.
Теория
Документация снижает bus factor и делает знания команды воспроизводимыми. Она должна быть частью delivery, а не отдельным разовым проектом.
Типичные ошибки
- Хранить критичные знания только в голове senior-разработчиков.
- Писать большую wiki без связи с кодом и релизным процессом.
- Не проверять документацию на реальном onboarding.
Как отвечать на собеседовании
- Назови README, ADR, API contracts и runbook-и.
- Свяжи документацию с MR process и onboarding метрикой.