302. Как нанимать людей и не сойти с ума

Есть компании, где программистов нанимают в 9 этапов. Девять, Карл! Может быть это специально сделано, чтобы остались только те, кто хочет работать именно у нас. Или те, кому больше некуда идти. Не знаю. Но уверен, что это сводит с ума. Я как-то 5 собеседований проходил и был довольно близок к помешательству.

Ок, девять это перебор. А у вас сколько? Три-четыре, наверное? Предварительный скрининг, тех. собес, собес с командой, битва с финальным боссом.

Последние годы нанимаю людей за одну встречу. Проходит она так:

— 45 минут техническое интервью. Минут 30 лайв кодинга, минут 15 технических вопросов. Проводит разработчик, я сижу молча. Важно начать именно с технического интервью и именно с лайв кодинга. Есть много людей, кто может заболтать. Но по скорости стука клавиш и шевелению извилин на лайв кодинге обычно все понятно без лишних слов.

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

— 5 минут я даю кандидату обратную связь. Прямо и честно. Возможно, я единственный в мире, кто так делает. Также назначаю дедлайн, когда вернусь с решением. Обычно это 2-14 дней.

Потом или отказ или офер. Если готовы сделать офер и кандидат готов его принять, приглашаю на дейли с командой. Кандидат слушает дейли и потом представляется и минут 5 болтает с командой. Потом найм.

Одна встреча на полтора часа. Всё. Никто не сошел с ума. Все счастливы.

Расписание инцидентов на продакшне:

Для команд в РФ: 31 декабря и 1 января

Для команд-релокантов: 24-25 декабря

Счастливых вам праздников!

#жизашиза

303. Все на митинг!

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

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

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

— У вас много созвонов и общих встреч?

— 1 час в неделю груминг для обсуждения задач. 15-30 минут каждый день дейли для текучки. Кажется, что это мало, если сравнивать с моими прошлыми работами.

— Вот! Это и есть ваше конкурентное преимущество! Пользуйся!

Я очень удивился. А потом подумал, а ведь точно!

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

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

304. Работа без официального графика

У нас в компании нет рабочих дней и часов.

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

ПРО ДНИ

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

В выходные обычно меньше пишем в чат. Но если кто-то написал — никто не против. Ему даже ответят.

Если кто-то недоступен целый рабочий день — он предупреждает об этом.

ПРО ЧАСЫ

Мы живем в нескольких часовых поясах, 5 часов разницы между крайними точками. Чтобы не путаться время встреч говорим по Москве — часовой пояс офиса.

Подразумевается, что мы все доступны для быстрого ответа и созвона в рабочее время. Но что такое рабочее время никто никогда не обсуждал. Проблем с этим не возникало. Кто-то начинает работать в 8 утра, кто-то в час дня. Наверное, можно считать временем доступности с 12 до 18 мск, но это не точно. Некоторые активно работают и обсуждают в чате что-то ночью.

Если кому-то надо забрать ребенка среди дня или куда-то съездить — он не предупреждает об этом, потому что в этом просто нет смысла.

ОЩУЩЕНИЯ

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

305. Самописные платежные админки

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

1. Упрощенный цикл проектирования и разработки

Обычно продуктовая разработка идет так: исследование > ТЗ > дизайн > разработка бэк/фронт > тестирование. Больше всего времени уходит на дизайн, разработку фронта и правку его багов.

Админка — это что-то для себя. Одна должна работать, но не обязана быть красивой и в корпоративной дизайн-системе. Поэтому я не подпускаю к админке дизайнеров и фронтендеров. Цикл упрощенный: ТЗ > разработка бэк > тестирование.

Стэк для фронта подбирается такой, чтобы с ним справился бэкендер. Бутсрап css какой-нибудь. Для Лавравеля на PHP и Джанги на Питоне есть фреймворки для админок. Рельсы — вообще лучше всех в плане “сделать админку одним бэкендером за день”.

2. Перекрестные проверки

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

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

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

306. Фидбек это важно?

Продуктологу надо слушать пользователей. Если пользователи просят, значит надо это сделать.

— Мы запилили эту фичу, потому что много пользователей ее просили!
— «Много пользователей» это сколько?
— Ну, постоянно пишут.
— В цифрах сколько?
— 7 человек.
— У вас же 100 тысяч пользователей!
— Ну, один из этих пользователей — наш директор.

Сколько процентов пользователей должны написать, чтобы прислушаться? 1%, 10%, 50%? А проценты считать от общего объема пользователей или от тех, кто хоть что-то написал?

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

Ну так что с фидбеком делать то? Вот простой алгоритм:

1. Надо иметь стратегию развития продукта. Не бояться ее постоянно корректировать.
2. Собирать фидбэк из любых источников.
3. Соотносить просьбы пользователей со стратегией.
4. Если просят то, что помогает стратегии — ставить в план. Даже если 1 человек попросил. Если просят то, что мешает стратегии — не делать, даже если тысяча попросила.
5. Если много пользователей просят то, что не соответствует стратегии, вернуться к п.1.

Самый короткий стаж на одном месте

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

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

А у вас как?

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

#жизашиза

307. Хороший баг себя проявит

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

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

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

БАГОВ ВСЕГДА ДОХРЕНА. Они копились годами. Регулярные ревизии ничего не давали. Сотни и сотни проблем, которые никто никогда не в силах будет исправить.

Некоторым коллегам это безразлично. Но я то нервный, я страдал.

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

