Мы, ITшники, привыкли к высокому уровню удобства продуктов и сервисов, которые мы сами и наши коллеги разрабатывают.
- Хочешь заказать еду? Скачай приложение и нажми кнопку!
- Нужно записаться к врачу? Скачай приложение и нажми кнопку!
- Надо купить или забронировать отель или билет? Скачай приложение и нажми кнопку!
- Надо продать авто? Скачай приложение и нажми кнопку! Да, сейчас так можно!
Авторизация в один клик! Оформи заказ сейчас, плати потом! Мы делаем всё, чтобы наши клиенты были довольны и ничто не мешало им быстро пройти всю воронку — от захода на сайт/приложение до финального действия.

А теперь я расскажу вам о моей (суровой и современной реальности) покупки автомобиля.
- Февраль–март: исследование, как можно купить автомобиль, не переплачивая в 1.5 или 2 раза.
- Апрель–май: осознание необходимости поиска автомобиля на аукционах Южной Кореи и выбор модели и марки, которые мне подходят.
- Июнь–июль: поиск провайдера, который сможет купить автомобиль в Южной Корее и доставить его в РФ.
- Июль: поиск конкретного автомобиля, уточнение его состояния, переписка с подборщиком, оформление договора и передача денег.
- Август: ожидание ... и наблюдение за перемещением автомобиля в контейнере из Владивостока в Москву.
- Сентябрь: ожидание прибытия автомобиля в Москву, перегон в Беларусь на растаможку и обратно в Москву, после чего — детейлинг и окончательные процедуры оформления и получения номеров.

Для меня это всё кажется полной дикостью, тк даже чисто ITшный опыт поиска авто на южнокорейском сайте был крайне ужасным. С нашим auto.ru не сравнится (не реклама). Я сам бы это все не осилил, мне помогал отец, тк, видимо, его поколение к такому привыкло, а наше (мое) ещё (уже) нет.

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

Про проклятие знания.

Проклятие знания (англ. curse of knowledge) — одно из когнитивных искажений в мышлении человека (см. их список); термин, предложенный психологом Робином Хогартом для обозначения психологического феномена, заключающегося в том, что более информированным людям чрезвычайно сложно рассматривать какую-либо проблему с точки зрения менее информированных людей[1].

Где-то последний месяц я жутко расстраивался из-за того, что приходится объяснять людям простейшие и, по моему мнению, понятные вещи. С одной стороны, это, наверное, часть моей работы, с другой стороны, возникает ряд вопросов: как всё это работало и существовало раньше. Покаравшись в инете открыл для себя бложик Тимлид Очевидность.

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

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

Учить — лечить — мочить

Татуировка «УЧИТЬ — ЛЕЧИТЬ — МОЧИТЬ» должна занимать достойное место на вашем туловище. Действуйте всегда исключительно в таком порядке, и все у вас в вашей менеджерской жизни будет прекрасно!

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

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

Про запас прочности.

Хорошо известна история, когда Генри Форд внезапно отправил руководителей всех отделов своих заводов в двухнедельный круиз по Карибам. По возвращении половину он уволил, а другую половину повысил, те руководители, чьи отделы в их отсутствии не потеряли эффективности, заслужили награду, ведь они, по мысли Форда, сумели грамотно организовать работу своих сотрудников. Те, чьи отделы начали «проседать», закономерно показали себя плохими управленцами.

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

История.
В декабре 2023 года один из моих тимлидов сообщил, что покидает компанию через две недели. Ничего необычного, подумал я, бывает. Моё беспокойство было связано не с его уходом, а с тем, что мне придётся искать нового тимлида, и какое-то время команда будет без руководителя. Через месяц, уже в январе 2024 года, я пришёл в команду узнать, как дела, и всё было хорошо: бэклог на квартал сформирован, команда понимала, что, когда и зачем ей нужно делать, осознавала свои обязательства перед всеми стейкхолдерами. Команда самостоятельно ставила себе цели на спринт и вела все скрам-процессы. Спустя ещё месяц ситуация радикально не изменилась, команда продолжала самостоятельно функционировать. Только спустя третий месяц начали проявляться первые проблемы, видимо, запас прочности, заложенный ушедшим руководителем, начал иссякать. В разговоре с членами команды стало ясно, что ушедший тимлид изначально закладывал принципы самостоятельности и ответственности. В команде не было такого: "я тут делаю только что-то одно, а что делает мой сосед, меня не волнует." В каждом сотруднике чувствовались проактивность, не было безразличия, а было общее желание показывать результаты.

