Программирование характерно человеческой натуре, которая, всегда правильно понимает это свойство. Чаще всего оно понимает в угоду своему социально-экономическому положению с учетом текущих потребностей без учета даже близкой перспективы.
Программирование разделяет общество на тех, кто что-то пишет и тех, кто потребляет это что-то. В первом приближении, клиент ориентируется на техническое задание, на свои представления о том, что он на самом деле хочет. Другой клиент не ориентируется юридическую составляющую: на бумажный носитель, печать и подпись, а ставит задачу на словах. В обоих предельных случаях, первый клиент постоянно уточняет свои желания, а второй клиент всегда декларирует свежие идеи как исходные.
Программист, приступив к работе, показывает клиенту, как выглядит его задача в реализации, что дает возможность клиенту уточнить свои представления, чем увеличивает объем или сложность работ. Далеко не каждый программист идет на встречу и соглашается с переходом работы в непрерывный процесс при сохранении прочих условий этой работы. Далеко не каждый клиент понимает, что лучше заплатить один раз одному программисту (коллективу, компании), чем потом несколько раз переписывать сделанное, посредством другого программиста, привлекать другой коллектив или компанию.
В этом естественном процессе выживают сильнейшие. Чтобы адекватно реагировать на клиента, безопасно и фактически довести задачу до ее решения и полного удовлетворения клиента необходимо иметь, помимо надлежащей квалификации и опыта, представления о логике мышления клиента. В частности, работе на скорость (то есть оплата за час) следует предпочесть работу на результат. Можно согласиться на часовую оплату только с учетом фактора Пи (резервируется время на 3.14). Далее, лучшее решение – решение, принятое клиентом, но никоим образом не программистом. Только в этом случае будут нивелированы все обстоятельства, которые обязательно возникнут в процессе эксплуатации продукта. Наконец, юридическое (письменное) оформление отношений всегда предпочтительно, однако не всегда оно окажется на стороне программиста. В подавляющем большинстве случаев, клиент найдет изъян в любом программном изделии. Это обстоятельство вне компетенции даже самого квалифицированного программиста, а чаще всего уровень компетенции может сыграть даже роковую роль.
Магазинная идея, что клиент всегда прав в области информационных технологий приобретает катастрофическое значение. То, что всякой личности свойственно преувеличивать свои интеллектуальные способности превращается здесь в фактор абсолютной непогрешимости, становится единственно правильным фактором, на который программист должен делать свою ставку.
Тот фактор, что любая работа повышает квалификацию исполнителя следует расширить на случай негативной непредвиденности и работать над созданием полнофункционального продукта, то есть делать код, который можно всегда расширить. В частности, если декларируется необходимая разрядность числа не более 3-х целых и 2 десятых, «дешевле» предусмотреть строку на сотню символов, а если поле адреса предполагается длиною в тысячу символов, лучше предусмотреть две и никоим образом не создавать таблицы с конкретным количеством колонок или строк. Если в сознании еще остались основы классического программирования, то нужно всеми силами их прикрыть объектно-ориентированным стилем, причем брать в качестве объекта не кнопки, символы, числа, окна и прочую компьютерную мишуру, а реальные объекты клиента. Пусть клиент будет объектом, пусть этот объект создает задачи, предлагает алгоритмы их решения, а программист будет только это реализовывать. И тогда у обоих будет достойный результат.