Телеграм канал «Наташа Косинова. Варю айти СУП»

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

Пишу по пунктам алгоритм анализа, начиная с бизнес уровня:
1. Выяснить политический контекст ситуации. О чем договорились уже. Кто за что отвечает и какие есть, и есть ли, рычаги влияния. Тут по-хорошему карту заинтересованных лиц описать. И некий приоритет, кто в первом приоритете влияния.
2.Понять, что есть на нашей территории, и что мы делаем в рамках проекта. Иногда реально сложно понять, мы работаем над проектом или продуктом. Часто руководители говорят о продукте, но фактически его нет и идёт работа по проекту. У меня есть статья про разницу проекта и продукта, можно вот тут почитать.
3.Раз уже есть продукт или подобие продукта, а документы от заказчика противоречивые, то стоит изучить существующий вариант, по нему зафиксировать некий концепт. Проще всего предложить заказчику, то что уже есть.
4.Поговорить с коллегами, кто уже общался с заказчиком. По этим договорённостям составить тоже некий концепт. Я люблю графы, поэтому составляю mind maps по проектам.
5.Понять насколько то, что хочет заказчик или якобы хочет, отличается от текущей версии реализации (совместить один граф с другим, можно взять приложение yed, или если не нарушаем nda, то взять ИИ, и коллег).
6.Писать ТЗ за основу беря, то что уже реализовано. Тут подключать менеджеров для того, чтобы презентовать заказчику вижен по автоматизации.
7.Когда мы поймём разницу и то, что нужно доработать, пойти к тим лидам и архитекторам и с ними проговорить. Обозначить будет ли этот набор фич риском или нет. Если да, то в оценку включать риски.

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

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

🎯Главная цель - не написать в ТЗ, то, что будет "замедленной бомбой", а писать то, что 100% есть, а с другой стороны нужно заказчику и мы это 100% понимаем, если не понимаем, то лучше не писать)

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

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

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

Есть ещё такая, я бы сказала #ошибка_джуна или #смертельные_грехи_аналитика, когда не понимая процессы As Is, сразу пробуют зафиксировать To Be. И вот документ выходит некой чепухой, хоть и могут топить за то, что он To Be.

Моделирую рабочую ситуацию!

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

Предыдущий кейс 🚀

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

У аналитика типичное поведение - "с этим работать невозможно", у руководителя проекта типичное поведение "ТЗ до завтра сделаешь?" и прекрасная речь, которая заканчивается вопросом "да, ведь?"

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

❓Что посоветуете аналитику?
Какой видите план действий?

Я тут не написала уровень квалификации аналитика, даже интересно, что вы скажите какого уровня нужен аналитик на проекте? 😁

#кейссолвинг #выаналитик

---
😎О системном и бизнес анализе. Подписывайтесь и рекомендуйте друзьям, коллегам

😄СУП в вк

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

Мы говорили о взаимодействие аналитика и разработчика. Тема больная и все через неё проходят.

Я несколько инсайтов опишу, которые мне больше всего запомнились:
1.Если разработчик не читает ТЗ от аналитика, то тут нужна помощь старших товарищей, это не задача джуна.
2.Разработка часто перегружена, фокус внимания смещен, в голове очень много других задач, поэтому первая реакция чаще всего - как много вы написали, когда мне это всё читать! О ужас!
3.Если такая ситуация возникает, то тут вопрос к процессу и значит плохо работает скрам мастер, теряется смысл ретроспектив.
4.Стоит понимать свои эмоции, которые возникают в связи с ситуацией, потому что эмоции они перекрывают кострутив и сложно в такой ситуации, что-то адекватно сделать. Человек может брать на себя реакцию разработчика, хотя тут может быть что угодно и причина скрыта и неочевидна.
5.Каждый выбирает свою стратегию поведения, исходя из того опыта и ресурсов, что есть.

Для меня тут скорее самое важное это #инстайт того, что разработчики просто банально могут быть перегружены. И это большая боль руководителя проекта или продакта, когда ты такой на подъёме, сейчас как расскажу команде, как мы заживём и какие у меня крутые идеи! А тебя встречает "морда кирпичом", или безразличие. Ну вот опять нам подкинули новое, а мы ещё старое никак не переварим.

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

Если у вас есть запрос на для разбора вашей ситуации, пишите мне, приходите. Мы создаём бережное пространство, и призываем соблюдать конфиденциальность и NDA.


-----
🙂О системном и бизнес анализе. Подписывайтесь и рекомендуйте друзьям!
😄СУП в ВК
-------
😄Подписаться на ЛСА в ВК

🙂Хочу вами поделиться записью прямого эфира с Еленой Логачевой и Дмитрием Безуглым

Тема нашего разговора:
Делегирование, когда всё вокруг меняется: доверие, контроль и результат в нестабильные периоды.

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

Непредсказуемый стейкхолдер.
Немного инсайтов.

Вот всем кажется, что самое главное, это прокачать свои hard skills, углубиться в темы, побольше знать инструментов, теорий и т.д. Я тоже это всё люблю и мой мозг радуется сложным техническим задачам. И вот ты всё написал, всё сделал, а теперь нужно защитить. И вот тут то и #инсайт , что много сил тратится на то, чтобы вцелом понять как себя вести с тем или иным человеком. Что, зачем, и почему, какие аргументы с кем и как работают. А когда у этого самого человека настроение меняется, он подвержен своим эмоциям и не умеет с ними справляться экологично, или хотя бы объяснить другим, что с ним происходит, и что он собственно хочет? Ты действуешь как сапёр, угадаешь или нет. Или как ухажер принцессы, 99% её капризов понятны, но вот будет этот 1% который выстрелит и перечеркнёт все твои 99% стараний.

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

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

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

#softskills #мойопыт #манипуляции

Возвращаюсь к вам с анонсом!
Приглашаю вас на первую сессию интервизии!

Интервизия Лаборатории системного анализа в sup.expert - это сессия совместной работы равных коллег, где нет деления на гуру и всех остальных. Здесь опыт одних встречается с незамыленным взглядом других.

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

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

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

Мы принимаем к обсуждению любые вопросы и проблемы из работы системных и бизнесовых аналитиков, архитекторов и всех, кто причастен к проектированию ИТ-систем и работе с требованиями.

☄️Уже в этот четверг 2 июля с 19:00 до 21:00 московскому времени, будем разбирать первый кейс действующего аналитика.
Модератор Сергей Нужненко.

Добавляйте встречу себе в календарь и приходите поучаствовать!

Мы делаем ограничение по количеству участников, поэтому просим заранее
✔️зарегистрироваться по ссылке

-----
🙂О системном и бизнес анализе. Подписывайтесь и рекомендуйте друзьям!
😄СУП в ВК
-------
😄Подписаться на ЛСА в ВК

Очень много эмоций и мыслей, что сложно сразу осознать, что пролетело 2 года магистратуры и теперь я официально бизнес-педагог!)

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

И конечно комюнити, кто-то останется в контактах, кто-то переходит в статус друга.

Чуть позже буду делиться своими результатами исследования и возможно проведу первый заход тренинга, который я разработала для системных аналитиков)

А пока всех с летней пятницей!

P. S. А рубашка у меня подарок от бренда однокурсника из ВШЭ 😎