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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что и требовалось доказать. Если вам поставили задачу сделать алгоритм распознавания чисел в ситуации, когда во всех трехзначных числах первая цифра 1, с вероятностью 99% вы жестко пропишите в алгоритме ограничение на то, что первая цифра может быть только 1. Более того, вы будете правы, что сделаете именно так. А то, что потом кто-то решит добавить возможность ставить вперёд семёрку и не расскажет вам об этом — это уже будет не ваша забота.

Внезапно понял, на что чаще всего похожи те 1-1, на которые ко мне приходят менеджеры. Больше всего мне они напоминают мои встречи с agile coach’ами. Конечно, мне бы больше хотелось, чтобы люди ко мне приходили за услугой, которую мы вместе с моей коллегой по MS когда-то обозвали CTO-as-a-Service (CTOaaS), но по факту это гораздо чаще именно ACaaS. И я это связываю с тем, что чаще всего можно порешать проблему какими-то управленческими решениями (добавить-убрать встречи, внедрить процесс или ритуал, провести дискуссию, наладить коммуникацию и т.д.) без погружения на уровень техники.

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

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

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

P.P.S. Друзья эджайл-коучи, если вам кажется, что я здесь написал херню (или предлагаю херню, потому что какой из меня эджайл-коуч), напишите об этом, пожалуйста, в комментах. Буду вам очень благодарен 😊

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

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

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

А уже в Белграде меня догнало другое осознание - так это что же получается, я, наконец, вырос?

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

Так вот, вернёмся к истории. В тот же день я решил поделиться двумя этими радостными новостями в чатиках. И сделал роковую ошибку, потому что в ягуар-чате рассказал про Ягуар, а в кипрском gamedev-prosecco чате про виллу. Почему ошибку? Потому что в ягуар-чате мне сразу же рассказали какой ужасный ненадежный мотор этот 2.7 дизель, как мне надо опасаться того, что у него переломится коленвал и как я ничего не могу с этим поделать - как бы аккуратно я ни водил, как бы тщательно машину ни обслуживал, это может случиться буквально в любой момент. А в кипрском чатике мне быстро объяснили, что район, который я выбрал, ужасно криминальный и весь населён нелегальными мигрантами, что хозяин готов всё для меня сделать ровно потому что вообще сдать что-то в этом районе это большая удача и вообще лучше забыть про депозит, который я оставил за виллу, и искать что-то совсем в другой части острова.