Если сотрудники должны уменьшать головную боль своего руководителя, то что должен делать руководитель?

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

Но часто руководители остаются разработчиками с нагрузкой руководства. Они забирают себе неинтересные задачи, оставляя команде самое вкусное. Это тормозит развитие как руководителя, так и сотрудников. Руководитель вечно занят, но свою роль не выполняет.

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

Освобождайте время для стратегических задач вида:
- подготовки новых проектов и зон ответственности;
- разработки технологической стратегии;
- роста и позиционирования команды;
- внедрения DORA метрики :)

#руководство

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

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

После такого откровения больше половины младших специалистов предпочитают искать советы где-то еще и иногда за пределами нашей компании. Увы :(

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

Быстрее делайте свои текущие задачи и жадно набирайте новые.

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

Фактически вы просто ускоряете свою личную релизную трубу:
1. Быстрее шипите типовые задачи в продакшен.
2. Руководитель дает вам все больше задач.
3. В итоге вы делаете все более разнообразные задачи.
4. Опыт и экспертиза накапливаются.

И как результат — неизбежно становитесь опытным разработчиком или "мидлом".

Поэтому, если вы — младший специалист, то не мучайте руководителя составлением индивидуального плана развития, а просто фигачьте :)

#карьера

Если младшему специалисту достаточно фигачить, то с более старшими специалистами такой трюк не пройдет. Делать только текущие задачи — недостаточно, нужно научиться делать другую работу.

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

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

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

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

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

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

И помнить, что запуск сервиса — только начало пути :)

Пункт № 3. Прозрачность
- организация и координация работы команды в случае необходимости;
- умение выделить MVP для более быстрой поставки в продакшен;
- понятный контекст работы для своей команды, руководителя и смежников.

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

А рассказывать статус по проекту с нужным уровнем абстракции для разных потребителей — высочайший полет в менеджменте, к которому нужно стремиться!

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

#карьера

— Какова вероятность встретить на улице динозавра?
— 50%. Либо встречу, либо нет.

Яндекс. Пятница.

#яндекс

Год назад я писал заметку про то, что когда становишься руководителем, то очень многое меняется.

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

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

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

Ну если вы, конечно, хотите стать хорошим руководителем.

#руководство

В своей книге Форма жизни №4 Евгений Черешнев привел вызывающие волнение расчеты:

Если читать весь день от заката до рассвета, по 12 часов, то, вероятно, можно осилить одну книгу приличного размера в сутки (сознательно упрощаю расчеты). В год удастся прочитать 365 книг, если ничего больше не делать. Если читателем вы заделались лет в 10, то 25 000 книг за жизнь — это предел. Не будем отрываться от реальности — вспомним о работе, учебе, семье, телевизоре, отведем 10 000 часов на то, чтобы стать профессионалом в какой-либо области, добавим немного времени на другие занятия — и окажется, что в жизни здорового человека отведено место примерно для 1000 книг. Всего 1000!!!

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

Из телеграмм-папки «Пашем-пишем» я узнал, что мой коллега Артем Сайгин ведет канал Growth Lab про рост IT-продуктов. Мы обсуждали ведение каналов, саморазвитие и чтение. Выяснилось, что чтение тоже можно растить, как и IT-продукты :)

Артем развил привычку, которая позволяет ему читать до 800 часов в год! Это результат системного подхода, набора лайфхаков и силы воли.

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

Мой результат скромнее. Я читаю в дороге и перед сном, выходит примерно 300-400 часов в год.

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

А вы много читаете? Какие лайфхаки используете? Как выбираете следующую книгу?

#лайфхаки

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

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

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

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

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

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

Речь идет про Continuous Integration (CI). Существует множество систем CI: Teamcity, Jenkins, Bitbucket Pipelines, AWS CodePipeline, GitLab.

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

Если вы придете в компанию, например, в Яндекс с самописным CI, глубокие знания Teamcity не особо помогут. А правильное высокоуровневое видение всегда полезно.

#разработка

В мире разработки утки – особые герои. Не уступают гусям ;)

Разработчики часто применяют утиную типизацию в слаботипизированных языках, а точнее утиный тест:

Если объект выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, и есть утка.

То есть достаточно, чтобы объекты поддерживали необходимый набор методов. Это позволяет работать с ними независимо от иерархии наследования.

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

Проверял на себе, это правда работает. Только я объяснял свои решения нашему лосю :)

Всем любителям уток рекомендую канал моего коллеги – Музей уток #yanducks. Такого разнообразия уток вы точно ещё не видели!

#разработка

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

Для развития руководителей есть похожая карта — Teamlead Roadmap. Опять же повторюсь, что не нужно слепо следовать таким картам. Используйте их как источник вдохновения и корректировки своего развития.

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

In my experience it's very difficult to achieve all of this simultaneously, but a reasonable thing to strive for.

Идеальным руководителем стать нельзя, но стремиться к этому точно можно и нужно ;)

#руководство #карьера

Геосервисам исполнилось 20 лет! Как время летит! Успехов и новых свершений всем нам!

#гео

В конце прошлой недели с коллегами обсуждали "тяжелую долю" руководителей.

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

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

Давайте обсудим это чуть подробнее.

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

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

Но стоит помнить, что снижение в одной области компенсируется ростом в другой. Руководитель меньше пишет кода, но БОЛЬШЕ его читает и видит БОЛЬШЕ различных решений. Условно, если разработчику опыт приезжает по дороге, то в руководителя опыт летит с многополосной автострады :)

Если руководителю придется писать больше кода, то поначалу он может уступать в скорости разработчикам, но через какое-то время разница в скорости написания кода нивелируется. Практика сделает свое дело.

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

