Про руководство разработкой и продуктом | Олег Мохов 🕘 история названий (1)

Яндекс ❤️ Я отдал Яндексу почти 15 лет своей жизни, и не могу остаться в стороне происходящего. Сила Яндекса в людях, которые там работают и я уверен что в эти выходные у ребят их не было... Мы, пользователи Телеграма, мало что можем кроме слов. Но всё же мы можем поддержать ребят подпиской на их личные каналы. Поэтому сегодняшний пост про таких людей. — Юра Ремнёв — руководитель разработки, пишет про работу и жизнь — Никита Дубко — продакт Яндекс Контеста, ведёт два блога про две стороны своей карьеры верстальщицкую и продуктовую — Миша Трошев — руководитель разработки в рекламе. Очень люблю Мишин слог и юмор — Рома Хатипов — руководитель разработки в Поиске, тут его личный блог, отдельно отмечу Ромину систему заметок. — Эрик Бурыгин — руководитель тестирования разработки, а так же член ПК TeamLead Conf, пишет про руководство и свою книгу) — Настя Абрашитова — руководитель DevTools, а так же автор подкаста «Три тимлида заходят в бар», много пишет про свою работу. — Женя Антонов — технический менеджер в инфре, а так же автор подкаста «Три тимлида заходят в бар», очень много и классно пишет про руководство. — Настя Котова — старшая фронтенд-разработчица, пишет про кишки Node.js — Егор Филиппов — честно, запутался уже где и кем он руководит, но его слог и юмор меня просто восхищают — Ира Магницкая — продакт Контеста, пишет про свою жизнь — Антон Субботин — фронтендер и руководитель в Практикуме Ребята, держитесь! Яндекс делают люди, и здесь много разных классных людей и это только те, кого я с ходу вспомнил. Я готов добавить ваш канал, если вы Яндексоид — пишите в директ. Потому что сердце Яндекса — это яндексоиды ❤️

Кто был на Avito.Tech.Conf в эти выходные, с вас однозначный лайк 👍 Видели фотографии и посты о ней — и это реально было вау! Чего только фиолетовая «Нива» стоит! А если серьезно, то конференция собрала более 1000 IT-менеджеров — CTO, технических директоров и руководителей разработки из разных компаний. Говорят, что свободных мест не осталось. Полными были и залы с докладами и воркшопами от TL и C-level Авито, и, конечно, зоны активностей: тимлид-«техосмотр», 1–1, управленческий покер и «тихий аукцион» с редкими вещами. Да там даже открыли IT-погребок с фирменными соленьями (а такого точно ни на одной конфе не было)! Короче, респектуем ребятам из AvitoTech за такую конференцию и дух комьюнити, который удалось поймать и сохранить! Но если в этом году не удалось побывать офлайн, смотрите запись трансляции: – на YouTube – в VK Ждем Avito.Tech.Conf в следующем году 🥰

Как руководителю тренировать навыки? В плане развития руководителя написано: «Улучшить коммуникацию». Окей. А делать-то что? Больше общаться? Прочитать книгу? Сходить на курс? Провести ещё сто встреч? Можно всё это сделать, а потом обнаружить, что люди по-прежнему выходят с твоих встреч с разным пониманием того, о чём договорились. У Скотта Янга есть интересный разбор такой практики. В шахматах или музыке проще определить, что именно ты тренируешь и как выглядит хороший результат. В работе руководителя с этим сложнее: ситуации разные, результат зависит от многих людей, а обратная связь может прийти через несколько месяцев. Янг выделяет три вещи, которые стоит учитывать, когда переносишь осознанную практику в профессиональную работу. 1. «Что учить» — так же важно, как «как учить» Можно старательно развивать навык, который почти ничего не изменит в твоей работе. Поэтому сначала стоит разобраться: чего тебе сейчас не хватает для решения реальных задач? Если после встреч люди расходятся с разным пониманием решения, возможно, стоит тренировать умение формулировать договорённости. Если не приносят проблемы вовремя — разбираться с тем, как ты реагируешь на плохие новости. «Улучшить коммуникацию» в этих случаях будет означать совершенно разные вещи. 2. Показать навык бывает так же сложно, как освоить его В шахматах есть общие правила и сравнительно понятные критерии результата. А как понять, что человек стал лучше руководить? Команда выполнила план. Это благодаря руководителю? Сильным специалистам? Удачному стечению обстоятельств? Янг обращает внимание на то, что в профессиональной работе важны и сами навыки, и свидетельства того, что они у тебя есть: выполненные проекты, репутация, люди, которые могут подтвердить твой вклад. А я бы добавил сюда ещё один вопрос для плана развития: по каким изменениям мы поймём, что человек научился? «Прошёл курс» нам этого не покажет. Я, кстати, часто наблюдал, как люди ставят знак равенства между «знаю и применяю» и «прошёл курс». 3. Профессиональные навыки требуют практики в реальной работе Сложно научиться управлять проектами, не управляя проектами. Но и просто вести один проект за другим недостаточно: можно годами повторять одни и те же ошибки. Янг предлагает встраивать практику в саму работу — выбирать задачи, которые заставляют развиваться, и добавлять условия, помогающие учиться. Вот пример, который можно попробовать. Сужаем «улучшить коммуникацию» до одного навыка: заканчивать встречу понятными договорённостями. Берём ближайшие несколько встреч и в конце каждой оставляем время на три вопроса: — Что решили? — Кто что делает? — Когда и с каким результатом возвращаемся? Вроде очевидно. Но самое интересное начинается, если предложить ответить участникам. Ты думал, что решение принято, а человек услышал, что вы пока обсуждаете варианты. Ты ждёшь готовый результат в пятницу, а он собирался в пятницу только начать. Вот вам и материал для практики. После встречи смотрим: где разошлось понимание? Что осталось недоговорённым? На следующей встрече пробуем изменить одну вещь. Например, явно разделяем обсуждение вариантов от принятого решения: «Вот здесь мы пока выбираем, а вот это уже решили и делаем». В конце снова сверяем понимание. Стало ли меньше расхождений? Если нет — разбираемся, что ещё мешает. При этом люди могут одинаково понять решение, но не согласиться с ним или не иметь возможности его выполнить. Это тоже важно выяснить. Мне кажется, через эти три вопроса — что развивать, как увидеть результат и где практиковаться — план развития становится гораздо понятнее. А вы какие управленческие навыки пробовали тренировать целенаправленно? Как понимали, что стало лучше? © Кадр из «Кунг-фу Панды» (2008), DreamWorks Animation.

