Про руководство разработкой и продуктом | Олег Мохов

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

Кейс №4. Сениор или не сениор? Сегодняшний кейс просто формулируется и содержит много вопросов. Наняли сениора. Через неделю у него заканчивается испытательный срок, но за это время он сделал заметно меньше, чем мы ожидали. Теперь нужно решить, продолжать ли с ним работу. Вопрос: Как бы вы поступили в такой ситуации? Что выяснили бы за оставшуюся неделю, чтобы принять решение? Все кейсы — по тегу #кейсы@teamleading. Присылайте свои кейсы в директ или через форму.

Читалка для iOS: ищу бета-тестировщиков Давно не было новостей после того, как я решил развивать проект читалки. Всё это время я активно занимался мобильной версией и теперь наконец готов отдать её на бета-тестирование. Изначально я пошёл по простому пути и сделал приложение на основе WebView. Но в какой-то момент устал от бесконечных багов вроде «случайный двойной тап увеличивает всё, а вернуть обратно невозможно» и ненативных сценариев, которые то тут, то там вылезали наружу. В общем, мне это надоело настолько, что я решил полностью переписать приложение на Swift, сделав интерфейс нативным. Поэтому читалка для iOS — это, по сути, новый продукт. Разумеется, со своими багами 🙂 И теперь я ищу тех, кто поможет мне их найти. Для первого этапа мне нужно не больше 10 человек, готовых пользоваться приложением и делиться обратной связью. Со своей стороны обещаю потом пропиарить ваши Telegram-каналы, если они у вас есть. Если хотите поучаствовать в тестировании — пишите мне в личку!

Читалка для iOS: ищу бета-тестировщиков Давно не было новостей после того, как я решил развивать проект читалки. Всё это время я активно занимался мобильной версией и теперь наконец готов отдать её на бета-тестирование. Изначально я пошёл по простому пути и сделал приложение на основе WebView. Но в какой-то момент устал от бесконечных багов вроде «случайный двойной тап увеличивает всё, а вернуть обратно невозможно» и ненативных сценариев, которые то тут, то там вылезали наружу. В общем, мне это надоело настолько, что я решил полностью переписать приложение на Swift, сделав интерфейс нативным. Поэтому читалка для iOS — это, по сути, новый продукт. Разумеется, со своими багами 🙂 И теперь я ищу тех, кто поможет мне их найти. Для первого этапа мне нужно не больше 10 человек, готовых пользоваться приложением и делиться обратной связью. Со своей стороны обещаю потом пропиарить ваши Telegram-каналы, если они у вас есть. Если хотите поучаствовать в тестировании — пишите мне в личку!

Яндекс ❤️ Я отдал Яндексу почти 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. Профессиональные навыки требуют практики в реальной работе Сложно научиться управлять проектами, не управляя проектами. Но и просто вести один проект за другим недостаточно: можно годами повторять одни и те же ошибки. Янг предлагает встраивать практику в саму работу — выбирать задачи, которые заставляют развиваться, и добавлять условия, помогающие учиться. Вот пример, который можно попробовать. Сужаем «улучшить коммуникацию» до одного навыка: заканчивать встречу понятными договорённостями. Берём ближайшие несколько встреч и в конце каждой оставляем время на три вопроса: — Что решили? — Кто что делает? — Когда и с каким результатом возвращаемся? Вроде очевидно. Но самое интересное начинается, если предложить ответить участникам. Ты думал, что решение принято, а человек услышал, что вы пока обсуждаете варианты. Ты ждёшь готовый результат в пятницу, а он собирался в пятницу только начать. Вот вам и материал для практики. После встречи смотрим: где разошлось понимание? Что осталось недоговорённым? Как в следующий раз сформулировать точнее? Потом повторяем и проверяем, стало ли лучше. Причём люди могут одинаково понять решение, но не согласиться с ним или не иметь возможности его выполнить. Это тоже важно выяснить. Мне кажется, через эти три вопроса — что развивать, как увидеть результат и где практиковаться — план развития становится гораздо понятнее. А вы какие управленческие навыки пробовали тренировать целенаправленно? Как понимали, что стало лучше? © Paramount Pictures, «Кунг фу Панда»

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

Разбор кейса № 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. Присылайте свои кейсы в директ или через форму.

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

