Forwarded from Lamoda Tech
На что влияют уровни зрелости компаний — с точки зрения продуктовых дизайн-команд 🌱
Руководитель команды продуктового дизайна и исследований Lamoda Костя Обухов выступил на UX/UI Conf. На основе опыта управления он поделился видением модели зрелости компаний и тем, как в них встраивается функция продуктового дизайна.
❗️ Модель отсылает к методологии производительности и зрелости CMMI. Она не является универсальной и не покрывает все типы компаний.
Однако исходя из опыта, описанные критерии критически влияют на найм, экспертизу, процессы и понимание роли дизайнера в командах.
➡️ Делимся разбором модели в карточках.
#La_interview
Руководитель команды продуктового дизайна и исследований Lamoda Костя Обухов выступил на UX/UI Conf. На основе опыта управления он поделился видением модели зрелости компаний и тем, как в них встраивается функция продуктового дизайна.
Однако исходя из опыта, описанные критерии критически влияют на найм, экспертизу, процессы и понимание роли дизайнера в командах.
#La_interview
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍5🔥4❤1
если ты безработный или почти, а хочешь крутую работу, то хочу порекомендовать пообщаться с Димой (это другой Дима)
работа хорошая и место знатное!
Привет!
Я Дмитрий, Tech Product трайба платформы компании mindbox.
Ищу Senior Platform Engineer.
🎯 Основная цель:
Создание инфраструктурных сервисов как продуктов для разработки, движение к IDP (Internal Developer Platform).
📊 О нас:
- 50 миллионов транзакций в день, 400+ миллионов профилей в базах, десятки миллиардов фактов, несколько тысяч подключенных касс, с доступностью 24/7.
- 9 стоек своего железа, два цода, быстро растем по 1-2 стойке в год.
- 40 000+ ядер в Yandex.Cloud, входим в TOP10 клиентов.
🛠️ Стек::
- Kubernetes в Yandex.Cloud , а также на своем железе на Deckhouse с поддержкой от Flant
- Terraform + Ansible + Packer (переходим на Crossplane)
- с GitHub мигрируем на GitLab
- Gitlab + OctopusDeploy + Helmfile
- Prometheus + VictoriaMetrics + Grafana + AlertManager + GrafanaOnCall
- MS SQL мигрируем на PostgreSQL
- Kafka, Cassandra, Clickhouse, Redis, RabbitMQ, Mongo
- Graylog (1Tb логов в день) + Sentry + Loki
- Виртуализация HyperV (мигрируем на Proxmox)
- Other: Teleport,skupper,vault,ChaosMesh & etc
Если тебе интересна эта вакансия, то го к нам на собес :)
Мой контакт в Telegram: @impel1o
─────────────────────
P.S. Плюшки:
🎓 Well-being программы: 350 000 ₽ в год на образование, медицину, спорт и путешествия
🏡 Удаленка (но есть и отличные офисы в Москве и Ереване)
💻 Техника: MacBook, мониторы, наушники и другое
🏢 Работа в аккредитованной IT-компании
🎉 Корпоративная жизнь: тимбилдинги, квесты, спортивные мероприятия
работа хорошая и место знатное!
Привет!
Я Дмитрий, Tech Product трайба платформы компании mindbox.
Ищу Senior Platform Engineer.
🎯 Основная цель:
Создание инфраструктурных сервисов как продуктов для разработки, движение к IDP (Internal Developer Platform).
📊 О нас:
- 50 миллионов транзакций в день, 400+ миллионов профилей в базах, десятки миллиардов фактов, несколько тысяч подключенных касс, с доступностью 24/7.
- 9 стоек своего железа, два цода, быстро растем по 1-2 стойке в год.
- 40 000+ ядер в Yandex.Cloud, входим в TOP10 клиентов.
🛠️ Стек::
- Kubernetes в Yandex.Cloud , а также на своем железе на Deckhouse с поддержкой от Flant
- Terraform + Ansible + Packer (переходим на Crossplane)
- с GitHub мигрируем на GitLab
- Gitlab + OctopusDeploy + Helmfile
- Prometheus + VictoriaMetrics + Grafana + AlertManager + GrafanaOnCall
- MS SQL мигрируем на PostgreSQL
- Kafka, Cassandra, Clickhouse, Redis, RabbitMQ, Mongo
- Graylog (1Tb логов в день) + Sentry + Loki
- Виртуализация HyperV (мигрируем на Proxmox)
- Other: Teleport,skupper,vault,ChaosMesh & etc
Если тебе интересна эта вакансия, то го к нам на собес :)
Мой контакт в Telegram: @impel1o
─────────────────────
P.S. Плюшки:
🎓 Well-being программы: 350 000 ₽ в год на образование, медицину, спорт и путешествия
🏡 Удаленка (но есть и отличные офисы в Москве и Ереване)
💻 Техника: MacBook, мониторы, наушники и другое
🏢 Работа в аккредитованной IT-компании
🎉 Корпоративная жизнь: тимбилдинги, квесты, спортивные мероприятия
усложнять простое
часто стал встречать что простые вещи люди делают сложными просто потому что "я так всегда делаю и мне привычно"
с одной стороны — KISS (keep it simple, stupid) и нужно всё делать максимально просто. берешь ты воркфлоу или бизнес-процесс — не усложняй, начни с базовых простых блоков "начало" и "конец", соедини их максимально прямо, чтобы приходить к результату.
пример: задача может быть в бэклоге (статус "открыта"), когда до нее доходит исполнитель — переходит в статус "в работе", а по итогу — в статус "готово".
может быть, для прозрачности, стоит добавить что задача "зависла" (ожидает автора или какой-то другой задачи) или "готова к приемке" (если у вас приемка не прописана в DoD и требует участия заказчика)
когда я вижу воркфлоу из ветвей в 10 статусов в каждой ветке и автоматизацией на пять кнопок — мне становится плохо и я хочу посмотреть в глаза тем оптимизаторам, что это городят.
однако, с другой стороны — у каждой усложненной процедуры есть история. зачастую она базируется на использовании одного инструмента разными командами.
такие случаи можно решать через общие правила, либо разделение тех самых флоу по командам/проектам.
это касается не только задач и их флоу в трекерах, это может касаться любой сферы.
усложнение нужно только тогда, когда оно действительно дает большУю (и бОльшую) прозрачность и одновременно ускоряет работу. в других случаях — мы стремимся все формализовать, тем самым ставя себе ловушки по пути.
и еще одно: если вас надо всегда вести за руку — просто уходите из инженерии, займитесь другими делами, вам будет сильно легче.
часто стал встречать что простые вещи люди делают сложными просто потому что "я так всегда делаю и мне привычно"
с одной стороны — KISS (keep it simple, stupid) и нужно всё делать максимально просто. берешь ты воркфлоу или бизнес-процесс — не усложняй, начни с базовых простых блоков "начало" и "конец", соедини их максимально прямо, чтобы приходить к результату.
пример: задача может быть в бэклоге (статус "открыта"), когда до нее доходит исполнитель — переходит в статус "в работе", а по итогу — в статус "готово".
может быть, для прозрачности, стоит добавить что задача "зависла" (ожидает автора или какой-то другой задачи) или "готова к приемке" (если у вас приемка не прописана в DoD и требует участия заказчика)
когда я вижу воркфлоу из ветвей в 10 статусов в каждой ветке и автоматизацией на пять кнопок — мне становится плохо и я хочу посмотреть в глаза тем оптимизаторам, что это городят.
однако, с другой стороны — у каждой усложненной процедуры есть история. зачастую она базируется на использовании одного инструмента разными командами.
такие случаи можно решать через общие правила, либо разделение тех самых флоу по командам/проектам.
это касается не только задач и их флоу в трекерах, это может касаться любой сферы.
усложнение нужно только тогда, когда оно действительно дает большУю (и бОльшую) прозрачность и одновременно ускоряет работу. в других случаях — мы стремимся все формализовать, тем самым ставя себе ловушки по пути.
и еще одно: если вас надо всегда вести за руку — просто уходите из инженерии, займитесь другими делами, вам будет сильно легче.
💯6
Forwarded from Аня в IT среде обитания
Уровни корпоративных культур
Недавно Настя и Света начали цепочку размышлений на тему влияния корпоративных культур на карьерный рост сотрудников. Так получилось, что последнее мое выступление было как раз про стереотипы в IT. Я разделила их на несколько “эпох”, которые прожила вместе с индустрией. Помимо стереотипов они также хорошо отражают и различные состояния корпоративных культур.
↗️ Сквозь эти эпохи трансформируются:
⁃ степень экологичности/токсичности (и что таковым является);
⁃ умение слышать и принимать других;
⁃ границы коробки, в которую обычно складывают айтишников.
Мое проживание этих эпох началось лет 15-20 назад, потому что бонусом к работе в IT я еще учитываю среду, в которой училась. И мне казалось, что эти этапы проживаю с индустрией не только я, а вообще все, кто в ней работает.
👌 Да, но нет…
Сейчас на почве профессиональных ивентов много общаюсь с людьми из совершенно разных компаний. Они отличаются по размеру и локации, зрелости процессов и технологий, зрелости культуры. И знаете, кем я себя чувствую?
🚘 Путешественником во времени.
Потому что эпохи, которые проживают команды, могут отличаться не только от компании к компании, но и от команды к команде в рамках одной компании. И если ты для кого-то “гость из будущего”, то приходится откатываться мышлением назад, чтобы понять проблемы, о которых тебе говорят. А когда сам встречаешь гостя из будущего, то хочется дорасти до того уровня. Тут люди либо меняют команду/компанию, либо становятся проводником внешнего опыта внутрь.
‼️ И до меня дошло…
Все эти эпохи сейчас сосуществуют в единой временной сингулярности :)
Есть прекрасная книга “Лидер и племя”, которая описывает 5 уровней корпоративной культуры (перевод может разниться):
1. Отчаянная враждебность
2. Безразличная жертва
3. Одинокий воин
4. Гордость за племя
5. Искреннее удивление (жизнь прекрасна)
Она построена вокруг многолетнего исследования, которое доказало, что чем выше уровень корпоративной культуры, тем эффективнее работают сотрудники. Но при этом в рамках каждого уровня доминируют и добиваются “успехов” вполне конкретные типажи людей.
Тут мне вспомнился прошлогодний доклад про “Степени зрелости команд и как по ним идти”. В нем я переложила идеи книги конкретно на IT команды. Он был на закрытую аудиторию и у меня еще не было канала, поэтому на скриншоте к посту один из ключевых слайдов. Кажется, пора его переупаковать и рассказать где-то в паблике…
Кто хочет продолжить цепочку постов — подхватывайте и возвращайтесь в комментарии 😉
С какими уровнями вы сами сталкивались?
Недавно Настя и Света начали цепочку размышлений на тему влияния корпоративных культур на карьерный рост сотрудников. Так получилось, что последнее мое выступление было как раз про стереотипы в IT. Я разделила их на несколько “эпох”, которые прожила вместе с индустрией. Помимо стереотипов они также хорошо отражают и различные состояния корпоративных культур.
⁃ степень экологичности/токсичности (и что таковым является);
⁃ умение слышать и принимать других;
⁃ границы коробки, в которую обычно складывают айтишников.
Мое проживание этих эпох началось лет 15-20 назад, потому что бонусом к работе в IT я еще учитываю среду, в которой училась. И мне казалось, что эти этапы проживаю с индустрией не только я, а вообще все, кто в ней работает.
Сейчас на почве профессиональных ивентов много общаюсь с людьми из совершенно разных компаний. Они отличаются по размеру и локации, зрелости процессов и технологий, зрелости культуры. И знаете, кем я себя чувствую?
Потому что эпохи, которые проживают команды, могут отличаться не только от компании к компании, но и от команды к команде в рамках одной компании. И если ты для кого-то “гость из будущего”, то приходится откатываться мышлением назад, чтобы понять проблемы, о которых тебе говорят. А когда сам встречаешь гостя из будущего, то хочется дорасти до того уровня. Тут люди либо меняют команду/компанию, либо становятся проводником внешнего опыта внутрь.
Все эти эпохи сейчас сосуществуют в единой временной сингулярности :)
Есть прекрасная книга “Лидер и племя”, которая описывает 5 уровней корпоративной культуры (перевод может разниться):
1. Отчаянная враждебность
2. Безразличная жертва
3. Одинокий воин
4. Гордость за племя
5. Искреннее удивление (жизнь прекрасна)
Она построена вокруг многолетнего исследования, которое доказало, что чем выше уровень корпоративной культуры, тем эффективнее работают сотрудники. Но при этом в рамках каждого уровня доминируют и добиваются “успехов” вполне конкретные типажи людей.
Тут мне вспомнился прошлогодний доклад про “Степени зрелости команд и как по ним идти”. В нем я переложила идеи книги конкретно на IT команды. Он был на закрытую аудиторию и у меня еще не было канала, поэтому на скриншоте к посту один из ключевых слайдов. Кажется, пора его переупаковать и рассказать где-то в паблике…
Кто хочет продолжить цепочку постов — подхватывайте и возвращайтесь в комментарии 😉
С какими уровнями вы сами сталкивались?
Please open Telegram to view this post
VIEW IN TELEGRAM
👍2
процессы
как часто камнем преткновения в работе становятся плохие процессы? да почти постоянно
а почему? думаю, что процессная деятельность — это сложная штука, где нужен баланс между "в регламенте не описано" и "я делаю как хочу, ваши бумажки себе оставьте"
хотя, это больше похоже на саботаж и хитрый всегда найдет как срезать углы
а если посмотреть со стороны преимуществ: хорошие процессы — это не бюрократия и формализация, а упрощение и, порой, автоматизация пройденного пути. то есть это ускорение и исключение ошибок на понятных участках пути
из приколов — мало кто в принципе любит делать процессы, все хотят чтобы это сделал кто-то большой и умный, а исполнителю дела до процесса нет
мой подход всегда подразумевает что создание процесса — это инициатива руководителя, а вот отладка, улучшение и ускорение — работа всегда командная. каждый участник процесса может (и должен) внести в процесс улучшение
снова вспомню "если ты берешься за что-то — оставь это в лучшем виде, чем когда ты начал" — так и получается что-то хорошее. просто не сразу, а итерационно. по спирали, по спринтам, по пирамиде или как — не важно
а я процессы люблю и люблю их ставить, улучшать и даже упразднять. приходишь такой на работу и понимаешь — тут нужен процесс
как часто камнем преткновения в работе становятся плохие процессы? да почти постоянно
а почему? думаю, что процессная деятельность — это сложная штука, где нужен баланс между "в регламенте не описано" и "я делаю как хочу, ваши бумажки себе оставьте"
хотя, это больше похоже на саботаж и хитрый всегда найдет как срезать углы
а если посмотреть со стороны преимуществ: хорошие процессы — это не бюрократия и формализация, а упрощение и, порой, автоматизация пройденного пути. то есть это ускорение и исключение ошибок на понятных участках пути
из приколов — мало кто в принципе любит делать процессы, все хотят чтобы это сделал кто-то большой и умный, а исполнителю дела до процесса нет
мой подход всегда подразумевает что создание процесса — это инициатива руководителя, а вот отладка, улучшение и ускорение — работа всегда командная. каждый участник процесса может (и должен) внести в процесс улучшение
снова вспомню "если ты берешься за что-то — оставь это в лучшем виде, чем когда ты начал" — так и получается что-то хорошее. просто не сразу, а итерационно. по спирали, по спринтам, по пирамиде или как — не важно
а я процессы люблю и люблю их ставить, улучшать и даже упразднять. приходишь такой на работу и понимаешь — тут нужен процесс
👍10❤4
«Стачка» — крупнейшая региональная IT-конференция России. 18-19 апреля она пройдет в Ульяновске (УлГПУ).
→ 4 направления: «Разработка», «Digital-маркетинг», «Управление», «Дизайн и Контент»;
→ 250+ докладов от лучших спикеров IT-индустрии . Я буду на «Стачке» выступать в секции «СЕКЦИЯ»
Мой доклад «ДОКЛАД»Что затронем?
ПРОПИСАТЬ КЛЮЧЕВЫЕ ВОПРОСЫ И ТЕЗИСЫ
Регистрация участников и подача докладов уже открыты на сайте: https://ul25.nastachku.ru
Специальный промокод на скидку 15%: СПИКЕР15
НетВоркинг — все на Стачку!🔥
мой доклад ищите в секции devops!
→ 4 направления: «Разработка», «Digital-маркетинг», «Управление», «Дизайн и Контент»;
→ 250+ докладов от лучших спикеров IT-индустрии . Я буду на «Стачке» выступать в секции «СЕКЦИЯ»
Мой доклад «ДОКЛАД»Что затронем?
ПРОПИСАТЬ КЛЮЧЕВЫЕ ВОПРОСЫ И ТЕЗИСЫ
Регистрация участников и подача докладов уже открыты на сайте: https://ul25.nastachku.ru
Специальный промокод на скидку 15%: СПИКЕР15
НетВоркинг — все на Стачку!🔥
мой доклад ищите в секции devops!
👍4🔥3❤🔥2
спешим!
не люблю спешку. понимаю, иногда надо сделать здесь и сейчас, чтобы залатать дыру. но спешка нужна при ловле блох.
если хочешь построить что-то долговечное — это нужно делать пусть и не долго, но не в спешке.
случаи, когда бег с препятствиями приводил к хорошим результатам я могу вспомнить с трудом, но и ситуаций «сначала ТЗ допишем» и с затягиванием сроков знаю бесчисленное множество.
поэтому, я предпочитаю итерационный подход, где в каждую итерацию создается инкремент, документация, либо проводится исследование. и он работает.
а блох ловить в техподдержке можно и водопадом, и канбаном
не люблю спешку. понимаю, иногда надо сделать здесь и сейчас, чтобы залатать дыру. но спешка нужна при ловле блох.
если хочешь построить что-то долговечное — это нужно делать пусть и не долго, но не в спешке.
случаи, когда бег с препятствиями приводил к хорошим результатам я могу вспомнить с трудом, но и ситуаций «сначала ТЗ допишем» и с затягиванием сроков знаю бесчисленное множество.
поэтому, я предпочитаю итерационный подход, где в каждую итерацию создается инкремент, документация, либо проводится исследование. и он работает.
а блох ловить в техподдержке можно и водопадом, и канбаном
blameless
ах ты гад! из-за тебя у нас постоянно проблемы!
еще бы команда инженеров перестала косячить и было бы славно!
это снова заговор сетевиков.
эти и другие приколы обвинений не должны быть приемлемы в девопс
а почему? почему нельзя сказать "Иннокентий, ты накосячил!"?
всё просто, потому что Кеша в ответ начнет только защищаться и демотивироваться.
сравните: "Кеш, по проблеме, что случилась — давай сделаем её своей точкой роста и приложим усилия, чтобы она не повторилась?"
в том числе, этот подход работает для процессов, компании, самой рабочей рутине и всего чего угодно.
нет смысла просто винить, есть смысл разобраться и сделать лучше.
главное — проецировать то, куда хочется прийти и стараться туда идти.
очень часто blameless применяется к управлению инцидентами и проблемами. потому что когда случилась беда — всегда хочется найти кто виноват, а не что делать. потому что тот кто виноват и думать будет что делать.
даже если в инциденте виноват кто-то кто вынул вилку из розетки — это не повод его обвинять, это повод сделать чтобы такое не повторилось.
все равно что обвинять ребенка в его плохом поведении, хотя у него не то что умысла не было, у него не было желания сделать вообще что-то, кроме того, что сделано.
ищите руткоз, а не виноватого и обретете счастие!
и да, Макс, чего забросил канал?) твой прод совсем пожрал долгоносик?
ах ты гад! из-за тебя у нас постоянно проблемы!
еще бы команда инженеров перестала косячить и было бы славно!
это снова заговор сетевиков.
эти и другие приколы обвинений не должны быть приемлемы в девопс
а почему? почему нельзя сказать "Иннокентий, ты накосячил!"?
всё просто, потому что Кеша в ответ начнет только защищаться и демотивироваться.
сравните: "Кеш, по проблеме, что случилась — давай сделаем её своей точкой роста и приложим усилия, чтобы она не повторилась?"
в том числе, этот подход работает для процессов, компании, самой рабочей рутине и всего чего угодно.
нет смысла просто винить, есть смысл разобраться и сделать лучше.
главное — проецировать то, куда хочется прийти и стараться туда идти.
очень часто blameless применяется к управлению инцидентами и проблемами. потому что когда случилась беда — всегда хочется найти кто виноват, а не что делать. потому что тот кто виноват и думать будет что делать.
даже если в инциденте виноват кто-то кто вынул вилку из розетки — это не повод его обвинять, это повод сделать чтобы такое не повторилось.
все равно что обвинять ребенка в его плохом поведении, хотя у него не то что умысла не было, у него не было желания сделать вообще что-то, кроме того, что сделано.
ищите руткоз, а не виноватого и обретете счастие!
и да, Макс, чего забросил канал?) твой прод совсем пожрал долгоносик?
канал сыча
«Стачка» — крупнейшая региональная IT-конференция России. 18-19 апреля она пройдет в Ульяновске (УлГПУ). → 4 направления: «Разработка», «Digital-маркетинг», «Управление», «Дизайн и Контент»; → 250+ докладов от лучших спикеров IT-индустрии . Я буду на «Стачке»…
сычане! чтобы мне не было скучно и страшно на стачке — разыгрываю билет среди подписчиков)
что нужно сделать? рассказать в комментарии что-то клевое по теме канала и получить билет. дальше — ехать 18-19 апреля в Ульяновск и слушать докладики. поехали?
что нужно сделать? рассказать в комментарии что-то клевое по теме канала и получить билет. дальше — ехать 18-19 апреля в Ульяновск и слушать докладики. поехали?
Forwarded from Lamoda Tech
Как мы делили QA-стенд и получили платформу
Когда у вас несколько сотен сервисов, которые нужно тестировать, а занимает это дни или недели, вы понимаете боль фразы «выкатить хотфикс сейчас же». И наверняка думаете, как лучше тестировать, чтобы не крутить сервис по каждой фиче.
Как мы действовали в такой ситуации, расскажет Антон Егорушков, Head of DevOps Lamoda Tech на конференции «Стачка» в Ульяновске.
Он поделится, как в процессе мы пришли к созданию своей IDP, почему не прыгнули в готовые решения, и что важнее: CI/CD или релиз-менеджер?
➡️ Будете на «Стачке» — залетайте на доклад к Антону:
📅 19 апреля, 13:10-13:40
📍 Зал: 313. Архитектура и DevOps
#LaTech_speakers
Когда у вас несколько сотен сервисов, которые нужно тестировать, а занимает это дни или недели, вы понимаете боль фразы «выкатить хотфикс сейчас же». И наверняка думаете, как лучше тестировать, чтобы не крутить сервис по каждой фиче.
Как мы действовали в такой ситуации, расскажет Антон Егорушков, Head of DevOps Lamoda Tech на конференции «Стачка» в Ульяновске.
Он поделится, как в процессе мы пришли к созданию своей IDP, почему не прыгнули в готовые решения, и что важнее: CI/CD или релиз-менеджер?
#LaTech_speakers
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥11
Егорушков_Разработка_devops.pdf
4.6 MB
начинаю свой доклад на Стачке 2025, вот презентация, чтобы лучше рассмотреть что происходит, а так же задать вопросы и дать обратную связь
👍8
не обошлось без приколов: в последнюю минуту пиар сказал убрать кое-что из слайдов.
казалось бы: простое действие. но в аудитории комп без интернета.
позвали техников. но они не идут. спикеры в общем чате дают советы из разряда «скачай и кайфуй»
первый шаг: скачать свежую версию. ага, вайфай можно раздать, но вайфая у компа нет.
заливаю в облако и получаю шорт линк. но куда его вводить?
понимаю что у интерактивной панели в аудитории есть вайфай. даю с телефона точку доступа и качаю на панель файл. но трансляция идет с компа, да и проектор показывает то, что на компе.
ищу человека с флешкой (usb там есть), чтобы скачать и скопировать. но нет) 2025 год, флешек нет ни у кого.
благо Саша пришел на помощь и предложил поискать. я пошел в соседнюю аудиторию — мне там отказали даже на минуту дать флешку, типа самим нужна (вот она, взаимопомощь)
и тут Саша звонит и говорит что флешка есть. мы копируем. в последнюю минуту. сразу после этого появляются техники с флешкой, но уже не надо)
доклад прошел средне: я чуть даванул на технику, а народ ожидал чего-то попроще. но мне самому понравилось
казалось бы: простое действие. но в аудитории комп без интернета.
позвали техников. но они не идут. спикеры в общем чате дают советы из разряда «скачай и кайфуй»
первый шаг: скачать свежую версию. ага, вайфай можно раздать, но вайфая у компа нет.
заливаю в облако и получаю шорт линк. но куда его вводить?
понимаю что у интерактивной панели в аудитории есть вайфай. даю с телефона точку доступа и качаю на панель файл. но трансляция идет с компа, да и проектор показывает то, что на компе.
ищу человека с флешкой (usb там есть), чтобы скачать и скопировать. но нет) 2025 год, флешек нет ни у кого.
благо Саша пришел на помощь и предложил поискать. я пошел в соседнюю аудиторию — мне там отказали даже на минуту дать флешку, типа самим нужна (вот она, взаимопомощь)
и тут Саша звонит и говорит что флешка есть. мы копируем. в последнюю минуту. сразу после этого появляются техники с флешкой, но уже не надо)
доклад прошел средне: я чуть даванул на технику, а народ ожидал чего-то попроще. но мне самому понравилось
🔥9👍2😁2
испытательный срок
на днях у меня завершился (успешно) испытательный срок в lamoda🤪
и по этому поводу я хочу сказать что это был больше испытательный для компании, а не для меня.
редко когда задумываются что ИС дан двум сторонам: одной (компании) понять что найм не ошибся и сотрудник вписался, а другой (сотруднику) — чтобы оценить соответствие работодателя и команды своим хотелкам и соображениям.
да, я ещё во время ИС привел в компанию многих, не будучи уверенным что все ок в компании, но я был уверен в себе и своей команде. это глупо и самонадеянно.
если подбить итоги: я пересобрал команду, некоторые ребята ушли, не знаю, повлиял ли я на них или то, что накопилось ранее. нанял около десяти ребят и создал четыре крутых команды внутри. мы описали дорожную карту и обозначили цели. я описал наши принципы и ценности. но я все ещё не уверен, что моя команда на 100% разделяет их и готова биться по моим правилам с наследием.
в любом случае, мне стало сильно интереснее работать, чем это было в феврале. я вижу не просто свет в конце тоннеля, но путь, который надо пройти и знаю что мы его пройдем. будет интересно.
и да, у меня до сих пор бомбит от заборов между командами и пофигизма многих на те слои окаменелого дерьма, что лежат вокруг.
на днях у меня завершился (успешно) испытательный срок в lamoda
и по этому поводу я хочу сказать что это был больше испытательный для компании, а не для меня.
редко когда задумываются что ИС дан двум сторонам: одной (компании) понять что найм не ошибся и сотрудник вписался, а другой (сотруднику) — чтобы оценить соответствие работодателя и команды своим хотелкам и соображениям.
да, я ещё во время ИС привел в компанию многих, не будучи уверенным что все ок в компании, но я был уверен в себе и своей команде. это глупо и самонадеянно.
если подбить итоги: я пересобрал команду, некоторые ребята ушли, не знаю, повлиял ли я на них или то, что накопилось ранее. нанял около десяти ребят и создал четыре крутых команды внутри. мы описали дорожную карту и обозначили цели. я описал наши принципы и ценности. но я все ещё не уверен, что моя команда на 100% разделяет их и готова биться по моим правилам с наследием.
в любом случае, мне стало сильно интереснее работать, чем это было в феврале. я вижу не просто свет в конце тоннеля, но путь, который надо пройти и знаю что мы его пройдем. будет интересно.
и да, у меня до сих пор бомбит от заборов между командами и пофигизма многих на те слои окаменелого дерьма, что лежат вокруг.
Please open Telegram to view this post
VIEW IN TELEGRAM
👍27❤20
Forwarded from Байки из Глеба
Быть правым и полезным
Честно говоря, фраза «А я же говорил» почти всегда кажется мне непродуктивной — особенно если её говорят уже после того, как всё пошло не так, и при этом не предлагают никаких решений. Чаще всего за ней скрываются проблемы с коммуникацией, управлением рисками и общей культурой принятия решений.
Но всё же, уместность таких слов зависит от ситуации. Чтобы понять, насколько она вообще уместна, полезно задать себе несколько вопросов:
- В компании вообще принята зрелая культура работы с рисками и несогласием (в духе Disagree & Commit)?
- Старался ли человек реально донести свою точку зрения, а не просто пробросить реплику?
- Была ли его позиция как-то зафиксирована — письменно, в обсуждении, на совещании?
- Фраза звучит как поддержка или как «я был прав, а вы — нет»?
Если на хотя бы один из этих вопросов ответ «нет», то, скорее всего, «А я же говорил» только мешает. Лучше искать, что можно сделать, а не кто оказался прав.
Честно говоря, фраза «А я же говорил» почти всегда кажется мне непродуктивной — особенно если её говорят уже после того, как всё пошло не так, и при этом не предлагают никаких решений. Чаще всего за ней скрываются проблемы с коммуникацией, управлением рисками и общей культурой принятия решений.
Но всё же, уместность таких слов зависит от ситуации. Чтобы понять, насколько она вообще уместна, полезно задать себе несколько вопросов:
- В компании вообще принята зрелая культура работы с рисками и несогласием (в духе Disagree & Commit)?
- Старался ли человек реально донести свою точку зрения, а не просто пробросить реплику?
- Была ли его позиция как-то зафиксирована — письменно, в обсуждении, на совещании?
- Фраза звучит как поддержка или как «я был прав, а вы — нет»?
Если на хотя бы один из этих вопросов ответ «нет», то, скорее всего, «А я же говорил» только мешает. Лучше искать, что можно сделать, а не кто оказался прав.