🌟У меня появилась команда. Она не из людей

Провёл полную ревизию FitnessSDK и заново собрал вокруг проекта единый рабочий контур.

С помощью AI я:

— проверил текущее состояние продукта
— зафиксировал архитектуру и ограничения
— собрал пользовательскую и техническую документацию
— оформил всё в виде отдельного сайта с удобной навигацией по проекту

Это уже не просто набор заметок или docs “на всякий случай”. Это структурированная система, на которую теперь опирается дальнейшая разработка MVP 2.0.

Причём AI в моём процессе — это уже не “спросить что-то у чат-бота”.

На текущем этапе AI-агенты у меня:

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

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

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

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

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

Следующий этап — FitnessSDK MVP 2.0, уже в модели, где AI встроен в сам процесс разработки, а не подключается эпизодически.

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

⭐️ Залез в App Store Analytics по своему FitnessSDK — делюсь быстрым разбором

Гео:

— Европа — 48 (основной рынок)
— Азия — 11
— США/Канада — 9
— Остальные — почти ноль

По странам:

— Россия — 46 (почти весь объём)
— Япония — 9
— Остальные — единичные

Конверсия: 44.4%

Это, кстати, очень сильный показатель (выше среднего по рынку)

Но есть нюанс 👇
График почти весь в нуле, потом резкие скачки.

Что это значит:

— трафика пока мало
— нет стабильного потока
— данные ещё “сырые”

Вывод:
Продукт уже хорошо конвертит → значит можно масштабировать
Главная задача сейчас — дать больше трафика

🚀 Что дальше:

— усиливать Европу (уже есть сигнал)
— заходить плотнее в США
— разобраться, откуда идёт Россия

И да, хотел добавить 5-й язык — португальский…
но, похоже, следующая локализация будет японская 🇯🇵🐸 Эх...где мои испанцы 🥲

Интересно наблюдать, как из таких маленьких цифр постепенно собирается продукт

Скачать приложение из AppStore

✍️ Мини-наблюдение

Пару недель назад начал новую практику — читать книги, которые мне реально интересны, на английском.

Сейчас читаю The Anarchy (про Ост-Индскую компанию и Британскую Индию).

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

Но по факту всё было куда интереснее:

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

Фактически:

не армия создала империю, а бизнес, который постепенно стал властью.

Как я читаю сейчас
— сначала читаю на английском и пытаюсь уловить смысл
— не лезу сразу в перевод
— максимум 1–2 страницы за раз
— потом разбираю и обсуждаю прочитанное (иногда с ChatGPT)
— через несколько дней возвращаюсь и перечитываю

Не гонюсь за скоростью — важнее понять и “прожить” текст.

И вот мысль, которая меня не отпускает:

Как так получилось, что
маленькая торговая компания
смогла взять под контроль огромную страну, которая не покорялась многим великим правителям?

Там явно есть что-то глубже, чем просто “сила”. Читаем дальше Raja.

🌟Сегодня прошла закрытая встреча в Самаре про AI в разработке и продуктах.

Собрали небольшой круг — и получилось именно то, что хотелось: не лекция, а живая рабочая дискуссия с людьми, которые реально используют AI каждый день.

Обсудили много практики:
🔸как внедряется AI в продукты и процессы
🔸автоматизация через n8n и интеграции с внутренними системами
🔸генерация кода, тестов и аналитики
🔸как устроены AI-агенты и где они ломаются
🔸сколько реально стоит локальная модель и какое железо нужно

Отдельно было круто послушать про стартап, который сейчас в топ-100 мирового отбора и будет работать с Давидом Яном (ABBYY) — сильный кейс 👏

Спасибо всем, кто пришёл и поделился своим опытом.

🥂Полученные инсайты точно не останутся «в заметках» — буду применять их в своих пет-проектах и не только.

🥂 Пока дизайнеры спорят, Codex уже сделал весь UI

