dmgritsan - CTO & Co-founder with AI tools

Галя, у нас отмена!

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

Но самый интересный фидбек пришёл, собственно, от того, кто охарактеризовал меня как ISFP. Он сказал, что то ли я книжку, которую читаю, не так понял, то ли книжка не самая актуальная. Потому что "никакой дихотомии по измерению J/P особо нет". Это сопровождалось ещё кучей выкладок, которые мне только предстоит понять и обещанием накидать книжек поактуальнее.

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

Медленно и не очень регулярно читаю книжку по типологии личности. Кажется, умение определять как человек думает, принимает решения, ощущает окружающий мир довольно полезно для менеджера. Первые три разделения в описанной в книге системе довольно классические: Introverts <=> Extraverts, Sensors <=> iNtuitives, Thinkers <=> Feelers. Классические не в том смысле, что понятные мне, для меня в них тоже оказалось много нового, но по крайней мере понятные моему психотерапевту, поскольку это всё взято из Юнга. А вот ещё одно разделение мне (и психотерапевту тоже, да) показалось интересным с точки зрения менеджера. Причём, возможно, даже не столько по отношению к людям в команде, сколько по отношению к самому себе.

Разделение это между Judger (J) и Perceiver (P). Если очень упрощать, то J — это те, кто быстро принимают решение и не готовы его менять под влиянием новых вводных, а P — те, кто наоборот готов до бесконечности собирать дополнительные данные и с большим трудом останавливается, чтобы принять какое-то решение. Я про себя знаю (возможно, меня в этом убедил мой бывший руководитель, предположивший что я ISFP), что я прям классический P — меня хлебом не корми, дай ещё с одной точки зрения посмотреть на ситуацию. И это, в принципе, классное умение, но проблема в том, что в жизни любого управленца есть периоды, когда надо собирать данные, а есть периоды, когда надо принимать решения и придерживаться плана хоть сколько-то продолжительное время несмотря ни на что.

Поэтому, зная, что я P, я стараюсь искусственно внедрять для себя какие-то ритуалы, или делать какие-то вещи, которые меня заставят проявлять J-качества. Например, когда мне показалось, что консультировать людей может быть полезно, я, понимая, что надо не передумать, пока я не проведу достаточно встреч, публично закоммитился на два месяца. Чтобы не сильно отвлекаться от фокусов на неделю и день (а фокус на период - это вполне себе решение, которого надо придерживаться), у меня появился утренний обмен планами на день и еженедельный созвон с обсуждением планов на предстоящую неделю. Даже фоллоу-апы после встреч писать — это для меня в каком-то смысле J-ритуал. Потому что там ты должен зафикисровать action-point’ы не только для всех остальных, но и для себя. Не написал фоллоу-ап, считай ничего не решили, собираем информацию дальше.

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

Кстати, нужно более подробно рассказать про то, как мы расписывали образ будущего?

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

Когда я обсуждаю такой подход с другими менеджерами, часто слышу, разные аргументы. Где ты найдешь столько вовлеченных разработчиков, а тем более быстро. А мне надо, чтобы код писали сейчас, а не через три месяца. У меня уже есть команда, работаю с тем, что есть. И так далее. Все они имеют право на жизнь. Но так же имеет право на жизнь и моё предположение, что те, кто высказывают эти аргументы, просто не пытались строить свою команду всерьёз. Это, на самом деле, довольно большая менеджерская работа, результат от которой может превзойти самые смелые ожидания, а может не случиться вообще. И здесь мне кажется очень важным посмотреть на эту проблему с другой стороны — не с менеджерской, а с разработческой. Что именно разработчики, которые готовы вовлекаться в бизнес, видят важного и полезного в этом вовлечении. Чего они от нас менеджеров ждут. Я давно собирался написать пост на эту тему, но недавно за меня это сделала моя прекрасная коллега, с которой у нас как раз и случился тот самый метч несколько лет назад в команде Яндекс.Сплита. Почитайте её пост, он отлично написан и классно иллюстрирован ☺️. И что важно, он содержит понятные практические шаги, которые стоит попробовать сделать, чтобы команда разработки стала частью бизнеса, а не каким-то аутсорс-подразделением.

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

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

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

