Про форматы сплочения команд на удаленке (часть 2)

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

Мы в практике применяем пару регулярный вещей, в той или ной степени смешения прижившихся в разных командах:
Курилка (политкорректное - "мит у кулера"). Это общая видеоконференция, в которой по желанию, в течение дня находятся ребята из команды. Эффект у курилки наиболее близок к реальному офису: можно прямо сейчас задать вопрос и тут же получить ответ. Особенно ценна курилка для новичков, которые могут получать помощь не только от своего наставника, а от всей команды.
Беды с башкой (политкорректное - "час тимлида"). Необязательная к посещению регулярная, обычно ежедневная, часовая встреча с тимлидом по рабочим и не очень вопросам. Плюс в том, что такая встреча есть у тимлида в календаре и она с максимальной вероятностью состоится, а команда сможет решить вопросы с тимлидом и что важно, друг с другом не дожидаясь будущего дэйли.

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

И, как обычно, оба варианта сразу - самое идеальное решение.

Продолжение следует...

Про форматы сплочения команд на удаленке (часть 3 и пока последняя)

Казалось бы, предыдущий пост исчерпал тему, закрыв рабочий день, но по мере работы по циклическим моделям планирования (каковыми и scrum, и kanban-метод, и их производные являются) со временем у любого человека появляется ощущение "белки в колесе". Вот тут бы про WLB поговорить, и мы обязательно поговорим, но потом. А сейчас про технологии (да, я официально этим постом присваиваю себе термин "технологии создания командной культуры"), которые помогают отслеживать прогресс себя любимого и команды.

В SCRUM есть ретроспектива, одна из целей которой именно такая: подвести итого, отметить что получилось, что нет и зафиксировать прогресс ДЛЯ КОМАНДЫ.
Если же вы используете ту или иную производную kanban-метода, то у вас может и не быть ретро (или его аналога), а потребность делать отсечки прогресса есть.

Мы в разное время применяли чуть разные технологии для этого:
- ежемесячные отчеты. Конечно, отчётами в общем понимании это не было. Обычно ПМ команды готовил презентацию с самыми яркими вехами прогресса по всем проектам команды в первой части; обзором вовлечения в разные проекты инженеров и какими-то личными новостями ребят. А потом, без жёсткого расписания, обычно на дэйли по мере готовности вместе смотрели эти графики, цифры и веселились над скилами ПМа по созданию всратых презентаций.
- еженедельные новости + рассказ. Это более "технология", чем отчёты. В понедельник на рулетке выбирается кто-то из команды, выигравший в течение недели готовит рассказ на свободную личную тему: иногда с презентацией, иногда просто с фотками, был опыт трансляции во время поездки по улицам и трансляции ретроигр. Что за темы? Да что угодно! Я уже упомянул ретроигры и рассказ о своем городе, были рассказы о путешествии куда-то, о своих увлечениях (чего только не было: разный спорт, ролевые игры, автомоделирование) и так далее. Вторая часть начинается в пятницу: менеджмент готовит краткие новости по прогрессу по проектам команды и на дэйли рассказывает его, а после этого выигравший рассказывает о том, о чем хочет (с таймингом около 1 часа). Надо оговориться, что рассказ бывает не всегда: его могут не успеть подготовить в силу отсутствия времени или других личных обстоятельств, а вот новости - элемент обязательный, его никогда не пропускают.

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

Про технотекст или ещё раз про прогнозирование сроков

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

https://habr.com/ru/articles/789414/
https://habr.com/ru/companies/tinkoff/articles/782012/

Про начальников-дураков

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

Учитывая что у нас с вами канал для менеджеров, я бы перефразировал "как не быть дебилами-управленцами" ?

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

А вы что думаете?

Рекомендую прекрасную книгу на тему: "45 татуировок менеджера" Максима Батырева.

Про систематизацию

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

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

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

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

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

А как считаете вы?

Про язык команды

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

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

