#рекап

Стикерочки из 2025

#цитатки
 
Чешский писатель Карел Чапек как-то раз был в Лондоне и там поразился великолепным газонам, по которым прохаживались гуляющие, и спросил работника парка, в чём их секрет.
 
– Никакого секрета, сэр, – ответил работник, – нужно стричь-поливать, стричь-поливать, стричь-поливать каждый день, и так триста лет.
 
===
 
В этой новогодней открытке хочу вам пожелать, чтобы каким бы "газоном" вы ни занимались – брендом ли работодателя, инженерной ли культурой, наймом или тайм-ту-маркетом, – пусть достижение великолепного результата у вас случится обязательно и поскорее.
 
Счастливых праздников!

===
 
P.S.: если будете смотреть по сторонам про идеи к праздничному столу – таки гляньте видосик с рождественским Джейми Оливером.

Пара быстрых нехитрых трюков, и вот картошка и морковка из обыденных становятся духоподъёмными, вот ей-богу.

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

Ну как вы?
 
👍 – норм
🤔 – ещё сам не понял
❤️ – а хорошо
🤬 – бывало лучше
🔥 – вообще хорошо!
🤯 – пытаюсь смириться, что давайте уже после праздников – это сейчас

#вопрос_ответ
 
Q: Поделитесь, какую мотивацию используете для лидеров и активного ядра внутренних сообществ?
 
A: В первом приближении историю с внутренними сообществами я стараюсь заваривать на базе идеи.
 
+ Тайм-ту-маркет: в одной команде запилили, в другой подсмотрели и не стали делать свой велосипед; суммарно все ускорились с доставкой ценности

+ Бас-фактор: размазываем экспертизу более равномерным слоем по людям в компании. Чтобы в случае, если носитель важных знаний ушёл в отпуск, уволился, выгорел, разочаровался в человечестве – мы не потеряли что-то полезное

+ Профессиональное развитие людей в стриме: через систематизацию знаний и шаринг экспертизы

+ Чтобы было с кем вменяемым поговорить про работу (ищешь такое место – сделай его)
 
Алгоритм: беру лидера сообщества (фактического или потенциального); садимся обсудить идею, вокруг чего может крутиться сообщество; накидываю варианты в духе тех, что выше; слушаю, что человеку больше откликается; копаем вместе, что можно поделать, чтобы двигаться в сторону треда, который отзывается

===
 
Какие прецеденты по части поощрений активистам внутренних сообществ я видел за последние несколько лет:
 
+ Фидбэк-бумеранг от участников сообщества
 
Эйчары проводят опросы 360 и прочие исследования лояльности, замеряют там импакт от фактора "я как инженер состою во внутренних сообществах и мне это по кайфу", возвращаются к хосту сообщества с этими замерами
 
+ Гордость хоста за участников
 
Деврелы помогают вести лог активностей в сообществе, перепроверяют ачивки – что ребятам из коммьюнити получилось сделать внутри сообщества и благодаря ему.

Возвращаются с этими находками к хосту сообщества.

Часто эти ачивки оформляются в какой-нибудь внутренний дайджест
 
+ Благодарность от топов
 
СТО, CEO, COO, прочий С-левел. Тут у кого какая орг структура
 
+ Мерч
 
+ Баллы имени Святой Геймификации Всего На Свете
 
Копятся, потому обмениваются на мерч или технику (новый монитор, нашуники, дальше по перечню товаров магазина мерча)
 
+ Лычки
 
Специальная метка на внутреннем портале – "лидер такого-то сообщества". На аватарке в корп мессенджере – то же самое. Тематический флажок на столе в офисе (благословенный офлайн)
 
+ Диджитал-айдентика
 
Похоже по смыслу на лычки и мерч, но есть отличие – это про визуальные артефакты для сообщества, а не отдельно взятого человека. Лого, стикерочки, кастомный форк корпоративного шаблона слайдов.

Не на коленке, а вот прямо призвали на помощь дизайнеров, сделали красиво. Себе футболку – ладно уж, а вот что у ребят из твоего стрима есть собственная айдентинка – приятно
 
===
 
Материальная мотивация для ядра внутреннего сообщества в моем опыте скорее не работала, чем работала. Баллы для магазина мерча, сам мерч, билетики на конфы – приятные штуки, но скорее в режиме бонуса постфактум, чем как "то, ради чего". С деньгами ещё сложнее
 
В жизни сообщества всегда есть стадия выгорания лидера (вот ей-богу всегда). Когда делает-делает, а отклик участников не всегда такой, как хотелось бы. Если его усилия будут не за сильную идею, которая драйвит, то риск выгорания выше
 
===
 
Это ответ на вопрос из сообщества деврел-бюро
 
Задать свой вопрос – приносите в форму или личку @adolgushev.
 
===
 
👍 – тоже мотивируем наших коммьюнити-активистов какими-то такими штуками
🤔 – мотивируем совсем другими штуками
❤️ – лидер внутреннего сообщества – это я, здравствуйте
🤬 – если вам надо мотивировать активистов, значит, вы что-то не так делаете
🔥 – вижу в посте идею, которую хочется попробовать для своих сообществ
🤯 – а помотивируйте меня какими-то такими штуками?

Завтра повышение цены на билеты #деврел_мастерская – успевайте

#вопрос_ответ
 
Q: Как обычно выстроен процесс согласования технического контента? 
 
A: Типовая схема согласования:
 
1. ок от непосредственно эксперта-автора – в случае, когда контент генерит деврел/редактор/специально обученные люди
 
2. ок от хэда деврела (или кто лидит эту функцию в компании)
 
3. ок от прямого руководителя эксперта – чтобы был в курсе и подтвердил, что нигде не переврали, ничьи политические чувства не затронуты
 
4. ок от руководителя направления, в котором работает эксперт; например, для доклада по разработке – от СТО; для продуктовых историй – от CPO

5. ок от безопасников
 
6. ок от пиара 
 
===
 
В зависимости от контекста компании и обстоятельств, можно убирать шаги (иногда бывает, что добавлять)
 
Из тех, кто может добавиться – ещё какие-то стейкхолдеры деврела. Например, CEO в этом сезоне хочет держать руку на пульсе технического контента; попросил показывать ему все история для публикации наружу
 
Каждый шаг в схеме требует предварительной договоренности. Например, СТО может в гробу видать согласования контента, тогда нужен будет человек вместо него с достаточными полномочиями.

Кто бы это ни был, все причастные должны согласиться с такой расстановкой ролей. Иначе не поедет
 
===
 
Важная история: протокол на случай фейла. 
 
Например, у нас вышла какая-то история в паблик, которую вроде как пропустили через всю цепочку согласований, но она наделала шума негативного
 
У стейкхолдеров в такие моменты есть соблазн включить режим ручного контроля: перепроверять каждый чих, чтобы фейл не повторился. Это заметно усложняет и замедляет согласования
 
Для таких случаев можно использовать приём "сухая серия"

===
 
Задать свой вопрос про деврел – приносите в форму или личку @adolgushev. 
 
===
 
👍 – согласовываем похожим образом
🤔 – согласовываем вообще по-другому
❤️ – о, пригодится такой список, спасибо!
🤬 – не согласен ни по одному пункту
🔥 – я – тот, кому приносят на согласование
🤯 – публикуем всё как есть, без согласований

#обучалово #видосик
 
Для тех, кто любит смотреть видео прямо в телеге – аттач с записью открытого урока обучения "Деврел-лид"
 
00:00 О чём это видео
00:45 Лидские ups and lows из личного опыта
05:00 Лидский инструментарий из книжки
05:38 Что за преподы
06:46 Чем отличается руководитель от исполнителя?
11:27 Процессы в команде
13:20 Какое предназначение у команды
20:28 А что не устраивает?
29:15 Наброс: деврел по инерции
31:02 Вопрос из чата: насколько ок спрашивать у ИТ-команды, чем должен заниматься деврел
38:33 Анализ входящего потока команды
46:21 Программа курса
48:23 Формат обучения
49:51 Что дальше
51:46 Вопрос из чата: можно ли стать деврел-лидом без опыта в девреле
53:33 Вопрос из чата: на текущем рынке как дела с ролями деврелов и лидов?
54:49 Вопрос от зрителей: как стать лидом, если место занято?
 
👍 – гляну видос
🤔 – я деврел-лид, и у меня всё оке-доке, нет вопросов
❤️ – я не деврел, пока просто интересуюсь
🤬 – вот даже не любопытно
🔥 – я деврел, но не лид
🤯 – делаю деврел-штуки, но я не деврел – какие-нибудь советы для такого случая?

Шатаем точки контакта с аудиторией: стенд на конференции