А слайды потом пришлёте? На сайте Мартина Фаулера вышла статья про принципы хороших слайдов. Автор, Сумит Могхе, разбирает довольно знакомую проблему: мы пытаемся одной презентацией решить сразу две задачи — помочь себе выступить и дать людям материал для самостоятельного изучения доклада. Представьте презентацию и слайд с восемью пунктами. Докладчик объясняет первый, вы уже прочитали восьмой. Он ещё рассказывает вводную, а вы уже не согласны с выводом. Автор предлагает смотреть на слайды как на дополнительный визуальный канал. Вы говорите, а на экране постепенно появляется то, что помогает понять мысль: схема, график, фотография, короткий тезис. Каждый новый элемент появляется тогда, когда вы готовы его объяснить. И совершенно неважно, получится из этого пять слайдов или двадцать или четыреста (Привет, Рома и Никита). Мне кажется, это практичнее советов вроде «сократите количество слайдов», оставьте суть и главную мысль. Можно сократить презентацию до десяти слайдов и получить десять плотно набитых шпаргалок. Но ок, даже так может быть ок, но дальше возникает вопрос: а что отправлять после выступления? Человек открывает файл, а там три картинки, стрелочка и слово «Ответственность». На докладе всё складывалось в понятную историю. Через месяц уже сложно вспомнить, что именно спикер хотел этим сказать. А если человек вообще не был на выступлении? Автор предлагает готовить отдельный материал: краткий конспект или слайды с заметками докладчика. Получатель сможет разобраться без вашего присутствия. Возможно, есть смысл делать две версии слайдов: одну для выступления, вторую — для чтения, с пояснениями и выводами, и в ней убирать постепенное появление в том числе. Работы больше, зато у каждой версии понятная задача. А ещё можно делать расшифровку доклада, как делают, например, Саша Брызгалова или Макс Дорофеев. Чтобы можно было спокойно прочитать, найти нужную мысль и вернуться к аргументам, которые на выступлении не успел обдумать.

Разбор кейса № 3. Сотрудник регулярно смотрит видео ⠀ Давайте разберёмся. В целом подписчики всё верно разложили: по большому счёту, в этом кейсе и кейса нет. Чем человек занимается в рабочее время — его личное дело, если к качеству и результатам его работы нет претензий. ⠀ И всё-таки один важный момент вы пропустили. Вы рассматривали ситуацию исключительно со своей позиции: «Мне это не мешает — значит, проблемы нет». Но у этой истории есть и другая сторона. ⠀ Когда-то давным-давно в Студии Артемия Лебедева можно было курить прямо на рабочем месте. Затем Артемий прочитал книгу Аллена Карра, бросил курить, а заодно ввёл запрет на курение в студии. ⠀ К чему здесь эта история? К тому, что нельзя забывать о принятых в компании правилах. ⠀ Если в вашей компании нельзя смотреть видео на рабочем месте, то, увы и ах, сотрудник нарушает установленное правило. Причины появления такого ограничения могут быть совершенно разными. Насколько оно разумно — отдельный вопрос. Но пока правило действует, его нужно соблюдать. ⠀ И если руководитель видит, что кто-то это правило игнорирует, он должен отреагировать. ⠀ Все кейсы — по тегу #кейсы@teamleading. Присылайте свои кейсы в директ или через форму.

