По каким срокам работаешь

Сроки и управление проектами

Вопрос о сроках — один из самых важных при найме в профессиональную команду. Давайте разберёмся, как к этому подходить правильно, учитывая реалии разработки.

Принципы оценки сроков

Ключевой принцип: Реалистичность

Ничего нет хуже, чем обещать невозможное. Профессиональный разработчик знает, что срок нужно оценивать на основе:

• Сложности задачи
• Наличия багов и неожиданностей
• Необходимости code review
• Тестирования и рефакторинга
• Документирования

// Пример: оценка задачи по калькулятору

// Когда клиент говорит: "Сделай калькулятор за 2 часа"
// Что нужно учесть:

// 1. Реализация базовых операций (30 минут)
// 2. Обработка ошибок и граничных случаев (1 час)
// 3. Написание тестов (45 минут)
// 4. Code review и исправления (30 минут)
// 5. Буфер на неожиданности (30 минут)
// ———
// Итого: 3,5-4 часа

Методологии оценки

1. Метод трёх точек (Three-Point Estimation)

Оценка основана на трёх сценариях:

Песимистичный сценарий (P): если всё пойдёт не так
Оптимистичный сценарий (O): если всё пойдёт идеально
Наиболее вероятный сценарий (M): реалистичный случай

Эстимирование = (P + 4*M + O) / 6

Практический пример

Задача: Интеграция с внешним REST API

Оптимистичный (O): 4 часа
  - API документация хороша
  - Нет проблем с аутентификацией
  - Простой формат данных

Наиболее вероятный (M): 8 часов
  - Небольшие проблемы с документацией
  - Нужно разобраться с rate limiting
  - Нужны трансформации данных

Песимистичный (P): 16 часов
  - API нестабильно
  - Документация неполная
  - Нужна обработка множества edge cases
  - Задержки из-за ревью

Эстимирование = (16 + 4*8 + 4) / 6 = 60 / 6 = 10 часов

2. Planning Poker (Agile approach)

Команда совместно оценивает задачи в story points:

Разработчики независимо выбирают числа:

Первый раунд:
- Dev1: 5 points
- Dev2: 8 points
- Dev3: 5 points

Обсуждение разницы (Dev2 видит что-то, что другие пропустили)

Второй раунд:
- Dev1: 8 points
- Dev2: 8 points
- Dev3: 8 points

Согласие: 8 story points = ~1 день работы

Реальные сроки в разработке

Стандартный спринт (2 недели)

10 дней разработки
- Планирование: 1 день
- Разработка: 6-7 дней
- Code review: 1 день
- Тестирование: 1 день
- Исправления: 1 день
- Деплой: 0.5 дня

Бизнес-логика (простая CRUD)

// Создание нового entity с CRUD операциями
// Оценка: 2-3 дня

@Entity
public class Product {
    @Id
    private Long id;
    private String name;
    private BigDecimal price;
    // ...
}

@RestController
@RequestMapping("/api/products")
public class ProductController {
    
    @PostMapping
    public ResponseEntity<Product> create(@RequestBody CreateProductRequest req) {
        // Валидация (4 часа)
        // Сохранение в БД (2 часа)
        // Тесты (3 часа)
        // Ревью и исправления (2 часа)
        return ResponseEntity.ok(productService.create(req));
    }
    
    @GetMapping("/{id}")
    public ResponseEntity<Product> getById(@PathVariable Long id) {
        // Получение (1 час)
        // Тесты (1 час)
        return ResponseEntity.ok(productService.findById(id));
    }
    
    @PutMapping("/{id}")
    public ResponseEntity<Product> update(
        @PathVariable Long id,
        @RequestBody UpdateProductRequest req) {
        // Обновление (3 часа)
        // Тесты (2 часа)
        return ResponseEntity.ok(productService.update(id, req));
    }
    
    @DeleteMapping("/{id}")
    public ResponseEntity<Void> delete(@PathVariable Long id) {
        // Удаление (1 час)
        // Тесты (1 час)
        productService.delete(id);
        return ResponseEntity.noContent().build();
    }
}

Сложная бизнес-логика (с обработкой)

// Система платежей с несколькими статусами
// Оценка: 1-2 недели

public enum PaymentStatus {
    PENDING, PROCESSING, COMPLETED, FAILED, REFUNDED
}

@Service
public class PaymentService {
    
    // Проверка статуса (2 часа)
    public PaymentStatus checkStatus(Long paymentId) { }
    
    // Обработка платежа (4 часа)
    public void processPayment(Payment payment) { }
    
    // Обработка ошибок и retry (3 часа)
    @Transactional
    public void retryFailedPayment(Long paymentId) { }
    
    // Возврат средств (2 часа)
    public void refund(Long paymentId) { }
    
    // Уведомления (3 часа)
    public void notifyUser(Long paymentId) { }
}

// Тестирование (8-10 часов)
// Integraton тесты с внешним API (6-8 часов)
// Обработка edge cases (4 часа)

Интеграция с внешним API

// Интеграция с платёжной системой
// Оценка: 1 неделя

@Service
public class StripeIntegrationService {
    private final StripeClient stripeClient;
    
    // Создание платежа (3 часа)
    public StripePaymentIntent createPayment(PaymentRequest req) {
        return stripeClient.createPaymentIntent(
            req.getAmount(),
            req.getCurrency()
        );
    }
    
    // Обработка webhook (4 часа)
    @PostMapping("/stripe/webhook")
    public ResponseEntity<Void> handleStripeWebhook(
        @RequestBody String payload,
        @RequestHeader("Stripe-Signature") String signature) {
        // Верификация сигнатуры (2 часа)
        // Обработка различных событий (3 часа)
        return ResponseEntity.ok().build();
    }
    
    // Обработка ошибок (3 часа)
    // Тестирование с VCR.py (4 часа)
    // Документирование (2 часа)
}

Как правильно ответить на вопрос о сроках

Профессиональный подход

Интервьюер: "По каким срокам вы работаете?"

Хороший ответ:
"Я предпочитаю давать реалистичные оценки на основе
аглорима три точек. Сначала разберусь в требованиях,
оценю сложность, учту тестирование и ревью.
Обычно для небольшой фичи нужна неделя, для более
сложных интеграций — 2-3 недели. Я всегда общаю о
борьем прогрессе и сообщаю о рисках заранее."

Плохой ответ:
"Сделаю за день, никаких проблем!"
Или
"Не знаю, может быть за месяц?"

Процесс оценки в реальной команде

// 1. Получение задачи
Task: "Добавить интеграцию с Slack notifications"

// 2. Анализ требований (30 минут)
// - Какие события должны отправлять уведомления?
// - Какой формат сообщений?
// - Нужна ли обработка ошибок?

// 3. Техническая оценка
SlackNotificationService service = new SlackNotificationService();
// - Использование Slack SDK (2 часа)
// - Обработка различных типов уведомлений (3 часа)
// - Тестирование (3 часа)
// - Ревью и исправления (2 часа)
// - Документирование (1 час)

// 4. Итоговая оценка: 3-4 дня работы

// 5. Буфер на непредвиденные обстоятельства: +1 день

// 6. Финальная оценка: 4-5 дней = 1 неделя

Best Practices

1. Никогда не обещайте срок под давлением — это всегда ведёт к проблемам
2. Включайте буфер (20-30%) на непредвиденные обстоятельства
3. Общайте рано, если видите, что срок может быть нарушен
4. Разбивайте задачи на меньшие части для лучшей оценки
5. Учитесь на истории — смотрите, как долго занимали подобные задачи раньше
6. Используйте инструменты (Jira, GitHub Projects) для отслеживания

Заключение

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