Какую это вызвало у меня ассоциацию? Конечно же про процессы в команде и то, без чего я не вижу возможности жить в agile-команде, ретроспективы. Если вы опытный менеджер и знаете как надо, то вы можете прийти в чужую вам команду и сказать - теперь мы будем жить так. Проблема в том, что без обсуждения, рефлексии и возможности на это повлиять, команда с высокой вероятностью будет саботировать какие-то процессы или имитировать их выполнение для галочки. И даже если вам будет казаться, что всё ok, потому что оно “как по учебнику”, на самом деле всё может быть вообще не ok и в один не самый прекрасный момент это неок вырвется наружу.

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

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

Только хардкор ручной сбор

В выходные я был на маленькой сербской винодельне, помогал собирать урожай винограда одного из сортов. Когда мы спросили сколько людей трудится в podrum (дословный перевод — подвал или погреб, но имеется ввиду именно винное производство), выяснилось, что по сути только сам винодел. Да, конечно, на сборе урожая он был скорее менеджер — позвал людей, обеспечил условия для сбора, накормил после. Но, вообще-то, кроме него у этой винодельни нет ни одного сотрудника, т.е. по сути он в одиночку производит 10.000 бутылок вина в год.

Что такое десять тысяч бутылок? Если говорить с точки зрения бизнеса, не так уж и много. Даже если взять итоговую цену этих бутылок на полках магазинов, это не больше 200.000 евро в год. Вычтем отсюда маржу магазинов, стоимость логистики до них и прочее, получится, что самому виноделу достаётся хорошо если 100.000 евро в год. Вычтем расходы на единицу товара (бутылки, пробки, наклейки) останется 80.000. Вычтем расходы на производство (уход за виноградом, оборудование для выдержки, обслуживание тракторов и всяких специальных машин типа гребнеотделителя, пресса и прочих) - останется, наверное, тысяч 50, а то и меньше. Поделим на 12 месяцев, получим примерно 4000 евро в месяц (не удивлюсь, если мои оценки настолько неверны, что в 2 раза меньше или в 1,5 раза больше, но не суть). И что бы ты ни делал, ты не можешь кратно увеличить свои доходы. При этом есть куча рисков (в первую очередь погодно-климатических), которые ты не контролируешь и которые могут лишить тебя дохода на год, а могут и на несколько лет.

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

Мне кажется, корень проблемы лежит где-то в детстве, в котором в России в 90-е практически не было видно никакой золотой середины. Люди, которые просто спокойно занимались своим любимым делом, в лучшем случае могли обеспечивать базовые потребности своих семей, а о многих вещах им оставалось мечтать. Те же, у кого с моей точки зрения всё было, либо строили корпоративные карьеры, либо строили с нуля бизнесы сильно превышающие семейные. И получается, что малый бизнес, который я видел, пока подрастал, был для выживания, а не для жизни.

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

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

И тут мы переходим ко второй вещи - границы применимости автотестов. Я видел отлично покрытые автотестами SDK. Более того, я считаю, что делать хороший SDK без очень плотного покрытия автотестами невозможно. Я видел неплохо покрытые автотестами API. Особенно, когда они были статичными и редко менялись. Я почти никогда не видел хорошо покрытые тестами интерфейсы. И я также почти никогда не видел покрытые автотестами сценарии взаимодействия нескольких независимых систем. И вот это, пожалуй, самая сложная история. Когда мы говорим про автотесты, то чаще всего они хорошо покрывают очень ограниченный скоуп, а не продукт целиком. Да, действительно, сочетание автотестов и постепенной раскатки может заменить собой сложные интеграционные тесты - бизнес-показатели не упали, значит всё ok. Правда, это своеобразное перекладывание нагрузки с QA на девопсов, аналитиков и кого-нибудь ещё, но, скорее всего вам все равно и такая система деплоя, и такая аналитика нужна ещё и для других целей. Но, не забываем, что для того, чтобы у вас были хорошие автотесты, вам все равно нужен QA-инженер и, возможно, ещё и QA-автоматизатор, который поможет развернуть систему автотестов или проконсультирует о применимости тех или иных подходов в каждом конкретном случае.

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

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

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

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

