Soft skills для аналитиков

Видели когда-нибудь, как стекленеет взгляд у людей в аудитории? Или сталкивались с тем, что в конце доклада или встречи люди задают абсолютно "левые" вопросы, не связанные с темой встречи? Это все связано с теми ошибками, которые совершаются при взаимодействии с целевой аудиторией. Информационная перегрузка Мы живем в эпоху твиттера и шортсов на youtube, поэтому не нужно думать, что люди готовы воспринять и запомнить большой объем информации в короткие сроки. Тренд на скорость - это даже не тренд, это объективная реальность в мире, где все быстро меняется. У людей уже нет привычки спокойно сидеть, слушать и анализировать (и нет, вам это не изменить, смиритесь)...

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

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

Мне кажется, что 90% аналитиков в той или иной мере общаются с конечными пользователями. Особенно - на этапе опытной эксплуатации или активного внедрения системы. Работа с людьми требует эмоциональной выносливости (на кого тут еще не орал пользователь?), построения личных границ и доли участия к проблемам людей. Это сложно балансировать, но нужно пытаться найти общий язык с клиентами - в долгосрочной перспективе вы продлеваете своей компании возможность работы с этим заказчиком, а себе добавляете очков в карму. IT сообщество маленькое, плохое впечатление живет долго. Как же работать с пользователями,...

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

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

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

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

Скажу сразу - приоритезировать свои задачи сложно. Я дошла до четких установок про то, как приоритезировать только тогда, когда несколько лет после работы аналитиком поработала Product Owner'ом, менеджером проекта и руководителем отдела. Поэтому все, что ниже - это взгляд на работу аналитиком под призмой того, как на это все смотрит ваш "руководитель". Далее я буду применять термин "руководитель" очень вольно - это может быть любой член команды, который отдает вам больше одной задачи в один период времени, без указания в каком порядке делать задачи. Потому что в таком случае он берет задачу приоритезации на себя...

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

Человеку, который приходит в профессию аналитика, кажется, что фраза “сбор требований” в описании вакансии - это самое понятное и не страшное. Это не описание бизнес-процессов в определенной нотации, ни схема взаимодействия компонентов. Что может быть страшного? Но первая же попытка прийти к заказчику оборачивается провалом - и под провалом я понимаю разработчиков, которые требуют сформулированных задач, или менеджера проекта, который требует согласованных требований от бизнеса. А что есть у аналитика? Мемо, где заказчик распинается о проблемах и абсолютное непонимание от аналитика, что же именно происходило на встрече...