Исправление ошибки или адаптация существующего функционала
Называть вещи своими именами, конкретизировать
Прописывать названия печатных форм, заголовков форм объектов в точности так, как они выглядят в конфигурации или в пользовательском интерфейсе.
Почему так: Разработчику может быть известно о других вариантах объекта, о которых пользователь не догадывается или они ему недоступны в силу ограниченных прав. Также пользователи склонны упрощать названия часто используемых объектов, когда общаются между собой, и также пишут в технических заданиях. Но для разработчика это может быть не так очевидно.
Плохой вариант: “При печати заказа выводится строка про НДС, а когда смотрю Акты на печать, ее нет”
Почему плохо:
- Не указано, из какого документа и какая печатная форма выводится. То, что это документ “Заказ”, не очевидно. Возможно, это печатная форма так называется, а документ подразумевается совсем другой.
- Не понятно, о какой строке про НДС идет речь, и в каком месте печ.формы это можно увидеть?
- Где пользователь смотрит то, что он называет “Акты на печать”? Если это ПФ, тогда что за признак “на печать”? И что такое “Акт”? - печатная форма или документ? Если это ПФ, то какая именно? Печатных форм со словом Акт может быть несколько.
Возможный хороший вариант: При формировании печатной формы “Акт выполненных работ (наш)” из формы документа “Заказ клиента”, перед подписями ответственных есть строка “Не включая НДС, согласно пп. 777 такого-то Положения”. А если формировать ту же печ.форму из обработки “Реестр печатных форм” с установленным флажком “На печать”, то эта строка пропадает.
Разработка нового функционала/объекта
Описывать цель доработки
Прежде чем писать о том, что нужно сделать, хорошо, когда есть упоминание, для чего это нужно.
Почему так: Из контекста цели можно понять, как именно реализовать отдельные детали, если их описание отсутствует или недостаточно подробно описано в ТЗ. Опытный разработчик/архитектор при этом может предложить более эффективный вариант решения, внести коррективы или внести дополнительные предложения, как лучше реализовать. А от каких-то решений, наоборот, отговорит в силу их неэффективности.
Плохой вариант: Прошу в отчет “Анализ продаж по распродажам” добавить колонку “Дата отгрузки партии”
Почему плохо: Нет уточнения, для чего нужна колонка? - для дополнительной группировки, какого-то анализа или для отбора строк этого отчета, чтобы потом результат подставить в другой отчет?
Возможный хороший вариант: В связи с частыми жалобами на просроченную продукцию во время промоакций, требуется дополнительный анализ отгружаемых партий в торговый зал, чтобы понимать сроки их логистики. Было бы удобно добавить колонку “Дата отгрузки партии” в отчет “Анализ продаж по распродажам”. Это бы позволило выгрузить отчет в Excel и отобрать строки с критичными сроками.
Вывод: Оказывается, отчет вообще не устраивает пользователя. Он просто пытается решить новую назревшую проблему подручными средствами.
Рассказать, что не устраивает в существующем функционале
По аналогии с предыдущим примером (см. “Описывать цель доработки”), при средних и крупных доработках хорошо бы знать, что именно не устраивает в текущей ситуации и почему требуется разработка? Возможно, часть задач можно закрыть функционалом смежных подсистем конфигурации, о которых пользователь не знает, или открыть ему доступ к дополнительным объектам/функциям, которые позволять это сделать.
Иногда бывает и так, что неудобен порядок выполнения каких-то операций, или расположение элементов на форме/в интерфейсе. Из-за этого пользователь может отказываться от использования новой доработки и продолжать делать “по старинке”.
Предоставить пример ожидаемого результата или референсы
Картинка, пример отчета в Excel, скрин из другой программы (“хочу также”), или хотя бы словесное описание того, что должно присутствовать в результате.
Описывать порядок и правила получения данных
Подробно описывать, откуда должны браться данные (например, для отчета), их порядок получения и алгоритм расчета.
Почему так: Вопрос даже не в том, что это уменьшает число вопросов программиста к постановщику. Зачастую при недостаточном описании разработчик принимается за реализацию похожих показателей из смежной подсистемы, или по инерции берется за неверный вариант, с которым работал недавно по другой задаче, потому что “на слуху”.
Плохой вариант: Для нового отчета по партиям добавить информацию о себестоимости.
Почему плохо: Не ясно, что за информация о себестоимости нужна, сколько должно быть новых колонок и каких? - себестоимость единицы, партии или всего наличного остатка. И что следует понимать под “себестоимостью”, она бывает фактической, полной, производственной, включающей или нет различные косвенные суммы.
Возможный хороший вариант: Прошу добавить в отчет по партиям колонку “Себестоимость единицы”, которую следует рассчитать как стоимость всех поступлений от поставщика и доп.услуг, разделенную на общее количество поступлений за период отчета.
На этом пока всё, всем внятных постановок! ))
