С чем не хочешь столкнуться на новом проекте

С чем не хочешь столкнуться на новом проекте

Как System Analyst с 10+ летним опытом, я выделил основные проблемы, которых желательно избежать на новом проекте. Это не просто пожелания, но реальные источники провалов проектов.

1. Отсутствие ясных требований

Это самая частая проблема.

Проблемы:

• Stakeholders неясно представляют что хотят
• Requirements документация отсутствует или устаревшая
• Постоянно появляются новые требования середине проекта (scope creep)
• Team не знает что на самом деле нужно делать

Как это выглядит:

• PO говорит: "Нужна новая функция"
• Team спрашивает: "Какая именно?"
• PO отвечает: "Типа как в конкурентов, но не совсем"

Последствия:

• Переделки кода
• Разочарование stakeholders
• Срыв сроков
• Снижение quality

Как избежать:

• Требую чёткие acceptance criteria для каждой задачи
• Провожу глубокие интервью со stakeholders
• Документирую всё в системе управления проектом
• Регулярно валидирую с заказчиком

2. Плохая архитектура

Легаси код, который никто не хочет трогать.

Проблемы:

• Нарушены принципы SOLID, DRY, KISS
• Код переплетён (high coupling)
• Всё зависит от всего
• Невозможно добавить новую функцию без риска сломать существующее
• Нет разделения слоёв (presentation, business, data)

Как это выглядит:

• Функция делает 10 разных вещей
• Database queries в контроллерах
• Дублирование кода во всех сервисах
• Тесты невозможны из-за жёсткой связанности

Последствия:

• Очень медленная разработка новых функций
• Высокий риск регрессии
• Дорогая поддержка
• Сложная интеграция с новыми сервисами

Как избежать:

• На начальном этапе требую архитектурный дизайн
• Провожу code review на предмет соблюдения принципов
• Требую разделение слоёв (DDD, clean architecture, onion architecture)
• Следу за SOLID принципами

3. Отсутствие тестов

Код без тестов — это time bomb.

Проблемы:

• Никто не знает что работает, а что нет
• Каждый раз при изменении кода нужна полная регрессия
• Баги попадают в production
• Нельзя рефакторить без страха

Как это выглядит:

• Нет unit тестов
• Нет integration тестов
• Нет e2e тестов
• Coverage < 20%
• Все тесты ручные

Последствия:

• Разработчики боятся менять код
• Много bugs в production
• Дорогая поддержка
• QA отдел становится bottleneck

Как избежать:

• Требую code coverage >= 90%
• Требую TDD подход
• Устанавливаю CI/CD с автоматическим запуском тестов
• Делаю тесты быстрыми (юнит тесты < 100ms, интеграционные < 1s)

4. Плохая коммуникация в команде

Теся и фронт работают в разных мирах.

Проблемы:

• Backend и Frontend не согласовывают API контракт
• Разработчики не читают documentation
• Нет daily standup или standup не работает
• Знания локализованы в одном человеке (bus factor = 1)
• Конфликты между отделами

Как это выглядит:

• Backend разработчик написал API совсем по-другому чем фронт ожидал
• Никто не знает как запустить локально проект
• Нет документации по архитектуре
• Человек ушёл и никто не может поддерживать его код

Последствия:

• Рассинхронизация между компонентами
• Много интеграционных багов
• Срыв сроков
• Высокий turnover разработчиков

Как избежать:

• Требую ежедневные standup'ы
• Требую документацию (API контрактов, архитектуры, процессов)
• Проводю синхронизационные встречи между Backend и Frontend
• Использую wiki/confluence для знаний
• Требую code review обязателен

5. Технический долг

Легче написать плохо, чем правильно. Потом платим дорого.

Проблемы:

• Shortcuts сделаны ради скорости
• Debt не исправляется, растёт
• Code становится всё хуже и хуже
• Невозможно добавить новые функции

Как это выглядит:

• Функция работает но она ужасная
• TODO комментарии везде
• Dependencies устаревшие
• Security уязвимостей
• Нет документации

Последствия:

• Проект замораживается когда debt слишком большой
• Нужно переписать всё заново
• Дорого
• Разочарование команды

Как избежать:

• Требую дефинировать DoD (Definition of Done)
• Выделяю 20% спринта на рефакторинг
• Требую обновление dependencies
• Требую документацию при написании кода
• Использую SonarQube или аналоги для контроля quality

6. Отсутствие мониторинга и логирования

Проблемы видны только когда пользователи жалуются.

Проблемы:

• Нельзя понять что случилось на production
• Нет логов
• Нет мониторинга performance
• Нет алертов

Как это выглядит:

• Пользователь говорит: "У меня не работает"
• Team отвечает: "Хм, мы не знаем"
• Нет логов для отладки
• Нет метрик производительности

Последствия:

• Долгая отладка проблем
• Потеря пользователей
• Дорогая поддержка

Как избежать:

• Требую логирование на каждом критичном этапе
• Требую мониторинг (Prometheus, DataDog, New Relic)
• Требую алерты на ошибки
• Требую dashboard для health check'а системы

7. Отсутствие DevOps культуры

Код есть, но развернуть его на production — квест.

Проблемы:

• Нет CI/CD
• Deploy это ручной процесс
• Разработка и production разные конфигурации
• Нет воспроизводимого окружения

Как это выглядит:

• Новый dev берёт проект, потом 2 дня его настраивает
• Deploy на production — это стресс, всегда что-то ломается
• Infrastructure as a mystery, а не as code
• Только один человек может делать deploy

Последствия:

• Медленный feedback loop
• Высокий риск при развёртывании
• Сложность масштабирования

Как избежать:

• Требую Docker контейнеры
• Требую Infrastructure as Code (Terraform, Ansible)
• Требую CI/CD пайплайны (GitHub Actions, GitLab CI, Jenkins)
• Требую automated deployment
• Требую мониторинг и логи в production

8. Недостаток ресурсов

Делаем 3 проекта одновременно с 2 разработчиками.

Проблемы:

• Люди перегружены
• Нет времени на качество
• Burnout
• Высокий turnover

Как это выглядит:

• Team работает выходные
• Velocity падает
• Баги растут
• Люди уходят

Последствия:

• Качество страдает
• Проект замораживается
• Дорого нанимать новых

Как избежать:

• Требую реалистичные планы
• Требую нормальное количество ресурсов
• Требую расчёт velocity на основе历 спринтов
• Говорю "Нет" когда план нереалистичный

9. Неправильная мотивация

Люди демотивированы, качество падает.

Проблемы:

• Цели не ясны
• Нет метрик успеха
• Нет feedback
• Политические игры
• Нет уважения к работе разработчиков

Последствия:

• Люди работают "как надо" минимально
• Качество очень страдает
• Turnover

Как избежать:

• Требую ясные цели и метрики
• Требую регулярный feedback (1:1 meetings)
• Требую уважение к команде
• Требую развитие (обучение, карьерный рост)

10. Отсутствие security культуры

Проблемы:

• SQL injection уязвимости
• XSS
• Утечки данных
• Нет encryption
• Credentials в коде

Как это выглядит:

• Пароли в git'e
• Никакой валидации входных данных
• Нет HTTPS
• Нет защиты от DDoS

Последствия:

• Дорогие утечки данных
• Потеря доверия пользователей
• Юридические проблемы

Как избежать:

• Требую OWASP Top 10 защиты
• Требую code review с security фокусом
• Требую penetration testing
• Требую security training для team

Выводы

На новом проекте я проверяю:

1. Clarity — требования ясны? Есть ли documentation?
2. Architecture — хорошо ли спроектировано? Следуются ли принципы?
3. Quality — есть ли тесты? Какой coverage?
4. Communication — как team общается? Есть ли документация?
5. DevOps — можно ли быстро развернуть?
6. Monitoring — видим ли мы что происходит на production?
7. Resources — достаточно ли людей?
8. Culture — люди мотивированы? Уважаются ли?
9. Security — защищено ли?

Эти 10 проблем — самые дорогие в долгосрочной перспективе. Лучше потратить время на prevention, чем на cure.