Год в Фейсбуке 👻

Год назад, второй раз в жизни после собеседований, я вошёл в офис Facebook на Rathbone Square в Лондоне. Вошёл с большими надеждами: как и устраиваясь в Яндекс 7 лет назад, я надеялся найти своё место и сделать что-то большое и полезное.

Хотелось уйти с удалёнки, попасть в стабильную компанию (переезд с семьей - та ещё эпопея), получить заветную строчку в резюме - и, где-то в глубине души, даже заняться the most important work of my career, как говорят в буткэмпе.

В честь годовщины порефлексирую вместе с вами о прошедшем годе.

🦠 Коронавирус, подлая тварь, всё испортил. После моих первых 3 недель в офисе Лондон стал постепенно, рывками закрываться - вплоть до полного локдауна. И уже в середине марта стало очевидно, что в офис мы вернёмся не скоро. Я нашёл квартиру побольше и подальше от центра (что оказалось очень мудрым решением) и скрепя сердце отказался от надежды разделить наконец работу и дом.

💷 Ожидания к стабильности компании полностью оправдались. Думаю, я куда сильнее переживал бы, окажись я в компании поменьше (впрочем, совсем маленькие я и не рассматривал вообще), где могли бы быть проблемы с деньгами. Ведь много людей, в том числе программистов, остались без работы во время пандемии!

Фейсбук платит немного выше рынка, даёт бонусы (важнейшая часть - sign-on, торгуйтесь изо всех сил!), акции. Кроме этого, у нас есть оплачиваемый COVID-отпуск (вплоть до десятков недель в год), всякие Laundry & Childcare allowance, было несколько выплат "на домашний офис". Короче, денег могло бы быть больше только в каком-то крутом финтехе или банках, но там свои особенности.

Но, увы, Лондон очень дорогой. И поэтому заработать миллионы в местном Фейсбуке, в отличие от США, обычному разработчику невозможно.

🧗‍♂️ Сложностей в работе очень много, даже намного больше, чем я опасался. В фейсбуке десятки тысяч программистов (прямо или косвенно я взаимодействую как минимум с полсотней человек) и сотни тысяч коммитов в нескольких громадных монорепозиториях. Кроме того, я работаю в Workplace - это такой "фейсбук для компаний", и он унаследовал огромную часть кода от самого Facebook. Разумеется, не бесплатно - разбираться в этом всём можно годами, и так и не разобраться.

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

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

И без того сложные (а часто и переусложнённые) системы с таким подходом становятся всё более и более запутанными (особенно продуктовый код), а работа программиста всё больше напоминает небезызвестный подвиг Геракла. Вторые 80% работы - это обсуждения и попытки понять, как это работает и что с этим делать.

Год в Фейсбуке - продолжение

⏰ Начитавшись нытья на Blind, я ожидал, что work-life balance будет поганым. И тут, видимо, мне повезло - а ещё свою роль сыграла пандемия, неготовность компании к удалёнке и какая-то всё же забота о сотрудниках.

У нас в команде достаточно лайтовое планирование и почти нет дедлайнов, не нужно много взаимодействовать с командами в других часовых поясах. Самое плохое, пожалуй, это ужасный on-call, в рамках которого приходится лезть в код, который я вижу в первый раз, и срочно там что-то ремонтировать. Настроение портит изрядно.

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

🤦🏻‍♂️ В целом, моя работа очень скучная. Найм устроен так, что ты не устраиваешься в конкретную команду, а сначала проходишь bootcamp, чтобы потом выбрать из доступных команд. В теории звучит круто - ведь можно пойти делать React или Presto! На практике же, в крутую команду практически невозможно попасть, а выбирать приходится из очень ограниченного количества команд, которые нанимают сейчас.

Конечно, Фейсбук - большая компания, и тут явно есть люди, занимающиеся исследованиями в AI или создающие крутые продукты с нуля. Им не просто больше повезло, а у них есть определённые карьерные цели, они зарабатывают репутацию и плюс-минус хорошо работают локтями в толпе.

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

