Как узнать, чего хотят клиенты. Десять рекомендаций

Философия бизнес-анализа в IT-проектах, или Кто такие бизнес-аналитики

Кто должен заниматься бизнес-анализом в IT-проектах? До сих пор встречается такое мнение: если требуется создать программу для автоматизации деятельности предприятия, нужно найти программистов и рассказать им, что требуется автоматизировать. Когда-то, лет 20 назад, это могло иметь место. Но сейчас такой подход выглядит так же, как если для создания нового космического корабля достаточно найти инженера-рационализатора. Программные продукты, как и требования бизнеса к ним, стали гораздо сложнее. Прежде, чем приступить к разработке программного продукта, необходимо выяснить реальные потребности бизнеса, спроектировать архитектуру системы, организовать работу команды специалистов, разработать программный код, спроектировать пользовательский интерфейс, разработать сопроводительную документацию, протестировать полученный продукт…

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

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

Рождаются ли аналитиками? Наверное, при рождении все мы аналитики. Когда ребенок впервые видит окружающий мир, новые предметы, он пытается их исследовать: потрогать, попробовать на вкус, покрутить в руках, бросить, разобрать. Потом человек учится ходить, начинает бегать. Если начать развивать такую врожденную способность, как бегать, можно стать спортсменом. Или не стать. Подобным образом развиваются и аналитические способности. Для этого требуются определенные знания, навыки, практика, упорство. Поэтому, далеко не каждый взрослый человек является аналитиком на уровне, достаточном для бизнес-анализа.

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

Не много ли? Так ведь это далеко не все! Кроме замечательных вышеперечисленных качеств, он должен быть еще и грамотным (в смысле языка), уметь системно излагать свои мысли, владеть инструментами для оформления своих мыслей (например, соответствующими программными продуктами), разбираться (или очень быстро учиться) в различных предметных областях (например, отраслях деятельности), разбираться во внедряемом программном продукте (если речь идет об автоматизации), обладать развитыми коммуникативными навыками и уметь расположить к себе собеседника, владеть техникой переговоров и обладать стрессоустойчивостью. Ну вот… Этого набора, пожалуй, хватит для вполне приличного аналитика. Если вы не готовы освоить 80% перечисленных способностей, лучше и не начинайте, а то пополните армию клоунов, именуемых себя аналитиками.

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

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

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

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

Как стать хорошим бизнес-аналитиком

Шаг первый: прочитать предыдущий раздел и подумать: «правильную ли профессию вы себе выбрали?» Если да, значит не остается другого выбора, кроме как перейти к шагу второму и начать развивать необходимые навыки. Давайте попробуем составить программу обучения хорошего бизнес-аналитика.

1. Личная эффективность и коммуникации

1.1. Посмотрите пару хороших тренингов по переговорам. А лучше посетите их вживую. В крайнем случае, купите хорошую книжку. Да и вообще, не упускайте возможности попрактиковаться. Аналитику нужна постоянная тренировка и развитие навыков общения. Из доступных видеотренингов могу порекомендовать Радислава Гандапаса.

1.2. Освойте основы тайм-менеджмента. Научитесь есть слонов и лягушек (если кто не понял ― наберите в Яндексе «Как съесть слона» или «как съесть лягушку», узнаете много интересного). Вам всегда будет не хватать времени. Из литературы можно посоветовать Глеба Архангельского (у него просто компактно собрано то, что встречается в большом количестве переводной литературы по тайм-менеджменту).

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

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

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

1.6. Вырабатывайте способность к стрессоустойчивости. Мне ни раз приходилось видеть слезы на глазах аналитиков, слушать, какие гады работают у Заказчика и пр. Люди бывают разные, и аналитику неизбежно придется столкнуться со сложными типами личности, с которыми трудно договариваться, настроить на конструктивную работу. Поэтому, нужно быть еще и немного психологом. Ни в коем случае нельзя подменять стрессоустойчивость безразличным отношением к работе! Это совсем разные вещи.

2. Знания и навыки

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

2.2. Подберите себе какой-нибудь инструмент для наглядного представления информации (в смысле программу). В простейшем случае это может быть и обыкновенный MS Office. (Visio решает множество задач по наглядному представлению информации).