Концерт Канье Уэста в России, или при чём тут Agile? Наблюдаю за тем, что происходит вокруг концертов Канье Уэста, и не могу не поделиться своим экспертным мнением человека, который ничего об этом не знает. Если вы пропустили: недавно объявили, что Ye даст аж два концерта в октябре на «Газпром Арене» в Петербурге. Для России, где с 2022 года мировые звёзды практически не появлялись, это, мягко говоря, событие. Новость разлетелась повсюду, и многие начали надеяться: а вдруг вслед за Канье к нам снова поедут и другие артисты? И вот вчера «Газпром Арена» сообщила, что никаких договоров на проведение концертов не подписывала. Организаторы при этом уверяют: всё идёт в штатном режиме. Комичности ситуации добавляет то, что двумя постами ранее в аккаунтах Арены разыгрывают билеты на эти же самые концерты, которые не подписаны 😃 Основываясь исключительно на этих формулировках, могу сделать единственно возможный вывод: мы наблюдаем столкновение двух моделей управления проектами — Waterfall и Agile. Чтобы организовать концерт Ye по Waterfall, нужно: Позвонить Канье и договориться → позвонить на площадку и договориться → согласовать всё с властями → подписать документы → анонсировать концерты. В Agile всё иначе. Менеджер проекта одной рукой звонит на арену и уточняет свободные даты, другой — Канье и спрашивает, когда свободен он. Находит пересечение, просит всех пока ничего туда не ставить и кричит маркетологу: — Вася, запускай продажу билетов! Потому что если организовывать такой концерт по Waterfall, он, возможно, не состоится никогда. Как и многие другие проекты, глядя на которые со стороны, думаешь: «Что у них там за бардак?» А бардак там не потому, что никто не знает, что делать. Просто без него, возможно, не получилось бы вообще ничего.

Стратегия — это не список хотелок Я тут готовлю обзор на готовящуюся к публикации книгу Уилла Ларсона «Стратегия разработки» (кстати, по ссылке предзаказ с приятной скидкой). Книга напомнила мне про Ричарда Румельта и его подход к стратегии. Наверняка вы видели стратегию примерно такого вида: — увеличить выручку на 30% — выйти на новые рынки — повысить качество продукта — внедрить ИИ — стать лидером отрасли Выглядит солидно. Можно собрать презентацию, добавить графики, выступить перед командой. Проблема в том, что это не стратегия. Это список целей и хотелок. Румельт в книге «Хорошая стратегия, плохая стратегия» пишет, что у хорошей стратегии есть довольно простое ядро: диагноз → руководящая политика → согласованные действия. Давайте разберём. ▫️. Диагноз Сначала нужно честно ответить на вопрос: что именно мешает нам получить желаемый результат? Не «рынок меняется». Не «нужно ускориться». Не «у нас недостаточно инноваций». Это всё слова, за которыми может вообще ничего не стоять. Хороший диагноз выделяет ключевую проблему из всей сложности происходящего. Например: «Продукт перестал расти, потому что новые пользователи не доходят до первого полезного результата и уходят в течение первого дня». Это уже диагноз. Его можно проверить, обсудить и даже опровергнуть. И это важный момент: если вы неправильно определили проблему, дальше можно очень качественно идти не туда. ▫️. Руководящая политика Дальше нужно выбрать общий подход к решению проблемы. Например: «Мы сосредоточимся на активации новых пользователей: упростим первый сценарий и сократим время до получения пользы от продукта». Это ещё не подробный план. Это принцип, который помогает принимать решения. — Добавлять ли новую фичу? Если она не помогает активации — скорее всего, нет. — Делать редизайн онбординга? Да, если именно там теряются пользователи. — Запускать ли ещё одну рекламную кампанию? Наверное, не сейчас: нет большого смысла приводить больше людей в дырявую воронку. Хорошая руководящая политика не только говорит, что делать. Она ещё и помогает понять, чего делать не надо. ▫️. Согласованные действия И только теперь появляются конкретные инициативы: — сократить регистрацию с пяти шагов до двух — переделать первый пользовательский сценарий — убрать необязательные настройки из онбординга — добавить аналитику точек отваливания — ускорить загрузку первого экрана — изменить коммуникацию с новыми пользователями Ключевое слово здесь — «согласованные». Каждое действие поддерживает выбранную политику, а все вместе они работают на решение проблемы из диагноза. Если продуктовая команда переделывает онбординг, маркетинг приводит совсем другую аудиторию, а разработка занята платформой для фич, которые понадобятся через три года, — это не согласованные действия. Это просто несколько подразделений, у каждого из которых есть свой план. И вот здесь, как мне кажется, находится самая неприятная часть стратегии. Стратегия требует выбора. Нельзя одновременно делать ставку на рост, снижение расходов, выход в пять стран, качество, новую платформу, ИИ и ещё двадцать стратегических инициатив. Точнее, написать всё это в презентации можно. Но тогда реальную стратегию обозначат ограничения: количество людей, денег и часов в сутках. Обычно даже этот выбор будет довольно хаотичным. Короче, когда вам в следующий раз покажут стратегию, попробуйте задать пять вопросов: — Какую конкретно проблему мы решаем? — Почему мы считаем главной именно её? — Какой подход мы выбрали? — От чего мы решили отказаться? — Как действия разных команд поддерживают друг друга? Если ответов нет, то, скорее всего, перед вами не стратегия, а пожелания к будущему. Хорошая стратегия, по Румельту, — это не красивое описание того, куда мы хотим прийти. Это ещё и честный ответ на вопрос: что нам мешает и как именно мы собираемся с этим справиться.

