воскресенье, 13 января 2019 г.

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

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

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

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

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

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

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

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

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

3 комментария:

  1. Подпишусь под каждым словом. А почему не в фейсбук?

    ОтветитьУдалить
    Ответы
    1. В Фэйсбуке я это продублировал в группе 1С:ERP https://www.facebook.com/groups/1842678132511723

      Кстати, если захотите что-то в эту группу написать - буду очень благодарен : )

      Удалить
  2. Across multiple of} categories, however, CNC machines have turn out to be a preferred software. CNC machines are computer systems which might be} programmed to perform specific duties and obtain the exact specifications required to fabricate many merchandise. They have gained enormous reputation for his or her precision and reduction of labor prices. Their use has contributed to the increasing need for CAD recordsdata, Small Shower Caps which could be loaded into the pc to perform turning, bending, or welding. Thanks for stating that material prices and labor prices are probably the most significant prices in sheet steel fabrication.

    ОтветитьУдалить