Дал ему контекст своего проекта (текущие экраны, паттерны взаимодействия, токены цветов) — и вместо абстрактных советов получил почти готовую дизайн-систему.

— предложил структуру компонентов
— расписал типографику (иерархию заголовков / текста)
— подобрал цвета под тёмную тему
— учёл текущие UX-паттерны (свайпы, архив, действия)
— и всё это — уже в логике моего кода
— Добавил полноценные экраны

🌟 Фактически, не просто “сгенерил UI”, а продолжил продукт так, как будто он часть команды.

Самое интересное — он не пытался "сделать красиво", а: сохранял консистентность, снижал визуальный шум, разделял опасные и безопасные действия. Это уже не про “AI рисует экран”, а про то как AI думает в рамках продукта.

😏 Кажется, дальше роль дизайна и разработки будет не “делать руками”, а:
— задавать правильные ограничения
— следить за целостностью системы

И всё. Остальное — ускоряется в разы.

⭐️ Вы не ускорите команду, пока терпите посредственность

С прошлого года я разбираю кейсы управления в топовых американских компаниях — Netflix, Amazon, Google — и хочу начать небольшой цикл постов про управление командами, людьми и уровнем исполнения.

📺 Одна из идей, которая часто встречается в разборе культуры Netflix, — Talent Density, или плотность таланта.

Если сильно упростить:

эффективность команды определяется не количеством людей, а средним уровнем людей в этой команде.

Звучит логично. Но на практике многие компании делают наоборот: пытаются компенсировать слабый уровень процессами, мотивацией, контролем и бесконечными синками.

📌 Один из ключевых инсайтов:

сильный специалист — это не +20% к результату.

В IT разница часто кратная.
Один сильный инженер:

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

Другой человек может:

— делать похожую задачу в разы дольше
— плодить техдолг
— постоянно требовать дополнительной проверки
— создавать больше работы для остальных

📌 И это не всегда про "старается / не старается". Чаще это просто разный уровень зрелости, опыта и мышления.

Но самое неприятное — не индивидуальная скорость. Главное — системный эффект.

📌 Человек, который не тянет уровень своей роли, не просто движется медленнее. Он начинает менять поведение всей команды.

Что происходит незаметно:

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

Это не резкое падение. Это медленная деградация уровня.

Дальше включается закономерный эффект:

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

И в какой-то момент команда вроде бы укомплектована, но:

— скорость падает
— качество проседает
— сложные задачи никто не хочет брать

Если упростить до одной мысли:
одна "средняя" позиция может заметно замедлить всю команду.

📌 Важно: это не про токсичное деление людей на "сильных" и "слабых". И не про то, что нужно увольнять всех, кто ошибается.

Это про честный управленческий вопрос:

человек усиливает команду на своей роли — или команда постоянно компенсирует его уровень?

И это тот фактор, который редко учитывают, когда говорят про мотивацию, процессы и менеджмент.

🌟Во второй части разберу, как Netflix работает с этим на практике. Там подход довольно жёсткий, но очень логичный.

Читать дальше ->
- [Двухфакторная теория Герцберга]
- [Кто такие brilliant jerks?]
- [Патрик Ленсиони: почему плохая коммуникация опаснее нехватки компетенций]
- [Cynefin Framework: как понять, что делать в любой ситуации]
- [North Star Metric — Метрика Полярной звезды]
- [Метрики в Kanban]
- [Итеративно-инкрементный подход: как делать продукт без "ставки на один релиз"]
- [Крепостное право и управление человеческими ресурсами]

☀️ Вчера в Самару из Республики Марий Эл приехал мой друг Саша — крутой человек, опытный KMP-разработчик и специалист, который глубоко разбирается во внедрении Claude в инфраструктурный слой IT-компаний.

❤️Недавно он согласился принять участие в настройке инфраструктуры для FitnessSDK — а это значит, что впереди будет много интересного.

