Comments 179
Примадонна не приемлет руководства. Он рассматривают любую попытку руководства как оскорбление, поскольку он выше того, чтобы нести ответственность за свои действия.
Глупейшая ремарка. Как раз нежелание быть руководимым означает желание взять ответственность за свои действия на себя. Люди, боящиеся ответственности, всегда ищут руководящую руку.
Теперь, годы спустя, благодаря многолетним отношениям с основателями компании, он считает своё мнение выше мнения простого менеджера среднего звена.
Еще одна странная ремарка. Мнение о чем? У них разные зоны ответственности. Менеджер должен отвечать за то, как должен функционировать программный продукт, программист за то, какими программными путями этого добиться. Это не вопрос мнений, просто разные зоны компетентности.
Разработчик настолько одержим достижением архитектурной элегантности и совершенства кода, что забывает, что его работа должна приносить пользу бизнесу.
Здесь не может быть противоречий. Каким образом хорошая архитектура и совершенство кода может помешать бизнесу? Хороший код легче дорабатывать и отлаживать, это прямая помощь бизнесу. Если бизнес не понимает, что лучше потратить лишний день на хорошую архитектуру, вместо того, чтобы потом тратить 10 раз по полдня на доработки плохой, думаю «перфекционисту» стоит подыскать более умного бизнесмена.
PS В остальном очень жизненно. Спасибо. =))
Как раз нежелание быть руководимым означает желание взять ответственность за свои действия на себя
Это несвязанные вещи. Человек может противиться любому управлению собой, и при этом сваливать ответственность за свои действия на всех подряд. Пример такого поведения: типичный подросток.
Каким образом хорошая архитектура и совершенство кода может помешать бизнесу?
Хорошее — никак, идеальное/совершенное — тем, что на его воплощение требуется чуть менее, чем бесконечное количество времени.
Если у вас получается написать идеальную архитектуру быстрее, чем корявый код, что в принципе невозможно по определению, то вы либо вкладываете другие значения в эти слова, либо лукавите)Есть еще третий вариант — «написать код» было понято слишком буквально и имеется ввиду именно написание кода. Когда хорошая архитектура уже есть, то хороший код, особенно для сложного проекта, написать вполне может быть быстрее. Проблема именно в том, что для плохого кода не нужн планирование, которое отнимает гораздо больше времени чем собственно реализация.
Каким образом хорошая архитектура и совершенство кода может помешать бизнесу?
Элементарно. Если на них убита куча времени, и дедлайн безнадежно просран, то там уже пофигу, какая хорошая архитектура.
> В любом случае это проблема неправильного планирования ресурсов, а не перфекциониста.
Часто проблема перфекциониста неправильное планирование ресурсов (например, он не знает что для идеала в его понимании нужно бесконечное количество времени). И единственноправильным вариантом планирования будет отстранение перфекциониста (на старте или после таймаута). На то он и перфекционист, а не хороший разработчик.
В какой-то момент показалось, что я читаю не о взрослых людях а учебник колониального управления для белых британцев в странах третьего мира.
Меня такое каждый раз печалит.
Очень.
Мне хотелось сразу 3 комментария написать на нее)))
1. Автор как кот которому нечего делать начинает лизать… изучать программистов.
2. Это одна из «техник» как нагнуть программиста, и что даже техничка может управлять программистами.
Кстати про техничку это не шутка, была такая реальная методика и эта бы статья плавно бы вошла туда как отдельная глава )))
3.БРАВО!!! СУПЕР!!!
Чем больше будет таких учений, менеджеров которые им следуют, тем больше будет работы для Программистов и выше будут зарплаты!
Никто не отменял правило озвученное Бруксом несколько десятков лет в его книге «Мифический человеко-месяц».
Если Владельцу или менеджеру нравится гнобить программистов, тем лучше, стОящий и знающий программист может уйти в другую компанию и строить с нуля новую систему, на крайняк сделать свой стартап, а в компании в которой гнобят (нет нет, конечно же управляю программистами <ха-ха 3 раза>), вместо одного наймут 10, которые в конечном итоге угробят систему или будет стогнация.
Если менеджерам нужна «игра в управление», а по факту в гнобление с сокращением зарплаты, то еще существуют фирмы, где на первом месте стоит разработка ПО, его качество, отказоустойчивость, расширяемость, гибкое управление проектом, а не программистами. )))
Первый критерий программиста это его код(!), скорость, профессионализм.
Потом работа в коллективе (тк программист в одиночку писать высокопроизводительные библиотеки, сервисы), умение работать с несколькими программистами над одним проектом. Придерживание стандартам компании в написании кода и т.д. и т.п.
В статье озвучиваются ярлыки, но тот кто их навешивает сидит читает спецификацию по выходным? Дебажит сутки на пролет выискивая неточность? Днем и ночью продумывает архитектуру даже в ущерб своему здоровью?
Тот кто не любит программировать, но идет в программисты за деньгами, не выдержит никакой конкуренции с фанатами-профессионалами. Менеджер просто не в состоянии понять глубину знаний и без программистов он НИКТО! Пустышка с деньгами и огромным самомнением, что за пару тысяч ему будут лизать ботинки. Может в других сферах это так, но не у программистов к которым приходит волшебная палочка выручалочка -Интернет.
И сейчас все больше и больше команд основное время работает по удаленке.
Пусть менеджеры эту крысиную возню с ярлыками оставят для себя, написав себе эти ярлыки на бейджиках и приколят их к своей груди. )))
А мы будем писать код благодарному работодателю или для своего бизнеса, под пальмами у моря или в том месте где душа поет и из под пальцев выходит код который хочется поцеловать.
Боже мой, как вы делаете из мухи слона! Программисты уж какие-то суперлюди по Ницше. Вы можете себе придумывать что угодно, пока спрос на специалистов такой высокий, но по-моему лучше себя не обманывать и просто признать, что мы инженеры, просто в немного специфической сфере, которая отличается от классического инженерного дела (возможность быстро вносить измения, почти моментальный фидбэк).
И еще дополню.
Программирование часто изобретение чего-то нового.
Каждый изобретатель может быть инженером.
Но далеко не каждый инженер может быть изобретателем.
Изобретатель конечно плохой инженер, который «тупо верит»
( Блин в мемориз надо этот перл ))) )
Программист конечно же обычный скот который надо поставить в стойло, что бы не брыкался и зарплату не просил, ярлычок навесить и знать как пнуть больнее.
Зарплату в вашей конторе не снижают еще «опущенным звездам»?
Девиз висит «Не заменимых людей нет»?
«Верной дорогой идете товарищи» (с)
И я конечно же фантазер и обижаюсь, на кого, на вас?
Ой рассмешили, только мало. ))))
Как говорят? «Пиши исчо!»
Чем больше будут придерживаться менеджеры этой идеологии тем лучше.
Когда менеджеры сядут в лужу, не прав конечно останется только
Еще Крылов да-авным давно написал басню Квартет, как раз подходит под ваше управление.
PS:
Программист, когда ему становится не комфортно может сменить релокацию на любой город или страну не выходя из дома. Люди в команде могут не видеть друг друга годами, но при этом слаженно работать.
Пусть ваши менеджеры потешат свое ЧСВ ярлыками и методами «опускания звезд», если им не хватает мозгов управлять командой. Так как при разработке ПО другие ярлыки и оценки применяются.
Так что
Я консультант и работаю со многими организациями и да я «вершитель судеб» и таких как Вы и менеджмента, с крайне высоким КПД.
Незаменимых, действительно нет. Есть стоимость замены.
Большинство — простые ремесленники, начинающие визжать, когда только достал линейку, для объективных измерений. Устраивающие истерики при увольнении о их незаменимости, а потом отказывающееся забирать трудовую…
Я консультантЯ это понял )))
Незаменимых, действительно нет. Есть стоимость заменыЯ про это же.
Очень часто «стоимость замены» IT специалиста может не только о-очень больно ударить по карману владельцев бизнеса, но и уничтожить сам бизнес. И бизнес совершенно не относящийся к IT сфере. А у IT бизнеса риски еще выше при смене ключевых специалистов.
Кто не наступал на эти грабли, пусть наступает, каску им давать не обязательно )))
PS:
Из-за не грамотного админа или из-за не протестированного продукта простой в ОДИН день может вылиться в недополучении прибыли в десятки миллионов рублей.
2-3 дня таких в год и владельцы, которые умеют считать деньги понимают что принять «супер-звезду» с максимальной зарплатной планкой всегда выгоднее, чем иметь 10 середнячков, которые не в зуб ногой, не в…
Сегодня важно использовать ресурс который у тебя есть и если у тебя более ценный ресурс, то более эффективно его можно использовать. Новые библиотеки, архитектуру, алгоритмы, все что может «Головастик» ( это мой ярлык Специалиста с большой буквы). Что будет потом, то будет, потом и будем решать проблемы которые будут, а не которые мы придумываем в своей голове. Винтики нужны на конвейере, саппорте продукта, разработке мелких фич, но не на архитектуре проекта и не на ключевых ветках.
Ведь информационная разработка и поддержка это ряд методологий и правил сугубо технических. Если для менеджера важен продукт, его качество, расширяемость, поддержка, продвижение — это один порядок правил и методик.
Если для менеджера важно как выглядят IT специалисты, их манера речи, распорядок дня, стиль общения, их социальная мотивация то это другой ряд правил и методик, менеджеров которые бит от байта не отличают. Они с этими методиками хороши когда уже есть продукт с «жировой прослойкой» и устоявшаяся команда. Какое то время они будут управлять, могут даже увеличиться продажи, но в конечном итоге они обескровят команду, снизят мотивацию разработчиков и свалят на новое место, а контора за-агнется ибо Специалисты — штучный продукт. И даже высоко классному специалисту нужно время «въехать» во все тонкости существующего продукта. И срок «въезда» идет на месяцы, а ему зарплату все это время платят (возможно больше, чем ушедшему специалисту), а продукт стоит или клепаются только заплатки.
Для стартапа, когда надо творить их методика не подойдет, потому что продукт всегда штучный и в нем заложено все понимание главного разработчика (ов), как оно должно быть. И от уровня компетенции основного разработчика напрямую зависит жизнь продукта. Кто будет делать скелет? Команда винтиков или Головастик? Головастик в данном случае предпочтительней с любой стороны, как с финансовой, так и с технической. Да с ними трудно, да тяжело, но выхлоп результата значительно больше чем от винтиков.
Вот «эффективному менеджеру/консультанту» дать Х денег и срок, набрать команду, сделать продукт (все циклы силами набранной командой). Что бы он не пришел консультировать как руководить в команду, а пришел создавать ее с нуля. То в его голове что то бы и прояснилось.
Но только не подумайте, я не отговариваю от методологии технички с изучением проблемных личностей разработчиков, боже упаси.
Наоборот, пусть побольше таких менеджеров будут, после них растет зарплата. Потому что те кто считает деньги, они готовы принять на работу хоть дьявола с чертями, лишь бы увеличился доход.
А менеджеры пусть играют в свои крысиные игры )))
Если серьезно, то с точки зрения профессионализма есть градации и вы их знаете. Но сравнивать программиста и электриком в офисе просто глупо.
Любой мужчина в офисе может поменять розетку или лампочку от директора до дворника. Но посадите этих же мужчин за комп и пусть они сделают по ТЗ продукт. Вот и весь ответ.
Есть конечно конторы в которых программисты ремесленники, но в которых написаны тонны кода и применяются типовые решения или на двери табличка «Программист», а по факту за ней работает сисадмин.
И если у вас все работает и разрабатывать ничего не надо, я вам открою секрет. Вы можете уволить всех программистов и эффективных менеджеров в куче и забыть про них как страшный сон. )))
С точки зрения владельца бизнеса и тот, и другой — обычные наемные рабочие.
А что — электрик, это только лампочку менять? Про силовые кабели в 6кв что-нибудь слышали? В некоторых офисах разобраться в проводке и сделать так, чтобы все не сгорели, куда сложнее, чем по заранее известным алгоритмам писать программы.
Как вы относитесь к другому офисному персоналу? Офис-менеджер, например, либо HR?
Люди разные нужны, Люди разные важны.
И хороший HR и хороший электрик, как ген.дир и менеджер проекта ценны сами по себе. Но хороших специалистов к сожалению мало. А хороший специалист, он знает себе цену и не каждый будет терпеть подковерные гнобления.
И мне нравятся методологии которые раскрывают потенциал, позволяют более эффективно работать.
Ведь построение более эффективной работы IT отдела это более интереснее и полезнее, чем составлять список животных у себя в отделе и организовывать дрессировочные мероприятия.
Как то так.
Любой мужчина в офисе может поменять розетку или лампочку от директора до дворникаЯ не умею менять розетки. Разрабатываю продукт, которым пользуется половина населения Земли.
Не передёргивать, пожалуйста. Быть воспитателем в детском саду (менеджером) очень непростая задача. Не знаю какие вы задачи решаете, но я не вижу что такого "изобретательного" в том, чтобы дёрнуть за пару АПИ в правильной последовательности. Зато вижу, что надо это протестировать, написать логи и объяснить в документации почему надо дергать за эти два, а не те; что всегда и делали инженеры.
Автор, спасибо вам душевное за статью.
Спасибо — по нескольким причинам.
99% статей о разработчиках в контексте управления можно свести к одному тезису: “Как тяжело жить/решать задачи/доставлять ценность разрабу в условиях постоянно сопровождающих его внешних, отвлекающих факторов”.
Я, безусловно, чуть-чуть утрирую, но, почему-то, в подавляющем большинстве таких статей суть сводится к тому, как тяжело именно программисту. И задачи, чаще всего, не решаются или решаются с трудом, поскольку все время есть что-то, что отвлекает/не дает работать.
Причем, во многих из таких статей, как правило, виноват менеджер/бизнес/ или стейкхолдер, не пишущий код, а творящий вокруг себя хаос и разнообразный “микроменеджмент”.
А между тем, в адрес не-разработчика летят так им любимые “Я это делать не буду!”, “У меня все работает!”, “Ненене, мне пораньше уйти нужно — завтра задачки перетащу в code/review” и еще куча приевшихся, остоездивших фразочек из очередного стикерпака в телеграмме.
Одним словом — редко можно “проблемные статьи” о самих мастерах кода.
Это причина, скажем так, лирическая — о наболевшем.
И, поверьте мне, тут не работают аргументы в стиле “Да это просто чувак с нормальными кодерами работать не умеет, вот и слышит это постоянно”. Не работают т.к. с такими вот фразочками сталкивался далеко не один мой коллега из стана pm’ов, сейлзов, аналитиков и прочего так некоторыми нелюбимого комьюнити “не-программистов”.
Далее — о комментариях выше.
Уважаемый, AWSVladimir. Вас послушать/почитать, так это получается что у нас каждый 2й, если не 1й разраб — гений пера и кода, за которым просто очереди стоят и бизнес их носит на руках.
Менеджер просто не в состоянии понять глубину знаний и без программистов он НИКТО!
Естественно. Менеджер — это такая смесь интерфейса, вашей личной секретарши-напоминалки и пожаротушителя. Он — ничтожество. Просто потому что код не пишет.
Можно просто сказать: “Ты — менеджер? Иди пол мой и составляй свои доки, общайся на переговорах! Ты же — из стана бизнеса, подлец!”.
Вот здорово, правда? Вы же на работу ходите/растите свой бизнес исключительно ради кода, верно? ЗП/прибыль тут максимум на третьем месте.
В статье озвучиваются ярлыки, но тот кто их навешивает сидит читает спецификацию по выходным? Дебажит сутки на пролет выискивая неточность? Днем и ночью продумывает архитектуру даже в ущерб своему здоровью?
Позвольте, а кто бегает и улаживает косяки программиста, когда баг на баге? Кто согласовывает переносы срока и новые “подводные камни”, которые не были оговорены разработчиком, что называется, на берегу?
Конечно, всего не распознаешь заранее и не продумаешь. Так-то оно так. Только вот какая штука:
1. Обычно за описанное вами и платят деньги. Если речь идет о труде и задачах программиста. Это называется — зарабатывать деньги. Продумывать архитектуру (ой-ой-ой) в ущерб своему здоровью.
Вы не поверите, но в свой выходной/больничный/день свадьбы/похорон любимого котика руководитель проекта тоже может приходить в офис или, болея, с сизым горлом читать и писать доки, пересогласовывать новые сроки, улаживать тут и там возникающие пожары, просто потому что кто-то из ведущих программистов думал, что подойдет вот такое решение, а оказалось — что это не решение, а говно. А кроме того, там вообще айсберг пилить нужно.
За эту работу точно также платят деньги, как и вам.
А еще деньги платят за неудачные дни. Это когда исполнители косячат и нужно что-то порешать, как говорится, in-real-time. Потому что виноват же у нас, прежде всего, не исполнитель. А тот, кто так напланировал и надоговаривался. Просто по той причине, что “ПРОГРАММИСТ-НЕ-СОВЕРШАЕТ-ОШИБОК”.
… на крайняк сделать свой стартап
Да, у нас каждый второй — Ричард Хэндрикс с потенциально прорывной идеей и соткой пройденных посевных раундов. Ну вот сейчас, еще чуть-чуть, позвонит по скупе Уоррен Баффет или Юрий Мильнер и скажет: “Дружище! У нас для тебя ярд завалялся! Нам очень нужен очередной notepad! Это просто бомба!”.
Если менеджерам нужна «игра в управление», а по факту в гнобление с сокращением зарплаты, то еще существуют фирмы, где на первом месте стоит разработка ПО, его качество, отказоустойчивость, расширяемость, гибкое управление проектом, а не программистами. )))
Оукеееееей.
Г-споди, что вам за менеджеры-то попадались.
Вероятно, вы лучше меня знаете, что любой бизнес — это, прежде всего бизнес. Фундаментальная задача любого бизнеса — каким бы технологичным и легаси-ориентированным (уж простите за каламбур) он бы ни был — прибыль. Это банально, пыльно, пошло и зазорно, но это просто факт. Исходя из этого, в корне неверно полагать, что больше чем к 3-5% компаний в мире есть практически неисчерпаемые ресурсы и космический объем терпения у акционеров/собственников/наемного топа, который может бесконечно переносить выпуск в прод “гениальной архитектуры ради архитектуры”.
И сейчас все больше и больше команд основное время работает по удаленке.
Не хочется придираться и занудствовать, но…… откуда такое мнение? Есть пруфы? Все больше и больше по сравнению с чем/когда?
Я руководствуясь ровно такой же логикой могу утверждать, что еще лет 10-15 и появятся наконец решения, которые позволят создавать функционал движением пальца!
И нам больше не придется писать бесконечные доки и терпеть этих наглецов, которые понакодили вот-этого-вот-всякого! Просто потому что грядет время святых Цукербринов, которые вернут все на круги своя!
И, напоследок.
Вам не приходило в голову, что концепция “Заказчик-администратор/менеджер-исполнитель” существует далеко не первый год ровно по той причине, что не глупа и имеет право на существование?
Ну….просто так получается, что кто-то занимается решением конкретных задач и использованием технологий, а кто-то — планированием, распределением ресурсов, контролем и результатами производства?
Форд был не дурак, вероятно. И, возможно, вспоминать это в очередной раз было бы глупо, если бы это не было так актуально по сей день.
А вас послушать: ежкин кот, разработчик — это самая важная деталь организма под названием “Бизнес”.
Без фактических исполнителей, естественно, никакое производство, ни один механизм не сдвинется — это факт. Просто не стоит недооценивать и преуменьшать роль тех, кто по стечению обстоятельств не роется в коде.
А то создается ощущение, что вы — это один из персонажей описанных в статье.
ЕсВам не приходило в голову, что концепция “Заказчик-администратор/менеджер-исполнитель” существует далеко не первый год ровно по той причине, что не глупа и имеет право на существование?
Вот Вы реально в теме и реально крутитесь где создается ПО.
Я хотел сказать, что эта статья — крысиная возня и не имеет ничего общего с реальной разработкой. Программист — царь и бог на своем участке. Постановщик задач, тех лид на своем участке царь и бог, так же хелперы, тестировщики, даже тех.поддержка важна и часто от нее идут идеи оптимизации софта. И просто замечательно если на каждом участке есть Головастики.
Любая часть важна и требует уважения и благодарности, а не методологии «У них получился продукт, расправили плечи, улыбаются ждут что им повысят зарплату? Что они возомнили? Петухи, козлы, коалы (все они в верху на картинке), да вы же скот. В стойло скот, в стойло!»
Я про это.
У реальных Менеджеров работы выше крыши.(далее с большой буквы я говорю о монстрах-титанах-Менеджерах на чьих плечах лежит вся ответственность за проект) И своим я благодарен до земли. Сколько они работы проворачивают утрясая эти требования, хотелки, сколько пустой болтовни через них проходит, а на выходе только нужная выжимка необходимая для создания ПО.
На этом этапе Менеджер царь и бог, и конечно намного важнее любого программиста в команде, так как он задает основной вектор, оценивает рынок, затраты, риски. Программисты лишь исполнители. Да они боги на своем участке, но только в своем. И они не выше и не главнее Менеджеров, я хотел сказать что НИКТО это «крысиный менеджер». Он не то что в подметки не годится Менеджеру, это просто не совместимые вещи которые нельзя сравнивать.
И я глубоко уважаю Менеджеров с большой буквы которые выдают постановку как конфетку. У меня есть проекты на разработку которыми я восхищаюсь уже более 10 лет как они написаны, в них нет ни строчки кода, ни одного названия таблицы, но которое так написаны, что я ими восхищаюсь и я знаю, что если бы я захотел так грамотно и скурпулезно написать, я бы не написал. Я технарь, максимум тех.ТЗ на разработку.
Вот к Менеджерам я испытываю огромное уважение и понимаю «за что» им платят. Но я презираю «крысиных менеджеров», которые играют в свои социальные игры, напрочь не видят технической части. (прокомментирую, что бы опять не поняли привратно, техническую часть может видеть Менеджер гуманитарий, а «крысиный менеджер» может быть и с тех.дипломом их отличие Менеджер душу вкладывает в проект как в своего ребенка, а «крысиного менеджера» интересует только социальная возня).
Когда просто некое множество людей дробится на подмножества в соответствии с проявляемыми поведенческими паттернами — действительно наблюдаемыми среди этого множества! — это нормально.
То есть говорить, что в России все поголовно едят оливье на Новый Год — глупость.
Говорить, что россияне в НГ делятся на тех, кто ест оливье потому, что нравится, кто ест потому, что традиция, и тех, кто вообще не ест — вполне себе корректно.
Делить по паттернам поведения тоже не верный подход.
Все люди делятся на две категории: те, у кого револьвер заряжен, и те, кто копают. Копай.
Я ем оливье когда я хочу его есть. Т.е. преодически, меня нельзя отнести ни к какой категории. Я использую новые технологии, переодически. Довожу до идеала код переодичекски. Проявляю оптимизм или пессимизм тоже перодически и.т.д. стараюсь всегда смотреть по ситуации, относить меня к какой-то категории нельзя. А к чему призывает эта статья — увидели паттерн поведения человека. Поставьте на нем клеймо. И по этому клейму применяйте решение.
Все люди делятся на две категории: те, кто мыслит стериотипами, и те, кто умеют думать. Копай.
То есть говорить, что в России все поголовно едят оливье на Новый Год — глупость.
Отчего же? Почти все едят — не поголовно, конечно, но подавляющее большинство-таки едят.
Глупость — это говорить, что в России медведи по улицам ходят с балалайками, а Россию в иностранных фильмах показывать с музыкальным бэкграундом в виде мелодии баяна или балалайки непонятного происхождения. Но и та глупость по незнанию чужой культуры, наши стереотипные представления о других культурах будут выглядеть в их глазах не меньшей глупостью.
— большинство, это когда 40% едят оливье, 20% спят в оливье, 10% затрудняются ответить (раз на раз не приходится) и 30% не едят оливье.
Т.е. логике не будет никакого противоречия, если даже только эти 40% стабильно едят оливье на НГ — все равно получается самая большая группа из прочих остальных.
Если спросоня я не прав — прошу извинить.
Некомпетентный
…
Возможность исправления: нет
Тут меня, как человека с синдромом самозванца, ощутимо покоробило.
Я думаю, «aspiring manager» в данном случае не «честолюбивый менеджер» (он ещё не менеджер, а разработчик всё же), а «стремящийся стать менеджером» или «метящий в менеджеры».
Забейте в Google Translate «aspiring» — первое определние слова и пример:
>«directing one's hopes or ambitions toward becoming a specified type of person.
>»an aspiring artist""
Стороны разработчика софта и эксплуатации софта (часто с доработками) требуют совершенно разных подходов. Разный софт требует разных подходов (для примера можно выполнить мысленный эксперимент сравнивая oracle db, поделку на php и 1С). Кроме того, есть вполне актуальный торгуемый софт, чуть более чем полностью состоящий из легаси кода (тот же oracle db).
Например, даже в рамках одной компании могут быть условия, когда «прима» сильно мешает или наоборот, эффективно спасает проект (особенно, если техническая цена спасения проекта не особо важна). Впрочем, по каждому типу разработчика в этой классификации я могу привести как подтверждающий, так и опровергающий пример (видимо, как и большинство реально практикующих управленцев в ит).
Впрочем, статья хорошо написана и неплохо переведена. Как развлекательное чтиво, которое к тому же заставляет немного подумать — отлично.
Соглашусь с BD9 — заниматься подобным должен специалист. Только не психолог — их квалификация притча во языцех. Они, скорее, натурфилософы и пишут подобную галиматью.
Правы в общем то все комментаторы.
Например «Честолюбивый менеджер», из всего написанного, верно только:
Невозможно решить проблему честолюбивого менеджера, потому что он уже сделал чёткий карьерный выбор
Остальное — неверно, например, это может быть и разочаровавшийся «идеалист», (по этому предложенный пример работы с «идеалистом» спорен — может привести к подобным изменениям).
А выдавать плохой код (плохо работать)он может из-за исчезновения мотивации. Как из-за смены парадигмы, так и из-за выгорания.
«Солдатом» становятся многие после 30 — это связанно в основном с некоторыми физиологическими изменениями в человеке и частично с социальными.
Люди не должны работать сутками — это физиологически не возможно. Резерв по способности к переработкам индивидуален и то же не безграничен. В таких случаях проблема всегда в менеджменте, но в любой отрасли управленцев наказывают не охотно.
Это не касаясь таких проблем, как «отыгрыш» наказанных на подчинённых.
Метод внеочередных отпусков неплох, но работает только на уставших людях. На выгоревшем это не работает, с ним, лучше попрощаться.
Ну и т.д.
Метод внеочередных отпусков неплох, но работает только на уставших людях. На выгоревшем это не работает, с ним, лучше попрощаться.
Поматросить и бросить? Ну такое… оставшаяся команда быстро словит мессендж что ждёт их самих в будущем, когда они сломаются и выгорят.
могут скинуться ему на годовалый отпуск (и это минимум)
Человеку надо выдать все положенные выплаты по полной. В РФ это 3 мес. з/п + что набежало по отпускным
Т.е. уволить с явным осознанием того, что он не сможет позволить себе полное восстановление на выходное пособие?
В идеале, в организации должен быть специалист, который поставляет информацию менеджменту о состоянии сотрудников, что бы не допускать подобного.
Если бы я работал в вашей компании, то не позволил бы себе никаких переработок и авралов даже под угрозой увольнения.
Когда вам что-то надо (или вы не нужны)- это просто бизнес, ничего личного.
Не переживайте, я всегда на стороне справедливости. Просто так никого под увольнение не подводят, а все переработки оплачивают.
В европейских странах есть такое понятие как Саббатикал: https://en.m.wikipedia.org/wiki/Sabbatical
После нескольких лет работы на одну компанию она разрешает взять очень долгий (до 1 года) оплачиваемый отпуск и отдохнуть. Лично знаю людей которые так делали и мне эта идея тоже нравится
Спасибо вам и alexeykuzmin0 за пояснения!
При проявлении симптомов сотрудник должен идти/быть направлен к психиатру через психоневролога. Бояться психиатра не надо. Да, вы не псих, но отнюдь не здоровы. Адекватный специалист, как правило ставит на ноги за 6 — 10 сеансов. Редко, когда нужно больше. Как минимум, он должен найти источник.
Одним из направлений восстановления в любом случае будет длинный отпуск и занятие чем-то совсем другим. Возможно, сменить род деятельности придётся навсегда. Если повезёт, то только место работы.
Он действительно знает, как писать отличное программное обеспечение, и если ему дать достаточно времени, то сможет создать идеальную систему. Проблема в том, что он верит, что у него есть всё время в мире и полная свобода, хотя это далеко не так. Вместо того, чтобы найти компромисс, он сосредоточился на создании идеальной системы. Он считает, что это лучше для бизнеса.
Вот тут тонкий момент. Большинство людей, управляющих ИТ проектами, на моем опыте с легким сердцем ставят клеймо идеалиста на любом разработчике, которому не насрать на долгосрочную перспективу и который не хочет делать одну и ту же работу 10 раз. У них постоянно "заказчик хочет это вчера" и хоть трава не расти, а когда ты начинаешь объяснять, что кроме краткосрочной выгоды нас ждут тяжелые долгосрочные лишения, ты сразу идеалист и не понимаешь, как делать бизнес по-взрослому.
Иногда удается отвоевать немного времени на рефакторинг, но это как правило местечковое исправление некритичных участков, потому что времени дают всегда сильно меньше. Предсказуемо, это не дает сильного буста, потому что самые проблемные куски кода никуда не делись. Менеджмент же для себя делает вывод "Мы дали им время на рефакторинг, получили предсказуемый простой в развитии, но ощутимой выгоды нет". И с каждой следующей итерацией круг сужается — дают еще меньше времени, пользы еще меньше, а ты все больше идеалист, который всегда недоволен.
И они в свое время меня почти задавили числом, я был готов поверить. Но повезло, и я попал на проект, где "ежедневные коммиты" не были приоритетом. И все прошло как по учебнику: долгое планирование и компетентный архитектор обеспечили проект, где вообще не было форсмажоров. Внедрение нового разработчика в команду не было проблемой, равно как и его выход из команды.
Видел также прямо противоположную ситуацию: некомпитентный техлид и по совместительству интерфейс для заказчика за 3 месяца написания проекта с нуля породил легаси-монстра, как в плане архитектуры, так и в плане стабильности работы, я никогда не видел подобного. И каждый день на этом проекте проходил с девизом выкатить новую фичу как можно скорее, потому что заказчик ждет.
Самое смешное, что я случайно потом спалил, что этот техлид сам бежит впереди паровоза, и подгоняет кнутом, даже когда заказчик сказал, что понял риски и готов дать столько времени, сколько нужно.
До сих пор я так и не понял, как формализовать золотую середину между настоящим идеализмом и абсолютным отсутствием понимания долгосрочной перспективы, и уж тем более как продать потом эту середину менеджменту.
Но повезло, и я попал на проект, где «ежедневные коммиты» не были приоритетом. И все прошло как по учебнику: долгое планирование и компетентный архитектор обеспечили проект, где вообще не было форсмажоров. Внедрение нового разработчика в команду не было проблемой, равно как и его выход из команды.Немного смущает прошедшее время. Неужто проект оказался нежизнеспособен и сгинул в конкурентной борьбе?
Иногда удается отвоевать немного времени на рефакторинг, но это как правило местечковое исправление некритичных участков, потому что времени дают всегда сильно меньше.
Это всегда от ситуации зависит. Если проект заказной, заказчик часто не хочет или нет денег на это. Проект работает как-то, свои задачи выполняет, да и ладно. Или нет понимания, что «да там только пару полей добавить» тянет за собой еще шлейф изменений логики обработки. В таком случае за свои деньги переделывать проект для дяди никто не будет, возможна только косметика, как Вы пишите.
Если же проект свой и приносит хорошую прибыль, то можно реинвестировать и переработать.
Можно попробовать завоевать доверие менеджмента постепенно. Найти какие-либо easy win улучшения в проекте и попросить на них немного времени. Потом показать результат: «смотрите, как быстро мы запилили фичу X, а все потому, что мы заранее порефакторили вон там».
Постепенно, на каждой итерации можно выпрашивать побольше времени, пользуясь доверием, заработанным на прошлых этапах
А на другом уровне считаю за полноценных коллег только программеров, остальные для меня — умственные инвалиды от уборщицы вплоть до директоров. Но я этому уровню не даю прорваться наружу… в 99.99% процентах случаев.
Если директор твоей фирмы такой уж умственный инвалид — то почему тогда так получилось, что его зарплата отличается от твоей минимум на порядок, и что мешает тебе добиться в жизни того же самого?
Если честно, мне пофиг, кто там умнее-глупее. Главное чтобы эти умственные инвалиды не лезли в вопросы, связанные с проектированием ПО. А они пытаются это делать — вот только из-за этого я этот вопрос обсуждаю вообще. Не хватает чёткого знака — «Дальше умственным инвалидам ходить опасно!».
Вы — специалист в разработке, отлично, но при этом и на сам продукт, который вы разрабатываете вы смотрите со стороны творца, и можете не замечать насколько же он неудобный для конечного пользователя. Если на любые замечания вы реагируете высокомерным шипением «спасибо ваше мнение мне очень ценно, можете им подтереться, я лучше знаю как надо», то можете пропустить много интересного в жизни.
Как пример могу привести открытый софт линукса со всеми его «удобными» настройками всего лишь в десятке конфигурационных файлах разбросанных по системе и невнятным взаимодействием между разными компонентами против коммерчиского софта который зачастую ограничивает то, что пользователям позволяет настраивать. С точки зрения программистов получается очень странная картина — тот же почтовый сервер с календарем и резервацией комнат можно настроить своими силами на линуксе совершенно бесплатно, но большинство крупных и не только компаний покупают продукцию майкрософта, разработка которой велась не «программистами для программистов» и в проектированние которой влезали всякие «умственные инвалиды».
В общем — меньше снобизма, и жизнь будет лучше, и люди к вам потянутся.
Уборщица тоже лезет в вопросы проектирования ПО чтоб вы её за инвалидку считали?
В разработку ПО она и не лезет, зато частенько лезет мыть пол в серверной (со знакомыми многим админам последствиями)
С одной стороны всплывает в самые различные моменты «ну и рукожопы», а с другой стороны понимаю, что «снобизм, как соль, хорош в минимальных дозировках».
И «стиль настройки линукса» бесит, но «реализация MS» напрягает местами еще больше.
Это моя проф.деформация?
UPD: Отвечу сразу — да, живется мне порой «ой как не просто».
у них были причины сделать так
— Намеренное плохое UX в продуктах Atlassian путем принудительного сброса авторизации через N-часов (в разное время по разному, от 12 до 36) (толлерантное описание… но в голове одни маты). Был очень серьезный дискусс между представителями компании и сообществом, в результате которого таки удалось продавить «нашу» позицию. Но стоило это «тонны крови».
— Критические баги в google-драйвере (систематически)
— Ну очень плохой скайп
Это были отсылки к «миру IT-шников». Про «мир простых людей» я просто вообще не могу описывать ситуации — пригорает так сильно, что на луну ненароком улечу.
и изменения ради галочек
Не, ну Вы скажете, тоже. Они ведь деньги за это получают. Кто будет платить им бабосики, если они просто оставят то, что и так хорошо работает, и будут плевать в потолок?
habr.com/post/429018
Размер зарплаты зависит не только от профессионализма, но ещё и от рисков. Например, наркодилеры и проститутки получают больше, потому что рискуют своим здоровьем и свободой.
В случае директора — он рискует принять неверное решение и пустить фирму ко дну. В отличие от программистов, директоров так массово не нанимают, поэтому найти новую работу будет сложно, особенно с историей провала в послужном списке.
Идея не держать начальника за идиота вполне себе разумная.
А оспаривать более сложную технологию человек может, например, из-за того, что не умеет её готовить.
Есть вопрос в сложности алгоритма, ну например сортировка пузырьком, но будем честными современные технологии зачастую тяжелее.
Допустим человек может сделать все нативным sql запросом, а ему говорят используй ОРМ. Зачем если он может сделать все быстрее так, это будет работать быстрее и надежней?
Или он может сделать монолит, а ему говорят: микросервисы и кибернетес и блокчейн.
То же самое, несколько ранее, сделал движок казино.
Но на работе за деньги, я использую все эти ваши паттерны, SOLID, методологии и прочее-прочее. Кто платит — тот заказывает музыку.
Если есть более простая технология для решения проблемы, зачем использовать более сложную.
Потому что простой и эффективной она может казаться только вам, и зачастую из-за недостатка опыта.
я скорее докопался до слова «сложных». Если б было применено слово «эффективные технологии» или «производительные технологии»
Там же в кавычках, имеется в виду, что это такие сотрудники так называют более эффективные технологии.
Допустим человек может сделать все нативным sql запросом, а ему говорят используй ОРМ. Зачем если он может сделать все быстрее так, это будет работать быстрее и надежней?
Вот значит где собака порылась) Начнем с того, что раз "говорят", значит не вы отвечаете за продукт и его поддержку. Поэтому тот, кто отвечает, вправе решать, какие технологии будут лучше в долгосрочной перспективе.
Далее. Нативный SQL-запрос в большинстве случаев гораздо не надежнее при изменениях кода, и часто не быстрее из-за возможности lazy loading в ORM. ORM не в последнюю очередь используют из-за буквы R, маппинга связей между объектами. Это очень упрощает код. Поэтому да, используй ORM.
Ну еще раз, скажу — использовать надо то, что помогает тебе быстро и просто решить проблему, а не то что модно, молодежно, современно. У орм есть плюсы и минусы.
Я сам поклонник спринг дата, но тестить проще sql банальным копированием запросов в базу.
Вы экскаватор используете не ради его сложности, а потому что он производительный. Сложность — это его минус, с которой приходится мириться ради его производительности.
У вас почему-то сложность = производительность. Это отнюдь не так.
А представьте, что разработчик скажет: лопату к дрону присобачим, напишем машинное зрение, ИИ, блокчейн и подзарядку лазером на лету. Где сирень надо сажать?
Это, вероятно, и имел автор статьи. «Некомпетентный» разработчик — это не тот, кто против стрельбы из пушек по воробьям, но это тот, кто не используется более эффективные в каком-то конкретном случае инструменты, потому что для его понимания они «сложны».
Не всегда нужно исправлять человека, иногда нужно исправлять команду.
Я принципиально не беру листовки/флаеры на улице, не даю денег попрошайкам, отказываюсь от всех доп-услуг, режу рекламу, не пускаю бомжей в подъезд, не помогаю «деньги на операцию еще одному миллионному котику/воробушку/собачке». Все, я уже «плохой человек»?
Обычно люди «хорошими» называют людей которые такое же мировоззрение, как и они, используют. «свой» => «хороший».
Вы сейчас воды налили два ведра, совершенно непонятно, что конкретно вы хотели сказать. Я встречал людей, которые использовали подобные термины, имея ввиду примерно следующее:
- Отказался перерабатывать нахаляву — плохо относится к компании.
- Не хочет больше подтирать за одним и тем же сотрудником — нет эмпатии/соучастия
- Требует законный отпуск, хотя просят не уходить — не может войти в положение, выслушать
- Устал от бесконечных костылей, говорит, что время инкрементального рефакторинга давно упущено, теперь только выбросить и переписать, а продолжать так жить больше нельзя — истерит и закапывается в перфекционизм, не может предложить решение
- Разработчик объясняет срыв сроков тем, что руководитель проекта постоянно меняет требования в последний момент — не может взять ответственность на себя
Иными словами, в их понимании "хороший человек" — это тот, кто с улыбкой всегда прогнется под компанию и, желательно, чтоб делал это задешево.
Пожалуй дополню типичным случаем вне работы — ситуация с меркатильной женщиной (это важно)… если дотошный и внимательный мужчина быстро въезжает в формирующуюся ловушку и успевает дать задний ход («давай, досвиданья»), то он, почему-то, сразу становится «козлом».
«Козлом» становятся и в уже сформированных отношениях, когда, внезапно, мужчина перестает давать «ездить на себе, свесив ножки».
И для этого вовсе не требуется быть «плохим».
Да, это примерно так и работает. Когда с тебя можно что-то поиметь и ты позволяет это делать, ты – "хороший человек". Но стоит скинуть нахлебников со своей шеи – сразу становишься плохим. Иными словами "хороший"/"плохой" – это вообще не характеристика по сути, а способ манипуляции.
Мне много раз говорили, что как человек, я – говно. Я много над этим думал и пришёл к выводу, что мне говорят не совсем правду. Я слишком прямолинеен. И после того, как я указываю людям, что на самом деле говно – они, и даже обосновываю это, они обижаются и начинают считать говном меня… а потом своё дело делают расползающиеся слухи. И вот уже для окружающих я – говно, а все остальные двуличный твари, скрывающие свою настоящую личину – принцы на белых конях.
Поэтому при отклонении запроса на повышение у него остаётся только два варианта: встать в один ряд с другими разработчиками или уйти. В любом случае, ваша проблема решена.
Отрежьте пути выхода и ждите пока сотрудник станет послушным или будет вынужден уйти.
Пассаж про некомпетентных просто оскорбителен.
Читать такие советы печально, складывается впечатление, что со времен викторианских мануфактур менеджерский подход прогрессирует не очень сильно.
Рекрутёры будут звонить рок-звезде каждый день по несколько раз. Их репутация опережает их.
Телепатию уже изобрели, а я это пропустил…
Каким волшебным образом кто-то в другой компании узнает что «Я, три года тянущий проект на себе» — рок-звезда?
— Конференции? 9 из 10 рок-звезд не ездят на конференции, а работают над проектами.
— Руководство? Руководство рок-звезд делать больше нечего, как обсуждать с конкурентами своих программистов. Тем более что чаще руководство тупо ничего не знает о винтиках в своей организации. А рок-звезда — ровно такой же винтик. Просто большой и мощный.
— Коллеги? Ага, коллегки программисты идут бухать с руководителями соседних компаний и там рассказывают о человеке, который делает всё работу в их компании.
— Телепати! Вот как они узнают, не иначе.
я сам сейчас работаю по рекомендации предыдущего работодателя, а пред-предыдущее место получил от товарища по форуму.
Но это обычная текучка через знакомства. Совсем не война за голову, как описано в статье.
С аргументацией, что «купить можно всех». Речь шла о том, что ко мне придут и купят меня и проект через меня.
Это я к тому, что на уровне руководства никто о ценных сотрудниках болтать не будет.
А на уровне рядовых разработчиков тем более — есть темы и поинтереснее чем «мой коллега Вася такой крутой спец!»
Каким волшебным образом кто-то в другой компании узнает что «Я, три года тянущий проект на себе» — рок-звезда?Значит, Вы и не рок-звезда :) Рок-звезд хорошо знают
Рок-звезд хорошо знают
Через телепатию?
P.S.
Это я вам «тонко» намекаю на то, что не плохо было бы уже раскрыть, каким волшебным образом компании конкурентов узнают о существовании крутых спецов у своих противников.
А если про вас не знают — значит, вы и не знамениты :)
А Кармак — он в первую очередь владелец, также как Гейтс, например. Лицо компании.
НУ и кстати, с Кармаком сделаи провальный Rage, а без Кармака выстрелевший Doom. Так что большой вопрос, является ли Кармак сейчас рок-звездой(в терминах разработки, а не известности).
P.S. Ну и в целом вы ерунду пишите, рок-звездность не связано с размером компании. Рок-звездность — это уровень квалификации и способностей. Такие люди работают в самых разных компаниях. Опять же — прочитайте внимательнее раздел про рок-звездв в статье.
Да, вот я вижу — рок звезда это тот кто тащит и кто известен.
Я вот целиком определение привел, покажите там слово, в котором вы увидели «известность»:
Разработчик настолько талантлив, настолько продуктивен, настолько важен, что если он уйдёт, весь проект рухнет.
А она есть, пойдем от противного — Билл Гейтс, Павел Дуров,…
— Телепати! Вот как они узнают, не иначе.
Телепати — это вечеринка телепатов, что ли?
Ждем похожую статью про типы менеджеров и всякого рода управленцев среднего звена.
… поскольку им приносит удовлетворение именно сам процесс, а не цель
Счастливые люди
В каждом из психотипов нашел частичку себя. Учту)
Кому вопрос интересен более развернуто — я подчерпнул много здесь: evo-lutio.livejournal.com
Например взгляд на менеджера со стороны разработчика?
Например лично я считаю что менеджеры только мешаются в разработке.
Блин, у меня и так проблемы с самооценкой и я прошу всегда мало денег. А тут ещё такое. Теперь я считаю, что вообще не достоин работать и получать даже то, что мне платят.
Этот пост вообще мою самооценку снизил. Ну за что же вы так. И что же мне делать теперь.
Блин, у меня и так проблемы с самооценкой и я прошу всегда мало денег.
Давай, каждый раз, перед тем, как просить денег, ты будешь звонить/писать мне. Я буду тебя подбадривать — ты будешь просить больше и ещё 10% сверху накидывать для меня.
проблемы с самооценкой и я прошу всегда мало денегСтандартная рекомендация — иметь два оффера. Пусть торгуются между собой, а не с вами.
программисты такие же люди как и все, со своими тараканами
К сожалению, так же как нельзя быть полуграмотным кардиохирургом или частично компетентным пилотом, никто не может быть лишь частично компетентным разработчиком программного обеспеченияКакие правильные слова — именно!
aanechaev.livejournal.com/239663.html
Вчера я летел из Москвы в Берлин. На подлете капитан корабля порадовал нас, что в германской столице хорошая погода, но еще минут через 10 начали твориться чудеса. Вместо посадки самолет стал кружить над аэропортом, а командир сообщил, что мы не можем сесть по погодным условиям и должны ожидать посадки в воздухе. Пару раз пилот вроде пытался сесть, но потом с натужным ревом двигателей машина вновь взмывала в небо. Согласитесь, не самые приятные ощущения.
В итоге этих экспериментов капитан корабля уведомил нас, что сесть мы не сможем и полетим в Прагу, что и было проделано.
Дальше началось самое интересное. После посадки пассажиры с доступом к интернету без труда выяснили, что самолеты других авиакомпаний прекрасно приземлялись в том же аэропорту Шенефельд Берлина до и после наших попыток. В Праге нам заменили пилотов. При замене удалось перемолвиться с летчиками парой слов. И выяснилось, что летчики нашего экипажа просто плохо умеют пилотировать самолет. Ну, конечно, не совсем не умеют (хотя при посадки в Праге они так грохнули машину о полосу, что и подобное подозрение имело под собой основание). Просто на этой модели самолета они не имеют опыта садиться в тумане, который опустился на Берлин. Летчики других авиакомпаний имеют, а наши нет. Справедливости ради замечу, что новый экипаж в тот же туман в Берлине все-таки сел.
Что касается хирургов — про кардио не знаю, а вот в онкохирургии — весьма разные есть. А истинный уровень хирурга понятен только коллегам.
Вот кстати история про плохого хирурга — со всеми объяснениями:
www.anekdot.ru/id/977482
В общем… все люди — в каждой профессии, и никто не идеален.
habr.com/company/tuturu/blog/425983
Проблемные личности среди разработчиков