Музыкант и композитор Moby выложил 500 своих треков в свободный доступ — их можно бесплатно использовать в кино, рекламе, играх и ремиксах без лицензий и авторских отчислений. По словам самого музыканта, он просто хочет увидеть, что из этого сделают креативные люди. В ближайшее время Moby опубликует ещё около 1000 треков.
Карьерная игра на понижение
Слышу в последнее время довольно часто истории из бигтехов про понижение в должности: неэффективного (или ненужного) менеджера не убирают совсем, а ставят сверху на его роль нового человека. Или просто уменьшают скоуп обязанностей, забирают часть менеджерского функционала (а то и сразу весь), превращая управленца в исполнителя.
Зачем так делают? Давайте разбираться:
— Это является альтернативной увольнению: сотрудник сидит давно, особо не перформит, но и не отсвечивает, какой‑то кусок работы худо‑бедно выполняет, повышений не просит, а коллеги к нему привыкли. Пусть работает дальше, но в условной песочнице, чтобы не переплачивать и снизить риски в части ответственности.
— Это прокси‑флаг расставания и кусок теневого соцпакета: мы разгружаем тебя, но не освобождаем от обязанностей, ищи работу неспеша, в комфортном режиме. Это тонкий момент: сотруднику создают дискомфорт для эго, но комфортный ландшафт для подготовки себя к выходу. При этом только совсем уж слепой не считает такое сообщение работодателя.
Обычно коммуникация со стороны работодателя строится завуалированно, но основная мысль понятна: на выход или в подвал. И в свете разгонов о том как же стало трудно в айтишке найти работу, такие товарищи нередко соглашаются на шконку, скажем так, не у окошка.
Для сотрудника понижение в должности часто выглядит как более безопасная альтернатива увольнению:
Сырок продолжает совершать ежедневное путешествие из кухни в животик, прочие плюшки тоже на месте.
Нет стресса поиска новой работы, кэшфлоу хоть и уменьшается, но не прерывается.
Стаж идёт, рекрутер на новом месте будет доволен.
В остальном сплошные недостатки:
Про рост можно забыть, чаще всего новая позиция для специалиста — стагнационная.
Тебя сломали: плевать в общем-то на уважение коллег, в корпорации уважение это вообще довольно специфическая категория, а вот уважение к себе, эго точно страдают.
Вера в корпоративную стабильность пошатнулась: сегодня отпили кусок, а завтра могу и совсем всего лишить. А как теперь этим управлять? Начать перформить? Нет, поздно пить Боржоми, на новой позиции тебя никто не услышит.
А бывает ещё, когда "дело не в тебе" и это чистая правда
Бигтехи гонятся за эффективностью убирая лишние менеджерские прослойки. В ходе такой процедуры миддл-менеджмент может перейти в IC, а c-level при этом неизбежно сократится количественно.
Это выглядит как груминг дерева оргструктуры. Например, Amazon, Google и Microsoft используют такой подход: плохие менеджеры на выход, хороших разжаловать в исполнители, уменьшить отношение менеджеров к исполнителям в разработке (через сокращения и перелив).
Что выбирать — личное дело каждого. Но сама возможность такого выбора — это скорее привилегия, чем унижение.
Недавно прочитал, что идеальная Agile-команда -- как повара в кафе: подберут ингредиенты, приготовят блюдо персонально для клиента. Самое вкусное для конкретного гостя.
Представляете такую команду в реальном ресторане?
Приходите на бизнес-ланч, -- меню нет, но есть на все готовая, молодая, незашоренная процессами команда. Кто-то из них вообще администратор зала, но решил попробовать себя в новой роли.
И вот вы начинаете говорить, что хотели бы: соляночку на первое, чтобы по всем правилам; ну и, раз сами спросили, на второе -- стейк и картофель с розмарином и соусом. Вроде бы не бюджет бизнес-ланча, но команда записывает, активно обсуждают, подсказывают. Кто-то уже побежал готовить -- круто!
1. Приносят первую порцию, небольшую и жидкую - MVP пока что. На тарелку решили не тратиться, ведь главное не в упаковке. Пей, значит, из ладошки!
2. Высказываете замечания:
-- Вроде как картошку то стоило поварить..
-- На анчоусы (откуда?!) у вас аллергия,
-- Посуду бы конечно добавить.
Команда соглашается, но посуду решили добавить только в 3 спринт -- ресурсов не хватало и между идеей убрать анчоусы (да зачем вообще?!) и добавить посуду выбираете здоровье в ущерб брезгливости.
3. ...
4. ...
5. Итерации к 5 это уже будет солянка. В тарелке для супа. В чистой. Жаль только не доварили (спринта не хватило, затянули с нарезкой мяса). А как удалось объяснить, что 5 видов разного мяса в одном блюде и одинаково готового (тут промашка, обещали исправить) -- это не баг, а фича, -- это ваш, как заказчика, отдельный повод для гордости.
Но за 5 попыток наверно уже и наелся.
И ведь все как ты хотел! Что недоволен то?!
P.S. Agile — отличный подход. Но никакая методология не заменит здравого смысла и процесса, внутренней культуры. И ни одна методология не может применяться без изменений в любой сфере.
Панацеи нет, придется додумывать!
7 правил как промоутить сотрудников
В IT у программистов есть грейды. Это примерно то же самое, что разряды у слесарей. Линейка обычно такая: Junior, Middle, Senior, Team Lead. У нас она немного другая, но суть та же. Промоушен (с англ. “повышение”) — это переход на более высокий грейд. Моя компания использует грейды больше 5 лет, поэтому я решил написать 7 основных правил процесса повышения грейда.
1. Инициатива 🙋♂️
Сотрудник должен сам писать отчет и проводить самопрезентацию на новый грейд. Да, именно он должен доказывать, что достоин повышения — по своей инициативе. Синдром самозванца? Остается навечно на старом грейде.
2. Основная работа 🔩
Отчет сотрудника должен основываться на основных рабочих рутинных задачах, а не на дополнительных факультативных увлекательных проектах. Например, выбрать 3–5 показательных завершенных задач-достижений в рамках должностных обязанностей и рассказать о них.
3. Матрицы компетенций 🛤❌
Это не зло, но и далеко не основа грейдов, как считает большинство. Это набор подсказок о том, какими хардами (hard skills — техническими навыками) можно похвастаться при написании отчета.
4. Ценность 🏁
Хвастаться хардами можно, но важно объяснить их пользу для бизнеса. Если сотрудник не может объяснить бизнес-терминами, зачем он прикрутил еще один линтер — пусть не пишет об этом в отчете. Да и вообще, пусть убирает этот линтер нафиг. Каждая задача-достижение должна приносить простую и понятную пользу для бизнеса; иначе это вредное баловство за чей-то счет.
Кстати недавно я публиковал пост с 5 основными шагами Илона Маска для достижения целей. Там была ценная мысль: «Часто умные инженеры оптимизируют вещи, которые вообще не должны существовать». Поэтому мой самый частый вопрос на совещаниях: «Чтобы что?».
5. Зоны ответственности 🤝
Кроме хард-скиллов и ценности для бизнеса важно упомянуть выполнение обязанностей и закрытие зон ответственности. Вспомните должностные инструкции сотрудника или описание вакансии на его должность. Например, сотрудник может помогать в найме и обучении новичков. Или заниматься анализом требований к задачам и давать обратную связь, если данные противоречивы — тем самым экономя время всей команды. Закрытие зон ответственности следует учитывать при выборе задач-достижений для отчета.
6. Помощь 🛟
Сотруднику могут помогать его линейный руководитель и ментор. Они должны заранее дать шаблон отчета, вместе выбирать задачи для отчета на регулярных встречах. В идеале сотрудник должен писать отчет постоянно, пока работает у вас, а не в последний момент.
7. Непредвзятость ⚖️
Выработайте объективный механизм принятия решений “да/нет” по промоушену. Если “нет”, то “нет”. Пересдача. Закройте глаза и забудьте, что перед вами знакомый человек. Перед вами безымянный винтик — и вы тоже винтик. Если вы требуете профессионализма от сотрудников — проявляйте его сами.
Мы сейчас проводим ревизию нашей системы грейдов и, вероятно, это не последний пост на эту тему. Подпишитесь на меня здесь или в телеге.
МойОфис Экосистема: мы собрали офисные инструменты в единую рабочую среду
Представьте, как несколько сотрудников работают над одним документом — бюджетом или годовым отчётом, — но вместо слаженного процесса получается хаос: каждый редактирует свою копию, пересылает её по почте, и в итоге никто не может понять, какая версия последняя. На сводку правок уходит время, высок риск ошибок, а рассылка файлов создаёт угрозу утечки данных.
МойОфис решил эту проблему, создав единую экосистему приложений со сквозными сценариями. Вы можете начать работу в настольном редакторе, продолжить совместное редактирование в веб-версии, а затем внести правки с мобильного устройства — и всё это с одним файлом. Документ остаётся единым на всех этапах без дублирования версий. Можно отправить его прямо в корпоративный чат мессенджера Squadus от МойОфис или прикрепить к письму в нашей почте из интерфейса редактора, без скачивания и повторной загрузки.
Все обсуждения проходят в чате документа, а изменения автоматически сохраняются в облаке, исключая ручные операции вроде «сохрани-перешли-открой-где-то-еще». Доступ настраивается только для нужных сотрудников, а процесс согласования занимает считанные минуты.
Мы разделили наши продукты на 4 семейства и изменили их названия. Теперь это настольные документы («Документы Настольные»), чат и видеозвонки («Сквадус»), веб-документы («Документы Онлайн») и почта для организаций («МойОфис Почта» и «Мейлион»). Для упрощения навигации мы также обновили и названия приложений. Теперь текстовый редактор называется «МойТекст», табличный редактор — «МоиТаблицы» и так далее. Это позволяет легко идентифицировать все компоненты экосистемы по единому стилю наименований.
Читайте подробнее об Экосистеме МойОфис здесь.
Подписывать контейнеры с помощью GPG важно, потому что это гарантирует, что образ действительно создан вами или вашей командой и не был изменён после сборки. GPG — это проверенный инструмент, который уже давно используется для шифрования и подписи данных. Он не зависит от сторонних решений и является частью свободного ПО, поэтому ему можно доверять.
Когда вы подписываете контейнер, вы подтверждаете его целостность. Если кто-то заменит образ на поддельный с вредоносным кодом, подпись позволит это обнаружить. Без подписи вы рискуете запустить что-то небезопасное, даже не зная об этом.
Конечно, есть и другие инструменты, например cosign, которые тоже полезны, особенно в облачных средах. Но GPG остаётся надёжным базовым решением, которое работает везде и не требует дополнительной настройки. Проще говоря, это как печать на документе: если её нет, вы не можете быть уверены, что всё чисто.
Как это делать с помощью container-tools
container-tools % make
Usage: make <target>
help - Display this help message
all - Build all Debian images
check-dependencies - Verify required tools are installed
clean - Remove all build artifacts and downloads
list-vars - List all Makefile variables and their origins
shellcheck - Validate all bash scripts
package - Create tar.gz archive of the directory
release - Create Git tag and GitHub release
archive - Create git archive of HEAD
bundle - Create git bundle of repository
============================
** Debian Linux targets **
============================
|all|
|debian11|
|debian11-java|
|debian11-java-slim|
|debian11-corretto|
|debian11-graal|
|debian11-graal-slim|
|debian11-java-slim-maven|
|debian11-java-slim-gradle|
|debian11-graal-slim-maven|
|debian11-graal-slim-gradle|
|debian11-java-kafka|
|debian11-java-slim-kafka|
|debian11-nodejs-23.11.0|
|debian11-python-3.9.18|
Собираем базовый образ для NodeJS
make debian11-nodejs-23.11.0
После завершения сборки:
[Image was built successfully]
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Artifact location: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar
Artifact size: 93M
Для подписи используем gpg.py в составе container-tools:
./scripts/gpg.py --directory /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar --gpg-key-id 4795A07D0372203EFDDA0BF0C465AD00090932DB
2025-04-25 13:39:41,269 [INFO] Signing tarball: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar -> Signature: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar.asc
2025-04-25 13:39:41,752 [INFO] Successfully signed tarball: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar
2025-04-25 13:39:41,752 [INFO] Signature saved to: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar.asc
2025-04-25 13:39:41,752 [INFO] All tarballs have been processed successfully.
Подтверждаем:
./scripts/gpg.py --directory /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar --gpg-key-id 4795A07D0372203EFDDA0BF0C465AD00090932DB --verify
2025-04-25 13:40:19,734 [INFO] Verifying tarball: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar against signature: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar.asc
2025-04-25 13:40:20,192 [INFO] Verification successful: /srv/container-tools/debian/dist/debian11-nodejs-23.11.0/debian11-nodejs-23.11.0.tar
2025-04-25 13:40:20,193 [INFO] All tarballs have beeМожет ли Бэтмен взять отпуск
Сегодня я расскажу вам о нашем небольшом, но очень ценном управленческом инструменте — мы называем его «техлид продукта». Если вы как-то связаны с созданием цифровых продуктов и заинтересованы в том, чтобы они хорошо работали, вам наверняка пригодится этот подход. Он особенно актуален, когда человеческие ресурсы по каким-то причинам ограничены.
Большинство инженеров любят быть героями. Я — люблю. Представьте себе хайлоад-продукт: куча пользователей, запросов, деньги летят миллионами. Система сложная, размазанная по разным серверам, а, пожалуй, даже по разным дата-центрам. В общем, всё мчится и бибикает. Но вдруг где-то откручивается гайка, труба отпадает, из неё бьёт пар. Экраны мониторов в командной рубке заливаются красным, женский голос повторяет: «Тревога! Прод лежит». Картина маслом.
Вы видите, насколько все серьезно и, не раздумывая, вступаете в неравную схватку с проблемой. Вскоре вы разносите полгорода, находите и перерезаете красный провод. Мир спасен в самую последнюю секунду. Все женщины ваши, мужчины хотят быть как вы. Для вас это чувство — наркотик, и, как любой другой наркотик, он может разрушить вашу управленческую жизнь. Почему?
Потому что вы становитесь не-за-ме-нимы. Представьте себе ситуацию в Готэм-сити, когда Бэтмен уехал в отпуск посерфить на Шри Ланке.
Незаменимых быть не должно. Для решения этой проблемы мы во Флаге придумали дополнительную роль, которая позволяет надевать костюм Бэтмена любому разработчику, начиная с грейда мидл. Мы присвоили этой роли список обязанностей, определили премии, закрепили во внутренних системах.
Обязанности роли «техлид продукта»:
1️⃣ Ответственность за работоспособность продакшена и стейджинга (боевой контур и финальный контур тестирования). Причем, именно работоспособность: создаёт и изменяет эти контуры другая роль.
2️⃣ Управление процессом устранения аварий: координация как внутренних, так и внешних специалистов, информирование заинтересованных лиц о статусе устранения аварии.
3️⃣ Ответственность за анализ аварий: ведение Post Mortem (отчётов об авариях), разбор аварий с командой, постановка организационных и технических задач для предотвращения аварий по итогам анализа.
4️⃣ Ответственность за ключевые технические решения на проекте: библиотеки и фреймворки, архитектура и подходы к разработке.
5️⃣ Ответственность за актуальность документации по разворачиванию сервисов локально у разработчиков.
6️⃣ Ответственность за создание и поддержку тестовых контуров.
7️⃣ Ответственность за актуальность документации по контрактам взаимодействия модулей системы.
🎱 Контроль технического долга на продукте.
9️⃣ Ответственность за информационную безопасность продукта: принятие решений по уровню доступа к системе для участников команды и третьих лиц, актуальность версий ПО и другое.
Для Флага всё это уже давно не теория, а рутина где-то с лета 2023 года. Роль техлида «склеивает» множество узких специализаций, таких как DevOps, Backend, Frontend, Mobile, PM и SA. Сейчас я спокоен, потому что знаю: аварии устраняются быстро, выводы делаются, наши продукты и процессы становятся надёжнее с каждым факапом. Да, факапы всё равно происходят, никуда от них не денешься. Зато узнаю я об этом из отчётов, а не из ночных смс и звонков.
В середине XX века социолог Никлас Луман разработал метод организации информации Цеттелькастен (Zettelkasten). Он создавал множество заметок и, чтобы не терять знания, начал вести картотеку. Система нумерации и ссылок помогала ориентироваться в карточках. У каждой заметки был уникальный номер, отражающий тему и дополнения.
Спустя полвека идеи Лумана остаются актуальными. Более того, появились программные обеспечения для ведения базы знаний. Заметки сохраняются в облаке и отображаются в виде графа.
Веб-разработчик в YADRO Дмитрий сохраняет заметки в сервисе Obsidian. Дмитрий услышал о ПО от инженера и блогера Николая Тузова и понял, что система, похожая на картотеку, ему близка.
Программа оказалась понятной, легко адаптируемой под разные задачи. Когда Дмитрий перенес данные из Notion в Obsidian, образовалось несколько графов: по Go, хешированию и базам данных. В этой базе знаний все концепции в Go пересеклись в двух точках — интерфейсе и горутинах. Есть еще слайсы, но в основном все «лучи» сходятся именно в эти две точки.
Как Дмитрию удалось упорядочить большие объемы знаний и кому он рекомендует Цеттелькастен, читайте в статье →
«Первая Форма» представила новую админпанель для быстрой low-code настройки
В новой версии low-code BPM-системы «Первая Форма» представлена обновленная административная панель для настройки процессов. Её главное преимущество — редактор, который даёт администраторам системы возможность создавать автоматизации без глубоких технических знаний и привлечения IT-специалистов. Решение помогает быстрее настраивать и оптимизировать процессы.
В редакторе автоматизаций появилось три новых инструмента для работы с запросами:
Визуализация плана запроса. Эта функция отображает процесс сбора данных из баз и позволяет определить этапы SQL-запроса, которые влияют на производительность. Инструмент помогает администратору понять, как работает его запрос, найти причину долгого выполнения и оптимизировать его.
Встроенное версионирование скриптов с функцией отката. Если изменения привели к ошибке, администратор может вернуть предыдущую сохранённую версию без потери данных.
Интеллектуальная система подсказок (IntelliSense). Эта функция помогает быстрее написать запрос к базе данных без указания названий таблиц или полей. Администратор может написать название процесса или параметра, а система сама заполнит нужные значения.
«Обновлённый редактор “Первой Формы” решает ключевые технические задачи при настройке BPM-системы. IntelliSense для создания автоматизаций, инструменты анализа производительности SQL-запросов и система версионирования формируют комплексное решение, которое сокращает технический барьер между бизнес-требованиями и их реализацией».
Евгения Бушуева, руководитель проекта по тестированию нового интерфейса администрирования «Первой Формы»
Другие функции новой версии можно изучить в материале на сайте.
Секрет успеха и продуктивности раскрыт. Оказалось, нужно просто не откладывать неприятные дела, а сделать сразу, но плохо.
Профильный эксперт всю свою жизнь изучал работу успешных людей и нашёл простой парадокс: плохой результат лучше, чем никакой. Перфекционизм мешает вам завершать задачи и двигаться вперёд — в итоге желание сделать идеально только мешает.
Не можете начать проект — создайте папку, документ и впишите заголовок. Не идёт уборка — спрячьте только самое мусорное. Если сидеть и ждать вдохновения, то дела просто завалят вас снежным комом.
Делать хуже — не значит быть ленивым. Это избавляет от тревожности и даёт больше времени на восстановление.
Запоминаем: вы не ленивый, вы просто пытаетесь быть успешным.
Сравнение электронных таблиц Р7 и MS Excel
Я думаю, что то что P7 - это OnlyOffice для которого не удосужились даже поменять скин, ни для кого не является секретом.
Проблема в том, что OnlyOffice использует лицензию AGPLv3 – которая разрешает использование и распространение исходного кода, но запрещает продажу коммерческих продуктов на основе кодовой базы OnlyOffice.
Тот факт, что некоторые западные компании в одностороннем порядке разорвали контракты с российскими клиентами после 2022 года, не означает, что можно нарушать лицензионное право.
Есть крупные западные корпорации, которые занимаются редистрибуцией не своего программного обеспечения. Например Oracle может взять кодовую базу Ansible AWX и распространять его как Oracle Automation в составе подписки Oracle Linux. Отличие в том что:
Ansible AWX использует лицензию Apache 2.0
У Oracle есть R&D который выпускает в open-source свои разработки А в данном случае берется кодовая база целиком и перепродается как российские продукт. Это прежде всего не очень хорошие инвестиции в будущее.
Эффект Пигмалиона (Розенталя)
Раньше (до того как машины стали стоить как квартира) замечал несколько раз - вот выберешь себе новую машину и вдруг в городе их оказывается уже очень много. Вот едет и вот еще. И потом начинаешь замечать, что их реально много стало вокруг.
На самом деле, их конечно же не стало больше, просто мы их стали замечать.
Такое наше поведение является проявлением эффекта Пигмалиона (Розенталя) и является одним из когнитивных искажений (ошибок мышления - обожаю эту тему, вот и сюда ввернул).
Эффект Пигмалиона - ожидания человека определяют его действия.
Психологи Роберт Розенталь и Ленора Якобсон провели эксперимент: в начале учебного года они выделили учеников из разных классов начальной школы, которые по результатам теста оказались более талантливыми и обладали более высоким IQ, чем их одноклассники. На самом деле никаких выдающихся способностей у них обнаружено не было и ученики были выбраны случайно, однако учителям сообщили обратное. Повторное тестирование в конце года показало, что результаты «одарённых» учеников в среднем улучшились, а показатель IQ увеличился.
Дело в том, что наш мозг с трудом отличает восприятие и ожидание. Социолог Роберт Мёртон описал самосбывающиеся пророчества, к которым относится эффект Пигмалиона, как самогипноз. Имея изначально убеждение о себе или других, мы влияем на действительность и делаем так, что оно становится правдой. Этот психологический феномен позволяет целенаправленно или случайно влиять на реальность.
А что автомобиль?
Решив купить новый автомобиль мы перестроили внутренние фильтры восприятия информации и начали по другому видеть ситуацию - буквально выхватывать из автомобильного потока ту самую марку.
Отсюда есть 2 интересных следствия:
1. Просто формулируя цели — вы уже настраиваете себя.
Сформулировав цель вы получите результат больше, чем если не сформулируете и будете просто «копать-бежать».
Это лучше чем ничего, но точно недостаточно чтобы сделать прорыв.
OKR служит хорошей формулой для формулирования целей.
2. От ожиданий руководителя зависит результат сотрудников.
Руководитель, который думает что его окружают «дэбилы», получит результат сильно хуже, чем тот кто будет верить в своих сотрудников и доверять им. Мои ребята точно способны на большее!
А знаете чей слоган «для способных на большее»? Пишите в комментариях
Неудивительно, что эти ребята сейчас активно внедряют OKR. Это уже становится частью их культуры.
Вебинар: как соответствовать 152-ФЗ
Привет, Хабр! Ровно через 10 минут, в 16:00 мск, проведем вебинар для тех, кто взаимодействует с персональными данными. Поговорим про законодательство, которое регулирует эту работу, и расскажем, как определить свой уровень защищенности. Присоединяйтесь!
Смотреть трансляцию:
Программа вебинара
Что значит соответствовать 152-ФЗ
Кто определяет уровень защищенности компании и как его проверить самостоятельно
Как разграничиваются зоны ответственности по защите информации между оператором персональных данных и облачным провайдером
Как Selectel помогает соблюдать требования 152-ФЗ
Кому будет полезно
Всем, кто обрабатывает персональные данные
Всем, кому нужно подтверждение соответствия 152-ФЗ
Всем, кто думает, что в облаках небезопасно
Участникам вебинара отправим чек-лист вопросов для облачного провайдера по требованиям 152-ФЗ. За лучший вопрос подарим приз — нашего маскота Тирекса.
⛵️Без кого не выплывем: 4 ключевые роли в OKR-проекте
Одна из базовых причин, почему так много неудачных внедрений OKR - OKR не рассматривается в компании как проект трансформации.
И если уж компания решает, что помимо красиво сформулированных амбициозных целей им еще нужен результат, мы запускаем настоящий проект и собираем под него команду.
Представьте, что для выполнения сложной миссии нам нужна команда, почти, как на пиратском корабле🏴☠️.
Наш опыт показывает, что есть 4 ключевые роли, без который наш корабль никуда не поплывет.
Итак.
Для успешного внедрения OKR как проекта нам понадобятся следующие роли.
🔶 Лидер проекта внедрения OKR — главный в проекте, это по сути капитан корабля. Обычно эту роль на себя берет кто-то из ТОП-менеджеров. Он напрямую заинтересован в успехе проекта и обладает управленческими компетенциями. Как и любой бывалый капитан, он понимает важность человеческой составляющей в проекте изменений.
Ключевые его задачи:
✅ вовлекать ТОП-менеджеров и других участников проекта;
✅ управлять изменениями;
✅ обеспечивать ресурсами участников проекта.
🔶 OKR-коуч — главный эксперт по OKR. Это тот самый мудрец, обладающий секретными знаниями о сокровищах, без которых команда не реализует проект. Работает на уровне организации и ТОП-менеджеров, а не команды. Обладает обширной практикой и набором инструментов, которые подбирает под конкретную ситуацию, в том числе управления изменениями. Чаще это приглашенный эксперт.
🔶 OKR-мастер работает на уровне команды, а не компании. Он задает ритм, помогает грести в верном направлении через декомпозицию целей и выстраивание регулярного процесса изменений. С его участием команда системно добивается бОльших результатов. И точно доплывет быстрее, чем без него.
🔶 OKR-Strategist отвечает за сборку общего дерева целей по компании. Является экспертом в декомпозиции целей и работе с метриками. Его ценность в том, чтобы помочь компании правильно распределить ресурсы между различными целями и выстроить регулярный процесс мониторинга.
Стали выделять эту роль, когда выяснили, что в компании никто не отвечает за сборку общего дерева целей, каждый за свой кусочек.
У нас уже есть курс для OKR-мастеров. И мы планируем запустить обучение и по другим ролям, чтобы у компаний была возможность собрать полноценную команду и запускать изменения.
Поэтому сейчас я провожу бесплатные интенсивы в закрытом телеграм-чате. Подробности обучения и ссылка на чат в моем телеграм-канале.
У Трампа есть два экономических советника – Питер Наварро и Стивен Миран. Пока то, что происходит с тарифами укладывается в стратегию, которую описал Миран в своей книге «A User’s Guide to Restructuring the Global Trading System».
Если вкратце то Трамп хочет реструктуризовать всю мировую экономику, девальвировать доллар и с помощью метода кнута и пряника (пряник - это AI) вернуть производственные мощности в США, а так же заставить иностранных держателей государственных облигаций платить комиссию за использование доллара.
Посмотрим, что из этого получится, но необходимо заметить, что Миран и Бессант – это финансисты, которые работали в хедж-фондах, а Наварро занимался курсами MBA. Это теоретики, которые никогда не заминались реальным производством, а ломать логистические цепочки – это не тоже самое, что, их строить.
Как накачать управленческую мышцу? 🤔
Вспомните, как вы стали руководителем первый раз?
Вы показывали хорошие результаты на своей текущей позиции, были активны и хотели роста. Вы были хорошим экспертом и профессионалом.
Поэтому начальство и сделала вас руководителем, чтобы вы могли передать свою экспертизу и опыт новым сотрудникам.
Уже в роли руководителя вы брали самые сложные задачи на себя, как самый большой эксперт в команде.
Ваша экспертная мышца вновь прокачивалась значительное сильнее управленческой, еще очень слабой и не такой развитой.
В период кризисов вы также подключали свою экспертизу и опыт. Решения надо принимать быстро и максимально эффективно. Не до тренировок, дела делать надо.
В итоге в большинстве кризисных ситуациях (а последние лет 5 только такие и есть) вы добивались результата использую сильные экспертные мышцы. У управленческой мышцы даже не было шанса стать настолько же развитой, как экспертная.
Как это изменить?
В организме у нас тоже есть сильные мышцы - агонисты/антагонисты (двигатели), стабилизаторы (фиксируют сустав и корпус) и синергисты (усиливают движение).
Чтобы прокачать стабилизаторы, например, надо выключить основные мышцы с использованием тренажера, чтобы основная нагрузка была именно на те мышцы, которые нам необходимо.
По аналогии для прокачки управленческой мышцы нам необходимо отключить нашу экспертизу.
Как это сделать?
Начать управлять командой, где у вас нет предметной экспертизы.
Так вы автоматически подключите управленческую мышцу, потому что по другому просто не получится достичь результата.
А возвращаясь уже на привычку позицию, ты вдруг понимаешь, что у тебя кроме сильной экспертизы теперь честь и другая действительно сильная экспертиза - управление.
Поэтому в Японии управленцы периодически меняли свои позиции - руководил маркетингом, стал управлять складом или производством.
Это тоже про концентрированно прокачать управленческие компетенции.
Я не предлагаю менять ТОПов местами, есть вариант лучше.
Можно стать OKR-мастером для команды, где у тебя нет экспертизы и помочь ей достичь крутых результатов.
А я пока предлагаю вам перейти в мой телеграм-канал и больше узнать об OKR и лидерстве.
Давно искал простую напоминалку, которая бы мне подсказала, что пора оплатить подписку. Понятно, что сервисы и так напоминают, но хочется всё видеть списком в одном месте!
Не нашёл я простого инструмента, поэтому догадайтесь - сделал сам! Делал изначально для подписок, поэтому назвал When Pay, но теперь добавляю поход к врачу или дату поездки на поезде. В общем удобно и просто. Можно сделать задачу на 2035й год, к примеру.
Бот бесплатный, поэтому не дизлайкайте. Просто делюсь им с вами, товарищи любители запланировать и не прощёлкать!
Ссылка: https://t.me/when_pay_bot
💎Сократ и OKR
Более 2000 лет назад Сократ придумал концепцию - быть -> делать ->иметь
Суть ее в том, чтобы что-то «иметь», нам необходимо в начале «быть» этим человеком или компанией, потом «делать» (совершать поступки из этого нового состояния) и в результате поступков мы будем иметь то, что хотели.
Прочитайте еще раз. Вызывает ли у вас это сопротивление?
Почему?
Мы же часто хотим в начале что-то иметь, а уже после думаем про все остальное.
Но как можно «быть» в самом начале — спросите вы?
«Я же сначала хочу иметь млн долларов, а уже после этого я могу стать богатым. Наоборот не получится».
Но на самом деле всё не совсем так. Люди, которые выиграли лотерею или в казино, не остаются богатыми надолго.
Как думаете, почему?
Чтобы чего-то достичь, важно внутренне стать/быть таким. Именно этот новый подход изменит ваш способ мышления. Оно изменит действия, и уже это с более высокой вероятностью обеспечит «иметь».
Давайте посмотрим на такую ситуацию:
Есть ли для вас разница между - быть «отцом» и иметь детей?
Для одних разницы не будет. Это нормально 🙂
Но другие скажут что разница огромна — можно иметь детей и не быть отцом, а можно быть отцом, не имея детей.
Быть отцом — это цель, сформированная формате бытия (состояния).
Иметь детей — цель в виде действия (изменения).
А при чем тут OKR?
Когда мы только формировали с Татьяна Винтерголлер первый курс по OKR 3 года назад, то отметили , что есть цели-состояния, а есть цели-изменения. И долго обсуждали, стоит ли так усложнять на курсе. В результате первого прогона отказались.
И только в этом году я понял, в чем их отличия.
Формируя цель в формате состояния (каким я/компания хочу быть?), вы создаете целый набор вариантов, какие для этого необходимы изменения (цели-изменения) и, таким образом, создаете для себя целое пространство вариантов.
Если же вы фокусируетесь на целях-изменениях, то часть вариантов можно упустить.
Что важно — выбирайте тот вариант, который для вас комфортен на данном этапе. Если вы формируете цели от изменений, вы уже получаете преимущество перед 95% других, в следующем году сможете сделать следующих шаг 🙂
А как вы формируете цели и какой подход ближе? Поделитесь в комментариях.
P.S. Это пост-пояснение к публикации “В поисках идеальной формулы OKR”.
Как я провожу синки с тимлидами
Когда у вас больше пяти тимлидов в подчинении, а задачи множатся в геометрической прогрессии, стихийные синки превращаются в рулетку: то что-то забудете, то сорвёте дедлайн, то внезапный вопрос срочно «нужно обсудить». За год+ управления командами я перепробовал кучу подходов — и в итоге отточил формат, который убирает хаос, экономит нервы и не даёт терять важное. Рассказываю, как это работает.
Формат:
Обычно, такие встречи проходят раз в неделю. Цель – синхронизация по текущим задачам, проблемам и приоритетам.
Каждый синк – отдельная повторяющаяся приватная таска в таск трекере (как я веду задачи писал тут), либо приватная страничка в вики (в нашем случае конфлюенсе), где фиксируется повестка. Важно, что повестку наполняют оба: руководитель и подчиненный.
Структура:
Повестка состоит из трёх частей:
1️⃣ Обязательная часть
Фиксированный список тем, которые обсуждаются на каждой встрече. Этот раздел редко меняется.
Как правило это:
– Посмотреть action points с предыдущего синка
– Общий статус по задачам в работе
Для разных лидов обязательная часть может отличаться. Например, с некоторыми лидами у нас есть пункт по тайм менеджменту, потому что с этим часто бывают вопросы.
2️⃣ Опциональная часть
Эта такой живой раздел. Сюда каждый из участников записывает темы/вопросы, накапливающиеся в течение недели. Темы могут быть самыми разными: какой формат перфоманс ревью в этом полугодии, обсудить новую идею по изменению шаблонного сервиса, внедрение новых метрик и т.д.
3️⃣ Action points
Самый важный раздел. Здесь фиксируем договоренности с синка с указанием дедлайнов и ответственных.
Соответственно, такой скелет повестки с пояснениями по каждому разделу создается для каждой встречи и наполняется в течение недели.
Почему именно так?
Кому-то может показаться, что такой формат слишком бюрократичен. И в целом, когда у тебя пара подчиненных, действительно можно держать многое в голове, но когда их становится больше, то подобный формат мне дает:
✅ прозрачное отслеживание всех вопросов и договоренностей
✅ возможность накидывать темы заранее, не теряя их
✅ отсутствие стихийных созвонов, когда появляется какой-то вопрос. Всегда есть онятное место, куда его можно припарковать
✅ наличие повестки заранее, что позволяет лучше подготовиться к встрече
✅ лучше работает на асинхронное взаимодействие – если какая-то тема потеряла актуальность за неделю, можно просто её удалить, не тратя время на обсуждение
Про трекинг и достижение целей
Уже не раз замечал, что в задаче обязательно должен быть глагол. Если его нет, то при подведении итогов почти всегда возникает вопрос: «Что именно хотели сделать-то?»
Например, задача - 5 переговоров с клиентами. А действие какое?
- согласовать;
- провести;
- довести до счета;
- квалифицировать сделки после переговоров.
Глагол помогает устранить недосказанность. Интересно, что в команде часто происходят бурные обсуждения, какой глагол записать. Это подтверждает, что команда по-разному понимала одну и ту же задачу.
Чтобы возникало меньше вопросов, мы выработали формулу для задач на спринт: «что хотим сделать и для чего».
Например, согласовать 5 встреч с клиентами на следующей неделе, чтобы наполнить воронку.
Часть «для чего» позволяет понять, для чего вы хотите получить такой результат, и сразу проверить, то ли вы делаете.
Что еще важно:
1. используйте глаголы совершенного вида [сделаю, согласую, проведу и т.д.] - они нацеливают на финальный результат, а не на процесс.
2. используйте глаголы в личной форме - они наделяют ответственностью.
Теперь вы понимаете важность глагола в определении цели? Ваше мнение оставьте в комментариях.
P.S. Данный пост поясняет предыдущий. Продолжение в следующей публикации.