Наташа Косинова. Варю айти СУП
2.72K subscribers
68 photos
3 videos
9 files
336 links
Системный аналитик, бизнес-тренер, автор айти курсов. Работаю в айти с 2006 года. Мой канал про айти, без лапши успешного успеха. Варю айти СУП здорового человека)

Курс интеграции:
https://sup.expert/

Написать мне @tasha_kvitka
Download Telegram
#капитаночевидность #аналитик #системныйанализ #бизнесанализ
#инструменты #userstory #usecase

Вернёмся к #теория
Избитая всеми тема, какой подход лучше выбрать в фиксирование требований User Story или Use Cases.

Мало того, что многие не различают эти понятия, так ещё и не думают, а что лучше? Такое впечатление, что User Story это некая мода, поэтому не поддается анализу и логике их применение.

Ещё возникает постоянно вопрос, а какого чёрта вы не делаете микс? Почему на многих проектах забывают про существование Use Cases? Ой, мол как сложно. Надо думать. Я лучше буду херачить в своей песочнице...

В России постоянно всё из крайности в крайность. Но водку пьём, то торты едим. Точнее, то ТЗ на 100 страниц по ГОСТу канцелярским языком пишем, то на полстраницы User Story. Ни то, ни другое не даёт картины проекта. А ещё есть и противники UML. Я наоборот топлю за проектирование и описание функционала, как многослойного "торта" по диаграммам разного уровня детализации. Чтобы всегда можно было вернуться на тот уровень, который необходим.

"У нас нет времени" - вот что я постоянно слышу. Живя в Москве всю жизнь, могу сказать, что его никогда нет и оно есть всегда))) Опять же имхо, есть вещи без которых проект не сдвинуть, ну либо херак-херак и в продакшн. Тогда уже и о развитии сложно говорить и об системном анализе. Какие выводы делать по user story?

Тем кому тема близка и кто ломает голову, что лучше, посмотрите выступление с конференции, ссылка ниже.

Именно отсюда я знала о User Story 2.0, как раз когда появляется прослойка Use Cases и на них мапятся User Story. Вот так применяешь и то и другое и даже не знаешь, что это уже 2.0)))) Все когда-нибудь приходят к такой схеме работы с требованиями.

https://analystdays.ru/ru/talk/71737
#капитаночевидность #теория #системныйаналитик #умнаямысль #системныйанализ #разработкаIT #аналитикIT #материал

Наконец-то получилось послушать Левенчука про введение в системную инженерию, правда не всю лекцию, она длинная.

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

Что мне понравилось, я тезисно напишу:
👉●системная инженерия говорит как нужно сделать,
👉●реализация проекта с системной инженерией равно процессу "сначала думай, потом делай",
👉●системная инженерия зародилась там, где нужно было сделать что-то большое и сложное. В Америке, сначала это была авиация и космонавтика (тадам! Привет альмаматер, вот почему подобные вузы растят крутых аналитиков), потом было строительство небоскрёбов.
👉●Наши вузы учат, как писать алгоритмы, но не как это всё собрать вместе, архитектурно с интеграцией и координацией (тадам! Проблема на многих проектах как раз в отсутствие архитектуры и набивание шишек из-за отсутствия производственного опыта).
👉●25% времени от реализации больших проектов тратится на системную инженерию
👉●Но! Трата времени на проектирование и фиксирование требований "как нужно сделать", может принести выгоду проекту до 39%!!! Если говорить про крупный проект.
👉●Работу системного инженера невозможно потрогать и на неё уходит много времени, поэтому люди не понимают смысл работы этого персонажа и отказываются от них в проектах (тадам! Нафига нам аналитик, я сам всё сделаю)) )
👉●Но! Отсутствие системного инженера приводит к переделке проектов. Встречались случаи переделки до 15 раз!)))
👉●Системный инженер немного бюрократ и работает с описанием систем. Иногда действительно влюбляется в описание, хотя до самой системы далеко)

Справедливости ради всё таки скажу, что в современных реалиях аналитик ещё и ускоряет разработку, не только приводит её к виду того, что хотел заказчик, уменьшает % переделок, но я бы ещё говорила про ускорение. Хотя Левенчук говорит противоположное, что про ускорение речь не идёт. Но гибкие методологии и современный мир айти именно про это. А запись выступления была сделана 11 лет назад.

