Comments 74
Чего хочет разработчик
Не хватает пункта «Денег»
его руководитель хочет
Не хватает пункта «Платить как можно меньше»
Цель разработчика — быть более востребованным на рынке труда.— это и есть деньги.
А насчет руководителя вы скорее всего ошибаетесь. Адекватный руководитель заинтересован платить ровно столько, сколько нужно чтобы человек эффективно работал. Ни больше, ни меньше. Зарабатывая на труде разработчиков, логично желать, чтобы они спокойно работали и приносили прибыль.
А насчет руководителя вы скорее всего ошибаетесь. Адекватный руководитель заинтересован платить ровно столько, сколько нужно чтобы человек эффективно работал. Ни больше, ни меньше.
Это работает какой-то краткий момент, а потом начинаются проверки «эффективности». Как правило «можно ли заставить работника работать эффективнее за те же деньги».
Соглашусь, что такое имеет место. Однако, я считаю, что это — пережиток прошлого. Те, кто так делает, рано или поздно покинут рынок — их вытеснят компании, где платят в соответствии с эффективностью.
Другой вопрос, что "стоимость" разработчика он сам и работодатель оценивает по-разному. Об этом, собственно, и статья.
Глазами же каждого отдельного работника,
это и есть деньги.
Не совсем. Востребованность — это возможность без проблем найти работу.
А работнику часто хочется не этого, а банальных денег, увы.
Адекватный руководитель
Во-первых, кто вам сказал, что руководитель всегда адекватный? Во-вторых, вы мыслите рационально и идеализировано. В жизни часто бывает человеческий фактор. Т.е. руководитель в целом вменяемый, но есть какая-то придурь и т.д.
Ни больше, ни меньше.
С «ни больше» соглашусь, с «ни меньше» нет. Меньше не платят ровно по одной причине — боятся, что сотрудник уйдет в другое место. Просто попробуйте прийти и попросить выше зп. Как правило, будут вопросы, аргументы, пообещают подумать или повысить, но потом и т.д. И как альтернатива, придите и скажите, что вы увольняетесь. Уверяю, что во втором случае зп повысят гораздо быстрее и легче.
Не совсем. Востребованность — это возможность без проблем найти работу.Обычно, человек, который может без проблем найти работу, знает сколько он стоит и может аргументировать это. Поэтому, на мой взгляд, востребованность конвертируется в деньги.
А работнику часто хочется не этого, а банальных денег, увы.
Во-первых, кто вам сказал, что руководитель всегда адекватный? Во-вторых, вы мыслите рационально и идеализировано. В жизни часто бывает человеческий фактор. Т.е. руководитель в целом вменяемый, но есть какая-то придурь и т.д.Никто не говорил, я верю, что адекватные вытеснят неадекватных. Тяжело быть неадекватным, если твои сотрудники в любой момент могут встать и уйти в соседний офис.
И как альтернатива, придите и скажите, что вы увольняетесьДа, этот способ работает, но часто воспринимается как шантаж. Со всеми вытекающими.
в любой момент могут встать и уйти в соседний офис
Не везде рядом есть такой офис, чем меньше город, тем сложнее встать и уйти.
но часто воспринимается как шантаж
Я и не призываю так делать, а лишь на примере поясняю, что если можно не повышать зп, ее повышать не будут.
Тяжело быть неадекватным, если твои сотрудники в любой момент могут встать и уйти в соседний офис
Это в Москве.
Здесь в России соседних офисов нет. А если есть, то там уже на 5 вперед все укомплектовано.
На любом собеседовании вы наберете гораздо больше очков, если будете иметь за спиной успешно сданные проекты.
Т.е. априори об удержании разработчика речи не идет, набрал скилов и портфолио — прыгнул на место посытнее и так до бесконечности
Если разработчик условно хочет на проекте заюзать какую-то технологию, выучить её, а потом свалить в другое место. Либо руководитель хочет закрыть проект, собрать премию и свалить куда-то на повышение — то все это не будет работать.
Выгоднее сотрудничать. Обеим сторонам.
Ключевое забыли — «в долгосрочной перспективе». Если долгого сотрудничества не предполагается, то выгоднее «кинуть». ИМХО, дилемма заключенного для замкнутых сообществ. Когда работнику и работодателю некуда убежать.
Вы недооцениваете замкнутость сообщества разработчиков. За каждым из нас тянется шлейф побед и поражений. Современные коммуникации даже усугубляют это.
Аргументом в пользу вашей точки зрения является постоянно растущий недостаток разработчиков. Но работает это слегка криво. "Хорошие" компании все равно имеют возможность выбирать, а в "плохие" и неразборчивые вы и сами не захотите.
Я возможно вас удивлю, но проблемы получить контакты всех предыдущих работодателей и руководителей — нет. Пришедший на собеседование разработчик — не сферический конь в вакууме.
Что-то мне подсказывает, что ваше закрытое сообщество профессиональных разработчиков, ограничено вашим кругом общения.
Все про всех — это конечно гипербола. Но про большинство — можно получить информацию, достаточную для принятия решения.
Или допустим, что менеджер закрыл проект и решил попробовать себя в другой сфере. Это же не кидок и прочее — а обычная ситуация.
В описываемых вами ситуациях ничего плохого нет, это рабочие моменты.
А вот если, например, разработчик в разгаре тяжелого внедрения начинает рассказывать, что ему неинтересно фиксить баги и он хочет уйти — субъективно это воспринимается как "кидок". В этом случае ожидания руководителя такие — мы доводим дело до конца и расходимся.
Кстати очень прикольный момент, что новое != модное. Ну вот для примера, Kotlin он модный, но собран на старых идеях, а вот Idris реально новый, но вот точно не модный.
Поэтому стоит уметь различать эти две вещи и для саморазвития лучше все же изучать и классику и новые веяния, но при этом не поддаваясь слишком сильно моде. В конце концов, среди модных веяний только малая часть будет реально новизной обладать.
А так да, с вашим комментарием вполне согласен.
Разработчик хочет узнавать новое, а руководитель хочет, чтобы он хорошо умел пользоваться привычными инструментами.
Лол? Так и нанимайте тех, кто не хочет (не будет) узнавать новое. Проговаривайте это и в вакансии, и на интерью, тогда проблем не будет
Разработчик хочет решать интересные задачи, а у руководителя мешок обычных задач, которые кто-то должен делать.
Посмеялся. Может, у руководителя еще и пол надо помыть, картошку вскопать? Нанимайте людей для решения ваших обычных задач, а не для интересных.
Разработчик хочет участвовать в новых проектах, а руководителю нужно, чтобы кто-то поддерживал уже имеющиеся.
Вот и переведите на имеющиеся проекты тех, кто готов их поддерживать. А на новые — тех, кто хочет пилить новые. Разве так сложно?
Разработчик не хочет заниматься ничем кроме разработки, а руководителю нужно, чтобы код был документированным, чтобы процесс разработки был прозрачным и управляемым, чтобы выполнялись планы, выдавались релизы и т.д. Для этого он просит давать оценки, проводит стендапы, ретроспективы, заставляет планировать свою деятельность.
То же самое: при найме сразу проговаривайте, что у вас не только разработка, а еще и выполнение планов, выдача релизов и т.д.
Разработчик хочет принимать решения самостоятельно (он же знает, как правильно), а руководитель требует, чтобы о выявленных проблемах сообщали ему, чтобы он мог проконтролировать принятие решения.
Микроменеджер? Давайте, до свидания.
Неудивительно, что многие руководители разработки имеют плохую репутацию среди своих разработчиков – они не дают делать то, что хочется, а наоборот, заставляют заниматься тем, от чего тошнит.Действительно, не удивительно. Люди просто не понимают, зачем их наняли (либо им врали на интервью?).
Лол? Так и нанимайте тех, кто не хочет (не будет) узнавать новое. Проговаривайте это и в вакансии, и на интерью, тогда проблем не будетВидимо до конца прочитать не получилось, а ведь специально написал:
Думайте не только об успехе проекта, но и о развитии своих людей. Проектов много, пусть разработчики растут с каждым новым проектом. Займитесь регулярным обучением своих людей.
Посмеялся. Может, у руководителя еще и пол надо помыть, картошку вскопать? Нанимайте людей для решения ваших обычных задач, а не для интересных.Думаю мой посыл прошел мимо вас. Здесь идет речь о том, что в приоритете руководителя не развлечение разработчиков, а решение реальной задачи. А для этого иногда необходимо сосредоточено и невесело дебажить свой код, который в продакшене работает не так как надо.
Про помыть пол и вскопать картошку — жирно.
Вот и переведите на имеющиеся проекты тех, кто готов их поддерживать. А на новые — тех, кто хочет пилить новые. Разве так сложно?Поясню. Я утверждаю, что поддерживать проекты — полезно для карьеры разработчика. Кроме того, есть еще и понятие эффективности, и ваше решение — крайне неэффективно.
То же самое: при найме сразу проговаривайте, что у вас не только разработка, а еще и выполнение планов, выдача релизов и т.д.Любому, кто не школьник, это и так понятно. Но это не значит, что всем это нравится.
Микроменеджер? Давайте, до свидания.Банальный промежуточный контроль. Классика управления. Уверен, что вы в курсе.
Я утверждаю, что поддерживать проекты — полезно для карьеры разработчика.Представляю, приходите вы к Скотту Ханселману, и говорите: «привет, Скотт, для твоей карьеры будет полезно поддерживать кое-что, у нас тут проектик есть, не возьмешься?»
Кроме того, есть еще и понятие эффективности, и ваше решение — крайне неэффективно.
Еще раз — для кого неэффективно-то? И это не мое решение, так устроен мир разработки ПО.
- Для бизнеса очень даже эффективно, поэтому-то все ищут людей «с опытом», но надеются найти профессионалов, потому что им дашь им проект, они его и пилят и все.
- Для разработчика профессионального — тоже, ему сразу понятно, что от него требуется на проекте, и что он получит, завершив этот проект.
Любому, кто не школьник, это и так понятно. Но это не значит, что всем это нравится.Нормальные компании делают так, что все занимаются тем, что им нравится (и отсюда идут все эти KPI, карьерные цели, пути развития и т.п — просто хотят совместно выяснить, кто что хочет делать). А это нужно для того, чтобы люди были эффективны на 100%. Никто не будет эффективен, если занимается какой-то фигней, которая ему не нравится.
В реальном мире все не такВ моем реальном мире я не могу себе позволить набирать новых разработчиков на каждый проект — у проектов есть сроки, а найм — дело непредсказуемое. Кроме того, проекты сложные и если делать их каждый раз новой командой — будет или качество не очень, или денег компания не заработает.
приходите вы к Скотту ХанселмануЯ уверен, что Скотт на заре своей карьеры хоть что-то да поддерживал из того. что разрабатывал. Да и сейчас, если что-нибудь пишет в продакшен, не откажется пофиксить за собой. Профессиональная этика, все такое.
Нормальные компании делают так, что все занимаются тем, что им нравится (и отсюда идут все эти KPI, карьерные цели, пути развития и т.п — просто хотят совместно выяснить, кто что хочет делать). А это нужно для того, чтобы люди были эффективны на 100%. Никто не будет эффективен, если занимается какой-то фигней, которая ему не нравится.Было бы здорово, если бы это было возможно. К сожалению, это как идея коммунизма — на практике не очень работает. Всегда найдется дело, которым заниматься не очень хочется, но надо.
И если вам не трудно — приведите примеры «нормальных» компаний, где сотрудники занимаются только тем, что им нравится, и ничем другим.
И еще раз, если вы внимательно читали статью — она как раз про то, как найти компромисс между тем, что нужно и тем, что хочется.
Приведу пример компании
Если не секрет — что за компания-то? Чем занимается? Сколько людей работает?
Вы встатье затронули только разработчиков
Я сам разработчик, и считаю себя в праве говорить только от лица разработчиков.
По моему личному опыту работы в нескольких компаниях от расцвета до момента когда всё начинало идти через одно место всегда происходили одни и те же события
Интересно, как это выглядело со стороны руководства.
Рискну предположить — сначала никто ничего не контролирует и сотрудники делают что хотят. Иногда это даже приносит компании успех. По мере роста компания вынуждена выстраивать какие-то процессы, появляется контроль и управляемость. Вчерашние супермены, которые принимали все решения сами, теперь подчиняются назначенному менеджеру («эффективному»). Естественно это им не нравится и происходит частичная или полная смена состава. К сожалению, этот путь практически неизбежен для компании, которая растет. Руководство может смягчить этот процесс, как-то договориться с теми, кто начинал. Но совсем избежать этого тяжело. Это болезнь роста, через нее надо пройти.
из за гибкой методологии уже появился техдолг
Все, дальше снежный ком.
Вы так говорите, как будто при водопаде не бывает тех долга. Гибкие методологии — всего лишь инструмент, как интеграл. Вы ведь не будете жаловаться на интеграл из-за того, что у вас расчеты не сходятся?
В моем реальном мире я не могу себе позволить набирать новых разработчиков на каждый проект — у проектов есть сроки, а найм — дело непредсказуемое.
А когда вы тогда собираетесь выделять разработчикам время на изучение новых проектов? Вы же понимаете, что делать новый проект на новых технологиях — как раз означает, что четкие сроки могут быть внезапно сдвинуты?
У нас сейчас обучение имеет непрерывный характер. Мы постоянно формируем группы и чему-то их учим. Новые разработчики в обязательном порядке проходят первичное обучение. В общем готовимся заранее.
Новые разработчики в обязательном порядке проходят первичное обучение.
Первичное обучение это не совсем то, что осваивание новых технологий.
Опять таки — чему учите эти группы? Можете назвать навскидку технологии, которые недавно изучили ваши сотрудники? И какие из них на текущий момент НЕ используются в проекте?
1. Разработчик должен помнить что успех бизнеса, в котором он трудится, важен в первую очередь для него самого: если компания грохнется из-за низкой квалификации разработчиков, низкого качества кода, который разработчик создаёт (например, плохо документированного кода), первым с протянутой рукой пойдет именно он. При сокращении в компании, почему-то управленцев как правило оставляют, а разрабов пинком под зад на улицу.
2. Есть сомнения в том, что нужно обучать разработчиков. Нет, это, конечно, гуманно и мило, но сейчас ты его научишь, а завтра он уйдет к конкурентам которые предложат на 5% больше к зарплате?
С пунктом 1 согласен на 99%.
С пунктом 2 — не согласен совсем. Дело не в гуманности. Я обучаю своих людей, чтобы они были более эффективны, быстрее и лучше решали поставленные задачи. Кроме того, это ценится разработчиками, а значит они более охотно будут со мной работать. А к конкурентам кто угодно может уйти и без обучения, таков сегодня рынок труда.
del
Давайте проверим:
Руководителю разработки
Думайте не только об успехе проекта, но и о развитии своих людей. Проектов много, пусть разработчики растут с каждым новым проектом. Займитесь регулярным обучением своих людей.
КАК учить разработчиков. Новый проект для руководителя не означает смену технологий, ему нужно чтобы новый проект быстро запилили. Для этого лучше проверенные технологии.
Выделять им время?
Объясняйте разработчикам потребности бизнеса и смысл задач, требований и процессов.
То есть заставлять их вникать в бизнес
Объясняйте важность процессов и следите за тем, чтобы им следовали.
То есть заставлять их вникать в бизнес
Прислушивайтесь к мнению разработчиков по улучшению процессов.
То есть заставив их вникнуть в бизнес получить от них советы как его улучшить?
Поощряйте ответственность и организованность.
То есть заставляйте их работать пожестче, а тех кто сам себя заставляет хвалите?
Позволяйте разработчикам самостоятельно решать возникшие проблемы.
Если возникли проблемы, не помогайте, сами справятся?
Простите, но я увидел сколько должен изменить в своем подходе разработчик и вообще не увидел, что должен изменить в своем подходе руководитель.
P.S. Я отлично понимаю что хочет руководитель, и в принципе согласен с тезисами. Но предполагалось, что статья покажет что обеим сторонам надо развиваться, иначе какой в ней смысл?
- Руководители не хотят учить разработчиков, а хотят чтобы проект запилили быстро — статья призывает их заняться обучением. Выделять время. Тратить деньги бизнеса.
- Руководитель сам "знает" как что делать — статья призывает прислушаться к разработчикам.
- Руководитель хочет сам принимать решения — статья призывает его делегировать разработчикам. Предварительно добившись от них понимания и осознанности.
- Руководитель хочет ставить задачи — а статья призывает его воспитывать в людях правильные установки.
Это вовсе не мелкие исключения, как мне кажется. Это дополнительная и непростая работа, особенно для тех, кто привык только "руками водить".
С другой стороны, может быть кто-то напишет статью — про карьеру руководителя глазами разработчика, и в ней будет несколько другой фокус.
Руководители не хотят учить разработчиков, а хотят чтобы проект запилили быстро — статья призывает их заняться обучением. Выделять время. Тратить деньги бизнеса.
Очень спорный момент про обучение, хотя тут конечно вопрос, что считать обучением.
Если «классичекий» вариант с отчитать курс по какой-то теме, то тут толку с моей точки зрения очень мало. Траты времени в никуда, потому что знания, которые ты не «пропустил через себя», не попробовал в боевой обстановке, мало ценны. Классические образовательные курсы могут быть конечно полезны для начинающих программистов (слово разработчик подрузамивает, что человек в состоянии еще и спроектировать решение), но для человека с минимальным опытом, а тем более для человека с инженерным мышлением это часто пустая трата времени. Мы живем все-таки в 21 веке, и доступность информации очень высокая, человек всегда найдет информацию по интересующей его теме, а вот если интереса нет, то никакие курсы этому не помогут. В конце концов высшее учебное заведение должно было развить только один навык — способность учиться самостоятельно.
Если мы говорим про развитие разработчиков, то тут более должен идти фокус на делегирование полномочий разработчикам (что в статье справедливо упоминается), на развитие ответственности за выпущенный продукт, идеальным вариантом (правда не всегда реализуемым) является, когда разработчик ведет полный цикл от общения с заказчиком и сбора требований до технической поддержки.
Но тут конечно, опять же, вопрос о бизнес модели, если это аутсосорс, где зачастую свободы действия мало, и нужна просто армия «роботов», то тут может и сработать вариант с классическим обучением, для быстрой пусконаладки «роботов». Для продуктовой разработки или другой, где есть устоявшиеся команды и отношения с заказчиком «классика» уже не в тему. Тут нужно развивать ответственность каждого конкретного разработчика и стимулировать институт менторства.
Вам просто необходимо прочесть недавнюю статью от Джоэла Сполски об абстракции для разработчиков. Но в кратце, вы пытаетесь убедить, что токарю, делающему деталь для ракеты нужен не только полный курс физики, но и фин обоснование проекта запуска спутника не только знать, но и разделять взгляды руководства этого проекта. Это абсурд.
П.С. И для корпоратива реально проблема, когда человек на позиции токаря оказывается по уровню главконструктором и отчаливает в свой стартап собрав все сливки из компании.
2. Вы сейчас с легкой руки сравнили разработчиков и токарей, совершенно забыв, что в работе разработчика неопределенности на порядки больше. Уверен, что токарям крайне редко ставят задачу — «посмотри как мы делали это год назад в другом проекте и сделай также, что нужно поменяй». Я немного работал на заводе, и знаю как там все устроено.
3. Я сам довольно долго считал, что достаточно четко поставить задачу — а дальше пусть разбираются. Этот подход раз за разом приносил мне разочарование в человечестве. А вот когда я стал объяснять людям смысл — все заиграло другими красками.
Сравнение программиста с токарем напомнило притчу о трех каменщиках. IMHO, пусть лучше инженер вдохновляется строительством храма, чем думает как тратит жизнь с каждым ударом зубила.
недавнюю статью от Джоэла Сполски об абстракции для разработчиков
Если речь об этой статье 2002 года, то в ней Джоэл говорит примерно то же, что и автор поста: выполняя задачу, понимай, что именно ты делаешь:
The law of leaky abstractions means that whenever somebody comes up with a wizzy new code-generation tool that is supposed to make us all ever-so-efficient, you hear a lot of people saying “learn how to do it manually first, then use the wizzy tool to save time.”
Есть еще статья про боинги очень интересная.
Обратите внимание, как для ценности компании важно, что бы даже менеджеры полностью абстрагировались от того, что они делают. Как вы думаете, почему?
Можно долго и безрезультатно спорить насколько это все правильно и т.д. Я просто сокращу до минимума, а каждый может сам для себя решать.
Довольно крупному бизнесу (где работники — это статистика) важно что бы все сотрудники и само собой конечные актуаторы были легко заменимы и широко представлены на рынке труда. Все процессы владельцы бизнеса должны выстраивать исходя из этого.
Думаю, что такая формулировка дает понять где в этой системе ценностей понимания и одобрение целей и процессов компании рядовым сотрудником.
Что такое хорошо и что такое плохо. Карьера разработчика глазами его руководителя