Мудрость.
Если вы уходите в отпуск, а ваша команда успела потерять в эффективности за это короткий срок, то "хьюстон, у нас проблемы".

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

Субъективное мнение про ИПР.

Существует мнение, что составлением ИПР и развитием сотрудников должен заниматься руководитель. Я считаю иначе. Есть только один человек, который заинтересован в вашем развитии, — это вы сами. Да, наверное, лет 10-15 назад это было актуально. Сейчас, когда практически любая информация находится на расстоянии вытянутой руки от клавиатуры, когда количество курсов, конференций, вебинаров, подкастов и лекций больше, чем может вместить сознание любого инженера, составление ИПР звучит как расписка в собственной лени. Руководитель может скорректировать ваш план развития, упорядочить его, сказать, что важно сейчас, а что потом, но не составлять его за вас.

Лучший ИПР — это реальные задачи, решение которых даётся потом и кровью. Ничто так не закрепляется и не остаётся в памяти, как истории запусков сложных фич или проектов, как ошибки в найме и сложные взаимоотношения после, как лежащий прод в пятницу вечером после пятой пинты пива, как выбор между двумя плохими вариантами в условиях неопределённости, как ... .

Мне никто никогда не составлял план развития, как и я никогда не делал этого для своих сотрудников. Хорошо поставленная цель и соответствующая ей задача — лучший ИПР.

Про самый лучший интранет.

Я работал в разных конфигурациях корпоративных инструментов: личный мессенджер, далее МР, и самописный интранет; личный МР и энтерпрайзный коробочный интранет; корпоративный МР и самописный интранет; корпоративный МР и энтерпрайзный коробочный интранет. Так вот, интранет не нужен, никакой не нужен. Неважно, самописный он и поддерживается инженерами самой компании или это какая-то платная коробка. Всё, что представляет интранет, должно быть в МР, в корпоративном МР. Оргструктура, постановка целей, новости компании, календарь встреч, организация процесса ревью, организация процесса найма, NPS опросы, звонки, календарь дней рождений, создание заявок на отпуска, инцидент менеджмент, работа с codereview — всё это и многое другое должно быть в корпоративном МР или должно быть интегрировано в него, чтобы он был единым интерфейсом, через который любой сотрудник компании мог реагировать на изменения в других инструментах или создавать их через корпоративный МР.

Я не могу сказать, что где-то у меня был 100% опыт, что я описал выше, но на деле нет никаких технических проблем, чтобы это реализовать. API-интеграции и боты — наше всё. Ближе всего к этому, конечно же, приблизился Slack и впоследствии Mattermost.

(на скрине пример slack бота Mortimer для работы с инцидентами)

Про самоиронию.

Если у человека есть самоирония, он неуязвим!

В какой-то момент я понял, что самоирония — это один из моих инструментов руководителя. Для меня самоирония — это способ защитить себя от потенциальной критики, ведь когда ты сам публично критикуешь себя, любая внешняя критика не будет нести никакой смысловой нагрузки и будет звучать смешно. Я часто самоиронизирую над своими инженерными навыками, так как по разумным причинам не удается поддерживать их на уровне senior-инженера, а это важно при общении с сильными инженерами, чтобы они чувствовали себя комфортно при общении с СТО. Ведь звания/лычки/тайтлы никто не любит, а фраза "я не настоящий сварщик, так как уже 3 года не трогал код" помогает разрядить обстановку. Или, когда ты зашел на встречу, и все с умным видом что-то обсуждают, а ты ничего не понимаешь, фраза "Ребят, видимо, я немного отстаю, не совсем понимаю, почему..." помогает создать более открытую и непринужденную атмосферу.

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

Хорошим примером самоиронии Илона Маска является вот этот кусок из эпизода сериала "Теория большого взрыва". Вообще Маск — мастер самоиронии, иронии и сарказма. Ролики о том, как он увольнял из Twitter это отдельная категория интересного контента.

Пост о мелочи, которая может всё разрушить.

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

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

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