😎 Подводя итоги, наверное я правильно рассудил, выбрав именно Фейсбук для переезда. Худшее, что тут есть - это Авгиевы конюшни кода объёмнее привычных в десятки и сотни раз. Но в целом в компании довольно комфортно работать. С другой стороны, если посмотреть на несколько лет вперёд, оставаться работать разработчиком тут или в другой корпорации не имеет никакого смысла.

В фейсбук достаточно сложно (но вовсе не невозможно!) попасть, но стремиться к этому или нет - решать вам. Мой вердикт: да, если вы точно понимаете, зачем вам это нужно. Удачи!

@gromov_com

Соберёмся в клабхаусе?

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

Уже зарегистрировались? Мой ник - @oleggromov
Попробуем собраться и что-то обсудить? Если интересно, предлагайте темы 😎
Хороших выходных!

Калькулятор стоимости жизни - вести с полей

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

В конце января был готов первый юзабельный прототип, который я сразу же выложил на сайт. Он был страшненький, местами кривой и тормозной, но основную функцию выполнял. Можно было выбрать Москву, Лос-Анджелес и сравнить стоимость жизни. Готовность проекта была может быть 50%.

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


На чём я споткнулся
Мне удавалось фигачить по вечерам примерно по 3-5 часов каждый день, на пределе возможностей, и ощущения от этого фигачинга были как у Микеланджело, ваяющего Давида. Но сейчас, спустя ещё 2-3 недели, готовность проекта по-прежнему где-то на уровне 80%, а я вымотан, и список незаконченных задач только увеличился. Плюс куча дел на основной работе, не говоря уже про семью. Такая вот жизнь стартапера - либо проект делать, либо с ребёнком поиграть и уборку сделать.

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

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

3) Я придумал какие-то сложные и ненужные штуки 🎛 Лендинг с замороченной интеграцией с SPA, перевод интерфейса на русский (я планирую запускаться в том числе на "наших", но сколько кровушки выпил i18n!), шаринг ссылок (бэкенда нет, поэтому все настройки кодируются прямо в URL), сомнительные фичи типа geek mode для расчётов. Часть из этого можно выкинуть и запуститься так, но что-то нужно для метрик и воронок - можно понять, что пользователь вовлекается по переключению в geek mode; посмотреть, как часто ссылками делятся.

4) Очень много пришлось делать руками 🛠 У меня были надежды на Suggest из Blueprint, но он подвёл больше всего: я долго пытался прикрутить к нему сначала правильные стили, потом виртуализированный рендеринг, потом категории городов (выбранные, популярные, остальные) - но не вышло. Он с трудом кастомизируется, а код местами косой. Пришлось делать самому: вышло лучше, но, опять же, куча времени впустую. Ещё и неизбежные рефакторинги, чтобы всё заработало - и, слава богу, мне хватило ума взять TypeScript!


Как надо делать MVP
MVP даже простейшего продукта - сложная штука, которая будет вести себя не так, как я хочу (капризные они, эти программные системы). А я буду пытаться починить её и потрачу кучу сил на скорее всего ненужную разработку. У меня есть стратегия и план продвижения проекта + некоторая уверенность, что продукт "полетит", но пока что всё время я потратил исключительно на разработку.

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

Было интересно? Поделитесь своими мыслями в комментариях, а этим постом - с друзьями.
Удачи! 🤘

@gromov_com

Четыре модальности написания кода - часть первая

Я достаточно часто переключаюсь между разными модальностями, или режимами написания кода.

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

В больших компаниях всё ещё хуже: в список добавляются корпоративные тренинги, all-hands встречи, регулярные ревью результатов, часто возведённые в абсолют (в Фейсбуке, например), встречи с руководителями и трескотня бесчисленных чатов. Неудивительно, что многие пишут код всего несколько часов в день - часто в формально нерабочие часы.

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

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


Следующая, куда больше радующая меня модальность - творческое программирование. В результате такой работы получается хорошо продуманный код, правильно моделирующий проблему (и отчасти реальность - привет, ООП) и поэтому решающий её достаточно оптимальным и очевидным способом. Правильно выбранный подход, в свою очередь, приводит к меньшему количеству edge cases, а значит к более простому и надёжному коду.

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

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

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

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


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

@gromov_com

Четыре модальности написания кода - часть вторая

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


