Про руководство разработчиками | Олег Мохов @teamleading Channel on Telegram

Про руководство разработчиками | Олег Мохов

@teamleading


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

Для рекламы и связи: @olegmokhov

Про руководство разработчиками (Russian)

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

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

Присоединяйтесь к каналу "Про руководство разработчиками" (@teamleading) и узнавайте, как создать эффективную команду разработчиков, выстраивать процессы и достигать успешных результатов в своей работе. Для рекламы и связи с автором канала обращайтесь к Олегу по контакту @olegmokhov.

Про руководство разработчиками | Олег Мохов

24 Jan, 13:53


Кстати, в тему GPT и роботов вспомнилось что в фильме «Приключения Электроника» был эпизод, когда Сыроежкин принёс решение задачи по математике, которое не смог объяснить. Вот это вот знаменитое: «Интрегал!».

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

© Одесская киностудия

Про руководство разработчиками | Олег Мохов

23 Jan, 20:45


GPT — добро или зло для студентов?

Сегодня весь день принимал экзамен у студентов по JavaScript. Уже к середине экзамена я понял: практически никто из студентов больше не пишет код самостоятельно. И это не даёт мне покоя. Степень использования GPT варьируется от «я посмотрел и разобрался, что она предлагает» до «списал подчистую».

Ощутил себя Стояновым из недавно подсунутого мне Reels, где он, в роли преподавателя, сетует на то, что люди теперь даже 2+2 с калькулятором считают.

Обнаружить GPT не всегда просто, конечно сразу видны нулевые знания, но есть и забавное наблюдение. Даже на простую задачу GPT может написать избыточный код. Например, у студента задача — реализовать аналог Promise.all с небольшими доработками. GPT выдаёт код, где есть такое: promises.forEach(promise => Promise.resolve(promise)). Я спрашиваю: «Зачем тут нужен resolve?» — ответа нет. Потому что в условии нигде не сказано, что массив promises может содержать не только промисы, но GPT перестраховывается.

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

С другой стороны, ко мне приходят люди, которые говорят: «Я хочу стать разработчиком». И они… ну, совсем не дотягивают.

Что вы думаете? Может, есть идеи, как грамотно и органично вплести GPT в обучение? Или как лучше подготовить студентов к жизни в мире, где такие инструменты становятся частью повседневной работы?

Изображение к посту © Walt Disney Company

Про руководство разработчиками | Олег Мохов

20 Jan, 11:18


Лайфхак: в книге описаны не все страны, да и возвращаться к ним лень, но можно попросить GPT оценить человека из конкрентной страны и получить неплохое описание:


I have a meeting with a colleague from COUNTRY, please, tell me how they usually communicate, according to The Culture Map book:

- Communicating: low-context vs high-context
- Evaluating: direct negative feedback vs indirect negative feedback
- Persuading: principles-first vs applications-first
- Leading: egalitarian vs hierarchical
- Deciding: consensual vs top-down
- Trusting: task-based vs relationship-based
- Disagreeing: confrontational vs avoids confrontation
- Scheduling: linear-time vs flexible-time

Про руководство разработчиками | Олег Мохов

20 Jan, 09:06


Карта культурных различий или что там дальше в книге про Netflix?

Я разобрал главы с 1 по 5 книги про Netflix (1, 2, 3, 4 и 5). И перестал дальше писать, почему? Если коротко, то главу 6 я разобрал уже здесь и добавить к этому всему можно лишь то, что в Netflix принятие любого решения остаётся за сотрудником. За этим стоит большая ответственность, которую все сотрудники осознают.

Главы 7-9 я разбирать не буду, так как глубже на схожую тему есть отдельная книга «Радикальная прямота». И её мы тоже разберём в ближайшее время.

Интересна последняя 10-я глава, где рассказывается про культурную карту. Что же это такое?

Ну, во-первых, Эрин Мейер в итоге написала аж целую книгу про культурные карты, а если не хотите читать книгу, то вот TL;DR статья авторством той же Эрин.

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

С другой стороны эта глава про фреймворк, по которому вы можете понять какова ваша команда и как в ней принято. Критиковать — в лоб и прямо или деликатно? А тимлида у вас принято беспрекословно слушать или спорить с ним до посинения? А план как соблюдается — чётко или аджайл во весь рост?

Тут нет хороших и плохих характеристик, а есть фреймворк для самоопределения. Культура здесь скорее может задать базовый контекст, например в картинке к посту приводится срез по двум странам Россией и ещё одной, попробуйте угадать где Россия и что за вторая страна? (Ответ: Россия — жёлтая, вторая страна — Израиль).

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

Про руководство разработчиками | Олег Мохов

19 Jan, 08:04


Сайт с картами навыков в IT — https://roadmap.sh/roadmaps. Степень глубины там прямо очень большая, но если кажется что спустились до уровня атомов всегда можно укрупнить.

Про руководство разработчиками | Олег Мохов

18 Jan, 08:59


Кстати, для тимлидов карту навыков уже составили. Спасибо Стасу, Егору и сообществу.

Про руководство разработчиками | Олег Мохов

14 Jan, 10:54


Налетайте за хорошей книгой
(пока есть)

Прямо сейчас я читаю эту книгу на английском и всё хотел заполучить печатный формат на русском. Я сделал запрос в издательство Питер и мне его заапрувили, буквально с сегодняшнего дня отпечатали и готовы распостранить 200 экземпляров книги «Делай как в Google».

Мы с Сашей Поломодовым недавно переписывались и оба сошлись на мнении, что название не отражает сути книги. В английском варианте книга называется Software Engineering at Google и лучшим переводом могло бы быть «Разработка в Google».

Anyway, книга состоит из глав, где сконцентрирован опыт компании Google в разных частях процесса создания продуктов. Это не только описание того как и что работает, но и рефлексия, что работает хорошо, что Гугл попробовал и в итоге прекратил использовать. Короче, книга максимально интересная для прокачивания инженерной культуры в вашей компании, а по промокоду «Бумажная» вы ещё и скидочку получите аж 40% (предложение до 26 января). В общем, если вы такой же фанат бумажных книг как и я, то налетайте

Про руководство разработчиками | Олег Мохов

13 Jan, 06:32


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

Про руководство разработчиками | Олег Мохов

13 Jan, 06:32


Думай за рамками

Все деловая и мотивационная литература заполнена через край советами "думать за рамками" и "делать не как все".

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

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

В чем же подвох? Почему так много примеров успешных людей, которые "думали иначе"?

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

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

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

Про руководство разработчиками | Олег Мохов

10 Jan, 07:14


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

Сегодня ночью товарищ под ником Nifsky во время стрима с 17055 (!!!!!) попытки поставил практически финальный мировой рекорд по скоростному прохождению Марио.

Финальный уровень 8-4, его пульс и итоговые эмоции можно оценить на видео.

p.s. Теперь в спидранах Марио осталось всего 100 миллисекунд для абсолютного рекорда, если конечно не найдется ещё какой-нибудь хак как сэкономить время.

Про руководство разработчиками | Олег Мохов

09 Jan, 07:01


Нанять лучших в своём деле

— Какими качествами вы обладаете?
— Я упорен и стрессоустойчив
— Как докажете?
— Я спидранил Марио и побил мировой рекорд на 16 735 попытке.
— Вы приняты!


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

В найме российский IT свято придерживается экзаменационного догмата. И если в компаниях масштаба Яндекса и Озона это объяснимо — спрос выше предложения (про эффективность можем порассуждать, но думаю ничего нового мы не выведем — это не эффективно и отбраковывает сильных ребят). Но вот что удивительно, так это когда в компанию размером до 100 человек предлагают пройти несколько секций. То есть как будто бы кадрового дефицита нет? Или так проще? Очень интересно было бы услышать мнение небольших компаний на этот счёт.

Я лично ищу способы нанимать людей без собеседований. Например, хороший github, или опыт работы у знакомого мне тимлида — всё это повод скипнуть большую часть испытаний для разработчиков и сосредоточиться на behavioral interview.

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

Хорошего продуктового аналитика можно найти среди аспирантов физических (и прочих научных) факультетов, так как флоу работы «гипотеза - проверка - анализ» у физиков и аналитиков совпадают.

Это три примера того, когда есть конкретный опыт, который важнее экзаменационной оценки.

А какие вы знаете примеры говорящих строчек из резюме?

Про руководство разработчиками | Олег Мохов

06 Jan, 07:18


Книги 2025

Заглянем в будущее, на год вперед. Вот четыре книги, которые я точно прочитаю в новом году. Удивительно, но книга это снова отличный подарок, как минимум мне точно! Спасибо, жене, маме и подруге жены!

Про руководство разработчиками | Олег Мохов

01 Jan, 15:26


Книги 2024 и моя оценка.

1. Рейнвотер «Как пасти котов». 8/10.
Не стареющая классика

2. Шиманская «Детская агрессия». 7/10.
Лёгкая, утащил пару лайфхаков.


3. Кумай «Кинцуги». 5/10.
На 2/3 кулинарная, на 1/3 про кинцуги. Тема скорее не раскрыта.

4. Каган «Вдохновленные: Всё, что нужно знать продакт-менеджеру». 6/10.
Книга набор векторов на будущее, с хорошей библиографией.


5. Прохоров «Русская модель управления». 9/10.
Эта книга не идеализирует управление, как остальной бизнес-лит, а рассказывает что и как работает именно в РФ

6. Франкл «Сказать жизни "ДА!": психолог в концлагере». 5/10.
Впечатляет, но ожидания были больше.

7. Триз. Как решить любую проблему (не Альтшуллер). 2/10.
Так много слышал про триз, а оказывается это просто набор методик как крутить проблему. Конкретно в данной книге именно он, и ничего более. Первоисточник, вероятно, интереснее.

8. Стэньер «Карьера Software Engineering Manager». 10/10.
Эта книга — готовый гайд для начинающих тимлидов.


9. Тургенев «Бежин луг». 6/10.
Погулять по лесам

10. Иота «Она не объясняет, он не догадывается. Японское искусство диалога без ссор». 7/10.
Методология интересная

11. Братья Стругацкие «Понедельник начинается в субботу». 11/10.
Читаю каждый год

12. Клеппман «Высоконагруженные приложения». 9/10.
Классика, маст рид для архитекторов


13. Фельдберг, Лошманов «Nordic Dads». 5/10.
Книга про равенство отцов. Интересна та часть где рассказывают про законы про отцов в Nordic-странах.

14. Берн «Люди, которые играют в игры». 2/10.
Разочарование года, очень много мутной психологии, не для рядового читателя точно. Мне не зашла совсем

15. Гладуэлл «Гении и аутсайдеры. Почему одним всё, а другим ничего?». 9/10.
Много классных примеров про то когда случай, на самом деле не случай.


16. Хэнчетт «Vue.js в действии». 3/10.
Галопом по европам, ничего не отложилось


17. Паттон «Пользовательские истории. Искусство гибкой разработки ПО». 7/10.
Хорошие методы планирования проектов

18. Эриксон «Кругом одни идиоты». 7/10.
Как понимать других
, если они не такие же как ты

19. Фаулер «Рефакторинг кода на JavaScript». 9/10.
Годный справочник по написанию понятного кода


20. Мартин «Идеальный программист». 9/10.
Отличная книга про то какими характеристиками (спойлер: не хардами) обладают хорошие программисты

21. Рызов «Кремлёвская школа переговоров». 8/10.
Много хороших примеров как вести себя в разных переговорных ситуациях.

22. Пиз «Новый язык телодвижений». 8/10.
Как понимать других, если они не такие же как ты часть два. Тут про то как обращать внимание на язык тела

23. Хастингс, Мейер «Никаких правил: Уникальная культура Netflix». 8/10.
Про эту книгу я много писал уже, в целом интересно про культуру Netflix.

24. Логан «Лидер и племя: Пять уровней корпоративной культуры». 7/10.
Интересная методология разделения команд, мне лично отклинулись наставления по переходу на уровень выше и сам факт что 5-й уровень явление временное.
.

Делитесь своими списками и открытиями. А так же пишите про какую книгу хотите обзор?

p.s. Легенда:
10 — рекомендую, покупаю и дарю при случае, маст рид
8-9 — отличная книга, маст рид
6-7 — неплохая книга, рекомендую
4-5 — хорошее чтение, вряд ли прочитаю вновь
2-3 — не понравилось
1 — совсем не понравилось, не рекомендую

Про руководство разработчиками | Олег Мохов

31 Dec, 16:08


Итоги года

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

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

В новом году я вам желаю перемен, но только со знаком плюс! С наступающим 🎉
(а кого-то уже с наступившим)!

Про руководство разработчиками | Олег Мохов

25 Dec, 13:28


Культивируем откровенность. Рассекреть документы.
Глава 5. Книга «Никаких правил. Уникальная культура Netflix»

В прошлых постах я уже писал про главы 1, 2, 3 и 4.

Суть главы описана ещё в названии к ней. Откройте доступ ко всей информации о компании, чтобы все сотрудники были в курсе как компания себя чувствует. Я бы тут сказал, что речь не только про PnL, а вообще про разную аналитику, KPI всего и вся, графики и прогнозы.

Это всё даже в книге подвергается сомнению, но автор выводит нас на всё тот же самый изъезженный тезис «Чтобы быть открытым как Netflix, нужно будет Netflix'ом».

Чем лучше сотрудники, которые как мы помним очень самостоятельны, понимают что происходит в компании — тем лучше и осознаннее решения они могут принимать. Тут всё ок. Из тезиса выше можно сделать вывод, что надо просто расшарить папку с секретами. Но это не просто расшарить, а ещё очень-ОЧЕНЬ много работы для инфобеза.

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

Про руководство разработчиками | Олег Мохов

20 Dec, 09:45


ДАМП СПб, 14 февраля

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

🤑 А ещё вот вам мой персональный промокод на 15% скидку на Питерский ДАМП: MOKHOV

Так же я в ПК ДАМПа Екб, и там мы вот-вот объявим CFP, но пока можете писать мне в личку, что уже хотите выступить и я вам первым напишу когда мы CFP откроем. Уже открыли!

Короче, го на ДАМП!

Про руководство разработчиками | Олег Мохов

20 Dec, 07:00


Назовёшь меня другом или, может быть, гадом!
Но я ухожу, и просто так надо!

© Lumen, Синяя птица

Яндекс, было классно, но мне пора. Всё, пока!

Про руководство разработчиками | Олег Мохов

16 Dec, 16:33


Алгоритм Хорстмана

Недавно посмотрел лекцию «5 хреновых паттернов руководителей» (видео, статья). Там впервые увидел алгоритм дачи корректирующего фидбека, названный чьим-то именем. И ещё мне лично очень приглянулся пункт №1, как-то раньше я даже не думал о нём.

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

1. Запрос ресурса

Уточнить готов ли человек принять фидбек. В лекции автор приводит странный пример, когда тебе могут сказать «нет». На мой взгляд это ключевое, что, например, человек может не важно себя чувствовать, быть загружен в другие мысли (сложная задача, проблемы в семье), в целом может быть не готов на данной встрече принимать и слушать фидбек (вы только что выпили вкусный кофе и съели круассан). Это нормально. Я лично, в таком случае сказал бы человеку что планирую дать ему обратную связь на следующей встрече.

2. Констатировать поведение

Тут в целом всё как в лучших книжках лучших родителей. Не «ты плохой», а «ты поступил плохо». То есть мы описываем действия и придаём им окрас, но не человеку.

3. Констатировать влияние поведения

Опять же в статье приводится мало примеров, тут я бы рекомендовал почитать главы 2 и 8 из книги про Netflix. Вообще лайфхак-слова здесь «возможно ты не заметил что»...

4. Способствовать эффективности будущем

Т.е предложить как бы вы поступали в будущем.

Когда я обсуждал дачу фидбека с психологом, она подсказала мне ещё интересную вещь. Интуитивно на шагах 2-4 очень хочется развернуть открытую дискуссию. Вот ты сделал так-то, как ты думаешь, а что подумал тот-то? Или: а почему ты так сделал?

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

Особенно на пункте 4. Вы же заметили поведение, которое хотите скорректировать (или зафиксировать) и вы же уже успели обдумать как бы вы поступили в таком случае. Ну так и скажите, а не добивайте человека гробовым молчанием на вопрос: как бы ты поступил в следующий раз?

Ну как, согласны? 😃

Про руководство разработчиками | Олег Мохов

13 Dec, 08:54


Пока я писал посты по стопам книги про Netflix и задавался вопросом: Может ли всё описанное работать так же до сих пор? — вышла новость, рассказывающая о том, что всё что написано в книге можно смело зачеркнуть рядом со словом «Netflix».

Какие выводы делаю лично я?
1. Быстро и хорошо растущие организации, чтобы расти ещё быстрее и лучше, могут организовать такие условия работы, при которых сотрудники забудут обо всём на свете кроме работы. Это нормально и в какой-то степени даже must для стартапов, которые хотят чтобы их выручка кратно увеличивалась YoY. Собственно для них книга про Netflix — это всё ещё путеводитель.

2. Когда рост замедляется, то наступают перемены. Менять принципы на таком этапе — это, иногда, вопрос выживания.

Например у Netflix задачи кратно расти уже нет. Выручка Netflix за 2023 год — 33 миллиарда $, но последние годы компания росла по выручке всего на 6% в год, а в 2022 году чистая прибыль была в минусе, поэтому не удивительно, что одним из решений стала оптимизация расходов. Чуть раньше, например, Netflix анонсировал что перестанет публиковать отчёты о количестве подписчиков.

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

Про руководство разработчиками | Олег Мохов

12 Dec, 07:09


Сегодня у меня пост-призыв.

Я ищу людей, кто работал в Яндексе и сейчас работает в Авито, Т-Банке, Озоне. И наоборот тех кто работал в Авито, Т-Банке, Озоне и сейчас работает в Яндексе.

Напишите мне в тг @olegmokhov, если это вы и вы готовы ответить на несколько вопросов про внутренние сервисы.

С меня подписка на ваш канал, звездочки к постам, ответы на разные ваши вопросы, а так же кофе, если мы где-то с вами лично пересечёмся.

Про руководство разработчиками | Олег Мохов

09 Dec, 13:09


Догфудь и кастдевь.

Во вторник по дороге в аэропорт разговорились с таксистом и он мне рассказал про свой опыт управления электромобилем. Казалось бы, автомобили существуют уже больше 100 лет, отрасль заполонила нашу жизнь и в ней уже все грабли исхожены. Но электромобили во многих местах являются Game Changer'ами, в том числе даже там где это с ходу не очевидно.

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

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

upd. На эту тему Егор (@yeputons) прислал отличное видео «Electric cars prove we need to rethink brake lights» 

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

P.S. А фото к посту — это ещё один факт, уважаемые знатоки, для чего предназначен данный автомобиль?

Про руководство разработчиками

24 Nov, 16:37


Го на TeamLead Conf

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

На TeamLead Conf я буду помогать на стенде компании МТС. Мне отдельно приятно, что одну из активностей я придумал, а команда смогла её реализовать. Буду рад увидеться и пообщаться, подходите даже если мы не знакомы лично, я буду рад всем. Ну и приходите покрутить педали!

Про руководство разработчиками

11 Nov, 07:31


Предлагай больше всех.
Глава 4. Книга «Никаких правил. Уникальная культура Netflix»

В прошлых постах я уже писал про главы 1, 2 и 3.

Начиная с 4-й главы, на мой взгляд, начинается самое интересное. В этой главе авторы рассказывают про то как в Netflix платят.

TL;DR
— Творческим сотрудникам нужно платить зарплату по максимуму на рынке.
— Премии, привязанные к показателям компании, отсутствуют. Весь ФОТ (фонд оплаты труда) идёт на зарплату
— Для того чтобы повысить зп сотрудник должен доказать что рынок поменялся

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

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

Если смотреть на тезисы из книги под углом разработки, то тут есть что обсудить:
— Отвяжи доход от бизнесовых KPI
Это антитезис к тому, чем жил современный российский IT последние лет 10 до известных нам событий. В принципе ровно эти же самые события и показывают, что в случае форс-мажора стратегия «плати всё в зарплате» оказывается вернее. Я вижу как у многих, кто долго сидел на опционах и премиях, доход в последние годы в лучшем случае не растёт.

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

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

Из-за этого я несколько раз терял сильные кадры — их просто переманивали конкуренты на х1.5-х2, а подобного роста зп внутри моей команды они не готовы были ждать годами. И увы, я пока не знаю в российском IT компаний, которые бы следовали принципу от Netflix, а скорее вижу обратное, что у всех в KPI есть найм сильных специалистов за гроши, затем KPI на удержание, но при этом инструментов для этого не дают. Как в том анекдоте про уборщицу: ищется уборщица, обязательно наличие высшего образования, знание английского и своё ведро.

Итого. Подход Netflix'а к работе с талантами мне кажется адекватнее, чем у большей части современного российского IT. Уж точно заслуживающим более глубокого изучения и апробирования.

Про руководство разработчиками

06 Nov, 17:03


С августа прошло три месяца. Привычка читать каждый день привилась. И вот с чем я пришел к октябрю.
- 15 книг за три месяца и 23 с момента как я начал активно читать в июле.
- Осилены не дававшиеся ранее: Рызов, Мартин, Фаулер и даже Клеппманн
- почти на половину прочитан Тихий Дон Шолохова

Этот пост - напоминалка о том посте как я начал читать

Про руководство разработчиками

05 Nov, 15:45


Полезняхи

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

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

p.s. Кстати, я тоже там есть 😊

https://t.me/addlist/Pk3F9xr4il5lZTc6

Про руководство разработчиками

03 Nov, 17:56


Channel photo updated

Про руководство разработчиками

03 Nov, 16:54


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

Дж. Ханк Рейнвотер написал книгу «Как пасти котов» проводя строгие параллели между поведением котов («кошка гуляет сама по себе») и разработчиков. Кажется если канал и дальше будет про руководство разработчиками, то на его обложке должен красоваться шикарный кот-руководитель, глядящий в светлое будущее. Что ж, именно такой и будет новая обложка канала.

Про руководство разработчиками

03 Nov, 16:24


Soft Weekend — самая мягкая конференция этого года

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

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

До конференции ровно 20 дней, сама конференция будет идти всего один день. Этот пост не реклама, я искренне желаю Андрею удачи. Если тема софт-скиллс вам интересна, то регистрируйтесь на конференцию Soft Weekend.

upd. Этот пост был написан до появления в программе Антона Назарова. К его «творчеству» я отношусь резко негативно и осуждаю.

Про руководство разработчиками

31 Oct, 07:00


Книга «Никаких правил. Уникальная культура Netflix». Глава 3

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


Начнём со второго. В Netflix отказались от бюрократии. Если траты в интересах компании, то на что вы их потратите уже не важно. Что ж, чтобы давать сотрудникам тратить деньги как Netflix, нужно зарабатывать как Netflix.

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

Мне кажется что за этими словами скрывается лукавство, ведь компания — это не только C-level и высокогрейдовые личности, даже несмотря на то что в книге постоянно делается акцент, что в Netflix нанимают только таких. Охранник, таксист, уборщица — все они тоже работают в компании, и ассоциируют себя с ней. Вряд они могут свободно распоряжаться финансами, точно так же как СЕО или мидлы. Даже в интересах компании.

Теперь к первому пункту. В Netflix отказались от графика отпусков. Берите отпуск когда надо и на сколько надо. Главное чтобы задачи делались. Иными словами не зависеть от рабочего расписания, работать на 200%, но мочь делать передышки тогда, когда тебе это нужно — работа мечты.

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

Книга призывает руководителей показывать своим примером как надо ходить в отпуск и почаще обсуждать отпуска за обедами, чтобы у сотрудников устойчиво складывалась картинка о том, что и руководители позволяют себе не только работать днями и ночами. И снова, прекрасные мысли, но с оговорками. Если в беседе C-level и мидла один будет рассказывать о шикарных отдыхах в 5-ти звездочных отелях на Бали, а второй об (не менее шикарных) отдыхах на 0 звездочной даче родителей, то такой разговор быстро заглохнет, так как между ними пропасть. Лучше опускать финансовые подробности (даже косвенные, все понимают что отпуск на Бали в 5* — это не дешево) и сосредотачиваться на эмоциях и предметах — вкусная еда, красиво, восторг.

Чтобы ввести свободный график отпусков не обязательно зарабатывать как Netflix. Я давно заметил, что не всем достаточно положенных по ТК 28-ми дней отпуска в год, чтобы работать оставшееся время с высокой самоотдачей. Можно правильно настроить отпускную бюрократию. Вполне допустимо сделать так: устный ОК от руководителя и несколько дней можно не приходить на работу, а затем левым числом написать заявление на отпуск, если нужно сжечь какое-то количество дней.

И ещё одна мысль. Даже выехав в райское место, люди, порой, проводят время за ноутбуком, потому что или не умеют отдыхать, или, что совсем ужасно, им не дают. Мы, как руководители, должны не только показывать своим примером как надо отдыхать, но и сделать так, чтобы сотрудника в отпуске не тревожили. Это должно стать ценностью уровня компании. «Извини что пишу в отпуске, но...» — эта фраза должна использоваться только если пишущий решает вопрос жизни и смерти.

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

Про руководство разработчиками

28 Oct, 09:11


Книга «Никаких правил. Уникальная культура Netflix». Главы 1 и 2.

Книга про Netflix — это поразительный пример с одной стороны интересных вдохновляющих идей, а с другой стороны гипертрофированного образа идеальной компании.

Первые главы книги мне дались тяжелее всего. Когда я их читал, то всё не мог понять, автор рисует образ выдумки или в Netflix всё именно так на самом деле?

В первой главе рассказывается про концентрацию талантов в Netflix. Netflix нанимает лучших из лучших, платит им зарплату выше рыночной и тем самым в команде Netflix работают только звёзды. Одним из этапов, как Netflix пришел к этому, стал кризис, когда пришлось уволить треть сотрудников. Читая всё это невольно вспоминаешь Винни Пуха: «Делай так как нужно, а как не нужно делать не нужно». Т.е эта часть книги веет лукавством за три версты. Моё имхо, Netflix когда-то совершил ошибку выжившего, и, говоря по-простому, им повезло, что уволив треть, оставшиеся две трети не свалили и при этом смогли выстоять.

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

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

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

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

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

2. Предлагай конкретные меры. Дополнение пункта 1.

3. Будь благодарен услышав критику. Не важно нравится она вам или нет, но то что человек в целом решил вам что-то сказать заслуживает благодарности.

4. Прими или отклони. Не всякую критику нужно воспринимать как план к действию. Только вы решаете как именно ей распорядиться.

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

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

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

Про руководство разработчиками

17 Oct, 19:10


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

Смена работы это всегда возможность пересмотреть собственные желания, может быть и не нравилось вам никогда руководить разработчиками, а вы всю жизнь хотели выращивать кроликов ☺️

Про то как помочь себе ответить на вопрос «Чего я хочу?» я писал в посте про Икигай

Про руководство разработчиками

17 Oct, 16:38


Увольняют, что делать?

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

Люблю Андрея, но чувствуется, что его давненько не увольняли, если вообще увольняли 😊 и поэтому набор советов он даёт скорее теоретический.