Если руководитель не контролирует каждый шаг команды — всё развалится? Или наоборот, именно постоянный контроль мешает людям брать ответственность? Разбирались, существуют ли вообще «самоходные команды» и где проходит граница между доверием и потерей контроля — с гостями моего эфира: 🎙️ Галей Ширанковой — CPO социальных взаимодействий ВКонтакте, автором Telegram-канала «Полтора продакта» 🎙️ Олегом Моховым — руководителем разработки, автором Telegram-канала о лидерстве и управлении IT-командами Обсудили самые острые вопросы управления командами: 🔸что на самом деле означает «самоходная команда» и почему это не отсутствие руководителя, 🔸как вовремя отличить настоящую автономность от хаоса и безразличия, 🔸когда лидер обязан вмешаться, а когда лучше дать команде право на ошибку, 🔸почему продуктовые и технические KPI часто конфликтуют, 🔸чем отличается управление в стартапах и крупных технологических компаниях, 🔸нужно ли быть «переводчиком» между бизнесом и разработкой, 🔸как нанимать людей, способных работать самостоятельно, 🔸почему без понимания собственного стиля лидерства невозможно выстроить сильную команду. Полный выпуск уже на всех платформах, сохраняйте пост, чтобы посмотреть интервью в удобное время: 📺 YouTube 📺 Рутуб 📱 LinkedIn А как считаете вы? Можно ли действительно построить полностью автономную команду, или «самоходность» — это красивый управленческий идеал, который неизбежно разбивается о реальность?

Читалка. Перезагрузка 11 лет назад я сделал читалку. «Пожалуй, лучшую читалку для чтения Льва Николаевича Толстого онлайн». Нет, не так. 11 лет назад мы делали Яндекс Книги. Ничего общего с текущими Яндекс Книгами этот проект не имел кроме названия. Это был виджет в поиске Яндекса для покупки книг и одна из его фичей была «Предпросмотр книги». Сам сервис мы запустили в бету на ограниченный круг пользователей, а через две недели закрыли, так как наверху решили что проект не перспективен. Но что интересно, для предпросмотра мы сделали неплохой прототип читалки, который работает исключительно в браузере. После того как проект Яндекс Книги закончился я получил разрешение заопенсорсить Читалку, создал репозиторий и перенес код туда. Я рассказывал про читалку на русском и даже на английском. Но затем меня захватила работа и я забросил проект. Недавно я решил посмотреть заново на читалку, с учетом того что за 20$ в месяц теперь можно купить почти команду сениоров. Во-первых, потому что я сам много читаю. Во-вторых, потому что многих фич, которые я уже тогда реализовал, до сих пор нигде нет. Пара недель вайбкодинга и встречайте читалку 2.0... Всё ещё чисто браузерная читалка, просто кидаете файл с книгой и читаете... Теперь с поддержкой epub, закладками и цитатами, синхронизацией через гугл.драйв или яндекс.диск. Но при этом практически идеальную по типографике, дизайну и удобству использования. Это единственная читалка с режимом встроенных сносок и умеющая идеально сохранять позицию чтения кроссдевайсно. При этом в бэклоге ещё куча вкусных фич, и скоро я и их реализую. А ещё у читалки теперь есть маскот — Тиграша. В общем, пользуйтесь, и, если вам не сложно, то накидайте лайков этому посту и репозиторию. p.s. А ещё подписывайтесь на телеграм-канал читалки.