Как стать автором
Обновить

Техническое задание на доработку: 10 правил и немного занудства

Время на прочтение 14 мин
Количество просмотров 113K
Всего голосов 16: ↑15 и ↓1 +14
Комментарии 19

Комментарии 19

А вот RegionSoft CRM со складским учётом и производством подходит.

Какой милый продакт плейсмент. Ничего не мешало написать «а вот другая CRM — подходит».
Ну почему сразу продакт плейсмент? :-) За другие CRM мы не отвечаем, а за свою — на 100%, в том числе за складской учёт и производство «на уровне».
Зачем? Обоснование необходимости доработки и его место в бизнес-процессе. Этот пункт больше нужен самому заказчику, но и вендору нелишне знать, какие ещё процессы будут затронуты. Иногда это помогает найти альтернативное решение.

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

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


Интересная и болезненная тема, поэтому пара вопросов:
— как грамотно описывать хотелки типа валидации полей ввода, разбивка цифр на разряды или, например, что бы по веб-форме можно было перемещаться табуляцией и т.д.
— Вот вы указали, что не нужно просить разраба указывать предварительную стоимость, но как быть если мы гос и нам нужна система, но и деньги на нее нужно заложить, а полностью доверять в этом вопросе разрабу тоже нельзя, ведь он лицо заинтересованное в максимальной выгоде… Как быть в такой ситуации?
Очень болезненная :-)

1. Вы их уже грамотно описали в своём вопросе. Прямо так и указывайте «создать отчёт такой-то… с формой вызова, поля такие-то… поле 1 „цена“ — значения в рублёвом формате с точностью до 1 копейки (10,23 р.), поле 2 — »отработанные часы" в формате чч: мм, поле 3 «масса отгруженной продукции, в кг, с точностью до грамма» в десятичном формате с разделителем разрядов, поле 4 — «номер телефона» в формате +7-def-abc-xx-yy с проверкой корректности ввода и т.д…

2. Окончательную стоимость в ТЗ желательно указывать (мы об этом ниже пишем), причём по каждому этапу работ. Насчёт полностью доверять — это как повезёт. Есть разработчики, кто сумму берёт с потолка (так же, как и цену лицензии, например). Мы, например, имеем прейскурант, в котором указаны стоимости работ, времени специалистов, коэффициенты и т.д., поэтому даём обоснованную сумму заказчику. Думаю, как один из вариантов — запрашивать обоснование стоимости работ. Опять же, нормальному вендору невыгодно накручивать время работы, поскольку нужно закрыть максимум клиентов и необходимо строгое и корректное планирование.
Спасибо!
плюсовать, увы, не могу…
Самое забавное в этой теме сформулировано Шекли в каком-то рассказе. Суть — для того, чтобы задать правильный вопрос (создать ТЗ), надо знать половину ответа (понимание объектной области + понимание ограничений технологий). Ни у заказчика ни у исполнителя в момент написания ТЗ таких данных как правило нет (я в своей практике не встречал). Поэтому в любых разработках — здравствуй водопадик: сделали-вы не так поняли — мы не это хотели сказать- поиск консенсуса- поиск компромиса время/деньги/фукционал- принятие решения об эксплуатации. Причем исходная документация процентов на 60 выживает в части концепций(где дается общее описание что, зачем и для чего) и практически целиком идет в треш в части как (в случае если ТЗ не пишется разработчиком под себя). Причем, как показывает практика, часто Заказчик начинает менять бизнес процессы под автоматизацию, а это еще более юморная история.
Вы писали, что неправильная пунктуация меняет смысл. Приведите хоть один пример наподобие «Казнить нельзя помиловать».
Я сейчас хрестоматийного не упомню, но приведу поясняющий пример. Вот в ТЗ написано: «Предусмотреть механизм операций с дисконтными картами, купонами, исполняемых кассиром...» — неоднозначная трактовка: операций с картами И операций с купонами И операций, исполняемых кассиром или же операций с картами и купонами со стороны кассира? Лучше писать «Предусмотреть механизм операций кассира с дисконтными картами и купонами». Опять же «Предусмотреть механизм операций кассира, с дисконтными картами и купонами» меняет смысл.

Пока писал, вспомнилась шутка про панд. Panda. Large black-and-white bear-like mammal, native to China. Eats, shoots and leaves. (Панда. Крупное чёрно-белое медведеобразное млекопитающее, происходящее из Китая. Ест, стреляет и и уходит.) Нет запятой (Eats shoots and leaves) и смысл на месте (Ест побеги и листья).
Ест, стреляет и уходит. Так и надо жить :-)
Прошу прощения, но CRM со складским учетом и производством — это тот самый Луна-парк с необычными услугами и развлечениями? Или клиенты что-то производят и складируют?
Ну развлечений в нашей CRM маловато (разве только розовый скин для гламурных леди), хотя некоторые не стесняются обвешивать свои системы флажками и примочками.

Что касается производства и складирования, то это делает не клиент (хотя почему нет?), это делает тот, у кого стоит CRM (наш клиент). Например, вы производите и продаёте велосипеды. Так вот, вместо разведения зоопарка корпоративного софта, можно спокойно всё учитывать в одной RegionSoft CRM: запасы, остатки, потребности производства. И как только выясняется, что педальки закончились — отправлять заказ поставщику педалек. Прямо из CRM. Удобно и всеобъемлюще.
Теперь понятно, спасибо. Это что-то типа Nero Burning ROM, который уже не просто записыватель дисков, а еще и просмотрщик картинок, ТВ-передач и т.д.
Прошу прощения у тех, кто заминусил, но я подумал, что, коль скоро, CRM — это Client Resource Management, то есть какой-то интерактив с клиентскими материальными ресурсами, если у последних имеется производство или склад. И конечно мне хотелось представить как создавалось ТЗ на такой набор функционала
Ну вы сравнили :-)

CRM — это Client Relationship Mansgement, управление взаимоотношениями с клиентами (не Resource). И тут не принцип «не только, а ещё и», а принцип полной интеграции функциональности — все модули связаны, все события фиксируются во всех «заинтересованных» местах. На случай, если кому-то склад и производство не нужны или, наоборот, нужно больше наворотов, есть различные редакции: от простой классической CRM до ERP.

Что касается ТЗ, то оно на всю CRM в нашем случае не писалось, конечно. Давным-давно мы придумали софтину «для себя» и постепенно наращивали функциональность, часть которой как раз перекочевала в релизы из доработок по ТЗ. Это сложный процесс, но зато все требования и все функции системы выверенные, не придумки и фантазии разработчиков, а реальные хотелки клиентов. Так получается рабочая система.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий