Да. Стоит. Распахнутых настежь дверей нигде нет.
И ещё хочу добавить вещь, которую я услышал в лекции одного психолога: корректировать цель, к которой держишь путь, это нормально. Мы не всегда понимаем, чего именно мы хотим (точнее говоря: почти никогда). Поэтому изменять цель исходя из уже пройденного пути абсолютно здоровая практика.
Под профессионализмом я имел в виду навыки написания систем, которые а) способны работать в боевых условиях, б) созданы с учетом добавлений/изменений. Да, каждый может подразумевать под этим словом разные вещи, тем более бизнес.
Как раз дело в том, что бизнес возлагает принятие решений исключительно на менеджмент. Разработчики в принятии решений не участвуют вовсе. Вплоть до технических, про которые я и упоминал. Канал «разработчик» <-> «бизнес» не налажен, объяснить ему про потерю денег не получится (не говоря о том, что бизнес не считает, что разработчик в этом разбирается). Возможность потерять клиента в мифическом будущем не интересует бизнес, потому что через год это через год. А если мы сейчас скажем клиенту, что нам надо, к примеру, не месяц, а два, зато будет качественно, то клиент уйдёт к тому, кто готов сделать за месяц. И мы потеряем клиента прямо сейчас. Что там говорить, если менеджера зачастую не интересует, что будет на следующей неделе, главное выбить показатели текущей.
В итоге менеджмент принимает решения для того, чтобы выдать показатели здесь и сейчас. Мнением технического специалиста не интересуется никто. Следовательно, у технического специалиста нет ответственности. Нет ответственности — его деятельность не имеет значения. В итоге пишешь не предназначенный для прода код по техническим решениям человека без технического бэкграунда.
Да, по поводу ухода из такой компании я абсолютно согласен (да и вообще по поводу любого ухода). Я даже не хочу сказать, что такая бизнес-модель плохая, так делать нельзя и фу-фу-фу. Если бизнес зарабатывает деньги таким образом и процветает, то флаг им в руки. Опять же, возможно это мой личный негативный опыт. Но я не вижу причин, по которым в аутсорс-компании бизнес бы заботился о том: как код написан, насколько там современная версия, сколько мы времени сэкономим в будущем, если сейчас потратим больше времени на изучение чего-то нового и т.д. Чтобы бизнес задавал вопросы разработчику по его экспертизе. Главное это получить деньги с заказчика здесь и сейчас. С этим справляются менеджмент, а разработчики с желанием высказать своё мнение о том, что неплохо было бы написать то, что будет работать и через год; или желанием потратить больше времени сейчас, чтобы сэкономить через пару месяцев, идут лесом. И я вижу предпосылки к тому, что об этом как раз будут заботиться в продуктовых компаниях. И у разработчика будет больше ответственности. И больше смысла ходить в офис.
После работы в аутсорсе, заработал субъективное отторжение к нему на всю жизнь (даже был близок к тому, чтобы получить отторжение ко всему программированию). После долгого размышления пришёл к выводу: самое ужасное для меня в аутсорсе это то, что моя работа не имеет значения.
Поясню: в аутсорс-компании центром прибыли являются менеджеры (PM, аккаунты, по продажам и т.д.), именно они приносят компании деньги. А технические специалисты являются центром издержек. Да, без них никак нельзя, ведь надо кого-то продавать заказчикам. Но, в целом, они находятся на вторых ролях. В итоге все решения принимаются менеджерами среднего и младшего звена. Зачастую даже технические, зачастую вопреки опытным разработчикам в статусе лидов.
Несколько примеров из моей практики:
— Тесты. TDD не было никогда. Как бы разработчики не настаивали. В половине проектов удавалось продавить интеграционные тесты, но при первом же цейтноте менеджеры их отменяли. Пишешь код, который нельзя показать заказчику — валяешь дурака.
— Работа с системой контроля версий. Почему мы не можем показать фичу заказчику, когда её код уже написан? Что значит не можете смержить, потому что ждёте какой-то там кодревью? На лицо явный саботаж. Делайте merge немедленно!
— Самый показательный случай: менеджер попросил срочно поменять реализацию, поскольку в последний день спринта выяснилось, что у заказчика другое видение. Я предложил по быстрому заговнокодить (да, знаю, сам виноват), но с условием, что нужно будет выделить время, чтобы сделать нормально в следующем спринте. Конечно, в следующем спринте мне отказали с аргументом: «На тестовом всё и так работает, а что будет на проде нам совершенно неважно, потому что они будут выливать на прод уже после того, как мы закончим с ними сотрудничество.»
На всё это можно возразить: чувак, а какая тебе разница? Ты работаешь, получаешь за это деньги. Расслабься и получай удовольствие. Но даже если для кого-то это и недостаточно неприятный опыт, то есть пару следствий из такого положения дел.
Во-первых, профессионализм ничего не значит. Более того, он вреден. Лучше писать быстро, а не долго. В итоге имеем, что профессионал, с желанием написать действительно работающий и способный к расширению (для добавления новых фич) код, будет критиковаться. А быстро шлепающий говнокодер нахваливаться. Естественно, расти как профессионал в таких условиях как минимум трудно.
Во-вторых, место профессионализма займёт другое качество. В моём случае это была лояльность. Хорошим был сотрудник, который готов работать на выходных и всем доволен. А тот, который на ретроспективах говорит о проблемах был плохим. Потому что «мы команда, а в команде важно мыслить позитивно.»
P. S. Конечно это мой сугубо личный опыт. Возможно, что есть аутсорс компании, в которых этого нет. Возможно, в продуктовых это тоже присутствует. Но, как мне кажется, продуктовые компании больше смотрят на качество сервиса, которые они предоставляют. Потому что от этого напрямую зависит их прибыль. А, следовательно, приходит понимание ценности экспертизы технических работников.
Отличная статья, очень показательная. Нет, я понимаю, что я посредственный специалист и вашей компании я совсем не нужен. Но вывод на будущее, что в вашу компанию устраиваться не стоит, я сделал. Судя по комментариям такой вывод сделал не только я. Великолепная антиреклама.
На российском рынке труда нехватка специалистов высочайшего профиля (которую нехотя признает даже бизнес, хотя ему удобнее трубить о другом). Казалось бы, в такой ситуации с кандидатом (и тем более с работником) отношения должны быть максимально просты, честны и открыты: работник делает задачи в соответствии со своей зоной ответственности и получает за это деньги. Так давайте просто обсудим условия нашего сотрудничества. Но нет. Приходится удивлять потенциального работодателя, показывать свою энергию и доказывать, что ты способен эмоционально пропустить проект через себя. Trouble hiring senior engineers? It's probably you
Интересно, а могут ли внешние факторы быть причиной смены типажа?
К примеру, работал человек в аутсорсе, клепал скучные задачи линейно. А потом перешёл в компанию, развивающую свой продукт, и стал rock star.
Надеюсь, что следующее высказывание будет в аналогичной статье будущего:
«Невозможно будет построить корабль, который двигался бы быстрее скорости света» — учёные XX-XXI веков.
И ещё хочу добавить вещь, которую я услышал в лекции одного психолога: корректировать цель, к которой держишь путь, это нормально. Мы не всегда понимаем, чего именно мы хотим (точнее говоря: почти никогда). Поэтому изменять цель исходя из уже пройденного пути абсолютно здоровая практика.
Как раз дело в том, что бизнес возлагает принятие решений исключительно на менеджмент. Разработчики в принятии решений не участвуют вовсе. Вплоть до технических, про которые я и упоминал. Канал «разработчик» <-> «бизнес» не налажен, объяснить ему про потерю денег не получится (не говоря о том, что бизнес не считает, что разработчик в этом разбирается). Возможность потерять клиента в мифическом будущем не интересует бизнес, потому что через год это через год. А если мы сейчас скажем клиенту, что нам надо, к примеру, не месяц, а два, зато будет качественно, то клиент уйдёт к тому, кто готов сделать за месяц. И мы потеряем клиента прямо сейчас. Что там говорить, если менеджера зачастую не интересует, что будет на следующей неделе, главное выбить показатели текущей.
В итоге менеджмент принимает решения для того, чтобы выдать показатели здесь и сейчас. Мнением технического специалиста не интересуется никто. Следовательно, у технического специалиста нет ответственности. Нет ответственности — его деятельность не имеет значения. В итоге пишешь не предназначенный для прода код по техническим решениям человека без технического бэкграунда.
Да, по поводу ухода из такой компании я абсолютно согласен (да и вообще по поводу любого ухода). Я даже не хочу сказать, что такая бизнес-модель плохая, так делать нельзя и фу-фу-фу. Если бизнес зарабатывает деньги таким образом и процветает, то флаг им в руки. Опять же, возможно это мой личный негативный опыт. Но я не вижу причин, по которым в аутсорс-компании бизнес бы заботился о том: как код написан, насколько там современная версия, сколько мы времени сэкономим в будущем, если сейчас потратим больше времени на изучение чего-то нового и т.д. Чтобы бизнес задавал вопросы разработчику по его экспертизе. Главное это получить деньги с заказчика здесь и сейчас. С этим справляются менеджмент, а разработчики с желанием высказать своё мнение о том, что неплохо было бы написать то, что будет работать и через год; или желанием потратить больше времени сейчас, чтобы сэкономить через пару месяцев, идут лесом. И я вижу предпосылки к тому, что об этом как раз будут заботиться в продуктовых компаниях. И у разработчика будет больше ответственности. И больше смысла ходить в офис.
Поясню: в аутсорс-компании центром прибыли являются менеджеры (PM, аккаунты, по продажам и т.д.), именно они приносят компании деньги. А технические специалисты являются центром издержек. Да, без них никак нельзя, ведь надо кого-то продавать заказчикам. Но, в целом, они находятся на вторых ролях. В итоге все решения принимаются менеджерами среднего и младшего звена. Зачастую даже технические, зачастую вопреки опытным разработчикам в статусе лидов.
Несколько примеров из моей практики:
— Тесты. TDD не было никогда. Как бы разработчики не настаивали. В половине проектов удавалось продавить интеграционные тесты, но при первом же цейтноте менеджеры их отменяли. Пишешь код, который нельзя показать заказчику — валяешь дурака.
— Работа с системой контроля версий. Почему мы не можем показать фичу заказчику, когда её код уже написан? Что значит не можете смержить, потому что ждёте какой-то там кодревью? На лицо явный саботаж. Делайте merge немедленно!
— Самый показательный случай: менеджер попросил срочно поменять реализацию, поскольку в последний день спринта выяснилось, что у заказчика другое видение. Я предложил по быстрому заговнокодить (да, знаю, сам виноват), но с условием, что нужно будет выделить время, чтобы сделать нормально в следующем спринте. Конечно, в следующем спринте мне отказали с аргументом: «На тестовом всё и так работает, а что будет на проде нам совершенно неважно, потому что они будут выливать на прод уже после того, как мы закончим с ними сотрудничество.»
На всё это можно возразить: чувак, а какая тебе разница? Ты работаешь, получаешь за это деньги. Расслабься и получай удовольствие. Но даже если для кого-то это и недостаточно неприятный опыт, то есть пару следствий из такого положения дел.
Во-первых, профессионализм ничего не значит. Более того, он вреден. Лучше писать быстро, а не долго. В итоге имеем, что профессионал, с желанием написать действительно работающий и способный к расширению (для добавления новых фич) код, будет критиковаться. А быстро шлепающий говнокодер нахваливаться. Естественно, расти как профессионал в таких условиях как минимум трудно.
Во-вторых, место профессионализма займёт другое качество. В моём случае это была лояльность. Хорошим был сотрудник, который готов работать на выходных и всем доволен. А тот, который на ретроспективах говорит о проблемах был плохим. Потому что «мы команда, а в команде важно мыслить позитивно.»
P. S. Конечно это мой сугубо личный опыт. Возможно, что есть аутсорс компании, в которых этого нет. Возможно, в продуктовых это тоже присутствует. Но, как мне кажется, продуктовые компании больше смотрят на качество сервиса, которые они предоставляют. Потому что от этого напрямую зависит их прибыль. А, следовательно, приходит понимание ценности экспертизы технических работников.
На российском рынке труда нехватка специалистов высочайшего профиля (которую нехотя признает даже бизнес, хотя ему удобнее трубить о другом). Казалось бы, в такой ситуации с кандидатом (и тем более с работником) отношения должны быть максимально просты, честны и открыты: работник делает задачи в соответствии со своей зоной ответственности и получает за это деньги. Так давайте просто обсудим условия нашего сотрудничества. Но нет. Приходится удивлять потенциального работодателя, показывать свою энергию и доказывать, что ты способен эмоционально пропустить проект через себя.
Trouble hiring senior engineers? It's probably you
К примеру, работал человек в аутсорсе, клепал скучные задачи линейно. А потом перешёл в компанию, развивающую свой продукт, и стал rock star.
«Невозможно будет построить корабль, который двигался бы быстрее скорости света» — учёные XX-XXI веков.