С тех пор я живу счастливо. Если баг не правится за пару месяцев — он удаляется. Не архивируется, не анализируется, а тупо стирается. Как мудро говорят автомеханики про неполадки в машинах «хороший стук себя проявит». Если баг важный, он снова прилетит на доску. А если неважный, то и не жалко.

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

308. Голосуют ногами

Недавно я писал, что отзывы пользователей надо рассматривать через призму продуктовой стратегии. Хочу еще раз порассуждать на эту тему.

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

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

Если вам больно и обидно от негативных отзывов, вспомните, что главное голосование пользователей — ногами. Допустим, вашим продуктом регулярно пользуются 100 тысяч человек и каждый месяц вы получаете 1000 негативных отзывов. 99% людей проголосовало ногами «за продукт» и только 1% написал негатив. Впрочем, возможно этот один процент тоже проголосовал ногами за «остаться».

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

Транспрофессиональный переоход

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

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

Какие радикальные профессиональные переходы совершали вы? О знакомых тоже можете написать. Расскажите истории, как маркетолог стал моряком дальнего плавания, а егерь из сибирской тайги стал мастером маникюра.

#жизашиза

309. Много лет на одном месте

Моя родственница всю жизнь работала на одной работе. Она закончила институт, после него ее распределили в лабораторию при больнице и там она отработала 35 лет, пока не вышла на пенсию. Думаю, идея устроиться на другую работу у нее даже не возникала. Вполне типичная ситуация для Советского Союза. Хотя мои родители (ее ровесники) много раз меняли работу и даже переезжали в другие города ради карьеры.

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

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

С одной стороны я полностью поддерживаю идею работы на одном месте. Люди в моей команде часто работают много лет, а я стараюсь, чтобы им было интересно и они постоянно профессионально росли.

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

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

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

Вкалывают роботы, счастлив человек

Тут по радио сказали, что искусственный интеллект умнее всех нас вместе взятых и скоро заменит собой все профессии, включая правительство. К сожалению, меня AI пока не замещает. А я был бы рад…

Давайте помечтаем, какое конкретное дело на работе или в быту вы бы хотели поручить AI?

#жизашиза

310. Иерархия бэклога

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

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

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

Сохранять сфокусированность мне помогает иерархия бэклога и следующие принципы:

1. Стратегия. Должно быть понимание, в какую сторону развивается продукт в ближайшие пару лет. Надо сформулировать 1-3 North stars — ключевых метрик/целей. Пример: «Повысить ежемесячную выручку до 100М».

2. Эпики. Мыслить надо не фичами, а эпиками. Это значимое достижение, которое можно сделать за несколько месяцев. Например: «Подключить иностранные платежи». Каждый эпик должен внятно переоформить в какую-то North star. Мы планируем по 2-3 эпика на квартал.

3. Задачи. Каждая задача должна принадлежать какому-то эпику. Если пришла идея, которую хочется сделать, но она не попадает в запланированный эпик — не делайте ее. Конечно, есть мелочи, которые приходится делать вне очереди, но я слежу, чтобы доля задач «без эпика» была не более 10-20%.

Обычно в продуктовом бэклоге сотни и даже тысячи задач. Очень сложно с таким количеством работать. Эпиков же получается штук пятьдесят. Работать с 50 идеями проще, чем с 1000.

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

Любить сон

Сон — это удовольствие или потеря времени?

Хотите спать побольше или стремитесь сократить?

Любите вздремнуть, поплющить массу, всхрапнуть, покемарить?

#жизашиза

311. Парт-тайм сотрудники в продуктовых командах

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

— Вовлечены и понимали контекст что и для кого они делают.
— Профессиональны и внимательны, потому что «выстрел в ногу» будет болеть годами.

Прийти в команду на пару месяцев и сделать что-то полезное — почти нереально. Пару месяцев обычно уходит на «идеянахожусь».

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

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

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

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

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

Все, кто работал в той команде парт-тайм, параллельно работали в другой продуктовой компании. Ребята, кто приходил из заказной разработки (что логично для парт-таймеров) — быстро отвалились.

Украшения рабочего места

У меня на столе кроме мониторов и ноутбука ничего нет. Но некоторые любят украшать свое рабочее место.

Есть у вас фотография детей в рамке? Кактус? Безделушка? Антистресс? Грамота? Кубок?


#жизашиза

312. Адресно и конкретно

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

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

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

Надо обратиться:
1. адресно
2. конкретно

— Мужчина в зеленой куртке, подержите голову.
— Женщина в шляпе, наберите на телефоне 103 и вызовите скорую.

Метод работает в любых сферах деятельности.

Мост дизаярбл персон

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

А из прошлых эпох? Цезарь? Леннон? Джобс?


#жизашиза

313. Научное исследование: профилактика хронического стресса

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

Я не связан с медициной и попал в исследование как подопытный. Дело в том, что я давно езжу на мотоцикле, а для исследования нужны были именно такие люди. Сейчас объясню.

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

Академик Байдаков еще 40 лет назад выдвинул гипотезу, что при резком ускорении мозг немного сдвигается назад в черепной коробке, при этом снижается давление на лобные доли. Он проводил исследования на военных летчиках и парашютистах. Но из-за развала СССР опыты прекратили.

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

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

Но главное, метод работает! Езда на мотоцикле уже введена (пока факультативно) в программы курсов переподготовки руководителей при НИИФ. Я рад, что участвовал в этом эксперименте.

Если кто не боится научных статей, вот ссылка на исследование.

Это я пару лет назад во время исследований на полигоне в Ленобласти