2.3. Необходимо понимать архитектуру программного продукта. Еще лучше, если аналитик обладает навыками разработки. Чаще общайтесь с программистами. Посетите курсы для разработчиков, хотя бы основы. Это обязательно даст результат. Или, как вариант, попросите разработчиков организовать для вас внутренние курсы по архитектуре внедряемой системы.

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

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

3. Опыт

3.1. Вы знаете хорошего аналитика из своего окружения (коллегу, например)? Если да, проситесь стажером к нему на проект. Отбросьте амбиции. Наблюдайте. Слушайте. Учитесь. Делайте выводы. Это будет отличным стартом.

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

3.3. Учитесь предсказывать риски. Как это делать? Попробуйте начать с простого: записывайте свои опасения по проекту в отдельное место, независимо от их величины и стадии проекта. Подумайте, к чему они могут привести. Потом периодически просматривайте свои записи. Когда решите, что вы научились формулировать опасения адекватно, озвучивайте их команде. По окончании проекта также стоит вспомнить, какие причины создавали проблемы. Если проделывать подобную работу регулярно, навык предсказывать риски обязательно выработается (конечно же, не сразу, но никуда не денется). На этот счет есть разные мнения, в том числе и такое, что все члены команды должны сразу высказывать свои опасения. Я с этим полностью согласен. Однако в практике встречаются такие участники, которые целыми днями высказывают безумные опасения, потенциальный ущерб от которых гораздо меньше, чем время, затраченное ни их озвучивание и выслушивание.

3.4. Нужно научиться брать ответственность за принятые решения. Аналитик должен отвечать за свои методические решения. Не надо бояться, если они оказались ошибочные. Гораздо лучше сказать «я тут ошибся, давайте подумаем, как можно решить возникшую проблему», чем пытаться оправдаться или сваливать вину на других.

3.5. Старайтесь набраться столько опыта, чтобы вы смогли на два шага вперед предугадать то, что захочет клиент. Это не просто. Существует такое понятие, как неявные требования (или, как их иногда называют «недосказанные», «очевидные», «подразумеваемые», что с точки зрения требований синонимы). В реальности пренебрежение такими требованиями может вызвать немало вопросов и даже конфликтов. Например, для клиента может быть очевидно, для учета денежных сумм в программе должно быть предусмотрено 20 знаков (у него в существующих программах сейчас так и всегда так было), а во внедряемой системе, к примеру 15. Конечно, обычно это не сложно доработать, но потребует времени. Где-то число не вместится на форме, где-то придется расширять макеты в печатных формах и пр. Для работы с неявными требованиями удобно использовать контрольные списки («чек-листы»). Содержание таких списков зависит от опыта конкретного консультанта в своей области.

3.6. Научитесь излагать свои мысли четко и лаконично. В этом поможет только практика и изучение материалов других аналитиков.

4. Обучение и перспектива

4.1. Правильно выбирайте место работы. Если есть ощущение, что на существующем месте работы нет шансов стать толковым аналитиком, хорошо подумайте о смене работы. Хорошие аналитики всегда нужны.

4.2. Отраслевые знания. В каждом проекте старайтесь изучать отраслевые особенности нового бизнеса. Сделал и забыл ― это про другую профессию. Аналитику нужен накапливаемый опыт.

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

Практические рекомендации для улучшения эффективности извлечения и анализа информации

Для эффективной работы стоит продумать ряд организационных вопросов:

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