Материала от Левенчука в сети много, и много лекций тоже, не всё конечно посмотрела, да и эту лекцию про введение в системную инженерию пока осилила только первый час) Посмотрю второй час расскажу впечатление.

Вот ссылка, кому интересно)
https://vimeo.com/7725503/comments
#нотации #теория #мойопыт #бизнеспроцесс #проопыт

Про нотации))

Я знаю, что многие любят теорию. Немного #мысливслух о том, чем хороши нотации.

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

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

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

В этом плане мне нравится IDEF0 и epc (Aris) . Я часто забываю про IDEF0, как средство которое помогает понять картину мира, и место в этом мире нового бизнес - процесса. Где вход, где выход, какие роли, ресурсы нужны, управляющие процессы. И это один взгляд, а другой это тот же epc (Aris) , где чередование "событие" - "действие", также тебя ставит в позицию подумать и увидеть свои пробелы.

Нет единого "золотого ключика" , для любой двери. Поэтому я стараюсь смотреть на задачу с разных точек зрения и пробовать описывать тот же бизнес - процесс разными нотациями. Это интересная штука. Мы когда-то пробовали с аналитиками один и тот же процесс описать в bpmn и epc, и сравниваешь где какие плюсы, что стало лучше? Хорошая практика, если есть те кто готов у вас в команде такое провести, рекомендую пропустить через себя. То есть это фактически валидация работы аналитика.

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

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

Из моей практики, был такой случай, когда заказчик очень хотел аналитика со знанием uml. Я пришла на проект, нарисовала пару диаграмм, заказчик не понял. И тогда "яйца uml" мы использовали не как use cases, а просто как бизнес области проекта, этапы проекта. Главное заказчик понял))) Нарушили нотацию, но цель достигли. Также на конференции видела доклад аналитика, о том как с госами придумали язык, с помощью которого user interface описывали и согласовывали.

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

В очередной раз услышала фразу, про то, что "я не пользуюсь нашим продуктом".

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

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

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

Но! Вернемся в продукту. Как его развивать продакту, когда вокруг вот такие сотрудники?) Кроме того, чтобы быть на своей волне и быть немного психом как Стив Джоб, не знаю других способов. Ты видишь оборотную сторону большой компании, людей кто принимает решения, как принимают решения, как делаются проекты и начинаешь очень сильно сомневаться, что стоит пользоваться продуктом))) У меня принцип работы такой, что я не берусь за проекты, где человеку, кто будет пользоваться продуктом, продукт сможет нанести травмы или будет угроза жизни. Так что мои проекты максимум портят настроение))) И считаю, что человеческая психика по определению имеет врождённые защиты. Так что псих болезни пользователей, это уже не я)))

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

Есть ещё очень классные "отложенные" или "растянутые" мысли, когда сначала с тобой не согласны. Потому что даже и думать не могли, что так можно. А потом потихоньку меняется мнение, представление. И вот тогда человек может уже начать снимать свои защиты и присоединятся хотя бы к позднему большинству пользователей продукта (про позднее большинство, можно почитать вот в этой заметке - https://t.me/start_in_IT/13).

А вы пользуетесь продуктами вашей компании-работодателя?)
#Sкривая #технологии #теория #рассуждения #мысливслух

Я так часто говорю про S-кривую развития технологии, что похоже пора бы её уже зафиксировать тут.

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

Если смотреть на перевод с древне-греческого, то это искусство, мастерство, умение + слово, смысл, мысль, понятие. Искусство мысли? Что-то не очень понятно))

Мы же работаем с информационными технологиями и #капитаночевидность они позволяют нам обрабатывать данные для получения нового качества информации, что позволяет делать выводы, анализ, принимать решения о процессе, объекте, явление. И! Даёт конкурентное преимущество!)

В ИТ очень быстро появляются технологии и также быстро умирают. Пока ты учишь как её применять она уже неактуальна.

Если посмотреть на график s - кривой, то мы вкладываем деньги и ресурсы в развитие технологии, она достигает своего пика и останавливается. После паузы появляется новый цикл уже с новой технологией. Самый простой пример, это хранение информации. Дискеты, потом CD-диски, потом жёсткие диски, а теперь уже облачные хранилища. Несколько технологий могут одновременно конкурировать друг с другом. А нам, как людям применяющим технологии, остаётся либо быть гикам, и постоянно следить за новинками, тем самым оставаться востребованными, либо уходить в фундамент технологий и быть инженерами, которые хорошо зная базу, смогут в любой момент освоить и применить новую технологию или новый виток развития технологии.
​​#теория #мойопыт #мирвокруг #пополочкам

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

