Не хватает информации

Если задача сформулирована расплывчато, без деталей и контекста, разработчик может понять ее неправильно. Мы все часто мыслим по-разному: то, что очевидно одному, может быть неочевидно другому.

Детализация правок может сильно варьироваться. Иногда заказчики предоставляют только основные идеи или описание изменений, но без конкретных указаний по дизайну, техническим аспектам или бизнес-логике. Важно помнить: чем меньше деталей, тем больше времени уходит на уточнение и доработку.

Дмитрий Сулыбкин, менеджер проектов Friflex

Нет приоритетов

Все изменения обычно фиксируются в системе управления проектами (например, в Яндекс Трекере). Там менеджер проекта создает задачи, назначает исполнителей, ставит сроки и приоритет — сначала ключевые изменения, затем все остальные. О методах управления проектами читайте в статье.

Важно разделять основную и дополнительную части в функционале продукта. Без основной приложение не будет работать, а без дополнительной — вполне. Если передавать правки без указания приоритета, разработчики могут тратить время на мелкие изменения, а важные задачи останутся без внимания.

Нереалистичные ожидания

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

При обсуждении правок присутствует аналитик, который разбирается в возможностях разработки и может оценить, насколько правка реализуема. Иногда идея и реальность не совпадают или требуют гораздо больше сил и времени. Чтобы не загонять разработку в тупик, в данный момент от них лучше отказаться.

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

Алексей Лазаренко, менеджер проектов Friflex

Погоня за трендами

Пока идет разработка, можно заметить интересные решения в других продуктах и захотеть добавить их в свой. Но стоит ли?

В процессе работы над продуктом легко вдохновиться крупными проектами и захотеть добавить что-то сверх запланированного и согласованного изначально — например, нейросети. Но тогда может потеряться фокус на главной цели. Менеджер помогает удерживать внимание на ключевых задачах. Улучшения тоже можно внедрить — если они логично вписываются в процесс разработки. Или после того, как основной функционал готов.

Алексей Лазаренко, менеджер проектов Friflex

Как лучше передавать правки

Форматы могут быть разными:

• Устные обсуждения на звонках;
• Текстовые документы;
• Скриншоты и видео;
• Figma, Miro и другие визуальные инструменты;
• Текстовые сообщения в мессенджерах;
• Голосовые сообщения — наименее удобны, так как их сложно структурировать и искать нужную информацию.

Самый эффективный формат — текст и изображения или видео. А четко оформленный документ с разбивкой на задачи помогает разработчикам быстрее разобраться в правках.

Сколько правок можно вносить?

Есть два подхода:

Часто правки ограничивают в рамках этапов проекта, чтобы избежать бесконечных изменений.

Сколько стоит спонтанная правка

Допустим, Х — это условная единица стоимости трудозатрат. Ее можно приравнять, например, к одному рабочему дню специалиста или к средней по сложности задаче.

Количество Х зависит от нескольких факторов — объема и сложности задачи, специалистов, которые нужны, чтобы ее решить, и влияния на другие части системы (требуется ли регрессионное тестирование — проверка всего функционала после изменений).

Условная спонтанная правка — изменение логики фильтров в каталоге мобильного приложения.

Вот что нужно сделать, чтобы ее реализовать:

Общие затраты: примерно 5.5Х и возможный сдвиг сроков. Все индивидуально и иногда срок релиза может остаться прежним — за счет привлечения дополнительных специалистов.

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

Как передавать правки так, чтобы все получилось с первого раза

Чтобы правки были поняты и реализованы без задержек:

1. Будьте конкретны. Описывайте правки максимально точно — если это визуальные изменения, приложите скрины, макеты или наброски.

2. Определяйте приоритеты. Указывайте, какие правки критичны, а какие могут подождать.

3. Объясняйте контекст. Если правка касается функционала, уточняйте, как это повлияет на бизнес-цели и пользователей.

4. Планируйте правки заранее. Чем раньше пожелания внесены, тем меньше сдвигов в сроках.

5. Согласовывайте сроки и бюджет. Если правки требуют дополнительных ресурсов, обсуждайте их стоимость и влияние на сроки сразу.

Когда правки четко прописаны, согласованы и обсуждены на всех уровнях, это минимизирует вероятность разночтений и ускоряет процесс разработки.

Дмитрий Сулыбкин, менеджер проектов Friflex

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