#теория #системныйанализ #мойопыт #собеседования #поискработы
Из нескольких источников ко мне прилетел один и тот же вопрос "как синтегрировать системы?"
Оказалось, что Руководители отделов на собеседованиях вместе с вопросом "кем вы видите себя через 5 лет?" ещё и задают очень расплывчатые вопросы. Я сама этим грешила, но с другой стороны вот такой расплывчатой формулировкой я хотела посмотреть, как будет себя вести специалист, что будет спрашивать и как сузит себе пространство для ответа. Но тут потом странно получать отказ соискателю, раз сам четко задачу не поставил.
Конечно ответить на такой вопрос хочется ёмко, что я бы интегрировала системы "молча")))
Но думаю шутку не поймут. И тут хочется сузить область:
1. С точки зрения теории и топологии сетей (точка-точка, шлюз, шина, либо смесь всего этого, если несколько систем). На моей практике встречались все варианты, в enterprise чаще всего шина.
2. С точки зрения бизнеса - мы соединяем процессы или просто производим обмен данными, под обменом данными чаще всего подразумевают справочники.
3. С точки зрения выстраивания канала передачи данных. Вот тут я не могу как архитектор доказать, где какое решение нужно применять (что кстати интересно было бы это доказательство узнать), но тут может быть онлайн-вызов сервисов, прямые запросы в бд, очереди сообщений, файлы. По-моему, всё основное я перечислила.
4. Ещё точно нужно вспомнить выстраивание защиты канала передачи. Всё таки часто при интеграции идёт обмен конфиденциальной и персональной информации.
5. Режимы частоты обмена данными с графиками обмена.
6. Гарантированная доставка, если это требуется.
7. Мониторинг и логирование тоже никто не отменял.
Возможно я что-то забыла, например, про синхронные и асинхронные вызовы, в интеграции они всегда актуальны. Если есть что сказать пишите в комментариях)))
Вспомнить телрию оказалось сложно, когда у тебя постоянно практика. И иногда нет времени на теорию. Херак-херак и в продакшн)))) ну или просто уже не понимаешь почему так, оно просто сложилось, берёшь и делаешь... Как в анекдоте:
По коридору ВУЗа идет профессор. Навстречу студент:
- Здравствуйте, профессор. Можно Вас спросить?
- Конечно, спрашивайте, молодой человек.
- Скажите, профессор, Вы когда спать ложитесь, бороду на одеяло или под одеяло кладете?
После некоторой паузы:
- Да, знаете, как-то не задумывался.
- Ну, извините, пожалуйста.
Через неделю зеленый профессор с кругами под глазами встречает в коридоре того же студента и хватает за грудки:
- Ну ты и сволочь! Неделю уже спать не могу - и так неудобно, и так неудобно!
Так и я, почему вот тут нужно синхронный вызов онлайн, да бог его знает))) давно это было...
Из нескольких источников ко мне прилетел один и тот же вопрос "как синтегрировать системы?"
Оказалось, что Руководители отделов на собеседованиях вместе с вопросом "кем вы видите себя через 5 лет?" ещё и задают очень расплывчатые вопросы. Я сама этим грешила, но с другой стороны вот такой расплывчатой формулировкой я хотела посмотреть, как будет себя вести специалист, что будет спрашивать и как сузит себе пространство для ответа. Но тут потом странно получать отказ соискателю, раз сам четко задачу не поставил.
Конечно ответить на такой вопрос хочется ёмко, что я бы интегрировала системы "молча")))
Но думаю шутку не поймут. И тут хочется сузить область:
1. С точки зрения теории и топологии сетей (точка-точка, шлюз, шина, либо смесь всего этого, если несколько систем). На моей практике встречались все варианты, в enterprise чаще всего шина.
2. С точки зрения бизнеса - мы соединяем процессы или просто производим обмен данными, под обменом данными чаще всего подразумевают справочники.
3. С точки зрения выстраивания канала передачи данных. Вот тут я не могу как архитектор доказать, где какое решение нужно применять (что кстати интересно было бы это доказательство узнать), но тут может быть онлайн-вызов сервисов, прямые запросы в бд, очереди сообщений, файлы. По-моему, всё основное я перечислила.
4. Ещё точно нужно вспомнить выстраивание защиты канала передачи. Всё таки часто при интеграции идёт обмен конфиденциальной и персональной информации.
5. Режимы частоты обмена данными с графиками обмена.
6. Гарантированная доставка, если это требуется.
7. Мониторинг и логирование тоже никто не отменял.
Возможно я что-то забыла, например, про синхронные и асинхронные вызовы, в интеграции они всегда актуальны. Если есть что сказать пишите в комментариях)))
Вспомнить телрию оказалось сложно, когда у тебя постоянно практика. И иногда нет времени на теорию. Херак-херак и в продакшн)))) ну или просто уже не понимаешь почему так, оно просто сложилось, берёшь и делаешь... Как в анекдоте:
По коридору ВУЗа идет профессор. Навстречу студент:
- Здравствуйте, профессор. Можно Вас спросить?
- Конечно, спрашивайте, молодой человек.
- Скажите, профессор, Вы когда спать ложитесь, бороду на одеяло или под одеяло кладете?
После некоторой паузы:
- Да, знаете, как-то не задумывался.
- Ну, извините, пожалуйста.
Через неделю зеленый профессор с кругами под глазами встречает в коридоре того же студента и хватает за грудки:
- Ну ты и сволочь! Неделю уже спать не могу - и так неудобно, и так неудобно!
Так и я, почему вот тут нужно синхронный вызов онлайн, да бог его знает))) давно это было...
#мирвокруг #аналитик #материалы #бизнесанализ #системныйанализ #рекомендую #теория
Произошел очень забавный случай, я случайно пересеклась с девушкой, которая выступала на конференции Analyst days в 2018 году.
Она тогда заняла второе место за своё выступление и действительно доклад был хорош. Она получила приз, приставку игровую и ей пришлось её продать, ну не играет человек в игры.
Я часто этот доклад ставлю в пример того, как аналитики бегут решать проблему, не до конца разобравшись в проблеме. Я сама этим грешу и мозг привыкает так работать. Перепрыгивать через бизнес, проблемы, и сразу бегом писать ТЗ на мобильное приложение, думая что знаешь, что нужно заказчику.
Я нашла ссылку выступления Ольги и решила с вами поделиться.
https://analystdays.ru/ru/talk/58370
Произошел очень забавный случай, я случайно пересеклась с девушкой, которая выступала на конференции Analyst days в 2018 году.
Она тогда заняла второе место за своё выступление и действительно доклад был хорош. Она получила приз, приставку игровую и ей пришлось её продать, ну не играет человек в игры.
Я часто этот доклад ставлю в пример того, как аналитики бегут решать проблему, не до конца разобравшись в проблеме. Я сама этим грешу и мозг привыкает так работать. Перепрыгивать через бизнес, проблемы, и сразу бегом писать ТЗ на мобильное приложение, думая что знаешь, что нужно заказчику.
Я нашла ссылку выступления Ольги и решила с вами поделиться.
https://analystdays.ru/ru/talk/58370
analystdays.ru
Начало проекта: не торопись проектировать, узнай цель
Система создана и даже внедрена, а заказчик недоволен.
Знакомая ситуация? По результатам различных исследований, от 40% до 80%
IT-проектов заканчиваются неудачно и не удовлетворяют потребностям заказчика. К
основным причинам относят факторы, находящиеся в…
Знакомая ситуация? По результатам различных исследований, от 40% до 80%
IT-проектов заканчиваются неудачно и не удовлетворяют потребностям заказчика. К
основным причинам относят факторы, находящиеся в…
#теория #мойопыт #проITсистемы #WMS #мирвокруг #пополочкам
У меня есть рубрика про классы информационных систем, сегодня хочу её продолжить и рассказать про WMS - Warehouse Management System - Система управления складом.
Сейчас достаточно много вакансий в ИТ именно в ритейле, ядро которого это склад, конечно продажа, сайты, магазины, тоже имеют значение, но покупатель принимает решение основываясь на куче мелочей. И тут много значат качество товара и условия хранения, а это поставщики и работа склада.
🧰
Итак, что же входит в WMS - это основные процессы работы склада, где в основе лежат зоны и привязка к ним товаров. То есть весь склад разбивается на зоны, приёмка, размещение, хранение, отгрузка. 🔀 При этом хранение тоже разное, и зависит от температуры хранения. На каждом участке есть свои сотрудники 👷♂, которые отвечают за зону и процессы, которые там происходят. Передача товара осуществляется из зоны в зону, то есть от одних сотрудников к другим. Как эстафетная палочка в забеге) Принял товар передал, приехал погрузчик перенес в хранение, полежало в хранение, перешло в зону комплектации, там прибежал комплектовщик и собрал заказ, передал его и так по цепочке до отгрузки в машину, которая уже приедет к покупателю.
Привязка товаров к зонам происходит по штрихкодам, то есть сотрудник с помощью ТСД - терминала сбора данных, осуществляет привязку сканируя штрихкод товара и места, где он находится. Система учитывает условия хранения, сроки годности, поставщиков и расположение товаров на полках, чтобы просчитывать цепочки из заданий на сотрудников, которые находятся в разных зонах. При этом немаловажно понимать размещение товара, топологию склада, и оперативно её изменять под разные периоды времени работы склада. Например, перед праздниками, когда будет больше заказов, зон сборки и буферов для хранения запасов должно быть больше. Склад может иметь статическое хранение товаров, когда товар четко привязан к месту, но может быть и динамическое, тут много вольностей для перемещений.
Еще есть интересная задача по формированию оптимального маршрута перемещения сотрудника по складу, и товара в том числе, для экономии времени и уменьшения пробегов сотрудников по складу. Есть в цепочке workflow так много мелких действий, что изменяя их, можно оптимизировать работу звена, что может отразиться на производительности склада. Хочется сказать, что в положительную сторону)))
WMS системы классифицируются в зависимости от размера склада, количества товара, хранящегося на нём и бизнеса компании на:
✔️ системы начального уровня, склады небольших компаний,
✔️ коробочные системы, где основные функции зашиты и такие системы готовы к установке с выстроенными под неё процессами,
✔️ адаптируемые для больших логистических центров с распределительными центрами, где есть один центральный модуль, который поддерживает основные процессы, и модули, которые подключаются и донастраиваются по заказу,
✔️ конфигурационные, это склады с большой номенклатурой и высоким товарооборотом, тут можно сказать, что система создается с нуля, и учитываются особенности бизнеса компании.
Если вы начнете гуглить вендоров WMS систем, то увидите как их много. Википендия говорит, что на российском рынке под 50 разных. Если смотреть на рейтинги 2020, то тут можно увидеть знакомое всем название 1С :)
Остальные перечислять не буду) Про мировую практику скажу, что куда тут без SAP решения, оно есть.
На картинке данные 2019 года и ссылка на статью, для тех кому интересен подобный рынок)
https://www.solvo.ru/about/press/solvo-wms-vtoraya-samaya-populyarnaya-wms-sistema-v-rossii-po-itogam-2019/
У меня есть рубрика про классы информационных систем, сегодня хочу её продолжить и рассказать про WMS - Warehouse Management System - Система управления складом.
Сейчас достаточно много вакансий в ИТ именно в ритейле, ядро которого это склад, конечно продажа, сайты, магазины, тоже имеют значение, но покупатель принимает решение основываясь на куче мелочей. И тут много значат качество товара и условия хранения, а это поставщики и работа склада.
🧰
Итак, что же входит в WMS - это основные процессы работы склада, где в основе лежат зоны и привязка к ним товаров. То есть весь склад разбивается на зоны, приёмка, размещение, хранение, отгрузка. 🔀 При этом хранение тоже разное, и зависит от температуры хранения. На каждом участке есть свои сотрудники 👷♂, которые отвечают за зону и процессы, которые там происходят. Передача товара осуществляется из зоны в зону, то есть от одних сотрудников к другим. Как эстафетная палочка в забеге) Принял товар передал, приехал погрузчик перенес в хранение, полежало в хранение, перешло в зону комплектации, там прибежал комплектовщик и собрал заказ, передал его и так по цепочке до отгрузки в машину, которая уже приедет к покупателю.
Привязка товаров к зонам происходит по штрихкодам, то есть сотрудник с помощью ТСД - терминала сбора данных, осуществляет привязку сканируя штрихкод товара и места, где он находится. Система учитывает условия хранения, сроки годности, поставщиков и расположение товаров на полках, чтобы просчитывать цепочки из заданий на сотрудников, которые находятся в разных зонах. При этом немаловажно понимать размещение товара, топологию склада, и оперативно её изменять под разные периоды времени работы склада. Например, перед праздниками, когда будет больше заказов, зон сборки и буферов для хранения запасов должно быть больше. Склад может иметь статическое хранение товаров, когда товар четко привязан к месту, но может быть и динамическое, тут много вольностей для перемещений.
Еще есть интересная задача по формированию оптимального маршрута перемещения сотрудника по складу, и товара в том числе, для экономии времени и уменьшения пробегов сотрудников по складу. Есть в цепочке workflow так много мелких действий, что изменяя их, можно оптимизировать работу звена, что может отразиться на производительности склада. Хочется сказать, что в положительную сторону)))
WMS системы классифицируются в зависимости от размера склада, количества товара, хранящегося на нём и бизнеса компании на:
✔️ системы начального уровня, склады небольших компаний,
✔️ коробочные системы, где основные функции зашиты и такие системы готовы к установке с выстроенными под неё процессами,
✔️ адаптируемые для больших логистических центров с распределительными центрами, где есть один центральный модуль, который поддерживает основные процессы, и модули, которые подключаются и донастраиваются по заказу,
✔️ конфигурационные, это склады с большой номенклатурой и высоким товарооборотом, тут можно сказать, что система создается с нуля, и учитываются особенности бизнеса компании.
Если вы начнете гуглить вендоров WMS систем, то увидите как их много. Википендия говорит, что на российском рынке под 50 разных. Если смотреть на рейтинги 2020, то тут можно увидеть знакомое всем название 1С :)
Остальные перечислять не буду) Про мировую практику скажу, что куда тут без SAP решения, оно есть.
На картинке данные 2019 года и ссылка на статью, для тех кому интересен подобный рынок)
https://www.solvo.ru/about/press/solvo-wms-vtoraya-samaya-populyarnaya-wms-sistema-v-rossii-po-itogam-2019/
#мысливслух #теория #лояльность #капитаночевидность #пропродукт
Немного мыслей о теории выстраивания отношений с клиентами.
Говорить о том, что это нужно, даже как-то странно, и вроде бы клиенториентированность, клиентоцентричность бизнеса очевидна. Хочешь быть на плаву смотри на клиента и делай ему хорошо. И если ты хочешь, чтобы клиент к тебе возвращался, нужно выстаивать отношения. Где нужно говорить "спасибо", где нужно "извиняться", признавать свои ошибки, работать с возражениями, делать выводы. А где нужно фильтровать неадекват.
Есть прекрасный слайд, который отображает стадии развития отношений. Всё как в личных отношениях)
1. Сначала о тебе ничего не знают, кто ты что ты.
2. Потом что-то знают, название, бренд уже раскручивается и светится.
3. Дальше клиент знает ещё чуть больше, что предоставляет компании.
4. Клиент пользуется и знает, что есть хорошего, какие эмоции вызывает сервис.
5. Начинает больше сравнивать с другими компаниями и находит отличия, которые нравятся.
6. Понимает, что главное и о чем беспокоится компания предоставляя сервис.
7. Клиент начинает поддерживать компанию и готов рекомендовать знакомым и друзьям.
8. Лояльность и любовь, когда ошибки можно простить. Я же их люблю, они такие молодцы, ну вот в этот раз не сложилось, исправятся, буду любить дальше.
Именно этот высший пилотаж любви то к чему стоит стремиться, и именно этот уровень спасает компанию.
Лояльность способствует иррациональному принятию решения о покупке клиентом, даже если продукт не соответствует реалиям рынка. Клиенты, лояльные к Apple, покупали их компьютеры в середине 90-х. Компьютеры были однозначно устаревшие и по всем параметрам проигрывающие PC и Windows. Но потребительская лояльность помогла компании выжить и саккумулировать ресурсы для нового скачка. Тоже самое произошло с British Airways в кризис начала 80-х - именно они стали основоположниками и первыми применили инструмент лояльности.
Это связь с компанией на уровне эмоций, самое сильное что может быть.
Я поймала себя на мысли, что некоторые компании так хотят перепрыгнуть через несколько уровней, чтобы достичь уровня - порекомендуй нас другу, что забывают о рутине выстраивания отношений с клиентом. И когда мне пихают "приведи друга, получи бонус", я злюсь. Действительно стоит искать новые пути привлечения клиентов и выстраивания с ними любви, чтобы клиент говорил - Wow! Зачастую программы лояльности есть только потому что у соседа есть такая программа, а в сути взаимосвязи с клиентом на низком уровне мало кто рассуждает. Программы лояльности клепают по шаблону из компании в компанию, карточки с баллами есть у всех, иногда они действительно хороши, но чаще всего бесят))) Действительно ли это нужно? Если мне нравится компания, мне плевать на баллы, если есть кешбэк в банке, здорово, если нет, я скорее всего сильно не расстроюсь, если всё остальное мне нравится и цена, которую я плачу за сервис справедлива.
Немного мыслей о теории выстраивания отношений с клиентами.
Говорить о том, что это нужно, даже как-то странно, и вроде бы клиенториентированность, клиентоцентричность бизнеса очевидна. Хочешь быть на плаву смотри на клиента и делай ему хорошо. И если ты хочешь, чтобы клиент к тебе возвращался, нужно выстаивать отношения. Где нужно говорить "спасибо", где нужно "извиняться", признавать свои ошибки, работать с возражениями, делать выводы. А где нужно фильтровать неадекват.
Есть прекрасный слайд, который отображает стадии развития отношений. Всё как в личных отношениях)
1. Сначала о тебе ничего не знают, кто ты что ты.
2. Потом что-то знают, название, бренд уже раскручивается и светится.
3. Дальше клиент знает ещё чуть больше, что предоставляет компании.
4. Клиент пользуется и знает, что есть хорошего, какие эмоции вызывает сервис.
5. Начинает больше сравнивать с другими компаниями и находит отличия, которые нравятся.
6. Понимает, что главное и о чем беспокоится компания предоставляя сервис.
7. Клиент начинает поддерживать компанию и готов рекомендовать знакомым и друзьям.
8. Лояльность и любовь, когда ошибки можно простить. Я же их люблю, они такие молодцы, ну вот в этот раз не сложилось, исправятся, буду любить дальше.
Именно этот высший пилотаж любви то к чему стоит стремиться, и именно этот уровень спасает компанию.
Лояльность способствует иррациональному принятию решения о покупке клиентом, даже если продукт не соответствует реалиям рынка. Клиенты, лояльные к Apple, покупали их компьютеры в середине 90-х. Компьютеры были однозначно устаревшие и по всем параметрам проигрывающие PC и Windows. Но потребительская лояльность помогла компании выжить и саккумулировать ресурсы для нового скачка. Тоже самое произошло с British Airways в кризис начала 80-х - именно они стали основоположниками и первыми применили инструмент лояльности.
Это связь с компанией на уровне эмоций, самое сильное что может быть.
Я поймала себя на мысли, что некоторые компании так хотят перепрыгнуть через несколько уровней, чтобы достичь уровня - порекомендуй нас другу, что забывают о рутине выстраивания отношений с клиентом. И когда мне пихают "приведи друга, получи бонус", я злюсь. Действительно стоит искать новые пути привлечения клиентов и выстраивания с ними любви, чтобы клиент говорил - Wow! Зачастую программы лояльности есть только потому что у соседа есть такая программа, а в сути взаимосвязи с клиентом на низком уровне мало кто рассуждает. Программы лояльности клепают по шаблону из компании в компанию, карточки с баллами есть у всех, иногда они действительно хороши, но чаще всего бесят))) Действительно ли это нужно? Если мне нравится компания, мне плевать на баллы, если есть кешбэк в банке, здорово, если нет, я скорее всего сильно не расстроюсь, если всё остальное мне нравится и цена, которую я плачу за сервис справедлива.
#теория #мирвокруг #мысливслух #капитаннеочеаидность
Это #нереклама но этим стоит поделиться.
Подкаст Вани Замесина, разговор с Байрамом Аннаковым.
Я всё больше и больше замечаю в подкастах, в выступлениях топ-специалистов применение теорий. Я не всегда могу объяснить как принимаю решения. Хочется сказать, что это интуиция, но пока я слушала подкаст я пришла к выводу, что на самом деле это где-то глубоко сидящие теории. Конечно опыт, навыки и системное мышление. Всё это образует фундамент и ты просто потом понимаешь, вот это я и использую. Мой мозг как огромный дата центр обладает системной принятия решений и инструментарием в виде навыков, когда из ничего, складывается картина мира. И чем больше я изучаю новые предметные области, тем быстрее это делаю и вырабатываю те самые инструменты, которые мне помогают. Много рисую, это визуализация, много пишу, это механическая память, много пересказываю, это тоже способ уложить информацию.
Вот на такие мысли меня натолкнул подкаст. На самом деле это супер интересный диалог, местами монолог Байрама. И в какой-то момент ты понимаешь, почему все им восхищаются. Общение усеяно #инсайт -ами. Даже не хочется пересказывать и спойлерить))) Но попробую сформировать, то что мне понравилось:
1. Системное мышление, когда любой контекст воспринимается как единая система. И анализ того, почему эта система сложилась именно так. Какие были условия, что происходило. На простом примере: попробуйте ответить на вопрос "почему преподаватели в вузе берут взятки?"
2. Люблю теории массового обслуживания, которые строятся на очередях. До сих пор помню проектирование работы магазина и расчет количества касс в зависимости от потока покупателей. Тут Байрам интересную вещь сказал про системную динамику, где есть резервуары и потоки. И что резервуар появляется там, где входящий и исходящий поток меняется во времени. Что любой склад по факту это и есть резервуар. Конечно я не совсем пока согласна с мыслью, что склад это ещё и "костыль" в ритейле, что были бы четкие предсказания и склад не нужен.
3. Понравилась мысль о том, что продакт это социальный инженер, который создаёт и улучшает что-то для общества.
4. Пример MVP, ох посмеялась хорошо))) о том, что выходя из метро по причине нужды, начинаешь поиск туалета, нет Макдональдса рядом, ничего нет, кроме синих вонючих кабинок со злой тётушкой на входе. Но тебе так надо, что ты заплатишь и пойдёшь делать свои дела. Синяя кабинка это как раз MVP)))
5. Тема экологии, точнее того как уменьшить своё влияние на природу. Всё никак не могла понять откуда мода в компаниях дарить термосы. Оказывается в Америке, в аэропортах есть вода, которую ты можешь налить в свой термос и не покупать пластик.
И ещё раз убедилась в том, что теории, которые были в вузе не прошли даром и что да, аналитику стоит пополнять свой багаж не только инструментами работы с артефактам, но и теориями, алгоритмами, методами из фундаментальной части различных наук.
Мыслей на самом деле больше)) И если вы будете слушать подкаст, думаю, что у вас будут другие #инсайты, тут точно #рекомендую
При этом ближе к концу Байрам перечисляет книги и рекомендации, как развивать #системноемышление, которое так нужно всем)))
https://youtu.be/5zAjCyDUQ04
Это #нереклама но этим стоит поделиться.
Подкаст Вани Замесина, разговор с Байрамом Аннаковым.
Я всё больше и больше замечаю в подкастах, в выступлениях топ-специалистов применение теорий. Я не всегда могу объяснить как принимаю решения. Хочется сказать, что это интуиция, но пока я слушала подкаст я пришла к выводу, что на самом деле это где-то глубоко сидящие теории. Конечно опыт, навыки и системное мышление. Всё это образует фундамент и ты просто потом понимаешь, вот это я и использую. Мой мозг как огромный дата центр обладает системной принятия решений и инструментарием в виде навыков, когда из ничего, складывается картина мира. И чем больше я изучаю новые предметные области, тем быстрее это делаю и вырабатываю те самые инструменты, которые мне помогают. Много рисую, это визуализация, много пишу, это механическая память, много пересказываю, это тоже способ уложить информацию.
Вот на такие мысли меня натолкнул подкаст. На самом деле это супер интересный диалог, местами монолог Байрама. И в какой-то момент ты понимаешь, почему все им восхищаются. Общение усеяно #инсайт -ами. Даже не хочется пересказывать и спойлерить))) Но попробую сформировать, то что мне понравилось:
1. Системное мышление, когда любой контекст воспринимается как единая система. И анализ того, почему эта система сложилась именно так. Какие были условия, что происходило. На простом примере: попробуйте ответить на вопрос "почему преподаватели в вузе берут взятки?"
2. Люблю теории массового обслуживания, которые строятся на очередях. До сих пор помню проектирование работы магазина и расчет количества касс в зависимости от потока покупателей. Тут Байрам интересную вещь сказал про системную динамику, где есть резервуары и потоки. И что резервуар появляется там, где входящий и исходящий поток меняется во времени. Что любой склад по факту это и есть резервуар. Конечно я не совсем пока согласна с мыслью, что склад это ещё и "костыль" в ритейле, что были бы четкие предсказания и склад не нужен.
3. Понравилась мысль о том, что продакт это социальный инженер, который создаёт и улучшает что-то для общества.
4. Пример MVP, ох посмеялась хорошо))) о том, что выходя из метро по причине нужды, начинаешь поиск туалета, нет Макдональдса рядом, ничего нет, кроме синих вонючих кабинок со злой тётушкой на входе. Но тебе так надо, что ты заплатишь и пойдёшь делать свои дела. Синяя кабинка это как раз MVP)))
5. Тема экологии, точнее того как уменьшить своё влияние на природу. Всё никак не могла понять откуда мода в компаниях дарить термосы. Оказывается в Америке, в аэропортах есть вода, которую ты можешь налить в свой термос и не покупать пластик.
И ещё раз убедилась в том, что теории, которые были в вузе не прошли даром и что да, аналитику стоит пополнять свой багаж не только инструментами работы с артефактам, но и теориями, алгоритмами, методами из фундаментальной части различных наук.
Мыслей на самом деле больше)) И если вы будете слушать подкаст, думаю, что у вас будут другие #инсайты, тут точно #рекомендую
При этом ближе к концу Байрам перечисляет книги и рекомендации, как развивать #системноемышление, которое так нужно всем)))
https://youtu.be/5zAjCyDUQ04
YouTube
#4: Байрам Аннаков про системное мышление, AI и тренды будущего
Байрам—основатель и CEO App in the Air.
Я вижу Байрама предпринимателем с крайне нетипичным способом мыслить и смотреть на мир. Байрам делится своим опытом и свежими инсайтами в ежегодных выступлениях «Эмпатика Open»: https://www.youtube.com/watch?v=MFGGyzlYexQ&…
Я вижу Байрама предпринимателем с крайне нетипичным способом мыслить и смотреть на мир. Байрам делится своим опытом и свежими инсайтами в ежегодных выступлениях «Эмпатика Open»: https://www.youtube.com/watch?v=MFGGyzlYexQ&…
#капитаночевидность #аналитик #системныйанализ #бизнесанализ
#инструменты #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
#инструменты #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
analystdays.ru
Use Case VS User Story. Выбираем подход к специфицированию требований
Две наиболее популярные техники для специфицирования требований - это Use Case и User Story. У обеих техник есть свои преимущества и недостатки. В докладе я расскажу о своем опыте использования этих техник (6 лет с Use Case, 5 лет с User Story): с какой я…
#капитаночевидность #теория #системныйаналитик #умнаямысль #системныйанализ #разработкаIT #аналитикIT #материал
Наконец-то получилось послушать Левенчука про введение в системную инженерию, правда не всю лекцию, она длинная.
На самом деле, я часто могу сделать шаг назад и поискать информацию о системном аналитике так сказать "фундаментальную".
Побывала как будто на лекции в своём вузе))) И поняла откуда это название системотехник.
Что мне понравилось, я тезисно напишу:
👉●системная инженерия говорит как нужно сделать,
👉●реализация проекта с системной инженерией равно процессу "сначала думай, потом делай",
👉●системная инженерия зародилась там, где нужно было сделать что-то большое и сложное. В Америке, сначала это была авиация и космонавтика (тадам! Привет альмаматер, вот почему подобные вузы растят крутых аналитиков), потом было строительство небоскрёбов.
👉●Наши вузы учат, как писать алгоритмы, но не как это всё собрать вместе, архитектурно с интеграцией и координацией (тадам! Проблема на многих проектах как раз в отсутствие архитектуры и набивание шишек из-за отсутствия производственного опыта).
👉●25% времени от реализации больших проектов тратится на системную инженерию
👉●Но! Трата времени на проектирование и фиксирование требований "как нужно сделать", может принести выгоду проекту до 39%!!! Если говорить про крупный проект.
👉●Работу системного инженера невозможно потрогать и на неё уходит много времени, поэтому люди не понимают смысл работы этого персонажа и отказываются от них в проектах (тадам! Нафига нам аналитик, я сам всё сделаю)) )
👉●Но! Отсутствие системного инженера приводит к переделке проектов. Встречались случаи переделки до 15 раз!)))
👉●Системный инженер немного бюрократ и работает с описанием систем. Иногда действительно влюбляется в описание, хотя до самой системы далеко)
Справедливости ради всё таки скажу, что в современных реалиях аналитик ещё и ускоряет разработку, не только приводит её к виду того, что хотел заказчик, уменьшает % переделок, но я бы ещё говорила про ускорение. Хотя Левенчук говорит противоположное, что про ускорение речь не идёт. Но гибкие методологии и современный мир айти именно про это. А запись выступления была сделана 11 лет назад.
Материала от Левенчука в сети много, и много лекций тоже, не всё конечно посмотрела, да и эту лекцию про введение в системную инженерию пока осилила только первый час) Посмотрю второй час расскажу впечатление.
Вот ссылка, кому интересно)
https://vimeo.com/7725503/comments
Наконец-то получилось послушать Левенчука про введение в системную инженерию, правда не всю лекцию, она длинная.
На самом деле, я часто могу сделать шаг назад и поискать информацию о системном аналитике так сказать "фундаментальную".
Побывала как будто на лекции в своём вузе))) И поняла откуда это название системотехник.
Что мне понравилось, я тезисно напишу:
👉●системная инженерия говорит как нужно сделать,
👉●реализация проекта с системной инженерией равно процессу "сначала думай, потом делай",
👉●системная инженерия зародилась там, где нужно было сделать что-то большое и сложное. В Америке, сначала это была авиация и космонавтика (тадам! Привет альмаматер, вот почему подобные вузы растят крутых аналитиков), потом было строительство небоскрёбов.
👉●Наши вузы учат, как писать алгоритмы, но не как это всё собрать вместе, архитектурно с интеграцией и координацией (тадам! Проблема на многих проектах как раз в отсутствие архитектуры и набивание шишек из-за отсутствия производственного опыта).
👉●25% времени от реализации больших проектов тратится на системную инженерию
👉●Но! Трата времени на проектирование и фиксирование требований "как нужно сделать", может принести выгоду проекту до 39%!!! Если говорить про крупный проект.
👉●Работу системного инженера невозможно потрогать и на неё уходит много времени, поэтому люди не понимают смысл работы этого персонажа и отказываются от них в проектах (тадам! Нафига нам аналитик, я сам всё сделаю)) )
👉●Но! Отсутствие системного инженера приводит к переделке проектов. Встречались случаи переделки до 15 раз!)))
👉●Системный инженер немного бюрократ и работает с описанием систем. Иногда действительно влюбляется в описание, хотя до самой системы далеко)
Справедливости ради всё таки скажу, что в современных реалиях аналитик ещё и ускоряет разработку, не только приводит её к виду того, что хотел заказчик, уменьшает % переделок, но я бы ещё говорила про ускорение. Хотя Левенчук говорит противоположное, что про ускорение речь не идёт. Но гибкие методологии и современный мир айти именно про это. А запись выступления была сделана 11 лет назад.
Материала от Левенчука в сети много, и много лекций тоже, не всё конечно посмотрела, да и эту лекцию про введение в системную инженерию пока осилила только первый час) Посмотрю второй час расскажу впечатление.
Вот ссылка, кому интересно)
https://vimeo.com/7725503/comments
Vimeo
Введение в системную инженерию. Лекция первая (А.И.Левенчук).
Начальное введение в системную инженерию: темы разных определений системной инженерии, зачем нужна системная инженерия, связь системной инженерии и системного мышления,…
#нотации #теория #мойопыт #бизнеспроцесс #проопыт
Про нотации))
Я знаю, что многие любят теорию. Немного #мысливслух о том, чем хороши нотации.
Нотация - фактически язык, которым общаются все кто читает диаграммы. Набор графических элементов и правил для моделирования бизнес - процессов или проектирования информационных систем. Диаграммы в свою очередь это способ выстроить и передать информацию в виде картинок.
Если мы приходим в третьяковку, то большинство картин мы понимаем и они доступны для всех, в смысле впечатления и оценки таланта художника. Но часть картин не очень понятна, если ты не понимаешь вцелом какие-то основы стиля, периода творчества и другие вещи, за которые художника любят и считают прорывным.
Так и с нотациями, есть те, которые специалиста ограничивают. Фактически у тебя есть шаблон и он заставляет тебя задуматься о вещах, которые ты мог забыть. Ты работаешь именно с чётким языком описания.
В этом плане мне нравится IDEF0 и epc (Aris) . Я часто забываю про IDEF0, как средство которое помогает понять картину мира, и место в этом мире нового бизнес - процесса. Где вход, где выход, какие роли, ресурсы нужны, управляющие процессы. И это один взгляд, а другой это тот же epc (Aris) , где чередование "событие" - "действие", также тебя ставит в позицию подумать и увидеть свои пробелы.
Нет единого "золотого ключика" , для любой двери. Поэтому я стараюсь смотреть на задачу с разных точек зрения и пробовать описывать тот же бизнес - процесс разными нотациями. Это интересная штука. Мы когда-то пробовали с аналитиками один и тот же процесс описать в bpmn и epc, и сравниваешь где какие плюсы, что стало лучше? Хорошая практика, если есть те кто готов у вас в команде такое провести, рекомендую пропустить через себя. То есть это фактически валидация работы аналитика.
Когда большая насмотренность, много опыта применения нотаций, можешь даже создать свой язык для диаграмм.
Uml все считают избыточным, и иногда я вижу как креативные аналитики используют элементы uml, создают свой язык общения с заказчиком.
Из моей практики, был такой случай, когда заказчик очень хотел аналитика со знанием uml. Я пришла на проект, нарисовала пару диаграмм, заказчик не понял. И тогда "яйца uml" мы использовали не как use cases, а просто как бизнес области проекта, этапы проекта. Главное заказчик понял))) Нарушили нотацию, но цель достигли. Также на конференции видела доклад аналитика, о том как с госами придумали язык, с помощью которого user interface описывали и согласовывали.
И тут тоже интересный факт, художник или скульптор сначала очень много и упорно учится основам. А достигая мастерства, начинает хулиганить и может себе позволить новый стиль, чем и занимался Дали. К чему и вас призываю))) Пробовать креативеть, там где это можно конечно, при этом валидируя себя шаблонами и правилами из нотаций.
Про нотации))
Я знаю, что многие любят теорию. Немного #мысливслух о том, чем хороши нотации.
Нотация - фактически язык, которым общаются все кто читает диаграммы. Набор графических элементов и правил для моделирования бизнес - процессов или проектирования информационных систем. Диаграммы в свою очередь это способ выстроить и передать информацию в виде картинок.
Если мы приходим в третьяковку, то большинство картин мы понимаем и они доступны для всех, в смысле впечатления и оценки таланта художника. Но часть картин не очень понятна, если ты не понимаешь вцелом какие-то основы стиля, периода творчества и другие вещи, за которые художника любят и считают прорывным.
Так и с нотациями, есть те, которые специалиста ограничивают. Фактически у тебя есть шаблон и он заставляет тебя задуматься о вещах, которые ты мог забыть. Ты работаешь именно с чётким языком описания.
В этом плане мне нравится IDEF0 и epc (Aris) . Я часто забываю про IDEF0, как средство которое помогает понять картину мира, и место в этом мире нового бизнес - процесса. Где вход, где выход, какие роли, ресурсы нужны, управляющие процессы. И это один взгляд, а другой это тот же epc (Aris) , где чередование "событие" - "действие", также тебя ставит в позицию подумать и увидеть свои пробелы.
Нет единого "золотого ключика" , для любой двери. Поэтому я стараюсь смотреть на задачу с разных точек зрения и пробовать описывать тот же бизнес - процесс разными нотациями. Это интересная штука. Мы когда-то пробовали с аналитиками один и тот же процесс описать в bpmn и epc, и сравниваешь где какие плюсы, что стало лучше? Хорошая практика, если есть те кто готов у вас в команде такое провести, рекомендую пропустить через себя. То есть это фактически валидация работы аналитика.
Когда большая насмотренность, много опыта применения нотаций, можешь даже создать свой язык для диаграмм.
Uml все считают избыточным, и иногда я вижу как креативные аналитики используют элементы uml, создают свой язык общения с заказчиком.
Из моей практики, был такой случай, когда заказчик очень хотел аналитика со знанием uml. Я пришла на проект, нарисовала пару диаграмм, заказчик не понял. И тогда "яйца uml" мы использовали не как use cases, а просто как бизнес области проекта, этапы проекта. Главное заказчик понял))) Нарушили нотацию, но цель достигли. Также на конференции видела доклад аналитика, о том как с госами придумали язык, с помощью которого user interface описывали и согласовывали.
И тут тоже интересный факт, художник или скульптор сначала очень много и упорно учится основам. А достигая мастерства, начинает хулиганить и может себе позволить новый стиль, чем и занимался Дали. К чему и вас призываю))) Пробовать креативеть, там где это можно конечно, при этом валидируя себя шаблонами и правилами из нотаций.
#мысливслух #использованиепродукта
В очередной раз услышала фразу, про то, что "я не пользуюсь нашим продуктом".
И вспомнила как один из разработчиков, на одном из проектов пользовался только онлайн клавиатурой, и топил за то, что не нужно пользоваться личным кабинетом банка. Я уже не знаю, снимал ли он сразу всё зарплату и переводил ли её в наличные, но достаточно долго работал в банках))) И лучше было не спрашивать почему? Эти ответы не хотелось знать, как и дырки в безопасности.
Кто-то заклеивает камеры, я долгое время не ставила мобильный банк на смартфон. Каждый сходит с ума по своему. Кто-то являясь конструктором самолёта не заходит на его борт и боится летать. Кто-то делает операции по восстановлению зрения и ходит в очках.
Достаточно интересно с разработчиками обсуждать новые технологии, тенденции рынка и беспилотные машины, потому что они быстро тебя возвращают на землю. Такой холодный душ реальности)))
Но! Вернемся в продукту. Как его развивать продакту, когда вокруг вот такие сотрудники?) Кроме того, чтобы быть на своей волне и быть немного психом как Стив Джоб, не знаю других способов. Ты видишь оборотную сторону большой компании, людей кто принимает решения, как принимают решения, как делаются проекты и начинаешь очень сильно сомневаться, что стоит пользоваться продуктом))) У меня принцип работы такой, что я не берусь за проекты, где человеку, кто будет пользоваться продуктом, продукт сможет нанести травмы или будет угроза жизни. Так что мои проекты максимум портят настроение))) И считаю, что человеческая психика по определению имеет врождённые защиты. Так что псих болезни пользователей, это уже не я)))
Честно скажу, очень редко я пользовалась, тем что создавала. Где-то это было нереально, где-то отсутствовала культура. А где-то компания просто не создавала среду, в которой хотелось бы пользоваться. Например, ты как сотрудник не имел никаких скидок и преимуществ. И мало кто из руководителей, своим личным примером показывал, что пользуется услугами компании. Делаешь что-то, но оно даже тебе не нужно.
Есть ещё очень классные "отложенные" или "растянутые" мысли, когда сначала с тобой не согласны. Потому что даже и думать не могли, что так можно. А потом потихоньку меняется мнение, представление. И вот тогда человек может уже начать снимать свои защиты и присоединятся хотя бы к позднему большинству пользователей продукта (про позднее большинство, можно почитать вот в этой заметке - https://t.me/start_in_IT/13).
А вы пользуетесь продуктами вашей компании-работодателя?)
В очередной раз услышала фразу, про то, что "я не пользуюсь нашим продуктом".
И вспомнила как один из разработчиков, на одном из проектов пользовался только онлайн клавиатурой, и топил за то, что не нужно пользоваться личным кабинетом банка. Я уже не знаю, снимал ли он сразу всё зарплату и переводил ли её в наличные, но достаточно долго работал в банках))) И лучше было не спрашивать почему? Эти ответы не хотелось знать, как и дырки в безопасности.
Кто-то заклеивает камеры, я долгое время не ставила мобильный банк на смартфон. Каждый сходит с ума по своему. Кто-то являясь конструктором самолёта не заходит на его борт и боится летать. Кто-то делает операции по восстановлению зрения и ходит в очках.
Достаточно интересно с разработчиками обсуждать новые технологии, тенденции рынка и беспилотные машины, потому что они быстро тебя возвращают на землю. Такой холодный душ реальности)))
Но! Вернемся в продукту. Как его развивать продакту, когда вокруг вот такие сотрудники?) Кроме того, чтобы быть на своей волне и быть немного психом как Стив Джоб, не знаю других способов. Ты видишь оборотную сторону большой компании, людей кто принимает решения, как принимают решения, как делаются проекты и начинаешь очень сильно сомневаться, что стоит пользоваться продуктом))) У меня принцип работы такой, что я не берусь за проекты, где человеку, кто будет пользоваться продуктом, продукт сможет нанести травмы или будет угроза жизни. Так что мои проекты максимум портят настроение))) И считаю, что человеческая психика по определению имеет врождённые защиты. Так что псих болезни пользователей, это уже не я)))
Честно скажу, очень редко я пользовалась, тем что создавала. Где-то это было нереально, где-то отсутствовала культура. А где-то компания просто не создавала среду, в которой хотелось бы пользоваться. Например, ты как сотрудник не имел никаких скидок и преимуществ. И мало кто из руководителей, своим личным примером показывал, что пользуется услугами компании. Делаешь что-то, но оно даже тебе не нужно.
Есть ещё очень классные "отложенные" или "растянутые" мысли, когда сначала с тобой не согласны. Потому что даже и думать не могли, что так можно. А потом потихоньку меняется мнение, представление. И вот тогда человек может уже начать снимать свои защиты и присоединятся хотя бы к позднему большинству пользователей продукта (про позднее большинство, можно почитать вот в этой заметке - https://t.me/start_in_IT/13).
А вы пользуетесь продуктами вашей компании-работодателя?)
Telegram
Анализ с Натальей. Записки ИТ специалиста
#теория #продукт #материалы #инновации
Для тех кто не в курсе, есть диффузная модель Everett M. "Ev" Rogers (Эверетта Роджерса) распространения инноваций.
Советую на неё посмотреть, почитать. Особенно интересен момент "пропасти" через которую не могут перескочить…
Для тех кто не в курсе, есть диффузная модель Everett M. "Ev" Rogers (Эверетта Роджерса) распространения инноваций.
Советую на неё посмотреть, почитать. Особенно интересен момент "пропасти" через которую не могут перескочить…
#Sкривая #технологии #теория #рассуждения #мысливслух
Я так часто говорю про S-кривую развития технологии, что похоже пора бы её уже зафиксировать тут.
Начнём с определения термина технология. Очень многогранный термин. Первая ассоциация с технологией у меня, что это что-то новое, инновационное, что доступно в качестве знания ограниченному кругу людей. И это некий набор способов изготовления чего либо. У меня всё таки инженерный бэкграунд и технология для меня это всё таки производство деталей, и ещё идёт ассоциация с конвейером на предприятие. То есть для меня технология, это именно правила, инструменты, способы производства.
Если смотреть на перевод с древне-греческого, то это искусство, мастерство, умение + слово, смысл, мысль, понятие. Искусство мысли? Что-то не очень понятно))
Мы же работаем с информационными технологиями и #капитаночевидность они позволяют нам обрабатывать данные для получения нового качества информации, что позволяет делать выводы, анализ, принимать решения о процессе, объекте, явление. И! Даёт конкурентное преимущество!)
В ИТ очень быстро появляются технологии и также быстро умирают. Пока ты учишь как её применять она уже неактуальна.
Если посмотреть на график s - кривой, то мы вкладываем деньги и ресурсы в развитие технологии, она достигает своего пика и останавливается. После паузы появляется новый цикл уже с новой технологией. Самый простой пример, это хранение информации. Дискеты, потом CD-диски, потом жёсткие диски, а теперь уже облачные хранилища. Несколько технологий могут одновременно конкурировать друг с другом. А нам, как людям применяющим технологии, остаётся либо быть гикам, и постоянно следить за новинками, тем самым оставаться востребованными, либо уходить в фундамент технологий и быть инженерами, которые хорошо зная базу, смогут в любой момент освоить и применить новую технологию или новый виток развития технологии.
Я так часто говорю про 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, в посте ниже 👇 поговорим про них.
⚠️ А к вам вопрос, какие ещё классы систем вы встречали и которых нет у меня в списке ❓
Я думаю есть ещё что-то специфичное, что не встречалось у меня на жизненном пути))) пишите в комментариях👇
Давно у меня не было теории, поэтому вспомним про мою рубрику #про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, в посте ниже 👇 поговорим про них.
⚠️ А к вам вопрос, какие ещё классы систем вы встречали и которых нет у меня в списке ❓
Я думаю есть ещё что-то специфичное, что не встречалось у меня на жизненном пути))) пишите в комментариях👇
Telegram
Записки ИТ специалиста
#проITсистемы #мойопыт #мирвокруг #капитаночевидность #мысливслух #пополочкам #crm
CRM-системы, что это такое?
Решила я тут зафиксировать свои знания про классы или виды информационных систем.
Сподвигла меня на это реклама одного блоггера, который CRM прочитал…
CRM-системы, что это такое?
Решила я тут зафиксировать свои знания про классы или виды информационных систем.
Сподвигла меня на это реклама одного блоггера, который CRM прочитал…
#теория #мойопыт #мирвокруг #пополочкам #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
👆Выше пост, про все Классы Информационных Систем, что я встречала на практике.
Итак, про 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 - диаграмму с интересной вставкой из овалов и их цепочки. Честно, ни разу не встречала ранее. И конечно я как аналитик, пошла открыла книгу и увидела описание на диаграмме цепочку из статусов объекта, который участвует во взаимодействие.
К вам вопрос: встречали ли подобное описание и используете ли в своей практике? Удобно ли? Какие мысли?)
Сегодня предлагаю устроить обмен опытом. На днях девушка мне показала sequence - диаграмму с интересной вставкой из овалов и их цепочки. Честно, ни разу не встречала ранее. И конечно я как аналитик, пошла открыла книгу и увидела описание на диаграмме цепочку из статусов объекта, который участвует во взаимодействие.
К вам вопрос: встречали ли подобное описание и используете ли в своей практике? Удобно ли? Какие мысли?)
#теория #криваяБандуры #освоениематериала #обучение #новаяпредметнаяобласть
Я снова и снова наступаю на одни и те же грабли)) Сколько бы ты теорий не знал, как бы не работал над собой, а мозг есть мозг)) И он точит и говорит, чёт плохо выходит, нет результата. А подождать? Нееее уже столько вложила, просто ничего не выходит. Ты бездарность, плохо стараешься и точка!
И я не одна такая. И тут меня может успокоить кривая Бандуры. Я сначала думала, что она так названа потому что похожа на украинский музыкальный инструмент, но нет)) Её нарисовал Альберт Бандура))
И что можно увидеть? Что в самом начале всегда есть результат в новом деле, но в какой-то момент мы выходим на плато, и результат будет, но нужно перейти через плато. Нужно подождать. О спасибо #капитаночевидность при этом мозг хочет мгновенной отдачи. В этот момент хочется всё бросить.
Так что как я успокаиваю себя кривой Бандуры и как мышь продолжаю есть свой сыр (об этой аналогии освоения нового пост вот тут - > https://t.me/start_in_IT/315).
Я снова и снова наступаю на одни и те же грабли)) Сколько бы ты теорий не знал, как бы не работал над собой, а мозг есть мозг)) И он точит и говорит, чёт плохо выходит, нет результата. А подождать? Нееее уже столько вложила, просто ничего не выходит. Ты бездарность, плохо стараешься и точка!
И я не одна такая. И тут меня может успокоить кривая Бандуры. Я сначала думала, что она так названа потому что похожа на украинский музыкальный инструмент, но нет)) Её нарисовал Альберт Бандура))
И что можно увидеть? Что в самом начале всегда есть результат в новом деле, но в какой-то момент мы выходим на плато, и результат будет, но нужно перейти через плато. Нужно подождать. О спасибо #капитаночевидность при этом мозг хочет мгновенной отдачи. В этот момент хочется всё бросить.
Так что как я успокаиваю себя кривой Бандуры и как мышь продолжаю есть свой сыр (об этой аналогии освоения нового пост вот тут - > https://t.me/start_in_IT/315).
#управлениеизменениями #графикизменений #теория #мойопыт #мысливслух #аналитик #бизнесаналитик #системныйаналитик
Я сегодня побуду #капитаночевидность и попробую хотя бы начать рассказ про управление изменениями. Всё таки как ни крути, а приходится касаться этой темы, потому что любые изменения идут через сильное сопротивление.
Градус сопротивления зависит от человека, компании, гибкости и вцелом навыка интегрирования нового в среду.
График внедрения изменений прикладываю в комментариях. 👇
Тут как и со многими теориями я действовала по наитию, а потом уже увидела теорию и подтвердила сама себе, что всё правильно.
✅ Шаг 1. Прежде всего понять, что изменения нужны. Как и с многим в нашей жизни, нужно просто это проговорить. Лучше записать и показать факты, метрики.
✅ Шаг 2. Все будут сопротивляться. Все, Все да не все. Своих тех кто тоже за изменения и понимает, что давно пора такие тоже всегда есть. Нужно заручиться их поддержкой.
✅ Шаг 3. Дальше идём по графику и главное иметь больше поддержки и добавлять всё новых и новых в свои ряды. Когда ты адекватно оперируешь фактами, найти светлые головы не трудно, трудно попробовать удержать оптимизм и довести дело до конца, копая и копая. И сразу работая по-другому хотя бы в какой-то части. Как только изменение будет крутым, может пойти лавина и всё рядом.
К сожалению в большинстве своём аналитик мало имеет влияния. Поэтому достаточно сложно что-то делать, не имея на это полномочий, или не получая от руководства поддержки или ещё лучше делегирования поручений на внедрение изменений. Мол всё, Наташа давай свои шаблоны и внедряем их в конфлюес!!
Обычно идёт противочерие: ты внедряй, да, да, да иди, но я тебе инструмент не дам, копай землю руками, я посмотрю, начнёт получатся, вот тогда, может быть.... Лопату тебе куплю.
✅ Шаг 4. Всё рушится в точке, когда уже никто не верит, все устали, и просто хотят махнуть рукой. Мол, ну ладно, итак жили, к черту эти изменения. Это самый сложный период. Моральный дух падает все устали, вот тогда первые шаги могут уже давать свои плоды и график можно переломить и погнать вверх.
Цикл внедрения изменений зависит от масштаба. Что-то что делать нужно годами, тут я только в своей личной жизни внедряю))) В компании беру что-то сроком максимум полгода.
Удавалось ли мне всё внедрять? Нет конечно. Но были ли успехи? Однозначно. Трудно, тяжело, но очень интересно, а как же будет потом после изменений то. Ради этого интереса часто дожимала. Но если мои интересы противоречили интересам руководителей или менеджерам, исход понятен. Я чаще всего шла выше, эскалация меня убирала))) или просто делали условия невыносимыми, чтобы я сама ушла. А я уже столько сил потеряла в этом внедрении, что уже не могла дальше работать. Что-то было оправдано, что-то нет, но опыт есть опыт и понимание того, что вставая на тропу изменений, нужно беречь прежде всего свои силы, потому что моральный настрой надо поддерживать. Плюс можно брать для начала небольшие, посильные вещи. Маленькие победы это много энергии и уверенность в себе.
Из позиции, что я реально могу сделать сам в этих условиях, минимально? И дальше новый вопрос - а действительно ли моё текущее состояние мне позволяет это сделать?
Ну и конечно вопрос - а это правда нужно, или я просто сошла с ума?
Быть Чегеварой интересно, но опасно, он плохо кончил))))
А ничего не менять, это не жить, как по мне)))) Остаётся выбор в виде гармонии, к этому и стремлюсь, не всегда конечно получается. 😜
Я сегодня побуду #капитаночевидность и попробую хотя бы начать рассказ про управление изменениями. Всё таки как ни крути, а приходится касаться этой темы, потому что любые изменения идут через сильное сопротивление.
Градус сопротивления зависит от человека, компании, гибкости и вцелом навыка интегрирования нового в среду.
График внедрения изменений прикладываю в комментариях. 👇
Тут как и со многими теориями я действовала по наитию, а потом уже увидела теорию и подтвердила сама себе, что всё правильно.
✅ Шаг 1. Прежде всего понять, что изменения нужны. Как и с многим в нашей жизни, нужно просто это проговорить. Лучше записать и показать факты, метрики.
✅ Шаг 2. Все будут сопротивляться. Все, Все да не все. Своих тех кто тоже за изменения и понимает, что давно пора такие тоже всегда есть. Нужно заручиться их поддержкой.
✅ Шаг 3. Дальше идём по графику и главное иметь больше поддержки и добавлять всё новых и новых в свои ряды. Когда ты адекватно оперируешь фактами, найти светлые головы не трудно, трудно попробовать удержать оптимизм и довести дело до конца, копая и копая. И сразу работая по-другому хотя бы в какой-то части. Как только изменение будет крутым, может пойти лавина и всё рядом.
К сожалению в большинстве своём аналитик мало имеет влияния. Поэтому достаточно сложно что-то делать, не имея на это полномочий, или не получая от руководства поддержки или ещё лучше делегирования поручений на внедрение изменений. Мол всё, Наташа давай свои шаблоны и внедряем их в конфлюес!!
Обычно идёт противочерие: ты внедряй, да, да, да иди, но я тебе инструмент не дам, копай землю руками, я посмотрю, начнёт получатся, вот тогда, может быть.... Лопату тебе куплю.
✅ Шаг 4. Всё рушится в точке, когда уже никто не верит, все устали, и просто хотят махнуть рукой. Мол, ну ладно, итак жили, к черту эти изменения. Это самый сложный период. Моральный дух падает все устали, вот тогда первые шаги могут уже давать свои плоды и график можно переломить и погнать вверх.
Цикл внедрения изменений зависит от масштаба. Что-то что делать нужно годами, тут я только в своей личной жизни внедряю))) В компании беру что-то сроком максимум полгода.
Удавалось ли мне всё внедрять? Нет конечно. Но были ли успехи? Однозначно. Трудно, тяжело, но очень интересно, а как же будет потом после изменений то. Ради этого интереса часто дожимала. Но если мои интересы противоречили интересам руководителей или менеджерам, исход понятен. Я чаще всего шла выше, эскалация меня убирала))) или просто делали условия невыносимыми, чтобы я сама ушла. А я уже столько сил потеряла в этом внедрении, что уже не могла дальше работать. Что-то было оправдано, что-то нет, но опыт есть опыт и понимание того, что вставая на тропу изменений, нужно беречь прежде всего свои силы, потому что моральный настрой надо поддерживать. Плюс можно брать для начала небольшие, посильные вещи. Маленькие победы это много энергии и уверенность в себе.
Из позиции, что я реально могу сделать сам в этих условиях, минимально? И дальше новый вопрос - а действительно ли моё текущее состояние мне позволяет это сделать?
Ну и конечно вопрос - а это правда нужно, или я просто сошла с ума?
Быть Чегеварой интересно, но опасно, он плохо кончил))))
А ничего не менять, это не жить, как по мне)))) Остаётся выбор в виде гармонии, к этому и стремлюсь, не всегда конечно получается. 😜
#мысливслух #бизнесаналитик #бизнесмодели #александростервальдер #теория #артефакт #бизнес #productmanager
Системный зуд или бизнес - модели.
Я побуду немного #капитаночевидность хотя для меня долгое время бизнес модели были какой-то странной частью. Или вообще отсутствовали.
Есть такая штука, назову её "Системный зуд", когда чувствуешь, что тебя обманывают и какого-то пазла в картине мира не хватает, но черт побери какого???!!! Непонятно. Ты начинаешь постоянно думать, рыть и плохо спать ночами. Для меня такой деталью пазла оказались бизнес - модели по Остервальдеру. Я прекрасно знаю и вижу, как работают компании типа орифлейм или avon. Или кофейные разные подписки на кофейные капсулы, или картриджи принтеров, как расходник мега дорогой, а принтер дешёвый.
И эффект вау, меня посетил после изучения бизнес - моделей подобных компаний. #капитаночевидность Есть куча шаблонных бизнес - моделей.
И тут у меня будет вопрос, к вам, знаете ли вы и используете ли схематичное представление бизнес-моделей при анализе бизнеса, компании?
Правда от этого знания зуд превращается в анализ и дополнительные вопросы руководству.
Как-то после моей речи про бизнес-модели, и вопроса коллеги руководству с употреблением слова маржа, упал занавес непонимания. Зато я отлично поняла с кем я имею дело.
Итак, прикрепляю в комментариях 👇 схему бизнес - модели по Остервальдеру, подобное представление помогает структурированно показать ключевые элементы бизнеса и проанализировать как организация создает, поставляет и получает ценность. И кстати говоря помочь в понимание, где в этой модели сбой, чего не хватает.
Для меня это ещё один артефакт, который сверху системно даёт представление о бизнесе компании.
Системный зуд или бизнес - модели.
Я побуду немного #капитаночевидность хотя для меня долгое время бизнес модели были какой-то странной частью. Или вообще отсутствовали.
Есть такая штука, назову её "Системный зуд", когда чувствуешь, что тебя обманывают и какого-то пазла в картине мира не хватает, но черт побери какого???!!! Непонятно. Ты начинаешь постоянно думать, рыть и плохо спать ночами. Для меня такой деталью пазла оказались бизнес - модели по Остервальдеру. Я прекрасно знаю и вижу, как работают компании типа орифлейм или 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? Если да, что оно вам дало?)) Хочу опробовать этот стандарт. Если у кого-то такое же желание, предлагаю разложить любой, или ваш проект вместе))
Про 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? Если да, что оно вам дало?)) Хочу опробовать этот стандарт. Если у кого-то такое же желание, предлагаю разложить любой, или ваш проект вместе))
CodeFest 12 / 28-29 мая 2022
Цифра зрелости процессов работы команд
Management. Руслан Остропольский, СберЗдоровье
#подкаст #сережаимикрофон #яндекс #рассуждения #мысливслух #примерразвитиятехнологий
Хочу продолжить мысли и немного зафиксировать, что ребята из яндекса говорили в подкасте. 👆
Если брать историю, я бы добавила историю развития технологий, то мы как раз и получаем волны развития. Когда сначала способ передачи информации у нас не особо интересен компаниям, государству и данные передаются анонимно, а потом всё мы приходим к процессу, что дай паспорт, ИНН и другие данные о себе.
18 век письма, пишешь адрес и всё, можешь по этому адресу прийти.
Дальше телефон - даёшь номер и тебя соединяют через оператора, но прийти к тебе, это нужно знать адрес. Десятками лет этот барьер стирался и в 80-х годах можно было узнать и адрес. Дальше справочник жёлтые страницы лежал на станциях метро, я вот помню его, это уже 90-ые. Открыто можно узнать и номер телефона, и адрес. Моя мама по началу телефона могла сказать, к какому району Москвы относится телефон))
Потом интернет, и тоже все начинали со своих ник неймов, анонимности, а чем больше интернет проникает, тем больше происходит регулирования.
Теперь ждём новый способ коммуникации, который у нас также будет проходить этап анонимности))
Фактически Иван Черевко рассказал график развития технологий)))
Обычно я этот график через развития транспорта рассказываю, а вот ещё отличный пример через технологии коммуникации.
А насчёт приватности, черт его знает, стоит ли бояться, что мир прозрачен и все знают про всех. И через интернет можно найти много информации. Всё равно всё идёт к тому, чтобы эта информация была подтверждена. И интернет пока не следить за авторством, того, что появляется в сети. Фейк на фейке...
Ещё ребята обсуждают защиту финансовой информации. Всё таки PCI DSS как стандарт существует давно, и информация о платежах лучше шифруется и защищена, чем персональные данные или личные данные. При этом сотрудники Яндекса рассказали о том, что можно чистить историю заказов в яндекс)) Нехотя, но рассказали.
Вот тут то и я вспомнила одного разработчика, который так парился насчёт личного кабинета и мобильного банкинга, что пользовался виртуальной клавиатурой и заходил в банкинг только в экстренных случаях. А на телефоне у него не было приложения. Он мне пытался объяснить свою цепочку размышлений)))) Я поняла, что чем меньше знаешь, проще жить)) и в какой-то момент, когда ты знаешь как оно работает пользоваться совсем не хочется.
Про S - кривую писала вот тут: https://t.me/start_in_IT/357
Хочу продолжить мысли и немного зафиксировать, что ребята из яндекса говорили в подкасте. 👆
Если брать историю, я бы добавила историю развития технологий, то мы как раз и получаем волны развития. Когда сначала способ передачи информации у нас не особо интересен компаниям, государству и данные передаются анонимно, а потом всё мы приходим к процессу, что дай паспорт, ИНН и другие данные о себе.
18 век письма, пишешь адрес и всё, можешь по этому адресу прийти.
Дальше телефон - даёшь номер и тебя соединяют через оператора, но прийти к тебе, это нужно знать адрес. Десятками лет этот барьер стирался и в 80-х годах можно было узнать и адрес. Дальше справочник жёлтые страницы лежал на станциях метро, я вот помню его, это уже 90-ые. Открыто можно узнать и номер телефона, и адрес. Моя мама по началу телефона могла сказать, к какому району Москвы относится телефон))
Потом интернет, и тоже все начинали со своих ник неймов, анонимности, а чем больше интернет проникает, тем больше происходит регулирования.
Теперь ждём новый способ коммуникации, который у нас также будет проходить этап анонимности))
Фактически Иван Черевко рассказал график развития технологий)))
Обычно я этот график через развития транспорта рассказываю, а вот ещё отличный пример через технологии коммуникации.
А насчёт приватности, черт его знает, стоит ли бояться, что мир прозрачен и все знают про всех. И через интернет можно найти много информации. Всё равно всё идёт к тому, чтобы эта информация была подтверждена. И интернет пока не следить за авторством, того, что появляется в сети. Фейк на фейке...
Ещё ребята обсуждают защиту финансовой информации. Всё таки PCI DSS как стандарт существует давно, и информация о платежах лучше шифруется и защищена, чем персональные данные или личные данные. При этом сотрудники Яндекса рассказали о том, что можно чистить историю заказов в яндекс)) Нехотя, но рассказали.
Вот тут то и я вспомнила одного разработчика, который так парился насчёт личного кабинета и мобильного банкинга, что пользовался виртуальной клавиатурой и заходил в банкинг только в экстренных случаях. А на телефоне у него не было приложения. Он мне пытался объяснить свою цепочку размышлений)))) Я поняла, что чем меньше знаешь, проще жить)) и в какой-то момент, когда ты знаешь как оно работает пользоваться совсем не хочется.
Про S - кривую писала вот тут: https://t.me/start_in_IT/357
Telegram
Записки ИТ специалиста
#Sкривая #технологии #теория #рассуждения #мысливслух
Я так часто говорю про S-кривую развития технологии, что похоже пора бы её уже зафиксировать тут.
Начнём с определения термина технология. Очень многогранный термин. Первая ассоциация с технологией…
Я так часто говорю про S-кривую развития технологии, что похоже пора бы её уже зафиксировать тут.
Начнём с определения термина технология. Очень многогранный термин. Первая ассоциация с технологией…
#мысливслух #рассуждения #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, собирает целый комплекс знаний.
Почему аналитики плохо пишут 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, собирает целый комплекс знаний.
Telegram
Записки ИТ специалиста
#капитаночевидность #аналитик #системныйанализ #бизнесанализ
#инструменты #userstory #usecase
Вернёмся к #теория
Избитая всеми тема, какой подход лучше выбрать в фиксирование требований User Story или Use Cases.
Мало того, что многие не различают эти…
#инструменты #userstory #usecase
Вернёмся к #теория
Избитая всеми тема, какой подход лучше выбрать в фиксирование требований User Story или Use Cases.
Мало того, что многие не различают эти…