Один на один

Самое полезное для меня открытие последнего времени — проведение общения с коллегами в формате один на один.
Прежде всего, формат один на один полезен при общении Старший/Младший, Куратор/Курируемый, Менеджер/Участник и т.д..
У нас в продуктовой команде Велвики один на один работает так:

  • Общение длится 1 час, а общаемся один раз в месяц.
  • С новыми участниками команды общение происходит чаще — раз в неделю.
  • Запросить встречу один на один может кто угодно и с кем угодно (пользуются редко).


В чём польза такого общения:

  • Доверительная беседа в течение часа позволяет обсудить не только рабочие, но и личные темы — помогает понять место работы в жизни коллеги.
  • Прекрасная возможность предоставлять и получать регулярную обратную связь и фиксировать прогресс - обратная связь становится неотъемлемой частью.
  • Когда установлено доверие, то легче и раньше поднимаются финансовые и коммуникационные вопросы — проблема гасится до того, как она становится проблемой.

Что важно для один на один:

  1. Надо готовиться и фиксировать итоги. Каждое новое общение это продолжение прошлого.
  2. Не отвлекаться. Оба участника должны быть сосредоточены на общении, а не на постороннем.
  3. Не ждать многого с первого раза. Первый раз получается скомканным — тот, кто раньше не участвовал в таких форматах, не сразу готов к доверительной беседе.

Кстати, подойти к коллеге и спросить у него: "Ну как дела? Всё хорошо?" или неформально пообщаться в кафе — это не один на один. Это как на улице спросить у знакомого: "Как дела?", на что он ответит: "Нормально! Сам как?". Вот и поговорили.

Как генерировать идеи для продукта

Внешние источники:

1. Тренды в вашей индустрии: что происходит на рынке
2. Что делают конкуренты
3. Какие фичи просят пользователи конкурентов
4. Что делают похожие бизнесы на других рынках (например, Amazon vs InstaMart in India)
5. Что обсуждают на конференциях/форумах/спец ресурсах в вашей индустрии
6. Какие фичи просят ваши пользователи

Внутренние источники

7. Что пользователи делают в продукте (или не могут сделать); как выглядит user journey
8. Что говорят пользователи, которые перестали пользоваться продуктом
9. Что говорят другие отделы, которые общаются с пользователями (саппорт, сейлзы, маркетинг)
10. Что говорит руководство компании/топ менеджеры/лидеры
11. Что делают другие команды в вашей компании, есть ли возможность для коллаборации или заимствования
12. Догфудинг (интенсивное использование продукта самой командой)
13. Небольшие сфокусированные дискуссии с командой
14. Работа в "обратную сторону" от видения: если вы хотите достичь X, какие проблемы должны быть решены

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

Как дизайнеры рэп читали

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

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

После Мемус-батла Саша посвятил всех в таинство ретроспективы, объяснив суть и важность этого мероприятия.

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

Ретроспектива, если коротко, это процесс рефлексии о прошедшем спринте (двухнедельный отрезок работы), когда каждый из участников команды высказывает свои впечатления за прошедший период. Происходит это следующим образом: каждый участник команды на зеленых стикерах отмечает всё хорошее, что произошло за спринт, а на красных — все проблемы и трудности. После чего команда клеит эти стикеры на доску и вместе обсуждает.

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

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

Подводя небольшой итог занятий с Сашей: хорошая и сплоченная команда — это залог успеха.

Обзор книги Runing Lean

Недавно прочитал Runing Lean от Ash Muraya поделюсь впечатлениями.

Основная мысль завязана на запуск новых продуктов. Подход разложен на конкретные этапы: анализ потребности, запуск и выход на положительную экономику.

Внутри вам предлагают посмотреть на свой будущий продукт через Lean Canvas. Это таблица/шаблон, которая позволяет последовательно отвечать на ключевые вопросы. Ниже под постом положил сам канвас. Если читали Остервальдера с его бизнес моделями, то это версия немного с другого ракурса.

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

Как это работает

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

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

С вялым заказчиком каши не сваришь

Иногда пишу зарисовки из проектной деятельности. Вот и сегодня такая зарисовка.

Более-менее крупный проект может заглохнуть, если на стороне заказчика не будет команды. 