И вот так же в IT. Можно потратить уйму времени на исследование рынка, уникальный дизайн, общий перфоманс приложения/сайта, вложить кучу денег в маркетинг и продвижение, а в итоге всё запороть, забыв при релизе сменить адрес с тестового на продовый в финальной сборке.

Прошёл примерно год, как я воскресил этот канал и стараюсь регулярно сюда что-то писать.

Расскажу, почему вообще я его завёл. Помню, что было два триггера. Первый — это ТГ-канал Бывшая и смешная история вокруг этого канала. Рекомендую посмотреть, хороший стендап получился. Второй — это моя команда в ostrovok.ru. Когда я там работал, меня местами сильно бомбило по разным рабочим вопросам, и ребята порекомендовали завести канал, чтобы я писал туда, а не в рабочий мессенджер (Slack). Да, это были времена, когда Slack, JetBrains, Miro, MS и прочие ещё не знали о "культуре" отмен, а Линус Торвальдс вызывал уважение.

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

(продолжение)

Лично для себя я делю структуры на два типа: по центрам компетенций (далее ЦК) и по командам. По ЦК это значит, что, например, существует один руководитель всего backend, и весь найм backend-инженеров идет под его руководство, либо непосредственно, либо через какой-либо дополнительный слой, если речь идет о десятках или сотнях backend-инженеров. Командная структура подразумевает, что есть руководитель команды (тимлид — TL), и инженеры, которые входят в команду, подчиняются административно TL команды. TL команды в этом случае становится своего рода мини-СТО.

Понятно, что это холивар, в обоих подходах есть свои плюсы и минусы, и то и другое можно научиться как-то готовить, но я всей душой и сердцем за командную структуру. По одной причине: у любого сотрудника должен быть один и только один руководитель, и в командной структуре это именно так. В структуре ЦК у рядового сотрудника оказывается как минимум два руководителя: административный — в лице руководителя ЦК или какого-то руководителя внутри ЦК, и функциональный — в лице TL команды, в которой данный сотрудник сейчас работает. Двойственность всегда приведет к лишним конфликтам, дополнительной коммуникации, дополнительным проблемам и согласованиям, которых не должно быть, плюс если у сотрудника два руководителя, то это значит, что функциональный может поменяться, а это значит, что мне как сотруднику нет особого смысла вкладываться на 100% сейчас в работу той команды, где я нахожусь, так как сегодня я тут, а завтра я в другой команде. Это ведет к отсутствию овнершипа и привязанности к целям команды.

Совсем недавно вышло свежее исследование про руководителей разработки за 2024 год, вот, кстати, за 2023. Порадовало в отчете то, что книга "Как пасти котов" наконец-то считается антипаттерном, как не следует вести себя (тимлиду) при работе с командой. Я в своё время пытался два раза её прочитать и каждый раз останавливался на 1/3.

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

Утром стулья — вечером деньги.

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

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

Иными словами — сначала 🪑, потом 💸

А как начался ваш высокий сезон?

Интересный факт. Знаете почему в Jira тикеты (они же задачи) называется issue? И все поля тикета в jql начинаются на issue, например issuetype? Потому что Jira изначально разрабатывалась не как task tracker, а как инструмент для ведения инцидентов.

Инциденты — это наша обыденность, вопрос лишь в частоте их возникновения и уровне критичности. Они были, есть и будут. Хорошо, когда они происходят в рабочее время, когда все на своих местах и могут подключиться, но так бывает не всегда. Инцидент может застать нас в выходной день, в пятницу вечером, в отпуске, на больничном, где угодно. Я не могу выделить какое-то самое-самое необычное место для себя, но достаточно часто за последние 4 года меня просят подключиться к решению инцидента, когда я нахожусь в тренажёрном зале. Такое точно было раз 10. В какой-то момент у меня уже, как у собаки Павлова, выработался рефлекс, что при входе в зал я начинал проверять чат инцидентов и только если там чисто, шел заниматься.

11.11 и Чёрная пятница. Вокруг этих двух дат строятся разные маркетинговые кампании и промоакции в ноябре. Всё это вызывает рост трафика на Ecom сервисы от 2 до 5 раз. Мы в ЗЯ начали готовиться к высокому сезону ещё летом. Не могу сказать, что всё прошло идеально, но непосредственно для клиентов всё было относительно гладко. Под капотом, конечно, были проблемы и есть что тюнить, но нет предела совершенству.

