Saturday Night Hack

2021-09-07 10:00:04 ​​Менеджер проектов знает, как разработать новый продукт и собрать команду для его реализации. Станьте одним из таких специалистов после прохождения курса «Профессия менеджер проектов». Получите востребованную профессию с зарплатой от 100 000 рублей в месяц!

Project-менеджеры:
- управляют бюджетом, сроками и командой в компании;
- оценивают рентабельность и риски продукта;
- знают, как использовать IT и маркетинг для роста;
- умеют аргументированно доносить свои идеи и презентовать продукты.

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

Только сейчас действует скидка на курс! Регистрируйтесь по ссылке: https://clc.to/G8b5Qg Открыть/Комментировать

2021-09-03 18:00:59 ​​8 сентября, в 18:00 (Мск, GMT+3) команда Miro проведет бесплатный онлайн митап для разработчиков и тимлидов

В прямом эфире будут говорить о технологиях и людях, общаться и дарить огненный мерч. И, конечно же, слушать доклады:
Антон Медников, «Онбординг-процесс в Miro на примере личного опыта»;
Дмитрий Цыбин, «Регулярные релизы во время стремительного роста компании»;
Сергей Чернов, «Fluent setter’ы».

А под конец вас будет ждать круглый стол «Behind the glassdoor: Миро изнутри», на котором спикеры поговорят о жизни внутри компании и ответят на вопросы зрителей.

Подробности и регистрация на сайте.

Кстати, там же вас ждет задачка от спикеров митапа — за ее решение можно получить подарки и приглашение на собеседование. Загляните на сайт и проверьте свой уровень! Открыть/Комментировать

2021-08-31 17:14:01 Про кроссфит и развитие продуктов

В какой-то момент после того, как я начал заниматься кроссфитом, я задумался – как оценивают участников соревнований? Ведь на самом деле, это не один вид спорта, а много. Кто лучше – тот, кто больше всех потянул в становой тяге 200кг или тот, кто быстрее всех прогреб 1.5км? В итоге система оказалась супер-простой: в каждом комплексе у участников проходит отдельный зачет, а итоговый результат – это сумма мест. То есть если ты первый в становой тяге, десятый в гребле и пятый в бёрпи – то в итоге у тебя 1+10+5 баллов. После чего делается общий рейтинг по всем комплексам.

Самое интересное тут то, что очень часто победители в общем зачете не входят в топы в отдельных комплексах (реальную картину можно найти в результатах crossfit games). То есть вероятность стать победителем намного выше, если ты достаточно хорош в нескольких дисциплинах, чем если ты топ-1 в одной.

Уверен, что таких же принципов стоит придерживаться и в развитии продуктов (в широком смысле этого слова – от развития себя до развития компаний). Скотт Адамс (автор книги «How to Fail at Almost Everything and Still Win Big» и комиксов, которые вы наверняка встречали в интернете) пишет у себя в блоге: чтобы достичь экстраординарных результатов у вас есть 2 пути: стать лучшим в чём-то одном или войти в топ 25% в двух или более вещах.

Допустим, у вас есть выбор человека в команду. Один – нереально крутой программист. Он знает свой язык программирования лучше, чем Матц знает руби, Линус Торвальдс линукс, а Сократ то, что он ничего не знает. Но вот беда: с ним невозможно разговаривать, он непонятно пишет сообщения в мессенджере, все задачи делает в 2 раза дольше, чем рассчитывает, а его код в итоге никто не понимает. А второй – достаточно хороший программист (хоть и не ответил на собеседовании, почему люки круглые), он достаточно хорошо объясняет свои мысли (хотя иногда его не понимают), пишет тексты (хотя ему точно не хватает Ильяхова), а ещё как-будто что-то знает о продажах, потому что продакты его слушают и включают технический долг в планы. Кого вы бы наняли?