Хотел тут акцентировать внимание ещё на один момент: на гендерные различия в языке. Например, если в вашей команде появилась женщина (как ни крути, а в IT по большей части работают мужчины) и, внезапно, в общении с ней вся команда перестает использовать мат, то несмотря на то, что мы живём в традиционном обществе, на уровне подсознания такой член команды будет ощущать себя чужаком и всеми другими будет несознательно считаться чужим причем именно на языковом, а не на гендерном уровне.

Рекомендую очень интересный доклад на тему женского ИТ от Андрея Бреслава https://youtu.be/NmeG66pCq7Y

Есть ли у ваших команд языковые особенности?

Взять и переложить ответственность

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

С моей точки зрения, ответственность - это многозначный термин, который, впрочем, подразумевает одно и тоже: обещание или поручительство за достижение результата. Откуда тогда многозначность? Давайте поясню:
- подвид #1: длящаяся ответственность. Самый простой пример - это ответственность за своих детей. У нее нет "окончания", насколько взрослыми не стали бы дети. Где-то здесь же находится ответственность за успех команды или компании в целом на протяжении всей ее жизни.
- подвид #2: атомарная ответственность. Например, ответственность за результат конкретной задачи и проекта.

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

И, по результатам (финальным в случае атомарной и периодическим, например квартальным, в случае длящейся ответственности) руководитель разделяет с командой результат: хороший или плохой, не важно.

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

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

Не претендую на полноту и буду рад продолжить в комментариях.

Про hr-бренд

Привет. Продолжаю разбор статьи про дефицит персонала и сегодня предлагаю поговорить о тезисе номер 4: "Мало кто хочет работать в серой, никому не известной компании".

Казалось бы, тезис очевидный: все в отрасли хотят работать в Google и никто в ООО "Вектор". Кроме директора ООО "Вектор", конечно же. Давайте разберемся, так ли это на самом деле?

Ну, пожалуй с первой частью "все хотят работать в условном Google" я могу согласиться, но и у маленьких и никому неизвестных компаний все не так плохо. Потому что кандидаты тоже не одинаковые, раз. И Гуглу столько (и таких) не нужно, два. А расти до "таких" тоже надо, принося попутно пользу (и иногда - вред) компаниям поменьше Гугла, три.

Следующий аспект касается собственно построения HR-бренда. Это работа непростая, решается разными компаниями по-разному. Я не имею в виду лидеров ранка, скорее говорю про небольшие компании и стартапы. Кто-то активно участвует в OpenSource-сообществе и это привлекает энтузиастов, иные фокусируются на одной отрасли компетенций и вкладываются а технологический маркетинг, зарабатывая себе вес в данной отрасти в сообществе. Так, например, Флант сначала больше шел первым путем, потом и теперь - вторым.

Есть ещё путь золотой антилопы (просто сметать с рынка всех бОльшими, в сравнении с конкурентами, зарплатами), так поступал, например, Сбер на пике рынка в 2020-2021 годах, да и сейчас не брезгует. Но это путь не самых маленьких компаний.

А что привлекает вас в HR-брендах компаний?

Про тестовые задания для менеджеров

Нужно или не нужно делать тестовые задания? Насколько подробные? А для менеджеров? Оплачиваем не оплачиваем?

Так много вопросов и у меня есть история на тему из практики: когда-то у нас было длинное задание на 8-9 часов (и для инженеров, и для менеджеров). Оно, само по себе, было фильтром: те, кто соглашался делать 8-часовое задание в массе своей были с Флантом дольше, качество отбора было выше. Ну и качество собственно выполнения и процесс работы на заданием тоже давали возможность лучше понять кандидата.

Когда мы начали расти активно большое входное задание сильно срезало поток. Мы его уменьшили. Да, задания стало проходить легче, это меньше пугало, но "фильтровать" теперь приходится на других этапах. Хорошо, если отсеяли на техническом интервью, хуже, если на испытательном сроке.

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

Лично я твердо уверен, что тестовые задания обязательны: продавать себя должны уметь только кандидаты в отдел продаж, а раскрыть остальных - задача интервьюеров. И валидация заданий тоже нужна (мы ее, кстати, для менеджерских вакансий ввели в минимальном объеме).

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

А тем, кто ждёт оплаты за тестовые задания, предлагаю рассмотреть вакансии без тестовых (ну или где платят, если найдёте). Не скажу за всю отрасль или даже за весь Флант, но моей команде с такими ребятами не по пути.

Ребята, делюсь с вами радостью.

Классные ребята из Т-Банка выпустили в релиз документацию по OKR, которую я когда-то с командой Т-Кассы готовил. Вышло так, что я перешёл в Яндекс раньше, чем документация добралась до публикации - так что пользуясь случаем поблагодарю людей, которые эти доки всё-таки дотащили)

Пользуйтесь, мы эти статьи готовили, чтобы они несли пользу не только в Т-Банке , но и всем коллегам в индустрии
https://www.tbank.ru/it/tools/okr/

Ну и тогда опрос

Компания не семья

Однажды наш, Фланта, бывший сотрудник написал отзыв на hr-портале, где сказал, что мы пытаемся строить "бирюзовую псевдосемью". И хотя я не понимал, чем именно псевдосемья отличается от той культуры, что была у нас (довольно теплая, скорее дружеская чем семейная), меня лично этот отзыв насторожил.

Потом на сайте ребят, которые придумали ruby on rails и Basecamp, нашел вот такое определение: When companies say they’re a family, it’s a veiled way of demanding total sacrifice. Nights, weekends, whatever it takes for, you know, “the family”. Очень понятно и четко. И да, мы не требовали никогда жертвенности во имя чего бы то ни было (и вообще за WLB, и когда-нибудь я напишу об этом пост).

По ссылке можно прочесть сигнал о компании_не_семье целиком, а по этой и другие сигналы тоже (которые по своей сути - набор ценностей, и про ценности я напишу когда-нибудь также отдельный пост).

#чтивонавыходные

Про тупую работу (и развитие)

Привет. Продолжаем разбор тезисов из статьи про дефицит кадров. Сегодня тезис номер 5: "Мало кто хочет выполнять тупую работу годами без роста и развития". И, хотя автор опять переносит нас в HR повестку, я вижу тут два разных тезиса:
1. мало кто хочет выполнять тупую работу;
2. мало кто хочет работать годами без роста и развития.
И это две разных проблемы из разных миров.

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

По второму тезису: какой бы крутой не был HR, рост и развитие (профессиональное) зависит больше не от него, а от (внезапно!) желания самого человека и условий для развития, которые ему создали ИТ-руководители. В планах у меня есть несколько публикаций про то, как мы развиваем людей на уровне команды.

После всего сказанного может показаться, что роль HRа была преуменьшена, но это не так. HR создаёт и совершенствует систему развития, согласно которой уже действует ИТ руководство и сами сотрудники.

Что вы думаете про тупую работу? Много у вас её в ваших командах? Как боретесь?

Про смыслы

Привет, сегодня на очереди ещё один тезис из статьи о кадровом голоде: "Мало кто хочет работать без смысла. А в России это норма. Вот существует компания без миссии и ценностей, деньги зарабатывает".

Я разделяю точку зрения автора, в целом. В этом месте так и подмывает затянуть сказ про поиски смысла жизни в классической русской литературе, вспомнить, к примеру, "Бесов" Федора Михайловича и образ маленького человека из "Шинели" Николая Васильевича.

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

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

А бывает и так, что люди работают просто ради денег. А миссия и ценности у них сформулированы в сторону семьи или, например, рыбалки. И вообще им плевать на все эти корпоративные развлечения. Но, по моему опыту, в ИТ таких немного.

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

А в ваших компаниях миссия и ценности сформулированы?

Про bus factor

Как известно, понедельник - день тяжёлый, потому предлагаю начать неделю с темы простой, заезженной и вроде как всем понятной: bus factor, он же фактор автобуса, он же фактор кирпича.

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

