Почти в каждом проекте заказчик что-то считает столь очевидным, что и не упоминает об этом, а разработчик так же молча игнорирует часть требований как абсурдные или же "неудобные".

Что сделать, чтобы противоречивые точки зрения, упущения и умолчания не исказили систему? Как организовать работы, чтобы в результате информационная система не была отторгнута потребителем или бесконечно долго не "доводилась до ума" под встречные обвинения сторон?

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

Первая точка зрения очень распространена среди программистов. Вторая свойственна заказчикам, относящимся к разработчику как капризный клиент к портному: "Я плачу деньги, а ты сделай, чтобы мне было хорошо. И без лишних вопросов и примерок". Но и то и другое ведет к искажениям требований.

Есть только один способ решения проблемы: правильное распределение функций в проектной группе. В этом отношении мне кажется важным написать об аналитиках и их "разновидностях", о том, ПОЧЕМУ и КАК они должны сегодня играть ключевую роль в построении ИС без искажений. Изложение основных функций аналитиков и других требований к ним я могу предложить как основу для должностных инструкций участников проекта, причем я адресуюсь не только ко многим разработчикам, но и к заказчикам информационных систем.

Корни и актуальность проблемы

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

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

Откуда берутся искажения

"Диполь Тыугу" — предельно простая, но очень полезная модель, показывающая источники искажений, возникающих при создании ИС. Придумал ее Э. Х. Тыугу, который 25 лет назад был известен как разработчик языка ПРИЗ для описания сложных программных комплексов преимущественно вычислительного характера. Мне его диполь много позже нарисовал В. П. Иванников, директор ИСП РАН.

  

В исходном варианте диполь (см. рис. 1) показывает, почему искажается восприятие двух участников проекта ИС: "заказчика" и "программиста". Суть в том, что каждому из них проблемы другой стороны видны "издалека", когда чужое становится мелким, а отчетливо видны детали только своих проблем.

  

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

Немудрено, что получающееся в результате "изделие" или отвергается, или вызывает долгие мучения.

Искажения сегодня