Или с другой стороны: есть 2 компании. В одной самые высокие зарплаты на рынке, но в команде отношения напряженные, проект – легаси, нет целей, лидеров, аналитики (ладно хоть есть печеньки на кухне). А во второй зарплата на 15% ниже, но понятный проект (хотя вы о нём ничего не слышали до этого), процессы (но недостаточно скрама), адекватный руководитель (но ни на одной конфе не засветился и блог не ведёт), компенсируют конференции с английским на 70%. Кого бы вы выбрали?

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

2021-08-27 18:30:08 Про постановку задач и законы UX

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

В применении этого закона появились и некоторые хаки. Например, в мобильных интерфейсах часто «кликабельная» зона кнопок больше, чем видимая. Или кнопка пуск в windows (кстати, она ещё существует?): вроде бы она всегда далеко, где-то в углу и размер её совсем не большой. Но из-за того, что экран ограничен простое движение куда-то вниз и влево точно приведёт к этой кнопке и можно не тратить время на прицеливание. Такая кнопка считается бесконечно большой.

Так вот, когда вы ставите задачи (как другим людям, так и себе) – вы в каком-то смысле занимаетесь проектированием «интерфейса этой задачи». А значит тут применимы те же правила:

- Чем сильнее контекст задачи отличается от текущего контекста того, кому вы её ставите, тем сложнее её выполнить (по аналогии с кнопками, далеко расположенными друг от друга). Имеет смысл группировать задачи по контексту (например, сначала делаем все задачи по проектирование архитектуры приложения, а потом переходим к HR)
- Чем больше описано контекста и деталей в задаче (аналогия – чем больше кнопка) – тем проще её выполнить. Опять же, даже если вы ставите задачу самому себе – намного проще взять и сделать ту, в которой нужно меньше разбираться.
- До некоторых пор даже малейшее добавление контекста сильно упрощает выполнение задачи, но переизбыток информации почти не влияет на результат.

В общем, не забывайте про интерфейс ваших задач. А если научитесь ставить «бесконечно большие» задачи – расскажите мне, как это делать. Открыть/Комментировать

2021-08-23 14:23:38 Что выбрать: личную или командную выгоду?

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

Чаще всего мы выбираем между быстрой, большой личной выгодой (экономим силы/время) и долгосрочной небольшой выгодой для всех. Очень похоже на дилемму заключенного где сотрудничество – это решение в пользу команды, предательство – решение в личную пользу. За исключением того, что тут никто никого реально не предает (если, конечно, не забывает писать тесты и обновлять документацию). Напомню, суть дилеммы – это выбор сотрудничать или предавать в ситуации:

- Если Вася и Петя сотрудничают – они получают некоторую выгоду
- Если Вася предает Петю, а Петя сотрудничает с Васей, то Вася получает максимальную выгоду, а Петя ничего не получает. И наоборот
- Если они предают друг друга – оба получают наименьшую выгоду.

В 1984 году Роберт Аксельрод в книге «The Evolution of Cooperation» описал различные тактики принятия решения в повторяющейся дилемме заключенного (когда Вася помнит, как вел себя Петя до этого и принимает своё решение основываясь на этом). Это были изначально враждебные или дружелюбные алгоритмы; жадные или щедрые; мстительные и прощающие. В эксперименте стратегии сталкивали друг с другом и смотрели, какие стратегии зарабатывают больше очков. В итоге лидировали:

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

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

P.S. Кстати, об этом же пишет Наваль Равикант в «Как стать богатым»: играйте в долгосрочные игры с постоянными людьми. Долгосрочные игроки обогащают друг друга. Открыть/Комментировать

2021-08-11 15:27:37 Про KPI, метрики и эффект наблюдателя

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

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

Постановки KPI – пример использования этого эффекта. Кажется, это позволяет нам упростить управление: обкладываем сотрудников со всех сторон метриками, дашбордами и планами на месяц, запускаем команду биг дата для измерения вовлеченности и увольняем всех неугодных (ну простите, не удержался). Но не всё так просто.

