Тактика внедрения 8. Универсальные решения

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

Вот несколько примеров таких ситуаций, возникших при выполнении моих проектов:
Заполнение реквизитов. На этапе опытной эксплуатации заказчик поставил задачу реализовать контроль заполнения некоторых реквизитов в документе «Заказ клиента». Вместо того, чтобы добавить эти проверки в модуль этого документа, я после согласования с клиентом поручил программисту разработать функцию, которая проверяла бы заполнение любого реквизита в любом объекте. Кроме того, функция должна была проверять соответствие значения, указанного пользователем, заданному списку, а также возможность выполнить произвольную проверку данных объекта при помощи запроса. То есть, мы решили задачу выполнения любой сколь угодно сложной проверки любого реквизита в любом объекте системы.
Зачем я это сделал? Я понимал, что заказчик начинает выстраивать в системе регламент работы сотрудников. Он устанавливает для них какие-то ограничения и хочет автоматически проверять корректность их действий в системе. Следовательно, скоро понадобятся проверки и ограничения в других справочниках и документах, и на других участках. Дальнейший ход опытной эксплуатации показал, что я прав – заказчик начал вводить новые проверки. При этом он уже не обращался к нам, а самостоятельно пользовался созданной нами функцией. Это сократило для нас количество мелких дешевых доработок и позволило не отвлекаться от решения более важных и дорогих задач.
Права на изменения статуса. При запуске подсистемы управления денежными средствами заказчик попросил ограничить права сотрудников на изменение статуса заявки на расход денежных средств. Следуя логике, описанной выше, я принял во внимание, что в 1С:ERP во многих важных документах есть статус, и что задачи по ограничению прав на изменение статуса других документов вскоре обязательно появятся. Поэтому я поручил разработчику создать небольшое дополнение к системе прав доступа – в карточке пользователя добавить возможность указать любой объект со статусом, и статусы, при которых пользователь может изменять объект. Действительно, через некоторое время возникла потребность ограничить права доступа для заказов, клиента, складских ордеров и других документов. При этом никаких доработок делать уже не было нужно, работа свелась к настройке карточек пользователей, которую выполнил сам заказчик.
Загрузка данных от разных контрагентов. При автоматизации компании, занимающейся интернет-торговлей, возникла задача загружать в систему данные от разных служб доставки. На основании этих данных нужно было формировать складские документы, документы реализации и возвратов, а также обновлять данные о состоянии заказов. Кроме того, требовалось сверять сведения об оплате товаров, переданные службами доставки с данными из банка. Компания работала с несколькими службами доставки, и все они предоставляли данные в разном формате. Поэтому задача была выполнена следующим образом: сначала мы разработали универсальные объекты для хранения всех данных, передаваемых перевозчиками. Данные перевозчиков сначала загружались в это единое хранилище отдельными обработками. А документы 1С:ERP формировались уже с использованием хранилища.
Почему был использовано такое решение? Формирование учетных документов 1С:ERP – сложная и дорогая задача. Мы решили ее один раз, разработав модуль, который использовал для этого данные универсального хранилища. А загрузка данных из службы доставки – задача простая. Службы доставки могут измениться, или они могут поменять формат своих файлов. С выбранным нами решением в этом случае нужно только написать простой загрузчик новых данных в уже известный формат хранилища. С такой задачей легко справится служба поддержки компании, без нашей помощи. Алгоритм формирования документов 1С:ERP при этом менять не нужно – он использует данные хранилища, которые не менялись.

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

Тактика внедрения 7. Продающий дизайн

Одна из самых больших проблем программной разработки на заказ – отсутствие наглядного результата. Заказчик получает работающую программу, иногда очень дорогую, сложную, и эффективную. Но все это не видно ему глазами. Интерфейс программы совершенно не соответствует ни сложности и важности задач, которые она решает, ни уровню использованных программных решений. То, что может увидеть заказчик своими глазами никак не соответствует вложенным в разработку труду, таланту и опыту. В качестве примера можно привести внешний интерфейс известной системы по поиску данных в интернете, имеющей астрономическую стоимость: www.google.com.

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

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

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

В каждом отдельном случае можно придумать какой-то свой способ отразить программную доработку в интерфейсе системы. Дизайн программы не должен скрывать вашу работу, он должен помогать вам «продавать» ее заказчику при сдаче-приемке или запуске системы.

Тактика внедрения 6. Плохое решение лучше никакого

