Почему лучше не хлопать дверьми, даже если очень хочется

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

Самое глупое - это начать «резать правду-матку». Рассказывать коллегам, какие все вокруг беспросветные идиоты и как вам всё это надоело терпеть. Что процессы в компании говно, а руководство - тупое.

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

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

Как вы думаете, что стоит за таким токсичным поведением?

AMA-сессия

Всем привет!

Я, конечно, не Леонид, но нас в канале 300+ ?

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

А давайте сегодня проведем AMA-сессию (Ask Me Anything). Пишите ваши вопросы на любые темы, я на них отвечу. Например:
▪️Как перейти руководителем в ИТ
▪️Почему летают самолеты
▪️Как правильно учиться и запоминать море информации
▪️Где можно вкусно поесть
▪️Как организовывать работу команды
▪️Трудно ли жить корейцам в России
▪️Как выстраивать эффективные рабочие процессы

Допиваем утренний кофеек и погнали ?

Всем привет! ?

Почти 2 месяца назад я перешёл из продуктовой разработки в Big Data. За это время я узнал много нового для себя и про себя, успел приступить к работе над 20 проектами одновременно, уже выполнил 5 релизов и даже подменял другого PM, пока он был в отпуске.

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

Например, вчера аналитики и разработчики обсуждали тестирование функционала на «бариках». Если бы я не спросил, то так и остался бы в неведении относительно того, что «барик» — это research bar, расширение для браузера, а не Борисовские пруды, как мы их называли в школе. В общем, моё настроение колеблется от «о, вроде, я понял!» до «я ничего не понимаю…». Но это нормально. Обычно полная адаптация на новом месте занимает около 6 месяцев.

И вот в таких условиях меня вчера попросили быть ментором новому PM!!!
Сколько себя помню, я всегда охотно обучал и делился опытом с коллегами. Но тут будет первый опыт, когда я сам не до конца освоился. Главное - не стать героем картины Брейгеля!

Буду держать вас в курсе про эту историю.

Мелочь, а неприятно

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

А что я вижу вчера? Перевод денег стал более сложным процессом. По-прежнему можно переводить кредитные средства, но сначала их надо перевести на дебетовую карту, а только потом — на вклад. И в конце грейс-периода нужно повторить эти же действия.
Очевидно, что это намеренное усложнение пользовательского опыта (UX), которое может отсечь часть пользователей из-за своей заморочености. Кроме того, дополнительные шаги могут привести к ошибкам, которые принесут выгоду банку.

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

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

Кстати, объясните мне, пожалуйста, кто-то что-то заработал от "тапания” хомяка"? ?

Я изменил…

Как вы понимаете, корейская кухня всегда занимала особенное место в моем сердечке. Но сейчас — совсем другое дело… Китайская кухня пришла в мою жизнь незаметно: сначала Красная свинина семьи Мао под светлое Цинтао, затем лапшичка по-ланчжоуски и Хого.
И вот уже ты сидишь в чифаньке, ешь малатан в субботу, за которым ехал 40 минут…)

Как будто поменял один любимый фреймворк на другой.

Если захотите попробовать малатан в Москве, езжайте на м. Университет. Тут всё это и даже больше.

?Чек-лист «Как есть малатан»:
✅ Взять тазик и положить всё, что нравится с витрины;
✅ Взвесить на кассе и оплатить острый/неострый бульон;
✅ Сделать соус: кунжутная паста, соевый, чеснок, кинза +;
✅ Наслаждаться поеданием в приятной компании.

Говорите на понятном языке с разработчиком

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

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

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

Окей, договорились, что встретимся завтра. А я набросал схему, как есть (AS IS) и как мы хотим (TO BE), чтобы выглядели релизы, и отправляю в личку, чтобы завтра уже предметно обсуждать вопрос.

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

Мораль басни
1️⃣ Общайтесь с разработчиками на понятном им языке. Git - универсальный "язык" разработчиков
2️⃣ Готовьтесь ко встречи. Это может значительно сэкономить время
3️⃣ Используйте визуализацию на схемах, чтобы лучше понимать друг друга

?Напоследок оставлю ссылку на самый лучший и понятный тренажер по Git
https://learngitbranching.js.org/?locale=ru_RU

Сильные стороны слабых

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

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

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

Поэтому мы удивились, когда мой руководитель привлек этого сотрудника к нашему проекту.

Мы ему сказали: "Сан Саныч, Игорь же откровенно слабый инженер. Зачем вы тащите его в команду?"

На что мудрый Сан Саныч говорил: "Да, он не ахти какой инженер, но он - идеальный чекер"

"Он же не умеет делать расчеты!- спорили мы с ним, - Как он может что-то проверять?"

"Вы ни черта не понимаете!, - спокойно улыбался Сан Саныч и объяснял нам, - У Игоря есть талант: если ему дать эталонный образец и сказать сравнивать задачи с ним, то он это сделает лучше вас всех. Да, он не поймет, почему возникло расхождение. Но зато он отловит все несоотвествия и всех блох."

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

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

А как вас приятно удивляли другие люди?