Всегда ли прав клиент?

Клиент всегда прав! Но почему он прав знаю только я. Потому, что только я знаю как решить его проблемы.
Не восточная мудрость

Да, он всегда прав, но только в одном, что хочет иметь наилучший результат. В остальном он не прав.

Это высказывание наверняка покажется Вам слишком самоуверенным, но что делать если это так, по крайней мере, для областей связанных с внедрением каких - либо интеллектуальных систем и, в частности, систем автоматизации деятельности фирмы. Как известно, цель любого клиента состоит не в самой автоматизации, а в том, чтобы это работало и принесло доход, например, за счет получения более оперативной информации или уменьшения числа занятых сотрудников или еще чего-нибудь другого.

Однако, клиент уже привык к своим методам делопроизводства и не то чтобы не хочет их менять, но не понимает, что бывают другие варианты и он пытается найти, например, группу программистов, которые сделают ему отлично, т.е. точно в соответствии с тем как принято у него в фирме. И если фирма достаточно богата (а "своя" разработка стоит больших денег и большого времени), то такой подход кажется оправданным. Но здесь-то его и подстерегает неприятность.

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

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

Не надо бояться массовых программ! Не надо стремиться поставить задачу самому! Гораздо выгоднее и эффективнее однажды решенную задачу перенести на Вашу деятельность. При этом от клиента требуется сформулировать только конечную цель и ответить на вопросы, которые задаст разработчик.

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

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

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

Десятилетний опыт разработки и опыт эксплуатации в 16000 фирм финансовых, складских и других программ фирмы ФОЛИО дает нам право утверждать, что большинству клиентов кажется, что они знают как "улучшить" те или иные функции, но при реальном объяснении задача улучшения оказывается или неясной или просто абсурдной. К счастью, наши сотрудники умеют критически подходить к предложениям клиентов, быстро выявляя признаки негодного и, взамен, предлагая клиенту оптимальное решение его производственной задачи на основе готового стандартного решения. И принимая такой подход разработчика клиент оказывается в выигрыше.