До конца года в ЗЯ будут постоянно проходить разные скидки, акции и подарки как эта. Закупаемся и радуем близких всякими нищтяками.

Наткнулся на отличную серию статей, разбирающую каждый из этапов формирования команды – forming, storming, norming, performing, на примере монтажной бригады, прокладывающей ЛЭП где-то в тайге.

И вот под эту задачу компания набирает бригаду работников в количестве двенадцати человек: восьмерых рабочих-монтажников, двух водителей-механиков на две буровые установки с краном и повара-завхоза с помощником для обеспечения всей бытовой части. С таким расчётом, чтобы получились две рабочие подгруппы по 4 монтажника + 1 водитель-механик, каждая из которых – чих-пых, чих-пых, – обгоняя друг друга в шахматном порядке, проходили бы по 600-700 метров в день, устанавливая по 8 опор на подгруппу. Как говорится: "Отличный план! Надёжный, как швейцарские часы!"

- Стадия Forming - часть 1.1 / часть 1.2
- Стадия Storming - часть 2.1 / часть 2.2
- Стадия Norming - часть 3.1 / часть 3.2 / часть 3.3 / часть 3.4 / часть 3.5 / часть 3.6
- Стадия Performing - часть 4.1 / часть 4.2

Автор, конечно, проделал гигантскую работу, и сложно сделать какое-то краткое заключение. Просто читайте и делайте выводы сами. Первоисточник канал - @dmiboldyrev

Чем заняться в Дубае?

Подняться на Бурдж-Халифа? Посетить Дубай Молл? Покататься на верблюдах? Поплавать в Персидском заливе?

Нет, это всё не важно! Важно, что теперь разные бьюти нищтяки можно заказать онлайн в Золотом Яблоке, потому что сегодня мы открылись в Арабских Эмиратах!

iOS / android / goldapple.ae

P.S.: Если вы любите всё потрогать, пощупать, понюхать, то офлайн магазин тоже скоро будет.

Telegram — плохой мессенджер для корпоративной работы.

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

У меня большой опыт использования различных корп инструментов и мессенджеров. Помню, что все начиналось со Skype, потом был Google Talk, затем появилась Telegram и уже где-то в 2014 — Slack. Пять лет я пользовался Slack и был в восторге от его функциональности и ботов. Потом, при смене работы, пришлось перейти на весь стек MS 365, в том числе на MS Teams. Как мессенджер, Teams, конечно, слабоват по сравнению со Slack, но его интеграция календарь + звонки + чат — это кайф!

Я всегда (после опыта slack) был противником использования любых общих мессенджеров типа Telegram для корп работы. Причин этому множество, и некоторые вполне понятны и лежат на поверхности:
- безопасность,
- логин по корпоративной учетной записи,
- поиск любого сотрудника внутри мессенджера по ФИО.

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

И, пожалуй, главное — это принцип публичности информации и способов массовой коммуникации. В любом некорпоративном мессенджере нет возможности делать HBC (high bandwidth communication). Нет возможности написать что-то куда-то, чтобы эта информация была донесена до каждого сотрудника компании. Эта проблема порождает создание множества мелких чатов каждый раз с разным составом. Все общие чаты в Telegram, где больше ста человек, сразу замьючиваются, так как там, как правило, начинается бардак и флуд. Про отсутствие тредов я вообще молчу, топики не в счёт.

Сейчас, на мой субъективный взгляд, рынок в РФ поделился на две части. Первые — это те, кто раньше сидели на Slack и сами перешли на Mattermost или купил Mattermost, обернутый в собственный продукт (loop, time). Вторые — это те, кто не может по тем или иным причинам использовать Mattermost, и их обязывают пересаживаться на решения, которые получили какую-либо сертификацию от государства (express, squadus, ...). Есть ещё, конечно, что-то между, типа pachca и VK Teams, но о них я совсем ничего не знаю.

К чему я это всё? Slack и MS Teams ушли из России или навсегда, или на очень долгое время. Исходя из закреплённой новости, использование Telegram для корпоративного общения также может быть под вопросом (и я этому рад). Видимо, следующие два года будут крайне интересными в плане конкуренции за рынок корпоративных мессенджеров в РФ.