Если вам говорят: "С вами будет работать Ира, она в курсе всех процессов, а если надо – будет привлекать ещё кого-то!", то есть повод насторожиться. У заказчика должна быть команда, в которой Ира руководитель проекта, тогда норм.

Из жизни. На заре моего проектного менеджмента (в 2008-2009 году) у меня был проект внедрения системы автоматизации в транспортно-логистической компании. 

Большой проект, большое ТЗ. И один человек на стороне заказчика, который "активно" занимается проектом.

Этот один человек всегда загружен (работу же работать надо), поэтому обратная связь по релизам/вопросам идёт с задержками.

Нас, как исполнителя, никто не "трясёт" – сами тянут. В итоге проект скатывается в вялотекущий: у исполнителя нет тонуса, представитель заказчика не успевает, срок сдачи сдвигается и никого это не пугает (обоснованно же).

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

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

Заказчика в тонусе держать надо, а то на шею сядете и соскользнёте с неё очень быстро.

Core Protocols

Когда я пришел в ManyChat, я первый раз услышал про LeSS и пошел читать методичку. А в методичке по LeSS я наткнулся на отсылку к Core Protocols, про которые не слышал раньше, и тоже пошел читать про них.

И если вкратце, Core Protocols — это система фасилитационных техник, направленных на улучшение коммуникации внутри команд.

Есть большая история о том, как два инженера устали от всяких бестолковых встречь и задач и решили придумать свои процессы с блэкджеком и фасилитацией, подойдя к командам как к продукту. Тут у вас уже, наверное, зачеркнуты несколько ячеек в Bullshit Bingo, но подождите.

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

На деле получилось 2 списка: список коммитов (обязательств) и список самих протоколов, которые выложены в открытый доступ с открытой лицензией, как софт, и которые со временем дополняются, изменяются, актуализируются.

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

Я их переведу на русский со своими комментариями, и если вы найдете более емкие формулировки, то пишите, я дополню/исправлю:

1) Я обязуюсь участвовать, когда присутствую
Это про то, что если участвуешь во встрече, то участвуешь, а не залипаешь в ноутбуке. Дополнительно расширяется на личную внутреннюю осознанность. Если что-то делаешь, то понимаешь зачем.

2) Я буду стремиться больше воспринимать, чем быть воспринимаемым
Это про то, чтобы слушать и пытаться понять аргументы, а не продавливать свою точку зрения любыми средствами.

3) Я буду использовать команды, особенно при выполнении сложных задач
Это про помощь. Ты должен пользоваться всеми видами помощи, которые можешь получить от людей вокруг, а не пытаться супергеройски вытащить проект, перегореть и уволиться.

4) Я буду говорить всегда и только тогда, когда верю, что это улучшит соотношение усилие/результат
Это про осознанное высказывание мыслей. Не нужно говорить просто, чтобы стать заметным для кого-то на встрече.

5) Я буду предлагать и принимать только рациональное, ориентированное на результат поведение и общение
Понимаешь, что разговор эмоциональный, не про цель, на высоких тонах, отмечаешь это и не вписываешься в такую игру.

6) Я буду избегать непродуктивных ситуаций
Если понимаешь, что 23 встречи в неделю не приводят к результату, отмечаешь это, и стараешься не участвовать им, не мешая при этом другим.

7) Я сделаю сейчас то, что должно быть сделано в конечном итоге и может быть эффективно сделано сейчас
Это про выполнение здесь и сейчас того, что приблизит к результату, а не создаст видимость занятости.

8) Я буду стремиться двигаться к цели, смещая свое поведение в сторону действия
Всегда разгоняй активным действием, создавай положительную инерцию, которую сложно остановить даже самыми тупыми действиями и комментариями.

9) Я буду использовать протоколы, когда это применимо
Всегда помнишь про протоколы и стараешься их применять каждый раз, когда они нужны.

10) Я никому не причиню вреда—и не потерплю причинения вреда—за его или ее верность этим обязательствам
Если закомитились на core protocols, то не нужно закатывать глаза и проявлять агрессию (даже пассивную), когда тебе кто-то подсветил, что ты наваливаешь не в ту сторону.

11) Я никогда не буду делать ничего глупого нарочно
Вот да!

Это только верхушка, в следующий раз посмотрим на сами коммиты.

Вообще очень рекомендую прочитать оригинал текста с коммитами вот здесь — https://liveingreatness.com/core-protocols/the-core-commitments/