Ключевые learnings из интервью Саши Панова

Когда стоит, а когда не стоит
1. Самоорганизация —единственный известный Панову способ масштабирования, то есть хорошо работает, когда сошлась unit-экономика и надо «просто расти».
2. На этапе стартапа/запуска — не до этого, надо делать, что сказали, без лишних разговоров, так как время играет против компании, а денег не так много

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

Про принятия решений
1. Все равны, у каждого есть 1 голос по разным вопросам, в том числе и у «главного» (хотя что это в таком окружении означает?!) — его светлые идеи могут не принять и не сделать.
2. Для принятия решения, нужного руководителю нужно больше времени (а иногда и просто не возможно), больше уговоров, продажи и проч.
3. Самоорганизация — для руководителей, которые берут на себя всю ответственность. Как работает для команд внутри — уже вотчина руководителя (то есть внутри может не быть самоорганизации).

Как это все поддерживать
1. Система постоянно разваливается, поэтому есть команда «трансформации», которая решает конфликты, подкручивает систему, отслеживает, как работается в ней. Команду возглавляет ко-фаундер
2. Люди определяют процессы, а не наоборот — привет манифесту — для этого есть регулярная встреча

Из «неочевидного»
1. Свобода на работе — действует как легальный наркотик — тяжело отказаться.
2. Это не для всех — вот так неожиданность;)

Я пока не знаю зачем, но вдруг вам не лень — бустаните канальчик;)

https://t.me/boost/tw0_percent

Заставь дурака богу молиться

«Нельзя сказать точно, что нужно сделать, чтобы получилось, но можно точно сказать, что сделать, чтобы не получилось» (с) Не знаю кто

«В этом мире не все и всегда и везде, а кое-что, иногда и местами» (с) Дорофеев

Agile и продуктовые коучи довольно последовательно и настойчиво «топят» за использование тех или иных фреймворков и на проведении экспериментов/исследований.

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

Но сегодня я не планирую петь оды очевидному в формате «делай эксперименты – ты ж не тупой», а вспомнить, что ошибку выжившего никто не отменял.

На тренингах по экспериментам иногда рассказывают про Эдисона (тысяча прототипа лампочки, дать ссылку), Netflix или про компании Rovio, которая сделала Angry birds.

Последняя, действительно, сделала более 50 игрушек, пока не придумала культовую (у меня вот был первый iPhone и на нем уже была эта игра). На волне успеха она начала качать франшизу: мягкие игрушки, тематический парк в Китае, кино). Конечно же ребята делали другие игры для мобильных. Но ни одна из игр не сыскала такой славы и популярности, как безногие птички против свиней 🤦‍♂️

Пару лет назад компания находилась в состоянии выживания: прибыль падает, людей увольняют, чтобы с этим что-то сделать сотрудники продолжают жать на кнопку «а давайте еще придумаем что-то», но результата нет. При этом каждое придумывание – это исследования, прототипирования, UX-тестирования, разработка и вот это вот все, что съедает деньги из единственной дойной коровы

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

Про подход к проблемам


«Плохие времена рождают сильных людей. Сильные люди создают хорошие времена. Хорошие времена рождают слабых людей. Слабые люди создают плохие времена»

Когда-то компы были слабыми, а людям, работающим в ИТ, приходилось быть сильными:
🏋️ рюхали в математику может больше, чем в конкретный язык,
🏋️‍♀️читали Кнута, умели реализовывать нужные им структуры данных,
🏋🏼‍♀️ понимали в ОС, и как там реализована многозадачность,
🏋🏻‍♀️ знали про устройство процессора (и даже умели в СИшный код вставлять куски ассемблера, я вот застал).

Потом появилась Java и аналогичный C#. Две экосистемы бились за то, как бы ещё снизить порог входа, чтобы «войти в АйТи» было проще. Потом Индия сделала ставку на ИТ и в индустрии стали платить за строчки кода. Теперь (почти) каждый может стать разработчиком, ничего про это все не понимая, ибо зачем, когда у тебя вроде как уже все написано, бери да переиспользуй (помните, как мы почти потеряли интернет из-за ошибки в 1й мелкой Библиотеке?), да еще и серваки на 100500 ядер и памяти, как грязи (а за океаном одна из старейших итшных компанияй собралась строить звездные врата на 100 ярдов, потому что может).

Кажется, настали временя, когда с умной разработкой произошло тоже самое, что и с шахматами: люди решают задачи на оценку сложности алгоритма just for fun. Такие дела (с)

