Наташа Косинова. Варю айти СУП

👀Удивительное рядом!

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

Но я не перестаю удивляться как круг повторяется.
Из любимого:
1.У нас нет системного анализа и он нам не нужен.
2.Нфт фигня и зачем их писать, пустое.
3.Главное в бизнес-анализе процессы.
4.Микросервисы нас спасут (а теперь ещё ИИ спасёт).
5.Предметная область, что это такое? Всем же итак понятно.

Можете дополнить, то с чем вы столкнулись на этой неделе? 🔽

Нужен ли идеал?

Поймала себя на мысли, что в живой команде, всё не очень, а где-то точно круто и хорошо.

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

И вот такой когнитивный диссонанс, хочется думать, что где-то есть недостижымый идеал, в котором не хочется работать 😂

💭Универсальный продукт или кастом под заказчика

Предыдущий пост 👆

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

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

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

Мне понравилась аналогия, что

стоматолог не может научиться на себе лечить зубы.

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

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

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

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

#продуктпроект #мысливслух

💬Универсальный продукт VS Кастом под заказчика

Давно тут меня не было.
Ворвусь с рассуждений.

За и против разработки универсального продукта и кастом под заказчика.

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

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

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

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

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

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

Так что же лучше универсальное решёние или кастом под заказчика?
Вы на какой стороне?)

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

Вкатывание в новый проект

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

Тут конечно первое правило - назвать положение дел своими словами.

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


Какие тут могу выводы сделать:
✔️1.Понимать, что высокая степень неопределённости - это высокий стресс и иметь в запасе список действий, которые дают энергию и стресс снижают (у кого-то это прогулка с собакой, выпить кофе, позвонить другу, всё что угодно и что укладывается в 15 минут, когда в стрессе мозг отрубает и лучше заранее написать список).
✔️2.У меня есть такая черта, что я долго присматриваюсь к новым людям. Это не значит, что я не хочу общаться, или как-то ухожу в свой домик, это значит, что мне нужно какие сделать выводы для себя и стратегию поведения выработать. Особенно это видно в походах, сплавах, где ты условно в одной лодке с людьми.
✔️3.Стресс имеет свойство копиться, лучше его сливать сразу. Спорт, как по мне, лучшее лекарство. Мне помогает мелкая моторика. В команде для этого как раз ретроспектива нужна, но тут тоже отдельная задача создать пространство, где можно высказывать открыто. Это не всегда возможно.
✔️4.Карта заинтересованных лиц, оргструктуры, понимание того, кто на каком уровне принимает решения и влияет на это решение. Оно чаще всего в голове есть, но когда начинает строить диаграмму появляются нюансы, а может быть даже новые персонажи.
✔️5.У меня из моего жизненного опыта есть прекрасная история, когда всю нашу команду отправили к новому заказчику, как команду тестирования. Но никто нам не сказал, что нам нужно сыграть роли тестировщиков! Мы хотели чуть ли не в этот день написать заявление на увольнение. И все хором сказали заказчику, что если нас возьмут как тестировщиков мы уйдём. Провал менеджеров был грандиозный. К любой встрече с заказчиком нужно готовиться (понимать, кто будет, что будем обсуждать, что можно говорить, что нельзя, какая есть субординация, и обязательно нужна визуализация - списки вопросов, холст, картинки, диаграммы, mind maps всё подойдёт, на ночных встречах я всегда себе говорю - просто возьми фломастер и пиши, рисуй, чтобы не было страха белого листа).
✔️6.Любые эмоции - это нормально, это рабочий момент. Любые недопонимания, косяки, это тоже нормально, невозможно всегда быть идеалом. Тут конечно приходит синдром самозванца, особенно когда включается "ты же профессионал, значит может, значит ожидания от тебя завышенные".
✔️7.Очень важный пункт - присваивать достижения, результаты, оценивать промежуточное качество, понимая что было на входе и какой сделан вклад. Даже если об этом никто не говорит. Может сказать ментор, или коллега с бОльшим опытом. Если спрашивать у коллег, то тоже нужно понимать у кого и как справиться с критикой, если она будет и понять насколько она адекватная. Всю ситуацию своего состояния знаете только вы.

Полезные ссылки по теме:
🎙️Подкасты как погружаться в предметную область:
1. Часть про границы "картины мира"
2. Часть про модель предметки
3. Часть про психологию изучения нового
4. Часть про картинки
5. Часть про внешние источники

---------
📹Вебинар по предметке - rutube
---------

Другие посты по теме:
1. Кто такой стейкхолдер. Карта заинтересованных лиц.
2. Конус неопределённости.
3. Диаграмма эффект Даннинга-Крюгера.
4. Эффект Бандуры изучения нового.
5. Метод поедания сыра мышью

#предметнаяобласть #новыйпроект #мойопыт #softskills

Лена вспомнила про наш прямой эфир, решила с вами поделиться, вдруг будет в тему 😎

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

Начнём с того, что:
Телега жива и больше всего мне нравится)