Чтобы почувствовать, сколь насущна эта тема, посетите оживленный форум "Высокий уровень российских программистов — это миф" (http://www.osp.ru/system/forum/), участникам которого было предложено ответить на вопрос, который можно передать так: "Почему ни одна команда программистов ни за какие деньги не смогла сделать то, что мне было нужно, даже за вдвое больший срок, чем сама же установила?!"

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

На втором месте была оценка, по которой беда и в том, что заказчик сам не знает, чего хочет, а если и чувствует, то выразить не может. Часто тут не помогает никакое прототипирование: сегодня у заказчика одни претензии, а завтра — чуть ли не противоположные. Такие коллизии губительны и для самых небольших проектов.

В связи с этим любопытно, что через несколько дней после начала форума возникла попытка ограничить "умные" разговоры про постановки задач утверждением: не удается получить от программистов результат и тогда, когда нужна программа всего-то в 1000 операторов Си, и уж точно не больше 3000. А в таких случаях нечего, мол, говорить о постановках, писать надо!..

Конечно, дело не в размере программы. Правильно написала на форум Ирина: как бы еще убедить заказчика в том, что ему в проекте нужен аналитик (постановщик, архитектор). Николай Склобовский подытожил: "Работа без аналитика обречена на провал!"

Но очень важно, что не раз прозвучала критика и в адрес программистов. Ирина, например, написала: "Хотя некоторые программисты пытались меня убедить, что они сами прекрасно могут поставить задачу, практика показывает: программисты не в состоянии справиться с этой проблемой".

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

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

Диполь+ +

  

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

Технолог-постановщик, он же бизнес-аналитик

  • Главные задачи технолога-постановщика — правильно понимать потребности пользователей и предприятия, ясно и полно их описывать в уместных формах. Постановщик ближе всего находится к заказчику и его задачам. Он "живет" в них, но умеет их обобщать, строить алгоритмические и прочие формальные и неформальные модели их решения. Он должен представлять себе общие возможности современных информационных технологий, но не забивая себе голову вопросами, характерными для специалистов по ИТ.
  • Очень часто постановщик не является сотрудником фирмы-разработчика или специализированного подразделения предприятия-заказчика (например, отдела программирования). Современные методики предполагают, что даже консалтинговая фирма, имеющая в штате своих бизнес-аналитиков, ищет таких людей у заказчика, находит с ними общий язык и включает в проектный коллектив.
  • От постановщика не требуется обязательного освоение формальных языков и моделей (таких, как модель потоков данных или UML — "унифицированный язык моделирования"). Он может использовать формализмы, но только для более точного описания внешних требований к ИС, а не для принятия решений в проектировании "компьютерной" части системы.
  • Постановщик может и часто должен формировать не только постановки отдельных задач, но и целостную концептуальную модель автоматизированного предприятия. Однако он строит такую модель на верхних уровнях архитектурного представления системы, в то время как CASE-модели лежат ниже.
  • Постановщику нужен очень простой и гибкий компьютерный инструмент для ведения документации: текстов, коллекций рисунков и схем, записей алгоритмов и ссылок на нормативные документы с извлечениями из них. Значительную часть своих наработок постановщику следует помещать в общую базу проекта, в ту ее часть, которая поддерживает "требования к системе".

Системный аналитик, он же — "архитектор ИС"

  • Системный аналитик рассматривает всю совокупность внешних требований к системе. Вместе с постановщиком он анализирует противоречия в них. Он находится немного дальше от заказчика, чем постановщик, но ближе к программисту (а также к специалисту по сетям и др.). С участием экспертов по ИТ он проверяет требования на приемлемость. В случае слишком большой стоимости или невозможности реализации он ищет альтернативные подходы.
  • Системный аналитик создает целостный "логический" проект ИС, в котором еще не производится выбор конкретных компьютеров, СУБД, инструментов программирования (если не ставить телегу впереди лошади). Главное здесь то, что он видит и описывает архитектуру ИС в целом, объединяя все ее "слои" — от людей и целей до данных и функций.
  • Системный аналитик принимает решения, интегрируя концептуальную модель предприятия с потенциально доступными возможностями ИТ. Ему нужно рассматривать и чисто технические решения, вместе с ИТ-проектировщиками проверяя выполнимость тех или иных требований и логических решений. Но окончательные решения по технической архитектуре он не принимает, это дело "главного инженера" и "главного программиста" ИС, хотя многие такие решения должны согласовываться с системным аналитиком.
  • Системный аналитик — сотрудник специализированного "компьютерного" подразделения или фирмы. Он владеет формальными моделями (по крайней мере на бумаге, так как CASE-системы не всегда окупаются). Он обязан оценивать эффективность своих решений и присущий им риск. Главное здесь то, что он представляет коллектив разработчиков ИС перед заказчиком. Он проверяет решения вместе с бизнес-аналитиками и пользователями, он объясняет систему первым лицами заказчика, защищает ее на совещаниях. По этим причинам действительно "все шишки — на него".
  • Иногда системный аналитик — это "главный архитектор ИС", иногда — член "архитектурной мастерской". Но когда его функции выстроены правильно, тогда и заказчик и программист должны считать его не "генералом" (вдруг да прикажет желтую траву в зелень красить?!), не "страшилой-начальником", а конструктором совершенно определенного, высокого уровня. Да, он должен проверять то, что реализуют программисты, на соответствие требованиям к системе и ее частям, но эти проверки — к общей пользе. Так же как и контроль, которому подвергают его самого в независимых экспертизах качества.

От "диполя+ +" к оргструктуре

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

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

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



Евгений Захарович Зиндер — директор аналитического и конструкторского бюро "Группа 24", координатор рубрики "Директору информационной службы". Ему можно написать по адресу ezinder@osp.ru.