🧠 Рецепты уровня «нормально делай — нормально будет» после какого-то раза перестают работать.
©️ Так же и с правилом «экономия на масштабе» работать не всегда и не везде.
💣 В частности, увеличение размера/срока фиксированного релиза не всегда приводит к экономии или к росту эффективности.
📝 На эту тему есть короткая заметка, в которой, при желании, можно прочитать подробную статью

Немного видео с прошлого года

27 июня будет GigaConf 2024. В прошлом году эта же конференция называлась smartdev. У меня получилось поучаствовать в 2х активностях:
👨‍🏫 Выступление с коллегой Виталием Астраханцем по тому, как мы планируем ускорять devOps’ов-инженеров
😅 Панельная дискуссия стол по теме последних трендов в ИТ
Везде старался кривлялся из всех сил – смотреть можно.

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

Главный враг любых изменений/трансформаций - это…

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

– это временное предприятие, направленное на создание уникального продукта, услуги или результата. (с) PMBoK

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

Обратимся к статистике проектов

«Много успешных проектов оказалось в IT-индустрии и консалтинге: 56 и 54% соответственно»

«Удивительно высокую успешность показывают проекты в научных, образовательных и культурных организациях – 68%, а также в здравоохранении и госсекторе – более 50%.»

«Однако в реальном секторе, в ритейле и строительстве ситуация иная. В производстве 29% респондентов ответили, что проекты были удачными, в строительстве и ритейле такой ответ дали 30 и 36% респондентов соответственно»

«данные американского Института управления проектами (считается одним из основоположников проектного управления) и международной консалтинговой группы The Standish Group. Обычно из каждых 10 проектов успешными бывают только три, еще три сталкиваются с трудностями, два преодолевают значительные трудности, а еще два и вовсе проваливаются.»
Источник Ведомости. Российские компании рапортуют об успешности половины своих проектов

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

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

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

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

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

Я не буду этим пользоваться – это слишком легко…

Причина не в том, что дорого, сложно и долго – нет! Все как раз наоборот:
🆓 бесплатно (можно скачать бесплатно на гитверс с лицензией MIT, хотя мы умеем за деньги это внедрять),
🐣 легко (как писать на русском языке) и
⚡️ быстро (1.5 часа на установку и не больше 1 часа до запуска первого теста).

Спустя месяц после этого разговора до меня дошло, что главный враг изменений – это ущемленное эго.

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

Выступление как событие

Я не уверен, что цифра правильная, но за последние 6-7 лет я выступал со сцены на конференциях +/- 10 раз; участвовал в 3х дебатах; в подкастах — 3 раза (недавно вот записался в т.банке).
Записей, где я что-то говорю на камеру — немного больше.

Но каждый раз, когда мне предлагают выступить, у меня внутри появляется первая реакция:

— зачем?
— что, опять?
— аааа

(Кстати, сейчас я прохожу через это со вторым выступлением на CNews).

Люди вокруг могут подумать, что у меня есть потребность в том, чтобы быть на сцене, но нет — у меня есть потребность в продвижении идей, в которые я верю, и поэтому я вынужден выступать.

Очевидно, другой способ для продвижения идей — это другие формы коммуникаций: на работе с коллегами, в этом канале, дома и с друзьями

Всю свою жизнь я так или иначе борюсь с собой, с особенностями своей психики, но сейчас я понял, что нет
«хорошо» vs «плохо»,
есть
«работает» или «не работает».

Так и с выступлениями: я пытался сначала сделать что-то с этим чувством сопротивления, а потом забил — ну есть и есть — теперь я его использую как цензора:
❓а не херню ли я собираюсь спороть со сцены?
❓точно ли я попадаю в аудиторию?
❓такими ли словами стоит доносить свою мысль?

Думаю, у каждого из нас есть такие «приколы» в голове, поменять их очень сложно (если вообще возможно), но подумать, как их использовать себе на благо, точно стоит.

Неортодококсальный, асинхронный тренинг по обратной связи. План тренинга

В прошлом посте
я обещал выложить готовый план тренинга, если будет выполнено одно из условий — и вот тренинг в открытом доступе 💪

Как следует из названия, он не такой, как проводит его HR или, увидев как происходит общение в agile-команде, Agile-коучи.

😎 Почему?
Во-первых, говорить тренеру не нужно. Вот совсем. Да, прям совсем-совсем.

Во-вторых, от 60 до 80% всего времени уходит на практику.

В-третьих, потому что в сумме трудозатраты слушателей (и тренера), размазанные на несколько недель, превосходят все известные мне форматы (я видел варианты от 1 часа до 4х, проектировал на 8 — кому-то встречались другие варианты?).