Такие размышления успокоят не всех. Поэтому я рекомендую начинающему руководителю провести эксперимент:
1. Освободить себе 1 день в календаре.
2. Выключить мессенджер.
3. Погрузиться в детали какого-то проекта.
4. Выкатить правку в тестинг.

Так можно увидеть, что страхи преувеличены, и успокоиться ;)

#руководство

Сегодня мы запустили «Геоаналитику» — бесплатный инструмент для изучения потенциала районов города на основе геопривязанных данных о трафике и поисковых запросов из Яндекс Карт.

Мы считаем, что «Геоаналитика» поможет определить перспективные места для открытия точек продаж, складов и других объектов. А еще мы впервые открыто поделились уникальными на рынке данными по пешеходному и автомобильному трафикам, чтобы помогать предпринимателям лучше оценивать количество потенциальных клиентов или найти подходящие зоны для застройки и рамещения рекламы в городе.

«Геоаналитика» — это не только полезный и бесплатный сервис, но и красивый инструмент. Кликать по гексагонам на карте своего города — очень увлекательно!

#новости

На первом курсе мой сосед по общежитию (6-й курс) посоветовал мне: "Вместо игр учись слепой печати. Пригодится. Потом поймешь".

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

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

Но самое важное, что фокус внимания переключился на то, что я делаю, а не как делаю. "Мы не служим клавиатуре. Это сервисное действие" :)

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

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

P.S. Забавно, но я не знаю расположение клавиш. Если начинаю смотреть на клавиатуру, скорость печати падает. Однако когда доверяю механической памяти, все идет отлично. 🙂

#лайфхаки

Давненько не было баек. Пора это исправить! Расскажу вам, как я сломал Яндекс Карты :)

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

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

Вот мы и доходим до выпуска в продакшен. Заливаю debian-пакет на прод, открываю maps.yandex.ru, а там — сюрприз: только шапка, пустота вокруг и карты как не бывало.

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

Оказалось, что скрипты postinstal debian-пакетов изрядно нам подпортили жизнь. Разработали фикс, запустили его на весь кластер, и проблема ушла.

Фууух, можно выдохнуть и на свежую голову подумать, как предотвратить такое в будущем. Ведь в тестовом окружении всё было окей, а проблема всплыла только в продакшене.

Решили, что нам нужен промежуточный этап — вот и появилось окружение prestable. Сначала выкатываем сервис туда, смотрим, как работает сервис, и если всё гладко, то потом выкладываем в продакшен. И даже если что-то пойдет не так в prestable, пострадает лишь часть пользователей, а не все.

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

Что ни говори, а опыт оказался бесценным. И созданный prestable не раз выручал нас, спасая пользователей от неудачных релизов. Как говорится, «кто продакшен не клал, тот настоящей жизни не видал». Ошибки — часть обучения, не так ли? 🙂

#байки #инциденты

Книга — лучший подарок, особенно если это SRE. Рецепты выживания в продакшне для инженера по надежности Наташи Савенковой. Мне посчастливилось получить её от самого автора.

Эта книга — квинтэссенция опыта из жизни яндексового SRE, без лишней воды, кратко и по делу.

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

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

Книга — компактная и легко читается за вечер. Рекомендую её всем, кто стремится к повышению надёжности своих сервисов.

#книги #инфраструктура

Нашел свой пост в этушке от 2012 года про измерение своей эффективности с помощью отчета "Created vs. Resolved" в Jira.

Нужно было делать так, чтобы зеленого (решенного) было больше, чем созданного (красного).

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

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

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

Но, конечно, важно не только СКОЛЬКО вы решаете задач, но и КАКИЕ именно и с КАКИМ качеством.

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

#карьера

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

Hit two birds with one stone ;)

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

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

Курс рекомендую. Если еще делать домашнюю работу и самостоятельно прорабатывать пройденный материал, то будет совсем хорошо.

P.S. Вообще может уже пора китайский учить?

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

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

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

Самый эффективный способ — чётко разделять зоны ответственности и адаптировать их в процессе развития сервисов. Только так один административный руководитель сможет синхронизировать развитие разных сервисов.

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

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

#разработка

Разговаривал на работе про span of control и захотел поделиться с вами.

Span of control (SOC) — это количество неруководителей поделить на количество руководителей, т.е. этот коэффициент показывает среднее количество прямых подчиненных у руководителя.

Выделяют два вида организаций:
1. Иерархичные (tall) — низкое значение SOC.
2. Плоские (flat) — высокое значение SOC.

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

Значения SOC у крупных компаний не являются публичной информацией, но утверждается, что компании с высокой капитализацией (такие как Google, Netflix, Microsoft) придерживаются плоской структуры.

Если равняться на техногигантов, то нужно стремиться к значению SOC в районе 6-12.

Вот поэтому наши hr не согласовывали создание подразделений меньше 5 человек. Чтобы растить SOC и вместе с ним эффективность.

#руководство

Одна из основополагающих технологий в картах — геокодирование. Она распознает геокоординаты и преобразует их в адреса или наоборот. В наших сервисах она представлена продуктом Геокодер.

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

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

Сегодня в Казахстане мы запустили новую версию Геокодера с улучшенным поиском мест. Теперь решение работает на базе искусственного интеллекта и алгоритмов машинного обучения. Внешний интерфейс у него остался неизменным, но благодаря новым "мозгам" Геокодер на ИИ научился лучше обрабатывать неструктурированные запросы с опечатками и ошибками. Полнота ответов и скорость обработки запросов выросли. Соответственно, инструмент теперь способен лучше помогать местным компаниям работать с адресными данными.

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

Так что если вы в Казахстане и используете наш Геокодер, то вам никуда переезжать не надо. Вы уже пользуетесь Геокодером на ИИ 😉

#новости