Boatman's Home:  О сайте   Новости   Карта  
Статьи и заметки о менеджменте и системном анализе в ИТ + мысли о трудовых отношениях, рынках труда, услуг и программных продуктов
Это страница на старом движке. Новые статьи здесь
2011-07-21 05:50    Boatman   Обсудить в Google Groups   Перейти на страницу обсуждений

Данная статья создана для размещения на сайте boatmanshome.ru. Автор и обладатель исключительного права на эту статью - Нужненко Сергей Александрович.
Для данной статьи автор разрешает размещение ссылок и цитирование, а так же воспроизведение в личных и учебных целях.
Без согласования с автором запрещается для данной статьи или любой ее части воспроизведение в коммерческих целях, а так же любые распространение, публичный показ, импорт с целью распространения, прокат, переработка, сообщение для всеобщего сведения.
Для согласования видов использования статьи можно связаться с автором по e-mail: haron@ru.ru с пометкой в теме "Boatmanshome-text-use".

ШСА Введение

Что случилось
Благодарности
Термины и сокращения
ОПСА в ИТ
   Дисциплина
   Роль аналитика
   Контекст работы аналитика
   "Эффект бабочки", управление требованиями умерло и все такое
      Бабочка
      Ральность-модель-реальность и практическое мышление
      Управление требованиями умерло
      Квадрант Бескова
      Драма под названием "качественная работа аналитика"
   Работа аналитика изнутри и инструменты
Мантры аналитика

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

Те, кто присоединился к нам только что, ничего не пропустили.

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

Что случилось  ^

Летом 2011 года мы совместно с Денисом Бесковым и Тёмой Казаковым проводим мероприятие под названием "летняя школа систмного анализа".

Вот ссылки на анонс у Дениса .

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

Формат занятий - 1,5 часа практики и 1,5 часа теории 12 летних воскресений. В общей сложности 36 аудиторных часов и домашние задания для слушателей.

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

Благодаря решительности Дениса и Тёминой легкости на подъем этот курс появился на свет. Мы решили отказаться от длительной проработки материалов, сделав ставку на живое выступление у флипчарта по предварительно обсужденным тезисам. Это несколько снизило качество подачи по сравнению с конференцией или тренингом, но позволило выпустить курс в приемлемые сроки и в доступных ресурсах.

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

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

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

Благодарности  ^

Я выражаю благодарность Денису Бескову и Тёме Казакову за участие в создании и предварительном прогоне материалов, за их силы, вложенные в организацию подготовки и проведения школы.

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

Без вас эти строки не увидели бы свет.

Термины и сокращения  ^

Ниже часто будут применяться без расшифровки следующие вещи:
- АС - автоматизированная система;
- ПП - программный продукт;
- ПО - программное обеспечение.

ОПСА в ИТ  ^

И теперь мы начинаем с обзора структуры курса.

В центре нашего внимания стоят дисциплина с рабочим названием "прикладной системный анализ в ИТ", роль аналитика в ИТ проектах и работа, выполняемая этой ролью.

Рассмотрим это подробнее.

Дисциплина  ^

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

Вот список:
- Программная инженерия;
- Менеджмент;
- Психология;
- Социология;
- Маркетинг;
- Философия науки;
- Математика;
- Инженерное дело;
- Прикладные знания и практики предметных областей бизнеса (с которым приходится иметь дело).

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

Роль аналитика  ^

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

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

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

Имеется ввиду то, что сами по себе "анализы" не требуются.

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

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

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

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

Контекст работы аналитика  ^

Входы и выходы работы аналитика показаны на рисунке ниже.



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

"Эффект бабочки", управление требованиями умерло и все такое  ^

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

Бабочка  ^

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

Для того, чтобы говорить далее на одном языке, нам необходимо обсудить базовые термины и подходы, лежащие в основе всего курса.

Начнем с понятия проект и смежных терминов.

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

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

Проектирование деятельности, ведущей нас к реализации проекта мы назовем планирование.

А все фазы работ, которые присутствуют в модели "бабочки" следующие:
- исследование,
- анализ,
- синтез (проектирование),
- планирование,
- реализация.



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

Вот пример:
- бизнес планирует получение прибыли за счет ускорения некоторых операций у пользователей;
- представители пользователей планируют ускорение работы на определенных участках работы за счет определенных технических возможностей;
- технологии предоставляют требуемые технические возможности за счет создания технической системы или продукта.

И тут мы видим место для применения талантов аналитика:
- обеспечение связности и реализация (или организация) цепочки исследование-анализ-синтез;
- обеспечение связности и организация коммуникации между различными точками зрения.

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

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

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

Ральность-модель-реальность и практическое мышление  ^

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

Сама по себе теория хороша и необходима. Однако, здесь мы ее переписывать не будем и будем считать, что читателю известны базовые факты из теории систем. Если неизвестны - это ничем не помешает в освоении данных материалов.

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



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

Это самые страшные и достаточно частые ошибки в работе аналитиков, которых я встречал.

Обычно неудачи в донесении решений потребителям и неудачи в передаче ответственности сразу видны и обычно не отрицаются, а значит быстрее исправляются.

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

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

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

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

А сейчас я предлагаю прибрести две хорошие привычки:
- в ответ на получение любой информации снаружи или после вывода какого-то суждения спрашивать: "что (с этим) делать?";
- при выводе любых суждений спрашивать себя "откуда брались исходные посылки: все ли непосредственно из реальности?".