Что мне кажется в корне неверным в этих подходах? Сразу несколько вещей. Давайте отложим автотесты на сладкое (я про них тоже написал, но в один пост всё не влезло, так что продолжение ждите завтра) и начнём с простого - почему плохо, когда кто-то заменяет собой QA-инженера, который проводит ручное тестирование? Если это разработчик, особенно тот же самый, что написал код, то вероятность того, что он протестирует работоспособность поверхностно довольно высока. Знаете как много разработчиков коммитит неработающий код и отправляет его на тестирование? У меня, конечно, нет статистики, но очень много. И я не уверен, что перекладыванием ответственности за тестирование на разработку вы здесь что-то принципиально измените. Да, скорее всего основной сценарий разработчик протестирует руками, но будет ли он сидеть и выдумывать и проверять все корнер-кейсы? Не факт. А готов ли разработчик брать на себя дополнительную ответственность и решать, какое поведение блокер для релиза, а какое бага, которую можно исправить в следующем? А будет ли он, найдя багу на проде, пинать всех, чтобы они бросили всё и стали делать хотфикс? Не уверен!

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

В обоих случаях, если ручное тестирование проводит продакт или разработчик, у меня складывается ощущение, что они заняты не своей работой. Что значит не своей? Я в это вкладываю две вещи. Первая - ту работу, экспертиза в которой не является для них профильной. Вторая - ту работу, которая подразумевает другой склад характера, чтобы делать её хорошо. Да-да, QA-инженеры, разработчики и продакты это люди, которые могут сильно по-разному смотреть на одни и те же вещи. И то, что каждый из них прикоснулся к фиче, прежде чем она была зарелижена - это благо. Есть более-менее общепризнанное мнение, что diversity это хорошо, так как мы получаем больше различных взглядов на одни и те же проблемы. Так вот наличие у вас в команде QA-инженера в добавок к продакту и разработчику - это тоже в каком-то смысле diversity, которое повышает качество вашего продукта.


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

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

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

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

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

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

В общем, если делать какой-то вывод или пытаться придумать какой-то call to action, то пусть он будет такой: если вы недавно поменяли работу (можно же не уточнять, что ваша работа про IT, это и так понятно?) и вам хочется об этом поговорить - пишите мне в личку, созвонимся!

Два месяца назад я написал первый пост в канале про то, что хочу консультировать людей про всякое околоменеджерское в айти, опубликовал calendly с двумя слотами в неделю и сказал, что ближайшие два месяца буду проводить консультации бесплатно. С тех пор я написал еще 17 постов (этот 18ый), провел 13 полноценных встреч, которые, кстати, очень помогли написать эти 18 постов, а в канале за это время собралось больше 100 человек. Конечно, 13 консультаций — это ещё не статистика, но уже повод поразмышлять, сделать какие-то выводы и определить правила на следующие два месяца.

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

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

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

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

P.S. Если хотите записаться на 1-1, пока делайте это написав мне в личку @dmgritsan

После моего поста про Yandex Cloud и AWS один мой знакомый написал мне в личку, что было бы прикольно, если бы я поделился своими наработками из разряда “быстро сделаю сам”. Прежде чем отвечать подробно про какие-то конкретные наработки, попробовал проанализировать, какие у меня есть варианты окружений для проектов разного типа и вот что получилось:

- Простые скрипты, которые регулярно отрабатывают (например, несложный парсинг чего-то в интернете + отправка результатов в телегу). Это тупые lambda функции без каких-либо заморочек. Быстро написал скрипт, залил, добавил расписание или какие-то триггеры на новые сообщения в очереди или файлы в S3 и оно работает. Минус в том, что никаких возможностей для настройки CI/CD тут нет.
- Сложный анализ, где на функциях никуда не уедешь. Например, если речь про парсинг, то что-то, что требует Selenium. Тут уже github + github actions, докер контейнер, container registry и elastic container services. При этом, если это сложный парсинг, а потом отправка в телегу, то результаты парсинга, например, складываем в S3, а потом уже можно опять лямбдами обрабатывать.
- Если нужен супер простой бекенд в облаке с API’шкой, то API gateway со всё той же lambda. Помним, что жопа с CI/CD, но для проверки гипотез - почему нет.
- Когда нужен более-менее сложный бекенд в облаке, то flask-сервачок в докер-контейнере. К нему, естественно, опять github, github actions. Ну и тут уже можно придумать и настроить какие-то правила для тестовых и продовых окружений.
- Когда ко всему этому нужен ещё и фронтенд в облаке, то Amazon CloudFront. Он сам умеет из github вытаскивать обновления по коммиту, собирать новые билды и разворачивать их на своём Node.js серваке. Наверняка то же самое можно сделать и через докер-контейнеры самостоятельно, но сложнее и дольше.

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

Отсюда возникает интересный немного риторический вопрос. Вот ты новый игрок на рынке, делаешь отличный продукт с учетом ошибок тех, кто был на этом рынке первопроходцем. Но преимущество в удобстве и легком старте использования твоего сервиса нивелируется отсутствием поддержки от коммьюнити и тем, что для бесплатного использования доступно сильно меньше сервисов, чем у конкурентов. В моём случае, например, не хватило классической SQL-базы. Да, кстати, я на старте пытался использовать доступную во free tier YDB, но решил, что разбираться с тем, как уйти от использования реляционной базы в моём сценарии, слишком долго. Так вот, вопрос, как оценить - надо ли дать дополнительный бесплатный (хотя бы на какое-то время) сервис, чтобы поднять поддержку от комьюнити и сделать свой сервис более привлекательным для stackoverflow-driven разработки?

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

Раз уж я говорю, что я full-stack manager, то буду иногда писать и про те проекты, которые делаю своими руками, а также те проблемы, с которыми сталкиваюсь, или те наблюдения, которые делаю в процессе их разработки. На этих выходных переносил из Яндекс.Облака в AWS python-функцию, которая крутилась в serverless-режиме, собирала с нескольких сайтов и отправляла объявления в канал про сдачу в аренду недвижимости в Белграде.

Я написал её в октябре прошлого года, когда мы искали квартиру сами. В Сербии есть несколько классифайдов недвижимости с интерфейсами разной степени дружелюбности, и нам надо было максимально быстро находить на них новые объявления, чтобы быть в числе первых людей, которые их посмотрят. Рынок был такой, что если ты не посмотрел квартиру первым, то с большой вероятностью, ты её уже не снимешь. Так как у меня уже был довольно немаленький опыт написания парсеров (когда-нибудь я расскажу здесь, как записывался в итальянский визовый центр в Москве в 22 году и как парсил сайты производителей резины), я быстро проверил, что с 4 основных сайтов, которые нам нужны, можно довольно легко достать всю нужную нам информацию. Тогда передо мной встал вопрос, где и как поднять этот скрипт, чтобы он работал не у меня на ноуте, а регулярно отрабатывал независимо от обстоятельств.

Мой выбор пал на Яндекс.Облако. К тому моменту у меня уже был опыт разворачивания serverless-functions в Azure, AWS и Yandex.Cloud и именно у Яндекса это было делать удобнее всего. Честно говоря, я уже не помню на каком языке я поднимал что-то в Azure, но если речь идёт про python и функция требует установки зависимостей, то в AWS сначала придётся разобраться с тем, как собрать layer с этими зависимостями, чтобы его подключить. Когда ты занимаешься такими развёртываниями достаточно редко, а один layer используется только в одной функции, решение от Яндекса выглядит гораздо более понятным любому python-разработчику - просто положи файлик requirements.txt и при деплое система сама подтянет всё, что тебе нужно.

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

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

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

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

