Архив недели
Понедельник
Привет, друзья! Меня зовут Лёша Шаграев, на этой неделе я с вами в этом отличном твиттере! :)
10 лет я работал в Яндексе и делал продукты, основанные на машинном обучении — Яндекс.Новости, интерактивные элементы Поиска, поисковые подсказки, Яндекс.Клавиатуру и ещё кучу всего. Недавно уволился и отправился покорять мир :) В свободное время инвестирую в стартапы.
Про меня и мою работу отлично рассказывает блог на Хабре: habr.com/ru/users/ashag…
Со мной можно дружить в fb: facebook.com/ashagraev
А вот и расписание тем на неделю!
Понедельник, 2 ноября. Умные Алгоритмы в продукте
Вторник, 3 ноября. Prototype first
Среда, 4 ноября. KPI и обратная связь
Четверг, 5 ноября. Четверг объявляется днём добра! Тема пока что остаётся секретной и неясной, понятно лишь одно: она будет очень доброй!
Пятница, 6 ноября: Что нового я узнал об управлении людьми, когда попал в западную компанию
Суббота, 7 ноября. Модные фреймворки для руководителей и не только
Воскресенье, 8 ноября. Воскресенье — лучший день, чтобы обсудить героизм на работе! Почему его нужно предотвращать и как это делать? Как геройствовать экологично, если этого всё-таки не избежать?
@produnderhood Базовый вопрос, но все же ориентированный конкретно на Яндекс. Реально ли попасть продактом в Яндекс без опыта работы и какие навыки надо обязательно иметь?
Фундаментальный вопрос для любого нового сотрудника — какую именно пользу своей новой команде он может принести, какое новое качество для неё создать. В первую очередь важно именно это, а не опыт и даже не конкретные скиллы. twitter.com/vistrish/statu…
Если вы можете чётко ответить на указанные вопросы, а эта польза и это новое качество ценны для команды, преград никаких нет.
Скиллы, тем не менее, нужны, но их набор формализуется при помощи интервью.
Описания конкретных вакансий лучшим образом отвечают на вопрос, что нужно от кандидата. У Яндекса есть страничка yandex.ru/jobs/ya-interv…, там есть и описания, и материалы для подготовки.
Полезно посмотреть и на другие компании тоже. Например, мне нравятся описания у Фейсбука, типа facebook.com/careers/jobs/5…
Впрочем, моя позиция такова, что с нуля лучше начинать в другой роли: разработчика, аналитика, тестировщика. Требования в этих ролях более чёткие, а ценный опыт получить они всё равно позволяют. Превратиться в менеджера при этом вполне можно в будущем.
@produnderhood У меня есть вопрос. Расскажи про свой распорядок рабочего дня на работе в яндексе. И какой распорядок сейчас?
Когда я работал руководителем большой команды разработки, я вставал довольно рано и час-два в начале каждого дня тратил на работу с "целями". Цели — это такой инструмент, в котором собраны главные высокоуровневые задачи подразделения. twitter.com/thebits/status…
Суммарно было вполне ОК иметь 30-40 целей на полгода-год. Работа с целями — это постоянный поиск рисков, разного рода багов и их исправление. И то, и другое присутствует постоянно, и это ОК.
Затем при необходимости я пару часов программировал сам, пока не просыпались коллеги и не начинались встречи :) Для меня было типично пилить прототипы (о которых подробнее поговорим во вторник) или какой-нибудь сложный код про ML.
После этого начинался основной рабочий день: разного рода митинги, среди которых и 1х1 с директами, и разные встречи с руководителями, но в основной своей массе встречи были ситуатавными и нерегулярными.
Вечером, когда сезон митингов закрыт, можно было устроить тимбилдинг с пиццей и просмотром футбола, сходить в спортзал или продожить писать код.
Когда нужно было подумать, что-то изучить, пощупать новые продукты, сформулировать стратегию и вот это вот всё — я делал это только утром, иногда на выходных и очень часто в командировках-отпусках. Тут важны свежая не нагруженная рутиной голова и фокус.
Сейчас я день делю на несколько тематических кусочков, каждый из которых требует нескольких часов работы. Наиболее распространённые виды: написание кода, изучение документации (она очень объёмна и разнородна), технические дискуссии, рабочие встречи.
Опционально досыпаю лекции и всякие выступления, работу со студентами, инвесторские встречи, ведение продуктовых твиттеров и прочую нерегулярную деятельность :)
Для сохранения работоспосоности мне важно не заниматься одним и тем же видом деятельности долгое время, хотя, конечно, зависнуть над кодом на 20+ часов подряд я всё ещё способен. Поэтому собирать день из разнородных кусочков мне очень нравится.
В перерывах можно делать что угодно: заниматься спортом, гулять, кушать, смотреть кино или даже спать. Могу поработать 6-8 часов, потом поспать часок, а потом ещё сделать что-нибудь делать новое классное на свежую голову. Отлично работает!
Часто при общении со стартаперами, начинающими продактами и даже опытными разработчиками я вижу, как люди слишком сильно полагаются на Умные Алгоритмы и Машинное Обучение.
Ошибка случается, когда от Искусственного Интеллекта хотят, чтобы он решил задачу, которую не может решить Естественный Интеллект.
Машинное обучение никогда не решит задачу, которую вы не можете решить сами. А даже если и решит — не будет понятно, насколько хорошо это решение и той ли вообще задачи.
Вы сами вполне можете нарисовать абстрактную картину по теме; вы можете понять, какой товар релевантен пользовательскому запросу; вы можете распознать потребность, сформулированную голосом. Поэтому и автоматические методы в этих областях вполне справляются.
За любым продуктом стоит вИдение того, каким он может быть для пользователя при идеальном воплощении. И понимание, насколько и в каком смысле от этой идеальной картины можно отличаться, чтобы продукт остался продуктом!
Первый пример. Стартап хочет сделать автоматическое ценообразование для определённого типа товаров и ищет инвестиции под соответствующую разработку. Почему это важно? Потому что специфика такова, что назначать цены вручную в нужных объёмах невозможно.
Но ведь алгоритм в любом случае будет иногда ошибаться. Как эти ошибки будут детектироваться и обрабатываться? На каком уровне они могут находиться, чтобы продукт был жизнеспособен? Какого рода логику этому алгоритму придётся реализовывать?
Без ответа на эти вопросы невозможно понять, осуществима ли такая разработка в принципе, будет ли она результативной, принесёт ли необходимый экономический эффект. Соответственно, непонятно, стоит ли выделять инвестиции :)
Второй пример. Руководитель продукта хочет внедрить ленту рекомендаций на главной странице своего сервиса. Какие именно элементы там будут показаны? "Ну, машинное обучение определит!"
Конечно, такой ответ никуда не годится и в большинстве случаев означает, что руководитель продукта отказывается думать, а никакой ценности в результате работы не возникнет.
В процессе обучения любая модель оптимизирует некоторую функцию полезности. Выбор этой функции полезности — один из ключевых вопросов для продуктов, которые основаны на машинном обучении.
Во многом история таких продуктов, как веб-поиск, является историей развития функций полезности. Чем ближе математическая абстракция к истинной пользовательской ценности, тем лучше работает алгоритм.
Но выбор этой функции — существенно продуктовый вопрос. Какие типы взаимодействий мы будем считать удачными? Какого типа контент там должен появиться? На каких модельные примерах мы проверим, что модель делает именно то, для чего была создана?
А даже если и получится сделать всё, что хочется — будет ли этот результат востребован пользователями?
Поэтому в любой задаче начинать необходимо с очень конкретных примеров желаемого результата. Эти примеры можно носить на UX и исследовать другими способами, затем можно строить прототип для проверки, что необходимые показатели качества достижимы в принципе.
Пример продуктового внедрения, которое потребовало проработки и прототипирования: habr.com/ru/company/yan…
Пример того, как эволюция способов измерения качества определила развитие продукта: habr.com/ru/company/yan…
Вторник
Однажды я сформулировал продуктовое задание для дизайнера вот в таких вот терминах (разумеется, это нарочито вопиющий пример). После этого произошло чудо: и дизайнер, и разработчики, и руководители внезапно поняли, что я им пытался объяснить на протяжении предыдущих недель!
Разумеется, им тогда сильно помог контекст: они в целом понимали, о чём речь, им не хватало важных деталей, чтобы сложилась картинка. Это тот самый контекст, которого не хватает вам, чтобы понять, что это за дурацкие каракули.
В другой раз я пытался придумать Яндекс.Репетитор и за пару ночей написал прототипчик на питоне и html, который хорошо работал внутри сети, там были рейтинги и рекомендации, какой-то набор задач и основные элементы функциональности.
Это позволило показать его на UX'ах живым людям, показать будущей команде разработки, чтобы они поверили в идею и пошли её реализовывать.
Прототипы невероятно полезны. Они позволяют проводить UX'ы и другие качественные испытания и быстро-быстро итерироваться, развивая своё понимание будущего продукта. Они позволяют достаточно точно уточнить задание на дизайн или разработку.
Незаменимы прототипы и при общении с заказчиками и, не побоюсь этого слова, с юристами. Если вам нужно сделать некоторую функциональность, вы можете буквально руками собрать несколько примеров того, как она будет выглядеть, и проверить эти примеры о лиц, принимающих решения.
Это гарантирует вам безопасность и позволяет экономить огромное количество ресурсов. Представьте себе, что для полноценной реализации некоторой штуки нужно потратить месяцы разработки, а на выходе можно получить, что идея какая-то не летящая и делать надо было по-другому.
Интересно, что менеджер, не обладающий навыками разработки, всё равно может создавать прототипы — да хотя бы банально в Sketch, я очень полюбил этот метод. В Sketch можно быстро накликать красивый и вполне себе функциональный интерфейс.
Лично я никогда не стеснялся делать прототипы при помощи стилуса или банального Paint'а.
Но особенно классно это работает, когда менеджер всё-таки может программировать. Тогда он может создать прототип не просто продукта, но будущей архитектуры приложения, заранее найти источники данных, апишки и всё прочее. Это невероятно упрощает и ускоряет дальнейшую разработку!
Поэтому всем рекомендую любую продуктовую разработку начинать именно с прототипа. Чем больше времени вы тратите на прототипирование, тем точнее вы поймёте, что на самом деле получится в итоге и будет ли оно в итоге работать.
Если вы разработчик и прототипа в начале работы у вас нет — рекомендую начать именно с его создания и проверить о заказчика, что это именно то, что требуется.
Если вы руководитель продактов, то рекомендую требовать с них прототипов на старте примерно любой разработки, которая требует больше чем несколько дней на реализацию.
Среда
Вообще, KPI — он не для того, чтобы хвалить и наказывать. Он для того, чтобы понимать, как сделать продукт лучше. В моих командах для получения пользы от KPI (а не вреда) использовалась пара важных трюков, о которых и хочу вам рассказать.
Первый трюк — регулярный пересмотр метрики. KPI должен являться измеримым выражением представления о том, что такое хороший продукт. Это представление постоянно уточняется благодаря появлению новой информации, изменениям в поведении пользователей и т.д.
Для каждого продукта имелся достаточно широкий набор изменений, про которые совершенно точно известно, улучшают или ухудшают они пользовательский опыт. Такой набор придумать несложно, особенно в части ухудшений.
Рассмотрим для примера рекомендации. Вместе с разумными рекомендациями можно показывать немного случайных, и масштабы ухудшения будут зависеть от количества и "степени случайности" этих вставок. Можно показывать рекомендации для других пользователей. Или поменять цвет текста.
Этот набор регулярно обновляется. Для этого используются все известные науке методы генерации гипотез: наблюдения за конкурентами и продуктами из других областей, глубинные интервью, UX'ы, коридорные опросы, DSAT'ы, просмотр логов и всё остальное.
И вот с определённой регулярностью все эти изменения запускаются в A/B тестирование. По результатам формируется метрика, которая наилучшим образом ловит все эти изменения: ухудшения считает ухудшениями, улучшения — улучшениями.
В этом процессе нельзя допустить того, что в машинном обучении называется переобучением, так что лучше эту работу поручать кому-нибудь, кто хорошо разбирается в этом вопросе.
На выходе получается метрика, которая наилучшим возможным образом описывает возможный спектр изменений в продукте. Основывать дальнейшую аналитику и целеполагание на такой основе — одно удовольствие!
Самое забавное — иногда изменения, которые были ухудшающими пару лет назад, сейчас, в изменившейся ситуации, стали улучшениями. Такое случается регулярно и лишний раз подчёркивает, почему важно все изменения сохранять и иметь возможность воспроизвести.
Второй трюк — обратная связь для новой метрики. Раз в самом начале генерируется набор идей по результатам внимательного изучения продукта, то возникает и набор примеров неудачной работы, которую хочется улучшить, а также примеров удачной работы, которую хочется сохранить.
В конце каждого цикла нужно проверять, что сделанные по новой метрике внедрения сказываются на этих примерах. Плохие примеры, хотя бы некоторые, исправляются, а хороших становится больше.
Если этого не происходит — либо мы где-то ошиблись, либо набор гипотез-улучшений не был достаточно полный, либо, в конце концов, мы достигли определённого предела, после которого заметные глазу улучшения получить уже сложно.
В последнем случае вполне может быть правильным смесить фокус на какой-нибудь другой аспект или какой-нибудь другой продукт. Ведь всем хочется делать важное и заметное!
Четверг
Если вы давно в индустрии и экологичность вашего состояния вызывает подозрения, всенепременно посмотреть доклады Вадима Макишвили! Пользуясь случаем, передаю привет Вадиму. Вадим, ты крутой! Раз: youtu.be/FxljIvLxUqQ, два: youtu.be/ytX7Dv3K7Go.
Котикам с синдромом самозванца можно почитать so06.tci-thaijo.org/index.php/IJBS…. Тут не так много ответов, зато это каноничный текст, который помогает понять, что вообще происходит.
Для улучшения настроения в команде решительно рекомендую поставить en.wikipedia.org/wiki/Among_Us, а затем практиковать, практиковать, практиковать! А если хочется улучшать настроение токсично, можно поставить gsp.com/cgi-bin/man.cg…
Про OKR'ы здорового человека можно прочитать тут: rework.withgoogle.com/guides/set-goa…
А Netflix придумал, как улучшать здоровье продакшена при помощи ломания продакшена! Гиперкомпенсация, не иначе. netflixtechblog.com/the-netflix-si…
Разработчики, использующие пробелы вместо табуляций, зарабатывают больше. Имейте в виду! stackoverflow.blog/2017/06/15/dev…
Самая модная техника для руководителей сейчас называется Radical Candor, и мы про неё ещё поговорим. А пока что посмотрите видосик: youtu.be/4yODalLQ2lM. Если узнаете себя или своих друзей в неправильном квадратике, - вы знаете, что делать!
А Google мудро замечает, что hope is not a strategy. landing.google.com/sre/sre-book/c…
Ну а если вам хочется побольше наукообразных аргументов (например, потому что обычных недостаточно) в пользу того, что это всё вообще имеет хоть какой-то смысл, почитайте en.wikipedia.org/wiki/The_Begin…
Пятница
Любимое развлечение по пятницам — осознавать, какая чушь казалась очень даже хорошей идеей в понедельник!
На четвёртый день в своей новой компании (это был понедельник; первый день пришёлся на пятницу) со мной в общей сложности три часа разговаривали на тему "почему героизм на работе — это плохо и его нужно избегать".
Правильный ответ — потому что для меня это может быть легко и совершенно экологично, а вот мои коллеги могут расстраиваться от того, что не могут работать столько же, сколько и я.
А в некоторых культурах считается неприличным не работать, когда работает начальник, даже если он работает в ночь с праздничной субботы на праздничное воскресенье.
Люди из этих культур, а равно и котички с синдромом отличника будут страдать, пока я развлекаюсь. Так что, даже если можешь работать по 20 часов в день, хотя бы не выставляй этот факт напоказ, иначе можешь навредить команде.
Ясно, что там была и часть про то, что переработки маскируют недостатки в процессах и автоматизации, но это очень скучная часть и мы её пропустим.
На международном уровне команд много, разработчиков много, всего много. Поэтому менеджмент можно сделать типа точной наукой, с регрессионным анализом и доверительными интервалами. Поэтому вот вам пара исследований, научно доказывающих, что нормально делай — нормально будет.
Gallup Q12 report: оказывается, команды и бизнес-юниты, в которых сотрудники субъективно чувствуют себя хорошо, добиваются лучших бизнес-показателей.
Так что атмосферу мы улучшаем не просто так, а в том числе и чтобы заработать. gallup.com/workplace/3217…
Исследование от Google: как сделать команду эффективной. Для достижения эффективности в гугл-специфичном смысле достаточно обеспечить психологическую безопасность, исполнение сроков, ясную структуру команды, ощущение сопричастности и важности работы.
rework.withgoogle.com/print/guides/5…
Задача менеджера в современном смысле, выражаясь словами классика, — guide a team to achieve results. Все три части важны, так что люди должны развиваться, не грустить и чувствовать себя коллективом, а дела должны делаться и ещё и в срок.
В русскоязычном сегменте на конференциях для руководителей разработки я несколько чаще встречал позицию, согласно которой достижение результатов и построение атмосферы — противоречащие друг другу виды деятельности.
Другими словами: если уж слишком прижмёт и надо изо всех сил шипать, то какой уж тут коллектив и какая уж тут атмосфера, надо шипать, а потом разберёмся. Ну так вот: это мнение является ошибочным! И в подтверждение этому — ссылки из предыдущего треда.
Ну и хватит на сегодня! Суббота скоро! Гогого, суббота — огонь! Отличной всем субботы! Надо готовиться! :-D
Воскресенье
Чтобы ваш рассказ казался наукообразным, а сами вы выглядели экспертом, придумайте для объяснения два каких-нибудь ортогональных измерения (всенепременно два!) и классифицируйте сущности по отношению к этим двум измерениям.
Вот, например, дихотомии Юнга. Вещь хорошая, но кто их упомнит? Их слишком много. Если измерение одно, то в этом не достаёт новизны: и так понятно, что делать надо хорошо, а не плохо. А вот два измерения — это прям оптимум!
Вот вам первый пример, называется ситуативный менеджмент. Есть два (два!) ортогональных типа поведения менеджера: директивный и поддерживающий. Сотрудники в зависимости от стадии своего развития нуждаются в определённой доле того и другого. Читать тут: guntergroup.com/situational-le…
Второй пример — тот самый radical candor, который в русской традиции обыкновенно переводится как "радикальная откровенность". Там измерения другие, но их тоже два: caring personally и challenging directly. Читать можно прямо на radicalcandor.com
А однажды я был на презентации продукта, создатели которого говорили буквально такое: важна лишь техническая экспертиза и понимание, что делать, и мы хорошо умеем и то, и другое. А вот наши неразумные конкуренты почему-то специализируются только в одной из этих частей.
Такие декомпозиции реальности воспринимаются очень хорошо! Они показательны, просты для запоминания и к ним очень сложно придраться. Разумеется, реальность намного сложнее и в ней намного больше оттенков, которые придётся учесть, но мы же сейчас про презентации.
Возможно, не все смотрели топовейшую презентацию GitLab с YCombinator'2015. Если не смотрели — обязательно посмотрите!
Как же круто, когда можешь за две минуты объяснить, в чём фишка и почему всё получится. Кстати, у них и правда всё получилось.
youtube.com/watch?v=HmrDjv…
Понедельник
Ну, всем пока! :-D