Какой список уже собрался:
1. CRM - https://t.me/start_in_IT/219
2. MDM - https://t.me/start_in_IT/220
3.Интеграционные решения - https://t.me/start_in_IT/221 интеграционная шина - https://t.me/start_in_IT/222 брокер - https://t.me/start_in_IT/223
4.Биллинг - https://t.me/start_in_IT/225
5.ETL - https://t.me/start_in_IT/226
6.ERP - https://t.me/start_in_IT/228
7.WMS - https://t.me/start_in_IT/242

И вот я встретила системы класса MRM, в посте ниже 👇 поговорим про них.

⚠️ А к вам вопрос, какие ещё классы систем вы встречали и которых нет у меня в списке

Я думаю есть ещё что-то специфичное, что не встречалось у меня на жизненном пути))) пишите в комментариях👇
​​#теория #мойопыт #мирвокруг #пополочкам #MRM

👆Выше пост, про все Классы Информационных Систем, что я встречала на практике.

Итак, про MRM - Marketing Resource Management. Класс информационных систем автоматизации маркетинговой деятельности. Раз я встретила такую систему, то это показатель того, что они стали развиваться. И вот в статье на vc, я прочитала фразу, что к 2023 году востребованность подобных систем на рынке вырастет на 80%!

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

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

Что же даёт MRM? Управление маркетинговыми кампаниями. Планирование, бюджетирование, согласование кампаний, получение отчётов. Смею предположить, что какая-то часть подобного функционала есть в CRM, а что-то закрывают спец системы, типа Яндекс.Директ, Google.Ads и т.п.

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

Пока я искала информацию про MRM, наткнулась на ещё кучу других систем DAM, PIM, CMS, PXM.

Статья про все подобные системы https://picvar.io/blog/dam-pim-mrm/rus
#uml #sequence #материал #теория #нотация #мойопыт #системныйаналитик #системныйанализ

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

К вам вопрос: встречали ли подобное описание и используете ли в своей практике? Удобно ли? Какие мысли?)
#теория #криваяБандуры #освоениематериала #обучение #новаяпредметнаяобласть

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

И я не одна такая. И тут меня может успокоить кривая Бандуры. Я сначала думала, что она так названа потому что похожа на украинский музыкальный инструмент, но нет)) Её нарисовал Альберт Бандура))

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

Так что как я успокаиваю себя кривой Бандуры и как мышь продолжаю есть свой сыр (об этой аналогии освоения нового пост вот тут - > https://t.me/start_in_IT/315).
#управлениеизменениями #графикизменений #теория #мойопыт #мысливслух #аналитик #бизнесаналитик #системныйаналитик

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

График внедрения изменений прикладываю в комментариях. 👇

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

Шаг 1. Прежде всего понять, что изменения нужны. Как и с многим в нашей жизни, нужно просто это проговорить. Лучше записать и показать факты, метрики.
Шаг 2. Все будут сопротивляться. Все, Все да не все. Своих тех кто тоже за изменения и понимает, что давно пора такие тоже всегда есть. Нужно заручиться их поддержкой.
Шаг 3. Дальше идём по графику и главное иметь больше поддержки и добавлять всё новых и новых в свои ряды. Когда ты адекватно оперируешь фактами, найти светлые головы не трудно, трудно попробовать удержать оптимизм и довести дело до конца, копая и копая. И сразу работая по-другому хотя бы в какой-то части. Как только изменение будет крутым, может пойти лавина и всё рядом.

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

Обычно идёт противочерие: ты внедряй, да, да, да иди, но я тебе инструмент не дам, копай землю руками, я посмотрю, начнёт получатся, вот тогда, может быть.... Лопату тебе куплю.

Шаг 4. Всё рушится в точке, когда уже никто не верит, все устали, и просто хотят махнуть рукой. Мол, ну ладно, итак жили, к черту эти изменения. Это самый сложный период. Моральный дух падает все устали, вот тогда первые шаги могут уже давать свои плоды и график можно переломить и погнать вверх.

Цикл внедрения изменений зависит от масштаба. Что-то что делать нужно годами, тут я только в своей личной жизни внедряю))) В компании беру что-то сроком максимум полгода.

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

