Управление проектами ›
Эссе о внедрении ›
#28
16.08.10 14:22
(27) Сложно сказать без общей картины, по крайней мере пункт начинается с 4.20, т.е. вверху вероятно есть более общее описание, из которого этот пункт вытекает. А представьте ТЗ, которое буквально начинается так: 1.1 справочник Х, рекивизит 1 (число), реквизит 2 (строка),... И нигде не сказано откуда это, какова цель проекта, чего реально хочет заказчик. В результате, боевое подразделение разработчиков идет туда, не знаю куда, за тем, не знаю чем. Из разговора я понял как это происходит, человек пишет, что-то в тз, потом смотрит, что объем маленький, накидывает туда надерганных из разных конф реквизитов для солидности. Чистой воды подстава. Или вот интересный вопрос. Как до начала разработки можно понять количество документов в системе? (я больше работаю по конфам с нуля). Человек говорит, ну это же очевидно! Вот к пользователю приносят одну бумажку - это документ, вот он печатает пару других - это тоже документы. Результатом становиться то, что бюрократия бумажная превращается в бюрократию электронную. Недавно только клиент искал другую систему, жаловался, что на одно простое в общем-то действие ему надо заполнить кучу инфы в 5-6 документах. ИМХО правильнее было бы изучить процесс, выделить его временные этапы, участников, потом составить матрицу, на пересечении этапа и участвующего пользователя определить структуру информации (реквизиты, сведения...), определить название документа по его сути. Тогда может оказаться, что пользователь оформляет один документ, а остальные - просто подключенные печатные формы. Или например, позволит избежать ситуации, когда один документ заполняется несколькими участниками. Встречалось ли Вам такое, когда бригадир, делая отчет за смену, сидит и тупо не понимает, что за поле "себестоимость" или там "счет учета"?