Комментарии 39
В самом начале статьи постулируется такое необходимое качество, как ВОВЛЕЧЕННОСТ = способность искать по ночам пропавшие данные. После этого дальше читать перестал. Как то стало не очень интересно.
Ну и зря не дочитали, статья хорошая!
ВОВЛЕЧЕННОСТ = способность искать по ночам пропавшие данные. После этого дальше читать перестал.
Тоже резанул этот момент в статье. Как будто автор намекает - хотите быть классными - работайте по ночам.
Нет, ни чем хорошим работа по ночам не закончится.
При этом, если было бы сказано "пилите на выходных свои проекты" - с этим можно было согласиться (как показатель увлеченности своим делом), но когда речь идет о бесплатных постоянных переработках на работодателя - то это будет лишь показывать вашу степень неуважения к себе и к своему времени. А того, кто не ценит себя, окружающие также не будут ценить.
Также в этом контексте стоит упомянуть про разницу между должностью и зарплатой и реальной значимостью в проекте. И может сложиться так, что какой-нибудь Петя, на должности рядового программиста, сам того не зная, работая на выходных и по ночам будет обладать знаниями на уровне техлида, вот только должность техлида и зарплата техлида будет у другого сотрудника. Который общительный, умеет говорить, презентовать себя и любит выступать на конференциях.
А я полностью согласен, даже в этой формулировке
Именно тут проходит граница между просто разработчиком на пейчеке, и тех/тим лидом. Последний считает продукт своим детищем, и ночью встать для него, если что-то не то, это не должностная обязанность или страх потери работы/зарплаты, а естественное желание, как у матери к заплакавшему ребенку
Другой вопрос, что рабочий процесс должен быть построен так, чтобы ночью вставать не приходилось
Нет, тимлид - это должность, подразумевающая выполнение своих обязанностей 8ч в день (или 7,5 в Европе). Не более того. Никакого желания что то делать ночью быть не должно. И уж тем более это не может быть критерием
Последний считает продукт своим детищем, и ночью встать для него, если что-то не то, это не должностная обязанность или страх потери работы/зарплаты, а естественное желание, как у матери к заплакавшему ребенку
Есть нюанс. Для матери такое желание естественно — это действительно ее ребенок, носитель ее генов. А вот для наемного работника, не важно на какой позиции, такое желание противоестественно: это не его продукт, продукт этот работнику не принадлежит — он принадлежит хозяину бизнеса, иными словами, результаты труда наемного работника от этого работника отчуждаются.
Восприятие работником продукта как своего — это когнитивное искажение. Но поскольку такое искажение выгодно владельцам бизнесов (они же — капиталисты), и поскольку именно капиталисты являются господствущим классом в современном обществе, то современное общество старается поддерживать в наемных работниках это искажение восприятия: считать отчужденный от него продукт своим.
Не давайте себя обмануть.
Вообще-то, уровень техлида в нормальной компании - это уже какие то shares, доля в бизнесе
Ну а когда ты создал архитектуру продукта,, вложил в это свою творческую энергию, ты в любом случае воспринимаешь продукт как "своё детище"
Ну а когда ты создал архитектуру продукта,, вложил в это свою творческую энергию, ты в любом случае воспринимаешь продукт как «своё детище»Это понятно. Но я писал про то, что это восприятие в обычных условиях не соответствует объективной обстановке.
Вообще-то, уровень техлида в нормальной компании — это уже какие то shares, доля в бизнесеСначала — о том, чем эти голосующие акции не являются: о доле в бизнесе. Прежде всего, если этих голосующих акций у лида немного (а это почти наверняка так), то фактом, что они голосующие, можно пренебречь. Такие голосующие акции, например, часто при приватизации во времена Чубайса доставались работникам приватизированных предприятий, что на практике не делало их совладельцами бизнеса.
Далее, акции, если они ликвидны — то это просто дополнительные деньги, здесь и сейчас. Про их будущую же цену их сказать ничего нельзя, и она зависит от стольких многих факторов, что качество работы техлида на их фоне незаметно. В общем, в плане роста курса акции подобны лотерейным билетам: да, выигрыш возможен, но он не гарантирован и от вас не зависит. В эту же кучу попадают и опционы на покупку акций в будущем по фиксированной цене.
Ну, а дивидендами по акциям какого-нибудь стратапа можно просто пренебречь, часто они вообще равны нулю.
Вывод: насчет доли в бизнесе и в его доходах, конечно, надо смотреть конкретно в своем случае, но IMHO часто это — практически чистое моральное стимулирование модели «морковка спереди».
Такие идеи о "своем детище" на практике быстро разваливаются, т.к. точка зрения на развитие продукта у бизнеса и техлида отличаются, и решение не за техлидом, и в данной ситуации каждый считает продукт "своим детищем" и тянет одеяло на себя. В такой ситуации у техлида получается позиция "прокладки", номинального управляющего - он отвечает за техническую часть и желает ее максимально улучшить, но фактически никаких реальных полномочий на это повлиять не имеет, желания диктует исключительно бизнес, потому что бизнес все и оплачивает.
Роль техлида - наилучшим образом удовлетворить потребности бизнеса с помощью своей технической экспертизы. И с этой точки зрения это просто рутинная должность: переводить требования с языка бизнеса на язык технологий. Придумать как наилучшим образом реализовать запрошенное, с учётом потребностей бизнеса по стоимости, времени и функционалу - требуется найти некий компромисс, чтобы решение было функционально и финансово доступно, и в тоже время не ломало существующие процессы и было поддерживаемо.
Такие идеи о "своем детище" на практике быстро разваливаются
Еще вопрос, что понимать под своим детищем, например, это может быть challenge-история в духе "смогу ли сделать с учетом таких ограничений". Ну т.е. человек вполне понимает, что продукт (внутри которого challenge) не его, а компании. Но мотивация не в самом создании продукта (и владении им) - конечная цель в достижении результата (крут, смог и т.д.). Более того в ряде ситуаций вообще создается продукт под конкретные условия и кроме как в этом месте применить его нельзя. Вернее можно, но тогда придется условия другого места привести к необходимым для внедрения, что не всегда допускается.
Роль техлида - наилучшим образом удовлетворить потребности бизнеса с помощью своей технической экспертизы. И с этой точки зрения это просто рутинная должность: переводить требования с языка бизнеса на язык технологий.
Кмк зависит от ситуации - роли могут совмещаться (техлид + еще какая-то) и степени влияния на продукт также зависят от команды. Не везде и не всегда вы будете просто прослойкой. Более того, правильным решением будет команда, которая слушает своих участников, а не реализует задачи сверху вниз. Это не всегда и не везде может работать, но дает очень хорошие плоды
нет никакого искажения кому-то считать своим детищем некий продукт в который вложено много усилий. Считают своим как правило те, необязательно даже некие *лиды, кто по тем или иным причинам "занял" эту нишу. Любой в команде, кто больше других проявляет заинтересованность в его развитии может стать "отцом". А что он имеет с этого - не так важно. Кто-то хочет побольше бабла срубить, кто-то хочет реализовать свои идеи, у кого-то банально нет реальных детей и он(а) реализуется в работе. Какая разница-то ? Реальная разница показывает лишь то, что проекты у которых есть "опекун" развиваются и растут порой "несмотря на и вопреки". Даже если слабая техническая база, на интузиазме активного "опекуна" могут достигать больших результатов нежели более высоко-технологичный продукт сделанный по канонам бизнеса, но в безотцовщине.
нет никакого искажения кому-то считать своим детищем некий продукт в который вложено много усилий.
Объективно продукт работнику не принадлежит, а приложенные к его созданию усилия оплачены (надеюсь, адекватно) владельцем продукта.
А что он имеет с этого — не так важно.
Основная объективная причина, почему работник работает над продуктом — зарплата работника. Остальное — чисто субъективно, и, если смещает баланс приложенных работником сил и оплаты в пользу владельца бизнеса — вредно, т.к. противоречит объективным интересам работника. И други работников — кстати, тоже, потому как сбивает цену работников на рынке труда.
проекты у которых есть «опекун» развиваются и растутОбъективно наемный разработчик в судьбе проекта не заинтересован: это — не его проект, проект принадлежит владельцу бизнеса.
Именно на таких горбах и ездит менеджмент бизнес. "Твой" продукт, "заплакавшийся ребенок" - если человек воспринимает код своего работодателя так и никак иначе, то где быть месту личности этого человека?
Давайте начнем с главного - вы, устраиваясь на работу, изначально подписываетесь под то, что результат ваших трудов принадлежит работодателю (хотя ваше авторство никто не оспаривает). Вы изначально подписываетесь под то, что на вас будут "ездить" и вы будете получать за это деньги.
Значит ли это, что теперь свою работу надо делать спустя рукава? Я считаю, что нет и если я накосячил, то моя обязанность встать посреди ночи и починить свой косяк. Это, в том числе, часть вашего контракта с работодателем (делать свою работу хорошо и отвечать за результат). Бывают ли спорные ситуации, где косяк роде бы не твой - да бывают, но мы работаем командой и иногда нужно помогать коллегам.
Попутно у некоторых людей возникает вполне логичное желание - сделать классный продукт, да он формально не твой, но по сути своей он был создан тобой лично (или твоей командой). Не вижу ничего плохого в том, что люди хотят достигнуть каких-то вершин на работе, выполнить свой challenge.
Возвращаясь к вопросу "Где быть личности человека/автора?" - да везде, вы никогда не перестаете быть личностью, что на работе, что вне ее. Вы можете быть согласны/не согласны с чем-то, можете соглашаться или сопротивляться решениям. Да вы каждую секунду личность, принимающая те или иные решения.
Если вам не нравятся правила найма - работайте на себя на своих условиях или найдите компанию под ваши запросы.
P.S. я сам сейчас менеджер, периодически что-то делаю руками сам (помогаю команде) и за время роста с начальной позиции в ИТ до текущей каких-то принципиальных изменений не было. Как старался делать свою работу хорошо, так и делаю и не вижу тут поинтов про эксплуатацию (мне за это платят и я соглашаюсь на такие условия). Когда мне что-то категорически не нравилось и я не мог это поменять - менял работу и находил более адекватные (под свои запросы) места.
Вы изначально подписываетесь под то, что на вас будут "ездить" и вы будете получать за это деньги.
Что ж - вы идеальный исполнитель - чем больше таких тем выгоднее бизнесу.
Давайте начнем с главного — вы, устраиваясь на работу, изначально подписываетесь под то, что результат ваших трудов принадлежит работодателюА давайте рассмотрим, под что именно подписывается наемный работник, аккуратно рассмотрим.
Значит ли это, что теперь свою работу надо делать спустя рукава? Я считаю, что нет и если я накосячил, то моя обязанность встать посреди ночи и починить свой косяк.Обычно требования к качества работы наемного работника-программиста специально в трудовом договоре и связанных с ним документах, типа долностной инструкции (далее все это упоминается как просто «трудовой договор») не прописывается. А потому — регулируется «обычаем делового оборота», тем, как оно обычно бывает. А про результат труда программиста — программу — известно, что она на практике всегда содержит ошибки, а потому наличие ошибок — это не результат работы ненадлежащего качества («спустя рукава»), а нормальный результат. И исправление ошибок — не что-то экстраординарное, а часть нормальной работы программиста.
Как и когда это делается — зависит, от того, как определен в трудовом договоре режим работы программиста. Если рабочий день программиста не является ненормируемым (что должно быть прописано в трудовом договоре и влечет за собой согласно ТК некоторые дополнительные обязанности работодателя), то тогда, может — и среди ночи. Но обычно рабочий день программиста является нормируемым, а потому всякие косяки должны исправляться либо в указанное в трудовом договоре рабочее время, либо, в особых случаях, за счет сверхурочных работ (оформляемых согласно ТК, производимых в рамках ограничений, прописанных в ТК, и компенсируемых согласно ТК). То есть, никаких «встать среди ночи и починить косяк» без соответствующего оформления сверхурочной работы работодатель и (его представитель-менеджер) не имеет права с наемного программиста требовать.
Попутно у некоторых людей возникает вполне логичное желание — сделать классный продукт, да он формально не твой, но по сути своей он был создан тобой лично (или твоей командой).По сути, этот «классный продукт» — он не наемного программиста. Наемному программисту от этого классного продукта остается только возможность продемонстрировать умение делать такие «классные продукты». Если наемному работнику это зачем-то нужно (для резюме, например, или для занятия более высокой позиции) — он имеет право заниматься этим, не требуя дополнительной оплаты. Если не нужно — имеет право забить, и это — совершенно нормально, что бы ни говорил менеджер, подначивая наемного работника «на слабо».
Если вам не нравятся правила найма — работайте на себя на своих условиях или найдите компанию под ваши запросы.Не совсем так. Тут со времен «дикого капитализма» середины XIX века (или 90-х в России) кое-что поменялось: государство (в целом — после получения пенделей со стороны рабочего движения, но иногда — и чисто превентивно, чтобы пенделей не получать) решило, что при заключении трудового договора наемный работник является слабой стороной, и несколько ограничило нанимателя в том, что он вообще от работника может требовать. В РФ эти ограничения прописаны, в основном, в Трудовом Кодексе.
я сам сейчас менеджерА потому пишете со своей классовой позиции, которую вы занимаете в процессе общественного производства. Это нормально, однако предлагаю вам учитывать, что куда большее число посетителей Хабра являются наемными работниками, а потому будут оценивать написанное вами со своей классовой позиции.
А давайте рассмотрим, под что именно подписывается наемный работник, аккуратно рассмотрим.
Работник подписывается под выполнение определенных задач, которые, по идее, должны быть отображены в его должностной инструкции. Формулировки в ДИ чаще всего довольно широкие и подразумевают разные трактовки. Обязанность о передаче результатов своих трудов описывается в трудовом договоре (или еще где-то, не помню точно).
Если вы здесь хотите подвести под идею "Не написано в ДИ - идите нафиг", то я отвечу так: на мой взгляд, исчерпывающей ДИ не может быть в природе (либо ее придется постоянно править). Это как с законом - описаны общие принципы, но нет детализации до винтика. Хорошо это или нет - спорный вопрос. Я бы перевел это больше в область доверия и соблюдения данных слов. Если вы о чем-то договорились и это соблюдается, то формальное оформление уходит на второй план.
Есть ли у такого доверия риски - безусловно есть. Мой подход больше основан на том, что если вы не держите слово, то мы вряд ли будем работать вместе дальше.
программу — известно, что она на практике всегда содержит ошибки, а потому наличие ошибок — это не результат работы ненадлежащего качества («спустя рукава»), а нормальный результат.
Соглашусь, что наличие ошибок возможно, но наличие критических ошибок на Проде говорит о некачественном процессе разработки, не обязательно виноват программист (мог накосячить QA). Тем не менее, я считаю, что исправлять крит ночью все равно надо, тем более, что кроме разработчика никто другой может эту часть не знать так же хорошо.
Про ненормированный или обычный график
Да, есть такая история, что у разработчиков делают ненормированный график. Но на мой взгляд тут надо руководствоваться принципами разумности. Если у вас эта история ночного фикса раз в квартал, то может и не стоит "лезть в бутылку" и просто починить? А заодно провести ревью всего процесса и выработать меры по предотвращению этого в будущем?
Любой график позволит допускает перекосы, адекватной руководство и нормальные отношения кмк более важны, чем документально оформление режима работы.
По сути, этот «классный продукт» — он не наемного программиста. Если наемному работнику это зачем-то нужно ... он имеет право заниматься этим, не требуя дополнительной оплаты. Если не нужно — имеет право забить, и это — совершенно нормально, что бы ни говорил менеджер, подначивая наемного работника «на слабо».
Согласен, это выбор каждого ради чего он каждый день ходит на работу (ради денег, классного продукта, команды, принадлежности чему-то большому и т.д.). Главное, чтобы за этим "мне не интересно" не скрывалась идея, что теперь можно не следить за результатом.
при заключении трудового договора наемный работник является слабой стороной, и несколько ограничило нанимателя в том, что он вообще от работника может требовать.
Не понял эту мысль, у нас наоборот работник очень даже хорошо защищен и уволить за некачественную работу иногда очень нетривальная задача с риском пойти под суд и восстановить работника.
предлагаю вам учитывать, что куда большее число посетителей Хабра являются наемными работниками, а потому будут оценивать написанное вами со своей классовой позиции.
Я это понимаю, более того, я выражаю свою точки зрения и любой читатель Хабра может согласиться или нет с ней. Я не заставляю вас думать и действовать также.
Я видел разные команды и людей, где-то работали ради идеи/продукта (как с хорошей оплатой, так и без), где-то ради денег или чего-то еще. Есть люди, которым нравится продуктовая разработка, кому-то нравится заказная (аутсорс, аутстафф и т.д.).
Каждый из нас сам выбирает где, зачем и на каких условиях он будет работать, а также все ли фиксировать на бумаге или хватит лишь слова.
Работник подписывается под выполнение определенных задач, которые, по идее, должны быть отображены в его должностной инструкции. Формулировки в ДИ чаще всего довольно широкие и подразумевают разные трактовки.
Я же специально написал чуть дальше: «А потому — регулируется «обычаем делового оборота», тем, как оно обычно бывает». Не прописано в ДИ — смотрим на обычай. Конечно, трудовое право — оно не гражданское, и сослаться на «обычай делового оборота» в судебном решении там не получится, но, думаю, идею вы поняли: от программиста требуется то, что от него обычно требуется. А это — отнюдь не программа, лишенная ошибок.
Есть ли у такого доверия риски — безусловно есть. Мой подход больше основан на том, что если вы не держите слово, то мы вряд ли будем работать вместе дальше.В трудовом праве нигде нет требования «держать слово», т.е. — «за свои слова отвечают» (если чо — это чиста по «людским понятиям»). А в трудовом праве — другие формулировки.
Соглашусь, что наличие ошибок возможно, но наличие критических ошибок на Проде говорит о некачественном процессе разработки, не обязательно виноват программист (мог накосячить QA). Тем не менее, я считаю, что исправлять крит ночью все равно надо,
Я воспитан в СССР, а потому на всякое слово «надо» (там этим словом злоупотребляли), приучен отвечать вопросом «кому?». В данном случае, «надо» — владельцу бизнеса, и обнаружение критических ошибок не может быть поставлено в вину разработчику, а, значит, устранять сколь угодно критические ошибки следует в рамках трудового права: если они совсем уж критические — за счет организации сверхурочных работ (со всеми компенсациями и ограничениями согласно ТК), иначе — в рабочее время.
Да, есть такая история, что у разработчиков делают ненормированный график.Но оформляют ли его в трудовом договоре, как полагается по ТК — вот в чем вопрос.
нормальные отношения кмк более важны, чем документально оформление режима работыОбъективно отношения владельца бизнеса (и менеджера, как его представителя) являются отношениями эксплуататора и эксплуатируемого. То есть они изначально не являются нормальными, равноправными. А потому эксплуатируемый, как менее сильная сторона отношений, имеет все основания воспользоваться гарантиями, которые предоставляет ему государство. А чтобы ими воспользоваться, документальное оформление режима работ необходимо: без этого государство помочь мало чем сможет.
Главное, чтобы за этим «мне не интересно» не скрывалась идея, что теперь можно не следить за результатом.Объективно наемному работнику совершенно незачем следить за результатом: это — не его результат, то есть, работнику этот результат не принадлежит, отчужден от него.
Не понял эту мысль, у нас наоборот работник очень даже хорошо защищенЭта защита — не естественная, она — результат борьбы наемных работников за свои права, и будущее такого результата отнюдь не гарантировано: предприниматели объективно заинтересованы, чтобы лишить наемного работника такой защиты. И кое-где у них это получается.
Я видел разные командыО командах. Пресловутая «команда» — это ложная общность, гранфаллун: объективная общность интересов у членов комнды обычно в реальности отсутствует. Честнее было бы вместо слова «команда» использовать слова «группа», «отдел» и т.п. обозначения струтурных единиц предприятия.
Спасибо за развернутые комментарии и конструктивный диалог. Мы могли бы продолжить, но, кажется, наши рассуждения уже выходят за рамки комментариев Хабра и превращаются в "простыни".
Я уважаю вашу позицию, хотя и не до конца с ней согласен. Как и раньше, никого ни к чему не принуждаю - каждый читатель Хабра сам решит как ему поступать.
Тоже резануло, ощущение что процитировано из капиталистических книжек по успеху).
Я перестал читать с момента "надо смотреть онлайн-курсы" и "стопка учебников по machine learning". Не знаю, до этого все было нормально, но не хватало вот чего: я, будучи миддлом, испытывал, зачастую, опасения с кем-то что-то обсуждать. Вдруг моя попытка ввести новую технологию будет подвергнута критике и объективному анализу. Команда и тех лид решат что это сейчас не нужно. Я не могу знать в начале, будет ли это решение удобным или наоборот - есть и по-лучше. Я хотел попробовать новый подход, новую интерфейсную библиотеку, но такое сложно психологически согласовать с руководством, потомучто у них постоянно горят сроки и может руководителям вообще не важно, что там внутри, главное "всё сделать" и любая инициатива, не содержащая посыла "завтра мы уже выгрузим продукт в релиз", может быть воспринята как саботаж, некомпетентность и нежелание работать свои прямые обязанности - делать фичи и править баги, а не что-то менять, переписывать, рефакторить и учиться новому.
отличная статья! Спасибо!
Фундаментальненько )
Спасибо
Не в обиду автору, первый раз слышу про яндекс путешествия и яндекс вертикали. Если в качестве еще одного репера взять яндекс недвижимость, то мне, как пользователю, далеко до вопросов поиска партиций и эмоциональной вовлеченности техлида, а более важно, что сервис полуживой и хуже конкурентов.
Тех лиды бывают не только у разработчиков, я тех лиды аналитиков 😉
Статьи интересна подходом а как там у них в Яндексе. Вы бы добавили лучше практических кейсов где и как помог тех лиды.
Жаль в статье не так много ссылок на курсы, а в основном книги. Сейчас быстрый темп жизни и не всегда успеваешь прочитать книгу.
P. S. Статью прочитала, так хотели узнать как развивать
Спасибо, интересно! Но "искать в академических статьях, книгах, на онлайн-курсах".... что первых, что вторых, что третьих - как грязи по нынешним временам. Может их кто и ревьюит, но именно на техническом качестве это не сильно сказывается. И как в этом не потонуть не очень понятно...
… надо использовать онлайн-курсы, академические статьи, конференции и книги — и точно не блоги и Хабр
, — сказано на Хабре. :)
На мой взгляд, скорее наоборот: онлайн курсов низкого качества овер дофига, в книгах очень много воды и страдает актуальность, конференции — это как правило рассказы про success-стори без важных и нужных подробностей. А вот статьи в различных комьюнити имеют ревью в виде комментов, актуальные отсылки на доп. материалы, возможность связаться с автором для интересующих подробностей.
Статья по крайней мере звучит не очень реалистично( по крайней мере для меня).
С таким же успехом можно было просто скинуть список книг или ссылку на web skills
https://andreasbm.github.io/web-skills/?compact
Статья написана в стиле "хочешь заработать денег - просто поверь в себя", скорее всего я здесь преувеличиваю, но ощущения именно такие, вместо ощущения протянутой руки помощи.
Наверное к автору статьи бы я не подошёл за помощью, потому что ожидал бы " не понимаю почему у тебя не получается, на вот тебе книгу, иди читай." И ты смотришь на часы, время твоё заканчивается, а в руках у тебя книга, с которой придется провести время. И скорее всего, ты просто пойдёшь к человеку, который даст тебе решение здесь и сейчас или к нескольким людям сразу.
Возможно автором многое из того, что я говорю уже подразумевалось, но у меня глаза не на том месте и я плохо прочитал.
Как по мне - статья хорошая, когда тебе не приходится ползти идти искать ответы в другом месте, но здесь каждый абзац и каждое предложение хотелось бы детализировать.
Можно было бы разбить эту статью на много отдельных статей и вставить на них ссылки.
Ну или можно было бы честно (честно?) - в конце добавить ссылку на авторский курс -" А подробности - за деньги"
Так что - желаю автору продолжать развивать эту тему и больше её детализировать, хорошего дня❤
По моему опыту нет ничего ужаснее чем работать с тех лидом который не понимает тебя из-за нехватки скиллов.
В большинстве случаев всегда найдется человек умнее вас. Стоит ли его нанимать к себе в команду - кмк стоит, если он вам подходит по софт/хард скиллам. Никогда не поздно учиться, в том числе техлидам.
Мне кажется если техлид хороший по софт скиллам то его технический уровень уже не настолько критичен в данном контексте.
Лично я на месте такого техлида был бы рад адекватной критике, это же возможность стать лучше и повысить свой скилл.
Статью надо переименовать, как стать хорошим менеджером, тимлидом, техлидом. Понятия пересекаются во всей статье. В большей части это для тимлидов на мой взгляд.
Как стать хорошим техлидом