.jpg)
Представьте: вы просите разработчика «сделать кнопку красивее». Через день получаете результат — кнопка стала ярко-розовой и мигает. Вы в ярости, программист в недоумении. Знакомо?
Я разработчик и каждый день вижу такие ситуации. Проблема не в лени или глупости программиста, а в том, как сформулирована задача. Мозг разработчика — это машина для обработки конкретных инструкций. Если на входе — «сделай, чтобы работало как надо», на выходе будет хаос.
Эта статья — взгляд изнутри процесса разработки. Я расскажу, как ставить задачи так, чтобы программист делал их быстро, правильно и без лишних вопросов. Вы узнаете, как сэкономить часы переписок и избежать дорогих переделок.
Вот типичный алгоритм, по которому работает разработчик, получая задачу:
Главный вывод: программист не может додумывать. Если в задаче есть неопределённость, он либо остановится и будет ждать уточнений, либо сделает «как проще» — а это почти всегда не то, что нужно бизнесу.
Задача должна звучать как приказ: «Сменить телефон на странице контактов». Никаких «наверное», «может быть», «я думаю».
Плохо: «А можете поправить наш телефон на странице контактов? Он вроде бы старый».
Хорошо: «Заменить номер телефона с +7 (111) 111-11-11 на +7 (222) 222-22-22 на странице https://site.ru/contacts».
Чем суше и конкретнее текст, тем меньше вопросов.
Всегда указывайте:
Пример из жизни: Однажды менеджер написал: «Поправьте цены в каталоге». Программист полез в код, искал, где хранятся цены, потратил 2 часа. Оказалось, нужно было просто заменить число в админке на странице https://site.ru/admin/prices. Скрин бы сэкономил кучу времени.
Не просто «нажать кнопку», а что происходит до и после:
Помните: если вы не описали ветку «товар закончился», программист сделает так, чтобы кнопка просто не работала. Это проще. А вам нужно, чтобы показывалось сообщение «Товара нет, но мы привезём через 3 дня».
Если в проекте есть согласованная терминология — используйте её. «Заявка» — это заявка, а не «проект», «заказ» или «запись». Путаница в терминах ведёт к ошибкам в коде.
Кроме основной функции, пропишите:
Одна строка контекста: «Эта кнопка нужна, чтобы клиенты могли быстро повторить прошлый заказ». Когда программист понимает цель, он принимает верные решения в неописанных ситуациях.
Никаких «на мой взгляд», «боюсь что...», «вроде бы». Только факты. Если делаете видеоскрин — не показывайте, как вы открываете браузер и вводите пароль. Начинайте сразу с сути.
Главное — дать возможность воспроизвести. Лучший способ: видеоскрин с URL, временем, логином и консолью браузера (F12 → Console). Укажите, что должно было произойти.
Пример: «При нажатии на кнопку "Оплатить" на странице https://site.ru/cart вылетает ошибка "500". Ожидал, что откроется форма оплаты. Логин: test@test.ru».
Используйте все правила выше. Добавьте скриншот с пометками — это снижает количество вопросов на 80%.
Лучше всего — скриншот экрана со стрелками и текстом: «Вот эту кнопку сделать синей, а этот текст выровнять по левому краю». Текстовые описания без картинок — худший вариант.
Опишите то, что знаете точно. Остальное — вынесите в отдельный раздел «Требуется уточнить». Программист сам задаст вопросы, но у него будет база для начала работы.
Запишите видеоскрин на 30 секунд, где показываете проблему и говорите, что нужно сделать. Это быстрее, чем писать текст, и точнее.
Потому что «очевидное» для вас может быть неочевидным для него. Например, для вас «кнопка должна быть красивой» — это синяя и круглая. Для программиста — это 20 вариантов реализации. Он выберет тот, который проще, а не тот, который вам нравится.
По той же постановке. Если задача чёткая — проверку можно делегировать тестировщику или даже другому разработчику.
Хорошая постановка задачи — это не трата времени, а инвестиция. Она даёт:
Начните с малого — добавьте к следующей задаче скриншот с пометками. Увидите разницу.
Читайте также: