Повышаем вероятность грейдапа или как написать грамотное performance review

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

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

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

Правильная структура такой оценки выглядит примерно следующим образом:

1. Цели

Начните performance review с описания того, какие цели ставились на оцениваемый период.

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

- Завершить проект X и раскатить его на 50% пользователей.
- Съездить на конференции Y и выступить с резюме перед командой.

2. Описание результатов

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

- 26 сентября запустил проект Х — на 3 недели раньше запланированного срока.

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

3. Планы

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

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

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

If you do not ask for or talk about that promotion with your manager, do not expect to get it.

📹 Классный видос по теме — клик.

🎙️ Жан Курбанбаев — от IOI и Google до Ironman

Друзья, спасибо всем, кто был с нами на эфире!

Мы обсудили с Жаном его бэкграунд в спортивном программировании, тернистый путь к медали на IOI, работу в Google, разочарование в разработке, поиск себя, путь к первому полумарафону и участие в Ironman.

Спасибо Жану за то, что нашёл время, чтобы провести с нами этот эфир, он получился очень полезным и интересным!

Записи наших эфиров теперь можно также послушать на наших страничках в Spotify и Apple Podcasts:

🎵 Spotify — ссылка
🎙 Apple Podcasts — ссылка
🎵 Яндекс Музыка — ссылка

Работать нужно не 12 часов, а головой

В одном из интервью, долларовый миллиардер, Маргулан Сейсембаев, говорил что в жизни не работал больше 6 часов в день.

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

Приведу пример: летом работал по 10 часов, уделяя чуть больше времени работе и другим проектам. Вроде бы успевал и работать и задачи по проектам закрывать, но спустя 2-3 недели выгорел и перестал работать. Да, заставлял себя, сидел за рабочим столом, но тело и организм отказывались, не хотели работать.

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

Кэл Ньюпорт, выпускник MIT, профессор и автор бестселлеров New York Times, часто пишет о продуктивности и приводит такую формулу:

Выполненная работа = Потраченное время х Интенсивность

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

Давайте объясню, что подразумевается под термином "интенсивность" в формуле.

Плохая интенсивность — вроде работаешь, но в то же время на фоне общаешься, листаешь рилсы, тикток и тд.

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

В итоге чем интенсивнее работаешь, тем меньше тратишь времени и успеваешь больше.

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

📖 Почитать статью Кэла Ньюпорта о формуле: клик
📹 Посмотреть интервью с Маргуланом Сейсембаевым: клик

Тимур Тибеев — отказ от офферов в MAANG и жизнь в Австралии

🦘 Вам кажется, что с перевёрнутым текстом на постере что-то не так? Да не, всё в порядке, ведь к нам из самой Австралии подключится на эфир Тимур Тибеев — Senior SWE at Canva (Сидней), ex TeamLead at Yandex, автор канала @bigtechdream

🎙️ На эфире с Тимуром мы пообщаемся о его карьерном пути, о MAANG и отказе от офферов в Google и Amazon, о жизни и работе в Австралии, поисках жизненного баланса, профессиональном развитии и многом другом!

⏳ Встречаемся в воскресенье, 4 февраля в 11:00 (MSK) • 14:00 (ALMT) на нашем ТГ-канале.

Спасибо всем, кто был на эфире!

🇦🇺 В этот раз к нам из самой Австралии подключился Тимур Тибеев — Senior SWE at Canva, ex TeamLead at Yandex.

Мы пообщались с Тимуром про его карьерный путь, про отказ от офферов в Google и Amazon. Поговорили о жизни и работе в Австралии, поисках жизненного баланса, профессиональном развитии и многом другом!

Получилась супер интересная беседа, спасибо Тимуру за то, что нашёл возможность прийти к нам!

Подписывайтесь на его канал — @bigtechdream

Кстати, послушать этот и предыдущие выпуски можно на 🎵Spotify, 🎙Apple Podcasts и 🎵Яндекс Музыке — по ссылке

Что убивает большие проекты?

Недавно вспомнил один случай из жизни. В начале второго курса в универе договорились с другом совместно сделать аппку.

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

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

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

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

Однако было два очень важных «но»:

1. Мы оба были крайне неопытными разрабами и написали всё без какой-либо расширяемой архитектуры и с кучей говнокода.

2. Мы оба не имели опыта запуска проектов, поэтому не понимали, как правильно это делать.

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

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

Так вот, две морали сей истории:

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

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

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

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