Написание библиотечного кода, третья модальность, перенимает многие свойства творческого программирования, но обязывает разработчика соблюдать больше условий. Код должен быть производительным и надёжным, а ещё обратно совместимым и следующим принципам defensive programming - учитывать максимально возможное количество edge cases и предсказуемо вести себя (и ломаться) при “мусоре на входе” и прочих странных обстоятельствах: когда входные данные не помещаются в памяти, если операция прервалась в процессе выполнения (транзакции в БД) или кончилось место на диске, когда функции библиотеки вызываются асинхронно или параллельно, и возможны race conditions.

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

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


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

В стартапе на ранней стадии жизни немного разработчиков и мало кода, который выполняет понятные и, вероятно, бесполезные функции. Скорее всего, существенная часть результатов отправится в мусорное ведро в течение считанных месяцев, если не недель, поэтому разработка в режиме “я его слепила из того, что было” вполне оправдана.

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

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

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

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


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

@gromov_com

О, ну это чисто про меня! 🤣

#Понравилось
«Предприниматель — человек, который готов работать 80 часов в неделю, лишь бы не работать 40 часов в неделю».

🎒Субботние ссылки: Product-Market Fit не гарантирует успех, полный гайд по SaaS-метрикам, utility-классы на примере Tailwind CSS, как использовать анимации в UI

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

- Product-Market Fit Isn’t Enough - цикл статей (ищите ссылки на следующие части в конце) о факторах успешности интернет-бизнеса. Описывается связь между рынком и продуктом, продуктом и каналами продвижения, каналами продвижения и бизнес-моделью и бизнес-моделью и рынком. Каждое из "совпадений" (fit) подробно описано, а также рассказывается, почему изменение любого из этих компонентов наверняка приведёт к перенастройке всего бизнеса.

- SaaS metrics 2.0 - очень подробное описание ключевых метрик SaaS-бизнеса. Ключевая особенность SaaS - стоимость привлечения пользователя в продукт может быть так высока, что несмотря на финальную окупаемость, деньги в кассе могут закончиться. Особое внимание уделено хорошему удержанию пользователей (retention), что помогает сделать cash flow положительным. В статье есть всё, что нужно SaaS-стартаперу: про retention и churn, юнит-экономику (на примере HubSpot - какой у них громадный CAC!), когортный анализ, NPS, воронки конверсий, как всё это добро вывести на дашборд и использовать для управления развитием продукта.

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

- CSS utility classes - большая статья от Adam Wathan, создателя Tailwind CSS, о том, как он пришёл к атомарным утилитарным классам, на которых построена его библиотека, и чем этот подход лучше семантичных классов (и всякого БЭМ). Года полтора назад, когда я только узнал про Tailwind CSS, я подумал, что его придумали безумцы, обожравшиеся хайпа - как может настолько бессмысленный и не семантичный подход к написанию CSS вообще существовать? Спустя пару лет и, особенно, пару своих проектов, я заметил очень простую вещь: семантика определённых кусков HTML как правило надумана. Если у вас компонентый фреймворк, то инкапсуляция вполне обесепчеивается компонентами - от CSS требуется только не конфликтовать с другими стилями. Если никакого фреймворка нет, и вы пишете HTML, то очень легко попасть в ситуацию, когда семантически компоненты крайне отличаются друг от друга (карточка города и товар в наличии), а стили используют на 90% одинаковые. В общем, почитайте, там много светлых мыслей.

- The ultimate guide to proper use of animation in UX - я не дочитал, но похоже, что материал полезный. Автор ссылается на особенности восприятия и физику движения, чтобы обосновать использование тех или иных эффектов в анимации интерфейса. Есть куча примеров со скоростью и продолжительностью анимации, нелинейностью (easing) и блюром, анимацией нескольких элементов, изменением размеров. Должно быть полезно тем, кто хочет заморочиться с UI и сделать его по-максимуму sexy.

- My product is my garden - небольшая заметка о подходе к развитию продукта как к уходу за садом. Мне и близок, и не близок такой подход: с одной стороны, это та самая наиболее увлекающая работа, где можно заниматься любым аспектом продукта, к которому лежит душа, и гордиться результатом. С другой стороны, с любовью возделывая никому не нужные грядки, империю наверное не построить.

Приятного чтения! 🤘
@gromov_com