Во-первых, часто с помощью метрик мы лишь пытаемся подтвердить свою гипотезу. Типа, «так-так, кажется Василий не вовлечен. Давайте посмотрим, сколько сообщений в слак он отправляет? Вооот, я же говорил! Всего по 100 в день, а медиана по компании – 200!». Привет, confirmation bias, который помог нам подтвердить наши слова (и возможно пропустить по дороге пару опровержений). Но в реальности мы нашли лишь отклонение от нормы, но не причину. Возможно, Вася просто обладает редким навыком в одном сообщении сразу и здороваться, и свой вопрос писать. Это же не делает его не вовлеченным?

Во-вторых, конечно, из-за эффекта наблюдателя я, абстрактный не вовлеченный сотрудник, буду вести себя не так, как без надзора и стану ориентироваться на поставленные KPI. Но если вдруг сроки будут гореть, от результата будет зависеть моя премия, а в конце месяца мне нужно будет платить ипотеку – я буду придумывать механизмы, как эти метрики поднять любым способом. А на другие важные метрики, от которых явно не зависит моя судьба, я буду забивать (привет, законы Кэмпбелла и Гудхарта). А всё ради заветного бонуса. Причем в той или иной степени этому эффекту будут подвержены все, а степень эта будет зависеть от уровня осознанности, личных целей и размера платежа за ипотеку.

Основная мысль: метрики, дашборды и KPI – это упрощение, абстракция над любыми процессами и результатами. Они упрощают и ускоряют понимание общей картины, но скрывают детали. А значит:

– Они должны обозначать вектор, в котором нужно двигаться, а не быть целью;
– Они должны быть инструментом для поиска инсайтов и аномалий, а не инструментом для принятия решений. А в причинах этих аномалий нужно идти и разбираться.


Что почитать по теме?

– Морейнис про законы Кэмпбелла и Гудхарта
– Farnam Street про Observer effect
– Farnam Street про Confirmation bias

UPD: в комментариях напомнили ещё про джедайские техники:

– Дорофеев про Черный закон метрик Открыть/Комментировать

2021-08-05 19:10:09 Про объяснения

Чем больше наблюдаю за общением людей, тем больше замечаю, как они не понимают друг друга. Очевидно, КПД любых коммуникаций всегда меньше 100%, ведь знания не копируются через cmd+c/cmd+v из головы в голову. Но часто люди просто игнорируют этот факт и не задумываются о качестве своих объяснений и не пытаются их оценить и улучшить. Кажется, что самого факта объяснения достаточно, чтобы их поняли.

Вообще, 100% КПД коммуникаций – это главное достоинство фуллстеков (T-Shape/E-Shape/etc), ведь у них коммуникации происходят внутри головы. Но обычно нужно работать с командой, а значит стоит задуматься о качестве.

Я, конечно, не смогу на 100% передать свои идеи, но попробую накидать, о чем можно задуматься:

А не рассказываю ли я это для себя?

Из-за ошибки Хайндсайта («эффект послезнания») будет казаться, что вы рассказываете очевидные вещи и будете их пропускать. Но очевидны ли они собеседнику? Лучше уточнить.

А в чем цель?

Я хочу кому-то что-то рассказать. Но зачем? Рассказать о своём продукте можно:

– Клиенту, чтобы он вам заплатил. Объяснить нужно ценность продукта для него
– Инвестору, чтобы он дал вам денег. Нужно объяснить, почему продукт приумножит его вложения
– Потенциальному сотруднику, чтобы он пришел к вам работать. Объяснить нужно сложность/ интересность задач и крутость команды.

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

А какой контекст?

С кем мы общаемся? О чем они знают? О чем могут не знать? А достаточно ли ответов на вопросы «что?» или «как?», может стоит больше рассказать «зачем?». Будут нас слушать или читать? В какой обстановке? Сколько у них времени? Ответы на эти вопросы направят объяснение в нужную сторону, определят его глубину и придадут ему нужную форму.

А не хочу ли я показаться слишком умным?

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

Но может ваша цель именно в расширении контекста и вам, например, хочется людям рассказать про ошибку Хайндсайта или кошелёк Миллера в посте про коммуникации?

А что почитать по теме?

