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

16.10.20

Архитектура

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

технические требования техническое задание ТЗ постановка задачи

См. также

Архитектура решений Программист Платформа 1С v8.3 Бесплатно (free)

В статье расскажу про относительно уникальное явление на рынке. EmplDos - полноценный сервис, который в качестве Backend использует платформу 1С. Речь пойдёт не только о технической и архитектурной стороне вопроса, а ещё и о всех трудностях и граблях, которые пришлось и до сих пор приходится преодолевать на пути к успеху.

14.10.2024    3970    0    comol    28    

28

Кейсы автоматизации Платформа 1С v8.3 1С:Документооборот Бесплатно (free)

Компания «Уралхим» использует 1С:Документооборот не только для хранения и согласования документов, но и для централизованного управления НСИ между 47 системами (не только на 1С); для бэкенда к мобильным приложениям охранников; и в качестве сервиса заказа справок для сотрудников. О деталях реализации нестандартных решений, разработанных в компании «Уралхим» на базе 1С:Документооборот, пойдет речь в статье.

02.08.2024    3461    0    Novattor    1    

16

Кейсы автоматизации Платформа 1С v8.3 Энергетика и ЖКХ Россия Бесплатно (free)

Делимся опытом автоматизации учета башни раздачи воды.

27.12.2023    2197    0    slavik27    7    

15

Отчеты и дашборды Бизнес-аналитик Бухгалтер Пользователь Платформа 1С v8.3 Бухгалтерский учет 1С:Бухгалтерия 3.0 Бухгалтерский учет Бесплатно (free)

Если вы привыкли выгружать бухгалтерские операции в Excel и дополнять их там управленческой информацией, вы сможете значительно сэкономить время, получая нужные управленческие отчеты в бухгалтерской программе сразу, без лишних движений. Представляем решение для самостоятельного внедрения управленческого учета в 1С:Бухгалтерии.

11.12.2023    2910    0    Serg_Tangatarov    2    

16

Архитектура решений Программист Бесплатно (free)

Рассмотрим применение архитектурной проверки задач в процессе разработки.

30.10.2023    5609    0    ivanov660    10    

35

Кейсы автоматизации Работа с требованиями Анализ бизнес-процессов Бесплатно (free)

Автоматизировать производственные процессы в 1С:ERP без доработки типовых механизмов очень сложно. А дорабатывать типовые механизмы 1С:ERP не всегда оправданно. Решением может стать технология разработки Рабочих мест, которая позволяет автоматизировать самые сложные участки последовательно – шаг за шагом, процесс за процессом. Расскажем о том, как помочь пользователям вводить большое количество данных, не нарушая порядок ввода и полноту заполнения всех необходимых реквизитов, и как вовлечь сотрудников Заказчика в разработку и тестирование функционала Рабочих мест.

26.10.2023    2941    0    user1754524    15    

17

Кейсы автоматизации Платформа 1С v8.3 1С:ERP Управление предприятием 2 Бесплатно (free)

Когда проект внедрения ERP в крупном холдинге захлебывается в проблемах производительности и в отчаянии пользователей, нужен комплексный подход. Расскажем о битве за производительность и об организационных мероприятиях по наведению порядка в системе и коллективе.

29.08.2023    3520    0    ke_almaty    0    

15
Комментарии
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
1. FatPanzer 16.10.20 11:20 Сейчас в теме
Подробно описывать, откуда должны браться данные (например, для отчета), их порядок получения и алгоритм расчета.
В первую очередь это нужно для того, чтобы в момент описания алгоритма и расчета сам заказчик вдруг понял:
а) абсурдность своих пожеланий и принципиальную невозможность получения таких данных
б) нехватку исходных данных для получения необходимых данных
в) возможность получения этих данных другими отчетами

