Введение

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

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

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

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

Предпосылки развития

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

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

Направления развития

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

• Прогнозируемо решаемые (ПР)
• Субъективно решаемые (СР)

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

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

Первый тип задач рассматривать нет нужды, в силу того, что есть множество научных или около научных подходов, хорошо зарекомендовавших себя, которые с успехом помогают разрешать подобные задачи и предсказывать тренд их продвижения на перспективу. Для примера будет достаточно сказать о ТРИЗ (поклонником которого является Ваш покорный слуга). Невероятно логичный инструмент, который позволяет абстрагироваться от понятия психологической инертности мышления и направить мысль в «правильное» русло.

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

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

Объективно о субъективном

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

Для любого руководителя более приоритетной является ориентация не на объективные закономерности развития внешней и внутренней среды, а на свою интуицию, базу знаний и опыт. Именно такая направленность на свои внутренние качества и позволили ему достигнуть того положения, в котором он находится (так думают 99,9% руководителей, и определенная логика в их размышлении есть). Если бы он вел себя абсолютно предсказуемо, пусть даже алгоритм его мысли был бы очень сложен, то он был бы последователен и вычислим. Вряд ли подобный руководитель отличался от программного обеспечения (ПО), что позволило бы его легко заменить автоматизированной программой, но на практике пока такого не случается. Именно личный подход к делу, проявление эмоций и придание той или иной ситуации особых эмоциональных красок не позволяют оцифровать человеческое мышление и делают его поистине уникальным, так же, как и продукты, получаемые в результате мыслительной деятельности. Поэтому при работе с бизнес системами, хозяева которых бесспорно мыслящие люди, приходится постоянно «держать ухо востро» и быть готовым к смене курса развития поддерживаемой ИС.

Выбор модели развития в проектах с типом задач СР

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

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

На вопрос:

• Развивать или не развивать ИС в дальнейшем?

как правило, заказчики для себя отвечают перед внедрением, но вот на вопросы:

• Какое выбрать направление для развития?
• Каким образом?
• Что именно?

отвечают не сразу, так как считают, что ответы на них и так интуитивно понятны и определены (Зачем же мы тогда по-Вашему её внедряли?), а многие оставляют их ответы на потом, специально, чтобы не забивать себе голову подобной «ерундой».

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

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

• Пассивный подход
• Активный подход
• Предпроактивный подход
• Проактивный подход

Все 4 подхода живут и здравствуют в различных типах компаний.

Пассивный подход

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

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

Подход очень похож на принцип работы ГОЧС - «Экстренное реагирование при чрезвычайных ситуациях». Отреагировали, дыру залатали, а дальше пусть об этом думает кто-то другой (Вот только кто?)

Таким образом, рассматриваемый тип подхода можно охарактеризовать как проект, который развивают (вообще этот глагол к данному типу подхода сложно применим) по остаточному принципу, если «будет свободный ресурс». А у Вас он когда-то бывает?

Активный подход

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

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

Проактивный подход

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

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

Вышеупомянутую методологию ТРИЗ можно отнести именно к этому подходу. В подобных типах подходов к развитию ИС нам в принципе не обязательно общаться с пользователями, мы можем заранее спрогнозировать то, что им понадобится в будущем, но это не всегда работает, особенно если учитывать психологию людей. На определенных этапах работы с пользователями у них появляется ощущение того, что все изменения, какие-бы великолепные они не были, им навязывают. После чего появляется психологический блок, и решение задач заходит в тупик. Ключевые пользователи относятся к ИС как к своей младшей дочери и тоже эпизодически хотят влиять на её рост и развитие, поэтому так необходимо общение с пользователями при каждой доработке, даже если Вам уже очевидно, что и как делать дальше. Существует риск нарваться на слова пользователей: «А мы не ИМЕННО такое хотели!».

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

1. В решении должно быть учтено мнение заказчика о развитии (Причем представителя заказчика, занимающего как можно более топ положение)
2. Решений должно быть несколько. Не только основное, но и ряд альтернативных доработок. Это имеет смысл не только для выявления лучшего варианта, но и для сравнения их между собой
3. Решение учитывает объективно существующие обстоятельства, но они, как было показано выше, не очень основательны и могут быть изменены.

Только этого списка достаточно для того, чтобы понять, что если нет заказа с четкими требованиями и четким пониманием цели, то объективный прогноз составить затруднительно, и все усилия будут тщетными.

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

Предпроактивный подход

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

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

1. Не оценит
2. Не поймет
3. Будет воспринимать как что-то инородное и чужое.

Порой слишком перспективный взгляд вперед остается непонятым и недооцененным. Большинство мыслит категориями сегодняшних обязанностей и не стремится заглядывать далеко вперед. Аналитик должен быть подобен хорошему шахматисту, который в состоянии просчитать несколько шагов вперед, но при этом быть в состоянии их изменить в зависимости от того, как будет вести себя соперник. Пожалуй, лучше всего это охарактеризуется определениями «тактик и стратег». У Вас есть маленький сын, учащийся в 3 классе, который постоянно мучает Вас вопросами по математике. И Вы уже подсознательно ощущаете, что растет будущий талант именно в этой области. Вы, как заботливый отец, не вручите ему сразу талмуд по тригонометрии, добавив к нему методичку по алгебре для поступающих на мехмат. А почему? Потому что, как имеющий опыт мыслящий взрослый, Вы прекрасно понимаете, что до этих знаний он должен дорасти и быть к ним готовым. Именно поэтому Вы отправите свое чадо к заботливому репетитору, который будет пестовать и развивать Вашего ребенка. При этом Вами не может быть не учтен тот факт, что за 7 лет, которые остались до поступления в ВУЗ, взгляды и предпочтения юного математика могут кардинально измениться. Вот так же стоит подходить и к заказчикам. Они те же самые «дети» в той области, где Вы уже подросток :).

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

Об анализе информации

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

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

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

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

Авторы статьи

Иван Никитин

Михаил Цулая