Комментарии 74
Чего хочет разработчик
Не хватает пункта «Денег»
его руководитель хочет
Не хватает пункта «Платить как можно меньше»
Цель разработчика — быть более востребованным на рынке труда.— это и есть деньги.
А насчет руководителя вы скорее всего ошибаетесь. Адекватный руководитель заинтересован платить ровно столько, сколько нужно чтобы человек эффективно работал. Ни больше, ни меньше. Зарабатывая на труде разработчиков, логично желать, чтобы они спокойно работали и приносили прибыль.
А насчет руководителя вы скорее всего ошибаетесь. Адекватный руководитель заинтересован платить ровно столько, сколько нужно чтобы человек эффективно работал. Ни больше, ни меньше.
Это работает какой-то краткий момент, а потом начинаются проверки «эффективности». Как правило «можно ли заставить работника работать эффективнее за те же деньги».
Соглашусь, что такое имеет место. Однако, я считаю, что это — пережиток прошлого. Те, кто так делает, рано или поздно покинут рынок — их вытеснят компании, где платят в соответствии с эффективностью.
Другой вопрос, что "стоимость" разработчика он сам и работодатель оценивает по-разному. Об этом, собственно, и статья.
Часто это не имеет отношения к конкретному работнику, а является целью для всей компании — работать эффективнее. Чтобы компания выжила в конкурентной среде. И повышения эффективности, что логично, начинают требовать от всех работников, включая и руководителей.
Глазами же каждого отдельного работника,вертевшего на не интересующегося задачами и проблемами компании (и за это тоже работника не нужно осуждать, это нормально), кажется, что «выжать» хотят именно его. А на самом деле nothing personal, just business ©
Глазами же каждого отдельного работника,
На практике «это не затягивание гаек, а натягивание пружины». На некоторое время работника можно заставить работать эффективнее, но это ведет к увеличению числа ошибок, появлению технических долгов, выгоранию, «текучке» персонала. Как результат объёмы вы нарастите, но качество продукта упадет ниже плинтуса.
Тут, как и в медицине, все зависит от меры. Если «гайки» не подкручивать, работники работают все более расслабленно, и компания в итоге медленно идет ко дну. Если «гайки» перекручивать, толковые работники разбегаются по более комфортным компаниям, и с менее толковыми работниками компания снова неспешно идет туда же, куда и в первом случае. А соблюдение баланса между «не подкручиванием» и «перекручиванием» — непростое умение, в том числе за которое менеджмент и получает те зарплаты, которые он получает)
За всю свою карьеру, людей знающих в этом меру я не встречал. Вероятно потому что о повышении эффективности руководство задумывается всякий раз как замечает малейший убыток, не разобравшись досконально в причинах происходящего. А работники не решаются выступить с открытой критикой решения руководителя, т. к. им рабочее место дороже. Как результат обратная связь на затягивание гаек сильно запаздывает. Так же повышение эффективности как правило нарушает первоначальный договор между работником и работодателем (ты делаешь это, это и это, а мы тебе платим столько). Получается, что работодатель в одностороннем порядке изменил условия договора. Это обычно выливается в итальянскую забастовку. Ну раз вы нам платите за определенные работы, значит то за что не платят делать не обязательно. Получаются эффективные исполнители для узкого круга задач, всеми силами препятствуюшие внедрению новых технологий. Но вот только в IT это губительно.
это и есть деньги.
Не совсем. Востребованность — это возможность без проблем найти работу.
А работнику часто хочется не этого, а банальных денег, увы.
Адекватный руководитель
Во-первых, кто вам сказал, что руководитель всегда адекватный? Во-вторых, вы мыслите рационально и идеализировано. В жизни часто бывает человеческий фактор. Т.е. руководитель в целом вменяемый, но есть какая-то придурь и т.д.
Ни больше, ни меньше.
С «ни больше» соглашусь, с «ни меньше» нет. Меньше не платят ровно по одной причине — боятся, что сотрудник уйдет в другое место. Просто попробуйте прийти и попросить выше зп. Как правило, будут вопросы, аргументы, пообещают подумать или повысить, но потом и т.д. И как альтернатива, придите и скажите, что вы увольняетесь. Уверяю, что во втором случае зп повысят гораздо быстрее и легче.
Не совсем. Востребованность — это возможность без проблем найти работу.Обычно, человек, который может без проблем найти работу, знает сколько он стоит и может аргументировать это. Поэтому, на мой взгляд, востребованность конвертируется в деньги.
А работнику часто хочется не этого, а банальных денег, увы.
Во-первых, кто вам сказал, что руководитель всегда адекватный? Во-вторых, вы мыслите рационально и идеализировано. В жизни часто бывает человеческий фактор. Т.е. руководитель в целом вменяемый, но есть какая-то придурь и т.д.Никто не говорил, я верю, что адекватные вытеснят неадекватных. Тяжело быть неадекватным, если твои сотрудники в любой момент могут встать и уйти в соседний офис.
И как альтернатива, придите и скажите, что вы увольняетесьДа, этот способ работает, но часто воспринимается как шантаж. Со всеми вытекающими.
в любой момент могут встать и уйти в соседний офис
Не везде рядом есть такой офис, чем меньше город, тем сложнее встать и уйти.
но часто воспринимается как шантаж
Я и не призываю так делать, а лишь на примере поясняю, что если можно не повышать зп, ее повышать не будут.
Тяжело быть неадекватным, если твои сотрудники в любой момент могут встать и уйти в соседний офис
Это в Москве.
Здесь в России соседних офисов нет. А если есть, то там уже на 5 вперед все укомплектовано.
На любом собеседовании вы наберете гораздо больше очков, если будете иметь за спиной успешно сданные проекты.
Т.е. априори об удержании разработчика речи не идет, набрал скилов и портфолио — прыгнул на место посытнее и так до бесконечности
Ну откровенно говоря, все это верно лишь при одной ситуации: руководитель и разработчик заинтересованны в долгосрочном сотрудничестве.
Если разработчик условно хочет на проекте заюзать какую-то технологию, выучить её, а потом свалить в другое место. Либо руководитель хочет закрыть проект, собрать премию и свалить куда-то на повышение — то все это не будет работать.
Если разработчик условно хочет на проекте заюзать какую-то технологию, выучить её, а потом свалить в другое место. Либо руководитель хочет закрыть проект, собрать премию и свалить куда-то на повышение — то все это не будет работать.
Есть такая штука, дилемма заключенного. При своей простоте — это универсальное правило взаимодействия. Выгоднее сотрудничать. Обеим сторонам.
Выгоднее сотрудничать. Обеим сторонам.
Ключевое забыли — «в долгосрочной перспективе». Если долгого сотрудничества не предполагается, то выгоднее «кинуть». ИМХО, дилемма заключенного для замкнутых сообществ. Когда работнику и работодателю некуда убежать.
Вы недооцениваете замкнутость сообщества разработчиков. За каждым из нас тянется шлейф побед и поражений. Современные коммуникации даже усугубляют это.
Аргументом в пользу вашей точки зрения является постоянно растущий недостаток разработчиков. Но работает это слегка криво. "Хорошие" компании все равно имеют возможность выбирать, а в "плохие" и неразборчивые вы и сами не захотите.
Плохая репутация бежит быстрее человека :)
Лучше и не скажешь!
И что? У нас где-то есть объективная и беспристрастная система оценивающая репутацию? И никто не занимается накрутками и PR?
Чтобы испорченная репутация работала против человека — не нужно описанного. Достаточно ограниченного мира ИТ разработчиков и телефонного звонка
Вы всерьез считаете что мир ИТ разработчиков ограничен? Кем? Чем? Есть какой-то сайт на котором можно узнать репутацию любого разработчика? Может группа сайтов? Что-то мне подсказывает что часть разработчиков может быть не представлена нигде вобще, а часть может еще умышлено скрывать личность или иметь две и более.
Я возможно вас удивлю, но проблемы получить контакты всех предыдущих работодателей и руководителей — нет. Пришедший на собеседование разработчик — не сферический конь в вакууме.
Э-э. А если по условию контракта предыдущее место работы разглашать нельзя? А если разработчик к примеру имеет в послужном списке только одного работодателя и расстались они не по-дружески? А если разработчик до прихода официально не на какого работодателя не работал, а к примеру пилил свободный софт за донаты? А если разработчик долгое время работал в другой области, а разработка была лишь хобби? А если разработчик работал в другой стране и его работодатель не говорит ни на русском, ни на английском?
Что-то мне подсказывает, что ваше закрытое сообщество профессиональных разработчиков, ограничено вашим кругом общения.
Что-то мне подсказывает, что ваше закрытое сообщество профессиональных разработчиков, ограничено вашим кругом общения.
Есть куча пограничных ситуаций. Но гораздо чаще приходят люди, про которых все известно. Репутация есть репутация. Но если вы не злодей, чего вам бояться? :)
Странно. Я вот работал раньше в компании и довольно часто получалось так, что брали людей с хорошей репутацией и они себя не оправдывали, и брали людей без репутации вобще и они нормально работали. Ну это раньше. А сейчас я работаю там где просто все друг друга за ручку привели, но нас всего 10 человек. Но я не берусь говорить, что знаю все и про всех.
Поддержу tinhol
Пограничных ситуаций много
Я видел огромное количество примеров, когда нельзя говорить о проектах, о именах заказчиков.
Но ни разу не видел, чтобы нельзя было называть юр лицо компании где работал. Это невозможно технически — оно написано в трудовой книге
Противоречий нет. Репутация — не гарантия. Вопрос — а брали ли вы людей с плохой репутацией? А сейчас возьмете?
Все про всех — это конечно гипербола. Но про большинство — можно получить информацию, достаточную для принятия решения.
Все про всех — это конечно гипербола. Но про большинство — можно получить информацию, достаточную для принятия решения.
Если и не брали, то только потому, что их скорее всего отсеял отдел персонала и их резюме просто не попали в список. Если кого-то приводили в обход то возможно и брали, но их репутация при этом просто не проверялась. Если оценивать приходилось мне, то я оценивал только профессиональные навыки. Личностные качества мне не интересны.
А что плохого в том, что разработчик попробовал какую-то технологию, и скажем она не очень хорошо вписалась в проект? Это разве портит репутацию?
Или допустим, что менеджер закрыл проект и решил попробовать себя в другой сфере. Это же не кидок и прочее — а обычная ситуация.
Или допустим, что менеджер закрыл проект и решил попробовать себя в другой сфере. Это же не кидок и прочее — а обычная ситуация.
В описываемых вами ситуациях ничего плохого нет, это рабочие моменты.
А вот если, например, разработчик в разгаре тяжелого внедрения начинает рассказывать, что ему неинтересно фиксить баги и он хочет уйти — субъективно это воспринимается как "кидок". В этом случае ожидания руководителя такие — мы доводим дело до конца и расходимся.
НЛО прилетело и опубликовало эту надпись здесь
Кстати очень прикольный момент, что новое != модное. Ну вот для примера, Kotlin он модный, но собран на старых идеях, а вот Idris реально новый, но вот точно не модный.
Поэтому стоит уметь различать эти две вещи и для саморазвития лучше все же изучать и классику и новые веяния, но при этом не поддаваясь слишком сильно моде. В конце концов, среди модных веяний только малая часть будет реально новизной обладать.
В контексте статьи имеется ввиду новый для данного разработчика.
А так да, с вашим комментарием вполне согласен.
А так да, с вашим комментарием вполне согласен.
Ну, чтобы что-то стало модным оно должно иметь определенное и достаточно крупное (относительно сферы) сообщество, которое это оно использует. А большие сообщества так быстро не собираются (есть исключения, но на то они и исключения), поэтому инструмент успевает достаточно состариться перед началом моды на него.
А нет, случаем, статьи на английском языке? Надо скинуть кое-каким коллегам. (если вдруг нет — могу подготовить и опубликовать перевод на хабре/medium в течении недели-трех, если Вам интересно. Правда заранее предупреждаю — я не профессиональный переводчик и не лингвист, так что качество может быть несколько средним.)
Разработчик хочет узнавать новое, а руководитель хочет, чтобы он хорошо умел пользоваться привычными инструментами.
Лол? Так и нанимайте тех, кто не хочет (не будет) узнавать новое. Проговаривайте это и в вакансии, и на интерью, тогда проблем не будет
Разработчик хочет решать интересные задачи, а у руководителя мешок обычных задач, которые кто-то должен делать.
Посмеялся. Может, у руководителя еще и пол надо помыть, картошку вскопать? Нанимайте людей для решения ваших обычных задач, а не для интересных.
Разработчик хочет участвовать в новых проектах, а руководителю нужно, чтобы кто-то поддерживал уже имеющиеся.
Вот и переведите на имеющиеся проекты тех, кто готов их поддерживать. А на новые — тех, кто хочет пилить новые. Разве так сложно?
Разработчик не хочет заниматься ничем кроме разработки, а руководителю нужно, чтобы код был документированным, чтобы процесс разработки был прозрачным и управляемым, чтобы выполнялись планы, выдавались релизы и т.д. Для этого он просит давать оценки, проводит стендапы, ретроспективы, заставляет планировать свою деятельность.
То же самое: при найме сразу проговаривайте, что у вас не только разработка, а еще и выполнение планов, выдача релизов и т.д.
Разработчик хочет принимать решения самостоятельно (он же знает, как правильно), а руководитель требует, чтобы о выявленных проблемах сообщали ему, чтобы он мог проконтролировать принятие решения.
Микроменеджер? Давайте, до свидания.
Неудивительно, что многие руководители разработки имеют плохую репутацию среди своих разработчиков – они не дают делать то, что хочется, а наоборот, заставляют заниматься тем, от чего тошнит.Действительно, не удивительно. Люди просто не понимают, зачем их наняли (либо им врали на интервью?).
Ваш комментарий — отличная иллюстрация для данной статьи.
Про помыть пол и вскопать картошку — жирно.
Лол? Так и нанимайте тех, кто не хочет (не будет) узнавать новое. Проговаривайте это и в вакансии, и на интерью, тогда проблем не будетВидимо до конца прочитать не получилось, а ведь специально написал:
Думайте не только об успехе проекта, но и о развитии своих людей. Проектов много, пусть разработчики растут с каждым новым проектом. Займитесь регулярным обучением своих людей.
Посмеялся. Может, у руководителя еще и пол надо помыть, картошку вскопать? Нанимайте людей для решения ваших обычных задач, а не для интересных.Думаю мой посыл прошел мимо вас. Здесь идет речь о том, что в приоритете руководителя не развлечение разработчиков, а решение реальной задачи. А для этого иногда необходимо сосредоточено и невесело дебажить свой код, который в продакшене работает не так как надо.
Про помыть пол и вскопать картошку — жирно.
Вот и переведите на имеющиеся проекты тех, кто готов их поддерживать. А на новые — тех, кто хочет пилить новые. Разве так сложно?Поясню. Я утверждаю, что поддерживать проекты — полезно для карьеры разработчика. Кроме того, есть еще и понятие эффективности, и ваше решение — крайне неэффективно.
То же самое: при найме сразу проговаривайте, что у вас не только разработка, а еще и выполнение планов, выдача релизов и т.д.Любому, кто не школьник, это и так понятно. Но это не значит, что всем это нравится.
Микроменеджер? Давайте, до свидания.Банальный промежуточный контроль. Классика управления. Уверен, что вы в курсе.
В реальном мире все не так: вы нанимаете людей на конкретный проект, говорите, что копать вон там, вот и все. Когда всё вскопали, все расходятся. Если вместо этого вы направите людей, желающих копать глубоко, полоть траву, а желающих полоть траву — на археологические раскопки, то, конечно, о какой еще репутации руководителя может идти речь…
Еще раз — для кого неэффективно-то? И это не мое решение, так устроен мир разработки ПО.
Я утверждаю, что поддерживать проекты — полезно для карьеры разработчика.Представляю, приходите вы к Скотту Ханселману, и говорите: «привет, Скотт, для твоей карьеры будет полезно поддерживать кое-что, у нас тут проектик есть, не возьмешься?»
Кроме того, есть еще и понятие эффективности, и ваше решение — крайне неэффективно.
Еще раз — для кого неэффективно-то? И это не мое решение, так устроен мир разработки ПО.
- Для бизнеса очень даже эффективно, поэтому-то все ищут людей «с опытом», но надеются найти профессионалов, потому что им дашь им проект, они его и пилят и все.
- Для разработчика профессионального — тоже, ему сразу понятно, что от него требуется на проекте, и что он получит, завершив этот проект.
Любому, кто не школьник, это и так понятно. Но это не значит, что всем это нравится.Нормальные компании делают так, что все занимаются тем, что им нравится (и отсюда идут все эти KPI, карьерные цели, пути развития и т.п — просто хотят совместно выяснить, кто что хочет делать). А это нужно для того, чтобы люди были эффективны на 100%. Никто не будет эффективен, если занимается какой-то фигней, которая ему не нравится.
В реальном мире все не такВ моем реальном мире я не могу себе позволить набирать новых разработчиков на каждый проект — у проектов есть сроки, а найм — дело непредсказуемое. Кроме того, проекты сложные и если делать их каждый раз новой командой — будет или качество не очень, или денег компания не заработает.
приходите вы к Скотту ХанселмануЯ уверен, что Скотт на заре своей карьеры хоть что-то да поддерживал из того. что разрабатывал. Да и сейчас, если что-нибудь пишет в продакшен, не откажется пофиксить за собой. Профессиональная этика, все такое.
Нормальные компании делают так, что все занимаются тем, что им нравится (и отсюда идут все эти KPI, карьерные цели, пути развития и т.п — просто хотят совместно выяснить, кто что хочет делать). А это нужно для того, чтобы люди были эффективны на 100%. Никто не будет эффективен, если занимается какой-то фигней, которая ему не нравится.Было бы здорово, если бы это было возможно. К сожалению, это как идея коммунизма — на практике не очень работает. Всегда найдется дело, которым заниматься не очень хочется, но надо.
И если вам не трудно — приведите примеры «нормальных» компаний, где сотрудники занимаются только тем, что им нравится, и ничем другим.
И еще раз, если вы внимательно читали статью — она как раз про то, как найти компромисс между тем, что нужно и тем, что хочется.
НЛО прилетело и опубликовало эту надпись здесь
Приведу пример компании
Если не секрет — что за компания-то? Чем занимается? Сколько людей работает?
Вы встатье затронули только разработчиков
Я сам разработчик, и считаю себя в праве говорить только от лица разработчиков.
По моему личному опыту работы в нескольких компаниях от расцвета до момента когда всё начинало идти через одно место всегда происходили одни и те же события
Интересно, как это выглядело со стороны руководства.
Рискну предположить — сначала никто ничего не контролирует и сотрудники делают что хотят. Иногда это даже приносит компании успех. По мере роста компания вынуждена выстраивать какие-то процессы, появляется контроль и управляемость. Вчерашние супермены, которые принимали все решения сами, теперь подчиняются назначенному менеджеру («эффективному»). Естественно это им не нравится и происходит частичная или полная смена состава. К сожалению, этот путь практически неизбежен для компании, которая растет. Руководство может смягчить этот процесс, как-то договориться с теми, кто начинал. Но совсем избежать этого тяжело. Это болезнь роста, через нее надо пройти.
Помогу выделить суть предыдущего комментария:
Все, дальше снежный ком.
из за гибкой методологии уже появился техдолг
Все, дальше снежный ком.
Вы так говорите, как будто при водопаде не бывает тех долга. Гибкие методологии — всего лишь инструмент, как интеграл. Вы ведь не будете жаловаться на интеграл из-за того, что у вас расчеты не сходятся?
В комментарии был описан конкретный случай, мопед не мой(= Но и с моей колокольни, техдолг, когда тебе в спину дышит «цель спринта», возникает чаще, чем не возникает.
В моем реальном мире я не могу себе позволить набирать новых разработчиков на каждый проект — у проектов есть сроки, а найм — дело непредсказуемое.
А когда вы тогда собираетесь выделять разработчикам время на изучение новых проектов? Вы же понимаете, что делать новый проект на новых технологиях — как раз означает, что четкие сроки могут быть внезапно сдвинуты?
У нас сейчас обучение имеет непрерывный характер. Мы постоянно формируем группы и чему-то их учим. Новые разработчики в обязательном порядке проходят первичное обучение. В общем готовимся заранее.
Новые разработчики в обязательном порядке проходят первичное обучение.
Первичное обучение это не совсем то, что осваивание новых технологий.
Опять таки — чему учите эти группы? Можете назвать навскидку технологии, которые недавно изучили ваши сотрудники? И какие из них на текущий момент НЕ используются в проекте?
У каждого уровня сотрудников есть своя зона ответственности, масштабирования и отчетности. Таска, команда, проект, продукт, программа, департамент. Обычно закрытия происходят через одну вниз. Например, скрам мастер может легко закрыть таску. А продукт манагер закрыть команду. А програм манагер закрыть проект. И в сторону «открыть» тоже самое. Поэтому правила отношений начальник-подчиненный простые — бери больше и кидай дальше. Есть вопросы — задавай. Если ответа не будет — не серчай.
Что-ж, весьма разумная статья. Есть пара замечаний.
1. Разработчик должен помнить что успех бизнеса, в котором он трудится, важен в первую очередь для него самого: если компания грохнется из-за низкой квалификации разработчиков, низкого качества кода, который разработчик создаёт (например, плохо документированного кода), первым с протянутой рукой пойдет именно он. При сокращении в компании, почему-то управленцев как правило оставляют, а разрабов пинком под зад на улицу.
2. Есть сомнения в том, что нужно обучать разработчиков. Нет, это, конечно, гуманно и мило, но сейчас ты его научишь, а завтра он уйдет к конкурентам которые предложат на 5% больше к зарплате?
1. Разработчик должен помнить что успех бизнеса, в котором он трудится, важен в первую очередь для него самого: если компания грохнется из-за низкой квалификации разработчиков, низкого качества кода, который разработчик создаёт (например, плохо документированного кода), первым с протянутой рукой пойдет именно он. При сокращении в компании, почему-то управленцев как правило оставляют, а разрабов пинком под зад на улицу.
2. Есть сомнения в том, что нужно обучать разработчиков. Нет, это, конечно, гуманно и мило, но сейчас ты его научишь, а завтра он уйдет к конкурентам которые предложат на 5% больше к зарплате?
С пунктом 1 согласен на 99%.
С пунктом 2 — не согласен совсем. Дело не в гуманности. Я обучаю своих людей, чтобы они были более эффективны, быстрее и лучше решали поставленные задачи. Кроме того, это ценится разработчиками, а значит они более охотно будут со мной работать. А к конкурентам кто угодно может уйти и без обучения, таков сегодня рынок труда.
del
Мне одному кажется что в статье для разработчика указано, что он должен делать все, что хочет руководитель. А в пунктах у руководителя — за мелким исключением опять то, что хочет руководитель.
Давайте проверим:
КАК учить разработчиков. Новый проект для руководителя не означает смену технологий, ему нужно чтобы новый проект быстро запилили. Для этого лучше проверенные технологии.
Выделять им время?
То есть заставлять их вникать в бизнес
То есть заставлять их вникать в бизнес
То есть заставив их вникнуть в бизнес получить от них советы как его улучшить?
То есть заставляйте их работать пожестче, а тех кто сам себя заставляет хвалите?
Если возникли проблемы, не помогайте, сами справятся?
Простите, но я увидел сколько должен изменить в своем подходе разработчик и вообще не увидел, что должен изменить в своем подходе руководитель.
P.S. Я отлично понимаю что хочет руководитель, и в принципе согласен с тезисами. Но предполагалось, что статья покажет что обеим сторонам надо развиваться, иначе какой в ней смысл?
Давайте проверим:
Руководителю разработки
Думайте не только об успехе проекта, но и о развитии своих людей. Проектов много, пусть разработчики растут с каждым новым проектом. Займитесь регулярным обучением своих людей.
КАК учить разработчиков. Новый проект для руководителя не означает смену технологий, ему нужно чтобы новый проект быстро запилили. Для этого лучше проверенные технологии.
Выделять им время?
Объясняйте разработчикам потребности бизнеса и смысл задач, требований и процессов.
То есть заставлять их вникать в бизнес
Объясняйте важность процессов и следите за тем, чтобы им следовали.
То есть заставлять их вникать в бизнес
Прислушивайтесь к мнению разработчиков по улучшению процессов.
То есть заставив их вникнуть в бизнес получить от них советы как его улучшить?
Поощряйте ответственность и организованность.
То есть заставляйте их работать пожестче, а тех кто сам себя заставляет хвалите?
Позволяйте разработчикам самостоятельно решать возникшие проблемы.
Если возникли проблемы, не помогайте, сами справятся?
Простите, но я увидел сколько должен изменить в своем подходе разработчик и вообще не увидел, что должен изменить в своем подходе руководитель.
P.S. Я отлично понимаю что хочет руководитель, и в принципе согласен с тезисами. Но предполагалось, что статья покажет что обеим сторонам надо развиваться, иначе какой в ней смысл?
- Руководители не хотят учить разработчиков, а хотят чтобы проект запилили быстро — статья призывает их заняться обучением. Выделять время. Тратить деньги бизнеса.
- Руководитель сам "знает" как что делать — статья призывает прислушаться к разработчикам.
- Руководитель хочет сам принимать решения — статья призывает его делегировать разработчикам. Предварительно добившись от них понимания и осознанности.
- Руководитель хочет ставить задачи — а статья призывает его воспитывать в людях правильные установки.
Это вовсе не мелкие исключения, как мне кажется. Это дополнительная и непростая работа, особенно для тех, кто привык только "руками водить".
С другой стороны, может быть кто-то напишет статью — про карьеру руководителя глазами разработчика, и в ней будет несколько другой фокус.
Руководители не хотят учить разработчиков, а хотят чтобы проект запилили быстро — статья призывает их заняться обучением. Выделять время. Тратить деньги бизнеса.
Очень спорный момент про обучение, хотя тут конечно вопрос, что считать обучением.
Если «классичекий» вариант с отчитать курс по какой-то теме, то тут толку с моей точки зрения очень мало. Траты времени в никуда, потому что знания, которые ты не «пропустил через себя», не попробовал в боевой обстановке, мало ценны. Классические образовательные курсы могут быть конечно полезны для начинающих программистов (слово разработчик подрузамивает, что человек в состоянии еще и спроектировать решение), но для человека с минимальным опытом, а тем более для человека с инженерным мышлением это часто пустая трата времени. Мы живем все-таки в 21 веке, и доступность информации очень высокая, человек всегда найдет информацию по интересующей его теме, а вот если интереса нет, то никакие курсы этому не помогут. В конце концов высшее учебное заведение должно было развить только один навык — способность учиться самостоятельно.
Если мы говорим про развитие разработчиков, то тут более должен идти фокус на делегирование полномочий разработчикам (что в статье справедливо упоминается), на развитие ответственности за выпущенный продукт, идеальным вариантом (правда не всегда реализуемым) является, когда разработчик ведет полный цикл от общения с заказчиком и сбора требований до технической поддержки.
Но тут конечно, опять же, вопрос о бизнес модели, если это аутсосорс, где зачастую свободы действия мало, и нужна просто армия «роботов», то тут может и сработать вариант с классическим обучением, для быстрой пусконаладки «роботов». Для продуктовой разработки или другой, где есть устоявшиеся команды и отношения с заказчиком «классика» уже не в тему. Тут нужно развивать ответственность каждого конкретного разработчика и стимулировать институт менторства.
del
Вам просто необходимо прочесть недавнюю статью от Джоэла Сполски об абстракции для разработчиков. Но в кратце, вы пытаетесь убедить, что токарю, делающему деталь для ракеты нужен не только полный курс физики, но и фин обоснование проекта запуска спутника не только знать, но и разделять взгляды руководства этого проекта. Это абсурд.
П.С. И для корпоратива реально проблема, когда человек на позиции токаря оказывается по уровню главконструктором и отчаливает в свой стартап собрав все сливки из компании.
1. Уверен, что существуют разные точки зрения на эту проблему. Не думаю что одна статья, даже такого замечательного человека, сможет меня переубедить. Я уверен, что разработчики должны видеть картину в целом и понимать смысл.
2. Вы сейчас с легкой руки сравнили разработчиков и токарей, совершенно забыв, что в работе разработчика неопределенности на порядки больше. Уверен, что токарям крайне редко ставят задачу — «посмотри как мы делали это год назад в другом проекте и сделай также, что нужно поменяй». Я немного работал на заводе, и знаю как там все устроено.
3. Я сам довольно долго считал, что достаточно четко поставить задачу — а дальше пусть разбираются. Этот подход раз за разом приносил мне разочарование в человечестве. А вот когда я стал объяснять людям смысл — все заиграло другими красками.
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.”
К своему стыду статья Джоэла из 2006, просто наткнулся на ее перевод недавно.
Есть еще статья про боинги очень интересная.
Обратите внимание, как для ценности компании важно, что бы даже менеджеры полностью абстрагировались от того, что они делают. Как вы думаете, почему?
Можно долго и безрезультатно спорить насколько это все правильно и т.д. Я просто сокращу до минимума, а каждый может сам для себя решать.
Довольно крупному бизнесу (где работники — это статистика) важно что бы все сотрудники и само собой конечные актуаторы были легко заменимы и широко представлены на рынке труда. Все процессы владельцы бизнеса должны выстраивать исходя из этого.
Думаю, что такая формулировка дает понять где в этой системе ценностей понимания и одобрение целей и процессов компании рядовым сотрудником.
Есть еще статья про боинги очень интересная.
Обратите внимание, как для ценности компании важно, что бы даже менеджеры полностью абстрагировались от того, что они делают. Как вы думаете, почему?
Можно долго и безрезультатно спорить насколько это все правильно и т.д. Я просто сокращу до минимума, а каждый может сам для себя решать.
Довольно крупному бизнесу (где работники — это статистика) важно что бы все сотрудники и само собой конечные актуаторы были легко заменимы и широко представлены на рынке труда. Все процессы владельцы бизнеса должны выстраивать исходя из этого.
Думаю, что такая формулировка дает понять где в этой системе ценностей понимания и одобрение целей и процессов компании рядовым сотрудником.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что такое хорошо и что такое плохо. Карьера разработчика глазами его руководителя