Делал я однажды эксперимент

На стенде компании всем вообще людям, кто подходил, задавал вопрос в самом начале общения: "О чём тебе рассказать – что тут у нас есть весёлого, что полезного или что-то посередине?"

Делал так на всех конференциях, куда довелось угодить в 2023-2024

Если просили весёлое, то отводил к активности-игре

Полезное – знакомил с инженером из компании, близким по профилю к человеку; чтобы поговорили про работу

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

Условно: весёлое – "попади мячиком в стендиста, выиграй носки"; полезное – "познакомься, это Вася, он лидирует практику тестирования у нас в компании, расскажет тебе всякое"; посередине – "в этой игре прокати заявку на кредит по техническим системам банка, а я буду тебе комментировать"

Какие словил наблюдения:
+ если конференция фестивального типа (несколько тематических треков про разное), то 70% людей просят весёлое, 20% полезное, 10% что-то посередине
+ на конфах, посвященной одной тематике – 40% весёлое, 40% полезное, 20% посередине
+ в течение всего времени эксперимента стабильно рос процент людей, кто просит весёлое
+ чем выше уровень человека (по предвзятой субъективной экспресс-оценке в процессе разговора), тем с большей вероятностью выбирал полезное
+ были люди, кто выбрал один из трёх вариантов, а потом спрашивал "что ещё у вас есть?" и участвовал в других сценариях тоже

В итоге оно сложилось в воронку!

Весёлое →
Посередине →
Полезное

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

На каждом переходе между уровнями воронки отваливается часть людей; конверсия перехода никогда не 100%

Есть люди, готовые сразу запрыгнуть в более низкие уровни воронки

Всё по классике!

===

Какие мысли я в итоге утащил из этой истории:
+ не стоит бояться предлагать более сложные сценарии, где нужно больше вовлеченности участников
+ но начинать предлагать всё же лучше с простых опций; пусть даже и с возможностью их скипнуть
+ если предлагаем только простые (фановые) активности, то упускаем возможность сильнее прогреть лиды

И моё любимое: все эти инсайты – они из конференций, но не только про конференции.

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

Будь то конференция, Хабр или, например, внутриком.

Куда двинем дальше?

👍 – давай ещё истории из конференций
🤔 – про другие внешние точки контакта с аудиторией
❤️ – про работу с внутренней аудиторией (внутренний деврел, техновнутриком)
🤬 – никакой разницы, ибо всё тлен
🔥 – про деврел-активности руками не-деврел-специалистов
🤯 – про деврельские грейды и треки развития

#деврел_мастерская стартует 26 января
 
Перепроверьте, кто там спикеры и о чём будут рассказывать – вдруг там будет что-то интересное для вас
 
Помогаем внутреннему сообществу: история взлётов и падений
Толя Мелентьев
независимый эксперт
 
Как приручить сложного автора: лайфхаки и матчасть
Катя Рубашенко
технический редактор в ecom_tech
 
Сколько технического контекста тебе как деврелу нужно понимать и где его взять
Зина Беззаботнова
деврел в Ozon
 
От первого лица: как выглядит управление сообществом глазами лида
Алина Меркурьева
дизайн-лид B2B в Альфа Банке
 
Корпоративные заменители инженерного движа, которые не работают – для опенсорса, сообществ, конференций
Никита Соболев
full-time open source-разработчик, независимый эксперт
 
Как крупному ретейлу подружиться с айтишниками? Инсайты из опыта развития техбренда Ленты
Маша Киселёва
head of technology brand development в Lenta Tech
 
Хакатон своими руками: взгляд техлида-организатора
Ваня Елфимов
backend teamlead в Островке
 
Гордость и предубеждение соло-деврела: какие возможности открывает формат работы в качестве единственного специалиста функции
Маша Кияшко
деврел в red_mad_robot
 
Как дайджесты и внутренние коммуникации помогают позиционировать ИТ внутри компании
Олеся Богданова
деврел в Страховом Доме ВСК 

Грабли для компании-партнера конференции глазами организатора ивента
Артём Лузянин
крайний за конференцию "Город IT"
 
Почитать описания докладов
 
👍 – пойду гляну описания
🤔 – что за деврел-мастерская? первый раз слышу
❤️ – нравится!
🤬 – не нравится!
🔥 – я уже вписался
🤯 – я уже выписался
 