🙋Так что же представляет собой тренинг? —

Заранее спланированный перечень постов в telegram.

✉️Часть сообщений (27 штук) можно отправить в будущее через отложенные сообщения, так как содержимое известно заранее (и настраивается под тренера), как и время и дата публикаций.
✉️ 5 постов в общую группу придется написать в моменте, но в понятное время и дату.
✉️ Оставшиеся 8хN (где N — количество участников) сообщений отправляется в группе в ответ на текстовое задание.
✉️ И ещё 8хN — в личные сообщения участникам тренинга.

📝 Комментарии
1️⃣Я сам вел тренинг в группе в тележке. Ее смело можно вести в канале с подключенными комментариями (так будет еще лучше).
2️⃣ Ежедневные трудозатраты тренера в день на группу в 8-10 человек я оцениваю от 1 до 3х часов. На счастье, этот час не сконцентрированный, но я засиживался допоздна (при желании можно поменять время дачи обратной связи — для этого есть отдельный флаг в настройках файла).
Трудозатраты учащихся (писал в посте выше) до 1 часа в день (и снова размазанных по дню).
3️⃣ План выложен в google sheet (в комментарии к этому посту я выложу excel, если кому-то будет неудобно с западным облаком), который на первом листе содержит тренерскую инструкцию и мои комментарии — это нужн прочитать в обязательном порядке.
4️⃣ Я вкусил кайф от асинхронного обучения. Надеюсь, все, кто не испугается вложиться в группу и попробует, вернется ко мне с обратной связью (асинхронной, ага).

Услышал фразу:

Listen like you don’t have the answer

Стал забывать как это так слушать.

Пример delegation poker, разложенный на стоимость.

В терминах «покера»
“we” — это ребята с руками, команда,
а «you» — это заказчик работ, менеджер

Я не знаю, что делать…

Каждый из нас разговаривает сам с собой, даже когда идет непосредственное общение с другим человеком

У нас в компании была очередная встреча, на которую я не поехал. Надо было выяснить детали, звоню одному коллеге и получаю информацию про решение «А». Подумал, что стоит проговорить с другим человеком, как же мы теперь с этим А будем жить. Звоню, и мне говорят, что решения А принято не было, а на самом деле решение было «В».

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

И как же так получается?
Мне кажется, что есть фундаментальный косяк во второй сигнальной системе. То, как мы говорим и то, как мы слышим в целом не очень предназначено для того, чтобы передавать информацию точно. Я думаю, каждый имеет опыт попытки донести информацию «голосом через рот», когда понимаешь, что даже на 10% не передаешь словами то, что хотелось сказать (и это мы еще не переходим в область написанных текстов — привет всем ТЗ). Я не биолог, но речь очевидно была придумана не для того, чтобы мы понимали друг друга.

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

Почему обрывочные? Потому что из опыта уже понятно, что нет разницы будешь ли ты долго объяснять свое видение или скажешь 2 фразы между встречами – результаты будет любым:)

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

Я честно, не знаю, что с этим делать
Возможно, эта задача в целом поставлена некорректно и решить ее просто невозможно?

Это я, когда аппелирую к «достигнутым» «договоренностям» с некоторыми людьми

К сожалению…

Что меня по-настоящему триггерит / злит в коммуникациях – так это «к сожалению».

Каждый раз, когда я читаю текст, в котором встречается эта фраза, я понимаю, что в нем нет
❌ ни сожаления,
❌ ни даже переживания.

Например, почти все письма от компаний, которые (зачем-то) закрыли свой бизнес на территории моей страны, пишут «к сожалению». Но нет – сожаление может быть мое, но не их.

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

Кто-то в своей речи вместо «эээ», «ну» и «типа» вставляет «к сожалению».

Надо научить какую-нить LLM заменять «к сожалению» на «нам пофиг» – так хоть читать будет веселее.

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

Быть взрослым или почему лучше не давать советов

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

Рассмотрим на примере. Можно посоветовать другу или знакомому своего текущего работодателя.
И вроде бы все хорошо: компания нравится, задачи сложные и интересные, люди умные и приятные — пусть и другим будет так же хорошо.

Но есть сразу множество «Но»
1️⃣ В некоторые компании не успел зайти, как считывается культура.
Это видно по лицам:
напряженные или воодушевленные?
По разговорам:
тихо, как в морге или жужжание улья?
Бывает, что культура не твоя.

2️⃣ У кого-то сложные задачи вызывают радость, а у кого-то тоску по Dolce Vita.

3️⃣ Кому-то в кайф упороться с коллегами до поздна, а кто-то после 18:00 никогда не задерживается.

