Этап внедрения, запуска системы в работу, операция
рискованная, потому что в ней начинают работать пользователи. Откровенно
говоря, лучше бы пользователи вообще никогда не начинали работать в системах,
потому что они всегда все только портят. Программа, безупречно работающая в
добрых родительских руках разработчиков, при появлении незнакомых ей
пользователей начинает капризничать, отказывается работать, выдает самое
неожиданное поведение. И ее можно понять! Пользователи напрочь лишены такта,
они беззастенчиво заявляют, что программа неудобная, непонятная интуитивно, и
что в их старой программе все было намного лучше. К сожалению, пока деньги за
внедрение платятся всегда при обязательном условии работы в системе
пользователей. Поэтому вместо того, чтобы прогнать бесцеремонных невежд, не
способных оценить красоту программного решения и классическую лаконичность
интерфейса, проектной команде приходится внимательно их выслушивать, и
устранять причины их недовольства.
Разбор конфликтов между внедренцами и пользователями на
различных показывает следующую любопытную вещь. Большинство конфликтов вызваны размытой ответственностью за данные,
находящиеся в системе.
Система может работать неправильно по двум причинам: либо в
ней неправильный программный код, либо код правильный, но на вход поданы
неправильные данные. Проще говоря, в систему введены (или неким образом
«появились» в ней) кривые данные, на обработку которых система не рассчитана.
Причем, ситуация с ошибкой в коде – самая простая для
решения. Есть документация, где написано, как данная функция должна работать.
Есть уже готовый код, в который заложена правильная логика (пусть где-то в нем
и есть ошибка). Есть единое представление в головах разработчика и пользователя
о конечном результате. Найти ошибку, исправить ее – и проблема решена. Да,
пользователь недоволен, что столкнулся с ошибкой, но если она будет быстро
исправлена, он отнесется к этому с пониманием.
А вот ошибка данных – совсем другое дело. Прежде всего,
разработчику исправлять нечего – код правильный. Исправление неправильных
данных занимает больше времени и требует тесного взаимодействия с
пользователями – нужно выяснить, какие правильные данные должны быть указаны
вместо этих, проверить все остальные данные на наличие аналогичных ошибок,
согласовать исправления. Что еще хуже, возникает вопрос – а кто виноват в том,
что в системе находятся неправильные данные? Пользователи склонны обвинять в
этом разработчиков (вплоть до заявлений типа «Система не должна позволять
пользователю сделать ошибку!»), а разработчики – пользователей. Возникает
конфликт интересов, который затрудняет сотрудничество, приводит к потере
времени и лишним эмоциям.
Чтобы исключить такие ситуации и связанные с ними очень
опасные риски, достаточно при выполнении проекта придерживаться простого
принципа:
Разработчики создают
только программный код, и никогда не вводят данные. Любые данные вводят только
пользователи.
Этот простой принцип всегда вызывает много вопросов от
внедренцев, не знакомых с такой практикой, поэтому ниже приведены ответы на
наиболее частые вопросы.
Вопрос: Как же в этом случае выполнять сдачу работ?
Ответ: Сдача работ никогда не выполняется на рабочей базе,
потому что разработчики не контролируют находящиеся в ней данные. Там может
оказаться что угодно, в том числе и некорректные данные. Сдача-приемка всегда
выполняется на согласованном контрольном примере, введенным в тестовую базу данных.
Таким образом по крайней мере при сдаче-приемке новый программный код
отработает на правильных данных.
Вопрос: Как выполнять загрузку начальных данных?
Ответ: Для загрузки начальных данных разрабатываются
обработки, сдача-приемка которых выполняется на согласованных контрольных
примерах. Выполняют загрузку данных сами пользователи. Конечно, крайне
желательно, чтобы обработка информировала пользователя о том, что и куда она
загружает, давала возможность отбора и другой минимальной настройки. Таким образом,
любое несоответствие загружаемых данных контрольному примеру и алгоритму
загрузки находится в зоне ответственности пользователя.
Вопрос: Что делать, если в базе нужно произвести групповую
корректировку данных?
Ответ: Для групповой корректировки данных разрабатывается
обработка, сдача-приемка которой выполняется на согласованном контрольном
примере. Как и в случае с загрузкой начальных данных, она снабжается средствами
для отбора и другой минимальной настройки. При необходимости, разрабатывается
инструкция. Запускает эту обработку всегда только пользователь.
Вопрос: Что делать, если требуется изменить настройки
системы, и пользователь не знает, как это сделать?
Ответ: В этом случае готовится подробная инструкция, где
прямо указано, какие настройки и в каком месте должен изменить пользователь.
Вопрос: Что делать если пользователь настаивает на том,
чтобы какие-то данные были внесены в систему именно разработчиками (например,
если ввод этих данных у пользователя вызывает трудности или носит технический
характер)?
Ответ: Если уж не удается отвертеться от такого задания, необходимо
получить у пользователя точное содержание вводимых данных (например, в виде
файла MS Excel)
и оформить их проектным документом под подпись. А после ввода обязательно
организовать сверку пользователем введенных данных с тем, что он предоставил.
То есть, оформить все это, как сдачу-приемку доработки.
Ситуации в ходе проекта могут возникнуть самые разные, и
всегда можно что-то придумать для того, чтобы следовать принципу «код наш,
данные – ваши». Большинство рисков проекта, чреватых неприятным ситуациями,
простоями и бесплатной работой имеют своей причиной недостаточно четкое
разделение ответственности между исполнителем и заказчиком за результат, и
нужно использовать любую возможность, чтобы устранить любую неясность и любой
конфликт интересов. Следование принципу, в соответствии с которым проектная
команда отвечает только за программную реализацию (а также – инструкции,
проведенное обучение и другую работу, которую выполняет своими руками), а за
данные (и, в целом, за использование системы) отвечают только пользователи,
устраняет множество «мутных» ситуаций и дисциплинирует как разработчиков, так и
пользователей. Для заказчика эта логика очень понятна, потому что идея о том,
что разработчик отвечает за исправность созданного им инструмента, но не
отвечает за то, как заказчик им пользуется – проста и очевидна.
Подпишусь под каждым словом. А почему не в фейсбук?
ОтветитьУдалитьВ Фэйсбуке я это продублировал в группе 1С:ERP https://www.facebook.com/groups/1842678132511723
УдалитьКстати, если захотите что-то в эту группу написать - буду очень благодарен : )