Дальше, сорян, меня нет в макс, так что появились альтернативы, где я общаюсь - VK, express, на проекте, куда я вышла работать, был выбран - mattermost, с друзьями я много, где общаюсь, тут нельзяграм, обычные звонки, смски. Забугорные человеки - вотсап, пара человек точно.
Промежуточный итог: 7

Что ещё?)
Аааа, видео конференции!
Тут лидер у меня пока телемост, за ним идёт неправославный зум, гугл мит иногда, на работе dion, очень мало было звонков в МТС линк, кстати контур мне очень нравится, жаль, что он думает больше про корпорации, если есть возможность, я всегда за контур!
А ну куда же без сбер.джазз 😂
Выходит тоже 7.

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

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

Итого: 14, и добавлю ещё обычную электронную почту - и будет 15!

У кого список больше❓
Делитесь)

P. S. Ждём решений или ИИ-агентов, которые бы это всё многобразие собирали и синхронизировали

#коммуникация

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

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

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

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

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

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

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

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

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

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

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

Я описываю ситуацию, вы предлагаете варианты выхода, задаёте вопросы, я на следующий день или позже пишу свой ответ)

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

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

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

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

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

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

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

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

😄СУП в вк

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мои наблюдения про текущее состояние ИТ и что вокруг говорят эксперты. И конечно #моемнение #капитаночевидность 😎

Про ИИ и чё происходит, как я это вижу:
✔️1. Россия, как всегда, идёт своим путём и не смотрит на опыт тех кто за бугром уже опробовал ИИ. Нам чужие ошибки не нужны, мы набиваем свои и осваиваем бюджеты. Русская система управления в своей красе.
✔️2. На острие технологий и равно денег, как всегда финтех. Да, есть небольшая турбулентность, но также у банков есть раздутый штат, который можно подсократить (главное тут не выплеснуть ребёнка вместе с водой, что уже в некоторых компаниях наблюдается) и конечно впихнуть ИИ, где надо и не надо. Но никто же не анализирует, где надо? См.п.1
✔️3. ИИ не ускоритель, хотя кажется, что это так. ИИ даёт возможность разгрузить рутину, получить драфт, натолкнуть на мысли, но валидация за пользователем.
✔️4. Начинающие специалисты мало имеют опоры, знаний, и в итоге по каждому чиху бегут в ИИ, что приводит к тому, что не происходит процесс валидации результата. И тут вывод, что ИИ инструмент для эксперта, а джунам по-хорошему нужно ещё качать скиллы.
✔️5. Чтобы использовать ИИ, нужно хорошо понимать деятельность в которой будет применение. Да, есть банально as is, и to be, но имхо, тут надо копать глубже и разбираться в нюансах. Конечно поможет анализ и диаграмма деятельности, но фактически надо уходить в онтологию предметной области. И понимать нюансы задач деятельности, чтобы чётко понять, что мы делегируем ИИ и как валидируем, контролируем.
✔️6. Вопрос безопасности актуален. ИИ для меня как черная дыра, в которую попадает информация и где-то на задворках остаётся.
✔️7. А теперь самый сложный тезис и критичный. Мы можем говорить про разные этапы развития компании и внедрения технологий. И если мы говорим про автоматизацию, то нужно хорошо проводить бизнес-анализ, понимать как процесс оптимизировать, сделать эффективнее, но до этого уровня доходят компании, у которых высокая зрелость внутри, развития культура. Иначе мы получим автоматизированный хаос и вот на этот хаос, мы ещё добавим ИИ. А ИИ чаще всего непредсказуем, его нужно контролировать и валидировать. А мы вот взялись и доверили. И теперь автоматизированный хаос зажил своей жизнью с ИИ, и потихонечку гниёт изнутри. Прям такое состояние газлайтинга можно словить)) всё же хорошо, но не веришь своим глазам.
✔️8. Вывод про рынок, который колбасит, потому что ИИ должен заменить людей и освободить деньги бизнесу (так его можно продать). Но по факту, денег нужно больше и нужны инженеры-разнорабочие, которые могут всё. Что мы видим на примере "систем дизайна" - его хотят от разработчиков, от продактов, от прожектов, от аналитиков. И что я слышу, от аналитиков - разработчиков заменит ИИ, от разработчиков - аналитиков заменить ИИ, от продактов - всех заменит ИИ, останемся только мы. А по факту людей стало меньше, а работы стало больше, и причём она стала или должна стать более инженерная, много анализа с выводами, смотрим выше про анализ деятельности и онтологии.

😎Я художник, я так вижу.

Будет сложно, легко не будет...

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

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

Предлагаю помозговать.
Я описываю ситуацию, в которую попадает аналитик, вы предлагаете варианты решений выхода из этой ситуации.

Погнали!🚀

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

А дальше классика. Продакт вам говорит:

- Я не понимаю, что делает команда гамма, они меня кормят завтраками и ничего не отдают, а любая доработка это месяц, не меньше, разработки. Давай ты напишешь постановку задачи на новую фичу - "подборка оборудования под задачу электрика". И заодно разберёшься в том, что у них происходит, зафиксируешь в конфлюенс работу их 5 микросервисов.
Месяца хватит?

Что будете делать?
Какой план работы себе придумаете, с чего начинать?

Свой вариант расскажу после вас, завтра 😎

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