В калькуляторе стоимости жизни, над которым я работаю, есть несколько любопытных модулей.

1. Сохранение redux store в local storage. Эта штука запоминает все настройки калькулятора в браузере и восстанавливает их при последующих посещениях. Достаточно тривиальная на первый взгляд задача, которая осложняется изменением структуры стейта: приложение изменяется, вместе с чем я часто добавляю или удаляю ключи. В качестве решения я решил использовать deep object shape match и написал простой, но эффективный итеративный алгоритм сравнения. При этом null и любое скалярное значение считаются идентичными. Вместо этого можно было бы использовать популярный redux-persist, который умеет ещё и мёржить стейты, но я не уверен, что это хорошая идея - можно налететь на кривое состояние. Плюс выглядит он куда более монструозным.

2. Сериализация части стейта в URL. Вы можете поделиться своим расчётом с другом - для этого создаётся ссылка, в которой кодируются все важные настройки (фактически, часть стейта). Сейчас это сделано в полуручном режиме - ключи и аббревиатуры я задаю статично, но, при желании, упаковку-распаковку можно сделать стабильной и автоматизировать подобно protobuf, покрыть тестами и сделать конфигурируемый адаптер для чтения части URL и обновления store.

3. Разбиение строки на подстроки по совпадению с фильтром. Города в выпадашках для выбора можно фильтровать с клавиатуры, и я написал свой несложный и быстрый парсинг для разбиения строк на куски. Части строки потом обрамляются в span или любые другие элементы с подходящими стилями. Можно сделать и заопенсорсить либо небольшой react-компонент, либо саму библиотечку + любую презентационную часть.

4. Модуль-шина для обмена сообщениями между React и не-React частями сайта. Я заморочился (зря наверное) и сделал лендинг на чистом HTML/JS, а уже в него встраивается react-приложение. При этом мне хотелось, чтобы приложение могло реагировать на события из ванильной части кода (изменение языка влияет и на предварительно отрендеренную разметку, и на react-компоненты) и наоборот: можно переключиться из калькулятора на первый экран, а это триггерит анимации на лендинге и заново инициализирует написанные на чистом JS компоненты, которые меняют картинки и запускают Typewriter.

5. Typewriter, эмулятор печати с мигающим курсором. Класс на чистом JS (на самом деле, TS) без реакта, который удаляет и печатает названия городов как это делал бы человек. Посмотрите на новом лендинге (если вы уже пользовались калькулятором и попадаете в табличку с расчётом, нажмите на кнопку “Start over” или “Начать заново”). Промежутки между “нажатиями” на клавиши достаточно реалистично рандомизируются - получилось неплохо. Его можно выкладывать как есть, добавив примеров, и прикрутить дополнительные фичи: например, удаление и печать не только с конца, а части текста, или более хитрый алгоритм сравнения строк и удаление/печать только разницы.

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

PS Как вам новый дизайн лендинга и калькулятора? Он почти закончен, но не хватает мобильной версии - пожалуйста, не плюйтесь слишком сильно 😁 Скоро сделаю.

@gromov_com

20 лет продакт-менеджмента за 25 минут - конспект

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

Я посмотрел классное выступление “20 лет продакт-менеджмента за 25 минут” - рекомендую посмотреть и вам. Но если на просмотр нет времени, вот вам мой краткий конспект.

Самая важная мысль: работа продакта - решать проблемы клиентов. Не проблемы бизнеса, CEO и даже не свои собственные, а проблемы клиентов.

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

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

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

Ускоряйтесь. Цена промедления в принятии решений - упущенные возможности.

Говорите “нет”. Далеко не все идеи, даже поступающие от CEO компании, нужно реализовывать. Никому не нужным фичам не место в вашем продукте: от них будет практически невозможно избавиться, а за поддержку придётся платить команде и бизнесу.

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

Забавный факт: однажды на рынок выпустили bluetooth-колонку с подсветкой, которая меняет цвета и подключается к интернету (видимо, решили сыграть на популярной теме Internet of Things), чтобы насыпать соль по команде со смартфона. Кто-то явно позаботился о том, чтобы понять своих клиентов 😜

@gromov_com

Принятие решений в жизни и работе

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

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