И не придется воевать и отнимать время у разработчиков...
Shmell; CodeNull; eternium; charmillion; sogesti; Астиг; Albert_2008; Anchoret; Award; Brawler; Ashandy; kild; m_aster; Gluk_1C; mark_oilbass; user660153_aleks.pisanets; DERL; ovasiliev; Nizbel; user1304317; begemot; EliasShy; user811769; lefthander; XAKEP; sapervodichka; alex-l19041; awk; stas_ganiev; +29 Ответить
25. m_aster 114 20.10.20 11:44 Сейчас в теме
(1) Ли Якокка писал в своей книге "Карьера менеджера":
"Как я усвоил из уроков Макнамары, твердый порядок письменного изложения какой-либо
идеи - это первый шаг к ее претворению в жизнь. В разговоре можно - часто даже не
отдавая себе в этом отчета - высказывать всякого рода смутные и нелепые идеи. Когда же
вы излагаете свои мысли на бумаге, происходит нечто такое, что побуждает вас вникнуть
в конкретные детали. При этом гораздо труднее ввести в заблуждение самого себя или
кого- либо другого."
denis83; Bosma; abasovit; zima_a; Астиг; Anchoret; Designer1C; kukla11; PLAstic; AlekseiAdamov; tulakin_s; FatPanzer; +12 Ответить
2. alex-l19041 8 16.10.20 11:52 Сейчас в теме
Без лишних вопросов
- не получится, т.к. пользователь не сформулирует
идеальное описание задачи
...
3. RustIG 1747 16.10.20 12:06 Сейчас в теме
любой запрос от пользователя - это прежде всего повод "поговорить". И лучше разговаривать, глядя на один экран по Эни деск.
Тогда представления (картинки) в голове заказчика и исполнителя точно совпадут.
Shmell; eternium; Albert_2008; Serg O.; Izosin; begemot; burmsergey; EliasShy; Артано; mikl79; lefthander; artbear; EVKash; sapervodichka; alex-l19041; stas_ganiev; +16 Ответить
4. stas_ganiev 1809 16.10.20 12:07 Сейчас в теме
(3)Хорошо подмечено, согласен!
6. sapervodichka 6915 16.10.20 12:15 Сейчас в теме
(3) угумс, разрыв ожидания и реальности - это вечный повод для анекдотов )))
Serg O.; XAKEP; +2 Ответить
14. Sergant 54 16.10.20 22:35 Сейчас в теме
(3)
любой запрос от пользователя - это прежде всего повод "поговорить". И лучше разговаривать, глядя на один экран по Эни деск.
Тогда представления (картинки) в голове заказчика и исполнителя точно совпадут.


Хорошо, работать когда будем то - а то слишком много разговариваем. Статья об этом, - чтобы меньше говорить.
15. user1464234 16.10.20 22:49 Сейчас в теме
(14) статья о том, что программистам пора менять профессию. И хорошо, если удастся найти профессию, связанную с ИТ, потому что вопросы программистов никому не интересны.
А доверять нам наши коллеги уже не умеют.
19. RustIG 1747 18.10.20 15:06 Сейчас в теме
5. dsdred 3631 16.10.20 12:12 Сейчас в теме
У вас в тексте неплохо расписанные задачи ))

На той недели в нашу тех поддержку пришла задача:
00-00005689 = 3000,00
7. FatPanzer 16.10.20 12:15 Сейчас в теме
(5) Я обычно отвечаю: "Круто! Я рад за вас!"
С копией двум руководителям.
Астиг; IgorS; EVKash; dsdred; +4 Ответить
10. nomad_irk 76 16.10.20 12:37 Сейчас в теме
(7)Бывает отвечаю на следующий день:

"Сдаюсь! Что не так?"

Бывает отвечаю: "да, все именно так."

Так же с копией руководителям.
sogesti; rovenko.n; dsdred; FatPanzer; +4 Ответить
16. Kutuzov 748 16.10.20 23:09 Сейчас в теме
(5) Ну так-то все понятно - видимо что-то не то с суммой документа, приведен номер документа. Скорее всего, данная задача имеет уже предысторию)
20. dsdred 3631 18.10.20 19:54 Сейчас в теме
(16)Нет предыстории, просто задача что с документом и с сумой что то не то.