Успешное внедрение ERP - это умение вовремя организовать принятие нужных решений. Именно отсутствие решения или задержка в принятии решения заказчиком или исполнителем является самым большим фактором риска в проекте. Проекты часто заканчиваются провалом не потому что у клиента кончились деньги или лопнуло терпение, и не потому что от вас ушел ключевой программист. Чаще всего проекты рушатся из-за нагромождения нерешенных вопросов, приводящего к невозможности продолжать работу.
Накопившиеся нерешенные вопросы быстро превращаются в огромные завалы. При попытке разгрести их вы обнаруживаете, что для решения одной проблемы нужно решить две других, что невозможно понять, с какого конца взяться, и какой вопрос самый важный и срочный.
Внедрение ERP - это пулемет, расстреливает вас вопросами и проблемами, требующими срочного решения. За время внедрения его участникам необходимо принять несколько тысяч решений! Часто они взаимосвязаны, и задержка с одним решением вызывает задержку десяти других, а те - еще сотни.
Что можно сделать для того, чтобы проект не завяз в непреодолимой паутине из непринятых решений? Нужно принимать их вовремя! И поскольку решения обычно нужно готовить, как можно больше подобных вопросов нужно предусмотреть заранее. Принятие решений начинается еще в ходе переговоров. Каждый последующий этап должен выявить как можно больше вопросов, требующих решения в ходе дальнейших работ, и принять все эти решения заранее.
Тем более, нельзя допускать системного возникновения множества ненужных решений, когда сам способ, которым вы управляете, заставляет вас, заказчика или разработчиков постоянно, раз за разом принимать решения по одному и тому же поводу. Например, если вы сдаете работы по листам учета рабочего времени, то заказчик вынужден принимать отдельное решение по каждой строчке документа. Или если вы подготовили техническое задание, охватывающее несколько подразделений заказчика, сразу несколько человек должны будут одновременно принять решение о его согласовании, и по чисто математическим причинам вероятность успешного решения в отведенное на это время будет ничтожной.
Не смотря на попытку предусмотреть все заранее, вам все равно придется принимать решения уже на ходу. Нельзя уклоняться от принятия решений, нельзя динамить! Каждый вопрос должен быть решен максимально быстро, в идеале - мгновенно. Самое лучшее решение в проекте внедрения - не самое лучшее, а самое быстрое.
К сожалению, решения в ходе проекта принимаете не только вы, но и заказчик. Не все участники проекта с его стороны одинаково замотивированы или склонны принимать решения быстро. Задача руководителя проекта – не допускать появления вопросов, требующий одновременного участия большого числа людей. Чем больше людей участвует в решении, тем дольше оно будет приниматься. Лучше приложить усилия к тому, чтобы один сложный коллективный вопрос распался на несколько индивидуальных.
Это относится не только к организационным проблемам, но и к техническим. Нельзя позволять неожиданно возникшим техническим сложностям сбивать темп проекта. "Времянка" - дешевое решение на время - это способ превратить долгую и сложную внеплановую разработку (отправляющую весь план работ в мусорное ведро и приводящую к новому циклу переговоров) в быструю внеплановую плюс длительную плановую когда-то потом.
Главная задача руководителя проекта - максимально быстрое принятие всех решений по проекту, превращение сложных решений, требующих долгого времени и большого числа участников в простые, принимаемые мгновенно. Опыт и тщательное планирование помогут предвидеть все моменты, где может потребоваться чье-то решение и сделать это заранее. Ежедневное общение со всеми участниками проекта позволит вовремя разглядеть зарождающееся решение и принять меры по его нейтрализации, до того, как оно превратилось в остановку работы.

Тактика внедрения 5. Нарезка задач и сквозной контрольный пример

Чем сложнее и объемнее задача, которую вы собираетесь решить в ходе проекта, тем труднее будет сдать ее заказчику. Объем, на котором это становится практически невозможно, не так уж и велик. При сдаче работы объемом более 100 часов у вас гарантированно будет по крайней мере одна проблема. Задачу объемом более 300 часов вообще невозможно сдать без критической потери времени, денег и нервных клеток. Какой-нибудь «этап» «классического» проекта объемом 500-600 часов вообще не сдается, там решения о приемке с оформлением проектных и финансовых документов и реальное выполнение работ находятся в двух параллельных вселенных, жители которых не даже знают о существовании друг друга.

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

Главному принципу противоречит необходимость проведения для каждой задачи определенных управленческих процедур: подготовки точной формулировки, согласования с заказчиком объемов и срока работы, подготовки контрольного примера, собственно сдачи-приемки. Полный жизненный цикл для задачи на один час – это через чур. Поэтому оптимальный объем для отдельной задачи находится в диапазоне от 20 до 80 часов, наиболее удобный объем составляет 40 часов.

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

Тем не менее, в крупных проектах может возникнуть необходимость разработать какой-то большой блок или целую подсистему, которые предполагают сдачу заказчику целиком. Объем у такой работы может быть значительный, что однозначно приведет ее в зону риска. Что можно сделать в такой ситуации?

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

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

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

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

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

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

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

Но что делать, если нужно выполнить действительно объемную доработку? Например, разработать рабочее место с большим числом функций или создать с нуля целый модуль из множества объектов? Разумеется, вы можете спроектировать такую разработку при помощи графических нотаций, типа UML или EPC, а также подробно описать структуру данных, функции и автоматизируемый процесс в документации (иначе вы не внедряли бы ERP). Вот только заказчик обычно не является опытным проектировщиком, не умеет читать графические нотации, и не может достаточно внимательно проанализировать подробные текстовые описания функций, особенно если она разрастаются в целые технические задания на десятках листов.

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

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

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