В жизни, компании или продукте иногда случается жопа. В общем, что делать, если случилась жопа 🐗
Дисклеймер: это не универсальные советы (в такие я не верю), а личный опыт, который может быть полезен.
-
In
-
Когда кто-то говорит про рынки, в голове сразу образуются голубые и алые океаны.
Голубые океаны — это новые рынки, которые формируются компаниями. И эти компании врываются туда на коне, занимают здоровенную долю и становятся молодцами. Главное в таких рынках — это продуктовая ценность. Все стартапы мечтают работать именно в такой модели.
Алые (или красные) океаны — это уже устоявшиеся рынки с высокой конкуренцией. Там уже все давно поделено, а ценности максимально понятны пользователям. Здесь работают совсем другие механизмы. Я из главного тут выделю себестоимость и каналы дистрибуции продукта.
Еще можно создавать голубые океаны внутри алых. Короче, написано уже очень много слов про то, как охуенно жить в голубом океане без конкуренции и быть всегда на коне.
Я хочу подсветить другую важную и не всегда очевидную штуку.
Алый рынок с безумной конкуренцией тоже может быть норм. И там тоже можно зарабатывать деньги даже без уникальной продуктовой ценности.
Так вот, если в конкурентном и даже не особо растущем рынке есть:
- регулярное обновление (это когда значимая доля пользователей регулярно отмирает, а на их место приходят новые),
- недообслуженность (это когда часть пользователей живут с мыслями о том, что пользуются хуйней),
там можно занять значимую дольку.
Об этом важно помнить, чтобы не упираться рогом в выстраивание нового рынка, когда это не нужно.
In
-
Какой бэкграунд лучше, если ты руководитель в айтишном продукте? Это не про глубоко технических ребят (типа лидов). Это про бизнесовое управление продуктом, юнитом, вертикалью и чем угодно еще с ответственностью за деньги.
Как обычно, возьмем двух чуваков.
Первый вырос из разработки. Десять лет пахал простым работягой программистом. Потом ушел менеджерить (верхнеуровнево) какой-нибудь продукт. И теперь отвечает там за деньги. Он вам расскажет и за деплой, и за архитектуру, за производительность и за че-нибудь еще глубокотехническое.
Второй вырос из менеджера. Сначала был проджектом и двигал тикеты в джире (или любом другом такс-трекере), потом стал руководителем таких проджектов, а потом пошел менеджерить тот же продукт и тоже отвечать там за деньги. Он вам может рассказать за управление ресурсами, правильную приоритизацию задачек, скрам, канбан и еще дофига всего.
Первый очень глубоко погружен в технику. Второй — ну так себе, ни строчки кода в жизни не написал. Кто лучше? А продукт-то айтишный. Со сложной архитектурой, высокой нагрузкой и вот этим всем.
Раньше я бы сказал так: ну-у, если продукт технически сложный, то наверное там должен быть продакт, который шарит за технику. А значит, у него должен быть технический бэкграунд. Может и так, но я нашел ответ получше.
Короче, молодец тот, кто научился использовать свой бэкграунд во благо.
Если менеджер полезет в около-разработку и скажет что-то типа:
Да вы че какой-то хуйни тут наделали, щас я вам докер в кубернетис задеплою, охуеете все.
А потом действительно пойдет подрабатывать у себя девопсом, это очень плохо. Потому что его задача — это не заниматься девопс-практиками, а зарабатывать бабки. А ручное вмешательство в часть разработки приведет только к вечному микроменеджементу.
Тоже самое со вторым чуваком, который может прийти и начать заниматься проджект-менеджементом вместо бизнеса.
В обоих этих примерах чувак будет забирать не свою зону ответственности на себя. А значит, свою зону ответственности он слегка проебет. И бэкграунд будет не во благо, а во вред всему продукту.
Но! Любой бэкграунд может помогать и усиливать чувака. Важно принимать это именно как бэкграунд, а не свою зону ответственности. Технический чувак может лучше знать все особенности разработки и вовремя ловить нужные сигналы. Чувак-менеджер может лучше знать особенности управления ресурсами. И так про любой бэкграунд.
Неожиданный вывод. Не надо превращать свой бэкграунд в якорь. Не надо на нем фокусироваться. Забывать о нем, обесценивать и делать всякие другие пакости — тоже не надо. Надо делать так, чтобы он помогал решать текущие задачи. И тогда будет норм.
In
-
Во всяких гибких методологиях разработки есть такая штука с названием бэклог.
Это место, куда запихиваются все задачки, которые надо когда-нибудь сделать. В идеальном мире из розовых поней бэклог — это место, откуда в любой момент можно взять задачу и сделать ее, если вдруг освободился ресурс.
В реальном мире через несколько месяцев работы над продуктом бэклог часто превращается в свалку. Свалку задач, которые никогда не будут сделаны и уже нахуй не нужны, если посмотреть на них честно. Потому что приоритеты и видение уже поменялись.
Чтобы решить такую проблему, есть упражнение — почистить бэклог и собрать его заново. Да, это займет время, но фрустрации при очередном планировании будет кратно меньше.
Так вот, в мире продуктовой разработки такая штука не часто, но все-таки практикуется. И это упражнение воспринимается как вариант нормы. Но в мире собственных задач, которые годами висят в списке «когда-нибудь», это случается сильно реже. И зря.
Это ж как с вещами, которые могут годами лежать на верхних полках шкафа на балконе. Они занимают место, но использоваться не будут никогда, потому что про них все уже давно забыли.
Чтобы уменьшить количество персональной фрустрации, иногда нужно поступать радикально, потому что своя жизнь — это тоже не розовые пони. Выкинуть нахуй все, что лежит на этих самых верхних полках. И собрать заново. Времени на это уйдет много, по пути че-нибудь обязательно потеряется, но итог будет классный.
In
-
С тем, как отправлять рабочие письма, всё уже десять раз обсосали. Письма без темы — говно. Просранные вложения — говно. Ответ всем (когда это не нужно) — говно. Ответ только одному (когда нужно всем) — сами понимаете.
А вот про рабочие встречи все еще можно говорить, потому что тут не все так хорошо. Вот мои восемь пунктов про то, что с ними надо делать.
Дисклеймер: иногда действительно нужно посидеть-попиздеть. Еще бывают дейлики, которые нужны скорее для подсвечивания блокеров. А еще бывают влеты. И еще бывает так, что все уже в контексте, поэтому описанием можно пренебречь. Короче, никогда не будет так, что все ваши ивенты в календаре будут соответствовать всем пунктам.
1. Делать фоллоу-ап или оставлять хоть какой-то артефакт. Если такого нет — встречи не было. Посидели-попиздели, и все.
2. Планировать заранее. Кидать встречу в календарь за 30 минут до ее начала — это пиздец. Не надо так делать. Чувак мог увидеть у себя свободный слот в календаре и пойти поесть.
3. Обозначать адженду. Если в календаре нет адженды (или хоть какого-то описания) — плохо. Вспомнить и переключить контекст — это непростая задача, она займет какое-то время и отожрет драгоценные минуты.
4. Добавлять только нужных участников. Лишние участники — это вообще мрак. Если вам не нужен чувак, не надо его звать. Сюда же обратная история — нужно звать тех, кто будет отвечать за процесс или задачу из обсуждений.
5. Заранее договариваться. Просто закинуть в календарь и ничего не сделать, чтобы чувак пришел — это плохо. Бывают разные ситуации и чувак может просто не прийти.
6. Всех участников показывать явно, чтобы все остальные понимали состав.
7. Ставить нестандартное время только по договоренности. Это про рабочие зумы в 20:00, когда базово рабочий день заканчивается все-таки чуть раньше.
8. Добавлять ссылоньку для подключения (или локацию) в ивент сразу.
Примерно так я себе представляю идеальный ивент в вакууме.
In
-
Есть две крайности. Для наглядности возьмем чувака, который действительно что-то делает (не важно в какой роли): где-то у него получается, где-то не очень, иногда он чего-то достигает, а иногда лажает.
Так вот, первая крайность, в которую можно легко впасть, — это не отсвечивать. Да, сделал хорошо, добежал до чего-то, но вообще-то у меня тут команда и это не я. Само так получилось. От меня вообще мало зависело. А вот факапы — даа, ебать я лох. Да нет у меня никаких суперсил, вы че — просто иногда везет.
А вторая крайность совсем про другое. ЭТО Я, ЭТО Я СДЕЛАЛ ЗАЕБИСЬ. Смотрите, какой я успешный, вот у меня поршик (арендованный), а вот часы какие. Да без меня бы вообще нихуя не получилось, вы че. ЭТО ВСЕ-Е-Е Я. Вот смотрите, я тут одну букву в офере поменял, а потом прибыль к-а-а-а-к выросла в 10 раз! Да похуй, что там маркетинг налил в 1000 раз больше лидов. ЭТО ВСЕ Я!
Ну вы поняли.
На самом деле, это пост-признание. Мне некомфортно писать о своих достижениях. Даже этот пост я начал с каких-то чуваков. Вчерашний пост — он про меня, да. Но вместо того, чтобы поделиться своей суперсилой, я заворачиваю ее в какого-то чувака. Зато про факапы — это пожалуйста, они мои родненькие. Когда я думаю рассказать про себя, у меня в голове это звучит примерно так: да брось, там еще дохуя людей работало, в чем твоя заслуга? Или там вообще просто стечение обстоятельств, ну.
Ух, блядь. Выговорился.
Короче, иногда выебываться сверкать талантами — это нормально. Рассказать что-то хорошее про себя — это не значит присвоить себе чьи-то заслуги. Это не значит отнять у команды участие и их персональные успехи. Это значит принять свои результаты.
Да, становиться вторым чуваком — это не очень хорошо. Как и становиться первым чуваком — тоже пиздец. Важно одинаково хорошо уметь признавать и факапы, и успехи. Потому что все мы живые люди.
У меня впереди еще много работы по движению вправо (посмотрите на мой чудесный график в посте ниже). И нет, я не планирую доехать в самую правую часть. Но я не хочу оказаться чуваком, который едет влево.
Вчера Полина дала мне такой фидбэк (он на скрине), и я считаю, что в этом контексте им можно поделиться публично 🐗
In
-
Вчера я назвал чувака, который умеет в коммуникации, молодцом. Но на самом деле он супермолодец. И нинздя-коммуникакции — это суперсила, которая может помочь во всем.
Сегодня я расскажу еще про одну суперсилу — видеть. И это не про видеть зеленое зеленым, а красное красным, и не про эзотерические штуки типа светящихся волокон, как у Кастанеды.
Видеть — это про про мгновенный анализ, способность находить неочевидные решения и возможности. Это когда в безумной смеси людей, процессов и инструментов ты видишь то, что можно улучшить. Или когда в куче говна можешь найти ту маленькую штуку, за которую можно зацепиться и превратить это говно во что-то нормальное. И последнее — когда в безвыходных ситуациях получается увидеть второе дно шанс на изменения.
Теперь мини-гайд как научиться видеть 🐗
Такая суперсила образуется как следствие двух вещей. Первая — это опыт, ошибки и проебанные деньги. Короче, нужно побывать в режиме выживания, чтобы образовался особый навык. Увы 👋
Вторая вещь про хардскилы. Без них режим выживания может остаться бесконечным, если не повезет. Причем, хардскилы именно в широком смысле. Технические, менеджерские, какие-то еще, — набор зависит от того, где нужно учиться видеть.
Ну и все, когда есть набор из разного опыта, а рядом стоят нормальные хардскилы (которые нужно не забывать тренировать), получается та самая суперсила.
In
-
Если выбирать среди всех софт-скилов самый важный, я выберу навык коммуникаций. Если чувак умеет нормально:
- формулировать свои мысли,
- вовремя задавать вопросы,
- вовремя рассказывать о сложностях,
- аргументированно отстаивать свою позицию,
этот чувак молодец.
Разработчик, менеджер или еще кто-то — не важно. Можно быть бесконечно умным молодцом, но лажать в коммуникациях и не уметь договариваться. А такое приводит к очень плохим последствиям. Проебанные сроки, деньги, доверие, репутация, — все это во многих случаях следствие проебанных коммуникаций. Тут не договорился, там не спросил, тут не так рассказал. И все.
Любая безобидная херня может превратиться в фатальную, если налажать с этим софт-скиллом. И если вы видите такую проблемку у себя или у своих чуваков, бегите чинить, потому что оно может выстрелить в любой момент и не очень приятно.
А чтобы это все не звучало как советы в вакууме, вот мой факап из прошлого.
Когда-то я делал Эспрессо — учетную систему для кофеен. На старте предполагалось, что эта штука пойдет в рынок и я буду свободно продавать ее всем. И она не превратится в продукт для одной компании — Кофе Лайк. Мы так договорились, но ничего не зафиксировали. Короче, после первой же продажи наружу, ко мне пришли с вопросиками: какого хуя? В тот момент я еще не особо шарил, поэтому договориться не получилось, и де-факто эта штука осталась продуктом для одной компании. Договоренности только на словах и одна плохо проведенная встреча стоили мне дорого. Да и с взаимным доверием стало чуть сложнее.
Короче, по возможности не лажайте в коммуникациях. Это прям важный скил.
In
-
Понял, что слегка отстал от технологий и жизни. И нет, не потому что у меня в айфоне разъем лайтнинг, а не тайп-си.
Пришло время обновить лендос облачной кассы в Эвоторе. Добавить новые разделы и всякое такое. В моем сознании для таких штук всегда есть три варианта:
- собрать на тильде;
- уехать в НОРМАЛЬНУЮ CMS;
- делать сложную и дорогую связку из своего бэка и фронта.
С тильды у меня бомбит. Инструмент норм, но запах чувствуется издалека. Тильду всегда видно, короче. Нормальная CMS — это вообще пиздец. Дофига работы, сторонний ресурс на поддержку и дыры в безопасности. Делать свой бэк и фронт — дорого, долго и глупо. К тому же, любое изменение контента = деплой.
И тут я короче вспомнил про такую штуку — Headless CMS. Это что-то типа конструктора API для контента. В таком сценарии достаточно только напилить фронт, а бэк уже готов. И контентом можно управлять в админке. Прям как нормальный человек.
Короче, если у вас в команде есть нормальные компетенции фронтенд-разработки, это прям оптимальная связка. Не знаю, почему все еще не ушли в эту сторону.
In
-
У нас всегда есть какие-то супербольшие задачи. Обычно мы [менеджеры] их декомпозируем на короткие достижимые отрезки. Это все понятно.
Но самый трудный отрезок всегда первый. Сложно взять и сделать первый шаг, потому что за ним второй, третий, сто сорок шестой. И когда ты думаешь про первую небольшую задачку, в голове уже все сто сорок шесть.
И тут мне помогает управляемая амнезия — забыть нахуй, зачем нужно делать эту первую небольшую задачку. Я достаю себя из контекста здоровенной ебанины и просто делаю первую итерацию. А потом вторую, третью и все остальные.
В жизни, кстати, это тоже помогает. Но с такой амнезией нужно поаккуратнее конечно —большая задача не должна пропасть с радаров навсегда.
In