🌱 Команда сформировалась, проект выходит на новый этап, и скоро я расскажу, что нового происходит внутри FitnessSDK.

⭐️ Как Netflix поддерживает высокий уровень команды
Часть 2.

В первой части я писал про Talent Density — идею о том, что эффективность команды зависит не от количества людей, а от среднего уровня команды. Но возникает логичный вопрос: как Netflix удерживает этот уровень на практике?

🔖 У них для этого есть несколько довольно жёстких принципов:

— нанимать только сильных людей
— платить выше рынка
— не держать “средний уровень” ради стабильности
— и регулярно задавать себе не комфортный вопрос: "Если этот человек завтра захочет уйти — буду ли я реально пытаться его удержать?"

🔖 Это называется Keeper Test.
Идея тут не в токсичности или "культе эффективности". Netflix смотрит на другое: человек усиливает систему — или система постоянно компенсирует его уровень?

🔖 Потому что слабое соответствие роли редко выглядит как катастрофа.
Чаще это выглядит так:

— кто-то постоянно перепроверяет работу
— кто-то доделывает детали
— кто-то разгребает последствия
— сильные люди тратят время не на развитие системы, а на её компенсацию

И именно это со временем убивает скорость команды.

При этом важный момент: это не про увольнение за ошибки. Junior может ошибаться.

🔖 Новый человек может долго входить в контекст. Даже сильный специалист может просесть.

Вопрос в другом:

— человек растёт?
— становится самостоятельнее?
— уменьшает нагрузку на команду?
— начинает усиливать систему?

Если да — это инвестиция.
Если нет — команда постепенно начинает тащить его на себе.

🔖И это уже управленческая проблема.
Есть ещё одна жёсткая, но очень сильная фраза у Netflix: “Adequate performance gets a generous severance.” То есть: “нормально” — не всегда достаточно для команды высокого уровня.

Звучит спорно, но в этом и заключается их идея Dream Team: лучше меньше людей, но сильнее.

⭐️ Thoughtworks Technology Radar: что происходит с AI и разработкой прямо сейчас.

Недавно вышел новый Thoughtworks Technology Radar — один из самых авторитетных отчетов в мире engineering, архитектуры и AI.

Если коротко:

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

Что особенно бросилось в глаза

📎 MCP становится новым стандартом для AI-агентов

Практически все движется в сторону:
🔸AI-агентов
🔸tool calling
🔸автономных workflow
🔸multi-agent systems

И MCP (Model Context Protocol) начинает становиться универсальным способом, через который AI взаимодействует с инструментами и системами.

📎 Разработка меняется сильнее, чем кажется

Thoughtworks прямо пишет про:
🔸команды AI-агентов
🔸spec-driven development
🔸AI-native engineering
🔸context engineering

То есть разработчик постепенно переходит:
от написания кода, к управлению контекстом, архитектурой и AI workflow.

📎 Некоторые AI-тренды уже начинают “хоронить”

Например:
🔸Text-to-SQL
🔸слепое доверие AI-коду
🔸naive API-to-MCP conversion

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

🌟Что лично мне показалось самым важным

Главный сдвиг сейчас происходит не в моделях.

А в том, как:
🔸организовываются AI workflow
🔸управляется контекст
🔸строятся agent systems
🔸создается инфраструктура под AI

Похоже, именно это и будет определять рынок ближайшие несколько лет.

🌟AI сейчас стоит копейки. Но через 3 года ты можешь пожалеть, что не начал строить свою систему раньше.

🔍 Самара
🗓 16.05.2026 14:00

В эту субботу в 14:00 проведём встречу про связку, которая может стать твоим личным интеллектуальным усилителем: AI + Obsidian + локальные модели.

🔖Обсудим, зачем уже сейчас создавать собственную базу знаний в Obsidian с помощью AI — не просто хранить заметки, а накапливать опыт, идеи, документы, инсайты и превращать всё это в систему, которая помогает думать, учиться и принимать решения быстрее.