4️⃣ Получается, если и давать рекомендацию прийти в то или иное место, то уж точно не «в целом» (в компанию А), а в частности (к конкретному человеку). Но тут не все так просто. Может не сложиться «химии».

«Люди приходят работать в компанию, а уходят от руководителя».

Как говорит Дорофеев
В этом мире не все, всегда и везде, а кое что, иногда и местами

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

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

Конфликты с коллегами

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

———
Давайте поговорим о такой теме, как «война» на работе.

Начнем с определений:

Война — это крайняя форма разрешения противоречий, характеризующаяся резкой сменой отношений.

1️⃣ Война всегда ведется за мир!
Что характерно за мир лучше довоенного.

2️⃣ Когда субъекты вступают в эту крайнюю форму?
Когда обладают картиной мира, в которой они побеждают.

Выводы
Если вы захотели с кем-то «повоевать», то у вас в наличии обязаны быть:
1. Адекватная (!) картина мира, где вы побеждаете
2. У вас есть образ будущего, где (как минимум вам) сильно лучше, чем до вступления в конфронтацию.

Следствия
1. Если у вас нет ресурсов для ведения управленческих боев — не надо вступать в них.

Сун Цзы говорил, что полководец медлит (не действует), так как не видит пути к победе.

2. Если по результатам конфликта вы вернете прошлый мир — он однозначно не стоит ресурсов, которые будут затрачены на ведение и подготовку боев.

Техника «дорога к жизни»: покажи, как можно второй стороне сохранить лицо и не вступать в бой — она будет тебе благодарена.

3. Картина мира должна быть адекватной.

Критерием адекватности является отсутствие сюрпризов (неожиданностей). Адекватная КМ опирается на твердое, а не на пустое.

———
Надеюсь, мои наблюдения на тему корпоративных конфликтов кому-то помогут.

Ps
Я сам, когда нахожусь внутри, хватаю себя за руку и задаю себе 2 вопроса (про образ будущего и ресурсы для выигрыша), но иногда (лишь иногда) у меня получается отрефлексировать вхождение в «боевой режим». Но чем чаще это делать, тем лучше будет получаться, так что дорогу корпоративного стоицизма осилит идущий.

Как расти?

Прилив поднимает даже дырявые лодки (с) Кто-то умный, может Талеб

Отлив покажет, кто пошел купаться без трусов (с) Уоррен Баффет

Наблюдаю исход одной компании (в ИТ). Средняя длительность работы в компании 5-7+ лет. Атмосфера в компании такая, что менеджеры гордятся (на полном серьезе так и пишут в резюме), что никто (подчеркиваю: н и к т о) не ушел за время их работы из компании и из их функциональной группы. Теперь, как можно понять, массовый исход и суета на рынке.

Среди тех, на кого мы смотрим, есть 2 группы соискателей:
👍 Имеют N-летний опыт работы. 👎 Имеют N раз повторенный годичный опыт работы.

Почему так получается?
Когда-то в Сбере был слоган «карьера сама себя не построит».
Я тот еще карьерист, прямо скажем, поэтому я последний, кого надо слушать на эту тему. Но можно обратиться к великим, например, к Форду.

Генри Форд в своих книжках много писал про организацию производства (и под конец жизни слегка тронулся умом, но сейчас не про это), но часть советов он давал своим сотрудникам. Один из тех, что я запомнил и продолжаю применять для себя, звучит так:

Если после работы не работать над тем, чтобы изменить то, как ты работаешь, то перспективы сделать карьеру не очень

Это что получается: надо работать сильно больше 8 рабочих часов в день? Если коротко, то ответ «да». Чуть длиннее ниже.

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

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

А что если нет?
Получается, что мы выбрали целевые метрики для себя, которые важны без привязки к конкретному проекту.
После работы вкладываемся в то, чтобы их сделать лучше и далее раз в период делаем самооценку.. и она не улучшается. Штош 😢
Перед нами классический цикл PDCA. В алгоритме выше мы описали первые 3 буквы. Остался последняя –«Act», где мы предпринимаем корректирующие воздействия, чтобы результат начал оправдывать наши ожидания. Иногда все понятно: планка слишком высоко задрана, метрики не те или усилия в целом не связаны с метриками. Но иногда это не столь очевидно, а зачастую, зависимости в башке такие, что без психолога не разобраться. Поэтому нужно делать ретроспективу, из которой выходить уже с тем самым набором корректирующих action item’ов для следующего периода.

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

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

Pps
Все написанное выше – это советы, которые я даю исключительно самому себе – не является рекомендацией к выполнению 🙂