понедельник, 21 января 2019 г.

Тактика внедрения 4. Макетирование

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

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

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

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

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

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

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

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

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

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

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

среда, 2 января 2019 г.

Тактика внедрения 2. Сдача-приемка на контрольном примере

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

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

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

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

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

Контрольный пример состоит из трех простых компонентов:

- Сценарий демонстрации;
- Входные данные;
- Выходные данные.

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

Например, мы сдаем доработку по помещению части поступивших на склад товаров в «карантин». В сценарии указано, что необходимо создать документ «Приходный ордер на товары». Состав товаров, количество и склад ордера указаны, как входные данные. Далее надо заполнить созданную разработчиком закладку «Карантин», состав и количеств товаров, направленных в «карантин», также указано, как входные данные. Затем надо провести документ. Для получения информации о товарах в «карантине» нужно сформировать созданный вами отчет «Карантин». Результат отчета должен совпасть с выходными данными контрольного примера.
Состав контрольного примера для каждой задачи готовится либо самим заказчиком или разработчиком (за деньги!) с последующим обязательным согласованием с заказчиком. Контрольный пример должен учитывать все возможные варианты действия созданной или доработанной функции системы или, по крайней мере, все наиболее частые случаи. Чем больше будет пример, тем качественнее будет выполнена разработка и тем надежнее будет сдача-приемка. Заказчик заинтересован в полноте контрольного примера, но, в тоже время, от крайностей его удерживает необходимость самому подготовить его или оплатить вам его подготовку.

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

Очень важно еще на старте проекта договориться с заказчиком, что после сдачи-приемки на контрольном примере задача считается выполненной. Если заказчик хочет провести дополнительное тестирование – ради Бога, подписывай протокол выполнения работ или акт, и тестируй сколько душе угодно! Разумеется, если контрольный пример при сдаче не проходит, то есть выдаются ошибки или результат прохождения сценария не похож на выходные данные, то задача – не сдана, и отправляется на устранение замечаний. А все новые идеи и пожелания, возникшие у заказчика при сдаче-приемке (в том числе и выявление некорректной работы системы на каких-то данных, не вошедших в пример) считаются новыми требованиями, и реализуются в рамках новой задачи за отдельные деньги.

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

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

Сдача на контрольном примере – обязательный элемент всех серьезных методик разработки информационных систем. Например, в ГОСТе контрольный пример скрывается под видом документа «Программа и методика испытаний», про который проектировщики часто забывают, ограничиваясь техническим заданием. А в SRUM контрольный пример мимоходом описан, как «критерий готовности» или Definition of Done, (DoD).

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