На мои замечания Владимир Вдовин, директор фирмы, ответил (дословно) "У
нас тут не научно-исследовательский институт, мы создаем ПРОДАВАЕМЫЕ
продукты", "Сейчас архитектуры не продаются, продаются КРАСИВЫЕ КАРТИНКИ
и коробочки".
клиент/заказчик всегда прав. (кроме случаев, когда речь идет о явном
нарушении законов.)
не грузите заказчика своими проблемами в архитекутре, или плохо написанном
ТЗ.
решайте проблемы по мере их поступления.
Именно поэтому "стариков" брать не хотят. они видят, как все плохо, и у них
не горят глаза "как мы круто все сделаем".
С моим опытом я вижу ошибки в архитектуре часто просто по интерфейсу. Я
не могу делать проект ЗНАЯ, что в конкретных местах у пользователя будут
ошибки, хотя пользователь этого может и не заметить.
Знаете - оставьте эти знания при себе.
Знания - это ваши козыри. Придержите их до конца игры.
Иначе вы не продадите первую версию.
Если ошибку заметят - оплатят ее отдельно. Вы ведь уже знаете, как ее
исправить? пока молодой будет разбираться - у вас уже все готово.
Если ошибку не заметят - заказчик будет счастлив, что все работает.
И главное: проблемная ситуация может не возникнуть за все время
эксплуатации.
например:
Ну, а бухгалтерскую систему "Фрегат" я сломал через 5 минут, просто
"неудачным действием пользователя".
Когда я разговаривал разработчиками выяснилось, что многие бухгалтерские
ситуации им просто в голову не приходили, что и отразилось на архитектуре.
не каждая бухгалтерия использует _все_возможные_ "бухгалтерские алгоритмы".
Когда выходила 1С8.0 мы были в числе первых, кто начал ее внедрять.
Выяснилось например, что продажа валютной выручки элементарно неработает.
Недоописана.
Зато многие, простые российские компании, которые никогда не торговали на
экспорт, давали интервью "мы перешли на 8.0! все классно, и никаких проблем
при переходе с семерки!"
Вывод: Нет необходимости [сразу] описывать все возможные,
потенциально-проблемные ситуации, которые известны вашему Опыту.
Универсальный Решатель Задач пишется за бесконечное кол-во времени.
Я для того чтобы сделать без ошибок - нужны исследования, которые никто
оплачивать не хочет.
во-первых сделать совсем без ошибок - невозможно.
во-вторых, этап предварительного обследования есть в каждом проекте, и нужен
он Вам, а не Заказчику. Чтобы не завалить проект в целом.
Главное - не углубляться в детали, и не тратить много времени (за которое
всеравно не платят).
Всеравно при внедрении выяснится масса деталей, которых и в вашем опыте нет,
и на этапе исследования не заметишь.
Какое бы классное и полное ТЗ вы не составили на этапе обследования, никто
кроме вас не будет по нему программу писать.
Так что заплатив за исследование - закачик может остаться ни с чем.
Заказчики предпочитают платить за результат - который хоть как-то работает.
