Каталог решений - Чего хочет разработчик от ТЗ? Примеры из практики

Чего хочет разработчик от ТЗ? Примеры из практики

Чего хочет разработчик от ТЗ? Примеры из практики

В наличии

Модная нынче тема — составление ТЗ и формирование технических требований. Внесу свою маленькую лепту в виде примеров из личной практики и того, каким я вижу идеальное описание задачи. Задачи, которую можно просто взять и сделать! Без лишних вопросов.

Категория:

Описание

 

Исправление ошибки или адаптация существующего функционала

Называть вещи своими именами, конкретизировать

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

Почему так: Разработчику может быть известно о других вариантах объекта, о которых пользователь не догадывается или они ему недоступны в силу ограниченных прав. Также пользователи склонны упрощать названия часто используемых объектов, когда общаются между собой, и также пишут в технических заданиях. Но для разработчика это может быть не так очевидно.

Плохой вариант: “При печати заказа выводится строка про НДС, а когда смотрю Акты на печать, ее нет”

Почему плохо:

  1. Не указано, из какого документа и какая печатная форма выводится. То, что это документ “Заказ”, не очевидно. Возможно, это печатная форма так называется, а документ подразумевается совсем другой.
  2. Не понятно, о какой строке про НДС идет речь, и в каком месте печ.формы это можно увидеть?
  3. Где пользователь смотрит то, что он называет  “Акты на печать”? Если это ПФ, тогда что за признак “на печать”? И что такое “Акт”? — печатная форма или документ? Если это ПФ, то какая именно? Печатных форм со словом Акт может быть несколько.

Возможный хороший вариант: При формировании печатной формы “Акт выполненных работ (наш)” из формы документа “Заказ клиента”, перед подписями ответственных есть строка “Не включая НДС, согласно пп. 777 такого-то Положения”. А если формировать ту же печ.форму из обработки “Реестр печатных форм” с установленным флажком “На печать”, то эта строка пропадает.

Разработка нового функционала/объекта

Описывать цель доработки

Прежде чем писать о том, что нужно сделать, хорошо, когда есть упоминание, для чего это нужно.

Почему так: Из контекста цели можно понять, как именно реализовать отдельные детали, если их описание отсутствует или недостаточно подробно описано в ТЗ. Опытный разработчик/архитектор при этом может предложить более эффективный вариант решения, внести коррективы или внести дополнительные предложения, как лучше реализовать. А от каких-то решений, наоборот, отговорит в силу их неэффективности.

Плохой вариант: Прошу в отчет “Анализ продаж по распродажам” добавить колонку “Дата отгрузки партии”

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

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

Вывод: Оказывается, отчет вообще не устраивает пользователя. Он просто пытается решить новую назревшую проблему подручными средствами.

Рассказать, что не устраивает в существующем функционале

По аналогии с предыдущим примером (см. “Описывать цель доработки”), при средних и крупных доработках хорошо бы знать, что именно не устраивает в текущей ситуации и почему требуется разработка? Возможно, часть задач можно закрыть функционалом смежных подсистем конфигурации, о которых пользователь не знает, или открыть ему доступ к дополнительным объектам/функциям, которые позволять это сделать.

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

Предоставить пример ожидаемого результата или референсы

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

Описывать порядок и правила получения данных

Подробно описывать, откуда должны браться данные (например, для отчета), их порядок получения и алгоритм расчета.

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

Плохой вариант: Для нового отчета по партиям добавить информацию о себестоимости.

Почему плохо: Не ясно, что за информация о себестоимости нужна, сколько должно быть новых колонок и каких? — себестоимость единицы, партии или всего наличного остатка. И что следует понимать под “себестоимостью”, она бывает фактической, полной, производственной, включающей или нет различные косвенные суммы.

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

На этом пока всё, всем внятных постановок! ))

has been added to your cart:
Оформление заказа