Кейс №3. Сотрудник регулярно смотрит видео Сегодняшний кейс и простой, и непростой одновременно. По пути на кофепоинт вы проходите мимо сотрудника и регулярно замечаете, что он смотрит разные видео. Причём не на весь экран, а в небольшом окне — в режиме «картинка в картинке». Что будете делать? P.S. Предлагаю рассмотреть три варианта: вы его руководитель, коллега из смежной команды или вообще не знакомы с этим человеком. Все кейсы — по тегу #кейсы@teamleading. Присылайте свои кейсы в директ или через форму.

«Приключения Электроника» как экспресс-курс по LLM Смотрю с детьми советские «Приключения Электроника» и ловлю себя на том, что половину фильма легко переложить на современные реалии. Сам Электроник — LLM в корпусе робота. Знаний море, контекст понимает, но без обвязки, скиллов и нормального описания задачи действует довольно прямолинейно. «Крути педали, человека спасать надо» — обучение на лету. С велосипедом система быстро разбирается. «Цель игры — забить шайбу в ворота» — уже классическая ошибка постановки задачи. В какие именно ворота, не уточнили, поэтому Электроник забивает в ближайшие. Формально цель достигнута, фактически матч чуть не проигран. Уточнение промпта вида «не те ворота» не помогает, робот начинает вести шайбу по кратчайшему маршруту, и попадает всё время во вратаря. После нескольких безуспешных попыток уходит в цикл («Смотри, на второй круг пошли. Это не хоккей, а марафон какой-то»). Писать в тетради почерком Сыроежкина — отдельный скилл. Поэтому Электроник может решить за него задачи и аккуратно всё записать. Но в промпте было только «реши», без уточнения «методами, доступными шестикласснику». Ответ правильный, а решение учитель не принял. Собака Рэсси — субагент. Понимает команды Электроника, может самостоятельно выполнить поручение, а между вызовами чаще всего находится в замороженном состоянии. Сыроежкин, который делегировал Электронику школу, спорт и домашние дела, — ранний кейс чрезмерной автоматизации. Сначала кажется, что у тебя просто освободилось время. Потом выясняется, что вместе с рутиной ты отдал системе всё, в том числе свою репутацию, отношения с людьми и место в команде (пу-пу-пу...) Урри всё пытается найти у Электроника «кнопку» — универсальный системный промпт, который заставит его беспрекословно выполнять любые команды. Но кнопки нет: Электроник интерпретирует цели и действует исходя из собственной картины мира. А банда Стампа в итоге не взламывает Электроника технически. Она просто убеждает его, что кража картин — хорошее и полезное дело. Классический prompt injection: подменить контекст и заставить агента применить свои способности в чужих интересах. Профессор Громов при этом занимается не столько программированием, сколько alignment: пытается не просто добиться от системы правильных ответов, а научить её понимать людей и самостоятельно отличать хорошее от плохого. А вообще фильм классный и очень добрый. И мысль в нём для нашего времени довольно актуальная: если делегировать машине отдельные задачи, у человека появится свободное время. Если делегировать ей вообще всё — машина незаметно займёт место человека. Так что human in the loop нужен не только для контроля качества. Иногда он нужен, чтобы человеку самому оставалось чем заниматься.

