#теория #системныйанализ #мойопыт #собеседования #поискработы
Из нескольких источников ко мне прилетел один и тот же вопрос "как синтегрировать системы?"
Оказалось, что Руководители отделов на собеседованиях вместе с вопросом "кем вы видите себя через 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-диски, потом жёсткие диски, а теперь уже облачные хранилища. Несколько технологий могут одновременно конкурировать друг с другом. А нам, как людям применяющим технологии, остаётся либо быть гикам, и постоянно следить за новинками, тем самым оставаться востребованными, либо уходить в фундамент технологий и быть инженерами, которые хорошо зная базу, смогут в любой момент освоить и применить новую технологию или новый виток развития технологии.