🔖Также поговорим о более провокационной теме: почему AI-подписки сейчас стоят относительно дёшево — и почему через 2–3 года всё может измениться.

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

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

🔖Разберём, почему важно изучать локальные модели, как их устанавливать, какие инструменты для работы с ними существуют, в чём их плюсы, как мы используем локальные модели в своём проекте и как их можно дообучать под свои задачи.

🔖Одним словом, будем обсуждать, насколько мощной может быть комбинация AI + Obsidian, зачем нужна собственная база знаний и почему локальные модели могут стать не игрушкой для гиков, а способом сохранить независимость.

⏳Когда: суббота, 14:00
🍀Место: отправим после заявки через Google Form
Организатор: nasibov07 (пишите если будут вопросы)

Заполняй форму и приходи. Количество мест ограничено.

⭐️Я показал ребятам, как мы в FitnessSDK подняли локальный AI-сервер и собрали собственного агента на бесплатной модели.

Сегодня провели закрытую встречу, после которой у меня снова появилось ощущение: мы живём в моменте, где многие всё ещё обсуждают AI как «чатик для текстов», а кто-то уже тихо собирает вокруг себя новые производственные контуры.

🔖 Я показал ребятам, как мы в FitnessSDK подняли локальный AI-сервер и собрали собственного агента на бесплатной модели.

Не облако.
Не подписка.
Не магия за деньги.

А локальная система, которая работает у нас, на нашем компьютере, под наши задачи.

🔖 Идея была простая:

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

В итоге мы получили что-то вроде умной версии Яндекс Алисы, только без ограничений и полностью под нашим контролем.

🔖 Агент умеет:
— понимать человеческую речь;
— отвечать голосом;
— читать документы;
— анализировать материалы;
— разжёвывать суть прочитанного;
— готовить контекст, который дальше можно передавать в Codex.

🔖 Зачем это нужно?

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

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

По сути, мы начали собирать не просто AI-помощника, а внутренний инфраструктурный слой для разработки продукта.

🔖 Отдельно показал

как мы используем Obsidian + AI для проекта: как собираем базу знаний, как структурируем документацию, как делаем её удобной не только для человека, но и для AI-агентов.

И вот это, на мой взгляд, уже следующий уровень. Не просто «задать вопрос нейросети». А построить систему, где знания проекта не размазаны по чатам, заметкам и головам людей, а превращаются в рабочую среду, с которой могут взаимодействовать и команда, и AI.

🔖 Самое интересное, что всё это мы делали не ради красивой демонстрации.

Мы прощупывали реальные возможности:
можно ли дешево, локально и безопасно собрать помощника, который будет усиливать команду и разгружать дорогие AI-инструменты от лишней работы.

Ответ — да, можно.

🔖 И это только первая итерация.
У меня всё больше укрепляется ощущение, что в ближайшие годы преимущество будет не у тех, кто «пользуется нейросетями», а у тех, кто умеет встраивать AI в процессы, архитектуру, документацию и ежедневную разработку.

Потому что одно дело — открыть чат и что-то спросить. И совсем другое — построить вокруг проекта систему, которая начинает думать вместе с командой.

⭐️От группы людей к команде: 5 этапов по Такмену

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

Есть хорошая модель групповой динамики — модель Такмена. Она описывает, через какие этапы обычно проходит команда.

🔖 1. Forming — Формирование

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

На этом этапе много вопросов:
• «Что мы вообще делаем?»
• «Кто за что отвечает?»
• «Какие здесь правила игры?»

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

Задача лидера:

Дать ясность. Объяснить цели, правила, роли и ожидания.

🔖 2. Storming — Конфликт

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

Главная ошибка лидера на этом этапе — пытаться просто подавить конфликт.

Задача лидера:

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

🔖 3. Norming — Нормирование

