Сегодня поразмышляем на тему рынка AI решений. После ухода иностранных вендоров российский рынок AI достаточно парадоксален - с одной стороны это технологические монстры рынка со своими "коробочными" решениями, а с другой - много мелких компаний с компетенциями и технологиями, но без законченных продуктов, только узкоспециализированными функциями.
Что произойдет в случае возвращения западных компаний на российский рынок? Смогут ли отечественные решения полноценно конкурировать или будут вытеснены? Может ли быть у российских AI решений своя "фишка", которая станет конкурентным преимуществом?
Я думаю да, если фокус в создании локальных AI решений будет в решении конкретных проблем на нашем рынке. Не европейских, не средних по Африке и Америке, а наших. Решения, заточенные под специфику языка, менталитета, отраслевых требований и законодательства будут выигрывать. У меня есть пример, не из мира AI, когда прекрасное решение для маркетплейсов Miracle, не могло составить конкуренцию российским "малышам" из-за своей ориентированности на европейский рынок (начиная с SaaS и хостеров и заканчивая коннекторами с логистическими компаниями).
Что пока тормозит развитие локальных AI решений:
🔵 Большинство решений остаются в статусе "полуфабрикатов" - технология есть, а полноценных продуктов с понятной бизнес-ценностью почти нет
🔵 Недостаток специалистов в области AI - не хватает подготовленных кадров
🔵 Все еще AI воспринимается как эксперимент, мало кейсов с четкой окупаемостью, поэтому бизнес не всегда готов инвестировать в технологию
🔵 Да и в целом - очень мало компаний, кто инвестирует в ИТ - как правило ИТ бюджет-это расходы, а не инвестиции
В итоге российский рынок AI сегодня находится на перепутье: есть хорошие наработки и понимание потребностей рынка, но для устойчивого роста необходимо превратить технологии в полноценные, масштабируемые продукты с доказанной экономической выгодой. Только это позволит отечественным решениям не просто удержаться, но и стать конкурентоспособными на фоне потенциальных конкурентов, используя свое главное преимущество - глубокую адаптацию под наши реалии.
#AI #ChatGPT #чтотампроchatgpt #data #данные #мнения
Что произойдет в случае возвращения западных компаний на российский рынок? Смогут ли отечественные решения полноценно конкурировать или будут вытеснены? Может ли быть у российских AI решений своя "фишка", которая станет конкурентным преимуществом?
Я думаю да, если фокус в создании локальных AI решений будет в решении конкретных проблем на нашем рынке. Не европейских, не средних по Африке и Америке, а наших. Решения, заточенные под специфику языка, менталитета, отраслевых требований и законодательства будут выигрывать. У меня есть пример, не из мира AI, когда прекрасное решение для маркетплейсов Miracle, не могло составить конкуренцию российским "малышам" из-за своей ориентированности на европейский рынок (начиная с SaaS и хостеров и заканчивая коннекторами с логистическими компаниями).
Что пока тормозит развитие локальных AI решений:
В итоге российский рынок AI сегодня находится на перепутье: есть хорошие наработки и понимание потребностей рынка, но для устойчивого роста необходимо превратить технологии в полноценные, масштабируемые продукты с доказанной экономической выгодой. Только это позволит отечественным решениям не просто удержаться, но и стать конкурентоспособными на фоне потенциальных конкурентов, используя свое главное преимущество - глубокую адаптацию под наши реалии.
#AI #ChatGPT #чтотампроchatgpt #data #данные #мнения
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥2👍1🤔1
Недавняя шок-новость - В России разработан стандарт качества цифровой трансформации. На самом деле Минцифры, Цифровая Экономика и Роскачество начали его разработку давно. Сам стандарт датирован 2024 годом.
В принципе правильно, а то цифровой трансформацией сейчас называется всё и вся. Порадовал факт, что в пункте 4.2 зафиксировано, что подход построен на цикле Деминга-Шухарта - PDCA. Всего стандарт выделяет шесть основных этапов цифровой трансформации:
1️⃣ оценка и анализ текущего состояния
2️⃣ стратегическое планирование
3️⃣ определение ключевых ресурсов
4️⃣ реализация запланированных мер
5️⃣ оценка полученных результатов
6️⃣ улучшение.
В пункте 4.3 стандарт устанавливает следующие принципы цифровой трансформации:
📌 ориентация на потребителя и клиентоориентированный подход
📌 анализ
📌 индивидуальный подход
📌 участие руководства
📌 мониторинг и аналитика
📌 гибкость и адаптивность
Также в документе закрепляются подходы по работе с командами и их лидерами. Стандарт содержит рекомендации по разработке особой кадровой политики, отвечающей интересам эффективной цифровой трансформации.
Ну и на сладкое - также выпущена Методика самооценки, где каждая организация может ответить на вопросы и понять свой уровень цифровизациии, что на мой взгляд очень полезно. Ну хотя бы чтоб не страдать иллюзиями. Но даже если вы не собираетесь в цифровую трансформацию или не собираетесь себя оценивать, то рекомендую прочитать список вопросов - там есть о чем подумать:
📌 В организации определены ключевые процессы, их интеграция между подразделениями и выявлены потребности в их оптимизации
📌 Организация адаптирует процессы в ответ на новые клиентские запросы или регуляторные изменения
📌 В организации внедрены методы управления качеством процессов
📌 Предпринимаются меры для поддержания мотивации и вовлеченности сотрудников в оптимизацию процессов
📌 ИТ-архитектура организации, ее цели и задачи соответствуют Стратегии цифровой трансформации
📌 Разработан план управления рисками, связанными с цифровыми технологиями
📌 Организован процесс управления изменениями, включая адаптацию бизнес-процессов к новым условиям и интеграцию новых решений с существующими системами
Понятно - вопросов там сильно больше, и все они даже не про цифровую трансформацию, а про современный бизнес, который уже немыслим без цифры. Как говорится - "…пойдете вы туда или нет, но он там будет…"
#разработка #цифроваятранформация #agile #development #продуктоваяразработка
Документ призван унифицировать основные принципы и понятия, а также определить подходы и ожидаемые результаты компаний при реализации цифровой трансформации
В принципе правильно, а то цифровой трансформацией сейчас называется всё и вся. Порадовал факт, что в пункте 4.2 зафиксировано, что подход построен на цикле Деминга-Шухарта - PDCA. Всего стандарт выделяет шесть основных этапов цифровой трансформации:
В пункте 4.3 стандарт устанавливает следующие принципы цифровой трансформации:
Также в документе закрепляются подходы по работе с командами и их лидерами. Стандарт содержит рекомендации по разработке особой кадровой политики, отвечающей интересам эффективной цифровой трансформации.
Ну и на сладкое - также выпущена Методика самооценки, где каждая организация может ответить на вопросы и понять свой уровень цифровизациии, что на мой взгляд очень полезно. Ну хотя бы чтоб не страдать иллюзиями. Но даже если вы не собираетесь в цифровую трансформацию или не собираетесь себя оценивать, то рекомендую прочитать список вопросов - там есть о чем подумать:
Понятно - вопросов там сильно больше, и все они даже не про цифровую трансформацию, а про современный бизнес, который уже немыслим без цифры. Как говорится - "…пойдете вы туда или нет, но он там будет…"
#разработка #цифроваятранформация #agile #development #продуктоваяразработка
Please open Telegram to view this post
VIEW IN TELEGRAM
👍1🔥1
Назрела необходимость завести новую рубрику - "Услышано в кулуарах". Недавно на одном из архитектурных комитетов услышал от оппонента фразу:
Если что, то для меня это прозвучало как похвала. Но я задумался, а все ли понимают, почему не надо лезть в ядро? Все ли осознают риски и принимают последствия? (*Дисклеймер - под системой здесь мы понимаем энтерпрайз систему, монолит, покупное решение)
Все банально. Ядро - фундамент, на котором всё держится. Любые изменения в ядре - это потенциальный каскад рисков:
📌 непредсказуемые побочные эффекты
📌 нарушение стабильности и быстродействия
📌 сложности при тестировании
📌 проблемы с безопасностью
📌 невозможность обновить версию системы без новых существенных доработок
Поверьте, у вас никогда не будет столько экспертизы и возможностей, сколько у создателей системы. Поэтому, когда появляется новая функциональность - не нужно "лезть в матрицу", надо строить вокруг. Можно создать отдельный внешний сервис, использовать адаптер к другой системе - всё, что угодно, но не трогать ядро.
Если вам зайдет такая аналогия, то ядро это как фундамент здания. Его нельзя перестраивать каждый раз, когда хочется поменять окна или повесить кондиционер. Оно должно быть прочным, стабильным и неизменным, чтобы всё остальное могло на нём надёжно держаться.
В общем - архитектура это не только про как сделать, но и про то, что не трогать.
И если вы приняли решение не лезть в ядро, а сделать сервис рядом — скорее всего, вы поступили дальновидно.
#услышановкулурах #разработка #впоискахсеребрянойпули #цифроваятранформация #архитектура #антипаттерны
Вы сделали (отдельный) сервис потому, что не стали влезать в ядро системы
Если что, то для меня это прозвучало как похвала. Но я задумался, а все ли понимают, почему не надо лезть в ядро? Все ли осознают риски и принимают последствия? (*Дисклеймер - под системой здесь мы понимаем энтерпрайз систему, монолит, покупное решение)
Все банально. Ядро - фундамент, на котором всё держится. Любые изменения в ядре - это потенциальный каскад рисков:
Поверьте, у вас никогда не будет столько экспертизы и возможностей, сколько у создателей системы. Поэтому, когда появляется новая функциональность - не нужно "лезть в матрицу", надо строить вокруг. Можно создать отдельный внешний сервис, использовать адаптер к другой системе - всё, что угодно, но не трогать ядро.
Если вам зайдет такая аналогия, то ядро это как фундамент здания. Его нельзя перестраивать каждый раз, когда хочется поменять окна или повесить кондиционер. Оно должно быть прочным, стабильным и неизменным, чтобы всё остальное могло на нём надёжно держаться.
В общем - архитектура это не только про как сделать, но и про то, что не трогать.
И если вы приняли решение не лезть в ядро, а сделать сервис рядом — скорее всего, вы поступили дальновидно.
#услышановкулурах #разработка #впоискахсеребрянойпули #цифроваятранформация #архитектура #антипаттерны
Please open Telegram to view this post
VIEW IN TELEGRAM
💯7👍2❤1
Оказывается, не только ИТшники любят упоротые аббревиатуры. Сегодня в ленте Линкедина (все еще заблокированного) встретил новую для себя аббревиатуру из мира негоциантов. Негоцианты, если что, это коммерсанты, переговорщики, торговцы.
Итак, встречайте - ZOPA - зона возможного соглашения (Zone Of Possible Agreement) в коммерческих переговорах. При наличии ZOPA соглашение в пределах этой зоны рационально для обеих сторон. За пределами этой зоны никакие переговоры не должны приводить к соглашению.
Живите теперь с тем фактом, что для успешности переговоров надо первоначально найти ZOPA.
#управление #шуткаюмора
Итак, встречайте - ZOPA - зона возможного соглашения (Zone Of Possible Agreement) в коммерческих переговорах. При наличии ZOPA соглашение в пределах этой зоны рационально для обеих сторон. За пределами этой зоны никакие переговоры не должны приводить к соглашению.
Живите теперь с тем фактом, что для успешности переговоров надо первоначально найти ZOPA.
#управление #шуткаюмора
🤣15👍4
Ох, обожаю я появление новых терминов. Особенно так любимых всеми ИТшниками аббревиатур из трех букв. В одном из каналов нашел ссылку на статью - "MVP vs MLP: почему минимально жизнеспособного продукта уже недостаточно в 2025 году" и очень хочу поразгонять на эту тему.
Ну и дальше по списку - MVP уже не работает, потому что в 2025 году мало сделать просто рабочий прототип, нужно чтобы пользователи "влюбились в продукт с первого касания", поэтому MLP. Вспомнили про Эрика Риса и The Lean Startup (2011) и определили, что через 14 лет все это не работает потому, что:
✖️ Высочайшие требования к UX
✖️ Конкуренция во всех нишах
✖️ Технологии упростили создание
✖️ Первое впечатление - решающее
В общем складывается впечатление, что автор поста плохо читал или плохо понял Эрика Риса и все перепутал. По Lean Startup - MVP это про поиск. Поиск Problem - Solution Fit (соответствие решения проблеме) или Product - Market Fit (соответствие продукта рынку). А если надо сразу нарисовать почти идеальный CJM, то где во всей этой истории поиск? Такое ощущение, что стартапер должен уметь сразу безошибочно заполнить все поля на канвасе, чтобы сразу продукт получился.
На самом деле, большинство стартапов умирают гораздо раньше Lovely. И не по причине плохого CJM или плохого дизайна, а потому, что не попадают решением в проблему или своим продуктом в рынок. Мало придумать новую высокотехнологическую хрень. Надо еще найти, какую действительно насущную проблему эта хрень будет решать, а потом еще и найти рынок для ее реализации.
Складывается ощущение, что автор попутал терминологию и назвал POC - MVP, а MVP - MLP. Ну или продажи MVP пошли вниз, поэтому надо срочно придумать новое название для старого термина, чтобы поднять продажи.
#гибкиеметодики #продуктоваяразработка #leanstartup #впоискахсеребрянойпули
В мире стартапов назревает сдвиг: классический подход Minimum Viable Product (MVP) больше не гарантирует успеха... … на сцену выходит концепция Minimum Lovable Product (MLP): стратегия запуска, ориентированная на создание любимого продукта с первого дня.
Ну и дальше по списку - MVP уже не работает, потому что в 2025 году мало сделать просто рабочий прототип, нужно чтобы пользователи "влюбились в продукт с первого касания", поэтому MLP. Вспомнили про Эрика Риса и The Lean Startup (2011) и определили, что через 14 лет все это не работает потому, что:
В общем складывается впечатление, что автор поста плохо читал или плохо понял Эрика Риса и все перепутал. По Lean Startup - MVP это про поиск. Поиск Problem - Solution Fit (соответствие решения проблеме) или Product - Market Fit (соответствие продукта рынку). А если надо сразу нарисовать почти идеальный CJM, то где во всей этой истории поиск? Такое ощущение, что стартапер должен уметь сразу безошибочно заполнить все поля на канвасе, чтобы сразу продукт получился.
На самом деле, большинство стартапов умирают гораздо раньше Lovely. И не по причине плохого CJM или плохого дизайна, а потому, что не попадают решением в проблему или своим продуктом в рынок. Мало придумать новую высокотехнологическую хрень. Надо еще найти, какую действительно насущную проблему эта хрень будет решать, а потом еще и найти рынок для ее реализации.
Складывается ощущение, что автор попутал терминологию и назвал POC - MVP, а MVP - MLP. Ну или продажи MVP пошли вниз, поэтому надо срочно придумать новое название для старого термина, чтобы поднять продажи.
#гибкиеметодики #продуктоваяразработка #leanstartup #впоискахсеребрянойпули
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4💯3❤1🔥1
Пришел к мысли, что надо продолжить писать свои Записки программиста, и вот что получилось:
Записки программиста. День 417.
Сегодня в ТЗ появилась новая строчка:
Не быстрое. Не безопасное. Не стабильное. Просто, *ука, удобное.
Я почувствовал себя как в том анекдоте: "Доктор, у меня что-то болит где-то вот тут…"
Начал искать, что заказчик имел в виду.
Спросил: - А что значит "удобное"?
Ответ: - "Ну чтобы человеку приятно было... пользоваться".
Ну круто, теперь всё ясно. Надо вставить в код usePleasure() и autoUserSatisfaction(true).
Ладно, на фиг, решил перевести это на технический.
Применил поверхностные навыки глубинного интервью:
🟢 Для кого удобно? (новичок, эксперт, бабушка?)
🟢 На чём удобно? (телефон, планшет, холодильник?)
🟢 В чём удобно? (скорость? структура? кнопки с душой?)
Ответ был неожиданный, ну как в том фильме про 7 перпендикулярных линий: "Ну вы же профи, вы же понимаете".
Понял. Пошёл ставить темную тему и анимации - беспроигрышный вариант, когда говорим про удобство.
В итоге написал требования сам:
Отправил заказчику. Он одобрил - "Да, да, вот теперь прям удобно"
В общем теперь каждый раз, когда вижу "удобно", сразу думаю: удобно кому, когда, и почему это опять моя проблема. В общем - если в ТЗ написано "удобное приложение" - это не требование, это из области метафизики. Будьте осторожны, там рядом обычно бродит "интуитивно понятно" и "должно просто работать".
#антипаттерны #управление #разработка #никогдатакогонебыло #шуткаюмора
Записки программиста. День 417.
Сегодня в ТЗ появилась новая строчка:
Приложение должно быть удобным.
Не быстрое. Не безопасное. Не стабильное. Просто, *ука, удобное.
Я почувствовал себя как в том анекдоте: "Доктор, у меня что-то болит где-то вот тут…"
Начал искать, что заказчик имел в виду.
Спросил: - А что значит "удобное"?
Ответ: - "Ну чтобы человеку приятно было... пользоваться".
Ну круто, теперь всё ясно. Надо вставить в код usePleasure() и autoUserSatisfaction(true).
Ладно, на фиг, решил перевести это на технический.
Применил поверхностные навыки глубинного интервью:
Ответ был неожиданный, ну как в том фильме про 7 перпендикулярных линий: "Ну вы же профи, вы же понимаете".
Понял. Пошёл ставить темную тему и анимации - беспроигрышный вариант, когда говорим про удобство.
В итоге написал требования сам:
Основные сценарии (регистрация, заказ, оплата) должны занимать не более 3 шагов и проходить без ошибок у 95% пользователей по данным аналитики
Отправил заказчику. Он одобрил - "Да, да, вот теперь прям удобно"
В общем теперь каждый раз, когда вижу "удобно", сразу думаю: удобно кому, когда, и почему это опять моя проблема. В общем - если в ТЗ написано "удобное приложение" - это не требование, это из области метафизики. Будьте осторожны, там рядом обычно бродит "интуитивно понятно" и "должно просто работать".
#антипаттерны #управление #разработка #никогдатакогонебыло #шуткаюмора
Please open Telegram to view this post
VIEW IN TELEGRAM
🤣10💯6😁5
В очередной раз возвращаемся к теме Микросервисной архитектуры и сегодня посмотрим на антипаттерны в которые можно попасть, когда вы заходите на проектирование микросервисов.
Поехали:
1️⃣ Монолитный образ мысли. Делаем микросервисы, как привыкли делать монолитные приложения - сильная связанность, взаимозависимости сервисов, ограниченная автономность. Забываем про нормальное масштабирование, отказоустойчивость и высокую нагрузку
2️⃣ Монолит данных. Много сервисов, а БД - одна. Возникает жёсткая связь по данным, получаем сложности с согласованностью и узкие места по производительности
3️⃣ Болтливые сервисы. Чрезмерный обмен сообщениями между сервисами приводит к перегрузке, высокой задержке и повышенному использованию ресурсов
4️⃣ Неверно определенные границы сервисов. Либо сервисов мало - мегасервисы, либо слишком много - излишняя декомпозиция и микросервисный ад. И в том, и в другом случае получаем хаос, идем решать сложности с разработкой, тестированием и выкаткой
5️⃣ Расползание сервисов. Много сервисов без четкого контроля и управления. Все бесконтрольно создают сервисы - забываем о том, чтобы хоть что-то понимать в нашей архитектуре и направлении нашего движения
6️⃣ Отсутствие agnostic подхода. Мы верим в K8S или в BareMetal или в Managed services от нашего облачного провайдера и сильно удивляемся, когда все наше решение оказывается прибито гвоздями к конкретной реализации
7️⃣ Игнорировать observability и удивляться, что система нестабильна, время восстановления растет, контроль - утрачивается
Что со всем этим делать? Если вы увидели что-то вам знакомое, значит скорее всего вам не показалось. Пока все не разъехалось в разные стороны надо остановиться, провести аудит того, что уже наделали, внедрить архитектурный надзор или контроль и уже идти дальше, стараясь не допускать нарушений. Микросервисы - классная технология, но ее надо уметь готовить и понимать, зачем именно вам она нужна? Какие ваши вопросы она решает? И все будет хорошо.
#архитектура #development #разработка #платформы #впоискахсеребрянойпули #антипаттерны
Поехали:
Что со всем этим делать? Если вы увидели что-то вам знакомое, значит скорее всего вам не показалось. Пока все не разъехалось в разные стороны надо остановиться, провести аудит того, что уже наделали, внедрить архитектурный надзор или контроль и уже идти дальше, стараясь не допускать нарушений. Микросервисы - классная технология, но ее надо уметь готовить и понимать, зачем именно вам она нужна? Какие ваши вопросы она решает? И все будет хорошо.
#архитектура #development #разработка #платформы #впоискахсеребрянойпули #антипаттерны
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4💯4👍1
Про клиентский опыт, иногда бессмысленный и беспощадный. Конец прошлой недели ознаменовался странным общением с Альфа-банком по поводу заблокированных мобильных доступов к мобильным приложениям и личному кабинету.
Началось все странно. Неожиданно меня выкинуло из мобильного приложения, а при попытке входа стало писать "Неверные данные". Вначале я подумал, что у банка проблемы, но поспрашивав у друзей понял, что проблемы только у меня и позвонил на горячую линию. И тут начались чудеса. Девушка-оператор, приятным голосом сообщила мне, что я заблокирован потому, что совершил какой-то непонятный платеж…
Предыстория - пару недель назад я оплатил обучение своей дочки в институте. Как и последние три года, я взял квитанцию, отсканировал QR-код, нажал оплатить и вдруг платеж стал "непонятным". Мне рассказали про 115 ФЗ, про правила обслуживания банка, про налоговую, но никто так и не смог объяснить, почему платеж физического лица в сторону Федерального государственного автономного образовательного учреждения вдруг вызвал повышенный интерес.
Финал - я приехал в офис, где мне пришлось с документами доказывать, что Андреева А.А. является моей дочкой и что я действительно плачу за ее обучение. После чего меня разблокировали. Я трижды проверил в приложении и в смс информацию - никто и ничего мне не присылал и не уведомлял о том, что мне нужно приехать в банк и что-то доказать.
Пост Финал - я запросил у банка официальные разъяснения со ссылками на пункты законов, подзаконных актов, договора о банковском обслуживании и получил в ответ реально стандартную отписку:
Все это вкупе дает достаточно печальную картинку. Обычная оплата по квитанции (представляете себе сколько сейчас оплат идет в сторону институтов) превращается в квест. Даже если предположить, что оплата насторожила, то где уведомление на e-mail, смс, личный кабинет? Почему приложение просто выбрасывает из себя и не дает внятных инструкций - что делать? Почему банк не может объяснить, на основании чего он это сделал? Почему присылают дебильное сообщение и еще просят в смс оценить качество ответа? Мне очень нравился сервис Альфы, но теперь я даже не знаю, что и думать.
#клиентскийопыт #еком #CX #CJM #мнения
Началось все странно. Неожиданно меня выкинуло из мобильного приложения, а при попытке входа стало писать "Неверные данные". Вначале я подумал, что у банка проблемы, но поспрашивав у друзей понял, что проблемы только у меня и позвонил на горячую линию. И тут начались чудеса. Девушка-оператор, приятным голосом сообщила мне, что я заблокирован потому, что совершил какой-то непонятный платеж…
Предыстория - пару недель назад я оплатил обучение своей дочки в институте. Как и последние три года, я взял квитанцию, отсканировал QR-код, нажал оплатить и вдруг платеж стал "непонятным". Мне рассказали про 115 ФЗ, про правила обслуживания банка, про налоговую, но никто так и не смог объяснить, почему платеж физического лица в сторону Федерального государственного автономного образовательного учреждения вдруг вызвал повышенный интерес.
Финал - я приехал в офис, где мне пришлось с документами доказывать, что Андреева А.А. является моей дочкой и что я действительно плачу за ее обучение. После чего меня разблокировали. Я трижды проверил в приложении и в смс информацию - никто и ничего мне не присылал и не уведомлял о том, что мне нужно приехать в банк и что-то доказать.
Пост Финал - я запросил у банка официальные разъяснения со ссылками на пункты законов, подзаконных актов, договора о банковском обслуживании и получил в ответ реально стандартную отписку:
…В соответствии с Договором комплексного банковского обслуживания, в случае обнаружения или возникновения подозрений у нас о неправомерности проводимых операций с использованием вашей карты, мы вправе блокировать карты и не исполнять поручения до выяснения обстоятельств. Мы не преследуем цели создать вам какие-либо неудобства, а думаем в первую очередь о безопасности.
Все это вкупе дает достаточно печальную картинку. Обычная оплата по квитанции (представляете себе сколько сейчас оплат идет в сторону институтов) превращается в квест. Даже если предположить, что оплата насторожила, то где уведомление на e-mail, смс, личный кабинет? Почему приложение просто выбрасывает из себя и не дает внятных инструкций - что делать? Почему банк не может объяснить, на основании чего он это сделал? Почему присылают дебильное сообщение и еще просят в смс оценить качество ответа? Мне очень нравился сервис Альфы, но теперь я даже не знаю, что и думать.
#клиентскийопыт #еком #CX #CJM #мнения
🤔5👀4😢2🤬1
За последние несколько месяцев в общении с коллегами по цеху очень часто стала всплывать проблема защищенности подрядчиков. Не секрет, что мы все пользуемся подрядчиками: аутсорсинг разработки, интеграторы, DevOps'ы на подряде, поддержка 24/7 - всё это удобно, быстро и, казалось бы что могло пойти не так?
А все достаточно просто:
✖️ Слабая защита инфраструктуры и слабый контроль доступа на стороне самого подрядчика
✖️ Доступы по VPN в вашу инфраструктуру
✖️ Привилегированные учетки подрядчика в проде
✖️ Отсутствие логирования и мониторинга действий и доступов внутри сети
✖️ Ну и самое страшное - полное доверие к внешней команде, как к своей
В результате вы читаете о себе в новостях об инцидентах кибербезопасности и размышляете, что-же надо с этим всем делать. А делать надо следующие шаги:
📌 Пересматриваем модель доступа. Не надо подрядчику ходить туда, куда у вас даже не все мидлы и сеньеры имеют доступ. Изолируем среды, внедряем четкие правила доступа, автоматически отключаем неактивные сессии и мониторим неиспользуемые доступы
📌 Пересматриваем контракты с подрядчиками. Добавляем требования по безопасности, добавляем ответственность за инциденты, требования к регулярному аудиту
📌 Zero Trust - для всех и вся. Верифицируем каждый шаг. Многофакторка, логи, контроль подозрительной активности, сетевые политики
📌 Регулярный аудит. Кто деплоит код? Где код хранится? Кто имеет доступ к CI/CD? Контролируете ли вы все эти процессы?
📌 Фиксируем и мониторим. Все действия в лог, странные действия в алерты
Да, самая идеальная защита - это полная изоляция. Не пользуемся подрядчиками, отключаем все внешние точки входа, капсулируемся и живем без выхода наружу. В современном мире (в коммерческом) это утопия. У вас десятки точек входа, и каждая из них может выстрелить. Ваши подрядчики - часть модели угроз и относиться к ним надо соответствующе.
И, да. Безопасность - это не только про антивирус и регулярную смену пароля. Это про дисциплину и про немалую ответственность.
#итбезопасность #кибербезопасность #ИТбез #разработка
А все достаточно просто:
В результате вы читаете о себе в новостях об инцидентах кибербезопасности и размышляете, что-же надо с этим всем делать. А делать надо следующие шаги:
Да, самая идеальная защита - это полная изоляция. Не пользуемся подрядчиками, отключаем все внешние точки входа, капсулируемся и живем без выхода наружу. В современном мире (в коммерческом) это утопия. У вас десятки точек входа, и каждая из них может выстрелить. Ваши подрядчики - часть модели угроз и относиться к ним надо соответствующе.
И, да. Безопасность - это не только про антивирус и регулярную смену пароля. Это про дисциплину и про немалую ответственность.
#итбезопасность #кибербезопасность #ИТбез #разработка
Please open Telegram to view this post
VIEW IN TELEGRAM
👍13💯8
И снова про команды и управление ими. В условиях, когда все быстро меняется, и требования, и стратегия, и технологии, стабильность и продуктивность команд - ключевой фактор успеха. Классическая модель жизненного цикла команд Брюса Такмана, предложенная ещё в 1965 году, остаётся актуальной и сегодня - особенно в контексте кросс-функциональных и гибких команд.
Такман выделял 5 этапов жизненного цикла команд:
1️⃣ Формирование (Forming). Команда собирается, участники пытаются разобраться в задачах, ролях и корпоративной культуре. Присутствует высокий уровень неопределённости и осторожности, низкий уровень инициативы. Основные риски - Непонимание окружения, целей и ожиданий. Роль лидера на этом этапе - разъяснение структуры и целей, выстраивание доверия и коммуникаций
2️⃣ Притирка (Storming). Начинают возникать конфликты - люди начинают бороться за влияние или критиковать и оспаривать процессы, роли, подходы, ответственности. Основные риски - Конфликты, снижение мотивации, текучка. Роль лидера - Модерация конфликтов и фасилитация диалогов, управление ожиданиями, установление правил работы.
3️⃣ Нормализация (Norming). Члены команды договариваются о правилах игры, появляется командная работа, формируется доверие и неформальные правила взаимодействия. Основные риски - конформизм, боязнь обратной связи, заниженные ожидания. Роль лидера - поощрение инициативы, развитие обратной связи, поддержание прозрачности
4️⃣ Эффективность (Performing). Пик эффективности команды при минимуме управления. Высокая степень автономности, адаптивности, взаимоподдержки. Основные риски - потеря гибкости, выгорание ключевых членов команды. Роль лидера - фокус на развитии и масштабировании, сопровождение команды
5️⃣ Расставание ( Adjourning). Команда завершает проект и/или расформировывается. Основные риски - снижение мотивации, стресс, потеря накопленного опыта. Роль лидера - формализация результатов, ретроспектива, сохранение экспертизы
Модель эффективна:
✔️ при формировании проектных и продуктовых команд
✔️ в проектах трансформации
✔️ для оценки готовности команд к автономной работе
✔️ как основа для развития менеджеров команд
По этой модели можно диагностировать состояние команд и менять стиль управления командами. При этом в практике возможен откат на предыдущие этапы в случае изменения состава команды, смены руководства, перевода команды на другие задачи.
Почему важно отслеживать этапы команды? Если проигнорировать стадию Притирки, то можно недооценить риски. Если вовремя не распознать Нормализацию, то сложно будет держать устойчивый темп. А если слишком рано потребовать Эффективности, то можно получить выгорание и хаос.
#разработка #цифроваятранформация #agile #development #впоискахсеребрянойпули #мотивация
Такман выделял 5 этапов жизненного цикла команд:
Модель эффективна:
По этой модели можно диагностировать состояние команд и менять стиль управления командами. При этом в практике возможен откат на предыдущие этапы в случае изменения состава команды, смены руководства, перевода команды на другие задачи.
Почему важно отслеживать этапы команды? Если проигнорировать стадию Притирки, то можно недооценить риски. Если вовремя не распознать Нормализацию, то сложно будет держать устойчивый темп. А если слишком рано потребовать Эффективности, то можно получить выгорание и хаос.
#разработка #цифроваятранформация #agile #development #впоискахсеребрянойпули #мотивация
Please open Telegram to view this post
VIEW IN TELEGRAM
👍15❤2
В начале месяца с удовольствием прослушал семинар Positive Technologies на тему "Остается ли в тайне ваш диалог с LLM? Как использовать большие языковые модели безопасно!". Алексей Лукацкий и его команда, как всегда, были неподражаемы.
Лишний раз я получил подтверждение, что ИИ - это такая же технология, как и все другие, а не магия. А раз это технология, то в отношении нее действуют такие же правила кибербеза, как и в отношении других технологий. Даже так - правил больше, поскольку технология хайповая и все стремятся начать ее пользовать, невзирая на опасности. Поэтому и компрометация конфиденциальной информации и персональных данных и потеря интеллектуальной собственности и все остальное по списку.
Если по цифрам:
✅ 15% - рост затрат на безопасность ИИ из-за рисков, которые несет GenAI
✅ 55% сотрудников - используют в работе несанкционированные GenAI
✅ 62% атак на ИИ совершаются внутренними сотрудниками
(* исследования Gartner и Salesforce)
Ну и примеры из любимого мной сериала - "ИИ заменяет разработчика":
✖️ Код - риск содержания небезопасного кода: инъекции, уязвимости итд. и риск генерации кода на базе публичных репозиториев
✖️ API - генерация swagger - риск раскрытия закрытых методов API, некорректная документация
✖️ Автотесты - эксплойты вместо тестов
✖️ Конфиги - генерация конфигов с избыточными правами и известными уязвимостями
✖️ SQL запросы - инъекции и раскрытие схем БД
На волне хайпа использования ИИ везде, где только можно, стоит помнить и учитывать реальные последствия бездумного использования ИИ. Ссылка на вебинар и все сопутствующие документы - тут.
#кибербезопасность #ИТбез #разработка #AI #ChatGPT #чтотампроchatgpt
Лишний раз я получил подтверждение, что ИИ - это такая же технология, как и все другие, а не магия. А раз это технология, то в отношении нее действуют такие же правила кибербеза, как и в отношении других технологий. Даже так - правил больше, поскольку технология хайповая и все стремятся начать ее пользовать, невзирая на опасности. Поэтому и компрометация конфиденциальной информации и персональных данных и потеря интеллектуальной собственности и все остальное по списку.
Если по цифрам:
(* исследования Gartner и Salesforce)
Ну и примеры из любимого мной сериала - "ИИ заменяет разработчика":
На волне хайпа использования ИИ везде, где только можно, стоит помнить и учитывать реальные последствия бездумного использования ИИ. Ссылка на вебинар и все сопутствующие документы - тут.
#кибербезопасность #ИТбез #разработка #AI #ChatGPT #чтотампроchatgpt
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7💯7
Как часто в разговорах с бизнесом, в технических заданиях, в брифах встречается фраза: "Сделайте так, чтобы было интуитивно понятно. Чтобы пользователь сам во всём разобрался". И вроде бы все прекрасно, если бы не одно НО - интуитивность, понятие субъективное ну или относительное.
То, что очевидно для дизайнера 25 лет может быть темной магией для пользователя 50+.
А то, что очевидно для бухгалтера в финансовой системе, может быть неочевидным для пользователя инсты. И ничего с этим не сделаешь, потому что оно НЕ конкретно, НЕ измеримо, НЕ имеет критериев успеха. А значит бесполезно.
Интуитивность - это не свойство интерфейса, а результат системной работы. Поэтому нужно:
🟢 Сформировать ключевые сценарии, которые должны быть пройдены без подсказок
🟢 Провести тесты на реальных пользователях
🟢 Проанализировать аналитику по существующим сценариям
🟢 Использовать существующие паттерны из лучших практик
И вместо "интуитивно понятно" в требованиях появляется:
✅ Пользователь должен уметь оформить заказ за ≤3 минут
✅ 90% пользователей должны пройти регистрацию без ошибок
✅ Интерфейс должен соответствовать рекомендациям Apple Human Interface Guidelines
✅ Конверсия на шаге Х - не ниже 80% после редизайна
Интуитивный интерфейс - это не набор компонент в Figma. Это гипотезы, которые нужно проверять. Если вы не хотите тестировать, значит вы не хотите знать правду о своём продукте. А если хотите - то начнете не с рисования кнопок, а с формулировки конкретных поведенческих целей. И вот тогда интерфейс действительно станет "интуитивным" - но не для дизайнера или продакта, а для реального пользователя.
#клиентскийопыт #CJM #CX #ритейл
То, что очевидно для дизайнера 25 лет может быть темной магией для пользователя 50+.
А то, что очевидно для бухгалтера в финансовой системе, может быть неочевидным для пользователя инсты. И ничего с этим не сделаешь, потому что оно НЕ конкретно, НЕ измеримо, НЕ имеет критериев успеха. А значит бесполезно.
Интуитивность - это не свойство интерфейса, а результат системной работы. Поэтому нужно:
И вместо "интуитивно понятно" в требованиях появляется:
Интуитивный интерфейс - это не набор компонент в Figma. Это гипотезы, которые нужно проверять. Если вы не хотите тестировать, значит вы не хотите знать правду о своём продукте. А если хотите - то начнете не с рисования кнопок, а с формулировки конкретных поведенческих целей. И вот тогда интерфейс действительно станет "интуитивным" - но не для дизайнера или продакта, а для реального пользователя.
#клиентскийопыт #CJM #CX #ритейл
Please open Telegram to view this post
VIEW IN TELEGRAM
👍11🔥6🤣2
Пару недель назад рассказывал про "ложные микросервисы" и антипаттерны в их проектировании. А сегодня давайте посмотрим на 10 важных моментов, которые должен знать о микросервисах каждый разработчик, когда заходит в микросервисную историю:
1️⃣ Начнем с API Gateway - главного маршрутизатора всего и вся. Он принимает запросы, решает, куда отправлять, имеете ли вы права на отправку и получение, отслеживает что происходит и меняет маршруты при необходимости. Если надо, API Gateway может агрегировать ответы от нескольких сервисов, кэшировать, писать логи и преобразовывать протоколы. В общем очень полезная штука
2️⃣ Service Discovery - динамический реестр всех сервисов. Основной компонент микросервисной архитектуры, обеспечивающий гибкое и эффективное динамическое взаимодействие между сервисами. Сервисы регистрируются в реестре, а реестр проверяет их работоспособность и обновляет статус сервисов
3️⃣ Circuit Breaker - выключатель цепи, который перенаправляет вызовы на другие экземпляры сервисов, при замедлении или остановке сервисов для сохранения стабильности системы, удовлетворенности клиентов и предотвращении каскадных сбоев
4️⃣ SAGA - паттерн для транзакций в архитектуре микросервисов для обеспечения согласованности данных. Каждый сервис управляет своей частью распределенной транзакции независимо, чтобы повышает гибкость и надежность системы
5️⃣ Loose coupling - низкая связанность - минимизация зависимостей с другими сервисами. Дает гибкость, увеличивает надежность и масштабируемость
6️⃣ High cohesion - высокая связность - отсутствие в микросервисе лишней функциональности. Сервис должен иметь четко определенную область применения и не выполнять неспецифические задачи. Дает возможность легче поддерживать и развивать код сервиса
7️⃣ Database per Service - у каждого сервиса своя база данных. Аналогично низкой связанности, только про хранение данных. Увеличивает безопасность микросервиса и данных, хранимых в нем и улучшает быстродействие
8️⃣ FaaS - Function As a Service - сочетание Serverless и Микросервисного подхода. Особенно хорош при построении Event Driven Architecture. Дает возможность переложить все управление инфрой на облачного провайдера
9️⃣ CQRS - Command Query Responsibility Segregation - разделение операций изменения и чтения данных на два независимых асинхронных потока. Улучшает производительность, масштабируемость и упрощает разработку
🔟 Sidecar pattern - вынесение доп.логики и вспомогательных функций в отдельный контейнер без изменения логики и кода основного сервиса. Хорошо применяется для логирования и прочих сервисных вещей
В заключение хочу сказать, что проектирование микросервисной архитектуры - дело сложное и 10 паттернами тут не обойтись. Есть еще огромное количество других паттернов, которые можно использовать вместе или вместо тех, что были описаны здесь. Описанное выше - это тот минимум, с которого можно отправляться в путешествие по миру микросервисов, чтобы не заблудиться и не разуверится в самой концепции.
#архитектура #development #разработка #платформы #впоискахсеребрянойпули #антипаттерны
В заключение хочу сказать, что проектирование микросервисной архитектуры - дело сложное и 10 паттернами тут не обойтись. Есть еще огромное количество других паттернов, которые можно использовать вместе или вместо тех, что были описаны здесь. Описанное выше - это тот минимум, с которого можно отправляться в путешествие по миру микросервисов, чтобы не заблудиться и не разуверится в самой концепции.
#архитектура #development #разработка #платформы #впоискахсеребрянойпули #антипаттерны
Please open Telegram to view this post
VIEW IN TELEGRAM
👍10🤔2
"Цифровизация - модная тема и все должны идти в цифру". Попалось мне недавно на глаза выступление Натальи Касперской на форуме ЦИПР 10 в июне этого года в Нижнем Новгороде. Особенно зашла та часть, где она рассуждает о цифровизации и ее ограничениях. Большинство сказанного совпадает с моими собственными мыслями на эту тему. Для тех, кому интересно - исходное видео по ссылке.
Итак, ограничения цифровизации:
1️⃣ Вся цифровизация построена на данных, данные подвержены рискам ИБ, риски ИБ нельзя закрыть на 100%, это невозможно. Уязвимость меряется по самому слабому звену, которым является цифровизация.
2️⃣ Оборудование и устройства все иностранного производства. Все наши данные принадлежат тому, кто произвел это устройство. Мы можем ставить любые защищенные приложения, но на платформенном уровне все данные могут быть перехвачены. Все может быть решено только полным импортозамещением, которое пока никто не знает, как сделать.
3️⃣ Электронным помощникам проще послать человека "на фиг". При полной цифровизации люди уже никуда пробиваться не смогут. А электронные помощники будут генерить классную статистику.
4️⃣ Цифровизация = электричество + интернет. Необходимые и достаточные условия. А у нас через некоторое время отключение интернета станет нормой. Если мы будем полагаться только на электронные системы, то мы рискуем оказаться безрукими слепыми и глухими котятами в момент отключения этих систем. Гигантский риск, который нельзя недооценивать.
5️⃣ ИИ - это здорово, это классно, это молодёжно, но надо понимать, что ИИ основанный на глубоких нейронных сетях это система, которая имеет ложноположительные и ложноотрицательные срабатывания. Это значит, что она "глючная" по определению. Ноль и ноль по ЛПС и ЛОС получить нельзя. Уменьшаешь одно, растет другое. Поэтому нельзя эту технологию внедрять в системы принятия ответственных решений.
6️⃣ Почему не говорят о том, что ИИ - это "черный ящик". Проблема "чёрного ящика" нейросетей заключается в сложности понимания того, как системы искусственного интеллекта обрабатывают данные и принимают решения.
Предложения:
📌 Когда мы что-то цифровизуем, мы должны иметь дубли документов на бумаге
📌 При создании любой системы цифровизации должны учитываться риски. Должны анализироваться модель угроз, возможные вектора атаки, внутренние уязвимости и должна быть составлена система защиты. Система цифровизация должна идти в комплекте с системой защиты
📌 Не надо возлагать излишних надежд на искусственный интеллект. Давайте он сначала выйдет на плато продуктивности (по кривой Гартнера).
Это взгляд человека, которые занимается новыми информационными технологиями, их использованием и защитой от них уже очень давно. Особенно приятно слышать это на крупном форуме, посвященном цифровой экономике России. Хайп пройдет и нам всем придется разгребать последствия.
#разработка #цифроваятранформация #agile #development #продуктоваяразработка
Итак, ограничения цифровизации:
Предложения:
Это взгляд человека, которые занимается новыми информационными технологиями, их использованием и защитой от них уже очень давно. Особенно приятно слышать это на крупном форуме, посвященном цифровой экономике России. Хайп пройдет и нам всем придется разгребать последствия.
#разработка #цифроваятранформация #agile #development #продуктоваяразработка
Please open Telegram to view this post
VIEW IN TELEGRAM
RUTUBE
Наталья Касперская о цифровизации.
Новости и обсуждения: https://t.me/aboutschools
Поддержать автора: https://t.me/tribute/app?startapp=d6Wf
Если видео понравилось - жмите на "ракету" (в топ!) - так его увидит большее число людей!
Поддержать автора: https://t.me/tribute/app?startapp=d6Wf
Если видео понравилось - жмите на "ракету" (в топ!) - так его увидит большее число людей!
💯7👍2❤1🤔1
Я считаю умение признавать свои ошибки одним из высших проявлений зрелости и силы. А умение признавать свои ошибки публично, делясь своим опытом, чтобы другие могли не совершать их - признаком лидерства.
В июне компания 12 Storees подверглась кибератаке. 16 июня, в заблокированной сети Инстаграмм компания выложила информацию о том, что они подверглись кибератаке, что цена вопроса был 20 млн руб, что они отказались платить, что утечки персональных данных не произошло и что компания продолжает акции распродажи.
Чуть больше, чем через месяц они выложили следующую историю, в которой они поделились не только информацией о том, как проходила атака и почему они делали или не делали что-то, но и теми выводами, которые они сделали из этой атаки и мерами, которые собираются предпринимать.
Выводы 12 STOREEZ:
🟢 Регулярное проведение учебных кибератак
🟢 Прохождение всеми сотрудниками тренингов по кибербезу
🟢 Регулярный внутренний и внешний аудит ИТ безопасности компании
🟢 Обязательное использование VPN
🟢 Обязательная двухфакторная аутентификация
🟢 Хранение минимум двух территориально распределенных копий данных
🟢 Наличие и регулярная проверка DRP
🟢 Не публиковать данные об атаке, пока не будет уверенности, что следующая атака будет отражена
Ну и рекомендации для сотрудников:
🔘 Сложные пароли
🔘 Регулярная смена паролей
🔘 Не хранить пароли в заметках
🔘 Не использовать рабочие компы для личных задач
🔘 Не хранить чувствительную рабочую инфу на личных устройствах
Вроде и то и другое - Азбука, но когда понимаешь, что за этим стоит, видишь потери компании, то начинаешь к этому относиться немного по-другому. Оставлю здесь ссылки, по которым можно найти эту информацию в телеграм-канале Алексея Лукацкого и еще раз посмотреть на это. Ссылка 1 и Ссылка 2. Читайте, думайте, делайте выводы. Реальный кибербез начинается с малого.
#кибербезопасность #ИТбез #разработка
В июне компания 12 Storees подверглась кибератаке. 16 июня, в заблокированной сети Инстаграмм компания выложила информацию о том, что они подверглись кибератаке, что цена вопроса был 20 млн руб, что они отказались платить, что утечки персональных данных не произошло и что компания продолжает акции распродажи.
Чуть больше, чем через месяц они выложили следующую историю, в которой они поделились не только информацией о том, как проходила атака и почему они делали или не делали что-то, но и теми выводами, которые они сделали из этой атаки и мерами, которые собираются предпринимать.
Выводы 12 STOREEZ:
Ну и рекомендации для сотрудников:
Вроде и то и другое - Азбука, но когда понимаешь, что за этим стоит, видишь потери компании, то начинаешь к этому относиться немного по-другому. Оставлю здесь ссылки, по которым можно найти эту информацию в телеграм-канале Алексея Лукацкого и еще раз посмотреть на это. Ссылка 1 и Ссылка 2. Читайте, думайте, делайте выводы. Реальный кибербез начинается с малого.
#кибербезопасность #ИТбез #разработка
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Пост Лукацкого
Месяц назад сеть магазинов 12Storeez столкнулась с инцидентом ИБ 🔓 и, как по мне, очень грамотно отработала его в публичном поле. На этом можно было бы и завершить эту историю, но производитель одежды решил пойти дальше и... фанфары, поделился результатами…
👍8😱2
К недавнему обсуждению в комментариях поста о выступлении Натальи Касперской по вопросам цифровизации. Обсуждался тезис - "цифровизация = электричество + интернет"
Из вчерашнего поста РИА-Новости:
Совпадение? Не думаю....🧐
#разработка #цифроваятранформация #agile #development #продуктоваяразработка
Из вчерашнего поста РИА-Новости:
КАЛУГА, 7 авг — РИА Новости. Минцифры и операторы связи подготовили техническую схему доступа россиян к массовым сервисам в условиях ограничения мобильного интернета, сообщил глава министерства Максут Шадаев на площадке форума "Цифровая эволюция".
"Минцифры совместно с операторами подготовило техническую схему доступа граждан к мобильному интернету в условиях ограничений. Когда происходит блокировка, по Captcha пользователи смогут получать доступ к белому списку основных сервисов на той же скорости, которая предусмотрена", — отметил он.
Совпадение? Не думаю....
#разработка #цифроваятранформация #agile #development #продуктоваяразработка
Please open Telegram to view this post
VIEW IN TELEGRAM
РИА Новости
Минцифры подготовило схему доступа к сервисам при отсутствии интернета
Минцифры и операторы связи подготовили техническую схему доступа россиян к массовым сервисам в условиях ограничения мобильного интернета, сообщил глава... РИА Новости, 07.08.2025
🤣8❤2
И снова про Эффективность команд. В прошлый раз мы рассматривали модель жизненного цикла команд Такмана, а сегодня рассмотрим модель, которая перекликается с предыдущей моделью - модель Дрекслера-Сиббета, которая выходит за рамки формирования команды и фокусируется на факторах, влияющих на эффективность на каждом этапе.
Когда кто-то говорит: "Команда не работает как единое целое", то зачастую это не про конкретных людей, а про то, что командная эффективность не была сформирована до конца. Модель Дрекслера-Сиббета дает возможность взглянуть на работу команды с точки зрения, где именно команда "буксует" - и как это исправить управленчески.
Модель эффективности команды Дрекслера-Сиббета или кривая эффективности команды или модель командной эффективности, была разработана Алланом Дрекслером и Дэвидом Сиббетом в 1970 году и далее неоднократно дорабатывалась. Забавен тот факт, что начало работ над эффективностью и выработка моделей вся датируется 70–80 годами 20 века.
Модель включает семь этапов: первые четыре направлены на формирование команды, а последние три фокусируются на её эффективности и устойчивости. Каждый этап дополняет предыдущий, помогая руководителям и командам определить своё текущее положение и потребности.
Этап 1 - Ориентация - Почему Я здесь? - Команда должна осознать и принять общую цель.
Ключ к успеху - Чёткое объяснение миссии, определение ожиданий, ролей и установление открытого диалога
Неуспех - дезориентация, страх, неопределенность
Этап 2 - Создание доверия - Кто мы такие? - Создание в команде совместного доверия, надежности, прямого и открытого диалога.
Ключ к успеху - открытое общение, активное слушание, обмен опытом, признание сильных сторон друг-друга
Неуспех - осторожность, недоверие, неэффективность
Этап 3 - Прояснение цели - Что мы делаем? - Формулирование конкретных целей, общего видения, критериев успеха.
Ключ к успеху - единое понимание приоритетов, SMART - цели
Неуспех - безынициативность, скептицизм, неуместная конкуренция.
Этап 4 - Приверженность - Как мы это делаем? - Формирование обязательств, четких принципов работы, плана достижения целей.
Ключ к успеху - процессы, сроки и результаты, взаимная ответственность, сотрудничество
Неуспех - зависимость и сопротивление
Этап 5 - Реализация - Кто, что, когда и где делает? - Команда реализует план, координируя задачи, управляя сроками и реагируя на возникающие проблемы.
Ключ к успеху - Делегирование, отслеживание прогресса, регулярная синхронизация, корректировка планов
Неуспех - конфликты, нарушения сроков, рассредоточенность
Этап 6 - Высокая производительность - Ух ты! - Команда работает на пике своей формы, доверяя друг другу и эффективно общаясь.
Ключ к успеху - конструктивное разрешение конфликтов, совместное лидерство и ответственность, партнерство
Неуспех - перегрузка, дисгармония
Этап 7 - Обновление - Зачем продолжать? - Команда оценивает достижения, рассматривает новые цели и направления
Ключ к успеху - ретроспектива побед и поражений, признание индивидуального и группового вклада, новые цели
Неуспех - усталость, скука, выгорание
Модель Дрекслера-Сиббета будет полезна при формировании, реструктуризации или масштабировании команд. Большинство ошибок происходят не на последних трех стадиях, а на первых четырех - на них закладывается фундамент работы команд. Если пропустить один из этапов или не отработать его "до успеха", то на следующих этапах команда может начать скрипеть и качаться.
#разработка #цифроваятранформация #agile #development #впоискахсеребрянойпули #мотивация
Когда кто-то говорит: "Команда не работает как единое целое", то зачастую это не про конкретных людей, а про то, что командная эффективность не была сформирована до конца. Модель Дрекслера-Сиббета дает возможность взглянуть на работу команды с точки зрения, где именно команда "буксует" - и как это исправить управленчески.
Модель эффективности команды Дрекслера-Сиббета или кривая эффективности команды или модель командной эффективности, была разработана Алланом Дрекслером и Дэвидом Сиббетом в 1970 году и далее неоднократно дорабатывалась. Забавен тот факт, что начало работ над эффективностью и выработка моделей вся датируется 70–80 годами 20 века.
Модель включает семь этапов: первые четыре направлены на формирование команды, а последние три фокусируются на её эффективности и устойчивости. Каждый этап дополняет предыдущий, помогая руководителям и командам определить своё текущее положение и потребности.
Этап 1 - Ориентация - Почему Я здесь? - Команда должна осознать и принять общую цель.
Ключ к успеху - Чёткое объяснение миссии, определение ожиданий, ролей и установление открытого диалога
Неуспех - дезориентация, страх, неопределенность
Этап 2 - Создание доверия - Кто мы такие? - Создание в команде совместного доверия, надежности, прямого и открытого диалога.
Ключ к успеху - открытое общение, активное слушание, обмен опытом, признание сильных сторон друг-друга
Неуспех - осторожность, недоверие, неэффективность
Этап 3 - Прояснение цели - Что мы делаем? - Формулирование конкретных целей, общего видения, критериев успеха.
Ключ к успеху - единое понимание приоритетов, SMART - цели
Неуспех - безынициативность, скептицизм, неуместная конкуренция.
Этап 4 - Приверженность - Как мы это делаем? - Формирование обязательств, четких принципов работы, плана достижения целей.
Ключ к успеху - процессы, сроки и результаты, взаимная ответственность, сотрудничество
Неуспех - зависимость и сопротивление
Этап 5 - Реализация - Кто, что, когда и где делает? - Команда реализует план, координируя задачи, управляя сроками и реагируя на возникающие проблемы.
Ключ к успеху - Делегирование, отслеживание прогресса, регулярная синхронизация, корректировка планов
Неуспех - конфликты, нарушения сроков, рассредоточенность
Этап 6 - Высокая производительность - Ух ты! - Команда работает на пике своей формы, доверяя друг другу и эффективно общаясь.
Ключ к успеху - конструктивное разрешение конфликтов, совместное лидерство и ответственность, партнерство
Неуспех - перегрузка, дисгармония
Этап 7 - Обновление - Зачем продолжать? - Команда оценивает достижения, рассматривает новые цели и направления
Ключ к успеху - ретроспектива побед и поражений, признание индивидуального и группового вклада, новые цели
Неуспех - усталость, скука, выгорание
Модель Дрекслера-Сиббета будет полезна при формировании, реструктуризации или масштабировании команд. Большинство ошибок происходят не на последних трех стадиях, а на первых четырех - на них закладывается фундамент работы команд. Если пропустить один из этапов или не отработать его "до успеха", то на следующих этапах команда может начать скрипеть и качаться.
#разработка #цифроваятранформация #agile #development #впоискахсеребрянойпули #мотивация
👍15👀2❤1
Вернусь опять к рынку труда на базе ежемесячного отчета Краткий обзор рынка труда за июнь 2025 от ХХ.
Основное:
🟣 hh индекс снизился на одну десятую и теперь составляет 5.5 (соотношение количества активных резюме к количеству активных вакансий)
🟣 Среднее число активных вакансий снизилось еще на 2% и составляло в июне 27% к уровню предыдущего года, а среднее число активных резюме составило 27%
🟣 Среднее число активных вакансий увеличилось на 4%, а резюме на 1% по сравнению с маем
По ритейлу и по ИТ, имеем:
📌 В ритейле сохраняется острый дефицит кадров ( hh индекс показывает 1.8)
📌 В ИТ дефицит вакансий немного уменьшился, но не значительно (hh индекс 12.5 против 12.8 в прошлом месяце)
📌 Число вакансий в ИТ уменьшилось на 31% по сравнению с маем прошлого года
📌 Число соискателей увеличилось на 28% за тот же период
📌 Число соискателей и число вакансий в ИТ практически не изменилось по сравнению с маем 2025 года. Вакансии увеличились на 1%, а соискатели уменьшились на тот же 1%.
Зона турбулентности не пройдена и непонятно, где и когда она закончится. Пока "идем по приборам". Многие компании на рынке начали серьезные преобразования своего ИТ ландшафта, меняя команды, подходы, открывая и закрывая проекты, что добавляет движа на рынке. По моим наблюдениям - аппетиты соискателей начали снижаться, становится более адекватными. Важно - серьезного спеца за три копейки не купить, но и космических требований уже не будет.
#подбор #разработка #development #управление #HR #development #рыноктруда #войтивит
Основное:
По ритейлу и по ИТ, имеем:
Зона турбулентности не пройдена и непонятно, где и когда она закончится. Пока "идем по приборам". Многие компании на рынке начали серьезные преобразования своего ИТ ландшафта, меняя команды, подходы, открывая и закрывая проекты, что добавляет движа на рынке. По моим наблюдениям - аппетиты соискателей начали снижаться, становится более адекватными. Важно - серьезного спеца за три копейки не купить, но и космических требований уже не будет.
#подбор #разработка #development #управление #HR #development #рыноктруда #войтивит
Please open Telegram to view this post
VIEW IN TELEGRAM
hh.ru
Обзоры рынка труда от hh.ru: коротко о важном
Рынок труда — зеркало того, что происходит на рынке в целом. Чтобы вы были всегда в курсе ситуации, мы наблюдаем за динамикой рынка труда и ежемесячно делимся актуальными отчётами.
👍14
И снова возвращусь к Запискам программиста.
День 503
Прилетело требование - "Сделайте так, чтобы всё можно было менять без программиста"
На вопрос "Все - это что?" получаю ответ - "Ну, чтобы и тексты, и цвета, и поля формы, и бизнес-логику"
Бизнес-логику, Карл! Менеджер собирается "перекинуть немного логику" между кнопками.
День 504
Начал делать админку. Хрен с ними с текстами и цветами, пусть развлекаются. Но попросили иметь возможность самому добавлять новые поля и кнопки в форму, чтобы запускать разные бизнес-процессы.
Валидацию тоже попросили сделать гибко - "Как в конструкторе"
Понял, что надо делать фреймворк для людей, которые не хотят учиться разрабатывать, но хотят все ломать.
День 505
Добавили в требования чтобы условия отображения кнопок можно было настраивать. Ну типа если возраст клиента больше 37, а геолокация - Новосиб, то показать кнопку - "Найти смысл жизни".
Написал DSL (Domain Specific Language).
Маркетолог Таня написала - if возраст > 37 and любовь is null и сайт упал
День 507
Запускали конструктор email-рассылок. Главбух собрал рассылку в которой 3 кнопки "Купить" и 1 "Отписаться от рассылки", которая почему-то ведёт на главную, а письмо весит 8 Мб.
В общем - когда все можно менять без программиста, все и сломать можно без программиста. Вначале продукт, потом админка к продукту, потом редактор логики, а потом бизнес пытается себя похоронить через drag and drop.
Нет ничего дороже фразы: "Давайте сделаем, чтобы оно просто работало… и без программиста"
#антипаттерны #управление #разработка #никогдатакогонебыло #шуткаюмора
День 503
Прилетело требование - "Сделайте так, чтобы всё можно было менять без программиста"
На вопрос "Все - это что?" получаю ответ - "Ну, чтобы и тексты, и цвета, и поля формы, и бизнес-логику"
Бизнес-логику, Карл! Менеджер собирается "перекинуть немного логику" между кнопками.
День 504
Начал делать админку. Хрен с ними с текстами и цветами, пусть развлекаются. Но попросили иметь возможность самому добавлять новые поля и кнопки в форму, чтобы запускать разные бизнес-процессы.
Валидацию тоже попросили сделать гибко - "Как в конструкторе"
Понял, что надо делать фреймворк для людей, которые не хотят учиться разрабатывать, но хотят все ломать.
День 505
Добавили в требования чтобы условия отображения кнопок можно было настраивать. Ну типа если возраст клиента больше 37, а геолокация - Новосиб, то показать кнопку - "Найти смысл жизни".
Написал DSL (Domain Specific Language).
Маркетолог Таня написала - if возраст > 37 and любовь is null и сайт упал
День 507
Запускали конструктор email-рассылок. Главбух собрал рассылку в которой 3 кнопки "Купить" и 1 "Отписаться от рассылки", которая почему-то ведёт на главную, а письмо весит 8 Мб.
В общем - когда все можно менять без программиста, все и сломать можно без программиста. Вначале продукт, потом админка к продукту, потом редактор логики, а потом бизнес пытается себя похоронить через drag and drop.
Нет ничего дороже фразы: "Давайте сделаем, чтобы оно просто работало… и без программиста"
#антипаттерны #управление #разработка #никогдатакогонебыло #шуткаюмора
👍16😁3
Недавно в комментариях упоминали такой вид систем, как Self Contained System (SCS). Зачастую их даже путают с микросервисами. Давайте повнимательнее посмотрим на этот класс систем и разберемся, зачем они нужны и где их применять.
SCS - это подход, при котором большая система делится на независимые, автономные модули, каждый из которых:
✔️ полностью отвечает за конкретную бизнес-функцию
✔️ имеет собственную UI, логику, базу данных
✔️ не зависит от других модулей во время выполнения
Каждая такая система может разрабатываться и разворачиваться самостоятельно, а зачастую даже разными командами.
На понятийном уровне - SCS может быть микросервисом (в плане предоставления API для функционирования других частей ИТ ландшафта), но микросервис в "чистом" виде не является SCS.
Из преимуществ SCS:
📌 Изоляция: каждый SCS работает максимально независимо. Проще разворачивать и обновлять
📌 Целостность: одна команда отвечает полностью за весь "колодец" - фронт, бэк, БД
📌 Простота: нет нужды в сложной оркестрации, как в микросервисах
SCS идеальный вариант для быстрого "раздевания" или "распиливания" монолитных систем - вырезать функции последовательно гораздо проще, чем сразу уложить это в правильные микросервисы. Особенно если это происходит в условиях ограниченных ресурсов и отсутствия опыта в построении микросервисной архитектуры.
Подход Self Сontained Systems не является заменой микросервисного подхода, скорее он органично дополняет его и предоставляет альтернативу, в случае нехватки времени или компетенций. Очевидно, что разделив огромный легаси монолит на SCS можно идти дальше и уже разваливать SCS на микросервисы. А можно и не идти, а построить масштабируемую, автономную архитектуру на SCS, сохранив при этом относительную простоту. Уж лучше несколько самодостаточных SCS систем, чем десятки плохо спроектированных микросервисов.
#архитектура #development #разработка #платформы #впоискахсеребрянойпули #антипаттерны
SCS - это подход, при котором большая система делится на независимые, автономные модули, каждый из которых:
Каждая такая система может разрабатываться и разворачиваться самостоятельно, а зачастую даже разными командами.
На понятийном уровне - SCS может быть микросервисом (в плане предоставления API для функционирования других частей ИТ ландшафта), но микросервис в "чистом" виде не является SCS.
Из преимуществ SCS:
SCS идеальный вариант для быстрого "раздевания" или "распиливания" монолитных систем - вырезать функции последовательно гораздо проще, чем сразу уложить это в правильные микросервисы. Особенно если это происходит в условиях ограниченных ресурсов и отсутствия опыта в построении микросервисной архитектуры.
Подход Self Сontained Systems не является заменой микросервисного подхода, скорее он органично дополняет его и предоставляет альтернативу, в случае нехватки времени или компетенций. Очевидно, что разделив огромный легаси монолит на SCS можно идти дальше и уже разваливать SCS на микросервисы. А можно и не идти, а построить масштабируемую, автономную архитектуру на SCS, сохранив при этом относительную простоту. Уж лучше несколько самодостаточных SCS систем, чем десятки плохо спроектированных микросервисов.
#архитектура #development #разработка #платформы #впоискахсеребрянойпули #антипаттерны
Please open Telegram to view this post
VIEW IN TELEGRAM
👍12🤔1
Немного мировых цифр по кибербезу на базе исследования компании DemandSage или то, что вас должно встревожить.
🟣 Ежедневно по всему миру происходит более 2200 кибератак
🟣 Число кибератак в мире выросло на 30% по сравнению с прошлым годом
🟣 1636 организаций еженедельно подвергаются кибератакам
🟣 Наибольшее количество атак приходится на образовательные организации и исследовательские центры: в неделю регистрируется 3341 инцидент
🟣 Больше всего атак на организации было зафиксировано в Африке - в среднем 2960 в неделю
🟣 Абсолютным лидером среди кибератак стали атаки шифровальщиков - 68% всех атак.
🟣 Лидером по числу атак с использованием шифровальщиков стал производственный сектор, на долю которого пришлось 29% инцидентов
🟣 Расходы на киберстрахование выросли на 28%.
Вроде выглядит неприятно, но мы же любим большие цифры. А если посмотреть по-другому - 2200 кибератак в день значит, что каждые 39 секунд в мире происходит одна атака. С этой стороны смотреть гораздо веселее.
По фишингу:
🔵 Фишинг отвечает примерно за 22 % всех утечек данных
🔵 Почти 83 % компаний сталкивались с фишинг-атаками
🔵 3,4 млрд фишинговых писем рассылается ежедневно — это 1,2 % от всех отправляемых ежедневно e-mail
🔵 90 % всех кибератак начинаются с фишинга
Повышается осведомленность о киберугрозах. А раз повышается осведомленность, то все идут защищаться. Инвестиции в кибербез растут. И к 2030 году объем мирового рынка кибербеза превысит 500 млрд вечнозеленых, хотя еще в 2022 году он не дотягивал до 300.
В общем киберугрозы в 2025 году стали масштабнее, агрессивнее и разнообразнее. Каждую минуту кого-то атакуют. Для нас это значит, что защита инфраструктуры, повышение киберграмотности и внедрение стратегий безопасности должны стать приоритетом для любой организации, вне зависимости от масштаба и отрасли.
#итбезопасность #кибербезопасность #ИТбез #разработка
Вроде выглядит неприятно, но мы же любим большие цифры. А если посмотреть по-другому - 2200 кибератак в день значит, что каждые 39 секунд в мире происходит одна атака. С этой стороны смотреть гораздо веселее.
По фишингу:
Повышается осведомленность о киберугрозах. А раз повышается осведомленность, то все идут защищаться. Инвестиции в кибербез растут. И к 2030 году объем мирового рынка кибербеза превысит 500 млрд вечнозеленых, хотя еще в 2022 году он не дотягивал до 300.
В общем киберугрозы в 2025 году стали масштабнее, агрессивнее и разнообразнее. Каждую минуту кого-то атакуют. Для нас это значит, что защита инфраструктуры, повышение киберграмотности и внедрение стратегий безопасности должны стать приоритетом для любой организации, вне зависимости от масштаба и отрасли.
#итбезопасность #кибербезопасность #ИТбез #разработка
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9😱2