Причем не типа документа, ни описания. У нас в организации не модно вдумчиво писать задачи, думать больно...
В битве экстрасенсов дети участвуют по сравнению с теми кто такие задачи обрабатывает.
sogesti; user660153_aleks.pisanets; +2 Ответить
21. FatPanzer 18.10.20 20:29 Сейчас в теме
(20) А скриншот полноэкранного отчета без отметок, без выделений, без подчеркиваний присылают? Со словами "Когда почините?"
22. dsdred 3631 18.10.20 20:55 Сейчас в теме
(21)Да чего только не присылают ))
Нам в чат тех поддержка шлет скриншоты задач поржать...

Хорошо что я не на поддержке, а на внедрении ))
36. Астиг 19 21.01.21 12:00 Сейчас в теме
8. caponid 16.10.20 12:31 Сейчас в теме
Но чаще всего бывает так, как в анекдоте: не выиграл, а проиграл, и не машину, а трешку...
Изменения на ходу или по итогу работы могут быть "феерическими"...
Прикрепленные файлы:
Serg O.; rovenko.n; AlekseiAdamov; Tol_arh; muskul; user1464234; dsdred; artbear; XAKEP; +9 Ответить
9. XAKEP 16.10.20 12:34 Сейчас в теме
(8)

Изменения на ходу или по итогу работы могут быть "феерическими"...
:)
:)
:)
-_-
11. succub1_5 91 16.10.20 14:12 Сейчас в теме
По отчетам: "1С - это учетная система, а не отчетная" - это первое когда заказчик требует один общий отчет:
" нужен отчет с колонками: на каждый день периода, кол-во и сумма во всех ценах продажи, остатки, дистрибуция, средний остаток, ШК, ЕИ, а если коробка/уп то коэф, еще доп реквизиты, еще ном поставщика, а да еще артикул, код и самое главное в отдельные колонки вся иерархия мне неудобно по ветвям раскрывать, пусть будет все построчно"...

По обработкам - в 99% понимают что хотят автоматизировать и проблем почти не бывает.
FatPanzer; +1 Ответить
12. serega9507585993 26 16.10.20 14:53 Сейчас в теме
А ещё лучше - пусть сами все делают и спрашивают у меня в конце - так правильно? )))
fomix; pm74; +2 Ответить
13. hiduk 126 16.10.20 15:35 Сейчас в теме
Всё уже придумано и описано до нас в книге «Разработка требований к программному обеспечению» Карла Вигерса и Джой Битти
17. ovasiliev 6 17.10.20 13:40 Сейчас в теме
Спасибо, не поленился человек написать простую мурзилку, которую можно тыкать в лицо разным фантазёрам.

"Не указано, из какого документа и какая печатная форма выводится.
Не понятно, о какой строке про НДС идет речь, и в каком месте печ.формы это можно увидеть?
Где пользователь смотрит то, что он называет “Акты на печать”? Если это ПФ, тогда что за признак “на печать”? И что такое “Акт”? - печатная форма или документ? Если это ПФ, то какая именно?

Когда программист общается напрямую с некомпетентным заказчиком (в частности, напрямую с пользователем-потребителем) и начинает ему задавать такие простые вопросы, заказчика это часто вводит в ступор. Он же такие простые вещи говорит, а программист его не понимает. Наверное, программист - самозванец, студент и вообще дебил.

Для этого и нужны менеджеры проектов / аналитики, чтобы, с одной стороны, пользователям сопли утирать, а с другой - внятное ТЗ выдавать.
товарищ Ын; Brawler; fomix; cherepaha-big; rovenko.n; Gluk_1C; stas_ganiev; +7 Ответить
18. пользователь 17.10.20 19:08
Сообщение было скрыто модератором.
...
23. qazaz2 17 19.10.20 09:56 Сейчас в теме
>>Прежде чем писать о том, что нужно сделать, хорошо, когда есть упоминание, для чего это нужно.
У меня по-разному бывает.
Если я непосредственно с заказчиком работаю то конечно хорошо.
А если задачу ставит какой-то околоИТшный ответственный товарищ (аналитик, архитектор, методист, начальник всея ИТ) то эта информация для меня лишняя. "Предлагать более эффективный вариант" это их хлеб и ответственность.