Быть Чегеварой интересно, но опасно, он плохо кончил))))
А ничего не менять, это не жить, как по мне)))) Остаётся выбор в виде гармонии, к этому и стремлюсь, не всегда конечно получается. 😜
#мысливслух #бизнесаналитик #бизнесмодели #александростервальдер #теория #артефакт #бизнес #productmanager

Системный зуд или бизнес - модели.

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

Есть такая штука, назову её "Системный зуд", когда чувствуешь, что тебя обманывают и какого-то пазла в картине мира не хватает, но черт побери какого???!!! Непонятно. Ты начинаешь постоянно думать, рыть и плохо спать ночами. Для меня такой деталью пазла оказались бизнес - модели по Остервальдеру. Я прекрасно знаю и вижу, как работают компании типа орифлейм или avon. Или кофейные разные подписки на кофейные капсулы, или картриджи принтеров, как расходник мега дорогой, а принтер дешёвый.

И эффект вау, меня посетил после изучения бизнес - моделей подобных компаний. #капитаночевидность Есть куча шаблонных бизнес - моделей.
И тут у меня будет вопрос, к вам, знаете ли вы и используете ли схематичное представление бизнес-моделей при анализе бизнеса, компании?
Правда от этого знания зуд превращается в анализ и дополнительные вопросы руководству.

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

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

Для меня это ещё один артефакт, который сверху системно даёт представление о бизнесе компании.
#omgessence #быстроепогружение #теория #стандарт #материал #проИТ #системнаяинженерия

Про OMG Essence

Побуду #капитаночевидность
Аналитика во многих случаях, можно рассматривать, как роль, которая делегирована от руководителя проекта. Да и вцелом понимать, как работает команда и заниматься координацией проекта/продукта приходится.
А иногда и выстраивать внутренние процессы. Как Тим Лид аналитиков, могу сказать, что начиная с ведущего аналитики такой навык нужен. А если у тебя своя команда, то хочется выстраивать так процессы, чтобы команда могла эффективно работать.

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

Вообщем это частая история задать себе вопрос, что не так работает у нас и как это исправить. Я уже тут приводила в пример оптимизацию процессов команды в сбере. Доклад Руслана Остропольского с конференции CodeFest - https://12.codefest.ru/lecture/1964
(о докладах с конференции https://t.me/start_in_IT/464)

Но вот ещё начала рыть OMG Essence. Очень часто видела картинки, но как-то глубоко не погружалась. А тут ещё поняла, что у Юрия Куприянова есть масса прекрасных докладов в том числе и про OMG Essence.
https://youtu.be/r535935Kclo

На эту же тему статья Ольги Цыгановой с разбором примера - https://habr.com/ru/company/custis/blog/678436/
Подобный стандарт рекомендуют применять, чтобы быстро погрузиться в проект, новую среду и ещё и выявить пробелы, проблемы и понять на каком этапе находится проект. Тоже частый запрос от руководителя - в мы ваще где? Насколько близко к нашей цели и какая она?
Подход системный, точнее даже системная инженерия лежит в основе.
Всё логично и с первого взгляда кажется монстром. Но аналитики любят такие штуки, да и авторы стандарта - это монстры системной инженерии, кто выявил и объединил фундамент любого проекта.

Вот даже интересно, вы применяли на практике OMG Essence? Если да, что оно вам дало?)) Хочу опробовать этот стандарт. Если у кого-то такое же желание, предлагаю разложить любой, или ваш проект вместе))
#подкаст #сережаимикрофон #яндекс #рассуждения #мысливслух #примерразвитиятехнологий

Хочу продолжить мысли и немного зафиксировать, что ребята из яндекса говорили в подкасте. 👆

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

18 век письма, пишешь адрес и всё, можешь по этому адресу прийти.
Дальше телефон - даёшь номер и тебя соединяют через оператора, но прийти к тебе, это нужно знать адрес. Десятками лет этот барьер стирался и в 80-х годах можно было узнать и адрес. Дальше справочник жёлтые страницы лежал на станциях метро, я вот помню его, это уже 90-ые. Открыто можно узнать и номер телефона, и адрес. Моя мама по началу телефона могла сказать, к какому району Москвы относится телефон))
Потом интернет, и тоже все начинали со своих ник неймов, анонимности, а чем больше интернет проникает, тем больше происходит регулирования.
Теперь ждём новый способ коммуникации, который у нас также будет проходить этап анонимности))

