Про видимую демократию

Про видимую демократию

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

Вы наверняка такое видели или даже делали сами (я точно грешен): руководитель организует встречу для обсуждения какой-то проблемы. Но приходит туда с готовым решением или идеей. Или даже презентацией. Ну потому что ты же руководитель/снователь `— ты всегда должен знать, что делать дальше 🙂

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

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

Но самое интересное начинается потом. Ведь это директор (а не команда) решил что-то делать. Единолично. Другие участники вряд ли хотят реализовывать решение, скорее всего не брали на себя никаких обязательств и уж точно не горят этой затеей. Короче, ничего сделано не будет.

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

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

Чинить баги по TDD

Один из кейсов, которые я рассмотрю на своём мастер-классе 26 октября (https://tdd.timepad.ru/event/1074439/?utm_source=telegram&utm_medium=messenger&utm_campaign=mypost-bugs) — это исправление багов по TDD.

Вот прилетает к нам задача, скажем «Жму на кнопку — не работает». Обычно мы чиним такие баги весьма тупо — поднимаем фронт и бек, придумываем гипотезу, и начинаем дебажить: вносим исправление и жмём на кнопку. Если заработало — отлично, если нет — просто перебираем дальше гипотезу за гипотезой. Иногда мы перебираем гипотезы настолько беспорядочно, что даже не убираем следы предыдущих попыток.

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

Правильный процесс выглядит так: открываем контроллер в API, куда ходит кнопка, а дальше ставим под сомнение каждый нижележащий метод, проговаривая про себя гипотезы, к примеру: «я сомневаюсь, что метод get_users() не возвращает неактивных пользователей». Если сразу не находим теста, который доказывает обратное — пишем свой. Если тест падает — отлично, у вас уже есть тест, и остаётся только написать код. Если написанный тест не падает — git checkout --, и ставим под сомнение следующий метод.

Такой процесс заставляет вас тестировать баги изолированно — вы никогда не натолкнётесь ещё на один баг, который создали во время предыдущих бесплодных попыток. А ещё вы никогда не отправите в прод неработающее говно, потому что у вас нет состояния «кажется всё заработало» — всё или заработало, или нет.

Защита

Самое время рассказать пару слов о защите. Вот несколько важных вещей, которые я понял на своем опыте.

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

Второе, нужно максимально упростить повествование не уходя в детали, потому что на выступление дается всего 10-15 минут. Было непросто выбрать логику повествования — когда ты работаешь над проектом полгода, становится сложно выкинуть какие-то части. Но чтобы вас поняли, это необходимо сделать, ваш рассказ должен понять даже ребенок. Мы выбрали одну самую большую боль пользователя и обернули её в историю этого пользователя — от момента, когда он сталкивается с проблемой, до её решения. Одна проблема — одно четкое решение, тогда вас точно услышат и осознанно оценят.

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

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

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

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

Перед защитой всегда очень волнуешься, так как относишься к этому со всей серьезностью. Особенно сильно переживаешь за то как тебя оценят. Когда мы готовились к защите, то чувствовали себя аутсайдерами из-за того, что долго и сложно работали над UI. Но по мере подготовки презентации я понимал, что у нас получается очень крепкая история. Так и получилось — пятёрку получили только две команды: мы и qlean. И нас обеих оценили в первую очередь за то, что мы нашли боль и осознанно попытались её решить. Вы можете сами оценить наш кейс, который сверстан практически в точности по сценарию рассказа презентации.

Часть вторая. Розыгрыш брифов!

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

В этот раз брифы были зашифрованы текстами песен. То есть по 1-2 строчки ты должен был догадаться о чем идет речь.

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

Первый слайд — «Все на свете из пластмассы и вокруг пластмассовая жизнь…»
В голове быстро проносится анализ: так, это либо экология, либо производство чего нибудь. Быстро решаю, что это не интересно, тем временем нужное количество человек уже подняли руки, идем дальше.

Второй слайд — «I really need you really love you, И как бы далеко бы я ни был от тебя…»
Что то про близкие отношения, думаю я, либо сервис знакомств, либо поиск кого то. Точно нет. В аудитории тоже происходит заминка. Серей Гальцев решает дать подсказку сомневающимся и говорит, что тема очень душевная. В итоге появляется нужное количество рук.

Третий слайд — «Перемен, требуют наши сердца! перемен, требуют наши глаза».
Опа, звучит круто, решаю поднять руку, но так же решает добрая половина аудитории, в итоге я был даже не четвертым, строчки явно пришлись многим по душе, так что я в пролете. Идем дальше.

Четвертый слайд — «Я раньше и не думал, что у нас на двоих с тобой одно лишь дыхание…».
Так, звучит подозрительно, дыхание, опять близость? нет не буду рисковать. В итоге команда формируется без меня.

Пятый слайд — «А у нас алкоголь дешевле, чем учебник — Так что, если ты ноешь, ты обсос, как Чендлер.»
Так, тут явно замешано образование, образовательными проектами я в той или иной мере занимался в университете, так что тоже пропускаю.

Шестой слайд — «Город-сказка, город-мечта».
Я смело поднимаю руку. Не особо следил за порядком, поэтому даже не заметил, что это последний слайд, просто понял, что мне это интересно. Урбанистика, город, в этом направление сейчас много чего происходит, должно интересно. Таким образом моя и ещё 3 руки сформировали последнюю команду.
Далее, нам показали те же самые слайды, но с брифом от заказчиков. Это было небольшое видеообращение с описанием проблемы.

1. «Все на свете из пластмассы и вокруг пластмассовая жизнь»
Фонд WWF заказал сервис, который поможет людям более осознанно подойти к проблеме загрязнения пластиком.

2. «I really need you really love you, И как бы далеко бы я ни был от тебя»
Фонд Добрая планета, попросил помочь им с организацией помощи волонтерам по работе с детьми-сиротами.

3. «Перемен, требуют наши сердца»
Фонд Борьбы с Коррупцией — это было довольно неожиданно, бриф читал начальник штаба — Леонид Волков. Он рассуждал о предстоящих выборах и о сложности наблюдений за их честностью. Его просьба была в том, чтобы придумать сервис, который облегчил бы жизнь наблюдателей. Все были немного в шоке, и я в том числе.

4. «Я раньше и не думал, что у нас на двоих с тобой одно лишь дыхание».
Как я понял — это некий стартап, который продвигает идею умных датчиков, отслеживающих чистоту воздуха.

5. «А у нас алкоголь дешевле, чем учебник», Фонд поддержки образования и науки «Рекурсия» попросил помочь в проекте по менторству студентов.

6. И, наконец, «Город-сказка, город-мечта», где заказчик, в виде Студии транспортного проектирования, просил помочь в организации сбора данных на местности. И так как это моя тема, я остановлюсь на ней чуть подробнее.

А сегодня хочу написать про пару способов, чтобы ломать боязнь чистого листа

Сегодня как раз обсуждали этот вопрос с моей mentee: ей нужно написать стратегию на следующие несколько месяцев; продуктовая область обширная и сложная - с чего начать? Несколько лет назад я в ее ситуации открывала Google Doc и, понятное дело, прокрастинировала. Мыслей много, но они как спутанный клубок ниток: непонятно, за какую нужно потянуть. Мозг пугается и решает: может, лучше и не трогать?

Сейчас у меня есть несколько уловок, чтобы себя обмануть и стартовать процесс.

1) Набросать структуру.
Почти для любого продуктового документа в интернетах можно найти шаблон. Что такое шаблон: по сути, просто список вопросов, которые нужно себе задать в данной ситуации. Психологически, на вопросы отвечать легче, чем пытаться написать целиковый текст с нуля.

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

2) "Мы уже это сделали".
Это вариация на тему Амазоновского working backwards. Наш мозг не очень хорошо умеет предполагать, зато отлично умеет объяснять – и этим надо пользоваться. Сравните:

"Представь, что нам надо сделать лучший в мире мессенджер. Что бы ты предложил?"

"Сейчас 2025 год, и мы запустили лучший в мире мессенджер. Что мы сделали, что у нас получилось?"

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

Я очень люблю делать это упражнение с командой. Например: "2 месяца спустя, мы запустили фичу X, но она с треском провалилась. Что пошло не так?".

3) "Это не я"
Этим способом я пользуюсь реже всего, но иногда он помогает :)
Представьте, что вы общаетесь с лучшим другом, и он/она задает вам вопрос: "А что бы ты мне посоветовал в ситуации Х?". (Ситуация Х, собственно, и есть ваш вопрос, над которым вы прокрастинируете).
Это забавно, но нам легче принимать решения за других, чем делать это для себя. Иногда новая перспектива, когда вы будто немного в стороне и просто даете совет, помогает абстрагироваться и снять творческий блок.

Мягкие навыки для продуктовой работы

Канал читают совершенно разные люди, у которых разные рабочие задачи. Кто-то программирует, кто-то в фигме/скетче дизайнерит, кто-то от цифр балдеет, кто-то пишет статьи — это всё профессиональные навыки, нужные для решения конкретных задач или hard skills.

Но есть ещё личные качества или мягкие навыки, они же soft skills. Глобально выделяют довольно капитанские навыки: умение работать в команде, гибкость, эмпатия, широта взглядов, стрессоустойчивость, управление временем и т.п.
Я не люблю слово "капитанские", но здесь оно прекрасно подходит — очевидно же, что мало кому нужен закостенелый угрюмыш, не умеющий разговаривать с людьми.

Мягкие навыки остаются с человеком и могут применяться, даже при кардинальной смене hard skills. Например, если в продуктовой команде программист стал дизайнером, то его hard skills изменились глобально, а soft skills при этом нужны те же самые, но, возможно, в других пропорциях.

Это было краткое вводное в понятия hard/soft skills.

А теперь к делу — какие же мягкие навыки нужны тем, кто работает в продуктовых командах?
Помимо очевидных, я бы выделил следующий ТОП-5:
1. Любопытство и тяга к знаниям
2. Умение доставать нужную информацию
3. Решительность и находчивость
4. Структурирование информации
5. Умение вовремя остановиться

Могу рассказать по каждому навыку с примерами из опыта- почему навык важен и как его проверить/проявить.
Надо?