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

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

В какой-то момент я понял, что самоирония — это один из моих инструментов руководителя. Для меня самоирония — это способ защитить себя от потенциальной критики, ведь когда ты сам публично критикуешь себя, любая внешняя критика не будет нести никакой смысловой нагрузки и будет звучать смешно. Я часто самоиронизирую над своими инженерными навыками, так как по разумным причинам не удается поддерживать их на уровне 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 команд. Это редко, так как высокая нагрузка на руководителя снижает управление. В таких случаях создаются дополнительные уровни управления (например, подотделы с руководителями групп).

Что думаете?

Должен ли СТО хантить сам?

Когда я работал в Магнит, рядом с нами, скажем так, на одной улице, расформировывалась одна из самых крупных (или самая крупная) IT-компаний РФ в сфере доставки продуктов и еды из ресторанов. Благодаря проактивным действиям и нетворкингу нам удалось привлечь в свои команды топовых инженеров. Этим занимался не рекрутмент, этим занимался наш СТО и все СТО-1.

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

Думаю, вы слышали, что, начиная с декабря 2024 года, в IT-инфополе начали появляться новости о череде сокращений у крупных IT-гигантов. Это продолжается и на текущий момент, новостей становится больше и касается это большего числа компаний. Понимаю, что аудитория этого канала является достаточно узким кругом моих знакомств, но всё же, если вы сейчас находитесь в поиске, напишите мне (@arxell). Или откликайтесь на наш лендинг. Сейчас в первую очередь нужны сильные C# backend-разработчики для развития своей программы лояльности/биллинга и запуска разных рекламных штук =)

Банального вопроса пост.

Должен ли TeamLead писать код?

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

Должен ли TeamLead писать код в команде, состоящей из трёх backend-разработчиков?

Или такой:

Должен ли TeamLead писать код в команде, состоящей из десяти инженеров разных стеков разработки/тестирования/аналитики?

В целом всё просто. Чем больше в команде инженеров разных специальностей, тем меньше TeamLead должен уделять времени написанию кода. Его фокус смещается на people-менеджмент, процессы, архитектуру, документацию, метрики и планирование. На самом деле, на все то, что описано на Teamlead Roadmap.

Сейчас это встречается реже, но раньше в вакансиях на TeamLead'а часто писали про "играющего тренера" при команде из ±10 человек. Это жуткий антипаттерн. Если вы хотите полноценного "играющего тренера", который будет хотя бы 50% времени писать код, то это точно про функциональные команды (команды одного стека разработки) с составом ±5 человек.

Моя точка зрения такая: Не важно, пишет ли ваш TeamLead код, важно, чтобы он "программировал" своих сотрудников и свою команду на успех!

Набор статей на эту тему для составления собственного мнения:
- Должен ли тимлид писать код?
- Почему тимлид может писать код?
- От джуна до тимлида. Должен ли тимлид писать хороший код, чем хорош planning poker и другие интересности
- Уже не программист, но еще не менеджер
- Руководитель, который навсегда в вашем сердечке, — какой он? И что делает его таким крутым? ❤️

Крутое исследование от JetBrains - State of Developer Ecosystem Report 2024

Вот что я для себя отметил:
- JS, как всегда, на первом месте. Python тоже не отстает, видимо, благодаря ML/DS и прочим математическим задачам.
- Радует, что PostgreSQL потихоньку отжимает аудиторию у MySQL, а MongoDB/SQLite/Redis внезапно для меня стабильно находятся на +- третьем месте.
- GoLang немного сдал позиции, но, видимо, за пределами РФ. В РФ все же Go остается крайне популярным.
- Rust потихоньку растет и все еще надеется заменить C/C++.
- Yandex Cloud занял 1% аудитории облачных сервисов, что приятно.
- 28% респондентов ответили, что компания измеряет их development experience и продуктивность. При этом за эти метрики в 68% случаев отвечает TeamLead, а в 17% случаев — платформенные команды. Однако! =)
- Самое сложное в работе: 38% — понять, чего хочет клиент, 34% — коммуникации по рабочим вопросам c коллегами, 32% — понимание чужого кода.
- И самое интересное и волнующее для меня — это размер команды: 71% опрошенных работают в командах до 12 человек.

Метрики эффективности спринта.

Летом 2024 года, когда все были в отпусках, у меня выдалось две относительно свободные недели. Передо мной стояла задача подумать над тем, как можно оценить работу команд, которые делают Ecom в ЗЯ. Не с целью найти слабых, а скорее понять, что где как поломано, работает плохо или не работает вообще. Не помню как, но сначала я наткнулся на этот плагин для grafana, а затем на эту статью от Skyeng на Habr. И понеслось...

Я загорелся идеей на основе непосредственных данных из базы Jira построить ряд дешбордов для оценки как классических метрик типа TimeToMarket / LeadTime / CycleTime, так и метрик эффективности спринта.

