Тысяча преданных фанатов
В 2008 году Кевин Келли, основатель и редактор журнала Wired, написал статью 1000 True Fans про passion economy - экономику создаталей, независимых от распространённых средств дистрибуции. Мне она кажется особенно полезной в качестве размышления о современном мире и роли работы и заработка в нём.
Почитайте оригинал, а ниже основные тезисы с моими комментариями.
Вам может быть достаточно всего 1000 преданных фанатов, чтобы заработать себе на жизнь. Каждому из них реалистично продать на $100 в год и, делая это без посредников, заработать $100k за год. Сумма, достаточная для жизни одного человека в реалиях США.
Преданный фанат - это человек, который поедет за 200 километров, чтобы послушать ваше выступление, купит на DVD сборник ваших бесплатных youtube-видео. Разумеется, такими будут не все.
В эпоху распределённых коммуникаций, у продавцов снова появилась возможность напрямую взаимодействовать с покупателями, а не через ритейлеров - магазины, издательства и прочие площадки. А значит, знать их имена и имейлы, иметь возможность поддерживать отношения и следить за изменением вкусов и предпочтений.
Поэтому я считаю, что иметь свою площадку - идеально, сайт и email-рассылку, или минимально модерируемый и потенциально подверженный блокировкам канал связи с подписчиками жизненно важно.
Кроме прямой связи с фанатами, peer-to-peer коммуникация и продажи позволяют оставить себе все деньги от продажи, а не только лицензионные отчисления. Это значит, что вам больше не нужны миллионы читателей или покупателей, чтобы зарабатывать на своём творчестве.
Тысяча - не сакральное число. В зависимости от того, что вы создаёте и продаёте, от стоимости, вашего образа жизни, расходов и предпочтений, вам может понадобиться больше или меньше последователей - но эта зависимость более линейная, а значит легче масштабируется.
Любопытно, что маятник качнулся назад: если в результате промышленной революции мы стали потребителями массовых товаров, интернет позволяет создавать и продавать продукты и контент напрямую - особенно с переносом ценности в сферу цифровых продуктов и услуг.
А значит, можно быть более независимым - не только от full-time работы (это вообще странная идея, что человек должен постоянно работать, особенно сохраняя специализацию всю жизнь), но и от посредников разного рода.
В 2008 году Кевин Келли, основатель и редактор журнала Wired, написал статью 1000 True Fans про passion economy - экономику создаталей, независимых от распространённых средств дистрибуции. Мне она кажется особенно полезной в качестве размышления о современном мире и роли работы и заработка в нём.
Почитайте оригинал, а ниже основные тезисы с моими комментариями.
Вам может быть достаточно всего 1000 преданных фанатов, чтобы заработать себе на жизнь. Каждому из них реалистично продать на $100 в год и, делая это без посредников, заработать $100k за год. Сумма, достаточная для жизни одного человека в реалиях США.
Преданный фанат - это человек, который поедет за 200 километров, чтобы послушать ваше выступление, купит на DVD сборник ваших бесплатных youtube-видео. Разумеется, такими будут не все.
В эпоху распределённых коммуникаций, у продавцов снова появилась возможность напрямую взаимодействовать с покупателями, а не через ритейлеров - магазины, издательства и прочие площадки. А значит, знать их имена и имейлы, иметь возможность поддерживать отношения и следить за изменением вкусов и предпочтений.
Поэтому я считаю, что иметь свою площадку - идеально, сайт и email-рассылку, или минимально модерируемый и потенциально подверженный блокировкам канал связи с подписчиками жизненно важно.
Кроме прямой связи с фанатами, peer-to-peer коммуникация и продажи позволяют оставить себе все деньги от продажи, а не только лицензионные отчисления. Это значит, что вам больше не нужны миллионы читателей или покупателей, чтобы зарабатывать на своём творчестве.
Тысяча - не сакральное число. В зависимости от того, что вы создаёте и продаёте, от стоимости, вашего образа жизни, расходов и предпочтений, вам может понадобиться больше или меньше последователей - но эта зависимость более линейная, а значит легче масштабируется.
Любопытно, что маятник качнулся назад: если в результате промышленной революции мы стали потребителями массовых товаров, интернет позволяет создавать и продавать продукты и контент напрямую - особенно с переносом ценности в сферу цифровых продуктов и услуг.
А значит, можно быть более независимым - не только от full-time работы (это вообще странная идея, что человек должен постоянно работать, особенно сохраняя специализацию всю жизнь), но и от посредников разного рода.
Друзья, сегодня в 19 часов по Москве опять собираемся в 🎙голосовом чатике и обсуждаем ведение блога и признание сообществом для разработчиков и любых других айтишников и digital-деятелей. Если у вас есть сомнения, вопросы, комментарии или просто интерес к теме, присоединяйтесь к чату - и до связи вечером!
Telegram
Чаты-нечаты Олега Громова
Обсуждение к каналу t.me/gromov_com
Вот и меня настигла прокрастинация: вместо того, чтобы делать дизайн сайта (и запустить его уже наконец - от этого столько всего зависит!), я пишу заметки в канал и переписываю статью про публичность, чтобы опубликовать на хабре.
А всё потому, что дизайн делать сложно. У меня есть таблица с дизайн-решениями, в которой большинства вопросов я даже не коснулся ещё. И я не хочу, потому что это не дизайн делать сложно, а принимать решения сложно.
Иногда решение небольшое, например, как показать рекомендации к статье, а иногда за ним тянется целый шлейф последствий, которые влияют на весь визуальный язык.
Плюс всё это ещё руками обновлять-переставлять, никакие компоненты и стили в Фигме не спасают! И хорошо ещё, что я сам же и разработчик - могу обновить всего один экран и запросто вспомнить, как правильно. А если б разработчиком было кто-то ещё? Страшно подумать.
В конце концов, всё-таки правильно, что я решил сделать весь дизайн (ну может процентов на 80-90%) сразу. Включать в один подход весь стек - информационную архитектуру, дизайн, бэкенд и фронтенд - получается сложно.
Значит эджайл - не всегда хорошо: я быстро делаю понятные вещи (в данном случае бэкенд и прочая инфра, потому что сайт - простая штука) и буксую на сложных решениях. А потом переделываю всё туда-сюда по десять раз, и выглядит всё так себе.
А вот водопад решает: и голова про дизайн болит всего несколько дней - а не всё время, и на этапе разработки уже все важные решения приняты, бери и делай.
А всё потому, что дизайн делать сложно. У меня есть таблица с дизайн-решениями, в которой большинства вопросов я даже не коснулся ещё. И я не хочу, потому что это не дизайн делать сложно, а принимать решения сложно.
Иногда решение небольшое, например, как показать рекомендации к статье, а иногда за ним тянется целый шлейф последствий, которые влияют на весь визуальный язык.
Плюс всё это ещё руками обновлять-переставлять, никакие компоненты и стили в Фигме не спасают! И хорошо ещё, что я сам же и разработчик - могу обновить всего один экран и запросто вспомнить, как правильно. А если б разработчиком было кто-то ещё? Страшно подумать.
В конце концов, всё-таки правильно, что я решил сделать весь дизайн (ну может процентов на 80-90%) сразу. Включать в один подход весь стек - информационную архитектуру, дизайн, бэкенд и фронтенд - получается сложно.
Значит эджайл - не всегда хорошо: я быстро делаю понятные вещи (в данном случае бэкенд и прочая инфра, потому что сайт - простая штука) и буксую на сложных решениях. А потом переделываю всё туда-сюда по десять раз, и выглядит всё так себе.
А вот водопад решает: и голова про дизайн болит всего несколько дней - а не всё время, и на этапе разработки уже все важные решения приняты, бери и делай.
У Ани Булдаковой есть классный проект по поиску менторов и менти (как это по-русски-то сказать?).
Я там нашёл ментора, чтобы поработать над своими предпринимательскими скиллами: меня интересует комбинация исследований рынка, маркетинга и продуктовой работы, чтобы делать продукты, которые нужны, в сегменте рынка, в который я смогу запрыгнуть в одиночку и с минимальными инвестициями.
По-моему, найти наставника, который уже прошёлся по всем привлекательным для вас граблям, это крутая идея с огромным потенциалом для личного развития. Вам тоже рекомендую попробовать, если идея нравится так же, как и мне 👍
Я там нашёл ментора, чтобы поработать над своими предпринимательскими скиллами: меня интересует комбинация исследований рынка, маркетинга и продуктовой работы, чтобы делать продукты, которые нужны, в сегменте рынка, в который я смогу запрыгнуть в одиночку и с минимальными инвестициями.
По-моему, найти наставника, который уже прошёлся по всем привлекательным для вас граблям, это крутая идея с огромным потенциалом для личного развития. Вам тоже рекомендую попробовать, если идея нравится так же, как и мне 👍
Поможет ли профессиональный блог найти работу?
После публикации поста и длинного гайда про ведение блога и публичность меня несколько раз спрашивали, поможет ли ведение блога в поиске новой, возможно более интересной и высокооплачиваемой работы. Ответ (на мой взгляд): и да, и нет.
В долгосрочной перспективе, если вы регулярно рассказываете о своём опыте, делитесь мыслями, получаете обратную связь и вовлекаетесь в обсуждения рабочих проблем, вы явно станете более выразительными и подкованными в обсуждениях. То есть прокачаете софт-скиллы, без которых даже самые крутые разработчики сейчас мало кому нужны.
Если вы будете больше "изучать на публике", заниматься чем-то новым для себя и рассказывать об этом опыте, это наверняка поможет вам разобраться в теме лучше и обнаружить пробелы в знаниях. Ваша компетенция будет развиваться как-то так: теоретическое, отрывочное знание → навыки, подкреплённые знанием → опыт, оформленный в выразительные мысли. Тоже пригодится.
В то же время, я ни разу не слышал, чтобы кто-то находил работу вследствие ведения небольшого блога. Наверное привлечь внимание работодателей к себе может быть немного проще, если вы известны в профессиональном сообществе, но вряд ли это заменит собеседования или необходимость искать подходящую именно вам компанию.
Это верно для постоянной, full-time работы. А вот фрилансеру, портфолио которого каждый день попадается на глаза сотням потенциальных клиентов, ведение блога может оказаться полезным уже спустя пару статей.
В краткосрочной перспективе, если вы уже ищете или собираетесь искать работу в ближайшие полгода, вряд ли стоит заморачиваться написанием длинных статей и полноценной раскруткой своего блога. Это не происходит так быстро, плюс отнимает кучу времени и сил, которые вы могли бы потратить на поиск или подготовку к собеседованиям.
Если чем-то необычным и стоит заниматься перед поиском новой работы, особенно в небольших компаниях, так это сайд-проектами.
На собеседовениях часто спрашивают про проекты и опыт. И, если у вас нет феноменальных успехов на текущей работе, вам будет очень удобно рассказать про собственный проект - от идеи до деталей реализации. А вашим собеседникам это укажет сразу на несколько важных качеств: энтузиазм к профессии, желание и умение учиться, навык доводить начатое до конца, компетентность.
Про подход к сайд-проектам я скоро тоже напишу.
А у вас есть свои проекты? Расскажите в комментариях.
После публикации поста и длинного гайда про ведение блога и публичность меня несколько раз спрашивали, поможет ли ведение блога в поиске новой, возможно более интересной и высокооплачиваемой работы. Ответ (на мой взгляд): и да, и нет.
В долгосрочной перспективе, если вы регулярно рассказываете о своём опыте, делитесь мыслями, получаете обратную связь и вовлекаетесь в обсуждения рабочих проблем, вы явно станете более выразительными и подкованными в обсуждениях. То есть прокачаете софт-скиллы, без которых даже самые крутые разработчики сейчас мало кому нужны.
Если вы будете больше "изучать на публике", заниматься чем-то новым для себя и рассказывать об этом опыте, это наверняка поможет вам разобраться в теме лучше и обнаружить пробелы в знаниях. Ваша компетенция будет развиваться как-то так: теоретическое, отрывочное знание → навыки, подкреплённые знанием → опыт, оформленный в выразительные мысли. Тоже пригодится.
В то же время, я ни разу не слышал, чтобы кто-то находил работу вследствие ведения небольшого блога. Наверное привлечь внимание работодателей к себе может быть немного проще, если вы известны в профессиональном сообществе, но вряд ли это заменит собеседования или необходимость искать подходящую именно вам компанию.
Это верно для постоянной, full-time работы. А вот фрилансеру, портфолио которого каждый день попадается на глаза сотням потенциальных клиентов, ведение блога может оказаться полезным уже спустя пару статей.
В краткосрочной перспективе, если вы уже ищете или собираетесь искать работу в ближайшие полгода, вряд ли стоит заморачиваться написанием длинных статей и полноценной раскруткой своего блога. Это не происходит так быстро, плюс отнимает кучу времени и сил, которые вы могли бы потратить на поиск или подготовку к собеседованиям.
Если чем-то необычным и стоит заниматься перед поиском новой работы, особенно в небольших компаниях, так это сайд-проектами.
На собеседовениях часто спрашивают про проекты и опыт. И, если у вас нет феноменальных успехов на текущей работе, вам будет очень удобно рассказать про собственный проект - от идеи до деталей реализации. А вашим собеседникам это укажет сразу на несколько важных качеств: энтузиазм к профессии, желание и умение учиться, навык доводить начатое до конца, компетентность.
Про подход к сайд-проектам я скоро тоже напишу.
А у вас есть свои проекты? Расскажите в комментариях.
Из Фейсбука в стартап
Через месяц я выхожу на работу в стартап Hook. Уже получены новые рабочие визы, написано заявление в Фейсбук (месяц назад - тут notice period 8 недель), осталось только доработать месяц - и на новое место.
Вот почему я ухожу.
❶ В Хуке я буду отвечать за весь фронтенд: сначала писать код, а потом, если компания будет расти, нанимать команду. Это не бог весть какая ответственность для меня - по крайней мере, ничего нового, - но намного интереснее и лучше, чем пилить малюсенькие фичи для одного из тысячи внутренних приложений внутри компании-монстра. В стартапе от моих действий зависит, без преувеличения, судьба компании - а в Фейсбуке от них не зависит ничего.
❷ Мне больше нравятся маленькие команды, где я знаю каждого человека: в Хуке я 6-й по счёту сотрудник, а в Фейсбуке половина моих коллег наверняка не вспомнит как меня зовут спустя год. Немного лучше Фейсбука был Топтал - но основное время я всё равно проводил с командой из 6-8 человек, мной же и нанятой преимущественно. А всего в компании было несколько сотен разработчиков, многовато.
❸ Hook работает в интересной для меня сфере: удержание клиентов в SaaS-компаниях. Это и исследования и статистика, которые я полюбил в Яндексе, и подписочный бизнес - что мне хотелось бы делать в конце концов, и проблемы удержания (retention) и customer success, которые заботят меня как предпринимателя. Хочется делать полезные продукты, к которым возвращаются.
❹ Работа в фейсбуках и гуглах не вписывается в мои представления о прекрасном. Тут и общее направление развития компании (захватить весь мир своими сервисами, чтобыпродать всю возможную рекламу позволить всем общаться в сети), и механики (придумать залипуху получше, чтоб откручивать побольше рекламы пользователям больше нравилось), и детали самой работы - тренинги, нормированное общение, формальные и зарегулированные отношения, все эти PSC и фидбэки на всё и всех. Такая среда заставляет меня чувствовать себя если не рабом, то каким-то роботом, все процессы и пути для которого уже определены кем-то сверху.
❺ В Фейсбуке сложно, потому что он очень большой и быстро меняется, а ещё тут слишком много хаоса. Это спорный пункт: если бы мне хотелось работать в компании, вероятно, я нашёл бы способ победить сложность. Но заставить себя полюбить весь этот бардак мне не удалось - впрочем, я практически сразу разочаровался в идее работы в корпорации.
❻ В стартапе платят меньше, особенно с учётом бонусов, RSU-рефрешеров и роста акций в Фейсбуке. Но я иду в стартап не за деньгами и даже не за призрачной возможностью разбогатеть. Я хочу сделать что-то заметное, получить новый опыт - в том числе, посмотреть на жизнь компании на грани выживания изнутри. В будущем это наверняка поможет мне достигнуть своей цели - уйти в предпринимательство фултайм и ни от кого не зависеть.
❼ Не в последнюю очередь, я недавно узнал, что у Фейсбука очень людоедское отношение к интеллектуальной собственности: при желании компания может претендовать абсолютно на всё, что я создаю - в рабочее и нерабочее время, на своём или их оборудовании, связанное и не связанное с бизнесом компании. На практике, я думаю, никто не покусится на безобидный сайд-проект или блог (если не считать истории с Техлидом). По сути же, для меня неприемлимо, чтобы кто-то имел даже теоретическую возможность претендовать на то, что я создаю вне работы. С Хуком я договорился так, что могу работать над своими проектами в свободное время, если они не конкурируют с бизнесом компании.
Я уже встречался с новой командой: после года удалёнки в Фейсбуке, без людей и какого-либо живого общения, войти в настоящий офис с несколькими живыми людьми, все без масок, где каждый искренне интересуется тобой - это просто какая-то магия! 🔥
P.S. Сегодня вечером в 19:15 по Москве поговорим в голосовом чатике про работу в стартапах и корпорациях. Присоединяйтесь, если вам интересна тема - приносите свои истории, комментарии, вопросы. До связи!
Через месяц я выхожу на работу в стартап Hook. Уже получены новые рабочие визы, написано заявление в Фейсбук (месяц назад - тут notice period 8 недель), осталось только доработать месяц - и на новое место.
Вот почему я ухожу.
❶ В Хуке я буду отвечать за весь фронтенд: сначала писать код, а потом, если компания будет расти, нанимать команду. Это не бог весть какая ответственность для меня - по крайней мере, ничего нового, - но намного интереснее и лучше, чем пилить малюсенькие фичи для одного из тысячи внутренних приложений внутри компании-монстра. В стартапе от моих действий зависит, без преувеличения, судьба компании - а в Фейсбуке от них не зависит ничего.
❷ Мне больше нравятся маленькие команды, где я знаю каждого человека: в Хуке я 6-й по счёту сотрудник, а в Фейсбуке половина моих коллег наверняка не вспомнит как меня зовут спустя год. Немного лучше Фейсбука был Топтал - но основное время я всё равно проводил с командой из 6-8 человек, мной же и нанятой преимущественно. А всего в компании было несколько сотен разработчиков, многовато.
❸ Hook работает в интересной для меня сфере: удержание клиентов в SaaS-компаниях. Это и исследования и статистика, которые я полюбил в Яндексе, и подписочный бизнес - что мне хотелось бы делать в конце концов, и проблемы удержания (retention) и customer success, которые заботят меня как предпринимателя. Хочется делать полезные продукты, к которым возвращаются.
❹ Работа в фейсбуках и гуглах не вписывается в мои представления о прекрасном. Тут и общее направление развития компании (захватить весь мир своими сервисами, чтобы
❺ В Фейсбуке сложно, потому что он очень большой и быстро меняется, а ещё тут слишком много хаоса. Это спорный пункт: если бы мне хотелось работать в компании, вероятно, я нашёл бы способ победить сложность. Но заставить себя полюбить весь этот бардак мне не удалось - впрочем, я практически сразу разочаровался в идее работы в корпорации.
❻ В стартапе платят меньше, особенно с учётом бонусов, RSU-рефрешеров и роста акций в Фейсбуке. Но я иду в стартап не за деньгами и даже не за призрачной возможностью разбогатеть. Я хочу сделать что-то заметное, получить новый опыт - в том числе, посмотреть на жизнь компании на грани выживания изнутри. В будущем это наверняка поможет мне достигнуть своей цели - уйти в предпринимательство фултайм и ни от кого не зависеть.
❼ Не в последнюю очередь, я недавно узнал, что у Фейсбука очень людоедское отношение к интеллектуальной собственности: при желании компания может претендовать абсолютно на всё, что я создаю - в рабочее и нерабочее время, на своём или их оборудовании, связанное и не связанное с бизнесом компании. На практике, я думаю, никто не покусится на безобидный сайд-проект или блог (если не считать истории с Техлидом). По сути же, для меня неприемлимо, чтобы кто-то имел даже теоретическую возможность претендовать на то, что я создаю вне работы. С Хуком я договорился так, что могу работать над своими проектами в свободное время, если они не конкурируют с бизнесом компании.
Я уже встречался с новой командой: после года удалёнки в Фейсбуке, без людей и какого-либо живого общения, войти в настоящий офис с несколькими живыми людьми, все без масок, где каждый искренне интересуется тобой - это просто какая-то магия! 🔥
P.S. Сегодня вечером в 19:15 по Москве поговорим в голосовом чатике про работу в стартапах и корпорациях. Присоединяйтесь, если вам интересна тема - приносите свои истории, комментарии, вопросы. До связи!
Какими должны быть условия работы программистов и почему?
Пришла мне в голову идея: отвечать на посты в каналах, на которые я подписан. Без цели покритиковать или поддержать, а как реакция на мысли, которые меня зацепили. Посмотрим, понравится ли вам - и особенно авторам каналов 🤣
Сегодня отвечаю на пост "Бренд" канала 2Pizza. Он не про бренд в общем смысле, а про HR-бренд: какими должны быть условия работы разработчика, чтобы позиция была привлекательной. Канал, соответственно, тоже не про пиццу - но это мы и так поняли.
В посте явно есть здравые мысли: про отсутствие глупого контроля и микроменеджмента, одинаково хорошее отношение ко всем сотрудникам, удобную мебель и окна в офисе, про обязательную индексацию зарплаты, причём в связи с ростом всего рынка, а не только инфляцией. Про доверие и прозрачность.
Все остальные мысли иначе как спорными не назовёшь.
Лет 15 назад, когда я только начинал карьеру, программист в обыкновенной компании находился где-то на уровне слесаря по уровню влияния на бизнес. Платили соответственно, а из бонусов были туалет на этаже и курилка под лестницей. Ещё "офисный" стул и стол из ламинированного ДСП да какой-нибудь не первой свежести комп под ним.
Десятилетие спустя потребление ушло в онлайн: начиная от нетфликсов и заканчивая агрегаторами всего офлайна. Реклама тоже почти вся в интернете. Сегодня даже обыкновенный веб-разработчик - это представитель элиты, создающий потребительские чудеса в свободное от игры в плейстейшн время. Рынок труда характеризуется ёмким термином "рынок кандидата".
В отрасли действительно куча бабла, в том числе свободного, за которое сражаются стартапы. Но большинство компаний, предоставляющих подобные плюшки своим сотрудникам, все эти яндексы и гуглы, не просто прибыльные, а сверхприбыльные - оттого и могут позволить себе всё перечисленное выше, а на сдачу более-менее адекватное, доверительное отношение ко всем.
Они же задают правила игры: именно в богатые корпорации самые сложные в отрасли собеседования, где недостаточно просто поболтать, сказать "я это могу" и пожать руки, чтобы завтра выйти на работу в самый дорогой в мире офис.
Некоторые готовятся, без преувеличения, годами, чтобы попасть в "компанию мечты" - не говоря уж о докторах наук, положивших на алтарь образования десятилетия, чтобы потом крутить алгоритмы таргетинга в фейсбуке.
В таких компаниях сотни и тысячи кандидатов на каждую позицию, и они, предоставляя наилучшие из возможных условия, и спрашивают с каждого дай бог. Чего стоят только ревью производительности каждые полгода-год, в том или ином виде существующие в каждом техногиганте, по результатам которых запросто можно вылететь из компании.
При этом компании поменьше не могут себе позволить перебирать кандидатов месяцами - на это нет ни денег, ни самих кандидатов. Любой столкнувшийся с поиском разработчиков с нанимающей стороны знает, как сложно найти подходящего человека: подкованного технически, с совпадающими ценностями, хорошего командного игрока.
Они-то и вынуждены проводить собеседования, состоящие из пары разговоров "за жизнь", - чтобы нанять хоть кого-то в разумный срок. Но, по определению, не могут конкурировать со сверхбогатыми монстрами индустрии. Их ресурсы конечны.
Если в таких компаниях адекватное руководство, они понимают правила игры - и будут стремиться, пусть вынужденно, предоставить сопоставимые плюшки, создать доверительные отношения. Но проверять тоже будут - иначе их бизнес разорится уже на пятом, а то и втором нанятом разработчике.
Я понимаю, откуда растут ноги у такой позиции. Собеседования в нашей индустрии - это жесть: не понятно, зачем стартапу с CRUD-поделкой "олимпиадные" тестовые задания для фронтендеров. Или чем работа веб-питониста в яндексе или фейсбуке принципиально отличается от такой же в аутсорс-галере?
Но не понимаю, как можно игнорировать реалии рынка-олигополии, ни слова не сказать про свою роль в компании и ответственность за успех её бизнеса, а также совершенно не хотеть доказать свою исключительность и звёздность на практике?
Вы либо крестик снимите, либо трусы наденьте.
Пришла мне в голову идея: отвечать на посты в каналах, на которые я подписан. Без цели покритиковать или поддержать, а как реакция на мысли, которые меня зацепили. Посмотрим, понравится ли вам - и особенно авторам каналов 🤣
Сегодня отвечаю на пост "Бренд" канала 2Pizza. Он не про бренд в общем смысле, а про HR-бренд: какими должны быть условия работы разработчика, чтобы позиция была привлекательной. Канал, соответственно, тоже не про пиццу - но это мы и так поняли.
В посте явно есть здравые мысли: про отсутствие глупого контроля и микроменеджмента, одинаково хорошее отношение ко всем сотрудникам, удобную мебель и окна в офисе, про обязательную индексацию зарплаты, причём в связи с ростом всего рынка, а не только инфляцией. Про доверие и прозрачность.
Все остальные мысли иначе как спорными не назовёшь.
Лет 15 назад, когда я только начинал карьеру, программист в обыкновенной компании находился где-то на уровне слесаря по уровню влияния на бизнес. Платили соответственно, а из бонусов были туалет на этаже и курилка под лестницей. Ещё "офисный" стул и стол из ламинированного ДСП да какой-нибудь не первой свежести комп под ним.
Десятилетие спустя потребление ушло в онлайн: начиная от нетфликсов и заканчивая агрегаторами всего офлайна. Реклама тоже почти вся в интернете. Сегодня даже обыкновенный веб-разработчик - это представитель элиты, создающий потребительские чудеса в свободное от игры в плейстейшн время. Рынок труда характеризуется ёмким термином "рынок кандидата".
В отрасли действительно куча бабла, в том числе свободного, за которое сражаются стартапы. Но большинство компаний, предоставляющих подобные плюшки своим сотрудникам, все эти яндексы и гуглы, не просто прибыльные, а сверхприбыльные - оттого и могут позволить себе всё перечисленное выше, а на сдачу более-менее адекватное, доверительное отношение ко всем.
Они же задают правила игры: именно в богатые корпорации самые сложные в отрасли собеседования, где недостаточно просто поболтать, сказать "я это могу" и пожать руки, чтобы завтра выйти на работу в самый дорогой в мире офис.
Некоторые готовятся, без преувеличения, годами, чтобы попасть в "компанию мечты" - не говоря уж о докторах наук, положивших на алтарь образования десятилетия, чтобы потом крутить алгоритмы таргетинга в фейсбуке.
В таких компаниях сотни и тысячи кандидатов на каждую позицию, и они, предоставляя наилучшие из возможных условия, и спрашивают с каждого дай бог. Чего стоят только ревью производительности каждые полгода-год, в том или ином виде существующие в каждом техногиганте, по результатам которых запросто можно вылететь из компании.
При этом компании поменьше не могут себе позволить перебирать кандидатов месяцами - на это нет ни денег, ни самих кандидатов. Любой столкнувшийся с поиском разработчиков с нанимающей стороны знает, как сложно найти подходящего человека: подкованного технически, с совпадающими ценностями, хорошего командного игрока.
Они-то и вынуждены проводить собеседования, состоящие из пары разговоров "за жизнь", - чтобы нанять хоть кого-то в разумный срок. Но, по определению, не могут конкурировать со сверхбогатыми монстрами индустрии. Их ресурсы конечны.
Если в таких компаниях адекватное руководство, они понимают правила игры - и будут стремиться, пусть вынужденно, предоставить сопоставимые плюшки, создать доверительные отношения. Но проверять тоже будут - иначе их бизнес разорится уже на пятом, а то и втором нанятом разработчике.
Я понимаю, откуда растут ноги у такой позиции. Собеседования в нашей индустрии - это жесть: не понятно, зачем стартапу с CRUD-поделкой "олимпиадные" тестовые задания для фронтендеров. Или чем работа веб-питониста в яндексе или фейсбуке принципиально отличается от такой же в аутсорс-галере?
Но не понимаю, как можно игнорировать реалии рынка-олигополии, ни слова не сказать про свою роль в компании и ответственность за успех её бизнеса, а также совершенно не хотеть доказать свою исключительность и звёздность на практике?
Вы либо крестик снимите, либо трусы наденьте.
Про RSU и опционы
Знакомые попросили написать несколько слов про RSU и опционы для статьи. Не уверен, что этот и без того короткий текст будет опубликован целиком - поэтому делюсь им с вами.
Многие крупные состоявшиеся компании, например Яндекс или Фейсбук, предлагают разработчикам RSU - restricted stock units, в простонародье "акции".
В отличие от опционов, которые позволяют купить акции компании по фиксированной в контракте цене, RSU выдаются бесплатно. Их выдают грантами, обычно привязанными к оговоренной денежной сумме, которые переходят в собственность (vesting) равными долями, обычно в течение 4 лет.
Например, в вашем офере может быть оговорен RSU-грант, эквивалентный $100,000. В момент выдачи гранта, если акция стоит $100, вам достанется пакет из 1000 акций.
Самое распространённое расписание вестинга будет такое, что через 1 год (cliff) вы сможете распоряжаться 1/4 частью акций, а дальше, каждый квартал, ещё 1/16 частью. Обычно их либо продают сразу, либо оставляют в надежде на рост - тогда придётся заплатить налог на рост активов (capital gains tax), если акции вырастут.
RSU проще в обращении и обычно предсказуемее опционов. Фактически, RSU - это дополнительный бонус, привязанный к стоимости акций публичной компании. Его всегда можно продать, даже по более низкой цене, чем в момент выдачи.
Опцион - скорее лотерейный билет. Часто его выдают на акции компании, которая ещё не вышла на биржу. Даже если компания публичная, стоимость акций может оказаться ниже стоимости покупки, и тогда опцион нет смысла использовать. Также на акции, полученные через опцион, обычно сложнее заплатить налог.
@gromov_com
Знакомые попросили написать несколько слов про RSU и опционы для статьи. Не уверен, что этот и без того короткий текст будет опубликован целиком - поэтому делюсь им с вами.
Многие крупные состоявшиеся компании, например Яндекс или Фейсбук, предлагают разработчикам RSU - restricted stock units, в простонародье "акции".
В отличие от опционов, которые позволяют купить акции компании по фиксированной в контракте цене, RSU выдаются бесплатно. Их выдают грантами, обычно привязанными к оговоренной денежной сумме, которые переходят в собственность (vesting) равными долями, обычно в течение 4 лет.
Например, в вашем офере может быть оговорен RSU-грант, эквивалентный $100,000. В момент выдачи гранта, если акция стоит $100, вам достанется пакет из 1000 акций.
Самое распространённое расписание вестинга будет такое, что через 1 год (cliff) вы сможете распоряжаться 1/4 частью акций, а дальше, каждый квартал, ещё 1/16 частью. Обычно их либо продают сразу, либо оставляют в надежде на рост - тогда придётся заплатить налог на рост активов (capital gains tax), если акции вырастут.
RSU проще в обращении и обычно предсказуемее опционов. Фактически, RSU - это дополнительный бонус, привязанный к стоимости акций публичной компании. Его всегда можно продать, даже по более низкой цене, чем в момент выдачи.
Опцион - скорее лотерейный билет. Часто его выдают на акции компании, которая ещё не вышла на биржу. Даже если компания публичная, стоимость акций может оказаться ниже стоимости покупки, и тогда опцион нет смысла использовать. Также на акции, полученные через опцион, обычно сложнее заплатить налог.
@gromov_com
Есть ли у вас сайд-проекты?
Anonymous Poll
17%
Да (кидайте ссылки в комментарии)
43%
Не хватает времени, но хотелось бы
3%
Нет, а зачем?
9%
Нет, мне и так кодинга хватает
28%
Посмотреть результаты
Зачем компания давать тестовые задания, а нам — тратить время на них?
На этот пост меня натолкнул текст в канале Стой под стрелой про булшит-детектор. В конце автор пишет, что пост не про тестовые задания, и я с ним согласен: полезно и важно понимать, зачем мы делаем что-либо в принципе. А повторять за кем-то, становясь последователем карго-культа, глупо.
Но написать хочу про тестовые задания на собеседованиях.
Я отсобеседовал сотни человек, в Яндекс и Топтал, и просмотрел тысячи резюме. Подходящих кандидатов - уж не знаю, почему - действительно мало. В то же время, я часто встречаю в сети скепсис по поводу тестовых заданий: нафиг мне, крутану, чей час стоит $100, выполнять задания?
Простой ответ на этот вопрос: потому что мне нравится ваша компания, продукт, команда - и я хочу с вами работать. В таком случае задания и вам полезны: присмотритесь к компании, к людям, задающим вопросы. Не понравилось - до свидания, почему нет? Иначе это как жаловаться на трату времени на первые свидания.
Если же вы откликаетесь на десятки вакансий, тратить на домашние задания по несколько часов - скорее всего, непозволительная роскошь. Но это вопрос к вам: зачем вы откликаетесь на столько позиций?
А компании? Зачем они дают тестовые задания и просят писать код на собеседовании? Неужели недостаточно гитхаба, опыта и рекомендаций?
Про гитхаб. У большинства кандидатов, которых я видел, ничего интересного в профиле нет. У существенной части гитхаб-аккуанты просто пустые. Это, кстати, отсылка к необходимости быть публичным, заниматься сайд-проектами - чтобы было что показать и о чём рассказать.
Опыт, особенно заявленный в резюме, обычно никак не проверить. Задавая каверзные вопросы на собеседовании, удаётся узнать, что человек на самом деле делал, чему научился. Нередко в резюме заявлено, что кандидат сделал проект с нуля, добился выдающихся результатов, а во время расспросов выясняется, что это ребята бэкенд на PHP писали, а он рядом стоял. Это, кстати, тоже сигнал - скорее всего, такого не наймут.
Рекомендации? Может и можно выяснить важные подробности об опыте и навыках кандидата через рекомендации. Но на практике я такого не встречал. Максимум, на что идёт большинство компаний - это проверка факта трудоустройства. А такого, чтоб звонить прошлым коллегам и руководителям и расспрашивать про бывшего коллегу, нет.
Да и сколько людей будут помнить достаточно много и хорошо, а ещё будут готовы поделиться честным фидбэком? А что делать с ситуациями, когда кандидат не делится с текущим начальством планами о смене работы?
Вообще смысл тестовых заданий шире проверки навыка писать код или решать алгоритмические задачки. Важно не только какой код был написан, а ещё и почему, какие варианты решения задачи кандидат рассматривал, на какие компромиссы пошёл.
Это и проверка на внимательность: сложно сосчитать, сколько раз я видел людей, решающих не ту задачу на собеседовании - несмотря не проговоренные условия и заданные вопросы.
В конце концов, важно уметь рассказать про то, что вы сделали. Начать от общего и идти к частному, объяснить свой образ мышления, упомянуть проблемы, которых вы изначально не учли, а также решения, которые вы приняли, и их возможные последствия.
Если я нанимаю вас в свою команду, и нам потом работать вместе несколько лет, мне важно, чтобы вы могли объяснить, пусть и не всегда технически корректно, что происходит в коде, почему архитектура именно такая, как это всё подстроится под новые требования и заработает под нагрузкой (пресловутое О-большое). Насколько ваш код понятен другим - и что вы сделали, чтобы он был понятным.
Поэтому тестовые задания и нужны компаниям. Конечно, лучше знать ответ на вопрос "зачем мы даём тестовое задание". Но даже если в какой-то команде не могут внятно этого проговорить (ну точно софт-скиллов не хватило), это не означает автоматически, что опытные интервьюеры не считывают эти сигналы неосозанно.
А если стремиться сделать найм максимально объективным и исключающим false positives, получатся FAANG-style собеседования, с десятком секций, кучей стресса и непонятными отказами.
На этот пост меня натолкнул текст в канале Стой под стрелой про булшит-детектор. В конце автор пишет, что пост не про тестовые задания, и я с ним согласен: полезно и важно понимать, зачем мы делаем что-либо в принципе. А повторять за кем-то, становясь последователем карго-культа, глупо.
Но написать хочу про тестовые задания на собеседованиях.
Я отсобеседовал сотни человек, в Яндекс и Топтал, и просмотрел тысячи резюме. Подходящих кандидатов - уж не знаю, почему - действительно мало. В то же время, я часто встречаю в сети скепсис по поводу тестовых заданий: нафиг мне, крутану, чей час стоит $100, выполнять задания?
Простой ответ на этот вопрос: потому что мне нравится ваша компания, продукт, команда - и я хочу с вами работать. В таком случае задания и вам полезны: присмотритесь к компании, к людям, задающим вопросы. Не понравилось - до свидания, почему нет? Иначе это как жаловаться на трату времени на первые свидания.
Если же вы откликаетесь на десятки вакансий, тратить на домашние задания по несколько часов - скорее всего, непозволительная роскошь. Но это вопрос к вам: зачем вы откликаетесь на столько позиций?
А компании? Зачем они дают тестовые задания и просят писать код на собеседовании? Неужели недостаточно гитхаба, опыта и рекомендаций?
Про гитхаб. У большинства кандидатов, которых я видел, ничего интересного в профиле нет. У существенной части гитхаб-аккуанты просто пустые. Это, кстати, отсылка к необходимости быть публичным, заниматься сайд-проектами - чтобы было что показать и о чём рассказать.
Опыт, особенно заявленный в резюме, обычно никак не проверить. Задавая каверзные вопросы на собеседовании, удаётся узнать, что человек на самом деле делал, чему научился. Нередко в резюме заявлено, что кандидат сделал проект с нуля, добился выдающихся результатов, а во время расспросов выясняется, что это ребята бэкенд на PHP писали, а он рядом стоял. Это, кстати, тоже сигнал - скорее всего, такого не наймут.
Рекомендации? Может и можно выяснить важные подробности об опыте и навыках кандидата через рекомендации. Но на практике я такого не встречал. Максимум, на что идёт большинство компаний - это проверка факта трудоустройства. А такого, чтоб звонить прошлым коллегам и руководителям и расспрашивать про бывшего коллегу, нет.
Да и сколько людей будут помнить достаточно много и хорошо, а ещё будут готовы поделиться честным фидбэком? А что делать с ситуациями, когда кандидат не делится с текущим начальством планами о смене работы?
Вообще смысл тестовых заданий шире проверки навыка писать код или решать алгоритмические задачки. Важно не только какой код был написан, а ещё и почему, какие варианты решения задачи кандидат рассматривал, на какие компромиссы пошёл.
Это и проверка на внимательность: сложно сосчитать, сколько раз я видел людей, решающих не ту задачу на собеседовании - несмотря не проговоренные условия и заданные вопросы.
В конце концов, важно уметь рассказать про то, что вы сделали. Начать от общего и идти к частному, объяснить свой образ мышления, упомянуть проблемы, которых вы изначально не учли, а также решения, которые вы приняли, и их возможные последствия.
Если я нанимаю вас в свою команду, и нам потом работать вместе несколько лет, мне важно, чтобы вы могли объяснить, пусть и не всегда технически корректно, что происходит в коде, почему архитектура именно такая, как это всё подстроится под новые требования и заработает под нагрузкой (пресловутое О-большое). Насколько ваш код понятен другим - и что вы сделали, чтобы он был понятным.
Поэтому тестовые задания и нужны компаниям. Конечно, лучше знать ответ на вопрос "зачем мы даём тестовое задание". Но даже если в какой-то команде не могут внятно этого проговорить (ну точно софт-скиллов не хватило), это не означает автоматически, что опытные интервьюеры не считывают эти сигналы неосозанно.
А если стремиться сделать найм максимально объективным и исключающим false positives, получатся FAANG-style собеседования, с десятком секций, кучей стресса и непонятными отказами.
Заказал я на одном популярном сайте авиабилеты. Данные пассажира выбрал из выпадашки: сайтом я пользовался уже когда-то. Мои данные там сохранены, включая номер заграна - они же и показались в менюшке, а в форме показались только имя-фамилия.
Проходит пара дней, мне падает на почту посадочный. А в нём номер моего российского паспорта - для нескольких международных перелётов. Ну как так, я же точно выбирал свой загран! Хорошо, до полётов ещё несколько дней, есть шанс всё исправить.
Захожу проверить себя, выбираю новые билеты - и точно, в выпадашке моё имя с правильными данными заграна. А вот в личном кабинете, в “Записной книжке” (тут активные путешественники угадали, о каком сайте речь) два пассажира сохранено: имя, фамилия, всё-всё-всё одинаковое, моё - но у одного российский паспорт, а у другого загран.
И тут уже не важно, в каком месте баг - в UI, в бэкенде, в неоднозначном контракте их взаимодействия. Важно, что кто-то просто не подумал, причём, наверняка, несколько разных человек.
Не удивился фронтендер, что разные паспорта одного пассажира схлопываются до последнего. Не подумал бэкендер: а что сделать ключом в табличке и какие данные отдать через API. Не подумал QA или тестировщик, что у человека может быть не один, а два, три и даже больше разных паспортов.
PM на всё это просто махнул рукой, потому что сайту авиабилетов оптимизировать надо предложения страховок и отелей, чтобы заработать. Только руководитель саппорта удивился, что после обновления интерфейса количество тикетов у его команды выросло на пару процентов.
Это, конечно, только мои предположения: реальную причину бага и ситуацию в команде я не знаю. Но что-то из этого вполне может оказаться правдой.
Поэтому даже “перекладывать джейсоны” или “делать круды” важно где. Если вам интересна предметная область, и вы с вниманием и интересом относитесь к работе, у вас есть все шансы порадовать сотни и тысячи других людей. Или, как минимум, поберечь их нервы.
Проходит пара дней, мне падает на почту посадочный. А в нём номер моего российского паспорта - для нескольких международных перелётов. Ну как так, я же точно выбирал свой загран! Хорошо, до полётов ещё несколько дней, есть шанс всё исправить.
Захожу проверить себя, выбираю новые билеты - и точно, в выпадашке моё имя с правильными данными заграна. А вот в личном кабинете, в “Записной книжке” (тут активные путешественники угадали, о каком сайте речь) два пассажира сохранено: имя, фамилия, всё-всё-всё одинаковое, моё - но у одного российский паспорт, а у другого загран.
И тут уже не важно, в каком месте баг - в UI, в бэкенде, в неоднозначном контракте их взаимодействия. Важно, что кто-то просто не подумал, причём, наверняка, несколько разных человек.
Не удивился фронтендер, что разные паспорта одного пассажира схлопываются до последнего. Не подумал бэкендер: а что сделать ключом в табличке и какие данные отдать через API. Не подумал QA или тестировщик, что у человека может быть не один, а два, три и даже больше разных паспортов.
PM на всё это просто махнул рукой, потому что сайту авиабилетов оптимизировать надо предложения страховок и отелей, чтобы заработать. Только руководитель саппорта удивился, что после обновления интерфейса количество тикетов у его команды выросло на пару процентов.
Это, конечно, только мои предположения: реальную причину бага и ситуацию в команде я не знаю. Но что-то из этого вполне может оказаться правдой.
Поэтому даже “перекладывать джейсоны” или “делать круды” важно где. Если вам интересна предметная область, и вы с вниманием и интересом относитесь к работе, у вас есть все шансы порадовать сотни и тысячи других людей. Или, как минимум, поберечь их нервы.
Баланс между порядком и хаосом
Стабильность работы в больших компаниях часто противопоставляют риску, связанному с предпринимательством. Причём иногда это выглядит так, будто бы гарантированная зарплата и понятная работа на следующие N лет - это однозначно хорошо, а вероятность ошибиться, делая что-то своё (или по-своему) - это однозначно плохо.
При этом кажется, что люди моего поколения и старше особенно часто склоняются к стабильности и предсказуемости. Моя гипотеза такова, что после хаоса 90-х (и, с натяжкой, вообще последней сотни лет) сложно отказаться от скучной, но сытой жизни в пользу каких-то неясных перспектив и приключений.
Конечно, есть личные предпочтения. Мне нравятся приключения и риск, которые в экономической деятельности ассоциируются с предпринимательством, а кому-то больше по душе размеренная и понятная жизнь без лишнего стресса. Ничто не лучше и не хуже.
Но, экстраполируя дихотомию стабильности и непредсказуемости на жизнь в общем, мы сталкиваемся с вопросом: сколько порядка и хаоса должно быть в жизни?
На этот вопрос хорошо ответил мой любимый Джордан Питерсон (если вы относитесь к его позиции скептически, посмотрите записи его лекций из университета - они намного глубже, интереснее и, в некотором смысле, нейтральнее, чем его политические взгляды). Он коснулся сразу нескольких связанных с этим идей, о которых я кратко расскажу.
Единственное, что постоянно в жизни любого человека, вне зависимости от его положения, места и времени жительства и занятия, это некий (дис)баланс между хаосом и порядком.
В восточной традиции этот баланс обозначется символом Инь-Ян. При этом порядок легко перетекает в хаос и наоборот: неудивительно, что даже кажущиеся стабильными карьеры и семьи рушатся в один момент, в то время как из хаоса, или из ничего, всё время возникают новые системы - отношения, компании и идеи.
Ещё интереснее идея Пути, или Дао. Правильным и желаемым положением для любого человека является идеальный баланс между порядком и хаосом, линия, разделяющая чёрное и белое в Инь-Ян.
Даже нервная система человека эволюционировала таким образом, чтобы максимально точно выделять в жизни ситуации идеального баланса: в таких обстоятельствах наша деятельность максимально интересует и вовлекает - и контролировать это ощущение сознательно, по-видимому, невозможно.
Советский психолог Выготский, тёзка моего сына, сформулировал те же идеи в своей теории Зоны ближайшего развития - если у вас есть дети, вы наверняка слышали о ней. Но вот что мне было неизвестно до знакомства с Питерсоном, это то, что эту концепцию можно применить к любому обучению, в том числе взрослых. Что, вероятно, и ввёл в обиход психолог Чиксентмихайи своими идеями про состояния Потока.
Оказываясь в ситуации полного порядка и предсказуемости, например, в корпорации или по какой-то причине слепо следуя догмам и правилам, человек легко превращается в бездушного раба. Это дословный перевод слов Питерсона (soulless slave) - очень неожиданно и приятно, что я обнаружил подтверждение идеям из книги Disciplined Minds в его лекции.
Полный хаос, отказ от социальной жизни и отсутствие каких-либо внешних структур - отношений, распорядка дня, обязательств и правил - могут вынести лишь единицы. Для большинства же из нас такие ситуации чреваты проблемами со сном и пищевым поведением, депрессией и ощущением постоянного стресса, даже террора.
Вывод простой и, как мне кажется, радостный: у каждого человека ещё с рождения есть точно откалиброванный инструмент для оценки своего положения и занятия.
Если вам интересно, и вы с полной отдачей вовлекаетесь в дело, наверняка вы находитесь в оптимальном для себя месте и занимаетесь чем-то стоящим. Если вам скучно, вы становитесь циничными и теряете эмоциональную связь с происходящим, вероятно, ваша жизнь стала слишком стабильной.
В большинстве случаев этот баланс будет временным, и нужно постоянно прислушиваться к себе, чтобы поддерживать его в правильном состоянии.
Стабильность работы в больших компаниях часто противопоставляют риску, связанному с предпринимательством. Причём иногда это выглядит так, будто бы гарантированная зарплата и понятная работа на следующие N лет - это однозначно хорошо, а вероятность ошибиться, делая что-то своё (или по-своему) - это однозначно плохо.
При этом кажется, что люди моего поколения и старше особенно часто склоняются к стабильности и предсказуемости. Моя гипотеза такова, что после хаоса 90-х (и, с натяжкой, вообще последней сотни лет) сложно отказаться от скучной, но сытой жизни в пользу каких-то неясных перспектив и приключений.
Конечно, есть личные предпочтения. Мне нравятся приключения и риск, которые в экономической деятельности ассоциируются с предпринимательством, а кому-то больше по душе размеренная и понятная жизнь без лишнего стресса. Ничто не лучше и не хуже.
Но, экстраполируя дихотомию стабильности и непредсказуемости на жизнь в общем, мы сталкиваемся с вопросом: сколько порядка и хаоса должно быть в жизни?
На этот вопрос хорошо ответил мой любимый Джордан Питерсон (если вы относитесь к его позиции скептически, посмотрите записи его лекций из университета - они намного глубже, интереснее и, в некотором смысле, нейтральнее, чем его политические взгляды). Он коснулся сразу нескольких связанных с этим идей, о которых я кратко расскажу.
Единственное, что постоянно в жизни любого человека, вне зависимости от его положения, места и времени жительства и занятия, это некий (дис)баланс между хаосом и порядком.
В восточной традиции этот баланс обозначется символом Инь-Ян. При этом порядок легко перетекает в хаос и наоборот: неудивительно, что даже кажущиеся стабильными карьеры и семьи рушатся в один момент, в то время как из хаоса, или из ничего, всё время возникают новые системы - отношения, компании и идеи.
Ещё интереснее идея Пути, или Дао. Правильным и желаемым положением для любого человека является идеальный баланс между порядком и хаосом, линия, разделяющая чёрное и белое в Инь-Ян.
Даже нервная система человека эволюционировала таким образом, чтобы максимально точно выделять в жизни ситуации идеального баланса: в таких обстоятельствах наша деятельность максимально интересует и вовлекает - и контролировать это ощущение сознательно, по-видимому, невозможно.
Советский психолог Выготский, тёзка моего сына, сформулировал те же идеи в своей теории Зоны ближайшего развития - если у вас есть дети, вы наверняка слышали о ней. Но вот что мне было неизвестно до знакомства с Питерсоном, это то, что эту концепцию можно применить к любому обучению, в том числе взрослых. Что, вероятно, и ввёл в обиход психолог Чиксентмихайи своими идеями про состояния Потока.
Оказываясь в ситуации полного порядка и предсказуемости, например, в корпорации или по какой-то причине слепо следуя догмам и правилам, человек легко превращается в бездушного раба. Это дословный перевод слов Питерсона (soulless slave) - очень неожиданно и приятно, что я обнаружил подтверждение идеям из книги Disciplined Minds в его лекции.
Полный хаос, отказ от социальной жизни и отсутствие каких-либо внешних структур - отношений, распорядка дня, обязательств и правил - могут вынести лишь единицы. Для большинства же из нас такие ситуации чреваты проблемами со сном и пищевым поведением, депрессией и ощущением постоянного стресса, даже террора.
Вывод простой и, как мне кажется, радостный: у каждого человека ещё с рождения есть точно откалиброванный инструмент для оценки своего положения и занятия.
Если вам интересно, и вы с полной отдачей вовлекаетесь в дело, наверняка вы находитесь в оптимальном для себя месте и занимаетесь чем-то стоящим. Если вам скучно, вы становитесь циничными и теряете эмоциональную связь с происходящим, вероятно, ваша жизнь стала слишком стабильной.
В большинстве случаев этот баланс будет временным, и нужно постоянно прислушиваться к себе, чтобы поддерживать его в правильном состоянии.
Полезные для фронтендеров алгоритмы
Когда-то у меня были сложные отношения с алгоритмами и вообще математикой. Классе в 8-м, уже увлекаясь программированием, я пришёл в какой-то кружок, где нам задали задачку: нарисовать треугольник Паскаля.
Я тогда вовсю ковырял С++ со справочником Страуструпа, но в алгоритмах ничего не понимал. Как решить задачку, я так и не сообразил - и в кружок ходить перестал. Хотя позже, уже в колледже, несколько раз ездил на олимпиады по программированию в составе команды. Мы даже привезли одну или две медали за призовые места, соревнуясь не только с колледжами, но и вузами юга России.
На олимпиадах мы решали литкод-подобные задачки (скучно) и писали алгоритмы для танчиков и самолётиков, сражающихся друг с другом (кайф). Разделение обязанностей в команде было такое: я (быстрее всех) писал код на С++, а пара других ребят выдумывала алгоритмы.
Следующие лет 10 про алгоритмы я не думал и редко сталкивался с ними в работе. Только готовясь к собеседованиям в фейсбук, прорешал штук 50 задач на литкоде. Стало понятно, почему спортивное программирование и задачки так увлекают многих: в какой-то момент, после преодоления первого сопротивления, приходит азарт и интерес - как же решить проблему максимально элегантно, понятно и эффективно?
Сейчас я считаю, что понимать базовые алгоритмы и структуры данных обязательно для любого программиста. Это как с музыкой: не важно, умеет ли музыкант читать ноты и писать аранжировки - он всё равно это делает, занимаясь музыкой. А если мы уже используем алгоритмы в работе, то почему бы не поучиться им хотя бы чуть-чуть?
Поэтому я задумал доклад про полезные алгоритмы для фронтендеров. Содержание будет примерно следующее:
— Алгоритмы обхода деревьев: BFS, DFS, рекурсивные и итеративные версии
— Подобные алгоритмы для древоподобных структур - вложенных массивов и словарей, сравнения, копирования и прочих операций с ними
— Сериализация и десериализация (парсинг): от CSV и JSON до HTML, JSX и Markdown, включая несериализуемые объекты и элементарный поиск циклов (в графе ссылок)
— Битовые операции и их приложение к компактным форматам (кстати, написал недавно библиотечку для упаковки boolean и integer значений в 32-битные числа) вроде Base64 и protobuf
Это то, что точно должно поместиться в получасовой обзорный доклад для конференции.
В дополнение хочу коснуться:
— Конечных автоматов для более элегантного парсинга и безглючной работы со сложными стейтами
— Элементарных алгоритмов поиска и сортировки
— Типовых алгоритмов на строках и массивах
Эти темы сложнее: не уверен, что смогу и успею раскрыть их в рамках доклада, и польза от них как будто бы ниже в приложении к day-to-day работе.
А вы что скажете? С какими алгоритмами приходилось сталкиваться во фронтенде и вебе?
Когда-то у меня были сложные отношения с алгоритмами и вообще математикой. Классе в 8-м, уже увлекаясь программированием, я пришёл в какой-то кружок, где нам задали задачку: нарисовать треугольник Паскаля.
Я тогда вовсю ковырял С++ со справочником Страуструпа, но в алгоритмах ничего не понимал. Как решить задачку, я так и не сообразил - и в кружок ходить перестал. Хотя позже, уже в колледже, несколько раз ездил на олимпиады по программированию в составе команды. Мы даже привезли одну или две медали за призовые места, соревнуясь не только с колледжами, но и вузами юга России.
На олимпиадах мы решали литкод-подобные задачки (скучно) и писали алгоритмы для танчиков и самолётиков, сражающихся друг с другом (кайф). Разделение обязанностей в команде было такое: я (быстрее всех) писал код на С++, а пара других ребят выдумывала алгоритмы.
Следующие лет 10 про алгоритмы я не думал и редко сталкивался с ними в работе. Только готовясь к собеседованиям в фейсбук, прорешал штук 50 задач на литкоде. Стало понятно, почему спортивное программирование и задачки так увлекают многих: в какой-то момент, после преодоления первого сопротивления, приходит азарт и интерес - как же решить проблему максимально элегантно, понятно и эффективно?
Сейчас я считаю, что понимать базовые алгоритмы и структуры данных обязательно для любого программиста. Это как с музыкой: не важно, умеет ли музыкант читать ноты и писать аранжировки - он всё равно это делает, занимаясь музыкой. А если мы уже используем алгоритмы в работе, то почему бы не поучиться им хотя бы чуть-чуть?
Поэтому я задумал доклад про полезные алгоритмы для фронтендеров. Содержание будет примерно следующее:
— Алгоритмы обхода деревьев: BFS, DFS, рекурсивные и итеративные версии
— Подобные алгоритмы для древоподобных структур - вложенных массивов и словарей, сравнения, копирования и прочих операций с ними
— Сериализация и десериализация (парсинг): от CSV и JSON до HTML, JSX и Markdown, включая несериализуемые объекты и элементарный поиск циклов (в графе ссылок)
— Битовые операции и их приложение к компактным форматам (кстати, написал недавно библиотечку для упаковки boolean и integer значений в 32-битные числа) вроде Base64 и protobuf
Это то, что точно должно поместиться в получасовой обзорный доклад для конференции.
В дополнение хочу коснуться:
— Конечных автоматов для более элегантного парсинга и безглючной работы со сложными стейтами
— Элементарных алгоритмов поиска и сортировки
— Типовых алгоритмов на строках и массивах
Эти темы сложнее: не уверен, что смогу и успею раскрыть их в рамках доклада, и польза от них как будто бы ниже в приложении к day-to-day работе.
А вы что скажете? С какими алгоритмами приходилось сталкиваться во фронтенде и вебе?
Как я прошёл собеседования в стартап
Я скоро выхожу на новую работу в стартап. Там я буду отвечать за весь фронтенд сервиса, похожего по смыслу на гугл-аналитику - личный кабинет с дашбордами, графиками, служебными страницами.
Сегодня я расскажу, как проходили собеседования и что мне, вероятно, помогло их пройти.
Ребята нашли меня на LinkedIn и, в отличие от десятков других сообщений, которые я получаю, это привлекло тем, что написал мне лично CEO. К тому моменту я уже решил, что буду уходить из Фейсбука, и предложение от стартапа, а не очередного амазона пришлось как нельзя кстати.
В начале мы созвонились с помощником CEO и поговорили про мои планы и то, кто нужен компании и на какую роль. Так как это стартап, мой интерес к продуктовой разработке, предпринимательству и соответствующее отношение к работе, вероятно, подошли под их ожидания. Плюс мы просто мило побеседовали.
В подобном разговоре - по сути, скрининге на адекватность и соответствие ожиданий - важно изложить свою историю и поделиться планами так, чтобы это звучало непротиворечиво, а также быть дружелюбным и расспросить про компанию.
Так как я ничего про Hook не знал, я спросил про количество сотрудников, ближайшие планы, источники финансирования. В конце разговора меня спросили о зарплатных ожиданиях, на что я ответил уклончиво: мол, в Фейсбуке всё равно платят больше - и тогда мне озвучили их вилку. Также я ещё раз уточнил, готовы ли они спонсировать рабочую визу.
После разговора я поискал в сети всех сотрудников компании, включая CEO, посмотрел их выступления и убедился, что история сходится и этим людям, кажется, можно доверять.
Следующим был разговор с CEO. Он очень подробно расспросил меня про планы, включая переход из найма в предпринимательство (да, я вполне открыто об этом заявляю - в стартапе это нормально), а также рассказал о компании и её ценностях, идее продукта и как он к ней пришёл, а также почему она должна полететь. Я очень много спрашивал про продукт, ожидания ко мне и бизнесовые штуки, вроде ключевых моментов в ближайший год, инвесторов, рисков.
На этом этапе стало очевидно, что мы друг другу нравимся и, вероятно, подходим. В дополнение ко всему, Hook делает аналитику для SaaS-компаний - и это классное совпадение. Мне интересны бизнесы с подписочной моделью, а ещё я много работал с аналитикой в Яндексе и кое-что понимаю в ключевых SaaS-метриках и механизмах - привлечении и удержании пользователей, онбординге, экономике.
В конце концов, я рассказал CEO о своих сайд-проектах, как и зачем я их делал, какие проблемы они решают, а также тех самых продуктовых метриках. Думаю, его впечатлило моё упорство в работе над своими проектами, а также понимание продуктовой разработки/аналитики и полного стека веб-технологий, плюс совпадающий опыт.
Потом мне дали тестовое домашнее задание с рекомендацией сделать его за час. Детали задания я раскрывать не буду, но нужно было сделать простое одностраничное веб-приложение - я выбрал React и TypeScript, написал весь код примерно за полтора часа и ещё около получаса подробно расписывал в readme что и почему я сделал, какие были подводные камни, на какие детали я обратил внимание. К репозиторию я дал доступ CTO.
В конце концов, у меня было два собеседования с CTO. На них я рассказал про домашнее задание - оно было очевидно готовым, но всегда полезно рассказать про процесс и код. Также мы коснулись моих проектов, в частности Калькулятора стоимости жизни. Тут я рассказывал про технологии и показывал код - как питонячий для парсинга и подготовки данных, так и фронтенд лендинга и самого приложения.
На следующий день я получил письмо о том, что меня готовы взять на работу и несколько раз поговорил по телефону с CEO про то, как всё прошло, зарплату, опцион, визы. Он, как и я, был очень удивлён совпадению интересов и навыков, но видел риск - тут я удивился - в том, что я захочу делать всё на свете. Сошлись на том, что и фронтенда достаточно, особенно с перспективой растить команду.
Конечно, после Фейсбука и The Trade Desk, где было по 4-5 секций и куча алгоритмов, эти собеседования прошли легко и быстро.
Я скоро выхожу на новую работу в стартап. Там я буду отвечать за весь фронтенд сервиса, похожего по смыслу на гугл-аналитику - личный кабинет с дашбордами, графиками, служебными страницами.
Сегодня я расскажу, как проходили собеседования и что мне, вероятно, помогло их пройти.
Ребята нашли меня на LinkedIn и, в отличие от десятков других сообщений, которые я получаю, это привлекло тем, что написал мне лично CEO. К тому моменту я уже решил, что буду уходить из Фейсбука, и предложение от стартапа, а не очередного амазона пришлось как нельзя кстати.
В начале мы созвонились с помощником CEO и поговорили про мои планы и то, кто нужен компании и на какую роль. Так как это стартап, мой интерес к продуктовой разработке, предпринимательству и соответствующее отношение к работе, вероятно, подошли под их ожидания. Плюс мы просто мило побеседовали.
В подобном разговоре - по сути, скрининге на адекватность и соответствие ожиданий - важно изложить свою историю и поделиться планами так, чтобы это звучало непротиворечиво, а также быть дружелюбным и расспросить про компанию.
Так как я ничего про Hook не знал, я спросил про количество сотрудников, ближайшие планы, источники финансирования. В конце разговора меня спросили о зарплатных ожиданиях, на что я ответил уклончиво: мол, в Фейсбуке всё равно платят больше - и тогда мне озвучили их вилку. Также я ещё раз уточнил, готовы ли они спонсировать рабочую визу.
После разговора я поискал в сети всех сотрудников компании, включая CEO, посмотрел их выступления и убедился, что история сходится и этим людям, кажется, можно доверять.
Следующим был разговор с CEO. Он очень подробно расспросил меня про планы, включая переход из найма в предпринимательство (да, я вполне открыто об этом заявляю - в стартапе это нормально), а также рассказал о компании и её ценностях, идее продукта и как он к ней пришёл, а также почему она должна полететь. Я очень много спрашивал про продукт, ожидания ко мне и бизнесовые штуки, вроде ключевых моментов в ближайший год, инвесторов, рисков.
На этом этапе стало очевидно, что мы друг другу нравимся и, вероятно, подходим. В дополнение ко всему, Hook делает аналитику для SaaS-компаний - и это классное совпадение. Мне интересны бизнесы с подписочной моделью, а ещё я много работал с аналитикой в Яндексе и кое-что понимаю в ключевых SaaS-метриках и механизмах - привлечении и удержании пользователей, онбординге, экономике.
В конце концов, я рассказал CEO о своих сайд-проектах, как и зачем я их делал, какие проблемы они решают, а также тех самых продуктовых метриках. Думаю, его впечатлило моё упорство в работе над своими проектами, а также понимание продуктовой разработки/аналитики и полного стека веб-технологий, плюс совпадающий опыт.
Потом мне дали тестовое домашнее задание с рекомендацией сделать его за час. Детали задания я раскрывать не буду, но нужно было сделать простое одностраничное веб-приложение - я выбрал React и TypeScript, написал весь код примерно за полтора часа и ещё около получаса подробно расписывал в readme что и почему я сделал, какие были подводные камни, на какие детали я обратил внимание. К репозиторию я дал доступ CTO.
В конце концов, у меня было два собеседования с CTO. На них я рассказал про домашнее задание - оно было очевидно готовым, но всегда полезно рассказать про процесс и код. Также мы коснулись моих проектов, в частности Калькулятора стоимости жизни. Тут я рассказывал про технологии и показывал код - как питонячий для парсинга и подготовки данных, так и фронтенд лендинга и самого приложения.
На следующий день я получил письмо о том, что меня готовы взять на работу и несколько раз поговорил по телефону с CEO про то, как всё прошло, зарплату, опцион, визы. Он, как и я, был очень удивлён совпадению интересов и навыков, но видел риск - тут я удивился - в том, что я захочу делать всё на свете. Сошлись на том, что и фронтенда достаточно, особенно с перспективой растить команду.
Конечно, после Фейсбука и The Trade Desk, где было по 4-5 секций и куча алгоритмов, эти собеседования прошли легко и быстро.
Апдейт по сайд-проектам: сайт и публичность
Некоторые из вас знают, что у меня есть сайд-проекты разной степени важности и законченности. Сегодня публикую небольшой апдейт по двум: сайту и публичной деятельности - стратегически важным проектам, которые будут жить и развиваться ещё много лет.
Сайт и online presence
В прошлом году я купил домен gromov.com и начал работу над новым сайтом. Текущий меня не устраивает ни внешним видом, ни контентом и структурой, а ещё там нет мультиязычности и комментариев.
Новый сайт должен закрыть эти проблемы, а также стать ключевым элементом моего online presence: именно туда я буду выкладывать все лонгриды, заметки, а ещё собирать ссылки на свои выступления, интервью, статьи и проекты.
Я считаю, что именно свой сайт - это максимально независимая и управляемая площадка для вещания в сети, в отличие от всяких медиумов, блогов на хабре и даже канала в телеге.
Сначала я взялся за работу со стороны движка - фактически, кастомной CMS на джанге, но быстро столкнулся с проблемой. Программировать там особо нечего, а вот понять, что именно запрограммировать, сложнее. Всякий раз, когда я сталкивался с необходимостью принять решение про дизайн или информационную архитектуру, я в итоге закапывался в какие-то дебри и забивал.
Я даже написал ТЗ для дизайнера, но быстро понял, что лучше сделаю всё сам, потому что дизайн неотрывно связан со структурой сайта и позиционированием, а отдавать эти вопросы на откуп кому-то я не готов.
Статус: дизайн ключевых страниц и элементов готов, надо программировать и выкладывать статьи и остальные важные страницы. Планирую закончить и выложить первую версию нового сайта этим летом.
Выступления и статьи
Я считаю свою публичную деятельность сайд-проектом, потому что на неё уходит достаточно времени и усилий, а также всё это нужно планировать, приоритизировать и вписывать в расписание.
Целей на ближайший год, глобально, две: ещё подрастить свою известность и авторитет в русскоязычном сообществе и выйти из сумрака в англоязычном.
Для этого я планирую выступить на нескольких конференциях, написать ещё кучу заметок в блог и несколько лонгридов, а также вовлекаться во все возможные активности и движухи. Для русскоязычной аудитории основные обновления останутся в телеграме, а для англоязычной я попробую писать в твитер, хотя управляться с несколькими площадками непросто.
Я также заребрендил свой канал, чтобы он был более человечным и обещал не только экспертность по разным вопросам, а ещё и приключения, в которые мои читатели виртуально отправляются вместе со мной.
Ютуб и другие форматы вроде подкастов я тоже обдумываю, но выдавать качественный контент с хорошим продакшеном видео и аудио сложнее, поэтому не уверен, что всерьёз займусь ими в этом году.
Статус: отправляю заявки на разные конференции, на русском и английском, более активно пишу статьи, планирую лонгриды для разных площадок и продвижение канала другими способами.
А у вас какие планы на год?
Некоторые из вас знают, что у меня есть сайд-проекты разной степени важности и законченности. Сегодня публикую небольшой апдейт по двум: сайту и публичной деятельности - стратегически важным проектам, которые будут жить и развиваться ещё много лет.
Сайт и online presence
В прошлом году я купил домен gromov.com и начал работу над новым сайтом. Текущий меня не устраивает ни внешним видом, ни контентом и структурой, а ещё там нет мультиязычности и комментариев.
Новый сайт должен закрыть эти проблемы, а также стать ключевым элементом моего online presence: именно туда я буду выкладывать все лонгриды, заметки, а ещё собирать ссылки на свои выступления, интервью, статьи и проекты.
Я считаю, что именно свой сайт - это максимально независимая и управляемая площадка для вещания в сети, в отличие от всяких медиумов, блогов на хабре и даже канала в телеге.
Сначала я взялся за работу со стороны движка - фактически, кастомной CMS на джанге, но быстро столкнулся с проблемой. Программировать там особо нечего, а вот понять, что именно запрограммировать, сложнее. Всякий раз, когда я сталкивался с необходимостью принять решение про дизайн или информационную архитектуру, я в итоге закапывался в какие-то дебри и забивал.
Я даже написал ТЗ для дизайнера, но быстро понял, что лучше сделаю всё сам, потому что дизайн неотрывно связан со структурой сайта и позиционированием, а отдавать эти вопросы на откуп кому-то я не готов.
Статус: дизайн ключевых страниц и элементов готов, надо программировать и выкладывать статьи и остальные важные страницы. Планирую закончить и выложить первую версию нового сайта этим летом.
Выступления и статьи
Я считаю свою публичную деятельность сайд-проектом, потому что на неё уходит достаточно времени и усилий, а также всё это нужно планировать, приоритизировать и вписывать в расписание.
Целей на ближайший год, глобально, две: ещё подрастить свою известность и авторитет в русскоязычном сообществе и выйти из сумрака в англоязычном.
Для этого я планирую выступить на нескольких конференциях, написать ещё кучу заметок в блог и несколько лонгридов, а также вовлекаться во все возможные активности и движухи. Для русскоязычной аудитории основные обновления останутся в телеграме, а для англоязычной я попробую писать в твитер, хотя управляться с несколькими площадками непросто.
Я также заребрендил свой канал, чтобы он был более человечным и обещал не только экспертность по разным вопросам, а ещё и приключения, в которые мои читатели виртуально отправляются вместе со мной.
Ютуб и другие форматы вроде подкастов я тоже обдумываю, но выдавать качественный контент с хорошим продакшеном видео и аудио сложнее, поэтому не уверен, что всерьёз займусь ими в этом году.
Статус: отправляю заявки на разные конференции, на русском и английском, более активно пишу статьи, планирую лонгриды для разных площадок и продвижение канала другими способами.
А у вас какие планы на год?
В чём разница между техлидом, тимлидом и архитектором?
Подписчик спрашивает: "есть возможность рассказать со своей точки зрения чем техлид/тимлид отличается от архитектора в общих чертах?".
Давно хотел коснуться этой темы. Какой-то общепризнанной классификации подобных позиций нет - но есть классный TeamLead Roadmap, который можно взять за основу для планирования карьеры.
Расскажу, глядя со своей колокольни. Моё мнение основано на 5 годах опыта работы тимлидом (в Яндексе и Топтале), а также размышлениях о том, как эффективно организовывать работу технических команд.
При этом разные команды и компании обычно работают совершенно по-разному, нарезая список активностей как требуется и называя людей на схожих позициях по-разному.
Техлид - это, как правило, самый опытный разработчик в команде. Часто, и максимально естественно, техлидом становится один из тех, кто начинал проект и принимал решения по поводу технологий и архитектуры системы. Техлид может отвечать за следующее:
- Технические решения, их надёжность, стоимость эксплутации и развития
- Часть процессов в команде: ревью кода и архитектуры фич, оценку сложности и планирование разработки, тестирование и деплои
- Часть проектов и активностей: активное управление техдолгом, миграцию на новый стек
В компаниях, где я работал, не было выделенной должности техлида. Обычно это неофициальный тайтл для человека, к которому и так приходят с вопросами на технические темы и к чьему мнению прислушиваются.
Часто техлид работает в паре с проджект-менеджером, отвечающим за реализацию проекта и, иногда, людей.
Тимлид - это должность с большим количеством обязанностей. В дополнение к ответственности за технологии, тимлиды часто отвечают за:
- Найм, адаптацию, развитие и увольнение людей
- Постановку, планирование и достижение всех целей команды - технических и бизнесовых
- Настройку и поддержание всех процессов в команде
- Активную коммуникацию и распространение информации во все стороны, а также управление ожиданиями: стейкхолдеров, менеджеров, членов команды
И в Яндексе, и в Топтале есть должность тимлида. Обычно это первая ступенька управленческого трека в карьере.
Кому-то, как мне, позиция тимлида может прийтись по вкусу - скорее всего, придётся делать кучу всего и вовлекаться не только в написание и поддержку кода, но и в продуктовые решения, планирование, обсуждения и политику.
Другим не нравится, что к тимлиду часто слишком много ожиданий - и код пиши, и людей нанимай, и проекты доводи до конца. Зарплата при этом не всегда существенно выше, чем у разработчиков.
Архитектор - более редкая птица. Я всего несколько раз встречался с людьми в такой должности, и обычно в иерархии управления они находятся вне продуктовых команд (но не обязательно над тимлидами или менеджерами).
Архитектор может отвечать за общее направление развития технологий и технические процессы в компании, касающиеся всех команд. Например, выбор и развитие архитектуры всех систем, унификацию технологий и решений, используемых для одинаковых задач, безопасность, надёжность и эффективность инфраструктуры, мониторинг и прочее.
Между целями архитекторов (сделать правильно и единообразно) и тимлидов (выпускать проекты в срок и сохранить интерес ключевых людей к работе) могут быть противоречия. Вероятно, обеим сторонам нужно активно поддерживать и корректировать баланс между чистотой решений и скоростью релизов.
А как разработка устроена у вас в компании?
Подписчик спрашивает: "есть возможность рассказать со своей точки зрения чем техлид/тимлид отличается от архитектора в общих чертах?".
Давно хотел коснуться этой темы. Какой-то общепризнанной классификации подобных позиций нет - но есть классный TeamLead Roadmap, который можно взять за основу для планирования карьеры.
Расскажу, глядя со своей колокольни. Моё мнение основано на 5 годах опыта работы тимлидом (в Яндексе и Топтале), а также размышлениях о том, как эффективно организовывать работу технических команд.
При этом разные команды и компании обычно работают совершенно по-разному, нарезая список активностей как требуется и называя людей на схожих позициях по-разному.
Техлид - это, как правило, самый опытный разработчик в команде. Часто, и максимально естественно, техлидом становится один из тех, кто начинал проект и принимал решения по поводу технологий и архитектуры системы. Техлид может отвечать за следующее:
- Технические решения, их надёжность, стоимость эксплутации и развития
- Часть процессов в команде: ревью кода и архитектуры фич, оценку сложности и планирование разработки, тестирование и деплои
- Часть проектов и активностей: активное управление техдолгом, миграцию на новый стек
В компаниях, где я работал, не было выделенной должности техлида. Обычно это неофициальный тайтл для человека, к которому и так приходят с вопросами на технические темы и к чьему мнению прислушиваются.
Часто техлид работает в паре с проджект-менеджером, отвечающим за реализацию проекта и, иногда, людей.
Тимлид - это должность с большим количеством обязанностей. В дополнение к ответственности за технологии, тимлиды часто отвечают за:
- Найм, адаптацию, развитие и увольнение людей
- Постановку, планирование и достижение всех целей команды - технических и бизнесовых
- Настройку и поддержание всех процессов в команде
- Активную коммуникацию и распространение информации во все стороны, а также управление ожиданиями: стейкхолдеров, менеджеров, членов команды
И в Яндексе, и в Топтале есть должность тимлида. Обычно это первая ступенька управленческого трека в карьере.
Кому-то, как мне, позиция тимлида может прийтись по вкусу - скорее всего, придётся делать кучу всего и вовлекаться не только в написание и поддержку кода, но и в продуктовые решения, планирование, обсуждения и политику.
Другим не нравится, что к тимлиду часто слишком много ожиданий - и код пиши, и людей нанимай, и проекты доводи до конца. Зарплата при этом не всегда существенно выше, чем у разработчиков.
Архитектор - более редкая птица. Я всего несколько раз встречался с людьми в такой должности, и обычно в иерархии управления они находятся вне продуктовых команд (но не обязательно над тимлидами или менеджерами).
Архитектор может отвечать за общее направление развития технологий и технические процессы в компании, касающиеся всех команд. Например, выбор и развитие архитектуры всех систем, унификацию технологий и решений, используемых для одинаковых задач, безопасность, надёжность и эффективность инфраструктуры, мониторинг и прочее.
Между целями архитекторов (сделать правильно и единообразно) и тимлидов (выпускать проекты в срок и сохранить интерес ключевых людей к работе) могут быть противоречия. Вероятно, обеим сторонам нужно активно поддерживать и корректировать баланс между чистотой решений и скоростью релизов.
А как разработка устроена у вас в компании?
Зачем устраиваться в FAANG и/или переезжать за границу
Роман Пушкин поделился мыслями про FAANG, и я хочу немного дополнить его пост.
В FAANG хотят попасть по разным причинам. Для кого-то это работа мечты. Может казаться, что, получив ачивку Яндекса, Фейсбука или Гугла, жизнь обретёт какую-то завершённость. Это достаточно наивная идея, активно продвигаемая, по-видимому, самими корпорациями через те самые мощные HR-бренды, на поддержание которых они тратят огромные деньги.
Разработчику в корпорации действительно непросто вырасти (в деньгах и ответственности), особенно потому, что треки individual contributor, product manager и engineering manager намеренно разделены.
Но достаточно легко представить продвижение для управленца или владельца продукта, потому что команды и продукты растут. Работа разработчика, особенно хорошего, достаточно сложно масштабируется, а умение писать или объяснять код не так уж просто сконвертировать в управленческие навыки. Плюс не очевидно, есть ли у крупных компаний причины продвигать разработчиков в менеджеров, особенно с учётом дефицита на рынке труда.
Про деньги тоже верно. FAANG часто платит немного выше рынка на входе, но основной рост дохода приходится не на базовую зарплату, а на RSU и рефрешеры. Чтобы получать их, нужно очень быстро крутить педали (и получать хорошие оценки на ревью) - и делать это много лет.
При том, что шансы попасть в интересный продукт или поменять команду на более интересную не такие уж высокие. Значит, велика вероятность заниматься какой-то фигней годами, только чтобы вырасти в деньгах и незначительно приблизиться к желаемому образу жизни.
В достаточно типовой ситуации, когда опытный программист с семьей переезжает за границу по рабочей визе и устраивается в FAANG, денег может хватать только на жизнь - и так много лет, с неясными перспективами, особенно до получения гражданства или хотя бы ПМЖ.
Сам по себе переезд за границу за лучшей жизнью - тоже не гарантированно успешный и уж точно не максимально наполненный счастливыми переживаниями путь. Переезд даже в другой город может сильно ударить по самооценке и качеству жизни, не говоря уж о другой стране. Даже если ваша зарплата выше рынка, многое за рубежом существенно дороже (жильё, детские сады, кружки и няни, образование, услуги), а в отсутствие родственников и друзей повседневная жизнь может напоминать будни гастарбайтера.
В итоге, стоит ли вообще переезжать, в частности на работу в FAANG? Сейчас для меня это неочевидно.
Сам по себе переезд корпорации помогают сделать максимально гладким со своими богатыми (и то не везде) релокационными пакетами. Но вот рабочая жизнь в совершенно новой среде едва ли так уж увлекательна. Времени, желания и возможности познакомиться с новыми людьми и по-настоящему вкусить жизнь в новом месте может и не оставаться.
Например, моя текущая жизнь в Англии достаточно тусклая в сравнении с 6 месяцами в США, когда я был студентом языковой школы и просто жил в своё удовольствие, изучая английский и путешествуя по Штатам.
Альтернативой может быть удалёнка. Как я писал в одной из статей, "удалёнка — это отличный вариант для тех, кто не хочет ввязываться в сложности переезда ради работы, а удалёнка в зарубежной компании особенно хороша из-за высокой зарплаты".
Зарабатывать можно на хорошую жизнь, крупные покупки и путешествия, оставаясь в привычной и понятной среде и не теряя связи с близкими людьми. И всегда иметь в запасе возможность переехать, если вам в какой-то момент этого захочется.
А вы как считаете, переезд за границу и работа в корпорации стоят всех сложностей?
Роман Пушкин поделился мыслями про FAANG, и я хочу немного дополнить его пост.
В FAANG хотят попасть по разным причинам. Для кого-то это работа мечты. Может казаться, что, получив ачивку Яндекса, Фейсбука или Гугла, жизнь обретёт какую-то завершённость. Это достаточно наивная идея, активно продвигаемая, по-видимому, самими корпорациями через те самые мощные HR-бренды, на поддержание которых они тратят огромные деньги.
Разработчику в корпорации действительно непросто вырасти (в деньгах и ответственности), особенно потому, что треки individual contributor, product manager и engineering manager намеренно разделены.
Но достаточно легко представить продвижение для управленца или владельца продукта, потому что команды и продукты растут. Работа разработчика, особенно хорошего, достаточно сложно масштабируется, а умение писать или объяснять код не так уж просто сконвертировать в управленческие навыки. Плюс не очевидно, есть ли у крупных компаний причины продвигать разработчиков в менеджеров, особенно с учётом дефицита на рынке труда.
Про деньги тоже верно. FAANG часто платит немного выше рынка на входе, но основной рост дохода приходится не на базовую зарплату, а на RSU и рефрешеры. Чтобы получать их, нужно очень быстро крутить педали (и получать хорошие оценки на ревью) - и делать это много лет.
При том, что шансы попасть в интересный продукт или поменять команду на более интересную не такие уж высокие. Значит, велика вероятность заниматься какой-то фигней годами, только чтобы вырасти в деньгах и незначительно приблизиться к желаемому образу жизни.
В достаточно типовой ситуации, когда опытный программист с семьей переезжает за границу по рабочей визе и устраивается в FAANG, денег может хватать только на жизнь - и так много лет, с неясными перспективами, особенно до получения гражданства или хотя бы ПМЖ.
Сам по себе переезд за границу за лучшей жизнью - тоже не гарантированно успешный и уж точно не максимально наполненный счастливыми переживаниями путь. Переезд даже в другой город может сильно ударить по самооценке и качеству жизни, не говоря уж о другой стране. Даже если ваша зарплата выше рынка, многое за рубежом существенно дороже (жильё, детские сады, кружки и няни, образование, услуги), а в отсутствие родственников и друзей повседневная жизнь может напоминать будни гастарбайтера.
В итоге, стоит ли вообще переезжать, в частности на работу в FAANG? Сейчас для меня это неочевидно.
Сам по себе переезд корпорации помогают сделать максимально гладким со своими богатыми (и то не везде) релокационными пакетами. Но вот рабочая жизнь в совершенно новой среде едва ли так уж увлекательна. Времени, желания и возможности познакомиться с новыми людьми и по-настоящему вкусить жизнь в новом месте может и не оставаться.
Например, моя текущая жизнь в Англии достаточно тусклая в сравнении с 6 месяцами в США, когда я был студентом языковой школы и просто жил в своё удовольствие, изучая английский и путешествуя по Штатам.
Альтернативой может быть удалёнка. Как я писал в одной из статей, "удалёнка — это отличный вариант для тех, кто не хочет ввязываться в сложности переезда ради работы, а удалёнка в зарубежной компании особенно хороша из-за высокой зарплаты".
Зарабатывать можно на хорошую жизнь, крупные покупки и путешествия, оставаясь в привычной и понятной среде и не теряя связи с близкими людьми. И всегда иметь в запасе возможность переехать, если вам в какой-то момент этого захочется.
А вы как считаете, переезд за границу и работа в корпорации стоят всех сложностей?
Апдейт по сайд-проектам: стартапы в зародыше
Прошлый апдейт про сайд-проекты был про новый сайт и публичную деятельность. Сегодня публикую апдейт по проектам, которые потенциально могли бы превратиться в бизнесы: калькулятору стоимости жизни и словарику Quiken.
Калькулятор стоимости жизни
Когда-то давно мне пришла в голову идея сделать калькулятор стоимости жизни в разных странах и городах. Данные в сети, собранные из разных источников, есть, а вот вменяемого интерфейса для сравнения стоимости своего образа жизни в разных локациях - пока нет.
За пару недель я собрал первый прототип продукта, потом пару месяцев доделывал лендинг и дорабатывал сам калькулятор, и сейчас они практически готовы. Осталось сделать мобильную версию и поправить всякие мелочи, а также починить конвертацию валют - открытое и бесплатное API, которое я нашёл, стало за это время недоступным без ключа.
По ссылкам из моего канала в калькулятор пришло около 400 человек, из которых порядка 250 активно пользовались им - я прикрутил метрики, которые трекаются гугл аналитикой, чтобы следить за вовлечённостью пользователей. Среднее время вовлечённой сессии - около полутора минут.
Но есть критически важная проблема: не понятно, как улучшить retention пользователей, потому что по своей природе такой калькулятор - это штука, которой воспользуешься от силы пару раз, планируя переезд. А переезжают люди нечасто.
Статус: планирую запуск через несколько месяцев, может быть осенью. Буду привлекать пользователей со всего мира через контент-маркетинг и всякие "партизанские" низкобюджетные техники, вроде партнёрств с существующими игроками на рынке.
Критические предположения, которые нужно проверить:
- для продукта есть рынок, и можно найти подходящую модель монетизации
- удастся запартнёриться с важными и заметными игроками на рынке, чтобы привлекать трафик без активных усилий
- калькулятор в принципе обеспечивает достаточную точность, чтобы быть полезным (частично провалидировано первыми пользователями)
Словарик с произношением Quiken
Quiken я начал делать по вечерам, когда Лондон закрылся на карантин. Мне казалось, что можно сделать полезную штуку для изучающих английский - но, в большей степени, хотелось доказать себе, что я могу что-то сделать от начала и до конца (после корпоративных ужасов последнего десятилетия).
Сейчас на проект я практически забил: мне недостаёт интереса к проблеме, чтобы заниматься им продолжительное время. Плюс не понятны перспективы: я достаточно подозрительно отношусь к B2C рынку изучения английского - тут и пообещать результат сложно, и денег с каждого пользователя много не взять, и конкуренция громадная. Не уверен, что хочу во всё это ввязываться.
Само браузерное расширение, хотя и полностью работоспособно уже больше года, было распубликовано гуглом за отсутствие страницы privacy policy - и я так и не сделал её. И не уверен, что сделаю, хотя дел там на полчаса.
Бэкенд сервиса вертится на 5-долларовом дроплете в Digital Ocean и смотрит в отдельный MySQL за $15. Итого: -$20 каждый месяц. Надо перенести БД в постгрес, который я использую для своего сайта - нагрузка и объём данных там мизерные, и можно сэкономить пятнашку в месяц на кофе.
Статус: нужно мигрировать базу данных и оставить проект в "музее", но делать всё это лень. А просто прибить жалко.
Мне также постоянно приходят в голову идеи разных проектов, которые я всегда записываю. Часть из них хочется поисследовать, но пока не знаю, как сложится работа в стартапе - и сколько свободного времени у меня будет оставаться.
Прошлый апдейт про сайд-проекты был про новый сайт и публичную деятельность. Сегодня публикую апдейт по проектам, которые потенциально могли бы превратиться в бизнесы: калькулятору стоимости жизни и словарику Quiken.
Калькулятор стоимости жизни
Когда-то давно мне пришла в голову идея сделать калькулятор стоимости жизни в разных странах и городах. Данные в сети, собранные из разных источников, есть, а вот вменяемого интерфейса для сравнения стоимости своего образа жизни в разных локациях - пока нет.
За пару недель я собрал первый прототип продукта, потом пару месяцев доделывал лендинг и дорабатывал сам калькулятор, и сейчас они практически готовы. Осталось сделать мобильную версию и поправить всякие мелочи, а также починить конвертацию валют - открытое и бесплатное API, которое я нашёл, стало за это время недоступным без ключа.
По ссылкам из моего канала в калькулятор пришло около 400 человек, из которых порядка 250 активно пользовались им - я прикрутил метрики, которые трекаются гугл аналитикой, чтобы следить за вовлечённостью пользователей. Среднее время вовлечённой сессии - около полутора минут.
Но есть критически важная проблема: не понятно, как улучшить retention пользователей, потому что по своей природе такой калькулятор - это штука, которой воспользуешься от силы пару раз, планируя переезд. А переезжают люди нечасто.
Статус: планирую запуск через несколько месяцев, может быть осенью. Буду привлекать пользователей со всего мира через контент-маркетинг и всякие "партизанские" низкобюджетные техники, вроде партнёрств с существующими игроками на рынке.
Критические предположения, которые нужно проверить:
- для продукта есть рынок, и можно найти подходящую модель монетизации
- удастся запартнёриться с важными и заметными игроками на рынке, чтобы привлекать трафик без активных усилий
- калькулятор в принципе обеспечивает достаточную точность, чтобы быть полезным (частично провалидировано первыми пользователями)
Словарик с произношением Quiken
Quiken я начал делать по вечерам, когда Лондон закрылся на карантин. Мне казалось, что можно сделать полезную штуку для изучающих английский - но, в большей степени, хотелось доказать себе, что я могу что-то сделать от начала и до конца (после корпоративных ужасов последнего десятилетия).
Сейчас на проект я практически забил: мне недостаёт интереса к проблеме, чтобы заниматься им продолжительное время. Плюс не понятны перспективы: я достаточно подозрительно отношусь к B2C рынку изучения английского - тут и пообещать результат сложно, и денег с каждого пользователя много не взять, и конкуренция громадная. Не уверен, что хочу во всё это ввязываться.
Само браузерное расширение, хотя и полностью работоспособно уже больше года, было распубликовано гуглом за отсутствие страницы privacy policy - и я так и не сделал её. И не уверен, что сделаю, хотя дел там на полчаса.
Бэкенд сервиса вертится на 5-долларовом дроплете в Digital Ocean и смотрит в отдельный MySQL за $15. Итого: -$20 каждый месяц. Надо перенести БД в постгрес, который я использую для своего сайта - нагрузка и объём данных там мизерные, и можно сэкономить пятнашку в месяц на кофе.
Статус: нужно мигрировать базу данных и оставить проект в "музее", но делать всё это лень. А просто прибить жалко.
Мне также постоянно приходят в голову идеи разных проектов, которые я всегда записываю. Часть из них хочется поисследовать, но пока не знаю, как сложится работа в стартапе - и сколько свободного времени у меня будет оставаться.
Интересные посты с декабря по конец мая
Привет всем новым подписчикам! Для вашего удобства публикую дайджест интересных постов с декабря по конец мая. Прошлый дайджест с начала ведения канала по конец 2020-го можно найти здесь.
1. Важнее всего люди
2. Фейсбук сломался - и это ожидаемо
3. Конспект стрима "Попасть в FAANG недостаточно"
4. Кому на удалёнке жить тяжело
5. Занудные вопросы
6. Прототип Калькулятора стоимости жизни в табличке
7. Про первый веб-прототип Калькулятора, сделанный за неделю
8. Чем круты крутые программисты
9. Год в Фейсбуке 👻
10. Год в Фейсбуке - продолжение
11. Калькулятор стоимости жизни - вести с полей
12. Четыре модальности написания кода - часть первая
13. Четыре модальности написания кода - часть вторая
14. Субботние ссылки
15. Любопытные модули из Калькулятора стоимости жизни
16. 20 лет продакт-менеджмента за 25 минут - конспект
17. Принятие решений в жизни и на работе
18. Зачем сидеть в найме
19. Ребрендинг канала: G R O M O V → Приключения Громова
20. Откуда брать информацию про предпринимательство
21. Как быть лучше подавляющего большинства разработчиков
22. Длинный гайд про блоггинг (есть ещё версия получше на Хабре)
23. Тысяча преданных фанатов
24. Вот и меня настигла прокрастинация
25. Поможет ли профессиональный блог найти работу?
26. Из Фейсбука в стартап
27. Какими должны быть условия работы программистов и почему?
28. Про RSU и опционы
29. Зачем компания давать тестовые задания, а нам — тратить время на них?
30. Как я авиабилеты заказывал
31. Баланс между порядком и хаосом ☯
32. Полезные для фронтендеров алгоритмы
33. Как я прошёл собеседования в стартап
34. Апдейт по сайд-проектам: сайт и публичность
35. В чём разница между техлидом, тимлидом и архитектором?
36. Зачем устраиваться в FAANG и/или переезжать за границу
37. Апдейт по сайд-проектам: стартапы в зародыше
Поделитесь постом с друзьями, если какие-то мысли кажутся вам интересными.
Привет всем новым подписчикам! Для вашего удобства публикую дайджест интересных постов с декабря по конец мая. Прошлый дайджест с начала ведения канала по конец 2020-го можно найти здесь.
1. Важнее всего люди
2. Фейсбук сломался - и это ожидаемо
3. Конспект стрима "Попасть в FAANG недостаточно"
4. Кому на удалёнке жить тяжело
5. Занудные вопросы
6. Прототип Калькулятора стоимости жизни в табличке
7. Про первый веб-прототип Калькулятора, сделанный за неделю
8. Чем круты крутые программисты
9. Год в Фейсбуке 👻
10. Год в Фейсбуке - продолжение
11. Калькулятор стоимости жизни - вести с полей
12. Четыре модальности написания кода - часть первая
13. Четыре модальности написания кода - часть вторая
14. Субботние ссылки
15. Любопытные модули из Калькулятора стоимости жизни
16. 20 лет продакт-менеджмента за 25 минут - конспект
17. Принятие решений в жизни и на работе
18. Зачем сидеть в найме
19. Ребрендинг канала: G R O M O V → Приключения Громова
20. Откуда брать информацию про предпринимательство
21. Как быть лучше подавляющего большинства разработчиков
22. Длинный гайд про блоггинг (есть ещё версия получше на Хабре)
23. Тысяча преданных фанатов
24. Вот и меня настигла прокрастинация
25. Поможет ли профессиональный блог найти работу?
26. Из Фейсбука в стартап
27. Какими должны быть условия работы программистов и почему?
28. Про RSU и опционы
29. Зачем компания давать тестовые задания, а нам — тратить время на них?
30. Как я авиабилеты заказывал
31. Баланс между порядком и хаосом ☯
32. Полезные для фронтендеров алгоритмы
33. Как я прошёл собеседования в стартап
34. Апдейт по сайд-проектам: сайт и публичность
35. В чём разница между техлидом, тимлидом и архитектором?
36. Зачем устраиваться в FAANG и/или переезжать за границу
37. Апдейт по сайд-проектам: стартапы в зародыше
Поделитесь постом с друзьями, если какие-то мысли кажутся вам интересными.
Самая большая проблема служб поддержки
Ничего не понимаю в организации работы поддержки (но в какой-то момент придётся разобраться), но всё же поделюсь своими размышленями и наблюдениями за работой поддержки - как изнутри, из Фейсбука или Яндекса, так и снаружи, как клиента разных компаний и пользователя разных продуктов.
Обычно служба поддержки сталкивается с десятками и сотнями достаточно дурацких вопросов: как установить-обновить-удалить, где в мессенджере сообщения, а в банковском приложении баланс. Наверное, в большинстве недорогих b2c продуктов такие вопросы правильно решать с помощью ботов и прочих FAQ, что множество компаний и делает. Но кто-то всё равно должен следить за их актуальностью, поэтому нужна служба поддержки.
Клиентам также нужна помощь с уже сделанными покупками и действиями в приложении: как поменять количество товара в оплаченном заказе без создания нового, можно ли сделать refund на другую карту, какие условия обслуживания на конкретном тарифе - и множество важных, но далеко запрятанных или неавтоматизируемых штук. Это тоже к службе поддержки, и, как правило, справляются они неплохо. Хотя часто и не быстро тоже.
Но сложнее всего наладить работу с багами и кривыми фичами, которые путают пользователей, заставляют их делать ошибки (как у меня с номером паспорта - хотя проблема была техническая на стороне агрегатора), нервничать и добиваться решений.
Сотрудники поддержки обычно совершенно не понимают, что происходит в коде. Немного чаще они знают про важные обновления приложения, но точно не следят за всеми релизами и, в отличие от разработчиков, не могут отследить связь между новыми жалобами и вчерашним релизом.
При этом сами разработчики (не везде, но много где) часто не заинтересованы в исправлении багов. Даже не потому, что они такие ленивые жопы, а потому что часто приоритеты команды другие. В Фейсбуке это impact, а от исправления багов, особенно редких и сложновоспроизводимых, импакта ноль. Зато пользователям - гемор и игнор.
Казалось бы, такая большая и богатая компания: неужели нельзя найти людей и время починить очевидные косяки. Ну, может и большая, так и продуктов у неё тоже много. Наша команда, например, состоявшая из нескольких человек до недавних пор, поддерживает внутренний чат - достаточно сложное и сырое приложение, которым пользуются десятки тысяч людей. Каждый рабочий день, в течение десятков часов, во всех часовых поясах.
У нас багов в бэклоге столько, что их и десять землекопов будут разгребать месяц. А за это время новых насыплется.
Но это в разработке такое творится, а поддержка что в это время делает? В лучшем случае, успокаивает клиентов и отвечает, что мы уже чиним и скоро всё образуется - а в худшем, осознанно или нет, сваливает проблему на самих пользователей и напрягает их рекомендациями попробовать снова или отписками в духе "сам дурак".
И наверняка у сотрудников служб поддержки есть агрессивные KPI на время реакции и разрешения проблемы, на количество открытых жалоб и так далее. То есть они зажаты тисками: с одной стороны, надо помочь как можно скорее, а с другой - помочь-то часто и невозможно.
Что с этим делать? Не знаю. Но в маленькой компании (например, в своей будущей компании) я бы дал разработчикам общаться с клиентами и решать их проблемы. Конечно, не все возможные проблемы, а только откровенно технические, где наверняка замешаны проблемы с кодом.
А вы бы как решили проблемы служб поддержки?
Ничего не понимаю в организации работы поддержки (но в какой-то момент придётся разобраться), но всё же поделюсь своими размышленями и наблюдениями за работой поддержки - как изнутри, из Фейсбука или Яндекса, так и снаружи, как клиента разных компаний и пользователя разных продуктов.
Обычно служба поддержки сталкивается с десятками и сотнями достаточно дурацких вопросов: как установить-обновить-удалить, где в мессенджере сообщения, а в банковском приложении баланс. Наверное, в большинстве недорогих b2c продуктов такие вопросы правильно решать с помощью ботов и прочих FAQ, что множество компаний и делает. Но кто-то всё равно должен следить за их актуальностью, поэтому нужна служба поддержки.
Клиентам также нужна помощь с уже сделанными покупками и действиями в приложении: как поменять количество товара в оплаченном заказе без создания нового, можно ли сделать refund на другую карту, какие условия обслуживания на конкретном тарифе - и множество важных, но далеко запрятанных или неавтоматизируемых штук. Это тоже к службе поддержки, и, как правило, справляются они неплохо. Хотя часто и не быстро тоже.
Но сложнее всего наладить работу с багами и кривыми фичами, которые путают пользователей, заставляют их делать ошибки (как у меня с номером паспорта - хотя проблема была техническая на стороне агрегатора), нервничать и добиваться решений.
Сотрудники поддержки обычно совершенно не понимают, что происходит в коде. Немного чаще они знают про важные обновления приложения, но точно не следят за всеми релизами и, в отличие от разработчиков, не могут отследить связь между новыми жалобами и вчерашним релизом.
При этом сами разработчики (не везде, но много где) часто не заинтересованы в исправлении багов. Даже не потому, что они такие ленивые жопы, а потому что часто приоритеты команды другие. В Фейсбуке это impact, а от исправления багов, особенно редких и сложновоспроизводимых, импакта ноль. Зато пользователям - гемор и игнор.
Казалось бы, такая большая и богатая компания: неужели нельзя найти людей и время починить очевидные косяки. Ну, может и большая, так и продуктов у неё тоже много. Наша команда, например, состоявшая из нескольких человек до недавних пор, поддерживает внутренний чат - достаточно сложное и сырое приложение, которым пользуются десятки тысяч людей. Каждый рабочий день, в течение десятков часов, во всех часовых поясах.
У нас багов в бэклоге столько, что их и десять землекопов будут разгребать месяц. А за это время новых насыплется.
Но это в разработке такое творится, а поддержка что в это время делает? В лучшем случае, успокаивает клиентов и отвечает, что мы уже чиним и скоро всё образуется - а в худшем, осознанно или нет, сваливает проблему на самих пользователей и напрягает их рекомендациями попробовать снова или отписками в духе "сам дурак".
И наверняка у сотрудников служб поддержки есть агрессивные KPI на время реакции и разрешения проблемы, на количество открытых жалоб и так далее. То есть они зажаты тисками: с одной стороны, надо помочь как можно скорее, а с другой - помочь-то часто и невозможно.
Что с этим делать? Не знаю. Но в маленькой компании (например, в своей будущей компании) я бы дал разработчикам общаться с клиентами и решать их проблемы. Конечно, не все возможные проблемы, а только откровенно технические, где наверняка замешаны проблемы с кодом.
А вы бы как решили проблемы служб поддержки?