|
ЗАЧЕМ И КАК |
|
Выпуск 298 11 сентября 2012 г. ОТКЛИК ЧИТАТЕЛЯ На предыдущий выпуск отозвался М.В.Прокошин. С разрешения автора, помещаю его письмо полностью Здравствуйте! Хочу прокомментировать Ваши замечания из рассылки. Действительно, многие разработчики сейчас грешат отмеченными Вами проблемами: полная централизация хранения данных, неудобный интерфейс пользователя, долгая реакция на обращения пользователей. Но надо отметить, что и раньше эти проблемы присутствовали, просто раньше у Вас были единоличные методы их решения. И сейчас эти проблемы успешно решаются, просто фирме-разработчику надо расти, изживая «детские болезни». 1. Централизация хранения данных имеет свои минусы и плюсы. Как и злоупотребление Web-интерфейсом пользователя, как и повсеместное использование мощных кластерных серверных систем. Они создают у разработчика (проектировщика) впечатление возможности (и легкости) свести все данные в одно место, создать гигантское хранилище информации. Техника позволяет, у руководства всегда все данные под руками, обслуживание системы больше не зависит от криворуких системных администраторов на удаленных местах, капитализация центрального офиса на высоте! Есть повод освоить многомиллионные бюджеты, похвастать всюду «крутым» ультрасовременным дата-центром, с «горячим резервированием» в соседнем городе на случай, если пожар/землетрясение/наводнение. Но это - экстенсивный метод развития информационной автоматизированной системы. В данном случае техника развращает. Не надо думать о разбиении системы на части и их взаимодействии, не надо использовать дополнительные механизмы синхронизации различных участков обработки информации, не надо думать о процессах прохождения информации и участках ее обработки. Достаточно создать гигантскую свалку, куда все данные будут записываться, и дать пользователю механизм (да и то, как Вы правильно заметили, зачастую весьма кривоватый) фильтрации собственного куска информации. И, экстраполируя тенденцию, при выходе на уровень страны будут предложены те же мега-супер-крутые решения, объединяющие все данные в одну базу (а попытки таких решений мы уже наблюдаем и не всегда удачные). А ведь существуют механизмы синхронизации баз, существует понятие «распределенная БД», уже много лет существуют, примером была Ваша старая система. И никто не мешает иметь в каждом отделении стационара, к примеру, свою маленькую базу Оракла (бесплатный Express Edition) с данными своего отделения, как это и было в Вашей системе. На уровне города, например, можно иметь хранилище, где лежат копии историй болезни без последних данных, подлежащих получению при очередном сеансе синхронизации отделения с городской базой. И никто не мешает делать механизмы обновления версий программ без участия человека. И можно использовать все прочие прелести современных технических решений, включая легко масштабируемый Web-интерфейс. И не будет вопросов с фильтрацией, правами, каналами связи, огромными дата-центрами с работой в режиме 24/7. Просто надо ПРОДУМЫВАТЬ всю систему, а не слепо использовать модную нынче централизацию, удешевляя тем самым разработку (как кажется сначала). 2. Недостатки Web-интерфейса. С внедрением Windows интерфейса разработчики стали просто лениться продумывать действия пользователя. Стал моден принцип «накидал кнопочек на форму и все готово». А хорошая система требует проектирования интерфейса. У буржуев за рубежом даже специальные люди есть – дизайнеры интерфейсов. И задача дизайнера нарисовать формы так, чтобы это было эстетично, эргономично и удобно. В том числе, ни Windows ни Web интерфейс не отменял клавиатуры. Есть стандартные клавиши типа «Tab»-переход с поля на следующее поле, «Alt-Tab» - обратное действие, Enter (или Ctrl-Enter) – сохранить и закрыть форму (кнопка «Ок»), Esc – закрыть форму без записи (кнопка «Отмена»). И еще много других клавишных сочетаний. Но программист сейчас работает «на скорость», а уж про дизайн интерфейса я вообще молчу. Поэтому не озадачиваются клавиатурой, не думают о том, что удобно пользователю. Есть стандартное соотношение эффективности 80/20. Т.е. применительно к разработке, 80% всех задумок разработчик делает, 20% пренебрегает по разным причинам. И клавиатурные комбинации относятся, как правило, к этим 20 отбрасываемым процентам. Потому что пользователи не настаивают, не делают наличие удобного интерфейса условием приемки программного продукта. Се ля ви. Хотя если посмотреть Microsoft Office, например, то там клавиатурных комбинаций вполне достаточно. 3. Реакция службы поддержки. Здесь все должно быть просто четко спланировано и расписано, для этого менеджменту фирмы надо «подтянуться», выработать жесткие правила взаимодействия служб и разграничения ответственности работников. В качестве неплохого примера опишу работу службы поддержки одной фирмы Криста, которая ведет наш продукт. Первая линия поддержки – прямые телефонные консультации пользователей «здесь и сейчас». При необходимости специалист просит изложить проблему по email. В случае невозможности немедленного ответа специалист первой линии связывается со второй линией – поддержкой центра разработки, где выдаётся либо ответ на вопрос, либо описание проблемы. Описание проблемы направляется либо конкретному программисту (если изменения понятны и незначительны), либо аналитику, который для программиста делает описание постановки задачи, при необходимости связываясь с самим пользователем. От разработчика изменения идут в production-отдел, который включает изменение в глобальное обновление системы, либо обратно в отдел поддержки, который передает изменение клиенту (возможно и туда и сюда, в зависимости от срочности и индивидуальности проблемы). При обращении пользователя в поддержку и регистрации запроса на доработки обязателен вопрос срока, в течение которого для пользователя жизненно важно получить это обновление и по каким причинам. Главная проблема: пользователи, которые хотят «все и сразу». В таких случаях пользователю говорят, что ресурсы выделены ограниченные и ему надо определиться в списке поставленных им задач, что более важно, что менее. В случае необходимости расширения объемов «срочной помощи» вопрос переводится на уровень руководства, это помогает нормализовать взаимоотношения. Еще одна важная вещь – документация программных модулей. Все пользовательские функции и настройки системы, а также все обновления должны быть документированы, им должна постоянно обучаться поддержка. Надо вести систему учета установленных обновлений и запросов пользователя (т.н. CRM-Customer Relationship Management). Без этого реакция пользователей будет закономерно отрицательная. Так что, недостатки новых систем – это всего лишь недоработки конкретных исполнителей, с которыми можно и нужно бороться. С уважением, Михаил Прокошин, зам.нач. ОВ АСФР комитета адм. Алтайского края по финансам, налоговой и кредитной политике. ПОСЛЕСЛОВИЕ АВТОРА РАССЫЛКИ Вот это последнее - "можно и нужно бороться", - услышанное от профессионала, вселяет надежду, несмотря на скверное положение с разработкой медицинских систем. А положение - хуже некуда. Оно не сводится к недоработкам отдельных исполнителей. В медицине это система волюнтаризма самоуверенных программистов, обусловленная отсутствием хорошо ориентированных и требовательных пользователей - лечащих врачей и главных врачей. Я показал письмо Михаила Владимировича двум разработчикам МИС. Один запросто перешёл на личности ("автор недопонимает"). Другой написал, что "Прокошин прав, но проклятые деньги и сроки вынуждают жертвовать качеством...". Так и живем: одни самоутверждаются в своём превосходстве и непогрешимости, другие, конкурируя за заказчика, откровенно поступаются профессиональной честью. Какие же системы у них получатся? В какие системы погрузят они врачей? Не знаю, как противостоять этой безответственности. Но уж точно ситуацию не переломить, пока из среды медиков не выдвинутся бескомпромиссные постановщики задач. Только не бесправные, как в моей попытке, когда программист и переиначивал, и отбрасывал постановки в убеждении, что медицину он уже понял. Постановщик должен быть представителем заказчика с правом окончательных решений во всём, что затрагивает врачей. Он не консультант по случаю, а тоже разработчик, и именно его решающее слово должно побуждать программиста работать на совесть. Никаких намёков на что-либо подобное сегодня нет. Но понимать всю меру неблагополучия и молчать - стыдно. Вот и упорствую: рассказываю врачам, как должно быть. Мало рассказа - отдаю свои программы: хоть для развлечения любознательных, хоть для эксплуатации в любом масштабе. Размышляйте, пробуйте, убеждайтесь: то, что действительно нужно медицине, можно сделать. Авось кому-то это послужит точкой опоры. |