Как видишь идеально описанную задачу?

Идеально описанная задача для iOS-разработчика

Идеально описанная задача — это не просто техническое задание, а исчерпывающий контекст, который позволяет разработчику понять не только «что» и как делать, но и «зачем» и в каких границах. Вот ключевые составляющие:

1. Бизнес-цель и контекст

• Проблема или возможность: Зачем эта задача нужна? Пример: «Увеличить конверсию оформления заказа, упростив процесс выбора даты доставки».
• Пользовательская история (User Story): Кто, что и зачем? Формат: «Как [роль пользователя], я хочу [возможность], чтобы [получить выгоду]». Это связывает задачу с ценностью.

2. Детальные функциональные требования

• Исчерпывающий сценарий использования (Use Case): Описание всех возможных путей пользователя внутри фичи: успешный сценарий, альтернативные пути, обработка ошибок.
• Спецификация API: Эндпоинты, методы, ожидаемые модели данных для запросов и ответов, коды ошибок. Идеально — ссылка на документацию (Swagger/Postman) или примеры JSON.
• Логика состояния: Как элементы UI меняются в зависимости от данных (например, состояние кнопки «Отправить» при валидации полей).
• Требования к производительности: Ожидаемое время отклика, необходимость кэширования, работа в оффлайн-режиме.

3. Технические требования и ограничения

• Целевые версии iOS: Минимальная и рекомендуемая версия (iOS 15+).
• Поддержка устройств: Только iPhone? iPhone и iPad? Поддержка разных размеров экрана (включая Dynamic Type)?
• Архитектурные указания: В каком модуле/пакете реализовывать, какие существующие сервисы или архитектурные паттерны (MVVM, Coordinator, Clean Architecture) использовать.
• Интеграции: Необходимость использования специфичных библиотек (например, Kingfisher для загрузки изображений) или нативных фреймворков (Combine, SwiftUI, CoreData).
• Навигация: Как фича интегрируется в существующий граф навигации (через роутер, координатор, глубокую ссылку).

4. Дизайн и UI/UX-спецификация

• Ссылка на макеты в Figma/Zeplin: Обязательно с отмеченными состояниями, вариациями, размерами, шрифтами, цветами (с указанием имен из Design System, например, Color.primaryBackground).
• Анимации и переходы: Детальное описание или ссылка на интерактивный прототип: длительность, easing-функции, последовательность.
• Доступность (Accessibility): Требования к VoiceOver (labels, traits, hints), поддержка увеличения шрифта, цветового контраста.

5. Критерии приемки (Definition of Done, DoD)

• Тестирование: Какие unit- или UI-тесты должны быть написаны? Какие edge-кейсы покрыть?
• Code Review: Требования к качеству кода (например, соответствие SwiftLint правилам).
• Документация: Нужно ли обновлять документацию в коде (документация для публичных методов) или README?
• Нефункциональные требования: Производительность (отсутствие утечек памяти, Instruments), безопасность (обработка чувствительных данных).

Пример идеального описания задачи (фрагмент)

Задача: Реализовать экран выбора даты доставки.

Цель: Сократить количество отказов на этапе «Оформление заказа» на 15%, предоставив интуитивный и быстрый выбор даты.

Требования:

• Пользователь видит календарь на 2 месяца вперед.
• Недоступные даты (выходные, праздники) отключены и визуально выделены.
• При выборе даты отправляется аналитическое событие DeliveryDateSelected.
• Поддержка Dynamic Type и VoiceOver.

API:

// Endpoint: GET /api/v1/delivery/dates
// Response model
struct DeliveryDatesResponse: Codable {
    let availableDates: [Date]
    let blockedDates: [Date]
    let minimumLeadDays: Int
}

Технические детали:

• Использовать UICalendarView (iOS 16+) с fallback на кастомное решение для iOS 15.
• Интеграция через существующий OrderCoordinator.
• Модуль DeliveryModule в пакете FeatureDelivery.

Критерии приемки:

1. Покрытие бизнес-логики (валидация дат) unit-тестами на 90%.
2. В UI-тестах покрыты кейсы: успешный выбор, попытка выбрать заблокированную дату.
3. Отсутствие retain cycles (проверено через Instruments).
4. Дизайн-ревью пройдено.

Ссылки: Figma-макет, Swagger, [Аналог в приложении X].

Такой подход минимизирует недопонимание, сокращает количество уточняющих вопросов и позволяет разработчику сразу приступить к качественной реализации, имея четкое видение конечного результата и его границ.