После конфликтов команда начинает вырабатывать общие нормы. Появляется доверие. Роли становятся понятнее. Люди начинают лучше слышать друг друга. Обсуждения становятся менее эмоциональными и более продуктивными.

Вместо:
«Я знаю лучше»

появляется:
«Давайте решим это вместе».

Это момент, когда команда начинает становиться командой, а не просто набором отдельных специалистов.

Задача лидера:

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

🔖 4. Performing — Работа

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

Фокус смещается с отношений и внутренних споров на результат. Команда уже не спрашивает каждые пять минут, что делать. Она сама видит задачу и действует.

Задача лидера:

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

🔖 5. Adjourning — Завершение

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

Здесь важно не просто «разойтись», а подвести итоги.

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

Задача лидера:

Провести ретроспективу, поблагодарить людей и помочь им перейти к следующему этапу.

🌟Главная мысль модели Такмена:

Конфликт в команде — это не всегда признак слабости. Иногда это обязательный этап взросления команды.

Плох не сам конфликт.

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

⭐️ Командные роли Бенне и Шитса: почему в группе важны не только должности

В любой команде есть формальные роли: разработчик, дизайнер, тимлид, аналитик, менеджер.

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

Бенне и Шитс предложили смотреть на поведение людей в группе через три типа ролей.

🔖 1. Роли задачи
Это люди, которые помогают команде двигаться к результату.

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

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

🔖 2. Роли поддержки
Это люди, которые удерживают рабочую атмосферу.

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

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

🔖 3. Индивидуалистические роли
А вот здесь начинается самое интересное.

Это поведение, которое мешает общей работе: агрессия, блокирование идей, доминирование, поиск признания, уход от ответственности.

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

🔖Главная мысль простая:

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

Для TeamLead-а эта модель полезна тем, что помогает смотреть глубже должностей.

Не просто:
«У нас есть backend, mobile, QA и PM».

А иначе:

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

Иногда проблема команды не в процессах, не в Jira и не в созвонах.

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

🌟Engineering Club приглашает на Networking-встречу

В эту субботу собираемся в спокойной и дружеской атмосфере, чтобы познакомиться, пообщаться, обсудить IT, проекты, карьеру, технологии — и не только.

Это встреча без формального доклада и жесткой программы. Просто живое общение, новые знакомства, обмен опытом и возможность найти людей, с которыми интересно говорить на одном языке.

Приглашаем всех желающих: разработчиков, аналитиков, дизайнеров, тимлидов, продактов, начинающих специалистов и всех, кому интересна IT-среда.

🔮 Когда: в эту субботу, 14:00
📍 Где: Самара, кофейня «Мува»

По всем вопросам можно писать мне в личку: Насибов Ровшан

Engineering Club 🔸Networking

Сегодняшняя встреча получилась не просто networking, а полноценный инженерно-продуктовый разбор.

🟣Обсудили, как из идеи сделать SaaS-проект и пошагово довести его до продажи SDK-решения: от упаковки ценности и первых пользователей до мобилизации команды, ресурсов, архитектуры и выхода на рынок.

🟣Затем ушли в тему стартапа, связанного с картами. Поговорили о том, как работать с картами на iOS и Android, как устроены слои карты, какие бывают тайлы, откуда брать картографические данные и как вносить изменения так, чтобы это не превращалось в хаос.

🟣Самая инженерная часть встречи — производительность карт.

🟣Разобрали, как выгружать и отрисовывать на карте 5000+ точек и не уронить приложение. Почему такие задачи начинают тормозить интерфейс, где возникают узкие места и как это лечится: кластеризация, фильтрация по видимой области, батчинг, упрощение геометрии и грамотная работа с памятью.

🟣Отдельно обсудили алгоритм Рамера — Дугласа — Пекера: где он применяется, почему он так важен для карт и как помогает упрощать линии маршрутов без потери визуального смысла.

