Классические аналитические косяки

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

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

Итак, классические косяки.


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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

Вот тут важно помнить, что бизнес-требования - это такая штука, которая определяет скоуп проекта и общую стратегию функционирования проектируемого продукта в контексте Бизнеса. И что бизнес-требования - это ТРЕБОВАНИЯ. Т.е. к ним применяются все характеристики и свойства требований, включая критерии качества (можно посмотреть в Википедии). А их неправильное или некачественное определение является причиной глобальных рисков, лежащих и в финансовой плоскости проекта, и в плоскости его реализации.

Поэтому, когда Заказчик передает вам что-то и называет это бизнес-требованиями, надо не полениться и к полученному материалу сперва применить критерии контроля качества требований, а потом рассмотреть их в контексте автоматизируемого Бизнеса и попытаться найти их место в иерархии требований. Если вы убедитесь, что это бизнес-требования, то в добрый путь. А если нет, значит бизнес-требования необходимо сформулировать. Правда необходимость этого упражнения еще надо суметь доказать руководителю проекта, что является отдельной, порой весьма феерической, песней.

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


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

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

Комментарии

  1. "Бизнес всегда знает, что он хочет и зачем ему это" - могу поспорить на эту тему, у меня есть 2 противоположных примера.

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

    ОтветитьУдалить
  2. Основной аналитический косяк, он же камень преткновения - глубина детализации. А2, а также некоторые А3 не могут адекватно определить до какой степени нужно описывать функциональные требования.
    Часто происходит так: делают словесные описания БП, рисуют диаграммы, и на этом все. Когда дело доходит до, разработчиков, они сталкиваются с кучей креш-сценариев, вопросами по структурам данных, по интерфейсу и т. п., которые аналитик просто не продумал, хотя он может быть бесконечно крут в предметке.
    Реже происходит наоборот: аналитик детализирует требования так, что можно написать скрипт, который переведет русский язык в программный код. Все бы хорошо, только аналитик - не архитектор, он не может и не должен определять как система должна быть построена. Но если он пишет требования досконально, то это волей-неволей накладывает ограничения на принимаемые разработчиками решения. Чем туже требования, тем больше вероятность что разработчики скажут что решение получится кривое.

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

    ОтветитьУдалить
  3. Гриш, озвучь примеры, когда Бизнес не знает, чего хочет. Готов поспорить, что ходов через 5 мы оба убедимся в том, что аналитик прокосячил.

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

    Ну и спасибо, что не забываешь, заходишь... ;)

    ОтветитьУдалить
  4. Неудобная платформа этот блоггер — отслеживать комменты приходится вручную. Делаю это очень нерегулярно, так что если что - давай в скайпе чтоли

    ОтветитьУдалить
  5. Они ничего лучше не придумали, как подписка на комментарии по RSS или почтой. :)

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

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

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

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

    ОтветитьУдалить

Отправить комментарий

Популярные сообщения из этого блога

Драйв

Карта компетенции аналитика

Оценка эффективности работы руководителя проектов