Хочу дать вам несколько советов из личного опыта:

1⃣ Посчитайте ваши затраты. Если решение об увольнении принято, то ничего уже не поможет. Вас вызовут на разговор и будут давить подписанием расторжения по соглашению сторон. Будьте готовы влиять на то что вы можете повлиять, а именно на отступные. Прежде чем назвать сумму внимательно посчитайте свои текущие расходы в месяц и умножьте их хотя бы на 3. Если получилось больше 2-х месячных окладов, то называйте эту сумму и аргументируйте почему именно столько.

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

2⃣ Не портите себе карму. Есть такое расхожее мнение, что уволить человека просто так нельзя. В нём есть доля правды, увольнять на 100% по закону крайне тяжело. Но все чего вы сможете добиться, пойдя в контры — это выиграете время. Вас найдут как уволить.

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

3⃣ Посчитайте кризисный план. Если наступит самое плохое, новая работа будет плохо искаться и т.п, то от чего вы готовы отказаться? Уверен что у каждого из нас есть такие траты. Рестораны, спортзалы, частные детские садики, кружки, дорогие подарки, отпуск на Бали — всем этим можно на время пожертвовать, пока вы снова не встанете на ноги. В пирамиде Маслоу рухнул нижний слой и нужно сначала его восстанавливать.

4⃣ Готовьтесь к собеседованиям. Понимаю, что для тех кто регулярно собеседуется тут ничего нового, но если вы на последнем месте работаете больше 5 лет, то возможно уже и не помните основы, например чем position: relative отличается от position: absolute. Проблема в том, что в больших компаниях чтобы дойти до боссов (во всех смыслах) нужно сначала пройти достаточно теоретические этапы. Попроходите leetcode, почитайте разные книги в том числе новые издания тех книг, которые вы сами готовы рекомендовать.

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


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

Изображение: © клип «В Питере пить», группировка Ленинград

Про руководство разработчиками

10 Oct, 07:51


Blind-калибровки

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

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

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

Blind-калибровка даёт руководителю явные сигналы, что он завышает (или, иногда, занижает) оценки. Ещё к плюсам я бы отнес, что после вскрытия оценок обсуждение крутится не на том чтобы понизить оценку, которую поставил руководитель, а вокруг вопроса «почему остальные поставили оценку ниже?». Это даёт руководителю возможность добавить что-то в отзыв или принять факт что он завысил оценку.

Картинка взяла из статьи. ©

Про руководство разработчиками

09 Oct, 09:38


А еще говорят что айтишники не танцуют :)

Про руководство разработчиками

09 Oct, 09:28


Всегда действуй в интересах команды

В книге «Никаких правил. Уникальная культура Netflix» рассказывается история о политике расходов в Netflix. Один из сотрудников поехал в командировку и, чтобы сэкономить деньги компании, использовал каршеринг вместо такси. После делового ужина с парой бокалов вина он вызвал такси до отеля, но потом ему пришлось компенсировать расходы, так как это не вписывалось в политику компании. Чем был очень возмущён, он же ездил для решение задач компании.

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

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

У меня есть похожее правило: всегда действуй в интересах команды. Я часто сталкивался с бюрократией и «не положено». Единственное, что я понял — если я считаю что это принесет пользу, то я должен быть готов потратить свои деньги.

Когда я организовывал конференцию FrontTalks, политика Яндекса запрещала оплачивать афтепати. В 2018 году я очень хотел, чтобы там выступала кавер-группа и, не имея достаточных обоснований кроме «хочу», оплатил ее самостоятельно. Получилось классно. На фото, кстати, мы с ребятами из группы Everybody Dance.

За идеями для FrontTalks я часто ездил на конференции, в том числе зарубежные. Вообще я очень люблю путешествовать. Но как обосновать 4 конференции в год? Где-то и одну-то с трудом согласуют. И снова, не имея лучшего обоснования кроме «хочу», я оплачивал конференции сам. Профит такого подхода не только в новых знаниях, но и в том, что коллеги не завидовали: конференции я совмещал с отпусками и оплачивал сам, а коллегам доставалось чуть больше денег на важные для них конференции.

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

Когда-то Лёша Башкеев (CEO Яндекс Клауда) говорил, что для привлечения первоклассного кандидата нужно водить его в лучшие рестораны за свой счёт. У меня есть похожая история как-то нам нужно было за 2 месяца нанять почти 10 человек. И я сказал рекрутерам: если получится, всех свожу в ресторан. Влетело мне это тогда в копеечку, но я не жалею, ведь мы достигли результата.

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

Про руководство разработчиками

03 Oct, 07:11


А зачем вообще калибровать людей? Часть 2

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

И все-таки в каком-то виде сопоставление скиллов грейдам существует. Тут важно понимать, что любая конкретика неизбежно приводит к формализму, поэтому тут действуют общие принципы: чем выше грейд — тем больше скиллов и самостоятельности. Как именно далее формализовать эти два параметра уже решает каждый руководитель сам. Сениоры бывают как уже готовые тимлиды-переговорщики, но средние по навыкам программирования, так и интроверты-хардкорщики, которые за пять минут найдут баг, не найденный до этого месяцами. Ещё раз повторюсь, что мне не известно, чтобы кто-то в Big Tech ориентировался на строгий чеклист навыков. Тут мы подходим к главному. Зачем калибровать людей? Если в целом Perfomance Review — это подведение итогов полугодия (или года), то калибровки это уравновешивание чаш весов результатов каждого из сотрудников и, соответственно, бенефитов. Потому что строгой функции «f(результат) = оценка» — не существует.

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

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

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

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

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

