#типичныеошибки #системныйаналитик #сбортребований #капитаночевидность #какненужноделать #мысливслух #мойопыт

Расскажу про частые ошибки аналитиков. Особенно хорошо это видно на менторстве.

1.Номер один это паттерн поведения "я всё знаю и знаю лучше заказчика, что ему нужно". Часто такой Паттерн у руководителей проектов, либо аналитиков, которые пришли в профессию из смежных направлений из разработки, тестирования. И вспоминаем график, джуны часто думают о том, что всё знают и что там делать то.
2.Следующие грабли - это навязывать решение или фичи, которые не нужны заказчику. Но аналитик считает, что оно круто или я это видел у конкурентов. Наш велосипед ещё не едет, но давайте повесим фонарик или ещё лучше наклейки сделаем или счётчик расстояния, спидометр. И из велосипеда сделаем обвешенную погремушку, а в финале поймём, что не едет и надо бы накачать колеса.
3.Нефункциональные требования. Или как их называет Сергей Нужненко "волшебные" требования. Тут просто срабатывает триггер мозга "сложно, не хочу, не буду, неинтересно". В итоге на наш велосипед сможет сесть только ребёнок, потому что средний вес пассажира никто не сказал. Или велосипед просто угнали, а может сделали таких размеров, что он не влезает никуда и вообще стандарты, ГОСТы, ISO это для слабаков и это скучно.
4.Ещё аналитики очень любят рулить всем, стараются залезать в решение, архитектура, сроки, бюджеты и ныть, что всё ужасно. Я сама такая же))) и тут стоит возвращать себе свою роль и границы её, где и за что отвечает аналитик? А нытьё можно превращать в риски и анализировать сценарии, что может пойти не так и реализоваться в будущем.

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

У вас есть шанс запрыгнуть в уходящий завтра поезд и поучаствовать в тренинге по сбору требований, где мы будем в том числе совершать типичные ошибки аналитиков, и понимать, как с ними справляться, на что обращать внимание, чтобы в будущих проектах работать эффективнее и стабильнее!🚀
А также будем практироваться в формулирование требований, а том числе и в Agile подходе.✅

Присоединяйтесь, анонс был выше! 😎

Я боюсь, что разработчики решат, что я дурачок.

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

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

Что могу сказать...
Пусть будет взрыв!
Пусть назовут дурачком. Вы то знаете о себе правду лучше других 😎

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

Но я много раз в свою сторону получала взрыв эмоций под названием "какой мудак это написал!?"

Раньше я переживала, а теперь я понимаю, что такие эмоции это моё оружие. И когда все партизаны вокруг и ничего не говорят, я могу подготовить несколько вариантов диаграммы (а почему бы и не да!).
Сначала показать ту, которая вызовет взрыв эмоций, и на этих эмоциях "всё не так", я получу ответ, а "как надо". Только записывай. А если этот вариант совпадает с тем, что у меня есть в портфеле вариантов, то я как фокусник из рукава достану вариант со словами "а кстати говоря, у меня есть то, о чем вы говорите, так хотели бы? Посмотрим вместе?"

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

Хитро? Наверное.
Работа выполнена? Да.
А о способе получения информации уже никто и не вспомнит.

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

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

А вы какие используете катализаторы в работе?

#сбортребований #катализатор #лайфхаки #капитаночевидность #системныйанализ #мойопыт #моемнение #выявлениетребований

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

#анонс #китайскаяручка #тренинг #сбортребований #требования

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

✅ Блок 1. Команда аналитиков проводить интервью с заказчиком и фиксирует требования.
Происходит согласование требований с заказчиком и исполнителем. В конце мы получаем продукт.

✅ Блок 2. Разбираем, как повысить качество требований, для этого их разбиваем на уровни. Понимаем где требование, а где описано решение. Вносим изменения.

✅ Блок 3. Описываем нефункциональные требования к продукту. Разбираем, атрибуты качества требований.

✅ Блок 4. Обсуждаем, как можно ДОвыявить требования, с помощью Story mapping, Impact mapping. Разбираем нюансы работы аналитика в гибких подходах к разработке ПО.

-------------------------------
💪Кому подойдёт тренинг?

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

Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно поучаствовать в тренинге. Со стороны посмотрите на свой опыт, увидите какие типичные ошибки вы допускаете, определите зону ответственности и роста аналитика, поймёте как структурировать свою работу.

Если вы аналитик с опытом от 3 до 5 лет, тренинг поможет систематизировать свои знания, увидеть тонкую грань между требованием и решением.

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

✔️Формат тренинга - онлайн, выходные, 2 дня по 4 часа (с 10 до 14 по Москве).

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

-------------------------------
Все материалы и записи тренинга остаются у вас в доступе, вы всегда можете вернуться к ним.

-------------------------------
Если остались вопросы пишите их ниже в комментариях 👇

Чтобы записаться на тренинг оставляйте заявку на странице ➡️
https://sup.expert/pen

Аналитик исследует проблему и проектирует решение на языке требований.

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

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

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

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

А ещё мне нравится фраза "скажите, что мне сделать, я сделаю"... Такое веяние социального давления, проще подстроиться, чтобы всем было хорошо. А когда задаёшь вопросы, копаешь, роешь, вызываешь негатив, эмоции, а это всё очень сложно. Хочется же попроще, правда?)

Зачем вообще исследовать проблему?
✅1.Элементарно понимать, что мы делаем, зачем и главное, как мы будем это сдавать заказчику.
✅2.Не знаю свежую статистику % успешных проектов, но от 80 до 90% айти проектов, продуктов провальны, по причине того, что мы делаем, то что никому было не нужно, никто это не просил, или не просил в таком виде.
✅3.Рост количества переделок, "не попадания в цель", становится критичным или дорогим. Тут зависит от сферы, часто B2C сервисы, могут позволить себе клепать быстро, чтобы захватить рынок или протестировать гипотезу. В B2G, B2C, в сложном Enterprise у нас нет права совершать множество ошибок и смотреть конечный результат, а потом разводить руками - "не шмогла, не шмогла..."
✅4.Так хочется сразу перейти к решению. Это в том числе наши любимые когнитивные искажения, нашему мозгу проще перейти в ту область, где мы себя чувствуем увереннее и понимаем о чем идёт речь. Подмена понятий, тоже сюда. Упростить и сразу говорить о решение. Эмоций больше, приятнее и есть ощущение действия, результата.

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

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

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

Вот такие сегодня местами сложные мысли)

#мысливслух #сбортребований #исследование #проектирование #правдажизни