На главную страницу AlgoNet В сотрудничестве с ZDNet
АРХИВ СТАТЕЙ 2003-4-22 на главную / новости от 2003-4-22
AlgoNet.ru
поиск

 

Место для Вашей рекламы!

 

Все новости от 22 апреля 2003 г.

Сценарии работ

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

Если в обозримое время поиски обходных путей не дают результатов, то скорее всего придется дорабатывать программный продукт для устранения выявленной проблемы. Руководитель определяет трудоемкость работ, назначает ответственного и срок исполнения. После внесения изменений они тестируются, и новая версия отправляется пользователям. Проблема закрывается.

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

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

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

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

Кто в подобных случаях расставляет приоритеты? Сам разработчик — он принимает замечания и решает, что делать в первую очередь, а что отодвинуть на потом. Это должен быть чрезвычайно ответственный человек, который болеет за свое дело и аккуратно складывает распечатки дефектов в папочку, а таких среди программистов, приверженцев разумного хаоса, еще нужно поискать. В течение года такой разработчик забивает бумагами ящики своего рабочего стола, и гарантии, что хотя бы одно замечание пользователя при этом не потеряется, — никакой.

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

 

← март 2003 16  17  18  21  22  23  24  25  26 май 2003 →
Реклама!
 

 

Место для Вашей рекламы!