Фактически Иван Черевко рассказал график развития технологий)))
Обычно я этот график через развития транспорта рассказываю, а вот ещё отличный пример через технологии коммуникации.

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

Ещё ребята обсуждают защиту финансовой информации. Всё таки PCI DSS как стандарт существует давно, и информация о платежах лучше шифруется и защищена, чем персональные данные или личные данные. При этом сотрудники Яндекса рассказали о том, что можно чистить историю заказов в яндекс)) Нехотя, но рассказали.

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

Про S - кривую писала вот тут: https://t.me/start_in_IT/357
#мысливслух #рассуждения #usecases #мойопыт #менторство #замечено #выводы #системныйанализ

Почему аналитики плохо пишут use cases?

Очень часто на курсах по интеграции в ШСА, да и не только, на менторстве тоже, и на собеседованиях встречается общая проблема по use cases. Аналитики плохо пишут сценарии вариантов использования.

👉1.Во первых, есть аналитики, кто не делает различий между use cases и user story. Вместо того, чтобы спрашивать аналитиков различие между Soap и Rest, на собеседование, лучше спросить различие между use cases и user story.
👉2.Во вторых, сценарии, как техника, используются на разных уровнях абстракции и не только аналитиками, но и тестировщиками, проектировщиками интерфейсов, продактами, да всеми)) Удобно.
👉3.Действительно, на системном или на уровне проектирования взаимодействия систем, мало кто из аналитиков грамотно может описать use cases. Это уже уровень архитектора, проектировщика, разработчика. Но он часто необходим на проектах, особенно если речь едет об интеграции.
👉4.Часто идёт ещё и смешение понятий функция и сценарий использования. Хотя use case вполне можно считать спецификацией функции.
👉5.Ну и плюс очень часто мы стараемся оперировать каноничным подходом, который был у Коберна (по крайней мере я всех к нему отправляю). И ещё пытаемся смаппить use cases и user story, я об этом писала, аж в 2020 году, что есть такое понятие как use cases 2.0 - https://t.me/start_in_IT/257

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

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

Выводы у меня следующие:
1.Высокоуровневые, на уровне бизнеса и взаимодействия пользователь - система, аналитики вполне отлично справляются.
2.Если аналитик не имеет базы, фундамента, плохо пишет алгоритмы, блок-схемы, то и сценарии также идут плохо. Везде в основе теория графов, сети Петри.
3.Сюда же я отнесу абстрактное мышление, это прям бич. Переключаться с одного уровня на другой самая большая проблема. Сложно понять где мы находимся, и где наши границы и рамки описания сценариев.
4.Сценарии на уровне взаимодействия модулей, систем требует знаний словаря данных, модели данных, что кому передаёт, как, в каком формате, по каким протоколам, синхронно, асинхронно, или файлами, или голубиной почтой.
5.Плюс сценарий не панацея и часто его нужно дополнять описанием алгоритмов, функций, а это математика. И я опять возвращаюсь к базовым, фундаментальным знаниям.
6.И ещё сюда добавлю обзор архитектурных решений. Потому что нужно хотя бы на пальцах понимать, как выстроено решение, к которому мы пишем уже на системном уровне требования, а точнее проектируем на языке требований, функций, что объединяет в себе целый комплекс знаний.

Итого: круг замыкается снова на том, что системный анализ инженерия, и даже в таком простом, с первого взгляда, инструменте, как use cases, собирает целый комплекс знаний.
#мысливслух #rutube #моемнение #рассуждения

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

И вот открываю Rutube, и понимаю, что я со своим пользовательским опытом не хочу им пользоваться после YouTube.

Зачем делать новое, долгое, неконкурентно способное, если нужно сделать копию?

Я сознательно не стала ставить слово ПРОСТО. Если бы сделать копию было бы просто)))

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