🟣Отдельно разобрали роли CTO, CPO, PO и PM: кто за что отвечает, где проходит граница между технологией, продуктом и бизнесом, и почему в зрелой структуре эти роли не заменяют друг друга, а усиливают.

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

В итоге встреча получилась про то, как соединяются бизнес, продукт, архитектура и низкоуровневая инженерия.

Именно такие разговоры и формируют сильную инженерную среду.

😎 Сегодня была тренировка с Ромой.

Но где-то на середине подхода я понял, что тренируюсь не с Ромой, а с Джоном Уиком на минималках.

Железо выжило. Мы — тоже. 💪

🌟Архитектура выбора.
Часть 1: Почему человек не может избежать выбора?

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

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

От философии Жан-Поля Сартра и Эриха Фромма до практики управления людьми, бизнесом и сложными системами — мы попробуем разобраться, как устроена архитектура выбора и почему именно решения во многом определяют нашу реальность.

〰️〰️〰️〰️〰️〰️〰️

⭐️Жан-Поль Сартр однажды сформулировал одну из самых сильных мыслей экзистенциализма:

«Человек обречён быть свободным».

💬 На первый взгляд звучит парадоксально. Как свобода может быть приговором? Обычно мы воспринимаем свободу как привилегию, как возможность делать то, что хочется. Но Сартр говорил о другом: человек не может не выбирать.

Мы всегда находимся в ситуации выбора. Даже тогда, когда нам кажется, что мы ничего не решаем.

Сказать «да», «нет», промолчать, не вмешаться, отложить решение, сделать вид, что тебя это не касается и так далее..все это выбор.

📎 Человек может пытаться спрятаться за обстоятельства, за чужие приказы, за фразу «так получилось» или «у меня не было выбора». Но в большинстве случаев сам отказ от выбора уже становится выбранной позицией.

🔖Бездействие не является пустотой. Оно тоже влияет на ситуацию.

Иногда молчание может быть мудростью.
Иногда — страхом.
Иногда — стратегией.
Иногда — согласием.

Но оно никогда не является ничем.

И здесь мысль Сартра становится особенно неудобной: человек отвечает не только за то, что он сделал, но и за то, чего он не сделал.

⭐️ Эту тему очень интересно дополняет Эрих Фромм в своей книге «Бегство от свободы».

🔖 Фромм говорит о том, что человек часто не выдерживает свободы. Потому что свобода — это не только возможность. Это ещё и груз. Свобода требует думать, выбирать, ошибаться, отвечать за последствия и признавать: «это было моё решение».

Именно поэтому многие люди стараются от свободы убежать.

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

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

Поэтому Сартр и Фромм не противоречат друг другу. Они говорят о двух сторонах одной и той же проблемы.

🔖Сартр говорит:
человек неизбежно свободен.
🔖Фромм говорит:
человек часто боится этой свободы и пытается от неё убежать.

Но итог остаётся тем же: выбора не избежать.

🔖Человек может отказаться признавать свою свободу, но он не может полностью от неё избавиться.

И, возможно, зрелость начинается именно там, где человек перестаёт говорить «так получилось» и начинает честно признавать:

«Я выбрал. И теперь я отвечаю за этот выбор».

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

Как наши решения влияют на других людей и почему скорость принятия решений иногда оказывается важнее их идеальности?

Об этом поговорим во второй части цикла «Архитектура выбора».

⭐️ Быть в нужном месте в нужное время - мало.
Недавно услышал интересную мысль.

Часто говорят: чтобы добиться успеха или выиграть свой «куш», нужно оказаться в нужное время и в нужном месте.

Но автор добавил важную деталь: мало просто оказаться там. Нужно быть готовым.

И вот это, на мой взгляд, отвечает на многие вопросы.

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

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

Но и этого недостаточно.

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

Поэтому успех — это не только «оказаться в нужном месте в нужное время».

💫 Это еще и быть человеком, который в этот момент способен понять: «Вот он, мой шанс».

И не испугаться его.