Пост про мобильную платформу, как продолжение этого поста.

Наконец-то закрепил мысли о мобильной платформе в своем playbook.

Общая цель мобильной платформы — это обеспечение высокого DevExp для любого разработчика iOS/Android с целью повышения общего качества и стабильности разработки для последующего ускорения time-to-market в продуктовых командах.

Помните, где-то в середине 2010-х появился термин Mobile First? Я впервые услышал его на одном из AllHands в Островке. СЕО говорил, что вскоре более половины заказов будет делаться на мобильных платформах, и веб будет отодвинут на второй план. В целом сейчас так и есть. В ЗЯ веб занимает достаточно небольшую долю Ecom заказов относительно iOS+Android. При этом он критически необходим в рамках общего продуктового ландшафта для клиентов. Почему Mobile стал First, думаю, понятно. А что дальше? Как поддерживать близкие или одинаковые подходы для iOS/Android, чтобы условным QA было легче тестировать, а бэку не приходилось разрываться между хотелками разных платформ? Как делать BDUI? Как внедрять APM? Как выстраивать единые подходы к релизным циклам? Разные компании решают эти вопросы по-разному, но как будто все в итоге приходят к мобильным платформенным командам.

#playbook

Пост про благотворительность.

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

Явным триггером стала жуткая трагедия в ТЦ "Зимняя вишня" в городе Кемерово. Помню, что мне очень хотелось как-то помочь, но я не понимал, как это сделать. Это желание трансформировалось в поиск удобного способа помогать детям с какими-либо заболеваниями типа рака или чего-то аутоиммунного. Сначала я пользовался сервисом Добро от Mail.ru. Но сейчас, как мне кажется, существует значительно более удобный и простой способ жертвовать на благотворительность — это настроить в своем банке перевод кэшбэка в любой из благотворительных фондов. Мне этот вариант нравится тем, что чем больше я трачу, тем больше помогаю, а чтобы больше тратить, надо больше зарабатывать. Таким образом, изначально чувство алчности и условное желание купить новый автомобиль в итоге приводит к тому, что я больше трачу на благотворительность.

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

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

С наступающим новым годом, инженеры!

Помните Stadia от Google?

Stadia была анонсирована в марте 2019 года и запущена уже в ноябре. Идея облачного гейминга была не нова, и многие игроки на рынке уже имели свои платформы для этого, такие как GeForce Now от Nvidia, но интеграция Stadia с YouTube выглядела действительно инновационно. Уже в сентябре 2022 года Google официально объявила о прекращении работы Stadia, и в январе 2023 года платформа была окончательно закрыта.

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

Желаю всем нам, чтобы в следующем году мы как можно меньше падали, а уж если упали, то быстро поднялись и ... (ну вы поняли)

Всем мир, любовь и отсутствия инцидентов на предстоящих праздниках!

Про аутстафф.

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

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

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

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

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

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

В целом аутстафф — нормальная тема, если уметь его правильно применять и не преувеличивать с количеством.

Про управленческую ёмкость у руководителя руководителей.

Выше в этом посте я размышлял про максимальный размер команды. Сейчас хочется подумать о количестве прямых репортов у руководителя департамента/отдела/управления, те не о руководителе команды.

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

Если отталкиваться от «Кошелек Миллера», то это 7 ± 2. На мой взгляд, это не совсем верно именно для данного вопроса, верно что-то типа 4 ± 1. Две команды — вроде бы слишком мало, чтобы формировать домен, а шесть — уже как будто бы слишком много, чтобы держать в фокусе все цели всех команд и строить долгосрочное целеполагание и систему метрик для тимлидов этих команд. Понятно, что это зависит от множества факторов и условий, но, на мой взгляд, должно быть примерно так.

Если спросить у gpt, то

3–5 команд. Подходит для отделов, требующих высокой координации и персонального внимания (например, научные исследования, продуктовые команды в IT).
5–8 команд. Стандарт для крупных отделов, где требуется умеренный уровень координации.
Более 8 команд. Это редко, так как высокая нагрузка на руководителя снижает управление. В таких случаях создаются дополнительные уровни управления (например, подотделы с руководителями групп).

Что думаете?