2. Как фиксировать полученную информацию? Записывать полученную информацию необходимо в обязательном порядке. Если просто слушать и ничего не записывать, вы рискуете произвести плохое впечатление. Да и не запомните всего. В простейшем случае можно записывать ручкой на бумаге. Некоторые предпочитают вести запись на компьютере (но я не сторонник такого подхода). Удобно, если вы узаконите использование диктофона. Тогда ничего не потеряется. Правда, придется тратить время на прослушивание, но если грамотно строить речь исходя из того, что ведется аудиозапись, то эффективность получится отличная. Есть простые правила для улучшения восприятия аудиозаписи. Когда идет длительное обсуждение или дискуссия, надо всегда подводить итог и проговаривать то, как вы поняли услышанное и какие выводы сделаны. Если что-то показывают на компьютере, надо вставлять «голосовые комментарии» ― проговаривать то, что происходит. Когда вы будете документировать результат и одновременно прослушивать аудиозапись, потерянного времени практически не будет. А когда научитесь использовать технику аудиозаписи, то достоинства с лихвой перекроют недостатки. Как показывает практика, аудиозапись приходится слушать один или два раза параллельно документированию. Отсюда, кстати, можно сделать вывод, что на документирование результата встречи уходит в полтора-два раза больше времени, чем на саму встречу (под документированием в данном случае имеется ввиду подробное описание, включая графическую визуализацию процессов при необходимости). Результат договоренностей надо обязательно фиксировать в письменном виде. Хорошей практикой является использование протоколов рабочих встреч. Подготовьте для себя шаблон протокола, где будет информация об участниках встречи, времени, повестке вопросов и результатах.

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

• Договаривайтесь о встрече всегда заранее, планируйте достаточное количество времени (обычно два-три часа).
• Если вам уже известно что-то о деятельности сотрудника (службы) в качестве начала беседы можно использовать краткое резюме из известной информации примерно на одну-две минуты. Так и скажите: «По имеющейся у меня информации, вы занимаетесь … и так далее.», после чего сообщите, что хотите поговорить об этом подробнее.
• Может так случиться (точно случится), что сотрудник начнет рассказывать какие-нибудь тонкости технологии своей работы, которые, по мнению аналитика, не имеют значения на данном этапе работ, или вообще имеют слабое отношение к текущему проекту. А сотрудник может рассказывать об этом долго и увлеченно. Что делать, прерывать или нет? Некоторые специалисты советуют не прерывать ни в коем случае, иначе сотрудник обидится, замкнется и прочее. С другой стороны, если вы будете его слушать бесконечно, то не переслушаете, а времени потратите много. Есть разные способы направления диалога в нужное русло. Например, можно сказать, что «описываемый вопрос очень важен и интересен, но для этого лучше организовать отдельную встречу, а сегодня лучше поговорить о…». Можно дать возможность сотруднику порассуждать над волнующей его темой (если она явно не относится к теме встречи), но заранее определить себе время, которое мы можем на это потратить. Например, если 5 минут не имеют особого значения, пусть выскажется, после чего необходимо скорректировать направление диалога наводящим вопросом. Кстати, анкеты хорошо помогают держать диалог в конструктивных рамках. Если сотрудник явно начинает уходить в сторону, а в анкете об этом ни слова, можно так и спросить, почему он никак не упомянул об этом в анкете? Если скажет, что забыл, можно просто попросить письменно сформулировать свои мысли и продолжить дальше. Возможно, он скажет, что вопрос имеет низкий приоритет важности и он не стал о нем писать в анкете. Тогда можно предложить перейти к более важным вопросам, а к этому вернуться, если останется время. Не забывайте, что людям свойственно дольше говорить о том, что они лучше знают, а не о том, что от них хотят услышать.
• Если возникают вопросы по ходу изложения информации интервьюируемым сотрудником, не всегда следует задавать их сразу. Лучше фиксировать свои вопросы по ходу беседы, а задать их, когда человек закончит мысль. Задавать их сразу следует только тогда, когда они будут уместны в поддержании техники активного слушания. В дискуссии на данном этапе точно вступать не следует.
• Обычно в опросах участвует один аналитик. Но, бывает, что опрос провидится и в паре (например, аналитик и стажер, или аналитик и руководитель проекта). В этом случае нужно договориться о порядке задавания вопросов, чтобы не перебивали друг друга, а опрашиваемый сотрудник не чувствовал себя как на допросе. Например, задает вопрос всегда один человек, а когда он получит ответ, спрашивает у второго, есть ли у него еще вопросы на данную тему. Затем перешли к следующей теме и так далее.
• Как и в любых переговорах, проговаривайте сами ключевые моменты и получайте подтверждение того, что вы поняли все правильно
• Глупых вопросов бывает очень мало. Если есть хоть малейшее сомнение, но вопрос вам кажется глупым ― забудьте об этом. Лучше возьмите и спросите. Даже очевидные вещи бывают неочевидными.
• Если опыт позволяет, можно не только задавать вопросы, но и предлагать свои решения. С этим методом нужно быть аккуратнее, т.к. можно сбить с настроя опрашиваемого.

