Тактика внедрения 3. Код наш, данные – ваши

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

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

Система может работать неправильно по двум причинам: либо в ней неправильный программный код, либо код правильный, но на вход поданы неправильные данные. Проще говоря, в систему введены (или неким образом «появились» в ней) кривые данные, на обработку которых система не рассчитана.

Причем, ситуация с ошибкой в коде – самая простая для решения. Есть документация, где написано, как данная функция должна работать. Есть уже готовый код, в который заложена правильная логика (пусть где-то в нем и есть ошибка). Есть единое представление в головах разработчика и пользователя о конечном результате. Найти ошибку, исправить ее – и проблема решена. Да, пользователь недоволен, что столкнулся с ошибкой, но если она будет быстро исправлена, он отнесется к этому с пониманием.

А вот ошибка данных – совсем другое дело. Прежде всего, разработчику исправлять нечего – код правильный. Исправление неправильных данных занимает больше времени и требует тесного взаимодействия с пользователями – нужно выяснить, какие правильные данные должны быть указаны вместо этих, проверить все остальные данные на наличие аналогичных ошибок, согласовать исправления. Что еще хуже, возникает вопрос – а кто виноват в том, что в системе находятся неправильные данные? Пользователи склонны обвинять в этом разработчиков (вплоть до заявлений типа «Система не должна позволять пользователю сделать ошибку!»), а разработчики – пользователей. Возникает конфликт интересов, который затрудняет сотрудничество, приводит к потере времени и лишним эмоциям.

Чтобы исключить такие ситуации и связанные с ними очень опасные риски, достаточно при выполнении проекта придерживаться простого принципа:

Разработчики создают только программный код, и никогда не вводят данные. Любые данные вводят только пользователи.

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

Вопрос: Как же в этом случае выполнять сдачу работ?

Ответ: Сдача работ никогда не выполняется на рабочей базе, потому что разработчики не контролируют находящиеся в ней данные. Там может оказаться что угодно, в том числе и некорректные данные. Сдача-приемка всегда выполняется на согласованном контрольном примере, введенным в тестовую базу данных. Таким образом по крайней мере при сдаче-приемке новый программный код отработает на правильных данных.

Вопрос: Как выполнять загрузку начальных данных?

Ответ: Для загрузки начальных данных разрабатываются обработки, сдача-приемка которых выполняется на согласованных контрольных примерах. Выполняют загрузку данных сами пользователи. Конечно, крайне желательно, чтобы обработка информировала пользователя о том, что и куда она загружает, давала возможность отбора и другой минимальной настройки. Таким образом, любое несоответствие загружаемых данных контрольному примеру и алгоритму загрузки находится в зоне ответственности пользователя.

Вопрос: Что делать, если в базе нужно произвести групповую корректировку данных?

Ответ: Для групповой корректировки данных разрабатывается обработка, сдача-приемка которой выполняется на согласованном контрольном примере. Как и в случае с загрузкой начальных данных, она снабжается средствами для отбора и другой минимальной настройки. При необходимости, разрабатывается инструкция. Запускает эту обработку всегда только пользователь.

Вопрос: Что делать, если требуется изменить настройки системы, и пользователь не знает, как это сделать?

Ответ: В этом случае готовится подробная инструкция, где прямо указано, какие настройки и в каком месте должен изменить пользователь.

Вопрос: Что делать если пользователь настаивает на том, чтобы какие-то данные были внесены в систему именно разработчиками (например, если ввод этих данных у пользователя вызывает трудности или носит технический характер)?

Ответ: Если уж не удается отвертеться от такого задания, необходимо получить у пользователя точное содержание вводимых данных (например, в виде файла MS Excel) и оформить их проектным документом под подпись. А после ввода обязательно организовать сверку пользователем введенных данных с тем, что он предоставил. То есть, оформить все это, как сдачу-приемку доработки.

Ситуации в ходе проекта могут возникнуть самые разные, и всегда можно что-то придумать для того, чтобы следовать принципу «код наш, данные – ваши». Большинство рисков проекта, чреватых неприятным ситуациями, простоями и бесплатной работой имеют своей причиной недостаточно четкое разделение ответственности между исполнителем и заказчиком за результат, и нужно использовать любую возможность, чтобы устранить любую неясность и любой конфликт интересов. Следование принципу, в соответствии с которым проектная команда отвечает только за программную реализацию (а также – инструкции, проведенное обучение и другую работу, которую выполняет своими руками), а за данные (и, в целом, за использование системы) отвечают только пользователи, устраняет множество «мутных» ситуаций и дисциплинирует как разработчиков, так и пользователей. Для заказчика эта логика очень понятна, потому что идея о том, что разработчик отвечает за исправность созданного им инструмента, но не отвечает за то, как заказчик им пользуется – проста и очевидна.