Управление требованиями умерло  ^

Теперь давайте более детально разберем понятие требования и за что я его иногда не очень люблю.

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



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

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

Квадрант Бескова  ^

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

Детально о контекстах, как я надеюсь, мы еще расскажем, а сейчас просто посмотрим на них:
- разработка ПО:
-- внутреняя:
-- заказная,
-- массовое ПО дл продажи на рынке;
- построение АС:
-- силами интегратора и ИТ консультантов,
-- своими силами;
- организационные изменения:
-- своими силами,
-- под руководством управленческих консультантов.

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



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

Драма под названием "качественная работа аналитика"  ^

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

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

Это краткое определение рождает драматический расклад вокруг роли аналитика. Давайте смотреть, почему.

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

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

Сказано - сделано, подписываем контракт.

А потом
- разработчики приходят и говорят, а вот тут нам не ясно, как обрабатывать ошибки - не хватает альтернативных сценариев или не удается реализовать некоторые нефункциональные теребования;
- тестировщики обнаруживают, что не по всем требованиям можно протестировать;
- документописатель, получив в руки продукт, обнаруживает, что не все ясно, как им пользоваться;
- менеджер проекта срывает сроки;
- пользователи увидев продукт объявляют: "это не то, что мы ожидали";
- заказчик негодует;

А потом это все еще надо внедрять, эксплуатировать и выводить из эксплуатации (кто сталкивался с миграцией данных из заменяемых систем - понимает, о чем я).

И во всех этих неприятностях есть доля недоработок аналитика. Проблема лишь в том, что невозможно отделить качество проекта от качества планирования и качества реализации. А там в цепочке есть еще и исследование с анализом.

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

Вы думаете заказчик или пользователи?

А как вы думаете, это виды требований никто и никогда ранее не предъявлял к подобным системам?

Те же вопросы можно задать про тестируемость, реализуемость, противоречивость требований.

А что, если требования были выявлены, но отвергнуты заказчикам из-за высокой стоимости реализации, но это не было записано?

А кто виноват в том, что то, что сказали и подписали пользователи не является тем, что они ожидали в итоге?

А если требования были не поняты сторонами одинаково и в итоге получился сюрприз?

Я это все веду к списку свойств хороших проектных решений:
- полнота;
- реализуемость;
- проверяемость;
- обоснованность;
- непротиворечивость;
- понятность;
- нужность (ясно, какие цели/проблемы они закрывают).

С точки зрения современных техник управления требованиями важны еще атомарность и трассируемость.

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

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

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

Работа аналитика изнутри и инструменты  ^

Сделав небольшое отступление в систему убеждений, используемых в нашем курсе, мы возвращаемся к обзору структуры курса.

Итак, аналитику требуются базовые знания своих предметов труда, а именно их свойств, основных моделей и закономерностей существования:
- Люди;
- Организации;
- Деятельность/функционирование;
- АС и ПП;
- Рынок;
- Особенности и законы работы с информацией;

Базовые навыки и умения аналитика заключаются в
- умении исследовать реальность с получением модели:
-- идентификация объектов,
-- исследование границ,
-- классификация и таксономия,
-- базовые структуры описания реальности,
-- работа с контекстом;
- умении интерпретировать и сверять модели с реальностью:
-- форматы представления моделей,
-- материализация модели,
-- использование "общего вида";
- умении преобразовывать одни модели в другие:
-- формальная и модальная логики,
-- установка целей и границ моделирования,
-- анализ и синтез с использованием метамоделей.

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

В управлении всеми этими циклами нам помогают еще два вида работ:
- управление аналитическими работами;
- учет и управление проектными решениями.

Все написанное выше входит в материалы курса ОПСА в ИТ. К этому необходимо добавить понимание работы аналитика в разных контекстах из квадранта Бескова и описание структуры курса станет полным.

Мантры аналитика  ^

Теперь кратко перечислим, что должен повторять начинающий аналитик каждый вечер перед сном:
- я благодарен Денису Бескову, Тёме Казакову и Сергею Нужненко, а так же слушателям первого набора ШСА (лето 2011) за появление материалов курса ОПСА в ИТ.
- я интересуюсь смежными дисциплинами;
- я совмещаю несколько ролей;
- результатом моей работы являются проектные решения, принятые потребителями (решений) и другими заинтересованными сторонами;
- я умею исследовать деятельность, организации, рынок, умею работать с людьми и информацией, представляю себе процессы, протекающие в автоматизированных системах и программных продуктах как внутри, так и снаружи;
- я участвую в цикле исследование-анализ-синтез-планирование-реализация и слежу за последствиями подготовленных мной проектных решений на протяжении всего жизненного цикла АС/ПП;
- я слежу за реалистичностью исходных посылок, правильностью вывода и интерпретируемостью результирующих моделей;
- получая или передавая информацию я всегда знаю ответ на вопрос: "что (с этим) делать?";
- я мыслю категориями проектных решений и преобразования информации, так как управление требованиями умерло;
- я учитываю контекст, в котором работаю и выбираю правильные ключевые результаты своей работы в данном контексте;
- решения, которые я готовлю приемлемы сейчас и оправданы впоследствии.

Я благодарю читателя за интерес к этой статье. Продолжение следует, надеюсь, скоро.