Lomelind (lomelind) wrote,
Lomelind
lomelind

рабочее

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

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

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

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

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

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

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

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 12 comments