Каковы пути снижения рисков bus factor? Видится, что их два с половинками:

1) распространение знаний, например путем создания документации. Таким видится, наверное, традиционный путь в ИТ
1.5) а ещё можно нанять больше людей и сделать дублирование знаний "в головах". К сожалению, лишь там где это экономически обосновано.

2) снижение сложности задач. По этому пути пошел, в свое время, Генри Форд, разложив сложный технологический процесс сборки автомобиля на простые конвейерные операции.
2.5) Вряд ли можно совсем уж упростить до конвейерной операции процесс создания инновационных продуктов, каковым ИТ и является, зато можно универсализировать инструментарий (стэк, если хотите) таким образом, чтобы готовые "универсальные" инженеры могли заменять друг друга.

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

Отсюда рождает простой и универсальный метод: упрощай то, что можно упростить, остальное - документируй.

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

А вы как нивелируете bus factor у себя?

Про продолжительность дэйликов

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

Для начала предлагаю обратиться к известным практикам и узнать, что уже придумали до нас. А до нас в скрам гайде написали, что стендап (в последней редакции - daily scrum) длится до 15 минут. Откуда взялось ограничение? Дело в том, что в SCRUM у вас в спринте конечный бэклог, определена цель спринта, и, по хорошему, последовательность выполнения и для продумывания этого плана есть отдельное событие (Sprint planning, длина которого не определена), а на дэйли команда лишь обозначает точку, в которой находится сейчас (по заранее определенному плану).

Каденции в канбан не регламентированы по времени. Как раз потому, что поток работы не определяется заранее, а определяется лишь "ширина трубы", по которой он льется в WIP limits.

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

Рассказ, при этом, никак не противоречит оставлению письменных артефактов: комментариев, документации, IaC-сценариев. И даже помогает. Но сами по себе письменные артефакты не решают проблему так эффективно, как рассказ + письменные артефакты.

В обратную сторону, чем более простая, конвейерная работа у команды, тем короче будут "летучки" и письменные артефакты. Предположим, рабочий на конвейере в качестве артефактов заполняет журнал смены, в котором обычно лишь две цифры: общее количество деталей (=работы) и количество брака.

Какой длины утренние дэйли у вас? Пишите в комментариях.

Про оценку работы

Привет. Это будет суперкороткий пост.

В чём разительное отличие оценки в офисе и на удалёнке?

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

А вы как считаете?

Про второе мнение

Привет! Сегодня предлагаю поговорить о втором мнении как о практике менеджмента.

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

Так и в управлении сложными системами, такими как ИТ, сложно единолично принимать решения, даже на уровне команды, а тем более всего предприятия. Потому практики второго мнения в ИТ распространены широко.

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

Есть ещё вариант, когда практика использования второго мнения используется в качестве процесса. А разработке это, например, различные практики кодревью.

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

А вы используете практики второго мнения у себя?

Нанять или вырастить?

Пятничный привет от рубрики #чтивонавыходные

Сегодня порекомендую сочную статью от ребят из Ламоды с обоснованием, отчего они предпочитают нанимать джунов и "выращивать" из них высококвалифицированных специалистов https://habr.com/ru/amp/publications/774416/

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

На закуску там же есть оценка рисков и минусов подхода.

Пожалуйте в комментарии, чтобы обсудить статью!

Про новую нефть

Привет, это предпоследний пост с разбором тезисов статьи про дефицит кадров. И сегодня предлагаю обсудить тезис 9: "Редко, где персонал — это главная ценность компании".

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

Не подумайте, это не значит, что в ИТ нет компаний, в которых сотрудников не ценят, где другие ориентиры. Конечно они есть, навалом. Но рынок труда для ИТ настолько дефицитный, что найти работу в адекватной компании нет вообще никаких проблем, причём для любого уровня квалификации. И рейтинги таких компаний тоже есть. Например, вот такой
https://habr.com/ru/specials/773642/

Ох, тема конечно, холиварная, так что готов продолжить в комментариях.