Что такое вообще метрики эффективности спринта? Опять же, есть множество способов измерить спринт. На эту тему мне очень нравится вот этот доклад на PodlodkaTeamLeadCrew#12 от Avito. Но если не погружаться в академические тонкости, и строить что-то свое на коленке, то это % того, что команда сделала относительно того, что она обещала сделать.

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

На скрине спринт одной из команд, где я ВРИО тимлида, команда запланировала 12 сторей (целей), закрыла за сам спринт 9, то есть 75%. Уже чуть позже, в самом начале следующего спринта, еще 2 стори, то есть 91%. Но итоговый результат мы считаем 75%.

Если говорить о каких-то выводах, то основное, и, наверное, в чем-то стыдное и банальное, — это фокусировка команды на целях спринта, оформленных так, чтобы это было визуально максимально понятно и прозрачно видно на Scrum-доске, например, в виде swimlane'ов.

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

Что ты будешь делать, если задача, поставленная перед тобой, плохо описана?
1. спрошу у лида
2. верну задачу обратно в пул со статусом need info
3. отвечу на свои вопросы сам и сделаю так, как считаю правильным
Ожидаемый ответ: 1 или 1/3

Что ты будешь делать, если у тебя кончатся задачи в спринте?
1. ничего
2. займусь самообучением/самообразованием
3. возьму сам задачи из бэклога
4. спрошу у лида
5. посмотрю, что у нас с техническим долгом, и постараюсь закрыть его
Ожидаемый ответ: 3 или 4 или 5

Если тебе что-то непонятно, то ты спросишь у лида или попробуешь разобраться сам?
1. буду стараться разобраться сам, пока не сдамся
2. попробую быстро разобраться сам, если не получится, спрошу у лида
3. сразу спрошу у лида, тк это будет быстро и эффективно
Ожидаемый ответ: 1 или 2

Для разработки фичи нужна помощь разработчика из другой команды. Сегодня он работает удаленно, а фичу хочется начать делать уже сегодня. Что делать?
1. постараюсь четко сформулировать свой вопрос и задать его в корпоративном мессенджере. Буду надеяться, что получу полный ответ
2. предложу пообщаться с коллегой голосом в Skype
3. дождусь завтра, когда он будет в офисе, а пока займусь другими задачами
4. спрошу у лида
Ожидаемый ответ: 1 или 2

Собрали релиз, в который вошло множество фич, багфиксов и рефакторинга. Поняли, что в релизе есть новый баг, который затрагивает менее 1% пользователей. Что делать?
1. будем фиксить, снова все тестировать, в итоге отложим релиз на 1–2 дня, а возможно и больше
2. катим, но сразу фиксим и готовим новый релиз
Ожидаемый ответ: 2

Как лучше поступить при написании новой фичи в текущем большом проекте?
1. начну сразу делать фичу, после ее разработки/внедрения буду рефакторить проект
2. проведу небольшой рефакторинг, потом сразу буду делать фичу
3. буду рефакторить, пока не пойму, что код новой фичи хорошо ложится в текущий проект
Ожидаемый ответ: 2 или 3

Микросервис, с которым взаимодействует твой проект, изменил что-то в текущей интеграции по API, тем самым сломав ее. Изменения небольшие, и ты можешь сам пофиксить проблему на своей стороне. Что делать?
1. напишу ребятам, что они все сломали, и пусть чинят
2. напишу ребятам, что они все сломали, но починю у себя, тк это быстрее
Ожидаемый ответ: 2

Буквально вчера вышла новая версия языка, на котором написан твой проект. В ней есть множество киллер-фич, которые тебе очень нужны, но просто так обновиться нельзя, так как есть легаси-библиотеки, которые ее не поддерживают. Что делать?
1. всё, пора! Хватит это терпеть! Буду просить у лида время на обновление до новой версии
2. 5 лет терпели и еще 5 потерпим, а потом уже и работу сменю
Ожидаемый ответ: 1

Пока кто-то сокращает, мы нанимаем, открываем новые направления и рынки для бизнеса.

Новости на этой неделе.
- На рынке говорят о том, что крупные компании сокращают штат IT-шников. А ритейлер «Золотое Яблоко», наоборот, рассказал о планах нарастить пул таких специалистов.
- С массовыми сокращениями не всё так плохо — обнаружил, что в Золотом Яблоке открыто 30 вакансий, на которые планируют нанять 150 (!) человек.
- "Золотое Яблоко" планирует расширить штат IT-специалистов на 25%. Кажется, ритейлер готовится к серьёзному усилению в диджитале.
- «Золотое Яблоко» расширяет ИТ-штат на 25%
- «Золотое Яблоко» на четверть увеличит штат IT-специалистов

Чтобы вам было проще, вот мои вакансии в Ecom или пишите мне (@arxell) c ссылкой или c файлом на ваш CV, я перешлю кому надо.
- ios / android
- Middle .NET developer / Senior .Net developer
- Middle Fullstack QA / Senior Fullstack QA
- Системный аналитик
- Frontend developer Vue

Также ищем TeamLead'ов команд разработки, которые отвечают за delivery-процесс в своей команде по доставке ценностей для клиентов, метрики, планирование т.д. и т.п. что описано тут.