А автору + за попытку систематизации этой каши)
rovenko.n; stas_ganiev; +2 Ответить
24. l_men 16 20.10.20 09:03 Сейчас в теме
Без внятного ТЗ, результат ХЗ))
товарищ Ын; SuhoffGV; +2 Ответить
27. rovenko.n 21.10.20 11:47 Сейчас в теме
(24)больше всего в работе я люблю ясное и четко сформулированное ХЗ (не моё).
26. PLAstic 296 21.10.20 09:40 Сейчас в теме
Во-первых, формализация обращений. В этом вам поможет любая система сервисдеска. Все нужные поля будут вынесены отдельно и вы можете сделать их обязательными к заполнению.
Во-вторых, это стандартизация. Новая функциональность в формате юзерстори. Баги описываются в формате:
1) Описание;
2) Шаги для воспроизведения;
3) Фактический результат;
4) Ожидаемый результат.
Без этого таски не принимаются разрабами.
Тут всё просто как с детьми: дети будут настолько разбалованы и невоспитанны, насколько это позволят родители.
Прикрепленные файлы:
28. rovenko.n 21.10.20 11:50 Сейчас в теме
(26)очень часто пользователи начинают гнуть свою линию, ходить к директору и капать, что плохая служба поддержки не дает ответов. И руководитель может поддерживать этих прекрасных человеков.
Я в своей работе всегда говорю, что система не умная, а тупая, и если вы не сможете МНЕ объяснить как она должна работать, то я не смогу в системе это реализовать.
Brawler; fomix; +2 Ответить
29. l_men 16 21.10.20 15:51 Сейчас в теме
(28) Не все могут объяснить чего они хотят, поскольку сами не знают. "Нам нужна удобная программа" или "Сделай так что бы всё работало" - это максимум, что можно вытащить из некоторых пользователей. И это еще не самые худшие варианты.
30. FatPanzer 21.10.20 17:28 Сейчас в теме
(29) В этом случае необходимо идти к руководству пользователей. Если и они не смогут объяснить - тогда им этот функционал не нужен, ибо никто не понимает зачем и как. и как следствие "Велком ту зе типовой функционал".
31. rovenko.n 21.10.20 18:04 Сейчас в теме
(30)не всегда срабатывает. Сейчас столкнулись на проекте с тем, что нужен функционал, но никто не знает зачем. То есть, исторически сложилось, что он очень-очень нужен, но зачем - никто не в курсе.
32. FatPanzer 21.10.20 18:35 Сейчас в теме
(31) Не знают "зачем", но точно знают "какой"? Очень интересно прям...
33. user1464234 21.10.20 23:25 Сейчас в теме
ТЗ это незаменимая вещь. Никаким общением (даже если оно записано на видео, в чате, электронной почте) невозможно обосновать сам факт необходимости выполнения работ.
Но самое важное это что разработчик обязан привести конфигурацию в соответствие с ТЗ при завершении проекта, устранив все работы по пожеланиям трудящихся, не соответствующие ТЗ (в т.ч. утвержденным его изменениям).
Ситуация, когда у вас в шкафу лежит ТЗ на одну конфигурацию, а работает неизвестно что и непонятно как - немного странная.
34. PLAstic 296 22.10.20 09:08 Сейчас в теме
(33)
Ситуация, когда у вас в шкафу лежит ТЗ на одну конфигурацию, а работает неизвестно что и непонятно как - немного странная.
Очень вероятно. Всё зависит от профессионализма разработчика и его подхода к этапу обследования. Иногда задача выглядит просто и можно назначить сроки и прикинуть пути реализации, но как говорится "но тут есть нюанс".
Я плавно поворачиваю к тому, что ТЗ хорошо, но для маленьких проектов и маленьких команд, когда всё можно описать заранее один раз. Но всё же agile не с потолка придумали.
37. Астиг 19 21.01.21 12:07 Сейчас в теме
(34) Применять ТЗ или нет - это конечно вопрос важный. Но куда более критична способность пользователей и "заказчиков" четки и ясно формулировать, что они хотят получить. Это и в рамках Agile-практик будет востребовано.
35. abykovkhv 03.11.20 10:17 Сейчас в теме
ТЗ - сделанное заказчиком конечно хорошо, но практика жизни показывает, что по факту, если не подключился сам к написанию ТЗ, то придется бороться с гениальностью заказчика.
Оставьте свое сообщение