Воркшоп про то, как собрать QA команду

Настю Шарикову я знаю еще с первых сезонов Podlodka Crew, QA направление в которой она помогала организовывать. Настя – крутая, и у нее много интересного опыта в организации работы команд мобильного тестирования, который она приобрела как в работе в продуктовой компани, так и занимаясь консалтингом стартапов.

Так вот, Настя вместе с ребятами из Otus проводит открытый воркшоп про то, как вообще собирать команды тестировщиков, какие ошибки при этом можно совершить, и как понимать, насколько хорошо эта команда работает. Если в вашей команде есть тестировщики, или вы подозреваете, что работу соседней команды можно улучшить – приходите!

📆Дата: 27 июля, 19:00 по Москве
👉Регистрация

Нативная интеграция. Информация о продукте на сайте www.otus.ru

Подлодка про холакратию

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

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

Фреймворк для оценки экономического импакта любой работы

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

📈Increase revenue: любые изменения, которые ведут к тому, что либо у продукта появляется больше пользователей, либо получается заработать больше с текущих пользователей.
🔐Protect revenue: действия, направленные на то, чтобы удержать текущий рынок, повысить лояльность существующих пользователей, или поддерживать требуемую скорость разработки.
📉Reduce costs: все, что помогает резать косты, в том числе процессные улучшения и автоматизация.
✋Avoid costs: действия, которые помогают избежать возможных трат в будущем, митигация рисков.

Курс по управлению командой разработки от Практикума

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

Учеба идет 5 месяцев, уделять ей надо в среднем 8 часов в неделю. Вот что по темам:

- Постановка задач и делегирование
- Личное развитие и эффективность
- Работа с сотрудниками: адаптация, развитие, обратная связь
- Развитие команды и продукта
- Решение процессных проблем и улучшение цикла разработки

Попробовать интерактивный учебник вы можете бесплатно, первый модуль там открытый. Весь курс начинается 31 августа, не пропустите!

👉Начать учиться

Реклама АНО ДПО "Образовательные технологии Яндекса", ИНН:7704282033, erid: LjN8KTwHB

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

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

Так вот, по ссылке в заголовке – другая статья. Я не согласен со всеми советами оттуда, но меня очень привлекла одна конкретная ее часть – упор на реферралки от уже нанятых сотрудников. Где бы я ни работал, реферральная программа приносила самых клевых и замотивированных кандидатов, но при этом эйчары постоянно продалбывали ее правильно организовать. В статье приводится одна клевая практика, которой я когда-нибудь воспользуюсь – если у вас нет времени и желания выстраивать полноценную реферральную программу, можете провести one-time event, на котором за каждый реферрал от коллег вы будете выдавать им какой-то мерч, протеиновый батончик или еще что-то вкусное.

Большой гайд по менторству

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

Ну и дежурное напоминание про замечательный бесплатный менторский сервис, который делает Георгий Могелашвили – getmentor.dev.

Вебинар про мотивацию от участников нашего чата TLBootcamp

Ребята в нашем чате самоорганизовались и проводят вебинар про мотивацию сотрудников к обучению. Дмитрий Болдырев, организационный психолог, расскажет доклад про то, из чего образуется мотивация, как на нее можно влиять, как провести границу между мотивированием и манипуляцией и, главное, как мотивировать сотрудников к обучению. После доклада – сессия ответов на вопросы, которую будет модерировать Виталий Шароватов.

📆Дата: 3 августа, 19:00 по Москве
👉Ссылка на Zoom

Новость для опытных продакт-менеджеров

Найден быстрый путь в Тинькофф — Product Manager Week Offer. Можно пройти онлайн-собеседование за выходные и присоединиться к команде уже через неделю. 

Дальше — создавать продукты для 30 млн пользователей, работать с данными, ориентироваться на свою экспертность и здравый смысл. Как работать, решать вам, — оценивают только результат. 

Оставьте заявку до 9 августа: https://o.tinkoff.ru/wo-product.2023

McNamara fallacy

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

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

Напоминает большую часть попыток компаний уходить в хардкорную data driven культуру🤷‍♂️

Бреслав и Ложечкин: Performance Management

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

Readability кода в Google

В Google есть интересная практика, направленная на повышение читаемости кода – readability reviews. Каждый pull request ревьюится не только связанными с конкретным компонентом людьми, но и как минимум одним экспертом в языке, на котором написан код. Эксперт в этом контексте – инженер, который хорошо знает лучшие практики конкретного языка, рекомендуемые паттерны, принятые в компании стиль кода и список библиотек.

