lomelind | рабочее

Допустим есть люди, которым нужна программа для дела - заказчики.
И есть люди которые такую программу пишут - программеры.
Программерам удобно получить техническое задание (что и как должна программа делать) всё и сразу. Ещё и в окончательной версии.
А заказчикам удобно как раз наоборот - набросать какую-то общую концепцию, дождаться конкретной реализации, попробовать с ней поработать, сказать программеру поменять вот это и вот это, и прикрутить ещё такое и такое (о чём изначально речи не было). Дождаться пока программер проделает всё это, и... снова сказать "поменяй вот это и вот это, и прикрути ещё вот такое".
Через некоторое время такого взаимодействия программер начинает тихо выть на луну. Ибо часто подобные "поменяй и прикрути" требуют существенного переделывания уже сделанного. Что само по себе может к глюкам приводить. А ещё просто обидно - что если б "сразу сказали", то было бы намного проще.

Понятно что удобство-неудобство конкретной реализации можно оценить только попробовав, и мелкие нюансы могут быть неочевидны пока об них не споткнёшься. А другие - что хуже - очевидны и заказчику и программеру, но очевидны очень по разному (как пример - обозначения тестируемых. Программеру очевидно что если человек не хочет палить свои паспортные данные так подпишется ником каким-нибудь. Заказчику же очевидно что должна быть база в которой все по фио записаны и должен быть способ вывести результаты с чёткой идентификацией где чьи, но не паля конкретные фио). И вот такие вещи имхо нужно проговаривать пораньше.
А вот принципиальные вещи - вроде необходимости групповой обработки (программно сравнить результаты двух разных тестируемых) - и вовсе нужно изначально расписывать.

Программер видя такое дело норовит как можно больше неосновных функций оставить "на соплях", т.е. так, что это делается умными ручками а не программно. Ибо ручки переучить проще в случае чего.

Да, при этом система ещё и используется по назначению (точнее есть попытки это делать) и любые изменения с базой данных должны старые данные хранить (я от греха подальше просто копии делаю каждый раз как в базу вносится что-то нужное а не проверочное).

В общем вот такой вот хаос.

да, аргумент "любой каприз за ваши деньги" не катит, ибо речь идёт о нии и взаимодействии сотрудников внутри него - т.е. заказчик получает свою зряплату, программер получает свою зряплату, и результаты деятельности на это если и влияют то очень раком.

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