4. Как бороться с внутренним сопротивлением при опросе. Опрос ― это по сути первый визуальный контакт консультанта с персоналом. И не все отреагируют на него одинаково. Обязательно найдутся те, кто будет в силу разных причин не заинтересован в том, чтобы кто-то погружался в особенности его деятельности. И начинающие аналитики даже не представляют, какие экзотические причины встречаются на практике, что вводит их в депрессию вплоть до увольнения. Как с ними бороться? Лучше всего, постараться найти подход. Если не удается, то самым эффективным способом является углубленная формализация отношений на вверенном такому сотруднику участке. Доводите до руководства, что данный участок деятельности будет вынесен за рамки проекта. Или добивайтесь письменного подтверждения того, что на данном участке будет применяться полностью типовая модель учета, заложенная в программном продукте. Как привило, у руководства не останется выбора, кроме как жестко надавить на такого сотрудника. Но, главное, что бороться с ним вы будете не за счет своих нервов. В большинстве случаев, сопротивление обусловлено тем, что сотрудник занимается не очень нужной работой, или никто вообще не понимает, чем он занимается. Если работа не пыльная и не суетливая, то вполне естественно, что ему ничего не хочется менять, иначе он бы уже ушел на другую работу. Если ситуация совсем плохая, можно разработать тактику вывода такого сотрудника из проекта. Обычно это заканчивается его увольнением. На практике мне приходилось заниматься довольно жестким прессингом таких сотрудников, но после их ухода проект начинал оживать. Если с подобной ситуацией просто мириться из состояния «клиент всегда прав», проект может зайти в тупик или перейти в разряд глубоко убыточных. Надо четко понимать, что инициаторы проекта подобными лицами не могут быть по определению. Если вам так кажется, скорее всего, их просто не услышали и проект идет не в том (которое они ожидали) направлении.

5. Что делать с вопросами конфиденциальности? Чтобы не возникало вопросов типа «это нам нельзя говорить», «это конфиденциально» и тому подобное, проговорите заранее, как будет решаться вопрос конфиденциальности. Заключите соглашение о конфиденциальности, если это поможет.

6. Надо ли потом подтверждать правильность понятой информации? Безусловно, надо. После того, как вы опишите полученную информацию, обязательно отправьте ее источнику информации для подтверждения или корректировки. В конце обсуждения старайтесь подвести итог, где кратко зафиксируйте результаты понятой информации (резюме встречи).

7. Непрерывный анализ информации. Даже если вам говорят много и долго, не вся информация может оказаться полезной. И не вся информация представлена системно. Это и есть работа аналитика ― анализировать информацию, а не быть стенографистом, что часто случается среди начинающих аналитиков: «Было заслушано мнение Сергея Петровича по вопросу ввода в программу информации о новом товаре. Сергей Петрович считает, что сначала надо вводить …» ― ну что за бред? Хотя взято из реального протокола. Не надо воды в протоколах ― только принятые решения.

8. Техники задавания наводящих вопросов.

• Если вы не уверены, что описываемый процесс выглядит именно так, попробуйте позадавать сценарные вопросы вида «А что, если …».
• Вспомните аналогичный проект и какие трудности в нем возникли. Позадавайте вопросы вокруг причин этих трудностей. Если у вас не было похожего проекта, спросите у коллег.
• Изучайте отрасль клиента и не стесняйтесь задавать ему вопросы об отрасли. Рассказывая об отрасли в целом, он обязательно начнет оговариваться в стиле «вот у нас это делается так-то…», что позволит получить дополнительную информацию или поможет сформулировать правильные вопросы.

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

10. Ясность мыслей. Вырабатывайте хороший стиль построения фраз при изложении мыслей, как устно, так и письменно:

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

Типичные ошибки аналитиков, связанные с особенностями личности

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

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

Фото: pixabay