По каким критериям оцениваешь этапы выполнения?

Критерии оценки этапов выполнения проекта

В своей 10+ летней практике я разработал систему критериев для объективной оценки прогресса проектов. Это особенно важно в 1С-разработке, где множество зависимостей и легко скрыть реальное состояние.

1. Функциональная полнота (40%)

Основной метрик:

• Реально ли работает, а не просто скомпилировано?
• Все ли требования из TechSpec реализованы для этапа?
• User Story Acceptance Criteria — выполнены ли все критерии приёмки?

Ошибка: "Код написан, скомпилировался, PR создан"
Правильно: "Функция проверена на тестовой БД, работает с граничными случаями"

Проверяю не просто наличие кода, а его работоспособность в реальных условиях.

2. Качество кода (30%)

Code Review критерии:

• Соответствие стандартам проекта (именование, структура, БСП)
• Нет технического долга — нелинованный код, TODO, костыли
• Архитектура — код разделён по слоям, нет спагетти
• Переиспользуемость — функции DRY, no copy-paste
• Производительность — нет N+1 запросов, нет тяжёлых циклов на фронте

// Плохо — технический долг
Процедура ОбработатьДанные()
    // TODO: Оптимизировать после релиза
    Для Каждого Элемент Из ОченьБольшойМассив Цикл
        ДорогойЗапрос(Элемент);
    КонецЦикла;
КонецПроцедуры

// Хорошо — чистый код
Процедура ОбработатьДанные()
    ОтобранныхДанные = ОтобратьДанные(ОченьБольшойМассив);
    ВыполнитьПакетнуюОбработку(ОтобранныхДанные);
КонецПроцедуры

3. Покрытие тестами (15%)

Unit-тесты:

• Для бизнес-логики — минимум 80%+ покрытие
• Для критических путей — 100%
• Граничные случаи и ошибки тестируются

Интеграционные тесты:

• Данные сохраняются правильно в БД
• Взаимодействие модулей работает
• Внешние интеграции (если есть) проверены

Типичная оценка покрытия:
- 50% → недостаточно, высокий риск
- 70% → нормально
- 85%+ → хорошо
- 95%+ → отлично, но может быть overkill

4. Документация (10%)

Обязательно:

• Архитектурные решения описаны (почему так, а не иначе?)
• API документация — если есть внешний API
• Код с комментариями — сложная логика объяснена
• README/гайды — как развернуть, как использовать

Плохо: Код без комментариев, никто не понимает, что он делает
Хорошо: Код с высокоуровневым описанием сложных участков

5. Соответствие срокам (Вспомогательный критерий)

Важно не путать:

• Срок — это не качество. Лучше опоздать на неделю с хорошим кодом, чем прибежать вовремя с говном
• Но если задача оценена в 5 дней, а вы пишете 10 дней без уважительных причин — это проблема

Проверяю:

• Была ли адекватная оценка изначально?
• Произошли ли непредвиденные обстоятельства?
• Были ли проблемы, которые нужно было поднять раньше?

6. Готовность к развёртыванию (5%)

Deployment Readiness:

• Миграции БД протестированы (откат и повтор)
• Нет breaking changes без документации
• Конфигурация вынесена в переменные окружения
• Логирование достаточно для отладки на продакшене

Проверяю:
- Откат в одну команду?
- Логи покажут, что произошло на боевом сервере?
- Конфиг не хардкодирован?

Матрица оценки этапа

Любой из критериев < 50% → ОТКАЗАНО, нужно переделывать

Средний балл:
50-60% → Нужны серьёзные исправления
60-70% → Можно принять с замечаниями
70-85% → Хороший результат
85%+ → Отличный результат

Реальный пример оценки этапа

Задача: Реализация модуля интеграции с 1С через REST API

Функциональная полнота: 85% ✓ (Основной функционал есть, не хватает обработки edge cases)
Качество кода: 75% ✓ (Хороший код, но есть один блок с N+1 запросами)
Тесты: 70% ✓ (70% покрытие, не хватает интеграционных тестов)
Документация: 80% ✓ (API документирована, но нет гайда развёртывания)
Сроки: 100% ✓ (Выполнено в срок)
Деплой: 90% ✓ (Всё готово, кроме одного типа миграции)

Средний балл = 82.5% → ПРИНЯТО с рекомендациями

Система отслеживания

Я использую:

• Definition of Done (DoD) — четкий список критериев для каждого уровня (feature, sprint, release)
• Code Review Checklist — стандартизированный список для проверки кода
• Metrics Dashboard — отслеживание покрытия тестами, скорости разработки
• Retrospectives — регулярный анализ, что работает, что нет

Ключевые выводы

1. Не верю словам — проверяю лично, запускаю, смотрю код
2. Баланс качества и скорости — не требую perfection, но и не прощу халтуру
3. Objective metrics — не субъективное мнение, а проверяемые критерии
4. Раньше обсуждаю — если что-то идёт не в том направлении, говорю сразу, не жду конца этапа
5. Помогаю, не осуждаю — если критерий не выполнен, помогаю разобраться, в чём причина

Этот подход позволяет объективно оценивать прогресс и принимать обоснованные решения о готовности этапа к выпуску.