С одной стороны, такой процесс добавляет жуткой бюрократии – вместо обсуждения действительно полезных вопросов, вы будете зарубаться с незнакомым вам человеком о том, насколько правильно названа какая-то переменная (намеренно утрированный кейс, я предполагаю, что такие вещи все-таки на уровне линтера закрываются). Но с другой стороны, в том числе благодаря этому подходу Google получает похожие друг на друга кодовые базы вне зависимости от конкретного отдела и продукта. А, значит, переход людей между проектами становится значительно проще.

🪚 Инструменты тимлида

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

✅ Таск-трекеры
Лидером оказался Todoist. Но как по мне, без разницы что использовать и вообще я цели на месяц веду снаружи, а тут операционные проекты, которые я делаю прямо сейчас.

Для прокачки своей системы здорово поможет Дорофеев “Джедайские техники”. Он притапливает за свой инструмент, но можно набрать кучу дельных советов для построения собственной.

📝 Заметки
Всех обошел Obsidian. Если кто не в курсе, это маркдаун-редактор с плагинами. При помощи него можно сделать собственный репозиторий знаний а-ля маленькую Википедию.

Тоже им пользуюсь, но считаю, что только для лидских задач этот инструмент – оверкилл.

Возможно вам надо вести карточки сотрудников, проекты, ну может какие-то общие мысли. Из-за того, что структура заранее известна, можно обойтись даже Apple заметками.

Еще в пуле инструментов оказались:
- Confluence. Ну а почему бы не держать доку и рабочие заметки в одной системе?
- Miro. Медитировать над организационной структурой в нем намного удобнее, чем в том же мардаун-файле. Отдельный плюс – удобство шаринга и совместной работы

🎯 Фокусировка
Часть ребят использует технику Pomodoro с фокусировкой интервалами 25-45 минут.

Приложений и физических трекеров – бесконечность.

Сам комбинирую технику с режимом “Do not disturb”. Мне помодорки помогают в двух случаях:
- Сфокусировано поработать
- Стартануть неприятное дело, которое прокрастинирую. Спустя одну-две помодорки разгоняешься и уже идет с удовольствием

✉️ Почта / мессенджеры
Планирую написать “Новейшие правила деловой переписки”. В ней будет одна страница, в которой будет капсом: не читать почту.

У нас есть корпоративный мессенджер, туда сам залезаю раз в неделю.

Я шел от идеи “если ответить на сообщение спустя час – мир не рухнет”, и вот что со мной стало… Если что, про почту наброс, туда залезаю тоже раз в неделю.

Страдают только финансовые аналитики, которые подбивают ФОТ раз в квартал и пишут письма, а когда реакции нет – пытаются догнать в корпоративном мессенджере. Но в остальных 99% случаев все работает прекрасно.

Основная переписка команд происходит в телеге. Знаю, что некоторые заводят отдельные аккаунты. Мне хватает папки.

📅 Календарь
Тут вообще скучно. День, а лучше два без встреч. Забитый час каждый день под обед.

Встречи по возможности перевожу в переписку.

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

—

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

Если есть мегатулзы неупомянутые выше, делитесь 😉

#тимлидство

Как повышать людей в корпорациях

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

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

В статье дают несколько советов, как жить в таких условиях:

👉Важно повышать людей за разные виды вклада в общий результат, так как в итоге вам важны и те, кто умеет запускать сложные проекты, и те, кто обладает глубокими доменными знаниями и на ком держатся существующие системы, и те, кто выстраивает процессы в команде.
👉Как можно раньше привлекайте на свою сторону своих пиров, продавая им идею из предыдущего пункта.
👉Готовьтесь к обсуждению повышений с соответствующим комитетом/человеком заранее, подготовив всю нужную аргументацию и факты.
👉Если повышение случилось, расскажите о нем команде публично – это поможет людям откалиброваться в своих ожиданиях за что дается повышение.

Как помогать людям меняться

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

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

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

Знания-Ответственность-Полномочия

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

Always do Extra

Представьте, что вы делаете какую-то задачу, и она заняла у вас на 20% меньше времени, чем вы хотели на нее потратить. В этот момент у вас появляется следующая развилка:

1. Не делать ничего
2. Взять следующую задачу (doing more work в оригинальной статье)
3. Сделать текущую задачу лучше (doing extra work)

Отличие второго и третьего пункта в том, что выполнение задач на потоке – это обычная работа, то, что от вас ожидается. Выполнение extra work – возможность самому придумать цель, которая одновременно и проекту поможет, и прокачает какие-то ваши скиллы и знания. А заодно еще и поможет превысить ожидания и в каких-то случаях создать вау-эффект.

Так вот, автор топит за то, что в большинстве случаев на такой развилке лучше выбирать extra, а не more. При этом, конечно, важно не заигрываться в интересные задачи и не забывать о реальности.