Что делать, если нравятся темы/спикеры #деврел_мастерская, но в эти даты и время никак не получается вписаться?
 
Специально для такого случая есть опция "Купить только записи докладов", без чатика и подключения к созвонам.

Там будет видео с 10 докладами, в бессрочном доступе; чтобы можно было посмотреть в подходящий момент с комфортной скоростью.
 
Общения с экспертами и другими участниками это не заменит, но послушать истории интересных людей, выловить оттуда инсайты – такая возможность будет.

Присмотреться к опции "Купить только записи"

Как работают быстрые приготовления для статей на Хабр – чтобы получить 20к просмотров за сутки

Готовите вы, стало быть, статью к себе на Хабр.

При прочих равных Хабр – долго. В среднем по больнице на статью с нуля уходит 8-12 часов, начиная с "у нас всё обычное / мне не о чем написать" до финальной вёрстки.

Но есть быстрые трюки.

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

Например, дошлифовка заголовка и открывашки.

===

Пусть делаем переводную статью.

Что имеете в оригинале:

Заголовок:
Goodbye Microservices: From 100s of problem children to 1 superstar

Открывашка:

Microservices is a service-oriented software architecture in which server-side applications are constructed by combining many single-purpose, low-footprint network services. The touted benefits are improved modularity, reduced testing burden, better functional composition, environmental isolation, and development team autonomy. The opposite is a Monolithic architecture, where a large amount of functionality lives in a single service which is tested, deployed, and scaled as a single unit.

Twilio Segment adopted this as a best practice early-on, which served us well in some cases, and, as you’ll soon learn, not so well in others.

In the early days of Twilio Segment, we reached a tipping point with a core piece of Twilio Segment’s product. It seemed as if we were falling from the microservices tree, hitting every branch on the way down. Instead of enabling us to move faster, the small team found themselves mired in exploding complexity. Essential benefits of this architecture became burdens. As our velocity plummeted, our defect rate exploded.

Eventually, the team found themselves unable to make headway, with 3 full-time engineers spending most of their time just keeping the system alive. Something had to change. This post is the story of how we took a step back and embraced an approach that aligned well with our product requirements and needs of the team.

Дословно перевести можно как-то так:

Заголовок:
Прощайте, микросервисы: от сотен проблемных «детей» к одной суперзвезде

Открывашка:

Микросервисы — это сервис-ориентированная архитектура программного обеспечения, при которой серверные приложения строятся из множества узкоспециализированных, легковесных сетевых сервисов. Заявленные преимущества — лучшая модульность, меньшая нагрузка на тестирование, более гибкая композиция функциональности, изоляция окружений и автономность команд разработки. Противоположность этому подходу — монолитная архитектура, где значительный объём функциональности сосредоточен в одном сервисе, который тестируется, развертывается и масштабируется как единое целое.

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

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

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

===

Насколько инженеру захочется прочитать такую статью? Дети какие-то, суперзвёзды... А вступление в духе "давайте договоримся про термины и понятия"?

Дело вкуса, конечно.

Но что может получиться, если в название поместить тизер проблемы и решения, квинтэссенцию пользы? А в открывашке расшифровать – описать ситуацию, в которой читатель сможет себя представить, потому что жизненно?

Заголовок:
Как микросервисы стали тормозом. И почему мы вернулись к монолиту

Открывашка:

Изначально микросервисная архитектура решила реальную проблему - изолировала очереди и убрала “head-of-line blocking”, когда один упавший адресат тормозит всех.

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

В итоге команда объединила 140 сервисов в один монолит, собрала монорепо и стабилизировала тесты через запись/воспроизведение HTTP-трафика.

===

Что может получиться – статья на 20к просмотров в первые сутки, 33к за пару недель.

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

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

===

Эту историю принёс Вова Невзоров @vova_dev.

Рассказывал, как готовил статью для связки Хабр/телеграм-канал @system_design_world, смотрел доклад про быстрые приготовления для статей на Хабр, поймал эффект "20к просмотров в первые сутки". Сама статья – тут.

👍 – норм
🤔 – ну такое
❤️ – пойду погляжу канал Вовы, любопытно про такой контент
🤬 – не интересно про статьи на Хабр
🔥 – прикольный трюк, попробую для следующей статьи пошаманить заголовок и открывашку в таком духе
🤯 – но мы же не знаем, сколько просмотров собрала бы статья с дословным переводом? предъявите ваши А/Б-тесты!

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