Отправить запрос

Сотрудничество · 4 мин чтения

Как написать техническое задание, которое разработчик не поймёт неправильно

Что у вас есть, что это должно делать и как вы это проверите. Три коротких раздела, которые экономят недели.

На этой странице
  1. 1. Что у вас есть сейчас
  2. 2. Что это должно делать
  3. 3. Как вы это проверите
  4. Четыре фразы, с которых начинаются проблемы
  5. Когда не получается написать самому
  6. Шаблон

Большинство проектов, которые идут не так, ломаются не в коде. Они ломаются в первом письме, когда «простая выгрузка в бухгалтерию» значила одно для того, кто писал, и совсем другое для того, кто читал. Через шесть недель правы оба, и оба недовольны.

Чтобы этого избежать, не нужна спецификация на сорок страниц. Нужны три коротких раздела, записанных до того, как кто-то напишет первую строку кода.

1. Что у вас есть сейчас

Опишите исходную точку такой, какая она сегодня, а не какой должна быть.

  • Системы, о которых идёт речь. «Интернет-магазин на PHP 7.4, собственный код. Бухгалтерия в Xero. Остатки — в таблице, которую склад обновляет каждый вечер.»
  • Кто ими пользуется и насколько активно. «Три человека в офисе, около 40 заказов в день, в декабре вдвое больше.»
  • Что болит. «Кто-то вручную переносит каждый заказ в Xero. Это час в день, а ошибки находятся в конце месяца.»

Скриншоты помогают. Как и скучные цифры: сколько товаров, сколько заказов, сколько лет серверу. Разработчик, который знает, что на сервере PHP 7.4, не предложит решение под PHP 8.4, не предупредив вас.

2. Что это должно делать

Теперь опишите результат через то, что люди будут видеть и делать, а не через то, как это должно быть устроено.

Когда заказ в магазине оплачен, счёт с теми же позициями, ценами и НДС появляется в Xero в течение пяти минут. Если его не удалось создать, офис получает письмо с номером заказа и причиной.

Это хорошее задание. Обратите внимание, чего в нём нет: ни слова об API, очередях, cron или фреймворках. Это работа разработчика. Ваша — быть точным в отношении результата:

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

3. Как вы это проверите

Этот раздел обычно пропускают, и именно он самый важный. Запишите до начала работы, как вы решите, что она выполнена.

  • «Делаем десять тестовых заказов, среди них один возврат и один заказ из Швейцарии. Все десять правильно появляются в Xero.»
  • «Отключаем связь с Xero на час. Офис получает по одному письму на каждый неудачный заказ, и после восстановления ничего не потеряно.»
  • «Человек, который сейчас переносит заказы, неделю этого не делает, и ничего не ломается.»

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

Четыре фразы, с которых начинаются проблемы

  • «Как Amazon, только проще.» Проще в чём? Скажите, какие именно части вы имеете в виду.
  • «Должно работать быстро.» Насколько быстро и где измерено? «Страница товара загружается на телефоне меньше чем за две секунды» — это можно проверить.
  • «Стандартные функции.» Стандартных функций не бывает. Перечислите их.
  • «Увидим — поймём.» Поймёте, но только после того, как заплатите за версии, которые вам не понравились. Если вы действительно ещё не знаете, так и скажите и начните с небольшого платного исследования.

Когда не получается написать самому

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

Шаблон

Что есть сейчас
- Системы:
- Пользователи и объёмы:
- Что болит:

Что это должно делать
- Результат, как его увидят люди:
- Известные пограничные случаи:
- Не входит в задачу:
- Не должно измениться:

Как мы это проверим
- Тест 1:
- Тест 2:
- Готово, когда:

Скопируйте его, заполните и отправьте нам или любому разработчику. Вы получите лучший ответ и лучшую цену от всех.

Наша форма запроса спрашивает о первых двух разделах в двух вопросах. Начните оттуда.

Хотите так же у себя?

Два вопроса и адрес эл. почты. Отвечаем в течение двух рабочих дней, обычно быстрее.

Отправить запрос →