Фишка тут в том, что уволился я с накоплениями в размере примерно месяца расходов 🤷‍♂️ Чем думал, спрашивается? Хотя, зная об особенностях развития мозга (принималка решений и умение планировать будущее вырастает как раз годам к 25), не удивительно. Захотелось, почудилось - побежал и сделал.

Затем было взросление, совпавшее с устройством в Яндекс. В Яндексе я работал над партнёрским кодом рекламной сети - это такой джаваскрипт, который встраивается в сайт и показывает таргетированную рекламу. У нас там были миллиарды показов в сутки и куча статистики, в которую я с удовольствием (неожиданным, на самом деле) закопался на 3 года.

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

Следующие полдесятка лет я в основном так и жил. Мои результаты и достижения, как будто бы, стали лучше, но вот жить стало явно тяжелее. Постоянные расчёты и осознание вероятностной природы большинства событий в моей жизни привели к постоянному напряженённому ожиданию очередного поворота. Я не стал полагаться на удачу, но принял её важнейшую роль в жизни.

И вот сейчас я как будто бы отскакиваю назад, к тому, что Серж называет “танцем”. Мне кажется, это не только верное определение, но и ровно тот образ жизни, когда жизнь в кайф. А не вот это всё: накопления, ипотека и инвестиции на 20 лет вперёд, принятие обыденного, отказ стремиться к звёздам - просто потому, что попасть туда маловероятно.

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

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

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

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

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

Зачем сидеть в найме?

Привет, друзья! Давно не писал для вас: скоро расскажу и покажу, чем занимался эти несколько недель.

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

Когда я только начинал, в программировании не было денег. Я работал половину рабочего дня за 5000 рублей, а офис наш был в здании Горгаза, где мы арендовали комнату. Туалет на этаже, курилка под лестницей, корпоративы на Солёном озере. Классное было время.

Проработав год, я сбежал "писать диплом", а на самом деле, пытаться устроиться куда-то, где интереснее (не веб) и платят побольше. Прошёл собеседования в ЮгПромАвтоматизацию, но застрял где-то посреди процесса, потому что у меня не было военника. Денег за должность плюсовика предлагали тысяч 20. Устройся я туда, мог бы автоматизировать погрузочные горки.

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

Доходы от фриланса сложно спрогнозировать, а контролировать расходы я тогда едва пытался - у меня мало что оставалось, и купить удалось только потрёпанный 190-й мерс. Воображал же я себя неизменно предпринимателем и даже пытался поставить разработку на поток, чтобы кого-то нанять и открыть своё агентство. Этого не вышло, и я (внезапно) уехал покорять Москву.

В Москве, спустя год работы и неудачную попытку запустить свой курс, я попал в Яндекс. Тут-то меня и затянуло. У Яндекса были деньги, а в конце первого года работы мне выдали первый RSU-грант, который, по правилам компании, означал, что я могу взять льготную ипотеку под 3% от компании. Это казалось каким-то чудом: хоть квартиру в Москве я так и не купил, появился привкус и, в большей степени, предвкушение успеха.

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

С другой стороны, именно работа в Яндексе и излишки денег открыли мне дорогу в "большую" разработку. На лишние деньги я сначала купил бэху, а потом уволился и поехал в Америку учить английский в какой-то смутной надежде попасть на работу куда-то за рубеж. Гуглы и фейсбуки тогда всё равно казались чем-то недоступным, но хотя бы замаячили на горизонте.

Дальше я, вооружённый сносным разговорным английским, пошёл по проторённому пути. Сначала устроился работать в Кларну в Швеции, потом работал удалённо в Топтале и, в итоге, переехал в Лондон работать в Фейсбуке. Хоть я никогда и не хотел стать профессиональным программистом, а мечтал о предпринимательстве, так и вышло - в большей степени под влиянием мифов современности. FAANG - это престижно, карьера - это классно, можно жить за рубежом и "много" зарабатывать, инвестируя излишки.

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

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

Но, если не тратить всё бабло на рестораны, аренду тачек и бессмысленный туризм, можно попробовать жизнь с разных сторон. Купить пару лет свободы и заняться своими проектами, заплатить за MBA или другое образование, жильём обзавестись, наконец. С фейсбуковской или яндексовской зарплатой это вполне подъёмные задачи.

G R O M O V → Приключения Громова

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

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

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

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

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

Встречайте новое воплощение - Приключения Громова 🤘

Друзья, из опроса очевидно, что большинству удобнее всего поболтать вечером в будний день. Пятница - это не совсем будний день, да и мне неудобно. Поэтому завтра, 22 апреля в 19 часов по Москве поболтаем про то, как преуспеть, работая в найме. За основу я возьму недавний пост про работу по найму, а также более старый пост про траектории и риски в карьере (часть 1, часть 2).

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

Голосовой чат будет прямо в телеграме, в прикреплённом чатике. До связи завтра вечером!

Откуда брать информацию про предпринимательство

Оригинальный вопрос подписчика звучал так: “какие книги почитать программисту про предпринимательство?”. Но я отвечу на немного более широкий вопрос - не только про книги (это не единственный источник информации) и не только для программистов, а для всех интересующихся предпринимательством.

Вот что вспоминается мне в первую очередь.

1. Книга Personal MBA - хорошая карманная энциклопедия о бизнесе. Затрагиваются все этапы создания продукта (собственно создание ценности, delivery, маркетинг, продажи, финансы), а также работа с собой и в команде. Классное обзорное чтиво, особенно если вы только начинаете и ещё пугаетесь терминов вроде cashflow, unit economy или customer acquisition.

2. Про customer development: Lean Customer Development и The Mom Test. Касдев, как его называют по-русски, это очень полезный навык и отрезвляющая практика, особенно для стартаперов, готовых "пилить" какую-то штуку на чистой вере в идею годами. Поможет вам не потратить время на продукт, который никому не нужен. Также обратите внимание на выступления Вани Замесина.

3. Traction - самая полезная книга про маркетинг для стартапера. В ней перечислены 19 каналов или способов продвижения и сделан акцент на важной мысли: уделяйте маркетингу не менее половины времени. Прекрасное теоретическое/более абстрактное дополнение к этой книге - This is Marketing Сета Година.

4. Про инди-хакерство и бизнес на карманные деньги: 😍 прекрасная конференция MicroConf - можно смотреть все подряд выступления и по некоторым буквально учиться. Например, там есть Josh Kaufman, автор Personal MBA, Джейсон Коэн, основатель WP Engine, и много других крутых ребят. Когда-то я и подумать не мог, что в мире есть достаточное количество предпринимателей, которые делают прибыльные (с оборотом от десятков тысяч до миллионов долларов в год) интернет-бизнесы на карманные деньги. Неплохое сообщество таких людей - Indie Hackers.

5. Творческим людям полезно почитать War of Art, чтобы понять, как совладать с внутренними демонами, победить прокрастинацию и стабильно выдавать результаты.

6. The Lean Startup - признаюсь, что только листал эту книгу, но она считается чуть ли не библией стартапера. Главная идея в том, чтобы быть lean - то есть максимально быстро и дешёво проверять идеи. Но вам стоит почитать самостоятельно.

Из более развлекательного и вдохновляющего приходят в голову следующие штуки.

7. И ботаники делают бизнес - книга про Фёдора Овчинникова, основателя Додо Пиццы из Сыктывкара, и его предпринимательский путь. Сейчас Фёдор уже звезда, но начинал он очень скромно и прошёлся по всем возможным граблям, заготовленным для мелких предпринимателей. Не совсем про интернет и цифровые продукты, но всё равно вдохновляющее и интересное чтиво. Ещё у него есть блог Сила Ума.

8. Канал Big Money - YouTube-проект Евгения Черняка, который берёт интервью у крутых предпринимателей. Мне вспоминаются интервью с Фёдором из Додо Пиццы, основателем EPAM, ребятами из Preply (это такой украинский маркетплейс преподавателей языков) и, для ржаки, Портнягиным (моё любимое - почти бизнес-молодость, даже круче).

9. Русские Норм Елизаветы Осетинской - она приглашает не только предпринимателей, но среди её гостей было много интересных ребят, например, Юрий Мильнер, Аркадий Добкин (тот же EPAM), Микита Микадо.

А что читаете, смотрите или слушаете про предпринимательство вы? Поделитесь в комментариях.