– Пост Евгения Казначеева про теорию документаций – тут можно узнать про разные типы документаций и их цели.
– Книгу Ильяхова «Ясно, понятно» – тут вся книга пропитана идеей того, что нужно думать о слушателе/читателе, контексте и целях с тысячами примеров.

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

«The degree to which a system feels human and goal-oriented in its interactions reflects how well its creators interacted with each other.» Erika Hall, Conversational Design Открыть/Комментировать

2021-07-28 11:57:10 Все статьи про проведение 1:1 обычно написаны менеджерами для менеджеров. Решил исправить это и написал на хабр гайд про проведение 1:1 для разработчиков (который на самом деле подойдёт для всех).

Если правильно готовить 1:1 – это отличный инструмент вашего роста и построения комфортной среды на работе, пользуйтесь им. Открыть/Комментировать

2021-07-26 13:28:56 No gos

Часто релизы и тесты новых продуктов/фич/процессов тормозятся не из-за их основной гипотезы, а наоборот – из-за редких корнер-кейсов или добавления «приятных мелочей». Обсуждения, как их разрулить затягиваются, приходится привлекать всё больше людей, а решения начинают раскрывать всё больше технического и дизайнерского долга в продуктах, а значит увеличивают время разработки «хорошего решения».

Мы в работе стараемся не стопориться в таких ситуациях, а просто явно договариваемся о том, что мы не будем делать. Например:

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

Не могу представить себя лет 7 назад, мыслящим так же: «Это что, мы умышленно неработающее приложение выкатим на пользователя!?». Но оказалось, что так живётся намного лучше: продукты эволюционируют быстрее, данных собирается больше, а митингов, где мы решаем проблемы для 0.001% наших пользователей стало меньше. А часть идей всё равно приходится откатывать, так что корнер кейсы вообще не приходится решать.

Главное в таком подходе – фиксировать «долги» и обязательно к ним возвращаться. Вот тут мы часто обжигались – некоторые проблемы были понятны ещё на этапе разработки, но нигде не фиксировались и потом выстреливали в колено.

В общем, заранее договориться о том, что вы не будете делать – отличный способ ускорить разработку. А в книге Shape Up от Basecamp авторы вообще предлагают делать no gos частью описания любого проекта. Открыть/Комментировать

2021-07-23 10:01:38 Как ставить задачи джунам?

Самый быстрый ответ на этот вопрос: максимально детально. Но давайте копнём глубже.

Я как-то писал, что рост сотрудников можно оценивать по количеству конкретных задач, которые им ставят. Недавно я понял, что кроме метрики количества задач, есть ещё обратная – количество принимаемых решений. Так джуну ставят много четких указаний и он принимает мало решений, а чем «синьорней» он становится – тем больше он принимает решений сам и меньше выполняет конкретных задач, причем чем дальше – тем выше качество этих принимаемых решений. Он может сам находить проблемы, реализовывать решения (или раздавать задачи другим).

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

- Покажите проблему, а не только решение. Так будет «тренироваться нейронка», которая в дальнейшем для подобных задач будет находить подобные же решения.
- Поясните решение и ответьте на вопрос «почему?». Не «добавь индекс в базу данных», а «добавь индекс, иначе будет работать медленно. Можешь локально попробовать сделать то-то – увидишь, что всё тормозит. Кстати, explain analyze до/после поможет понять детали»
- Расширьте его кругозор, делитесь опытом (и не только своим). Вместо коммента на код-ревью «добавь контекста и переименуй переменную из users в `availableUsers`» можно написать тоже самое + добавить «Кстати, про именование можешь посмотреть классный доклад или почитать мини-книжку Naming Things!».
- Оставьте нерешенную проблему. Легко привыкнуть к тому, что в задаче приняты все решения и нужно просто «поработать руками». Но для роста нужно обратное и хорошо бы сразу тренировать «мышцу» принятия решений, поэтому оставьте место, где этим можно заняться

А есть ещё мнения по этому поводу?

Мы договорились с Евгением Антоновым, автором канала Тимлид Очевидность, написать посты на эту тему. Его вариант я ещё не видел, но знаю, что он будет тут – го читать. Открыть/Комментировать