Как поставить задачу программисту: пример и проверка

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

Разберём учебную ситуацию: менеджер каждый день открывает список заказов, выбирает свой филиал и статус «Ожидает выдачи». После перехода в карточку и возврата фильтр сбрасывается. Руководитель просит «запоминать фильтры». Это уже направление решения, но ещё не задача: непонятно, какие значения сохранять, для кого, на какой срок и что делать при смене доступа. Такие вопросы лучше раскрыть до оценки, а не во время спора о готовности.

Начните с наблюдения, которое можно повторить

Запишите последовательность без объяснения предполагаемой технической причины. Например: «Менеджер филиала Север открывает заказы, выбирает статус, переходит в заказ и возвращается кнопкой списка. В списке снова показаны все доступные статусы». Укажите адрес экрана, роль и среду проверки. Если поведение воспроизводится только на телефоне или после нового входа, это часть наблюдения, а не второстепенная деталь для будущего разговора.

Рядом обозначьте последствия для работы. В учебном примере сотрудник повторно настраивает список и может выбрать заказ из другой доступной ему группы. Не придумывайте точную потерю денег или часов, если её никто не измерял. Достаточно объяснить повторяемое действие и возможную ошибку. Если есть измерение, сохраните способ получения: сколько наблюдений, какие сотрудники и какой период. Оценка эффекта должна оставаться проверяемой, а не становиться украшением заявки.

Отделите фактический результат от желаемого. Фраза «фильтр сломан» смешивает их и заранее назначает диагноз. Разработчику полезнее знать, что произошло после конкретного действия и что должно было произойти по согласованному правилу. Если правило пока не принято, так и напишите. Задача с открытым вопросом честнее задачи, где неопределённость спрятана внутри слова «нормально».

Превратите пожелание в правило поведения

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

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

Обсудите исключения до рисунка кнопки

Сохранённое значение не должно само по себе давать право на просмотр данных. Если доступ к филиалу изменился, система должна обрабатывать запрос по действующим правам. В задаче опишите ожидаемое поведение экрана: например, недоступное значение сбрасывается с понятным объяснением или предлагается выбрать разрешённый вариант. Конкретное правило согласует владелец. Программист не должен угадывать его по старому скриншоту руководителя.

Другой случай — сохранённый статус больше не используется. Важно различать отсутствие результатов и недопустимый фильтр. В первом случае выбранное сочетание существует, но подходящих заказов нет; во втором сама настройка устарела. Одинаковый пустой экран не объясняет сотруднику разницу. Зафиксируйте, какое сообщение и действие доступны в каждом случае, не требуя показывать скрытые или удалённые записи ради красивой выдачи.

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

Разведите решение, ограничения и вопросы

Заказчик может предложить кнопку «Сохранить вид», но исходная проблема от этого не обязана решаться именно кнопкой. В задаче пометьте предложение как вариант интерфейса. Отдельно запишите ограничения, действительно обязательные для проекта: поддерживаемые устройства, доступные роли, запрет изменения исторических заказов и согласованные границы данных. Технический способ хранения разработчик сможет предложить после знакомства с системой, а не выбирать вслепую по названию поля.

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

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

Прикрепите данные, с которыми можно работать

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

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

Запишите готовность через проверку, а не через обещание

1. Открыть согласованную тестовую среду под указанной ролью.
2. Выбрать определённые филиал и статус, сохранить исходное состояние.
3. Перейти в доступную карточку и вернуться оговорённым способом.
4. Сверить сохранённые настройки и фактический состав списка.
5. Выполнить сценарий изменённого доступа и явного сброса.
6. Зафиксировать версию результата и оставшиеся ограничения.

Эта последовательность является примером приёмки, а не требованием к любому фильтру. Для вашего проекта нужны реальные состояния и согласованные переходы. Не ограничивайтесь фразой «проверил, работает»: отметьте, какой сценарий выполнен и что получилось. Если один пункт не прошёл, сохраните наблюдение отдельно от новой идеи о развитии функции. Тогда исправление возвращается к принятому правилу, а дополнительное пожелание получает собственную оценку.

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