Так вот, удачи! :)

Изображение к посту защищено © Warner Bros., фильм «Космический джем».

Про руководство разработчиками

25 Sep, 06:58


Как калибровать людей?

После того как все отзывы собраны, пишется суммаризирующий отзыв. У меня, обычно, отзыв будет выглядеть так: основной отзыв — самоотзыв, на повышенную оценку выделяю следующее <перечисление достижений и результата>. Для удобства самоотзыв копипастится и кладётся под кат.

С удовольствием подискутирую в комментариях о других подходах.

Дальше начинаются калибровки. За почти 10 лет ревью в Яндексе я видел разное. От супержестких калибровок имени Миши Парахина (самая длинная наша калибровка длилась 16 часов, причем последние 6 мы решали задачу «понизить 4 оценки»), до формальных «поставь че-нибудь, лишь бы не всем максимальные оценки».

У любой калибровки должна быть цель. Не важно калибруются 5 человек, или 500. Целью не может быть «просто посмотреть». Глупо для того чтобы «просто посмотреть» собираться в одной комнате, закрывать шторы и тратить 8 часов на то чтобы пробежаться по списку ни на что не ориентируясь.

Вспоминается цитата из фильма ДМБ:
«Жизнь без армии — все равно что любовь в резинке: движение есть, прогресса нет».
Так и тут, если у вас на калибровку нет цели, то это бессмысленная трата времени.

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

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

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

Про руководство разработчиками

16 Sep, 13:43


p2p feedback. Часть 3

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

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

2. Потратьте силы на топ «рейтинга» взаимовыручки. Простых «помог мне решить проблему» не достаточно, чтобы объяснить важность этой помощи. Вот здесь-таки нужна история. Например, вы неделю бились над оптимизацией какого-нибудь кода, попросили помощи у Василия, вместе с ним организовали два созвона, и предположение Василия оказалось верным. Оптимизация помогла сэкономить столько-то CPU.

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

Про руководство разработчиками

12 Sep, 15:28


p2p feedback. Часть 2
и как его улучшить в рамках ревью?

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

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

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

Теперь представим ситуацию, что в компании работает Фёдор, который выполняет свою работу ожидаемо, в рамках своего грейда, оценка на ревью «норм». Но 10 человек ставят его в своём «рейтинге» на первые места, т.е он им очень помогает в работе, а значит Фёдор ценный сотрудник, даже несмотря на то что остальные показатели у него средние. Это кубик, которого лично мне не хватало, чтобы ревью перестало быть только про результаты проектной работы, и стало ещё и про командную работу, а так же взаимовыручку.

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

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

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

Про руководство разработчиками

11 Sep, 13:48


p2p feedback
и как его улучшить в рамках ревью?

Ревью, как процесс, есть во многих IT-компаниях. Обычно ревью проходит так: отзывы -> оценки -> калибровки -> изменения (пересмотр зарплат, премии и другие плюшки). Я в системе ревью уже 10 лет и за это время появились разные мысли, которыми хочется поделиться. Начнём с отзывов.

Отзывы — это старт, а для многих уже и финиш, ревью. Нужно запросить отзывы на себя у коллег, написать отзывы самому и сделать самоотзыв. У кого запросить? Где-то пользуются 360 degree feedback, где-то в полуавтоматическом режиме, где-то сам человек решает. Различается так же и то как фидбек даётся: в свободном стиле, или подробные опросники, или даже шкалы оценки. Все полученные фидбеки руководитель аггрегирует и ставит оценку перфоманса.

Так вот из года в год я наблюдаю одну и ту же картину. Какая бы схема фидбека не была бы выбрана, какие бы рекомендации не были бы даны по тому у кого запрашивать отзывы и как их писать. Всё равно большая часть отзывов сведется к мастерству авторов в написании простыней общий смысл которых будет «всё норм» 👌. Таких отзывов 90%, они представляют собой восхитительные рассказы, содержащие и эмоции, и перечисления всех тикетов и встреч, и так же истории о том какой человек классный и приятный. Но не факты. А даже если факты и будут, то они зачастую продублируют те что человек написал сам про себя в самоотзыве.

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

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

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

Складывается ощущение что отзывы от смежников не нужны совсем (ну, кроме негативных). Это не совсем так. Первый инсайд, который меня осенил совсем недавно, это то что при прочих равных даже отзыв вида «Вася мне очень помог» от автора, который обычно пишет «С Петей/Машей/Витей норм работается» — это вполне сильный сигнал о Васе.

Т.е важно не то какой отзыв написан на Васю. А какой это отзыв среди других отзывов того же автора. Иными словами из 30 отзывов, где 29 являются простынями про то что «всё норм» и один сухой отзыв «Вася крутой» от определённого автора — именно этот один отзыв должен сильнее всего влиять на оценку человека.

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

А пока давайте пообщаемся про то как у вас устроено ревью?

Про руководство разработчиками

06 Sep, 15:59


Право на работу

Вы, наверное, слышали что недавно в Австралии ввели закон, запрещающий работодателю звонить и писать работнику во вне рабочие часы. Хоть я этот тренд не разделяю, это отличное начало и я понимаю почему многим это нужно. Людям тяжело отказать руководителю в личной переписке, а многие руководители в вопросе «можно ли им не отвечать по выходным?» играют в молчанку.

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

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

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

Недавно я прочитал книгу Nordic dads. Книга эта скорее вдохновляющая и развлекающая, но автор делает явный акцент на том что в северных странах есть право на отцовский декрет. Это право даёт отцам при рождении ребёнка уйти в декрет, который они не могут* пошарить с мамой ребёнка. Это не то же самое, что просто уйти в декрет — такое есть и в России. А это именно оплачиваемый государством декретный отпуск отца.

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

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

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

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

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