Прекрасно понимаю, что быстро что-то сделать, как пятилетку за 3 года, не так то просто. Но когда все двери открыты можно с видео котиков начать)) работает? Работает) Я пробью всё своё отторжение, когда пойму, что мне Rutube вожделенный, крутой контент покажет и только у них есть эксклюзив. Но пока блоггеры Rutube, как запасной аэропорт рассматривают. Я конечно необычный пользователь, и скорее отношусь к позднему большинству (см.пост на этот счёт https://t.me/start_in_IT/13 ), но чёт мне грустно, что новое не цепляет.
Даже вот стало очень интересно услышать мнение продактов, кто уже несколько раз запускали разные продукты, чтобы они делали с Rutube в текущей ситуации?

И мне кажется компании идут своим путем. Типа наплевать на чужой успешный опыт, у нас то, точно всё должно быть своё, пойдём своим путем к светлому будущему!

Хочется Rutube пожелать крутых продактов, команды, идей и взлёта. Ну и видимо всем нам учиться копировать фичи, а может и хакать, и красть идеи 😂
Перекупить сотрудника YouTube? 🤔
#теория #мысливслух #рассуждения #моемнение #мойопыт

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

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

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

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

Можно себя представить мышью, которая поедает сыр, я об этом писала вот тут - https://t.me/start_in_IT/315
Можно и нужно себе рассказать, что предметная область, проекты, и наш реальный мир очень сложный. И как не крути, на сложных проектах нужно пройти стадии обучения, освоения материала. Три месяца не просто так даются на испытательном сроке, не говоря уже об удаленке, где до полугода можно ходить в тумане неопределенности.
Как погружаться в предметную область я писала в постах и серии подкастов:
1.https://t.me/start_in_IT/420
2.https://t.me/start_in_IT/422
3.https://t.me/start_in_IT/425
4.https://t.me/start_in_IT/430
5.https://t.me/start_in_IT/433

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

P. S.
Про конус неопределенности можно посмотреть старое видео Сергея Нужненко -
https://vimeo.com/61968936
#обучение #водакаменьточит #самомотивация #мойопыт #рассуждения #мысливслух

Побуду #капитаночевидность и расскажу о диффузных преобразованиях, еле заметных или почти незаметных. Когда капля за каплей мы получаем большой результат. Или же принцип Паретто 80 на 20, когда 20% усилий нам дают 80% результата.

Очень часто я среди менти или участников курсов, тренингов вижу желание получить всё и сразу. Отсюда такие вопросы - почему так долго? Чего вы нам мозг взрываете, давайте сразу к сути? Зачем нам это всё знать?

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

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

Я это к чему? Что уметь учиться тоже искусство, и тут у каждого может быть свой подход. Я поэтому в онлайн обучение всегда включаю камеру, пишу от руки (это вообще мой способ запоминать), и стараюсь всегда приходить на занятия в прямом эфире. Запись, в моём случае, не очень хорошо работает. А лучше всего очные занятия.

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

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

И тут главное не ждать его, потому что в какой-то момент может ещё и эффект Бандуры случиться))) (про него почитать можно тут https://t.me/start_in_IT/370 ). Переключиться именно на процесс и просто делать, без оценок себя.

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

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

Уже года 4, я провожу оценку аналитиков в виде игры по сбору требований. Игра у меня родилась из большого количества собеседований, доклада Ольги Азимбаевой (можно почитать и посмотреть тут https://t.me/start_in_IT/233 ) и моего опыта.
Я имитирую типичного заказчика, погружаю аналитика в его обычную среду "сбора требований и общения с заказчиком". Цель выявить основные Паттерны поведения аналитика, посмотреть какие вопросы он задаёт заказчику, как собирает требования, какие требования, на что обращает внимание, насколько идёт за заказчиком и тем решением, которое ему приносит заказчик.

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

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

Очень сложный вопрос. У меня нет однозначного ответа. Тут скорее, как в личной жизни, когда ты видишь, что в отношениях идёт обман, и один паразитирует за счёт другого. Что делать? Часто говорить бесполезно. Да и кто ты такой, чтобы это говорить? Этот опыт нужно получить.

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

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

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

Вспомнила ещё книгу "Русская модель управления" ( https://t.me/start_in_IT/176 ), когда я вижу какие-то очень странные, по-моему мнению движения, реализации, я начинаю спрашивать "почему так?" Вспоминаю книгу и отвечаю, аааа вот почему.

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

Всегда есть выбор, даже если кажется, что его нет)