Разбор кейса № 2. Как выбрать из трёх несовершенных решений ⠀ Итак, у нас есть три решения. Каждое закрывает два требования из трёх, а идеального варианта на рынке нет. ⠀ Главная ошибка в такой ситуации — продолжать сравнивать решения только по списку возможностей. ⠀ Я вижу два пути. ⠀ 1. Выбирать не лучшее решение, а наиболее приемлемый недостаток ⠀ Для начала стоит ещё раз проверить сами требования. Если интеграция, аналитика и управление доступами объявлены одинаково важными, скорее всего, приоритеты просто не расставлены. «Нам нужно всё» — это не критерий выбора. ⠀ Нужно понять, что произойдёт, если каждого из требований не будет. ⠀ Без интеграции команде придётся переносить данные вручную? Без аналитики станет невозможно принимать решения или отчёты просто окажутся менее удобными? Отсутствие гибких доступов создаст реальный риск или только усложнит администрирование? ⠀ После этого нужно оценить не только сам недостаток, но и стоимость его компенсации. Какое-то ограничение можно обойти изменением процесса, какое-то — дополнительным инструментом, а какое-то невозможно компенсировать вообще. В конце концов, как предлагают в комментариях, недостающую функцию можно навайбкодить. ⠀ Следующий вопрос — насколько обратим выбор. Если отказаться от решения через полгода будет дорого и сложно, его недостатки нужно оценивать особенно строго. Если систему можно быстро заменить, допустимо выбрать вариант, который подходит сейчас, и проверить его на практике. ⠀ В итоге я бы сравнивал решения по трём параметрам: ⠀ — последствия отсутствующей возможности; — стоимость временного обходного решения; — стоимость ошибки и последующей замены системы. ⠀ Выбирать стоит вариант, недостаток которого создаёт наименьший риск и дешевле всего компенсируется. ⠀ 2. Пилотировать все три решения ⠀ Второй вариант менее очевиден: пилотировать все три решения, но смотреть не только на их функциональность, а ещё и на взаимодействие с поставщиками. ⠀ Нам дали обещание вот-вот всё настроить и доработать — так давайте проверим, насколько эти обещания реалистичны. ⠀ Многие B2B-решения предлагают неплохие условия пилотирования. Можно развернуть каждое из трёх решений на трети компании и потратить сумму, сопоставимую с внедрением одного решения для всех. ⠀ Таким образом, через полгода вы протестируете сами решения и поймёте, с кем из поставщиков вам по пути. ⠀ Все кейсы — по тегу #кейсы@teamleading. Присылайте свои кейсы в директ или через форму. © Изображение принадлежит Союзмультфильму

Кейс № 2. Как выбрать из трёх несовершенных решений Вам нужно выбрать новую систему для работы команды (таск-трекер, например). Перед началом поиска вы определили три важных требования: — интеграция с текущими инструментами; — необходимая аналитика; — гибкое управление доступами. После изучения рынка осталось три решения. Первое поддерживает аналитику и управление доступами, но не интегрируется с вашими инструментами. Второе поддерживает интеграции и управление доступами, но не даёт нужной аналитики. Третье поддерживает интеграции и аналитику, но не позволяет гибко настраивать доступы. Каждое решение закрывает два требования из трёх. При этом команда считает важными все три и не готова однозначно отказаться ни от одного. Идеального варианта на рынке нет, но решение нужно принять. Как будете выбирать? p.s. Для тех кто любит посложнее — у вас есть доступ к производителям решений и каждый уверяет что в течение ближайших 3-х месяцев недостаток их решения скоро исчезнет и они вот-вот зарелизят эту фичу. Все кейсы — по тегу #кейсы@teamleading. Присылайте свои кейсы в директ или через форму.

Разбор кейса № 1. Сотрудник выносит конфликт в публичное поле Итак, давайте разберём кейс. Здесь важно разделить два вопроса. Первый: почему сотрудник изменил договорённость и решил уйти сегодня? Мне кажется, главное, что должен понимать любой руководитель: не надо пытаться угадать мотивы сотрудника. За его поступком могут стоять обида — что вполне объяснимо — и желание выйти из ситуации условным «победителем». Но это лишь предположения, на которых не стоит строить свои дальнейшие действия. Так вот, не надо искать ответа на первый вопрос. Нужно просто принять происходящее как новый факт. Обычно, спустя какое-то время, ответ или сам собой находится, или же оказывается не важен. Второй: что делать? Итак, сотрудник публично обвинил руководителя. Ответ на эти обвинения зависит от того, насколько они справедливы. Поэтому руководителю стоит задать себе неприятный вопрос: а я действительно ничего подобного никому не говорил? Если вы не говорили того, в чём вас обвиняют, достаточно коротко обозначить факты: решение о расставании было заранее обсуждено с сотрудником, сроки были согласованы, а выносить детали рабочих отношений в публичное поле вы считаете некорректным. Если же вы действительно обсуждали сотрудника с другими людьми и сказали то, чего говорить не следовало, прятаться за фразой «я не выношу рабочие отношения в публичное поле» не стоит. Это будет выглядеть не как принципиальная позиция, а как попытка уйти от ответственности. В таком случае ошибку нужно признать: да, я сказал лишнее; это было некорректно; мне не следовало обсуждать сотрудника за его спиной. Такое признание не требует публично разбирать качество его работы или раскрывать остальные детали конфликта. Но вступать в большой публичный спор не стоит в обоих случаях. Главная задача руководителя в такой ситуации — не победить в споре. Нужно завершить отношения, сохранить рабочее состояние команды и не сказать публично того, о чём позже придётся пожалеть. Разбираться в мотивах сотрудника необязательно, а вот разобраться в собственных словах и поступках — необходимо. И мотайте на ус, кому можно доверять и с кем можно шушукаться. Я не строю иллюзий на этот счёт: сплетни были и будут всегда. Знающие меня люди уже догадались, что этим кейсом я завуалировал происходящее в группе «Слот». Кэш, бери на вооружение. Все кейсы — по тегу #кейсы@teamleading. Присылайте свои кейсы в директ или через форму.