Таких примеров может быть больше (приглашаю в комментарии). Если вы хотите стабильности ваших проектов, то я предлагаю вам ввести «правила на работу» и заранее продумать как это будет работать и оплачиваться. И да, вы точно будете первое время терять деньги на этом, но если ваша цель стабильность проекта, то оно того стоит.

Ну что ж, а мой рабочий день закончился, всем отличных выходных! :)


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

** Выходной день оплачивается либо х2, либо х1 и дополнительный отгул. Даже если ваш самолёт приземляется в субботу в 00:05 — это уже считается полностью оплачиваемым выходным. Именно это я подразумеваю под «захватывать выходные»

Про руководство разработчиками

02 Sep, 09:36


Cколько менеджеров нужно на встрече? Часть 3

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

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

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

Как действовать если календарь кишит регулярными встречами? map-reduce! Проходимся по списку встреч и задаём три вопроса про каждую из них:
1. Участвовал ли я активно в последних 3-х регулярках?
2. Что произойдет если я не приду на эту встречу?
3. Нужно ли мне знать что было на той встрече, и если да то каким образом мне комфортнее всего получать информацию о происходившем на ней?

Третье — это самое интересное. Менеджеры на столько обленились, что, вместо того чтобы писать follow up’ы, зовут на встречи всех подряд, чтобы «просто послушать». Ну уж нет уж господа менеджеры. Встреча — это тикет, а follow up — это пулл реквест с последующим мерджем в транк, поэтому давайте не будем игнорировать важность фиксации договорённостей после встречи. Собственно вы, как участник этой встречи, можете подсказать организатору как именно хотели бы получать follow up.

Проредили встречи? Ещё раз посмотрите на те, где участников больше 5. На некоторых из них вы всё ещё лишний. Повторить - закрепить. Я призываю вас оставлять в расписании только те встречи, в которых вы активно участвовали в прошлом. А остальные переводить в эпистолярный жанр.

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

Как быть, если слушатели горят желанием послушать? У Паттона описан метод «Аквариум». Во встрече активно участвуют до 5 человек, а остальные наблюдают. Если кто-то хочет подключиться к активной части, то нужно произвести замену, т.е чтобы кто-то из активных участников отключился от обсуждения. В оффлайне это сделать проще, чем в зуме. Но я думаю вы поняли, что смысл здесь в том, что эффективное обсуждение возможно только небольшой группой.

В конце хочу ответить на ещё один не заданный вопрос, почему мои посты называются «сколько менеджеров нужно на встрече?» Менеджер — это управленец, руководитель, а не только люди с M в названии должности (TPM, PM, Продакты). Руководителем можно быть не только группы, службы, отдела, но и функциональности, проекта, и даже эпика. И когда вы вступаете на эту дорогу руководства (если вы мидл, то уже наверняка бывали feature lead), то сразу же получаете кучу встреч впридачу, что сильно размывает ваш фокус, несмотря на то что подавляющее количество встреч вам посещать не обязательно.

Если же вы руководитель такого сотрудника, то помогите ему отказаться от неэффективных встреч. Часто я слышу мантру «я должен пойти, ведь меня же позвали», хотя в реальности организатор просто добавил всех »кому может быть интересно» и сотрудник может и не идти на эту встречу, ведь у него есть другие, куда более важные дела, чем «просто послушать».

Ходите только на полезные для вас встречи.

Про руководство разработчиками

22 Aug, 11:21


О, чёрт, я кажется догадался в чём дело и почему под постами нет ссылок на обсуждение.

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

За сим вопрос к сообществу: подскажите хороших спам-ботов?

Про руководство разработчиками

22 Aug, 11:10


Как всегда комментарии можно писать под этим сообщением. Поддержка не отвечает что происходит и почему в длинных постах нет ссылок на комменты.

Про руководство разработчиками

22 Aug, 11:08


Сколько менеджеров нужно на встрече?

В книге Джеффа Паттона есть короткий абзац-история про компанию ThoughWorks (в печатной книге страница 138). Суть такая, что команде нужно было обсудить бэклог, но при этом в продукте было 25 людей, принимающих решение и попытка собрать их в одной комнате обернулась сущим кошмаром для команды и она не смогла нормально запланироваться. Решение, которое предлагает Джефф очевидное и на поверхности — дробиться на небольшие группы и прорабатывать частички бэклога уже в них. Не так эффективно по времени, но эффективно по результату.

Казалось бы это элементарно, Ватсон. В доковидную эпоху это работало само собой, благодаря ограничениям размера переговорок, когда в маленькую переговорку не позовёшь 20 человек. Но в эпоху Zoom’митингов мы вернулись к формату похожих монстровстреч и соответствующих проблем. Сравните картинку из шедеврума и скриншот из зума (взято отсюда). Лично у меня нет ощущения во втором случае что когда я начну говорить то меня будут слушать 50 человек.

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

Знакомо?

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

Остальные встречи на 10+ человек — это всегда презентации и монологи, к которым нужно готовиться заранее. Не стройте ложных иллюзий, что получится что-то типа беседы или что-то иное. В лучшем случае пара человек выскажется, и чаще всего это будет или рядовая похвала, или неприятная критика (публичная, к слову). Зачем вам оно?

Хочется обсудить — собираете до 10 человек и обсуждаете. Затесался 11? Увы, это уже презентация 😉 (табличка «sarcasm»)

Про руководство разработчиками

16 Aug, 14:07


Пост для комментариев