- Что важнее вид с балкона на закат или близость разнообразных баров-ресторанов?
- Что лучше отдельно стоящий дом, от которого до всего ехать 15-20 минут или квартира, где всё в пешей доступности?
- Нужен свой бассейн, общий на несколько квартир или вообще не нужен, если море рядом?

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

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

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

А вот интересную тему, с которой изначально начался наш созвон в среду, я бы хотел вынести на более широкое обсуждение. Внимание, вопрос - как менеджеру присваивать результаты? Вот пришёл ты на собеседование и рассказываешь - я запустил крутую фичу, поднял продажи на 30%, снизил косты на архитектуру на 50%. Но ты не продакт, не маркетолог и не архитектор. Ты какой-то там (ох, сколько я видел разных названий) технический менеджер. Так в чем твоя роль здесь? Можешь ли ты объяснить, почему без тебя команда бы не справилась или хотя бы справилась бы хуже?

И, кажется, что ответ на этот вопрос у нас с моим собеседником оказался очень похожим. Роль менеджера в том, чтобы создавать условия для команды, в которых она может работать максимально эффективно. Не было бы условий - не было бы и таких результатов. Как ёмко сказал один мой руководитель про себя “Я - дух леса” (с). Но дальше начинаются нюансы, духи же бывают разными.

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

А как вы присваиваете себе результаты? Расскажите в комментах.

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

Отойду немного от темы менеджмента команды в сторону менеджмента себя.

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

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

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

Моя ошибка была в том, что я недооценил количество стресса от полной смены обстановки. За прошедшие полтора года я уже два раза выстраивал свою жизнь с нуля в новом месте, но в прошлые разы я не пытался это делать в одиночку — рядом был близкий человек (а часто ещё и компания ещё большого количества относительно знакомых людей) и наша собака. А тут я приехал один на разведку и всё пошло совсем не так. Вообще, я на эту тему думал давно и знаю, что это может смешно прозвучать, но, своим ментальным здоровьем в 22 и 23 году я во многом обязан своему псу, с которым независимо ни от чего, надо кому-то надо погулять два раза в день.

Мичи, спасибо тебе, что всего два раза! Но, да, два - не меньше. С ним не договоришься погулять завтра, он не пойдёт гулять один. Если совсем нет сил, надо как минимум договориться с тем, кто погуляет с ним вместо тебя. Но сейчас, пока он остался в Белграде, эта опора режима дня исчезла. И расписание походов в тренажерный зал к тренеру, которые задавали ритм недели, тоже исчезло. А новые желанные привычки стало просто не на что нанизывать.

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

А как вы справляетесь с переездами, внедряете новые привычки и избавляетесь от старых? Поделитесь своими лайфхаками в комментариях.

Кстати, в связи с переездом на Кипр (и временным отсутствием собаки, которая осталась в Белграде) поменял время для консультаций на ближайшие три недели. Записывайтесь тут: https://calendly.com/dmgritsan/copilot

И смело давайте ссылку друзьям (и на канал, и на calendly), если у них болит что-то менеджерское. Будет круто, если они запишутся, а ещё круче, если перед этим напишут мне что-то о себе и о том, что им хотелось бы обсудить.

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

Зашёл у нас разговор о такой штуке, как farewell party. Мы нашли столько разных смыслов, которые можно в неё вкладывать, что я даже удивился. И теперь хочется спросить у вас - а как вы относитесь к прощальным вечеринкам уходящих сотрудников? Ходите ли на них? Организовываете ли вы их сами? Какой смысл для себя в это вкладываете?

Те смыслы, которые мы нашли, собрал в опросе. Он анонимный с возможностью выбора нескольких вариантов ответа. Если выбираете “У меня своя причина” - расскажите в комментариях, какая!