Комментарии 344
В целом статья клёвая, но вопрос вот возник: почему наниматель хочет, чтобы разработчик чувствовал себя совладельцем компании (то есть задумывался о том, как компания получает прибыль), будучи при этом на зарплате? Может быть, я не вполне верно прочитал то, что здесь написано?
Это как будто не совсем тот аргумент. Достаточно просто требовать от разработчика общей адекватности. Задачу поставили — выполняй, если не можешь обосновать невозможность.
Разработчикам полОжить на прибыль компании и её планы. Об этом замечательно писали ещё Демарко и Листер. И там же, они же: разработчика намного сильнее мотивирует идея гордиться своей работой, чем призрачные миллионы, которые заработает компания.
На всякий случай: сейчас пишу код каждый день. Ни разу не помню, чтобы что-то реально было невозможно реализовать. Бывает, что невозможно реализовать быстро или красиво, но это отдельная история.
Это как будто не совсем тот аргумент. Достаточно просто требовать от разработчика общей адекватности. Задачу поставили — выполняй, если не можешь обосновать невозможность.
Разработчикам полОжить на прибыль компании и её планы. Об этом замечательно писали ещё Демарко и Листер. И там же, они же: разработчика намного сильнее мотивирует идея гордиться своей работой, чем призрачные миллионы, которые заработает компания.
На всякий случай: сейчас пишу код каждый день. Ни разу не помню, чтобы что-то реально было невозможно реализовать. Бывает, что невозможно реализовать быстро или красиво, но это отдельная история.
Честно говоря, я даже не знаю финансовых показателей компании за исключением зарплаты.
Да вы правы, деньги не мотивируют. И я не имел в виду мотивирование деньгами.
Наши разработчики хороши, код хороший, да и самому интересно писать код и люблю хороший код. Статья о векторе приложения усилий и личной эффективности: куда направить свои усилия. (При прочих равных, при одинаково хорошем и радующем глаз коде)
Одной фразой статью можно пересказать так:
Problem Solving Skills for Russians. Introduction.
Да вы правы, деньги не мотивируют. И я не имел в виду мотивирование деньгами.
Наши разработчики хороши, код хороший, да и самому интересно писать код и люблю хороший код. Статья о векторе приложения усилий и личной эффективности: куда направить свои усилия. (При прочих равных, при одинаково хорошем и радующем глаз коде)
Одной фразой статью можно пересказать так:
Problem Solving Skills for Russians. Introduction.
Соглашусь, что самый крутой проблем солвинг скилл — это начать решать проблему задачу. :)
Хм… как бы я ни сочувствовал проблемам своих нанимателей, мои проблемы (хорошо выполнить свою работу) мне важнее.
Вы так и не ответили — зачем же тогда все эти слова про прибыли компании? Меня бы это только раздражало.
Вы так и не ответили — зачем же тогда все эти слова про прибыли компании? Меня бы это только раздражало.
Вроде понятно написано:
Нам премию надо заработать. Да, в прямом смысле слова. Мы все должны работать и создать условия, чтобы клиент принёс нам деньги. Именно из них зарплата и премия будут!
Я не хочу об этом думать на работе. Даже не знаю, как объяснить…
В процессе программирования нет никаких денег. В коде нет денег. Деньги есть только в день зарплаты.
Есть важные задачи. Важность задачи определяет наниматель. Сложность задачи (время) определяет исполнитель.
Целесообразность делать задачу сложности X и важности Y определяет наниматель. Всё. Никаких денег.
В процессе программирования нет никаких денег. В коде нет денег. Деньги есть только в день зарплаты.
Есть важные задачи. Важность задачи определяет наниматель. Сложность задачи (время) определяет исполнитель.
Целесообразность делать задачу сложности X и важности Y определяет наниматель. Всё. Никаких денег.
Вот про эту особенность русских программистов и написана заметка.
Если так, то хотелось бы объяснений: чем это хорошо или плохо. А то сейчас выглядит как «они не хотят делать то, что я им велю». Суть проблемы (что было в голове у разработчика) совершенно не раскрыта. Может, для программиста эти просьбы звучали как «нужно сделать телепорт, это же принесет нам кучу денег».
:) если дали лопату, миллион долларов и сказали копайте яму 3 на 5 метров и глубиной 10 метров. То надо копать яму, а не рассуждать об интересности задачи, о способах держать лопату, об подходящей конструкции черенка, об эффективности ямы…
Если выкопать яму мешает состав грунта или погодные условия, то надо предложить способы и сроки создания ямы иначе (например, пригнать экскаватор)…
Увы, у нас просто начинают говорить, что грунт мерзлый, черенок не такой и вообще, я ни чего не хочу решать, я хочу зарплату. :(
Если выкопать яму мешает состав грунта или погодные условия, то надо предложить способы и сроки создания ямы иначе (например, пригнать экскаватор)…
Увы, у нас просто начинают говорить, что грунт мерзлый, черенок не такой и вообще, я ни чего не хочу решать, я хочу зарплату. :(
Да к черту яму! Вы, видимо, ради денег живете, а у меня более широкий спектр потребностей. Деньги — это только нижние два уровня пирамиды Маслоу. Жить по схеме «сказали копать — копай» можно только если работа воспринимается неприятной обязаловкой. Да, есть компании со строгой иерархией, где собрались люди, которым такое подходит. Но не нужно распространять эту идею на всех подряд.
Увольнения программистов, описанные в посте, автор воспринимает как наказание, а я воспринимаю как благо: может, они найдут себе работу, с которой получится наладить более гармоничные отношения.
Увольнения программистов, описанные в посте, автор воспринимает как наказание, а я воспринимаю как благо: может, они найдут себе работу, с которой получится наладить более гармоничные отношения.
Работа всегда должна восприниматься как средство получения денег. Если работу выполнять не профессионально, если не развиваться, то денег будет мало, а может и вообще не будет, как и не будет работы.
А все остальное реализуется в реальной жизни: вырастить детей, отдохнуть, заняться заняться оригами, созерцанием и рыбалкой будет возможно только, когда есть достаточно денег.
Э… Жаль, вряд ли подискутирую дальше, работа :).
А все остальное реализуется в реальной жизни: вырастить детей, отдохнуть, заняться заняться оригами, созерцанием и рыбалкой будет возможно только, когда есть достаточно денег.
Э… Жаль, вряд ли подискутирую дальше, работа :).
То есть, работа — это жизнь нереальная. Может, даже вообще смерть.
Работа — это только работа. Кто то на работе «клинится», и кроме работы ни чего в жизни не видит. Кто то считает, что работа — это всего лишь часть жизни, которая приносит благополучие. Так что прилеплять какие то ярлыки типа «вообще смерть» и прочую ерунду не стоит. Я в идеологическую болтологию не играю.
А разве вы не встречали профессионалов, которые любят свою работу?
Я вот вообще работу сменил с неинтересной на интересную для меня с ухудшением соц. пакета и уменьшением ЗП. И мне нравится. Я развиваюсь в интересные мне стороны и при этом имею возможность за деньги свои навыки применять. Сильно нужны деньги — нашел подработку. Не нужны — работаю и учусь.
Мне интересно, а нанимателю хорошо.
Я вот вообще работу сменил с неинтересной на интересную для меня с ухудшением соц. пакета и уменьшением ЗП. И мне нравится. Я развиваюсь в интересные мне стороны и при этом имею возможность за деньги свои навыки применять. Сильно нужны деньги — нашел подработку. Не нужны — работаю и учусь.
Мне интересно, а нанимателю хорошо.
А я говорил, что не люблю работу? :)
Я могу любить кота, но это не значит, что своему коту я буду посвящать все свое время и ставить его превыше всего остального.
А насчет зарплаты и соц. пакета… Ну достаточно завести семью, стать родителем, что б понять, что деньги и соц.пакет, мягко говоря, решают многое. И уходить с большего на меньшее уж точно не будете.
Я могу любить кота, но это не значит, что своему коту я буду посвящать все свое время и ставить его превыше всего остального.
А насчет зарплаты и соц. пакета… Ну достаточно завести семью, стать родителем, что б понять, что деньги и соц.пакет, мягко говоря, решают многое. И уходить с большего на меньшее уж точно не будете.
Если вы устроились то до увольнения не решать поставленные задачи — все равно что ссать в компот на кухне. Разработка — это как командная игра. Если же такой махровый индивидуалист то зачем устраиваться в команду?
Яму копать — неинтересно. Может, черт с ней и с деньгами за неё?
Если дали лопату, миллион долларов и сказали копайте яму 3 на 5 метров и глубиной 10 метров, то надо по возможности мягко донести до нанимателя, что он идиот, и заказать экскаватор, который выроет этот котлован ;)
Если нанимателю сказать или намекнуть (пусть даже очень корректно), что он идиот, то миллиона вы точно не увидите. :)
А с водителем экскаватора еще и делится придется. :) Экскаватор — это исключительная ситуация, которая должна обрабатываться отдельно. :)
А с водителем экскаватора еще и делится придется. :) Экскаватор — это исключительная ситуация, которая должна обрабатываться отдельно. :)
Ну во-первых, воображаемый миллион мне уже воображаемо дали, а во вторых — даже если на найм эксковатора уйдёт 500к — я лучше убью этот год другим, более интересным образом.
К слову — многие забывают, что на работу тратится время. Не абстрактное время в виде 8/5, а вполне весомое время жизни. Я вполне готов оплатить 500к водителю экскаватора, потому что таким образом я сохраню себе время жизни, которое я смогу потратить на саморазвитие/семью/любимую работу и так далее.
Вы держали в руках полмиллиона долларов? И смогли б их отдать? Или так, ради красного словца?.. :)
Речь идёт об оптимизации затрат ресурсов. Всех ресурсов, а не только материальных. Свое время это тоже ресурс и как бы не самый важный. 10 лет в режиме 8/5 копать яму лопатой или отдать полмиллиона долларов экскаваторщику ( а другие полмиллиона ставить себе), чтоб он выкопал её за неделю — для меня выбор очевиден. «Заработать» (не работая) полмиллиона за неделю лучше чем заработать миллион за 10 лет :)
Странно, фигурируют то «год», то уже «10 лет», хотя сроков изначально озвучено не было :)
А тем временем это ключевой момент! Если речь идёт о том, чтобы сэкономить год, отдав экскаваторщику полмиллиона долларов, то это глупо. Вы заработаете за этот год полмиллиона на вашей основной работе? Вряд ли. А тут вполне реальная возможность.
А вот если речь о 10 годах, тогда это вполне имеет смысл, т.к. за эти 10 лет вполне можно заработать и больше, поэтому горбатиться с лопатой смысла нет.
Теперь смотрим на задачу: яма 3х5 метров и глубиной 10 метров = 150 кубометров. Не спеша, по кубометру в день — это 7.5 месяцев по 5 дней в неделю, с выходными и праздниками.
Мой ответ: да, я лучше заработаю миллион за 7.5 месяцев, копая по кубометру земли в день, чем полмиллиона моментально, но ни хрена не делая, т.к. «более другим способом» я полмиллиона за 7.5 месяцев вряд ли заработаю, а физический труд у меня совершенно не вызывает отторжения.
А тем временем это ключевой момент! Если речь идёт о том, чтобы сэкономить год, отдав экскаваторщику полмиллиона долларов, то это глупо. Вы заработаете за этот год полмиллиона на вашей основной работе? Вряд ли. А тут вполне реальная возможность.
А вот если речь о 10 годах, тогда это вполне имеет смысл, т.к. за эти 10 лет вполне можно заработать и больше, поэтому горбатиться с лопатой смысла нет.
Теперь смотрим на задачу: яма 3х5 метров и глубиной 10 метров = 150 кубометров. Не спеша, по кубометру в день — это 7.5 месяцев по 5 дней в неделю, с выходными и праздниками.
Мой ответ: да, я лучше заработаю миллион за 7.5 месяцев, копая по кубометру земли в день, чем полмиллиона моментально, но ни хрена не делая, т.к. «более другим способом» я полмиллиона за 7.5 месяцев вряд ли заработаю, а физический труд у меня совершенно не вызывает отторжения.
Ваш расчёт времени не учитывает глубину… Тут, если Вы не Геракл, чтобы подкидывать землю на 3, 5, 10 метров в высоту, придётся делать какую-то вспомогательную «полуяму» (она же выход), а потом её ещё закапывать обратно. В любом случае каждый последующий метр продвижения вглубь будет существенно медленнее предыдущего (сложнее выкидывать землю, грунт более твёрдый и т.п.). Т.е. сложность с глубиной растёт практически экспотенциально… а значит для одной лопаты получится скорее всего не меньше 3 лет, если на первый метр в глубину нужно 0.75 месяца
Вы погреб никогда не копали? ;)
Не нужно на 10 метров высоту кидать. Корзина, блок, лебедка, помощник (справится и тинейджер) — и все дела. Вход-выход тоже не нужен, хватит банальной лестницы. Так что не будет никакого экспоненциального нарастания сложности.
Не нужно на 10 метров высоту кидать. Корзина, блок, лебедка, помощник (справится и тинейджер) — и все дела. Вход-выход тоже не нужен, хватит банальной лестницы. Так что не будет никакого экспоненциального нарастания сложности.
Плотность грунта все равно нарастает и трудоемкость копки сильно растет. Особенно в плотных, глинистых грунтах, там уже с метра-полутора копать становится значительно тяжелее.
Кроме того, 10 метров это в большинстве случаем ниже уровня верховых грунтовых вод, что может сделать копку человеком сильно затрудненной или невозможной.
Кроме того, 10 метров это в большинстве случаем ниже уровня верховых грунтовых вод, что может сделать копку человеком сильно затрудненной или невозможной.
Корзина, блок, лебедка, помощник (справится и тинейджер)
Ну если по условиям можно докупать оборудование и нанимать сотрудников, то проще нанять экскаваторщика :-)
Да и нарастание сложности ваша схема не отменяет, очевидно же, что поднять руками кубометр земли с помощью корзины, блока и лебёдки на 2 метра и на 10 метров — это совершенно разные по трудоёмкости задачи.
>Да и нарастание сложности ваша схема не отменяет, очевидно же, что поднять руками кубометр земли с помощью корзины, блока и лебёдки на 2 метра и на 10 метров — это совершенно разные по трудоёмкости задачи.
Вообще я имел в виду механическую лебедку (отсюда и тинейджер), так что нарастать будет только время подъема, которое составляет меньшую долю от общего времени, т.к. львиная доля приходится на непосредственно копание.
Вообще я имел в виду механическую лебедку (отсюда и тинейджер), так что нарастать будет только время подъема, которое составляет меньшую долю от общего времени, т.к. львиная доля приходится на непосредственно копание.
ну началось xD
сначала ему механическую лебёдку и помощника подавай… потом ещё и отбойный молоток, чтобы грунт разрыхлять и если камень на полтонны попадётся, целиком его не вытаскивать и т.д. и т.п… неинтересный мысленный эксперимент получается.
сначала ему механическую лебёдку и помощника подавай… потом ещё и отбойный молоток, чтобы грунт разрыхлять и если камень на полтонны попадётся, целиком его не вытаскивать и т.д. и т.п… неинтересный мысленный эксперимент получается.
А где было условие «одной только лопатой и в одиночку»? Вроде не было, так что я волен выбирать способ реализации проекта самостоятельно.
>неинтересный мысленный эксперимент получается.
Он стал неинтересным сразу после того, как начали придумывать и добавлять дополнительные условия, не оговоренные изначально. Разумеется, если продолжать добавлять условия, то в конечном итоге обязательно получится так, что дешевле нанять субподрядчика с экскаватором. Вам от этого легче станет? :)
Но самое интересное то, что если скатываться в обсуждение «а вот если копать нужно будет на берегу моря на линии прибоя, то надо будет еще бетонную стену-волнолом ставить, и саму яму делать в виде бетонного мешка», то при этом совершенно теряется основной поинт моего изначального комментария: иногда выгоднее «миллион, но придется некоторое время поработать самому», чем «полмиллиона, но на халяву и прямо сейчас».
>неинтересный мысленный эксперимент получается.
Он стал неинтересным сразу после того, как начали придумывать и добавлять дополнительные условия, не оговоренные изначально. Разумеется, если продолжать добавлять условия, то в конечном итоге обязательно получится так, что дешевле нанять субподрядчика с экскаватором. Вам от этого легче станет? :)
Но самое интересное то, что если скатываться в обсуждение «а вот если копать нужно будет на берегу моря на линии прибоя, то надо будет еще бетонную стену-волнолом ставить, и саму яму делать в виде бетонного мешка», то при этом совершенно теряется основной поинт моего изначального комментария: иногда выгоднее «миллион, но придется некоторое время поработать самому», чем «полмиллиона, но на халяву и прямо сейчас».
иногда выгоднее «миллион, но придется некоторое время поработать самому», чем «полмиллиона, но на халяву и прямо сейчас».
В том-то и дело, что «иногда», да и понятия «выгода» на самом деле субъективно, а не просто $/час.
>В том-то и дело, что «иногда»
Спасибо, Кэп! Но никто вроде бы и не утверждал обратного, или я что-то пропустил?
Спасибо, Кэп! Но никто вроде бы и не утверждал обратного, или я что-то пропустил?
А тем временем это ключевой момент! Если речь идёт о том, чтобы сэкономить год, отдав экскаваторщику полмиллиона долларов, то это глупо.
Тут слова «иногда» нет. А допуская «иногда» сроки становятся уже не ключевым моментом, вернее могут быть ключевым, а могут быть и нет — не всё сводится к $/час(день-месяц-год). Вот лично я бы сейчас предпочел полмиллиона здесь и сейчас, ничего практически не делая, чем миллион через год, копая этот год землю. Или даже год ничего не делая. Кроме всего прочего — полмиллиона выведет меня на новый уровень качества жизни, а миллион (по сравнению с полумиллионом) — нет.
Дочитайте, пожалуйста, абзац до конца и не выдергивайте фразу из контекста. Спасибо.
Перечитал до написания коммента, сейчас ещё раз перечитал. У вас основной аргумент — «я полмиллиона не заработаю за год, потому лучше землю год копать буду, чем отдам его экскаваторщику». Но такой аргумент действует не всегда. Не всё упирается в $/час.
Вы таки упустили кое-что: это был мой основной аргумент в тех конкретно условиях: не напрягаясь, по кубометру в день. При этих условиях я согласен копать и заработать полмиллиона долларов за 7.5 месяцев вместо того, чтобы отдать их экскаваторщику. Как только условия меняются — меняется и моя готовность. Так понятнее?
А где было условие «одной только лопатой и в одиночку»? Вроде не было, так что я волен выбирать способ реализации проекта самостоятельно.На мой взгляд, оно неявно предполагается отказом от экскаватора. Т.к. если есть свобода выбора способа реализации, то в чём смысл выбирать способы XIX века?
начали придумывать и добавлять дополнительные условия, не оговоренные изначальноОбычно в реальных проектах так и бывает… )))
теряется основной поинт моего изначального комментария: иногда выгоднее «миллион, но придется некоторое время поработать самому», чем «полмиллиона, но на халяву и прямо сейчас».Получается, Ваш основной поинт по сути в том, что иногда наёмный труд (самому копать X лет) выгоднее, чем высокодоходный бизнес (делегировать рутинную работу и забрать очень хорошую прибыль). Думаю, мало кто с этим согласится.
Просто Вы рассматриваете получение подобного заказа как случайность, а это скорее искусство продавать услуги на несколько порядков дороже, чем они стоят. Обладая таким умением, тратить время на копание ямы явно нерационально, невыгодно и просто глупо. Гораздо интереснее найти ещё парочку подобных заказов.
>На мой взгляд, оно неявно предполагается отказом от экскаватора.
Неверно. Я отказался не от экскаватора в принципе, а от экскаватора за полмиллиона долларов.
>Получается, Ваш основной поинт по сути в том, что иногда наёмный труд (самому копать X лет) выгоднее, чем высокодоходный бизнес
Неверно. О том, что такой заказ может быть не один, а несколько, речи не шло. Речь шла об одиночном заказе. Если таких заказов теоретически предполагается несколько (т.е. вы опять вносите дополнительные условия), то и мои действия, разумеется, будут другими.
Неверно. Я отказался не от экскаватора в принципе, а от экскаватора за полмиллиона долларов.
>Получается, Ваш основной поинт по сути в том, что иногда наёмный труд (самому копать X лет) выгоднее, чем высокодоходный бизнес
Неверно. О том, что такой заказ может быть не один, а несколько, речи не шло. Речь шла об одиночном заказе. Если таких заказов теоретически предполагается несколько (т.е. вы опять вносите дополнительные условия), то и мои действия, разумеется, будут другими.
Я отказался не от экскаватора в принципе, а от экскаватора за полмиллиона долларов.Тогда бы Вы написали: «Найду субподрядчика с экскаватором подешевле» )))
Если таких заказов теоретически предполагается несколько (т.е. вы опять вносите дополнительные условия), то и мои действия, разумеется, будут другими.Неверно. Никаких условий я не вносил, только рассматривал вероятные затруднения, которые Вы никак не учли в оценке сроков. А точно известно только одно: если копать X лет яму самому, то никаких других заказов не будет, будет только физическая и эмоциональная усталость от тяжелой рутинной работы. На другой чаше весов бизнес с 100% рентабельностью производства без каких-либо гарантий, но уже со стартовым капиталом в полмиллиона долларов.
>Тогда бы Вы написали: «Найду субподрядчика с экскаватором подешевле» )))
Если бы был «субподрядчик с экскаватором подешевле», то не было бы самой проблемы «полмиллиона и ничего не делать или миллион, но все делать самому», не так ли?
>Никаких условий я не вносил, только рассматривал вероятные затруднения, которые Вы никак не учли в оценке сроков.
Это не «вероятные затруднения». Еще раз: один заказ на миллион долларов за яму и возможные несколько заказов по миллиону долларов за яму — это совершенно разные ситуации, и совершенно очевидно, что и подходы к оптимальному решению будут разными. Я рассматривал первую ситуацию, поэтому не нужно примешивать сюда вторую.
Короче, кто понял — тот понял. Спор ради спора с постоянно меняющимися условиями меня как-то не прельщает. Всего хорошего.
Если бы был «субподрядчик с экскаватором подешевле», то не было бы самой проблемы «полмиллиона и ничего не делать или миллион, но все делать самому», не так ли?
>Никаких условий я не вносил, только рассматривал вероятные затруднения, которые Вы никак не учли в оценке сроков.
Это не «вероятные затруднения». Еще раз: один заказ на миллион долларов за яму и возможные несколько заказов по миллиону долларов за яму — это совершенно разные ситуации, и совершенно очевидно, что и подходы к оптимальному решению будут разными. Я рассматривал первую ситуацию, поэтому не нужно примешивать сюда вторую.
Короче, кто понял — тот понял. Спор ради спора с постоянно меняющимися условиями меня как-то не прельщает. Всего хорошего.
У нас в селе двухметровую могилу на кладбище выкапывали старыми лопатами за пару часов. Значит, за неделю можно гипотетически управиться и с 10 метровой ямой без учета времени на побъём грунта со дна. Так же, продолжительность будет сильно зависеть от плотности грунта, наличия в ней каменных пород, времени года и т.п. Ну в общем, максимум месяц я бы сказал.
Сложность с глубиной будет расти совсем нелинейно.
Камни, глина, грунтовые воды, осыпание стенок.
Воду придётся откачивать. Осыпание стенок предотвращать кессонами или копать яму с откосами. Камни долбить или взрывать.
десять ям глубиной метр — может быть и месяц. И то вряд ли. Копать два часа и копать 8 часов — разные вещи.
Камни, глина, грунтовые воды, осыпание стенок.
Воду придётся откачивать. Осыпание стенок предотвращать кессонами или копать яму с откосами. Камни долбить или взрывать.
десять ям глубиной метр — может быть и месяц. И то вряд ли. Копать два часа и копать 8 часов — разные вещи.
А вы представляете седбе яму 3*5*10?
Нанимателя мало интересуют подробности — он поставил задачу вам. При такой постановке задачи — заплатите из своего миллиона сколько надо экскаваторщику и наслаждайтесь жизнью.
поддерживаю… верно сказано!
Я верю, что автор немного промахнулся с истинной причиной проблем русских разработчиков. Направление было верное, но выводы не пошли достаточно далеко, что вы прекрасно своим комментом проиллюстрировали, а другие пользователи подтвердили плюсами.
Проблема русских разработчиков не в том, что они не предлагают альтернативных подходов к решению сложных задач, а в том, почему они этого не делают. Им в большинстве своем тупо наплевать на то, что они делают, зачем они это делают и где работают.
Русский разработчик в большинстве своем рассматривает себя как инструмент для использования других инструментов (кода, ИСР, ОС). Ему наплевать на то, что он своими инструментами в этой компании или этом мире достигает — ему важны только сами инструменты. Это как врач, которому наплевать на больницу, людей и болезни, ведь его «реальная» работа — использовать градусник. Или как пожарник, которому наплевать на пожары и людей в них, ведь его волнует только пожарный топор и методы его применения для открытия дверей в рушащихся зданиях. Или педагог, которому наплевать на детей, образование и родителей — ему нравится составлять учебные планы.
Проблема русских программистов именно в этом, а беда России в том, что эта проблема на программистах не заканчивается…
Проблема русских разработчиков не в том, что они не предлагают альтернативных подходов к решению сложных задач, а в том, почему они этого не делают. Им в большинстве своем тупо наплевать на то, что они делают, зачем они это делают и где работают.
Русский разработчик в большинстве своем рассматривает себя как инструмент для использования других инструментов (кода, ИСР, ОС). Ему наплевать на то, что он своими инструментами в этой компании или этом мире достигает — ему важны только сами инструменты. Это как врач, которому наплевать на больницу, людей и болезни, ведь его «реальная» работа — использовать градусник. Или как пожарник, которому наплевать на пожары и людей в них, ведь его волнует только пожарный топор и методы его применения для открытия дверей в рушащихся зданиях. Или педагог, которому наплевать на детей, образование и родителей — ему нравится составлять учебные планы.
Проблема русских программистов именно в этом, а беда России в том, что эта проблема на программистах не заканчивается…
Есть такое. Возможно это потому что испокон веков цели устанавливались кем-то. Царем, помещиком, революционным комитетом, партией… а твое дело было отработать «от забора до обеда».
А может наоборот ментальность такая, поэтому и произрастал подобный общественный строй.
А может наоборот ментальность такая, поэтому и произрастал подобный общественный строй.
Или как военный летчик, которому наплевать на войны. Ему нравится летать на быстрых самолетах ;)
Я не хочу об этом думать на работе. Даже не знаю, как объяснить…
В процессе программирования нет никаких денег. В коде нет денег. Деньги есть только в день зарплаты.
В моем понимании о деньгах все таки нужно думать. Иначе можно неправильно расставлять приоритеты. Допустим есть реально проблемная для клиента фича, и нужно заниматься ей, а программист говорит мне поебать на прибыль компании, и занимается рефакторингом части кода. Думаю понятно, что в данном случае происходят некоторые «проблемы в коммуникации»?
Я бы это назвал невыполнением обязанностей. Есть менеджер и он должен ставить задачи и их приоритеты, а программист должен их выполнять. Программист может предлагать изменять приоритеты, но не обязан этого делать. И в любом случае решение должен принимать не он.
Можно и так сказать. Я лишь хотел добавить, что по моему мнению, сказать программисту «Сделай вот это в первую очередь, это понравится нашим клиентам, и принесет нашей компании больше прибыли», гораздо лучше чем «Сделай вот это, потому, что я хочу, чтобы ты делал именно это. А почему именно, тебя не касается».
Мне, в те моменты когда я выполняю\выполнял роль программиста, не очень нравится быть тупо слепым орудием, и всегда хотелось знать, какую пользу принесет моя работа.
Мне, в те моменты когда я выполняю\выполнял роль программиста, не очень нравится быть тупо слепым орудием, и всегда хотелось знать, какую пользу принесет моя работа.
С подобным, по-моему, никто не спорит. Но ждать от программиста, что он будет думать о том, как принести больше прибыли, несколько наивно, по-моему. Это не инженерная задача.
Ну, тред начался с такого:
Думаю мой ответ это как раз объясняет. «Потому, что тогда программист может чувствовать, что реализует не очередную блажь начальника, а что-то действительно полезное.» А делать что-то, что захотел начальник, но не имеет никакого смысла, конечно же неприятно. Вот начальник и пытается донести смысл задания. Через прибыль.
В целом статья клёвая, но вопрос вот возник: почему наниматель хочет, чтобы разработчик чувствовал себя совладельцем компании
Думаю мой ответ это как раз объясняет. «Потому, что тогда программист может чувствовать, что реализует не очередную блажь начальника, а что-то действительно полезное.» А делать что-то, что захотел начальник, но не имеет никакого смысла, конечно же неприятно. Вот начальник и пытается донести смысл задания. Через прибыль.
Если бы мне (как программисту) на работе кто-то начал гнать про деньги, я бы сам уволился в тот же день. Понятно, что задача коммерческой компании — зарабатывать бабло, но я даже думать не хочу об этом. Для этого есть специально обученные люди, не я.
А про отказ выполнять задачу я из этого текста не понял. Если разработчик честно уверен, что задачу сделать нельзя, то какой смысл начинать? Из текста не ясно, что на самом деле думали разработчики о поставленных задачах, а это важно. Возможно, они ошиблись в оценке задач или не поняли задачу.
У меня есть некоторый опыт таких ситуаций. И всё время всё решается примерно так: «я не знаю, как это делать, да и можно ли сделать вообще, поэтому мне нужно 3 дня на исследование вопроса. Это ok?». Не всегда это происходит на этапе постановки задачи. Иногда можно после первого дня обнаружить себя в адских дебрях. Тогда нужно снова обсудить ситуацию.
А про отказ выполнять задачу я из этого текста не понял. Если разработчик честно уверен, что задачу сделать нельзя, то какой смысл начинать? Из текста не ясно, что на самом деле думали разработчики о поставленных задачах, а это важно. Возможно, они ошиблись в оценке задач или не поняли задачу.
У меня есть некоторый опыт таких ситуаций. И всё время всё решается примерно так: «я не знаю, как это делать, да и можно ли сделать вообще, поэтому мне нужно 3 дня на исследование вопроса. Это ok?». Не всегда это происходит на этапе постановки задачи. Иногда можно после первого дня обнаружить себя в адских дебрях. Тогда нужно снова обсудить ситуацию.
Если бы разраб пришёл через день, и вывалил перечень неудавшихся подходов — это было бы как то конструктивнее, что ли.
А сесть на принцип «я не начну» как-то неконструктивно, что ли…
:-)
А сесть на принцип «я не начну» как-то неконструктивно, что ли…
:-)
Всё зависит от задачи. Например, задача подразумевает наличие у программы сильного ИИ. Я даже пытаться не буду его реализовать, а сразу скажу, что на данном этапе развития науки и техники это невозможно.
Важный вопрос — а вы предложите другой вариант решения?
Условно «сейчас сильный ИИ сделать невозможно, но мы можем сделать его видимость для пользователей в таких случаях». Возможность обдумывать и предлагать такие варианты, на мой взгляд, во многом отличает сильных разработчиков.
Условно «сейчас сильный ИИ сделать невозможно, но мы можем сделать его видимость для пользователей в таких случаях». Возможность обдумывать и предлагать такие варианты, на мой взгляд, во многом отличает сильных разработчиков.
Если бы разраб пришёл через день, и вывалил перечень неудавшихся подходов — это было бы как то конструктивнее, что ли.
Наоборот, это был бы повод для немедленного увольнения, как не оправдавшего надежд (провалившего приказ руководства).
А вот попросить время на исследование — это действительно хороший подход. По крайней мере выделение этого времени однозначно покажет, что задача кому-то нужна, а не является бессмысленной прихотью. А по результатам исследований уже можно будет судить об экономической обоснованности необходимости решения этой задачи и о том, будет ли она снята или реально поручена.
Ну и с задачами, которые описал VolCh тоже практически все ясно. Разве что иногда можно попытать начальство и может быть выясниться, что под сильным ИИ на самом деле понимается простейшая система, которая пишется за пару часов, а сильный ИИ всего-лишь маркетинговый ход.
P.S. ru.wikibooks.org/wiki/%D0%9C%D0%B5%D1%82%D0%BE%D0%B4%D1%8B_%D0%9A%D1%80%D0%B8%D1%81%D1%82%D0%BE%D0%B1%D0%B0%D0%BB%D1%8F_%D0%A5%D1%83%D0%BD%D1%82%D1%8B
Если бы он сказал, что не знает ответа и требует день на исследования, то это было бы ещё более конструктивно.
Мой ответ не отрицал этого варианта, а отрицал вариант «не буду начинать».
Мой ответ не отрицал этого варианта, а отрицал вариант «не буду начинать».
Вы сказали, что если человек согласился (зная что задача не решаема) и (ожидаемо) провалил ее, то это конструктивный подход. Я же считаю, что это мало того не конструктивный подход, так еще и некорректный, так как сотрудничество работника и менеджера было начато с обмана. Если же не решаемость задачи заранее неизвестна, то лучше опять-же просить время на исследование и определять соглашаться или нет по результатам исследования.
Опять-же не стоит забывать и провалы менеджмента, когда требуют решить задачу по типу приведенной VolCh. С моей точки зрения в этом случае программист сказавший просто нет будет максимально корректен, а если менеджер сделает что-то отличное от уточняющих вопросов, то он тем самым покажет свою сверхнизкую квалификацию.
Разумеется, что все вышеперечисленные суждения не относятся к ситуации, когда разработчику просто лень что-то делать.
Опять-же не стоит забывать и провалы менеджмента, когда требуют решить задачу по типу приведенной VolCh. С моей точки зрения в этом случае программист сказавший просто нет будет максимально корректен, а если менеджер сделает что-то отличное от уточняющих вопросов, то он тем самым покажет свою сверхнизкую квалификацию.
Разумеется, что все вышеперечисленные суждения не относятся к ситуации, когда разработчику просто лень что-то делать.
Я сказал?! Процитируйте!
Ваш ответ был на комментарий, где было сказано дословно следующее:
А про отказ выполнять задачу я из этого текста не понял. Если разработчик честно уверен, что задачу сделать нельзя, то какой смысл начинать?
Если он уверен, то должен мотивировать отказ.
Из статьи это не следует.
В статье русским по белому написано
А это было сделано за полтора суток, криво ли, косо ли, но решение постановщика удовлетворило. То есть это можно сделать за полтора суток ценой полутора суток.
Вот и весь профессионализм, который вы настойчиво защищаете.
Из статьи это не следует.
В статье русским по белому написано
Последующие пять минут разработчик пытается хоть как-то обосновать и найти какую-нибудь существенную преграду. Градус беседы повышается. Заканчивается всё таким диалогом:
— Это нельзя сделать, потому, что это никогда и ни за что нельзя сделать!
А это было сделано за полтора суток, криво ли, косо ли, но решение постановщика удовлетворило. То есть это можно сделать за полтора суток ценой полутора суток.
Вот и весь профессионализм, который вы настойчиво защищаете.
P.S. Плюс, возможно, ценой некоторого технического долга.
Налицо неверная оценка «профессионалом» — сравните с «никогда и ни за что».
Налицо неверная оценка «профессионалом» — сравните с «никогда и ни за что».
Возможно, что за это время были изменены требования. Скажем, при разработке защиты от чего-то слово «невозможно» было заменено на «сложно», «практически невозможно» или «нерентабельно». С точки зрения заказчика разницы почти нет — его задача решена, но с точки зрения разработчика она принципиальна: он знает, что невозможно создать защиту, которую нельзя взломать — это вопрос лишь желания, времени и материальных ресурсов.
Сопоставьте, пожалуйста это
и это
и далее, (ВНЕЗАПНО)
И поймите, что ваши «невозможно», «сложно», «практически невозможно», «нерентабельно» здесь неуместны.
Если вы до сих пор упрямитесь, то и я бы вас уволил как тот американец. Не только потому, что вы оправдываете яростное бездействие того персонажа. Но и потому, что в данной дискуссии вы встали на рельсы изворотливости, лишь бы не признать собственной неправоты в одной конкретной ситуации.
А именно несоответствие ваших «невозможно», «сложно», «практически невозможно», «нерентабельно» с «сам сделал штуку за полтора дня» автора-программиста.
я разработчик. Специально обращаю внимание. Я пишу код каждый день
и это
Штучка в принципе небольшая
и далее, (ВНЕЗАПНО)
Плюнул на всё, сел и сам сделал штуку за полтора дня.
И поймите, что ваши «невозможно», «сложно», «практически невозможно», «нерентабельно» здесь неуместны.
Если вы до сих пор упрямитесь, то и я бы вас уволил как тот американец. Не только потому, что вы оправдываете яростное бездействие того персонажа. Но и потому, что в данной дискуссии вы встали на рельсы изворотливости, лишь бы не признать собственной неправоты в одной конкретной ситуации.
А именно несоответствие ваших «невозможно», «сложно», «практически невозможно», «нерентабельно» с «сам сделал штуку за полтора дня» автора-программиста.
Тут мы не знает всех подробностей, по этому мы не можем считать, что задачу которую решил неспециалист за полутора суток на самом деле эквивалентна той задаче, которую он требовал от подчиненного.
Кроме того, я не рассматривал случай, когда подчиненному просто лень работать, о чем написал в своих сообщениях.
Кроме того, я не рассматривал случай, когда подчиненному просто лень работать, о чем написал в своих сообщениях.
>Если разработчик честно уверен, что задачу сделать нельзя, то какой смысл начинать?
При этом человек, не являющийся специалистом в области, сумел решить задачу за полтора дня? Ну что ж, значит разработчик банально некомпетентен, раз он был «честно уверен, что задачу сделать нельзя». Увольнять не раздумывая.
При этом человек, не являющийся специалистом в области, сумел решить задачу за полтора дня? Ну что ж, значит разработчик банально некомпетентен, раз он был «честно уверен, что задачу сделать нельзя». Увольнять не раздумывая.
Эээ? Судя по тексту и по вашему «приходилось увольнять и таких и таких», я думал вы как минимум VP of engineering, т.е. о компании должны знать оченеь много?
Поправочка: чужие деньги не мотивируют,
Может разработчикам и положить на компанию, тут я за всех сказать не могу (я лично заинтересован в прибыли компании), но это неправильное положение дел. Если прибыль не растет, значит не растет з\п (не в деньгах счастье, но без них счастья нет). Если у вас три года подряд одна и та же з\п, то с нашей инфляцией, она становится маленькой. А если прибыль и вовсе уменьшается, за счет чего компания будет экономить, если основные расходы — з\п разработчикам? Поск новой работы — трата времени, денег, привыкание к новому коллективу.
Опять же, если вы заботитесь о прибыли компании, вас заметят, повысят. Что для вас интереснее — писать код модулей для системы или руководить разработкой системы?
Опять же, если вы заботитесь о прибыли компании, вас заметят, повысят. Что для вас интереснее — писать код модулей для системы или руководить разработкой системы?
А если прибыль растет, то зачастую растет зп только у гендира и высшего руководства, накрайняк менеджеров, о программистах вспоминают в последнюю очередь.
Очень актуально на территориях бывшего СССР
Очень актуально на территориях бывшего СССР
это уже другая проблема, не так ли?
Если директор понимает, на чем держится его компания, то он будет поощрять тех, кого нужно. Если он этого не понимает, то когда нибудь компания развалится
Если директор понимает, на чем держится его компания, то он будет поощрять тех, кого нужно. Если он этого не понимает, то когда нибудь компания развалится
Когда-нибудь — возможно, а возможно будет существовать на ротации вчерашних студентов )
А пока что такие компании живут и мое наблюдение весьма актуально
А пока что такие компании живут и мое наблюдение весьма актуально
Если коротко: повышать всех невозможно. Можно стремиться создать такие условия, в которых людям будет приятно работать, и тогда необходимость мотивировать их материально снизится (что хорошо, потому что материально мало кто мотивируется после прохождения определённого уровня дохода), и можно будет повышать только ключевых сотрудников (да и то не факт, что программист-суперзвезда станет добьется сходных результатов на новом для себя поприще).
> Можно стремиться создать такие условия, в которых людям будет приятно работать,
Вы не поверите, но на создание этих условий тоже нужны деньги.
Вы не поверите, но на создание этих условий тоже нужны деньги.
Вы не поверите, но поверю.
И что, вы считаете, что это должно заботить того, кто нанимается на работу? Это рынок, а не благотворительность. Ты соглашаешься на определённые условия труда, взамен предоставляя своё время, мозг и некое ненулевое желание решать задачи нанимателя. Наниматель ищет способные кадры, кадры ищут, где будет интересно и приятно (как тут верно кто-то замечал, в пирамиде потребностей есть не только деньги). Круто, конечно, когда есть взаимное уважение и понимание ресурсозатрат обеих сторон, но это не обязательное условие сотрудничества.
Как строить бизнес таким образом, чтобы прибыли хватало и на зарплату, и на обеспечение условий труда — забота нанимателя. Потому это его бизнес, который лично ему должен приносить прибыль.
Я всего лишь пытался сказать, что, если хочешь мотивировать при помощи денег, это следует делать с умом, а не шантажируя сотрудников тем, что скоро всем станет нечего кушать.
И что, вы считаете, что это должно заботить того, кто нанимается на работу? Это рынок, а не благотворительность. Ты соглашаешься на определённые условия труда, взамен предоставляя своё время, мозг и некое ненулевое желание решать задачи нанимателя. Наниматель ищет способные кадры, кадры ищут, где будет интересно и приятно (как тут верно кто-то замечал, в пирамиде потребностей есть не только деньги). Круто, конечно, когда есть взаимное уважение и понимание ресурсозатрат обеих сторон, но это не обязательное условие сотрудничества.
Как строить бизнес таким образом, чтобы прибыли хватало и на зарплату, и на обеспечение условий труда — забота нанимателя. Потому это его бизнес, который лично ему должен приносить прибыль.
Я всего лишь пытался сказать, что, если хочешь мотивировать при помощи денег, это следует делать с умом, а не шантажируя сотрудников тем, что скоро всем станет нечего кушать.
По вашей логике если программисту предоставить коморку на работе где он может спать, столовую где он сможет есть, то он будет работать после этого без денег ради чего-то светлого и высокого.
Люди ничего не приносящие компании — балласт, а от него нужно избавляться.
И избавление компании от такого балласта действительно проблема нанимателя.
Сомневаюсь что вы заплатили бы деньги сантехнику, который пришел бы посидеть на вашем золотом унитазе, вместо того чтобы делать работу.
Люди ничего не приносящие компании — балласт, а от него нужно избавляться.
И избавление компании от такого балласта действительно проблема нанимателя.
Сомневаюсь что вы заплатили бы деньги сантехнику, который пришел бы посидеть на вашем золотом унитазе, вместо того чтобы делать работу.
Честно, затрудняюсь сказать, где вы такую логику у меня увидели. Это какие-то ваши домыслы и додумывания.
Скорее это ваши домыслы что работника ничего не должно заботить кроме того чтобы педалить только то что ему кажется правильным, а не то что требует компания.
Это банальное невыполнение своих обязательств, которое влечет за собой снижение дохода/прибыли компании.
И в итоге все завязано на деньгах, о которых вы так хотите не думать.
Поразительно, правда?
Это банальное невыполнение своих обязательств, которое влечет за собой снижение дохода/прибыли компании.
И в итоге все завязано на деньгах, о которых вы так хотите не думать.
Поразительно, правда?
Во-первых, я излагаю свою позицию. Если вас она не устраивает, вы можете в ответ изложить свою. Однако уверен, что в этом нет необходимости, пока вы не поймете верно то, что я пытаюсь сказать.
Во-вторых, я нигде не написал, что работник должен педалить только то, что ему кажется правильным. Это пишете вы, непонятно на чём основываясь.
Невыполнение своих обязательств — если они были даны — это, безусловно, причина работодателю озаботиться. Однако, опять же, я об этом нигде не писал.
И с чего вы решили, что я не хочу о них думать? Я всего лишь занимаю такую позицию, что сотрудник не имеет обязательства думать за нанимателя, откуда возьмутся деньги на зарплату, если делает свою работу. Если же он не делает свою работу, то хоть с зарплатой, хоть без, это уже другой разговор.
Исходно я оспариваю лишь предположение, что сотрудника должны беспокоить процессы бизнеса, если он не мотивирован процентом-опционами и т.д. Если в ответ приводятся доводы, что вот есть же такие люди, которые болеют за компанию, то для меня это лишь свидетельство того, что многие люди реально любят свою работу. Не за деньги.
Теперь объясните мне, с чем вы спорили?
Во-вторых, я нигде не написал, что работник должен педалить только то, что ему кажется правильным. Это пишете вы, непонятно на чём основываясь.
Невыполнение своих обязательств — если они были даны — это, безусловно, причина работодателю озаботиться. Однако, опять же, я об этом нигде не писал.
И с чего вы решили, что я не хочу о них думать? Я всего лишь занимаю такую позицию, что сотрудник не имеет обязательства думать за нанимателя, откуда возьмутся деньги на зарплату, если делает свою работу. Если же он не делает свою работу, то хоть с зарплатой, хоть без, это уже другой разговор.
Исходно я оспариваю лишь предположение, что сотрудника должны беспокоить процессы бизнеса, если он не мотивирован процентом-опционами и т.д. Если в ответ приводятся доводы, что вот есть же такие люди, которые болеют за компанию, то для меня это лишь свидетельство того, что многие люди реально любят свою работу. Не за деньги.
Теперь объясните мне, с чем вы спорили?
Почему вы считаете, что высшее руководство и менеджеры — это инопланетяне? Это такие же жители бывшего СССР как и вы, которым как и вам может быть наплевать на компанию, наплевать на то как они зарабатывают деньги, чего они достигают в этом мире и какими (чьими?) усилиями.
Но вы так же должны понимать, что аргумент «всем наплевать и мне наплевать» уже не тянет. Вы же потом все-равно будете грустить, что никто (правительство, компания, друзья) о вас не думает. Пока сами не попадете в это самое правительство. Почему бы не начать изменения с СЕБЯ? Театр абсурда.
Но вы так же должны понимать, что аргумент «всем наплевать и мне наплевать» уже не тянет. Вы же потом все-равно будете грустить, что никто (правительство, компания, друзья) о вас не думает. Пока сами не попадете в это самое правительство. Почему бы не начать изменения с СЕБЯ? Театр абсурда.
Что для вас интереснее — писать код модулей для системы или руководить разработкой системы?
Не поверите, но писать любой код мне интересней, чем руководить людьми. Это, наверное, не просто разные, а противоположные области деятельности.
На мой взгляд разработчик не должен чувствовать себя совладельцем компании.
Но он должен понимать: он создаёт продукт в первую очередь для клиентов компании, а не для своего начальника. И платят тоже клиенты, начальник лишь перераспределяет деньги внутри фирмы.
Чтобы при обсуждении фич включалась своя голова, чтобы не было мыслей «сделаю как начальник скажет чтобы отвязался, а прав он или нет — это не мои проблемы»
В этом случае конечно требуется адекватность и от самого начальника — умение выслушивать мнение разработчика и вести с ним диалог.
Но он должен понимать: он создаёт продукт в первую очередь для клиентов компании, а не для своего начальника. И платят тоже клиенты, начальник лишь перераспределяет деньги внутри фирмы.
Чтобы при обсуждении фич включалась своя голова, чтобы не было мыслей «сделаю как начальник скажет чтобы отвязался, а прав он или нет — это не мои проблемы»
В этом случае конечно требуется адекватность и от самого начальника — умение выслушивать мнение разработчика и вести с ним диалог.
Есть вертикальные компании, есть горизонтальные компании. Роль начальника в разных схемах сильно различается. Где-то такая структура, что действительно нужно фигачить от забора и до обеда, не задавая вопросы.
Присоединяюсь. Разработчик должен чувствовать себя профессионалом — честная сделка: зарплата = решение задач, препятствий, проблем, катастроф, апокалипсисов. Приблизительно в рамках рабочих обязанностей, и без больших зашкаливаний.
И должен чувствовать, что свой этап бизнеса он сделал чётко, качественно и с чёстью. Остальные этапы бизнеса его не касаются, покуда разраб не имеет пропорциональной доли прибыли (а он не имеет, кроме условной тринадцатой зарплаты фиксированного размера).
А вот гаврики, которые доказывают невозможность продукта на словах явно ждут своих американизированных увольнителей.
И должен чувствовать, что свой этап бизнеса он сделал чётко, качественно и с чёстью. Остальные этапы бизнеса его не касаются, покуда разраб не имеет пропорциональной доли прибыли (а он не имеет, кроме условной тринадцатой зарплаты фиксированного размера).
А вот гаврики, которые доказывают невозможность продукта на словах явно ждут своих американизированных увольнителей.
Люто плюсую.
Аргумент, что «ты должен помочь компании заработать больше денег» часто, к сожалению, звучит как психологическая манипуляция.
Когда человек реально старается работать больше, продуктивнее? Когда он:
— совладелец компании
— имеет существенное количество опционов на акции, и серьезно предполагает поднять неплохие деньги после IPO / acquisition-a
— когда он видит, что запрлаты реально определяются пропорционально _реальному_ вкладу, т.е. нет ситуации, когда в команде 5 человек пишут весь код + еще есть срам-мастер, 3 принципал архитекта по тому, 5 senior VP какой-то херни, и все они получает денег больше программистов. В некоторых мелких компаниях такое бывает. 5 инженеров пишут весь код, и 15 человек менеджеров, аналитиков, которые непонятно че анализируют, архитекторов, которые даже документов технических не пишут, не говоря о том, чтоб код писать, вице-президентов всякой фигни и прочее.
— когда человек видит прямую зависимость между улучшением положения компании и своей зарплатой. В третьем квартале компания благодаря новым фичам увеличила прибыль на 50? Какая часть этих денег пойдет на премии разработчикам, а какая — в карман шарехолдерам или топ-менеджменту?
Автор, я вас не минусую, но и не плюсую. Вы видно, человек умный и опытный. Но это я замечаю часто среди американских менеджеров — он очень сильны в сейлс, общении с инвесторами, медиа и подобном. Но они плохо понимают механизмы мотивации гиков. Особенно если сами МБА-воротнички. Вы пишете, что пишете код каждый день. Значит, вы не из таких скорее всего, но все же, я бы на вашем месте обдумал, чем вы мотивируете людей.
А еще хотелось бы спросить. У вас в компании скрам есть? И есть ли у вас engineering culture, или скорее власть менеджеров?
Аргумент, что «ты должен помочь компании заработать больше денег» часто, к сожалению, звучит как психологическая манипуляция.
Когда человек реально старается работать больше, продуктивнее? Когда он:
— совладелец компании
— имеет существенное количество опционов на акции, и серьезно предполагает поднять неплохие деньги после IPO / acquisition-a
— когда он видит, что запрлаты реально определяются пропорционально _реальному_ вкладу, т.е. нет ситуации, когда в команде 5 человек пишут весь код + еще есть срам-мастер, 3 принципал архитекта по тому, 5 senior VP какой-то херни, и все они получает денег больше программистов. В некоторых мелких компаниях такое бывает. 5 инженеров пишут весь код, и 15 человек менеджеров, аналитиков, которые непонятно че анализируют, архитекторов, которые даже документов технических не пишут, не говоря о том, чтоб код писать, вице-президентов всякой фигни и прочее.
— когда человек видит прямую зависимость между улучшением положения компании и своей зарплатой. В третьем квартале компания благодаря новым фичам увеличила прибыль на 50? Какая часть этих денег пойдет на премии разработчикам, а какая — в карман шарехолдерам или топ-менеджменту?
Автор, я вас не минусую, но и не плюсую. Вы видно, человек умный и опытный. Но это я замечаю часто среди американских менеджеров — он очень сильны в сейлс, общении с инвесторами, медиа и подобном. Но они плохо понимают механизмы мотивации гиков. Особенно если сами МБА-воротнички. Вы пишете, что пишете код каждый день. Значит, вы не из таких скорее всего, но все же, я бы на вашем месте обдумал, чем вы мотивируете людей.
А еще хотелось бы спросить. У вас в компании скрам есть? И есть ли у вас engineering culture, или скорее власть менеджеров?
Думаю, что пост не про деньги. И не про денежную мотивацию. А про чувство своего. Если задача программиста писать код максимально красивый — это одно, а если писать так чтобы он был красивый сейчас, завтра, послезавтра, для себя, для коллеги, для тестера, чтобы он был рабочий для компании, для пользователя, для продукта, сейчас, завтра, послезватра — это другое. Поэтому и есть толпа прилежащих аналитиков, архитекторов, тимлидов, тестеров, QA, документописателей, дизайнеров, UX-мастеров, которые дают возможность коду превратиться в такой вот описанный шедевр — не сразу, но постепенно, вырастить его из маленького модуля в большой развесистый или прямой как палка инструмент. Для себя я обозначил это проблему как ширину кругозора. Программист может быть технически очень грамотным, но если он не смотрит наверх (пользователи), вправо (QA, тимлид, архи, литики), влево (дизайнеры, UX-мастера), вперед (время), назад (поддержка), то взгляд в землю приводит вот к таким перекосам. К сожалению, я как программист грешу такими штуками, и не очень знаю, что нужно сделать в каждом конкретном случае, но в теории (я ее сейчас проверяю) изучение архитектурных шаблонов интеграции должно помочь справится с нежеланием смотреть куда-либо кроме как под ноги.
Почему то сразу вспомнилось.
«При коммунизме человек теряет личность — батальонам она не нужна.
Капитализм человека делает вещью, а на каждую вещь есть вор.»
У нас огромный дефицит самореализации, и любая возможность — дороже любых бонусов.
«При коммунизме человек теряет личность — батальонам она не нужна.
Капитализм человека делает вещью, а на каждую вещь есть вор.»
У нас огромный дефицит самореализации, и любая возможность — дороже любых бонусов.
Есть такое свойство у некоторых программистов. Ключевое слово здесь — «у некоторых». Причем, у начинающих, которые входят в период ложной опытности. Не стоит распространять это на всех.
НЛО прилетело и опубликовало эту надпись здесь
Я встречал довольно много таких программистов. В смысле: программист думает, что ему должны, просто так должны, за вымышленную квалификацию. Он совершенно не думает о деньгах, которые он приносит. Он думает, что просто за то, что он якобы знает, он может сидеть ровно, ничего не делать и зп ему ДОЛЖНЫ выше по рынку. При этом знания его, зачастую, вымышленные им самим.
Как-то проследил, почему это происходит. Происходит, если человек работал в аутсорсинговых компаниях. Средняя общая некомпетентность влияет также на прием на работу. Разработчикам кажется, что распределение зарплат несправедливое. И заметили, что тот, кто на собеседовании больше покажет свое эго, больше наглости, тот выбивает больше зп, а компетентность — дело пятое. У них складывается впечатление, что компания на них зарабатывает миллионы (утрирую), а им, даже при больших зп, платит копейки.
В итоге странное смещение. Когда разработчик даже в разы менее эффективнее (5-10 раз), в разы пишет больше багов, или даже вообще почти ничего не делает — он все равно ощущает себя правильным и ценным работником, не менее ценным, чем эффективный разработчик. Компания ему просто так должна, она и так у него деньги своровала. Если компания этого не понимает — есть другие.
Как-то проследил, почему это происходит. Происходит, если человек работал в аутсорсинговых компаниях. Средняя общая некомпетентность влияет также на прием на работу. Разработчикам кажется, что распределение зарплат несправедливое. И заметили, что тот, кто на собеседовании больше покажет свое эго, больше наглости, тот выбивает больше зп, а компетентность — дело пятое. У них складывается впечатление, что компания на них зарабатывает миллионы (утрирую), а им, даже при больших зп, платит копейки.
В итоге странное смещение. Когда разработчик даже в разы менее эффективнее (5-10 раз), в разы пишет больше багов, или даже вообще почти ничего не делает — он все равно ощущает себя правильным и ценным работником, не менее ценным, чем эффективный разработчик. Компания ему просто так должна, она и так у него деньги своровала. Если компания этого не понимает — есть другие.
НЛО прилетело и опубликовало эту надпись здесь
В общем, как кажется, тех, которых я знаю (с десяток) — это некоторая обида по поводу зарплат, эгоцентризм. Аутсорс часто влияет, т.к. там заказчики часто платят за голову программиста.
Известно, что «работяге» меньше платят, т.к. он увлечен кодированием и:
1) реже меняет работу, значит реже повышают зп;
2) у него меньше шансов идти по карьерной лестнице, т.к. золотую курицу никто резать не будет. Сталкивался пару раз, как в менеджеры проектов выдвигали самых тупых программистов, т.к. толку от их кодирования было мало.
Вообще, возможно, это исходит действительно из нашего менталитета, менталитета бандитского, 90-х годов. Когда люди думают, что «решают вопросы» не те, которые имеют компетентность, а правильные люди, в бане, с девочками и водкой. Что работают «инженеры» узкого профиля, а решателям вопросов не надо даже знать что-то, не надо иметь представление о проблеме.
Это я описываю крайний психологический случай. Но мне это говорили даже прямым текстом. Вроде, технические специалисты в технических вопросах не должны участвовать в принятии решений. Они только реализовывают.
Этот стереотип так или иначе распространился среди всех. Даже если программист не думает такими категориями, я крайне мало видел людей, которые вообще думают о своей эффективности. Дошло до того, что даже в программировании большинство бредит некой «правильностью» построения архитектур, правильным процессом, который почему-то должен быть долгим, забрать кучу денег у заказчика, но он правильный и всё. Без вариантов и без денежных критериев. Тут на хабре периодически проскакивают статьи, какие мы стали толковые и умные, знаем уже как надо архитектурить, но заказчик нам не дает, всё хочет быстрее и дешевле. Странно, что он должен еще хотеть.
Известно, что «работяге» меньше платят, т.к. он увлечен кодированием и:
1) реже меняет работу, значит реже повышают зп;
2) у него меньше шансов идти по карьерной лестнице, т.к. золотую курицу никто резать не будет. Сталкивался пару раз, как в менеджеры проектов выдвигали самых тупых программистов, т.к. толку от их кодирования было мало.
Вообще, возможно, это исходит действительно из нашего менталитета, менталитета бандитского, 90-х годов. Когда люди думают, что «решают вопросы» не те, которые имеют компетентность, а правильные люди, в бане, с девочками и водкой. Что работают «инженеры» узкого профиля, а решателям вопросов не надо даже знать что-то, не надо иметь представление о проблеме.
Это я описываю крайний психологический случай. Но мне это говорили даже прямым текстом. Вроде, технические специалисты в технических вопросах не должны участвовать в принятии решений. Они только реализовывают.
Этот стереотип так или иначе распространился среди всех. Даже если программист не думает такими категориями, я крайне мало видел людей, которые вообще думают о своей эффективности. Дошло до того, что даже в программировании большинство бредит некой «правильностью» построения архитектур, правильным процессом, который почему-то должен быть долгим, забрать кучу денег у заказчика, но он правильный и всё. Без вариантов и без денежных критериев. Тут на хабре периодически проскакивают статьи, какие мы стали толковые и умные, знаем уже как надо архитектурить, но заказчик нам не дает, всё хочет быстрее и дешевле. Странно, что он должен еще хотеть.
Вроде, технические специалисты в технических вопросах не должны участвовать в принятии решений.
Если добавить слово «управленческих» (решений), то полностью согласен с этим мнением. Наше дело предложить технические варианты решения задачи, оценить затраты ресурсов на них и т. п., но не оценивать возможные доходы. Доходы — это психология, а не техника.
А управленческое решение управляет чем, психологией?
Нет, вопрос шел именно про технические моменты. Скажем, покупка системы для технических нужд, без технической оценки — что покупают и зачем.
Правильный выбор или решение должно базироваться на трех составляющих: наличие интеллекта, наличие информации, наличие умений для обработки информации такого рода. А у нас в том то и дело, управленческий аппарат только и изучает психологию, мистику, гипноз, НЛП, астрологию.
Оценивать затраты ресурсов, возможные доходы — это хорошо, но если выполняется параллельно, а не вместо знающих проблему людей.
Мы чаще всего решаем технические задачи. Информация для выбора решений исходит из разработки.
Нет, вопрос шел именно про технические моменты. Скажем, покупка системы для технических нужд, без технической оценки — что покупают и зачем.
Правильный выбор или решение должно базироваться на трех составляющих: наличие интеллекта, наличие информации, наличие умений для обработки информации такого рода. А у нас в том то и дело, управленческий аппарат только и изучает психологию, мистику, гипноз, НЛП, астрологию.
Оценивать затраты ресурсов, возможные доходы — это хорошо, но если выполняется параллельно, а не вместо знающих проблему людей.
Мы чаще всего решаем технические задачи. Информация для выбора решений исходит из разработки.
Мы недавно со знакомым перетирали подобные темы и как раз пришли к выводу, что у многих разработчиков между 25-30 годами карьерная дыра как раз таки ложной опытности. Когда количество проектов вроде растет, но человек при этом не начинает делать свою работу лучше. С мысли «черт, весь мой якобы бесценный опыт похоже мало чего стоит, я все равно говнокодер, и им и останусь сколько бы всего не „щупал“ и сколько бы „манов не курил“, пойду почитаю умные книжки» карьерный рост возобновляется.
У меня пять лет не было русского на рабочем компе
Мы все должны работать и создать условия, чтобы клиент принёс нам деньги. Именно из них зарплата и премия будут!
В россии просто немного другая ситуация, нам кажется что поведение разработчиков здесь следствие его приспособляемости к окружающей среде, а перестроится достаточно тяжело.
Мы на фрилансе работаем с западом и с рф.
И если на западе это «заказчик ставит задачу, решаешь ее, выставляешь счет, получаешь деньги».
То в рф это скорее «заказчик ставит задачу, решаешь ее, выставляешь счет, получаешь гору претензий на тему — почему так долго, почему так дорого, почему у второстепенного проекта сдвинулись сроки из-за этой задачи».
На окладе все примерно то же самое. Если задача гиморойная, сроки ее решения трудно предсказать, надежность решения неопределенная, результат не дай бог не известен заранее, второстепенный проект может сдвинуться на неопределенный срок, то к гадалке не ходи — в россии как минимум премии лишишься, как максимум — уволят.
В результате иногда «проще отказать, чем объяснить почему не хочешь»©
Разумеется это не абсолют, но тенденция.
Из-за этого очень любим работать на запад:-\
Цена геморройного вопроса «полтора суток».
а) То что цена вопроса 1.5 суток выяснилось после его решения. Проблема с такими вопросами в том, что это могло быть и 1.5 месяца и 1.5 часа. И заранее не угадаешь.
б) 1.5 суток заняло решение у неспециалиста. А значит какие-то важные вещи могли быть упущены, ввиду недостаточности знаний этого специалиста и ввиду недостаточности знаний он этого может даже не понимать. Сколько оно бы заняло у специалиста учитывающего все важные вещи — неизвестно.
б) 1.5 суток заняло решение у неспециалиста. А значит какие-то важные вещи могли быть упущены, ввиду недостаточности знаний этого специалиста и ввиду недостаточности знаний он этого может даже не понимать. Сколько оно бы заняло у специалиста учитывающего все важные вещи — неизвестно.
>Если задача гиморойная, сроки ее решения трудно предсказать, надежность решения неопределенная, результат не дай бог не известен заранее, второстепенный проект может сдвинуться на неопределенный срок
… то это прекрасный повод пойти и почитать литературу про оценивание проектов, которая поможет объяснить руководству почему на решение нужно столько ресурсов, а не столько, откуда такие риски и т.п. Если подобные объяснения не доходят, с такими людьми работать просто не надо. Но обычно проблема носит именно характер недопонимания.
… то это прекрасный повод пойти и почитать литературу про оценивание проектов, которая поможет объяснить руководству почему на решение нужно столько ресурсов, а не столько, откуда такие риски и т.п. Если подобные объяснения не доходят, с такими людьми работать просто не надо. Но обычно проблема носит именно характер недопонимания.
А может это руководству нужно читать такую литературу?
Классический ответ среднерусского руководства будет: «я не спрашиваю как оценивать риски и ресурсы, я спрашиваю когда это будет сделано?!» :)
Если руководство этого не понимает — объяснять бесполезно. А вот выбор с кем работать, а с кем нет — не всегда есть. Зачастую непонимающее руководство платит больше, чем понимающее…
Если руководство этого не понимает — объяснять бесполезно. А вот выбор с кем работать, а с кем нет — не всегда есть. Зачастую непонимающее руководство платит больше, чем понимающее…
Понимаю, это не к месту, но все-таки «блядь», а не «блять» и «специальный сайт» жутко вторичен (говорю как русский хаброкомментатор, англичанин бы сказал, что все пучком и сам бы исправил ситуацию), хотя и согласен с тезисами :) Что касается статьи, то проблемы такого рода все-таки сугубо индивидуальны. Боюсь, что нужно было пропустить через себя хотя бы пару тысяч япошек и россиян, прежде чем обобщать, и то, это будет не совсем удачный анализ.
У меня не столь много опыта, как у вас, я молод и глуп, если честно, но могу дать небольшой пример. Наш ведущий десктоп-разработчик часто упирается, по его выражениям могу судить, что он пытается найти способ спрыгнуть с поставленной задачи — «нет, это не получится»; «нет, это невозможно» и т.д. Отпускаю ситуацию, смиряюсь, хотя и говорю, что подход «не инженера». Через некоторое время он сам приносит качественное решение (часто реализованное в нерабочее время), со слегка исправленной постановкой задачи. Ему так удобно, он иначе воспринимает ситуацию, у него свой point of view, но полностью укладывается в интересы компании. Так уж сложилось, что одно и то же слово у двух людей может вызывать порою совершенно разные ассоциации, это слишком тонкий момент, для того чтобы разбрасываться хорошими кадрами.
Выше сказали «Разработчикам полОжить на прибыль компании и её планы.», есть множество примеров достаточно крупных компаний, в которых этот тезис опровергается чуть более, чем полностью. Более того, его обратное звучание служит основой компании. Зачем сыпать шаблонами?
У меня не столь много опыта, как у вас, я молод и глуп, если честно, но могу дать небольшой пример. Наш ведущий десктоп-разработчик часто упирается, по его выражениям могу судить, что он пытается найти способ спрыгнуть с поставленной задачи — «нет, это не получится»; «нет, это невозможно» и т.д. Отпускаю ситуацию, смиряюсь, хотя и говорю, что подход «не инженера». Через некоторое время он сам приносит качественное решение (часто реализованное в нерабочее время), со слегка исправленной постановкой задачи. Ему так удобно, он иначе воспринимает ситуацию, у него свой point of view, но полностью укладывается в интересы компании. Так уж сложилось, что одно и то же слово у двух людей может вызывать порою совершенно разные ассоциации, это слишком тонкий момент, для того чтобы разбрасываться хорошими кадрами.
Выше сказали «Разработчикам полОжить на прибыль компании и её планы.», есть множество примеров достаточно крупных компаний, в которых этот тезис опровергается чуть более, чем полностью. Более того, его обратное звучание служит основой компании. Зачем сыпать шаблонами?
А вы не путаете культуру компании, в которой не приживаются люди с иными взглядами, и шаблон мысли абстрактного разработчика в вакууме? Положение о положении на прибыль относится к ситуации, когда в уже сложившейся культуре «мы тебе платим, ты работаешь» разработчику пытаются объяснить, что, если он не сделает то, что сказали, возможно, компания разорится.
Множество примеров достаточно крупных компаний? Можно услышать? А потом позовём сюда людей, работающих в этих компаниях, и спросим, спят ли они плохо по ночам, если компания вдруг недополучила прибыль. Недополучают ли они свои проценты с прибыли компании? :) И маячит ли у них в голове морковка, когда они пишут самый крутой в мире код?
Могу поверить, что такое есть, если речь о небольшой команде мотивированных пацанов, но достаточно крупная компания, как правило, имеет свои особенности, не позволяющие реализовать такой подход. В конце концов, в большинстве программных продуктов — просто код (или вообще говнокод), который иногда работает, и этого вполне достаточно.
Множество примеров достаточно крупных компаний? Можно услышать? А потом позовём сюда людей, работающих в этих компаниях, и спросим, спят ли они плохо по ночам, если компания вдруг недополучила прибыль. Недополучают ли они свои проценты с прибыли компании? :) И маячит ли у них в голове морковка, когда они пишут самый крутой в мире код?
Могу поверить, что такое есть, если речь о небольшой команде мотивированных пацанов, но достаточно крупная компания, как правило, имеет свои особенности, не позволяющие реализовать такой подход. В конце концов, в большинстве программных продуктов — просто код (или вообще говнокод), который иногда работает, и этого вполне достаточно.
Да возьмите тот же 2ГИС, на Хабре зарегистрирована куча сотрудников из отдела разработки. Спросите. Я к этой компании не имею никакого отношения, но та атмосфера которая доходит по разным каналам передает именно описанный мною расклад. Про свою контору не упоминаю, мы как раз относимся к вашему типа «мотивированных пацанов».
Могу подтвердить, как сотрудник 2ГИС.
Мы (разработчики) — в департаменте RnD, все что касается прибыли — это совсем другой департамент, и я практически никак не соприкасаюсь с этими вопросами. Мы пишем код, и стараемся делать это качественно не из-за прибыли, а… как бы это объяснить… Культура, видимо. Когда ты работаешь вместе с профессионалами своего дела (и при этом интересными, продвинутыми людьми), сам стараешься расти — как при этом можно написать в коде ерунду и спать спокойно?)
Мы (разработчики) — в департаменте RnD, все что касается прибыли — это совсем другой департамент, и я практически никак не соприкасаюсь с этими вопросами. Мы пишем код, и стараемся делать это качественно не из-за прибыли, а… как бы это объяснить… Культура, видимо. Когда ты работаешь вместе с профессионалами своего дела (и при этом интересными, продвинутыми людьми), сам стараешься расти — как при этом можно написать в коде ерунду и спать спокойно?)
Я тоже разработчик и тоже с опытом управления. Никогда не видел чтобы кто-то отвечал «это невозможно». Сейчас про себя вспомнить пытался, и вспомнил только один случай. Но там от нас хотели сделать кое-что, что противоречит паре фундаментальных теорем и я чётко сказал где противоречие, и чем из тех задания можно пожертвовать чтобы вернуть задачу в плоскость возможного. Какие-то у вас неправильные разработчики…
Бывает мотивация падает, когда никому ненужной ерундой занимаешься (у японцев-то вот не падает...), но чтобы вот прямо «невозможно» — такого не было.
Бывает мотивация падает, когда никому ненужной ерундой занимаешься (у японцев-то вот не падает...), но чтобы вот прямо «невозможно» — такого не было.
Прочитал статью, полный бред. Автору не повезло с разработчиками, и судя по манере изложения разработчикам не повезло с автором.
Про Макаревича вообще «песня»: на западе облизывают музыканта, чтобы было бабло, а у нас хотят чтобы песня красиво звучала. Ну и кто после этого *удак?
Про Макаревича вообще «песня»: на западе облизывают музыканта, чтобы было бабло, а у нас хотят чтобы песня красиво звучала. Ну и кто после этого *удак?
Прочитал статью, поржал — узнал некоторых знакомых. На работе такое регулярно, тимлид (ненаш) спрашивает на совещании разработчика (нашего), как сделать какую-нибудь штуку в системе, в которой этот наш разработчик разбирается лучше всех в компании. Наш разработчик отвечает: никак. Но тимлид с ним работает уже несколько лет и эту его особенность знает, поэтому через какое-то время выясняют, что сделать эту штуку можно дня за три.
Про ситуацию с Макаревичем есть такая шутка в тему:
Про ситуацию с Макаревичем есть такая шутка в тему:
Американский форум. Задаёшь вопрос, потом тебе отвечают.
Русский форум. Задаёшь вопрос, потом тебе долго рассказывают, какой ты мудак.
Эта шутка действительно на ту же тему, но она не про ситуацию с Макаревичем.
Про ситуацию с Макаревичем есть такая шутка в тему:
Американский форум. Задаёшь вопрос, потом тебе отвечают.
Русский форум. Задаёшь вопрос, потом тебе долго рассказывают, какой ты мудак.
Там еще в серединке было — про израильский форум: Задаешь вопрос, потом тебе задают вопрос)
«на западе облизывают музыканта, чтобы было бабло, а у нас хотят чтобы песня красиво звучала»
Нет, Вы неверно поняли. Музыкант − он автор. Он знает, как его песня должна звучать. Когда на западе музыканта облизывают, это делается не для бабла (хоть и за бабло), а для того, чтобы музыкант был здесь хозяином, потому что его его произведение. Если на западе звуковики пытаются что-то улучшить, они не говорят:
− Да ты ничего в этом не понимаешь, я сейчас тебе поставлю звук как надо.
Они говорят:
− Ты все отлично делаешь. Я хочу помочь тебе сделать еще лучше.
Это не «за бабло», это культура, при которой уважение выше личного статуса. Я об этом писал в своем комментарии ниже.
«Прибыль» в западном понимании, это совсем не «прибыль» в российском понимании. «Прибыль» в западном понимании, это:
− Мы стараемся, мы работаем, за это нам благодарность.
«Прибыль» в нынешнем российском понимании, это:
− За копейку удавится, ты посмотри на него!
Нет, Вы неверно поняли. Музыкант − он автор. Он знает, как его песня должна звучать. Когда на западе музыканта облизывают, это делается не для бабла (хоть и за бабло), а для того, чтобы музыкант был здесь хозяином, потому что его его произведение. Если на западе звуковики пытаются что-то улучшить, они не говорят:
− Да ты ничего в этом не понимаешь, я сейчас тебе поставлю звук как надо.
Они говорят:
− Ты все отлично делаешь. Я хочу помочь тебе сделать еще лучше.
Это не «за бабло», это культура, при которой уважение выше личного статуса. Я об этом писал в своем комментарии ниже.
«Прибыль» в западном понимании, это совсем не «прибыль» в российском понимании. «Прибыль» в западном понимании, это:
− Мы стараемся, мы работаем, за это нам благодарность.
«Прибыль» в нынешнем российском понимании, это:
− За копейку удавится, ты посмотри на него!
>Про Макаревича вообще «песня»: на западе облизывают музыканта, чтобы было бабло, а у нас хотят чтобы песня красиво звучала.
Красиво звучала по мнению звукотехника? А почему его мнение должно быть важнее мнения музыканта, который, собственно, эту песню написал, и который намного лучше знает, какую эмоциональную подоплёку он хотел в неё заложить?
Красиво звучала по мнению звукотехника? А почему его мнение должно быть важнее мнения музыканта, который, собственно, эту песню написал, и который намного лучше знает, какую эмоциональную подоплёку он хотел в неё заложить?
Если вы не знаете точную причину такого поведения наших программистов, то я вам расскажу. Они хотят делать то, что они хотят, что им нравится. Поначалу да, они работают за деньги и все хорошо. Но потом им становится скучно.
Я был по обе стороны баррикад. Когда вы говорите: «нормальная такая задача, не сложная но и не простая» мне приходит на ум что-то вроде парсинга данных, миграции и.т.д. Никто не загружен, работа не спешная и вот, только беларус решил заюзать новую либу — приходит американец и приносит опять «новое» задание.
Я был по обе стороны баррикад. Когда вы говорите: «нормальная такая задача, не сложная но и не простая» мне приходит на ум что-то вроде парсинга данных, миграции и.т.д. Никто не загружен, работа не спешная и вот, только беларус решил заюзать новую либу — приходит американец и приносит опять «новое» задание.
Странно, что программисты отвечали «это сделать невозможно». Думаю, автор чего-то недоговаривает. Возможно, он понял ситуацию как-то иначе и ищет подтверждения своей версии.
Просто среди моих знакомых программистов нет таких, кто не различает «долго и скучно» и «невозможно».
Просто среди моих знакомых программистов нет таких, кто не различает «долго и скучно» и «невозможно».
Да 100% все не так черно-бело, как описал автор. Возможные варианты:
— менеджер и продакт-менеджер мудаки, коих там великое множество, и хотели, скажем, чтобы в четкой блочной верстке дивы с анимацией по кругу местами менялись в IE 6 по мысли пользователя. В такой случае программисту не хватило красноречия вежливо и настойчиво объяснить, почему это невозможно, понять суть таска и предложить возможный вариант. Но скажу по печальному опыту — 5 раз объяснишь, 10 раз объяснишь, на двадцатый продакт уже не думает головой, а хочет чтобы ты думал за него. При то что зарплата у него в 2 раза выше, и вышестоящее руководство уверено в том, что все идеи его, он работает вовсю, а на тебе вон сколько багов;
— к сожалению, встречал программистов-интровертов с жутко завышенной самооценкой, которые если им не нравится таск, будут всеми силами его спихнуть. Когда я был тимлидом, с таким совершенно не хотелось работать — на долю всех доставались скучные таски, и я делал кучу рутинной работы. Хуже не придумаешь, как если в команде кто-то начинает особо звездиться и ставить себя выше других. Кстати, экстраверты реже страдают звездной болезнью — они много общаются и видят, что не они одни хорошие опытные программисты на этом свете. А интроверт бог в своем мире, и привык считать себя богом во внешнем.
— менеджер и продакт-менеджер мудаки, коих там великое множество, и хотели, скажем, чтобы в четкой блочной верстке дивы с анимацией по кругу местами менялись в IE 6 по мысли пользователя. В такой случае программисту не хватило красноречия вежливо и настойчиво объяснить, почему это невозможно, понять суть таска и предложить возможный вариант. Но скажу по печальному опыту — 5 раз объяснишь, 10 раз объяснишь, на двадцатый продакт уже не думает головой, а хочет чтобы ты думал за него. При то что зарплата у него в 2 раза выше, и вышестоящее руководство уверено в том, что все идеи его, он работает вовсю, а на тебе вон сколько багов;
— к сожалению, встречал программистов-интровертов с жутко завышенной самооценкой, которые если им не нравится таск, будут всеми силами его спихнуть. Когда я был тимлидом, с таким совершенно не хотелось работать — на долю всех доставались скучные таски, и я делал кучу рутинной работы. Хуже не придумаешь, как если в команде кто-то начинает особо звездиться и ставить себя выше других. Кстати, экстраверты реже страдают звездной болезнью — они много общаются и видят, что не они одни хорошие опытные программисты на этом свете. А интроверт бог в своем мире, и привык считать себя богом во внешнем.
Вот именно, детский сад какой-то. Уверен, что программист не отвечал, как описано в статье:
-Почему нельзя сделать?
-Потому!
Иначе непонятно, как такого неадеквата приняли на работу.
-Почему нельзя сделать?
-Потому!
Иначе непонятно, как такого неадеквата приняли на работу.
>Они хотят делать то, что они хотят, что им нравится. Поначалу да, они работают за деньги и все хорошо. Но потом им становится скучно.
Вот тут и происходит конфликт интересов. Компания платит деньги программистам не за то, чтобы им было весело. Им платят деньги за то, чтобы они делали свою работу, приносящую прибыль компании.
«Мне это скучно, я не хочу этого делать» — верх непрофессионализма, и я бы даже сказал инфантилизма.
Вот тут и происходит конфликт интересов. Компания платит деньги программистам не за то, чтобы им было весело. Им платят деньги за то, чтобы они делали свою работу, приносящую прибыль компании.
«Мне это скучно, я не хочу этого делать» — верх непрофессионализма, и я бы даже сказал инфантилизма.
Мне кажется, вы совершенно правы.
Я работаю заграницей. Не так давно у меня был российский коллега. Каждая фича оборачивалась в многочасовую дискуссию о том, как этого сделать нельзя, и как вообще всё надо давно переписать. Особенно это было неуместно, когда решение было очевидно, а сроки сдачи коротки. Может, просто человек был такой, а, может, это тенденция. В любом случае, я рад, что больше не нужно с ним сотрудничать.
Вот ещё один пример того, что "[российские программисты] часто начинают думать почему проблему решить нельзя". Я заметил, что если поделиться идеей какого-либо проекта с иностранным коллегой, то обычно в ответ звучит что-то вроде «давай, попробуй, вперёд». Соотечественники же обычно приводят ряд примеров, показывающих, что ничего не получится. Надо сказать, что я себя тоже часто на этом ловлю.
Я работаю заграницей. Не так давно у меня был российский коллега. Каждая фича оборачивалась в многочасовую дискуссию о том, как этого сделать нельзя, и как вообще всё надо давно переписать. Особенно это было неуместно, когда решение было очевидно, а сроки сдачи коротки. Может, просто человек был такой, а, может, это тенденция. В любом случае, я рад, что больше не нужно с ним сотрудничать.
Вот ещё один пример того, что "[российские программисты] часто начинают думать почему проблему решить нельзя". Я заметил, что если поделиться идеей какого-либо проекта с иностранным коллегой, то обычно в ответ звучит что-то вроде «давай, попробуй, вперёд». Соотечественники же обычно приводят ряд примеров, показывающих, что ничего не получится. Надо сказать, что я себя тоже часто на этом ловлю.
Честно говоря, полностью противоположный опыт. Как раз американцы/европейцы любят на внеплановый запрос отвечать, что сделать невозможно, или же давать оценку в районе пары человеко-месяцев. А восточно-европейские разработчики загораются в духе «фигня вопрос, сейчас вставим за часик». У них скорее беда с частой и довольно серьезной недооценкой сложности задач.
Очень зависит от постановки.
В вашем случае она была, предположительно, такой: «Задумана блестящая фишка, влекущая азартную задачу, и пофигу, что её не было в техзадании».
Но западный люд услышал это как «Давай проведём эксперимент за твой счёт, за счёт твоих проектов и жизни».
В вашем случае она была, предположительно, такой: «Задумана блестящая фишка, влекущая азартную задачу, и пофигу, что её не было в техзадании».
Но западный люд услышал это как «Давай проведём эксперимент за твой счёт, за счёт твоих проектов и жизни».
Согласен — у нас американцы часто говорит, что сделать нельзя, хотя решение есть.
Думаю, и эта старая байка тут будет в тему.
Что-то это все мне напоминает.
Потому и напоминает, что «специальный сайт» слизан с вот этого xn-----clcksaplxf6byd3cyb.xn--p1ai/, который в свою очередь является адаптацией того самого «Programming, motherfucker!»
Но в отличие от сайта автора статьи, они хотя бы честно указали в футере:
Но в отличие от сайта автора статьи, они хотя бы честно указали в футере:
Вы просили написать, почему минус. Статья читается так: Автор, весь в белом, тимлид с огромным опытом, с идеальным английским, да ещё и код пишет каждый день, жалуется на то, что братья славяне, его подчинённые, вокруг все такие дураки ленивые.
Жанр прямо скажем не нов. Вот только при чём здесь хабр? Где проблема, где анализ, где решение? Например, решением может стать перестать нанимать «наших» разработчиков.
Или
Правда?
Жанр прямо скажем не нов. Вот только при чём здесь хабр? Где проблема, где анализ, где решение? Например, решением может стать перестать нанимать «наших» разработчиков.
Или
вместо того, чтобы начать думать, как решить проблему они часто начинают думать почему проблему решить нельзя
По-моему эта статья — самое важное, что я в жизни сделал.
Правда?
Спасибо, понял.
Вообще-то автора можно полностью убрать из повествования. Оставить только ключевое противостояние американцы--наши.
Статья фактически про одну мысль: Problem Solving Skills for Russians.
А как бы вы написали статью чтобы выполнить её цель? (по-настоящему повысить эффективность у читателей)
Вообще-то автора можно полностью убрать из повествования. Оставить только ключевое противостояние американцы--наши.
Статья фактически про одну мысль: Problem Solving Skills for Russians.
А как бы вы написали статью чтобы выполнить её цель? (по-настоящему повысить эффективность у читателей)
Вообще-то автора можно полностью убрать из повествования.
Да, это вообще хороший стиль.
По сути, я с вами не согласен лишь в чрезмерном обобщении. Но я думаю, что проблема лежит в другой плоскости. Всё дело в культуре менеджмента. Возможно, это советское прошлое из нас всё выветриться не может. Но у нас менеджер считает, что если он потребует сделать задачу в меньший срок и надавит на подчинённого, то и результат он получит быстрее и, стало быть, порадует своего начальника. Однако, третий закон Ньютона продолжает повторять, что на любое действие обязательно появится противодействие. И вот такое искусственное завышение сложности задачи и есть та самая компенсация, в надежде выторговать себе больше времени. Разработчик просто привык сопротивляться «эффективным» менеджерам и пытается, иногда, всё-таки встретится со своими близкими.
Порой разработчик перегибает, конечно, и в этом вы правы.
Я бы чуть наклонил вашу проблему, взгляните на это так: «очевидно полезная, нужная конечному пользователю, не двусмысленно со всех сторон полезная», не вызывающая сомнений вещь, похоже, вызвала-таки сомнения у потенциального исполнителя.
И тут возникает два варианта: а) исполнитель компетентен и может предполагать, во что выльется затея, в том числе для вашей компании; он рассказывает вам об этом, пытается пояснить, но вы ведь не слушаете, вам по-прежнему нужно узнать «как это сделать»; б) исполнитель некомпетентен, ленится.
В обоих случаях вам лучше распрощаться: а) исполнитель сможет найти место, где к нему будут прислушиваться; б) вы избавитесь от лодыря.
И тут возникает два варианта: а) исполнитель компетентен и может предполагать, во что выльется затея, в том числе для вашей компании; он рассказывает вам об этом, пытается пояснить, но вы ведь не слушаете, вам по-прежнему нужно узнать «как это сделать»; б) исполнитель некомпетентен, ленится.
В обоих случаях вам лучше распрощаться: а) исполнитель сможет найти место, где к нему будут прислушиваться; б) вы избавитесь от лодыря.
Как улучшить: сделать так, чтобы было понятно, что в голове у разработчика. Что у вас в голове, лично я понял ($$$).
А не возникал у вас вопрос, не слишком ли сильно вы обобщили? Обычно, чтобы делать такое утверждение нужна выборка побольше, чем несколько случаев из личного опыта.
Как бы это забавно не звучало, но я с вами несогласен :) То, что вы описали на самом деле как раз и является проблемой начальник-подчиненный, а именно ситуацией с проблемной коммуникацией в коллективе. С русскими, в виду особенностей культуры и менталитета, а именно меньшим уровнем толлератности и способности к эскалации конфликтов (о чем, кстати, писали в указанной вами статье), подобные ситуации могут проявляться чаще. Но это вовсе не означает, что это характерная особенность наших программистов и что какой-нибудь немец или поляк не сможет оказаться в данной ситуации.
Менеджер, пускай и пишущий код, и разработчик — имеют совершенно разную роль и мотивации в коллективе. Первый нацелен на выполнение задач, второй на сам процесс и всевозможные аспекты имплементации. У менеджера таски в джире, которые нужно закрывать, а у разработчика говнокод в редакторе, который еще поддерживать надо. Поэтому неудивительно, что в виду данного конфликта интересов у разработчика всегда будет альтернативное мнение: либо нельзя сделать, либо можно, но подругому, либо еще 100500 вариантов. А для менеджера зачастую, особенно вышедшего из разработчика, включается максимализм и понятие «сделанное не по моему» превращается в эквивалент «отказался делать». Вот и все особенности.
Я сам успел побывать по обе стороны баррикад. Еще полтора года назад пытался доказать своему французскому менеджеру, что подобное решение не взлетит и работать будет с жуткими глюками, а делать нужно по-другому (и таки все развивалось по предсказанному мною сценарию). А уже спустя несколько месяцев предпринимая попытки оказаться в роли архитекта пытался донести свое решение своим новым коллегам.
И вот что я вам скажу:
— коммуницируйте и общайтесь, обсуждайте требования и архитектуру с исполнителями;
— не игнорируйте мнение разработчика, т.к. он специалист и многие аспекты понимает лучше, чем играющий тренер :)
— пройдите процесс притирки коллектива и работа пойдет быстрее.
Кстати, признаюсь, статью было осилить нелегко в виду тяжелого языка изложения.
Менеджер, пускай и пишущий код, и разработчик — имеют совершенно разную роль и мотивации в коллективе. Первый нацелен на выполнение задач, второй на сам процесс и всевозможные аспекты имплементации. У менеджера таски в джире, которые нужно закрывать, а у разработчика говнокод в редакторе, который еще поддерживать надо. Поэтому неудивительно, что в виду данного конфликта интересов у разработчика всегда будет альтернативное мнение: либо нельзя сделать, либо можно, но подругому, либо еще 100500 вариантов. А для менеджера зачастую, особенно вышедшего из разработчика, включается максимализм и понятие «сделанное не по моему» превращается в эквивалент «отказался делать». Вот и все особенности.
Я сам успел побывать по обе стороны баррикад. Еще полтора года назад пытался доказать своему французскому менеджеру, что подобное решение не взлетит и работать будет с жуткими глюками, а делать нужно по-другому (и таки все развивалось по предсказанному мною сценарию). А уже спустя несколько месяцев предпринимая попытки оказаться в роли архитекта пытался донести свое решение своим новым коллегам.
И вот что я вам скажу:
— коммуницируйте и общайтесь, обсуждайте требования и архитектуру с исполнителями;
— не игнорируйте мнение разработчика, т.к. он специалист и многие аспекты понимает лучше, чем играющий тренер :)
— пройдите процесс притирки коллектива и работа пойдет быстрее.
Кстати, признаюсь, статью было осилить нелегко в виду тяжелого языка изложения.
То, что вы описали на самом деле как раз и является [...] ситуацией с проблемной коммуникацией в коллективе.
Кстати, признаюсь, статью было осилить нелегко в виду тяжелого языка изложения.
Я тоже заподозрил проблемы коммуникации. В первой ситуации задачу устно ставил автор статьи (который не смог чётко изложить свои мысли даже в письменной форме). Во второй ситуации вообще имеел место языковой барьер.
статья отличное, многое видел на своими глазами
За сайт спасибо, отправлю кое-кому из коллег…
Несколько идей:
1. Культурные особенности существуют, конечно. Поэтому квалификация американского менеджера, рассмотренного в примере, вызывает сомнения — не знание особенностей тех, с кем работать, приводит к печальным последствиям.
2. А может вы подсознательно выстраиваете такую линию поведения, которая приводит к таким результатам? А потом из множества событий запоминаете те, которые подтверждают вашу точку зрения?
3. Профессионализм в своей области — хорошая штука. Когда человек идете к врачу, ему обычно хочется, что бы его вылечили. А не со всей деликатностью приложили подорожник и крайне любезно отправили домой. Ну почуствует он себя человеком важным и у него останутся самые приятные воспоминания о визите… Не надолго только вот…
1. Культурные особенности существуют, конечно. Поэтому квалификация американского менеджера, рассмотренного в примере, вызывает сомнения — не знание особенностей тех, с кем работать, приводит к печальным последствиям.
2. А может вы подсознательно выстраиваете такую линию поведения, которая приводит к таким результатам? А потом из множества событий запоминаете те, которые подтверждают вашу точку зрения?
3. Профессионализм в своей области — хорошая штука. Когда человек идете к врачу, ему обычно хочется, что бы его вылечили. А не со всей деликатностью приложили подорожник и крайне любезно отправили домой. Ну почуствует он себя человеком важным и у него останутся самые приятные воспоминания о визите… Не надолго только вот…
Хорошая статья, еще отмечу из личного (и не личного) опыта: Ставишь задачу, обсуждаешь, говоришь почему нужно её сделать так, как она стоит, почему не нужны некоторые фишки и тд.После этого спокойно занимаешься дальнейшими делами. Через некоторое время задача выполняется и в ней ты видишь все то, что обсуждалось как «этого делать не надо». Другими словами, наши программисты любят делать не совсем (или совсем не) то, что нужно (как частное из «этого сделать нельзя», но немного в изощренной форме). И если нет возможности контролировать задачу поэтапно — то можно получить в конце то, что хотелось сделать программисту, а не результат выполнения задачи.
Это не особенность «наших» программистов, а особенность программирования в целом. Происходит это от недопонимания что должно получиться в конце или от недостатка времени на решение задачи, соответственно это проблема не только программиста, но и человека который ставит задачи.
Хорошо, приведу конкретный пример. Достаточно простой, но отражающий суть.
В связи с переносом сайта возникла необходимость обновиться на новую версию форума phpbb.
У фирмы было некоторое количество зарегистрированных пользователей, несколько тысяч сообщений на сервере и пара модераторов.
Т.к. сам сайт представлял из себя визитку, то он был уже перенесен. Для форума был создан свой поддомен, был найден исполнитель, который бы обновил старую версию форума.
При обсуждении исполнителем было предложено «давайте поставим vbullietin, он лучше, более функционален и у меня есть куча модулей, которые вам могли бы быть полезны.», на что был дан ответ " нам нужен именно phpbb, т.к. наши модераторы привыкли к его админке, он бесплатен и полностью нас устраивает". Ответных споров не последовало, после чего человеку был дан доступ и внесена предоплата. Через 2 дня человек пишет «все готово», после чего мы видим установленный nulled vBullietin с импортированной в него нашей базой.
Какое в этом случае было недопонимание и почему это проблема человека, который ставит задачи?
В связи с переносом сайта возникла необходимость обновиться на новую версию форума phpbb.
У фирмы было некоторое количество зарегистрированных пользователей, несколько тысяч сообщений на сервере и пара модераторов.
Т.к. сам сайт представлял из себя визитку, то он был уже перенесен. Для форума был создан свой поддомен, был найден исполнитель, который бы обновил старую версию форума.
При обсуждении исполнителем было предложено «давайте поставим vbullietin, он лучше, более функционален и у меня есть куча модулей, которые вам могли бы быть полезны.», на что был дан ответ " нам нужен именно phpbb, т.к. наши модераторы привыкли к его админке, он бесплатен и полностью нас устраивает". Ответных споров не последовало, после чего человеку был дан доступ и внесена предоплата. Через 2 дня человек пишет «все готово», после чего мы видим установленный nulled vBullietin с импортированной в него нашей базой.
Какое в этом случае было недопонимание и почему это проблема человека, который ставит задачи?
А сам исполнитель-то как свою глухоту/слепоту объясняет?
«Так было лучше», не более того. Вот именно такой ответ я слышал не один раз.
Детский сад какой-то =)
Ну в любом случае перед отправкой денег, нужно подытожить каким-либо документом (истории переписок не подходят, ибо там чёрт ногу сломит, при активном обсуждении), где описано по каким параметрам будет оценена работа, тогда подобных ситуаций не будет возникать.
Ну в любом случае перед отправкой денег, нужно подытожить каким-либо документом (истории переписок не подходят, ибо там чёрт ногу сломит, при активном обсуждении), где описано по каким параметрам будет оценена работа, тогда подобных ситуаций не будет возникать.
Конкретно в этом случае деньги не играли роли, да и кроме 50% предоплаты исполнитель не получил ничего. Больше жалко потраченного времени.
На мелких проектах с достаточно конкретизированными задачами странно получить такой результат.
Другое дело — человек работает в на постоянке, тут уже это более чем странно. Если в первом случае можно просто разойтись и найти нового исполнителя, то в этом случае все варианты с плохим исходом (ну, кроме того, что это может быть единичный случай и после беседы он не повторяется. Тут и говорить не о чем.)
На мелких проектах с достаточно конкретизированными задачами странно получить такой результат.
Другое дело — человек работает в на постоянке, тут уже это более чем странно. Если в первом случае можно просто разойтись и найти нового исполнителя, то в этом случае все варианты с плохим исходом (ну, кроме того, что это может быть единичный случай и после беседы он не повторяется. Тут и говорить не о чем.)
Все это сугубо субъективно, без конкретных примеров и обсуждать нечего.
Мне как разработчику очень часто приходилось к «автомобилю» приделывать «гребной винт с подводными крыльями» потому как с точки зрения заказчика/руководства это очень полезная фича, которую в принципе можно реализовать и несомненно это увеличивает пользовательскую базу с «автолюбителей» до «яхтсменов» т.к. все они просто мечтают об авто на подводных крыльях и готовы платить за это кучу денег.
В общем потом приходилось подводные крылья и гребные винты отрезать т.к. машинка почему-то с ними очень плохо ездила.
И вообще зачастую все эти «вдруг» возникающие по ходу разработки замечательные идеи без привязки к архитектуре проекта очень похожи на это:
Мне как разработчику очень часто приходилось к «автомобилю» приделывать «гребной винт с подводными крыльями» потому как с точки зрения заказчика/руководства это очень полезная фича, которую в принципе можно реализовать и несомненно это увеличивает пользовательскую базу с «автолюбителей» до «яхтсменов» т.к. все они просто мечтают об авто на подводных крыльях и готовы платить за это кучу денег.
В общем потом приходилось подводные крылья и гребные винты отрезать т.к. машинка почему-то с ними очень плохо ездила.
И вообще зачастую все эти «вдруг» возникающие по ходу разработки замечательные идеи без привязки к архитектуре проекта очень похожи на это:
Все это сугубо субъективно, без конкретных примеров и обсуждать нечего.
Именно! В тексте только абстрактные примеры «задач», а между строк я так и вижу диалоги:
— Нужно сделать, чтобы никто не мог сохранять картинки с сайта…
— Это невозможно. Если что-то отобразилось на экране, то это можно сохранить.
— Можно же накрутить сессии, порезать картинки на полосочки, спамить буфер обмена для защиты от Print Screen…
— Всё равно невозможно.
— Ты уволен.
— Нужно переместить вот эти кнопочки вот этот попапчик…
— Это невозможно. Релиз через неделю, 1500 автотестов полетит, тестировщики загнутся.
— Ты главное перемести, а тестировщики что-нибудь придумают.
— Всё равно невозможно.
— Ты уволен.
— Нужно заспасмить 2500 форумов нашими ссылками, подкрутить количество подписчиков в фейсбуке…
— Это невозможно. Нас гугл и фейсбук забанят, и вообще я только белым СЕО занимаюсь.
— Ты главное заспамь и подкрути, а если забанят — будем думать.
— Всё равно невозможно.
— Ты уволен.
Ваш «гребной винт с подводными крыльями» — тоже замечательный пример.
И ведь в каждом случае менеджера можно оправдять: «Это же простая задача! Это же во благо доходов компании! Ты что, сраный подчинённый, нелоялен компании?!»
НЛО прилетело и опубликовало эту надпись здесь
То есть, по-вашему, нужно выполнить приказ, не смея перечить, а если что — «моя хата с краю, ничего не знаю»?
НЛО прилетело и опубликовало эту надпись здесь
Как в армии — приказ подлежит обжалованию только после его выполнения
Давайте дополню вас цитатой.
Аркадий И Борис Стругацкие. Обитаемый остров:
Как метко…
Аркадий И Борис Стругацкие. Обитаемый остров:
— А где это сказано в уставе, — спросил Гай, усмехаясь, — чтобы подчинённый делал замечания своему начальнику?
— Там сказано противоположное, — со вздохом признался Максим. — По-моему, это неверно. Ты ведь слушаешь мои советы, когда решаешь задачи по баллистике, и ты слушаешь мои замечания, когда ошибаешься в вычислениях.
— Это дома! — проникновенно сказал Гай. — Дома всё можно.
— А если на стрельбах ты неправильно даёшь нам прицел? Плохо учёл поправку на ветер. А?
— Ни в коем случае, — твёрдо сказал Гай.
— Стрелять неправильно? — изумился Максим.
— Стрелять как приказано, — строго сказал Гай. — За эти десять минут, Мак, ты наговорил суток на пятьдесят карцера. Понимаешь?
— Нет, не понимаю… А если в бою?
— Что — в бою?
— Ты даёшь неправильный прицел. А?
— Гм… — сказал Гай, который ещё никогда в бою не командовал. Он вдруг вспомнил, как капрал Вахту во время разведки боем запутался в карте, загнал секцию под кинжальный огонь соседней роты, сам там остался и полсекции уложил, а ведь мы знали, что он запутался, но никто не подумал его поправить.
«Господи, — сообразил вдруг Гай, — да нам бы и в голову не пришло, что можно его поправить. А вот Максим этого не понимает и даже не то что не понимает — понимать тут нечего, — а просто не признаёт. Сколько раз уже так было: берёт самоочевидную вещь и отвергает её, и никак его не убедишь, и даже наоборот — сам начинаешь сомневаться, голова идёт кругом, и приходишь в полное обалдение… Нет, он всё-таки не обыкновенный человек… редкий, небывалый человек…»
Как метко…
Вы какую-то совсем фантастику рассказываете. Чтобы менеджер был уволен.
В крайнем случае вместе со всей командой, и то, скорее всего, останется.
В крайнем случае вместе со всей командой, и то, скорее всего, останется.
НЛО прилетело и опубликовало эту надпись здесь
По-моему скромному опыту это проблема характерна не только среди разработчиков, а вообще для большинства россиян. И лежит не в плоскости менеджмента, а гораздо глубже, где-то на уровне воспитания.Такая генетическая особенность искать проблемы. :) Никто в мире не умеет так находить проблемы, как наши соотечественники. Распространяется на все сферы.
Появилась идея бизнеса? Ответ иностранца: Да, давай, класс! дерзай, обращайся если нужна помощь.
У россиянина же найдется тысяча причин почему это сделать нельзя. Налогами задушат, работники разворуют, бандиты задавят, проверками завалят, законами загубят.
Решил записаться в спортзал и привести себя в форму? Воу, воу, полегче парень! Куда тебе такому жирному/худому идти? Посмотри на себя, ничего не выйдет, тут генетика нужна! А знаешь, сколько добавки стоят? А сколько времени нужно потратить? Не, даже пытаться не стоит.
Даже в научной среде. Решил что-то добавить в свою научную работу, идешь к научнику. И вместо предложений как это можно реализовать, получаешь 20 миллионов причин почему это сделать никогда не получится и что даже пытаться не стоит. Что, привел 20 миллионов причин «за»?? ничего, вот еще парочка тысяч новых «нет». У кого такое было, поднимите руку!
Хочешь поступить, например, в МГУ? хмм, не стоит пытаться там все по блату, все куплено-продано и т.д
Добавить фичу в приложение? Готовься к многочасовому спору.
Знакомо? И такое везде, в магазинах, в разговорах в общественном транспорте, на форумах. Такая фанатичная настроенность на поиск причин «почему не получится». И надо сказать, что я себя тоже часто на этом ловлю. Но стараюсь бороться.
Появилась идея бизнеса? Ответ иностранца: Да, давай, класс! дерзай, обращайся если нужна помощь.
У россиянина же найдется тысяча причин почему это сделать нельзя. Налогами задушат, работники разворуют, бандиты задавят, проверками завалят, законами загубят.
Решил записаться в спортзал и привести себя в форму? Воу, воу, полегче парень! Куда тебе такому жирному/худому идти? Посмотри на себя, ничего не выйдет, тут генетика нужна! А знаешь, сколько добавки стоят? А сколько времени нужно потратить? Не, даже пытаться не стоит.
Даже в научной среде. Решил что-то добавить в свою научную работу, идешь к научнику. И вместо предложений как это можно реализовать, получаешь 20 миллионов причин почему это сделать никогда не получится и что даже пытаться не стоит. Что, привел 20 миллионов причин «за»?? ничего, вот еще парочка тысяч новых «нет». У кого такое было, поднимите руку!
Хочешь поступить, например, в МГУ? хмм, не стоит пытаться там все по блату, все куплено-продано и т.д
Добавить фичу в приложение? Готовься к многочасовому спору.
Знакомо? И такое везде, в магазинах, в разговорах в общественном транспорте, на форумах. Такая фанатичная настроенность на поиск причин «почему не получится». И надо сказать, что я себя тоже часто на этом ловлю. Но стараюсь бороться.
Ну а кто выбирал режим «nightmare» при логине в мир? Нефиг теперь жаловаться, что попал в Россию.
НЛО прилетело и опубликовало эту надпись здесь
Это правда и мне это очень грустно. Я для себя сформулировал, что есть «люди возможностей» и «люди рисков». Первые в большинстве новых событий или событий за пределами зоны комфорта ищут возможности (часто в ущерб оценке рисков — например, хватаясь за заведомо проигрышное дело). Вторые — в большинстве ищут риски (часто в ценой упущенных возможностей).
Первые — предприниматели, топ-менеджмент (в т.ч. директора по развитию), стартаперы, их 10% от популяции. Вторые — все остальные, их 90% от популяции.
Вероятно, если бы вторые не тормозили первых, первые все рано или поздно разорились. А если бы не первые, вторые вообще ничего нового бы не сделали.
Выходит, что прогресс достигается постоянной кровавой борьбой первых и вторых. И меня, как первого, это заставляет сильно расстраиваться — мне так всю жизнь жить…
Первые — предприниматели, топ-менеджмент (в т.ч. директора по развитию), стартаперы, их 10% от популяции. Вторые — все остальные, их 90% от популяции.
Вероятно, если бы вторые не тормозили первых, первые все рано или поздно разорились. А если бы не первые, вторые вообще ничего нового бы не сделали.
Выходит, что прогресс достигается постоянной кровавой борьбой первых и вторых. И меня, как первого, это заставляет сильно расстраиваться — мне так всю жизнь жить…
Встречал подобное поведение. Что интересно — встречал редко, и ни разу у «наших» разработчиков. Последний раз видел у одного американца, который долгое время являлся единственным разработчиком довольно крупной и сложной инфраструктурной штуковины и при этом являлся очень «opinionated» в любых вопросах, касающихся этой штуки. В конце концов он попросту потерял контроль над этой штуковиной именно по этой причине — с ним было очень сложно обсуждать дальнейшую «судьбу» этой штуки (а штука — весьма важная для внутренней инфраструктуры), хотя его квалификация ни у кого не вызывала вопросов.
Просто отечественный разработчик достаточно смел, ответственнен и честен, чтобы сказать «нет». Как ни странно это может показаться, но согласиться и отправиться писать говногод (который в конечном итоге выльется в огромный геморой как для заказчика, так и для разработчиков) намного проще, чем ответить начальнику, что его идея плоха.
Я 2 года проработал в конторе занимающейся внедрением и настройкой ERP систем, столько негатива за весь предыдущий опыт работы я не получал. За все 2 года из нескольких десятков клиентов не было ни одного, кто остался бы доволен. И дело не в том, что контора такая плохая или разработчики дураки, имхо на местном рынке они одни из лучших, просто такие компании не могут сказать «нет» клиенту, когда тот просит откровенно идиотский костыль совершенно не вписывающийся в рамки системы. Логика проста — если мы не сделаем, сделает кто-то другой, так что деньги пройдут мимо, так что беремся и говнокодим, а потом гори оно все огнем.
Я 2 года проработал в конторе занимающейся внедрением и настройкой ERP систем, столько негатива за весь предыдущий опыт работы я не получал. За все 2 года из нескольких десятков клиентов не было ни одного, кто остался бы доволен. И дело не в том, что контора такая плохая или разработчики дураки, имхо на местном рынке они одни из лучших, просто такие компании не могут сказать «нет» клиенту, когда тот просит откровенно идиотский костыль совершенно не вписывающийся в рамки системы. Логика проста — если мы не сделаем, сделает кто-то другой, так что деньги пройдут мимо, так что беремся и говнокодим, а потом гори оно все огнем.
Очень странные у вас разработчики. Как можно спорить о реальности выполнения задачи, не проанализировав ее?
Я бы очень удивился, если бы разработчик отказался от задачи с rationale типа «нельзя сделать, потому что нельзя» — это пройдет за ответ на задачу, придуманную людьми из параллельной вселенной, но в случае с нормальной вызовет у непосредственного начальства недоумение как минимум.
Отказ от задачи без наличия весомой на то причины вполне логично рассматривается любым начальством как нежелание работать в принципе.
Я бы очень удивился, если бы разработчик отказался от задачи с rationale типа «нельзя сделать, потому что нельзя» — это пройдет за ответ на задачу, придуманную людьми из параллельной вселенной, но в случае с нормальной вызовет у непосредственного начальства недоумение как минимум.
Отказ от задачи без наличия весомой на то причины вполне логично рассматривается любым начальством как нежелание работать в принципе.
Как можно спорить о реальности выполнения задачи, не проанализировав ее?
На некоторые задачи достаточно миллисекунд анализа. Вон, например, выше говорили о задаче «обеспечить невозможность копирования картинки с экрана». Есть только один способ её решить — не выводить картинку на экран. Точка. Что тут ещё анализировать?
Вот смотрите, я думаю над этой задачей больше, чем ваши несколько миллисекунд. Ровно к концу чтения вашего поста у меня есть такая идея: не рисовать картинку целиком. Человеческий глаз имеет определенную границу частоты, перерисовывая изображение «построчно» с частотой, выше этой границы мы будем «видеть» картинку целиком, а любой «принтскрин» захватит только мгновенное содержимое канваса, и там будет лишь кусок изображения. Я что — «золотой мальчик»?) Нет, просто ищу решения) Вполне можно усложнить этот алгоритм, чтобы заскринить изображение было еще сложнее. Было бы желание и достаточно денег на разработку! =)
Вы решаете не ту задачу. Вы усложняете копирование, но не делаете его невозможным.
Вы же привязываетесь к формулировке задачи и на основании точного следования ей говорите: «Невозможно». Тогда как постановщик задачи может не разбираться в таких тонкостях и вполне будет удовлетворен решением на уровне «скопировать очень сложно» — если ему объяснить ситуацию, а не говорить «нет». Потому что ему, вероятно, нужно хоть какое-то решение проблемы, пусть и формулируемое по другому.
Так проблема в том, что он не формулирует проблему, а предлагает реализовать выбранное им на основе неизвестных мне критериев решение. То есть я должен догадаться какая проблема, какие критерии для решения, какие решения ещё были рассмотрены и отброшены, чтобы предложить ему разумные варианты. Не будет ли эффективнее если он сначала мне проблему опишет, критерии, а свой вариант предложит именно как вариант?
Так это и есть ваша работа.
Вот смотрите. Вы делаете ремонт, просите развести проводку по комнате. Если электрик квалифицированный, он сделает два-три контура (освещение/розетки/кондиционер). А если новичок — пробросит от щитка одну пару, и в коробе на потолке разведет её на все источники. Задачу-то он решил, но если у вас ночью ребенок что-то всунет в розетку — автоматика оставит вас без света. Вы, как типовой житель не должны знать ничего про контуры. про «автоматы», про необходимость разводить «землю», про амперы…
Таких задач уйма, и именно поэтому настоящих профи, которые стоят от 100к фиг найдешь. Но они отрабатывают свои деньги за счет огромного сокращения потока коммуникаций между разрабом и постановщиком задачи. Сказал «прилепи форум» — и он его лепит. Какой? Да погуглил, поспрашивал знакомых, посмотрел какой лучше прикрутить и приделал. Не тот? Переделает. Получается, что частично такой работник берет на себя задачи менеджера/тимлида/архитектора… но и зарабатывает больше «обычного») Такому человеку приятно платить зарплату, как и любому профи в своем деле.
Я не спорю и не доказываю ничего, если что) Работники, которым нужно поставить четкую задачу и они будут копать "от забора и до обеда"(с) тоже очень нужны! =)
Вот смотрите. Вы делаете ремонт, просите развести проводку по комнате. Если электрик квалифицированный, он сделает два-три контура (освещение/розетки/кондиционер). А если новичок — пробросит от щитка одну пару, и в коробе на потолке разведет её на все источники. Задачу-то он решил, но если у вас ночью ребенок что-то всунет в розетку — автоматика оставит вас без света. Вы, как типовой житель не должны знать ничего про контуры. про «автоматы», про необходимость разводить «землю», про амперы…
Таких задач уйма, и именно поэтому настоящих профи, которые стоят от 100к фиг найдешь. Но они отрабатывают свои деньги за счет огромного сокращения потока коммуникаций между разрабом и постановщиком задачи. Сказал «прилепи форум» — и он его лепит. Какой? Да погуглил, поспрашивал знакомых, посмотрел какой лучше прикрутить и приделал. Не тот? Переделает. Получается, что частично такой работник берет на себя задачи менеджера/тимлида/архитектора… но и зарабатывает больше «обычного») Такому человеку приятно платить зарплату, как и любому профи в своем деле.
Я не спорю и не доказываю ничего, если что) Работники, которым нужно поставить четкую задачу и они будут копать "от забора и до обеда"(с) тоже очень нужны! =)
Так в том и дело, что когда я ставлю задачу электрику, то не решаю её за него, оставив только реализацию за ним. Не говорю какие провода откуда и куда вести, какие автоматы ставить и т. п. И уж тем более не требую запитать трехфазную плиту на 10 кВт без проводов в квартире, где однофазный ввод на 25 А. И не буду его увольнять услышав в ответ «невозможно», даже если предложу. А вот разработчика, сказавшего «невозможно» в ответ на предложение установить форум на C#+ASP .NET MVC на шаред хостинг с PHP, судя по посту и некоторым комментам, вполне могут уволить.
Может быть, будет немного не в тему, но скажу, как я научился искать не проблему, а решение. И это олимпиадное программирование, так шумевшее в последние дни в связи с финалом ICPC. После решения кучи олимпиадных задач, когда есть четкое условие и гарантия, что задача решаема, привыкаешь к модели мышления «решение есть, но я его еще не придумал или пока не знаю такого метода». И уже в процессе обдумывания возникает несколько вариантов, как можно немного изменить условия, чтобы ты мог сесть и начать писать код. Так что даже если ты не придумаешь решения к начальной задаче, ты всегда можешь предложить менеджеру несколько других вариантов со слегка другими условиями.
Может быть, это одна из причин, почему олимпиадников так любят в крупных компаниях.
Может быть, это одна из причин, почему олимпиадников так любят в крупных компаниях.
Решение есть почти всегда. Но достаточно часто лучше было бы, если этого решения не было. Возникает только вопрос — кому лучше?
Это вам хорошие задачки попадались. Я на институтской олимпиаде по начерталке доказал, что решения не существует (точнее, в задаче было сказано найти точку, но условию отвечала целая бесконечная кривая). Меня даже позвали потом на после-олимпиадное обсуждение, где сидел автор задачи и краснел. В его задачи/решении была ошибка — находилась только одна точка из всех возможных. Но он был заслуженный, поэтому победу отдали человеку, допустившему ту же оишбку что и автор. «Ответ-то сошёлся».
Не согласен, что это поголовная особенность.
У меня лично был такой случай лет 5 назад: мне нужно было переделать один отчёт, т.к. в нём задваивались строки в определённых случаях. При пристальном рассмотрении выяснилось, что при текущей структуре таблиц проблему обойти не получается, т.е. отчёт невозможно получить в корректном виде. Изменение структуры таблиц означало геморрой месяца на три, если не больше, т.к. в них писало всё и вся, и мне пришлось бы переписывать процентов 50-60 огромной системы. Пробившись головой об стену дня 3-4, я пошёл к заказчику(это была внутренняя разработка) и выяснил, что можно убрать один показатель из конечного отчёта и таки получить его в корректном виде. Но ещё через недельку выяснилось, что отчётом пользуется ещё один человек, и ему убранный показатель очень нужен. Дальше стал уже разгораться конфликт, т.к. человек вообще не понимал, почему так, как он хочет, сделать нельзя. Уже на пике, я таки догадался, что этому человеку могут быть не нужны другие показатели, пошёл у нему, и вышел довольный — они действительно были ему не нужны, а убрав эти показатели из первоначального отчёта, я смог построить ещё один корректный отчёт. Я заменил один некорректный отчёт двумя корректными и все остались довольны, хотя проблема в первоначальной постановке действительно была близка к неразрешимости.
Я — русский :) Мой непосредственный начальник на той работе был белорусом :) Это была внутренняя разработка, т.е. о прибыли вообще речи не было. Но тем не менее, проблема была решена.
У меня лично был такой случай лет 5 назад: мне нужно было переделать один отчёт, т.к. в нём задваивались строки в определённых случаях. При пристальном рассмотрении выяснилось, что при текущей структуре таблиц проблему обойти не получается, т.е. отчёт невозможно получить в корректном виде. Изменение структуры таблиц означало геморрой месяца на три, если не больше, т.к. в них писало всё и вся, и мне пришлось бы переписывать процентов 50-60 огромной системы. Пробившись головой об стену дня 3-4, я пошёл к заказчику(это была внутренняя разработка) и выяснил, что можно убрать один показатель из конечного отчёта и таки получить его в корректном виде. Но ещё через недельку выяснилось, что отчётом пользуется ещё один человек, и ему убранный показатель очень нужен. Дальше стал уже разгораться конфликт, т.к. человек вообще не понимал, почему так, как он хочет, сделать нельзя. Уже на пике, я таки догадался, что этому человеку могут быть не нужны другие показатели, пошёл у нему, и вышел довольный — они действительно были ему не нужны, а убрав эти показатели из первоначального отчёта, я смог построить ещё один корректный отчёт. Я заменил один некорректный отчёт двумя корректными и все остались довольны, хотя проблема в первоначальной постановке действительно была близка к неразрешимости.
Я — русский :) Мой непосредственный начальник на той работе был белорусом :) Это была внутренняя разработка, т.е. о прибыли вообще речи не было. Но тем не менее, проблема была решена.
Рискну высказать свое предположение:
− Заявление, что решить задачу невозможно − это просто попытка спихнуть задание другому или набить цену себе.
В менталитете американцев прибыль − это важно. А в нашем менталитете важно нести свою значимость, свой личный статус.
В Менталитете американцев и европейцев прибыль компании − это благодарность покупателей, и соответственно благодарность руководства тебе, нанятому работнику. А в нашем менталитете прибыль ничто, а собственная крутость и ощущение незаменимости − все.
Американский менеджер приходит к разработчику с заданием, потому что уверен, что это действительно принесет прибыль компании. А российский руководитель приходит к разработчику, потому что его пнул его начальник, устроил разнос на совещании, и тот бежит к разработчику: выручай, сверни горы! И ответ «Это невозможно» просто-напросто попытка объяснить начальнику, что не надо мне на шею садиться и ножки свешивать, это ваша задача дать точное ТЗ.
Это наследие советской и постсоветской организации труда, когда начальник − или блатной, или чей-то сынок, или старый приятель директора, сам толком в вопросе не разбирается, а ответственность собирается спихнуть. Любая новая работа − это лишний геморрой, лишняя ответственность, которая скорее всего не будет оценена ни деньгами, ни даже похвалой. Поэтому разработчик просто надувает щеки. Он знает, что может решить задачу. Но надеется, что его будут уговаривать, и дадут поблажки, снизят ответственность. Либо отдадут работу кому-то другому.
Не могу ручаться, что мои доводы 100%, но я с подобным сталкивался несколько раз.
− Заявление, что решить задачу невозможно − это просто попытка спихнуть задание другому или набить цену себе.
В менталитете американцев прибыль − это важно. А в нашем менталитете важно нести свою значимость, свой личный статус.
В Менталитете американцев и европейцев прибыль компании − это благодарность покупателей, и соответственно благодарность руководства тебе, нанятому работнику. А в нашем менталитете прибыль ничто, а собственная крутость и ощущение незаменимости − все.
Американский менеджер приходит к разработчику с заданием, потому что уверен, что это действительно принесет прибыль компании. А российский руководитель приходит к разработчику, потому что его пнул его начальник, устроил разнос на совещании, и тот бежит к разработчику: выручай, сверни горы! И ответ «Это невозможно» просто-напросто попытка объяснить начальнику, что не надо мне на шею садиться и ножки свешивать, это ваша задача дать точное ТЗ.
Это наследие советской и постсоветской организации труда, когда начальник − или блатной, или чей-то сынок, или старый приятель директора, сам толком в вопросе не разбирается, а ответственность собирается спихнуть. Любая новая работа − это лишний геморрой, лишняя ответственность, которая скорее всего не будет оценена ни деньгами, ни даже похвалой. Поэтому разработчик просто надувает щеки. Он знает, что может решить задачу. Но надеется, что его будут уговаривать, и дадут поблажки, снизят ответственность. Либо отдадут работу кому-то другому.
Не могу ручаться, что мои доводы 100%, но я с подобным сталкивался несколько раз.
Черт. После прочтения статьи понял, что у меня японские корни.
Знаете, что мне напомнила Ваша позиция? Тем более, что Вы сами сказали: «будто это тупой прапор командует. Но в ней вся суть».
Вы даёте проблему. Вы даёте решение к ней, инструкцию как реализовать. Разработчику остаётся просто сесть и писать код. Вроде бы ничего плохого? Но давайте взглянем на ситуацию с другой стороны.
Прапорщик: «Вот лопата, косить отсюда и до обеда».
Ефрейтор: «У нас же коса есть?»
Рядовой: «Откуда, товарищ прапорщик?»
Сержант: «Будет сделано!»
Что требуется здесь? Безусловное исполнение приказа, без обсуждения. В боевых условиях оно спасает жизни, много жизней. Но представьте, что каждому из вышеупомянутых людей потом придётся отвечать за свои же поступки. Допустим, перед офицером, который любил полежать на этой траве. Лично отвечать. Таким образом ефрейтор всё скосит ровно, и офицер, может, даже и не заметит ничего. Рядовой оставит небольшой участок, а сержанту просто пофиг: это его работа.
Если Вы не видите параллели — поясню. Разработчику потом этот код поддерживать, не так ли? Как минимум, документировать, чтоб разобрались другие. Если есть возможность сделать просто и красиво — он сделает, и легко. Если только у него сейчас нет более высокого приоритета в чём-либо (допустим, изучение новой технологии). Если возможности сделать просто и красиво в рамках выданного задания нет — он не будет делать. Лучше сказать «нет» сейчас, чем ждать последующих проблем.
Да, «наши» везде ищут проблемы, возможные сложности. Что даёт им и конкурентное преимущество, и некий минус. Они могут найти решение проблемы, но автоматами-исполнителями они навряд ли будут. Как лично мне кажется, Вам бы следовало просто дать разработчику проблему и своё видение преподать не в качестве инструкции, а в качестве одного из возможных вариантов. Даже если Ваш авторитет стремится в космос, то «наш» разработчик всё равно будет искать лучшее решение. Просто потому, что это для него сродни вызову. Не сможет его найти — выберет Ваше. Сможет — тем лучше проекту. Особенно, если Вы будете вовлечены, как коллега с ним обсуждая подходы и реализации. Если Вы будете советовать, но не настаивать.
Вы даёте проблему. Вы даёте решение к ней, инструкцию как реализовать. Разработчику остаётся просто сесть и писать код. Вроде бы ничего плохого? Но давайте взглянем на ситуацию с другой стороны.
Прапорщик: «Вот лопата, косить отсюда и до обеда».
Ефрейтор: «У нас же коса есть?»
Рядовой: «Откуда, товарищ прапорщик?»
Сержант: «Будет сделано!»
Что требуется здесь? Безусловное исполнение приказа, без обсуждения. В боевых условиях оно спасает жизни, много жизней. Но представьте, что каждому из вышеупомянутых людей потом придётся отвечать за свои же поступки. Допустим, перед офицером, который любил полежать на этой траве. Лично отвечать. Таким образом ефрейтор всё скосит ровно, и офицер, может, даже и не заметит ничего. Рядовой оставит небольшой участок, а сержанту просто пофиг: это его работа.
Если Вы не видите параллели — поясню. Разработчику потом этот код поддерживать, не так ли? Как минимум, документировать, чтоб разобрались другие. Если есть возможность сделать просто и красиво — он сделает, и легко. Если только у него сейчас нет более высокого приоритета в чём-либо (допустим, изучение новой технологии). Если возможности сделать просто и красиво в рамках выданного задания нет — он не будет делать. Лучше сказать «нет» сейчас, чем ждать последующих проблем.
Да, «наши» везде ищут проблемы, возможные сложности. Что даёт им и конкурентное преимущество, и некий минус. Они могут найти решение проблемы, но автоматами-исполнителями они навряд ли будут. Как лично мне кажется, Вам бы следовало просто дать разработчику проблему и своё видение преподать не в качестве инструкции, а в качестве одного из возможных вариантов. Даже если Ваш авторитет стремится в космос, то «наш» разработчик всё равно будет искать лучшее решение. Просто потому, что это для него сродни вызову. Не сможет его найти — выберет Ваше. Сможет — тем лучше проекту. Особенно, если Вы будете вовлечены, как коллега с ним обсуждая подходы и реализации. Если Вы будете советовать, но не настаивать.
Так вроде разработчику не говорили «пропиши так и так». Было нечто в стиле «наши клиенты хотят вот такую плюшку, если мы её не сделаем — у нас будет меньше клиентов. Надо реализовать, пусть решение будет даже костыльным». Или я неверно понял посыл автора?
«Минут пять мы обсуждаем, я рассказываю, что и где именно нам нужно получить. Задание донёс, оно понятно и кристально ясно. Всё, стадию донесения задания прошли».
Не знаю, возможно я ошибся, но мне показалось, что имела место именно инструкция. Именно за счёт слова «донёс».
Не знаю, возможно я ошибся, но мне показалось, что имела место именно инструкция. Именно за счёт слова «донёс».
Видимо у нас просто разное восприятие.
Имхо, просто не бывает «невозможны задач», которые нельзя обосновать, почему они невозможны. Если для решения нужно например неделю — ну так и скажи, что на вроде бы простую фичу в реальности нужно перелопатить много, обсудим альтернативные варианты, более простые. Я правда говорю со стороны разработчиков, но сколько себя помню, всегда можно ответить — «можно сделать прямо так, но будет сложно, как насчет более простого варианта» или «а в чем основная цель? может, стоит поменять то-то и там то», да даже «я на проекте недавно и ещё ту часть системы не изучил, не могу с уверенностью сказать, сколько понадобится времени, временная вилка такая то».
Разумный разработчик всегда может предложить альтернативы, разумный руководитель — к ним прислушаться и как минимум — обсудить их. Вариант же «есть два мнения — моё и неправильное» ни с одной из сторон ни к чему хорошему бы не приводит.
Имхо, просто не бывает «невозможны задач», которые нельзя обосновать, почему они невозможны. Если для решения нужно например неделю — ну так и скажи, что на вроде бы простую фичу в реальности нужно перелопатить много, обсудим альтернативные варианты, более простые. Я правда говорю со стороны разработчиков, но сколько себя помню, всегда можно ответить — «можно сделать прямо так, но будет сложно, как насчет более простого варианта» или «а в чем основная цель? может, стоит поменять то-то и там то», да даже «я на проекте недавно и ещё ту часть системы не изучил, не могу с уверенностью сказать, сколько понадобится времени, временная вилка такая то».
Разумный разработчик всегда может предложить альтернативы, разумный руководитель — к ним прислушаться и как минимум — обсудить их. Вариант же «есть два мнения — моё и неправильное» ни с одной из сторон ни к чему хорошему бы не приводит.
Problem на русский переводится как:
вопрос (который надо обсудить),
задача (которую надо решить), задание (которое надо сделать)
тема (исследования в науке)
Houston we have a problem
Я хорошо понимаю автора. Сам с этим сталкивался. Но надо признать, что далеко ни все русские такие. У меня был вот такой случай. Работая в одной компании, старшим разработчиком, в паре у меня был Татарин. Дальше видимо можно прямо по вашему тексту читать, буква к букве. Этот человек мог просто умирать от безделья, но ничего не делать. Со всем отделом готов был спорить до рвоты. Чудовищно упрямый, хоть убивай.
Знаю одного такого. Последний раз виделся с ним года два назад. На тот момент он сидел без работы. И он всегда оспаривал любые идеи и проекты. К примеру я в тот момент работал в успешной конторе которая продавала свой софт и была лидером на территории Республики. Мой приятель же в корне критиковал проект. Что его не реально поддерживать. Что это вообще не правильно. Такой софт писать нельзя. Что от него куча проблем. И кому это вообще надо. Тем не менее уже лет 10 софт продается и набирает обороты. Не удивлюсь если приятель из-за своей пессимистичности до сих пор в поисках. Кстати тоже Татарин. Хочется верить что все таки с возрастом и опытом станет менее упертым.
Как-то даже не верится что хоть кто-то из наших (на 100% отечественных контор) верит в принцип «принесет деньги компании == принесет деньги тебе». По-моему в большинстве случаев все ровно наоборот. За штучки «не существующие в гугле» ответственный разработчик расплачивается красными глазами и десятками если не сотнями неудачных попыток что-то сделать в нерабочее время на домашнем компе. В результате, даже если что-то и получится, то этого никто не оценит (а в большинстве случаев и не вспомнит и не заметит изменений и не подумает как-то отследить и проанализировать ценность новинки), но сам разработчик неминуемо получит жутчайший геморрой с поддержкой этой «невозможной» штуки и с ее незапланированными переделками. А с увеличением числа «штучек» еще и проблемы с тем чтобы держать в памяти хотя бы папку на диске где лежит штучка трехлетней давности и с необходимостью то и дело вспоминать заново что там и как было накостылено, чтобы изменить пару строчек в угоду опять решившим наплевать обратную совместимость новым версиям гуглохрома.
>в принцип «принесет деньги компании == принесет деньги тебе».
Этот принцип работает через механзм премий. Премии же не из воздуха берутся, а из той же самой прибыли.
Этот принцип работает через механзм премий. Премии же не из воздуха берутся, а из той же самой прибыли.
Я вас умоляю :) Премии в большинстве отечественных контор это способ сделать часть зарплаты серой и платить меньше налогов, отчислений в пенсионный и т.д. Реальные премии платят только в очень хороших конторах, которых мало и чаще всего туда незнакомых работников со стороны просто не берут.
Да уж, премий. Обычно бывает так — ты месяц работаешь по 60 часов в неделю, потому что попросили и потому что дедлайн скоро, а по окончанию геморрой тебе вместо, скажем, трех отгулов и внеочередного командного корпоратива, +$200 к зарплате в этом месяце. При том, что начальник скорее всего получил $2000. Сидишь, обтекаешь и пишешь резюме.
Спасибо за статью, понравилась! )
Таких личностей встречал. Есть такие. Сам всегда удивлялся такой особенности. Сам являюсь программистом.
На своем опыте могу сказать что чаще имел проблемы от того что соглашался на все подряд порой не догадываясь о том какие проблемы за этим пойдут. Но зато тем самым я повышал свой уровень знаний, и самооценку. И всегда старался мыслить глобально. Даже если задача не из моей области, я знаю что её по любому сделать можно. Пусть придется разбираться но зато к экспириенсу +5. В крайнем случае можно найти того кто поможет с этим разобраться.
В общем жизнь — игра. Каждая новая задача — это хороший способ прокачаться. Чем сложнее и не понятнее задача, тем больше опыта она даст при завершении. Главное мыслить позитивно и не зацикливаться на одной области. Стараться абстрагироваться от привычных технологий, инструментов, логики и т.п.
Таких личностей встречал. Есть такие. Сам всегда удивлялся такой особенности. Сам являюсь программистом.
На своем опыте могу сказать что чаще имел проблемы от того что соглашался на все подряд порой не догадываясь о том какие проблемы за этим пойдут. Но зато тем самым я повышал свой уровень знаний, и самооценку. И всегда старался мыслить глобально. Даже если задача не из моей области, я знаю что её по любому сделать можно. Пусть придется разбираться но зато к экспириенсу +5. В крайнем случае можно найти того кто поможет с этим разобраться.
В общем жизнь — игра. Каждая новая задача — это хороший способ прокачаться. Чем сложнее и не понятнее задача, тем больше опыта она даст при завершении. Главное мыслить позитивно и не зацикливаться на одной области. Стараться абстрагироваться от привычных технологий, инструментов, логики и т.п.
Замечательная копипаста по теме
Общение с начальством
Общение с заказчиком
- Невозможно в принципе — я не знаю, как это сделать.
- Невозможно — я знаю как, но мне лениво.
- Сложно — придется прочитать документацию.
- В принципе, реализуемо — я как раз вчера скачал из интернета библиотеку, которая решает поставленную задачу.
- Элементарно — употребляется исключительно при оценке задач, стоящих перед другими программистами, независимо от степени их сложности.
- Работает — компилируется.
- Отлаживаю — не компилируется.
- Прогоняю тестовые примеры — пытаюсь найти такой, на котором программа не вываливается.
- Хорошо, я попытаюсь — давай-ка отъебись от меня.
- Работал допоздна — играл по сети.
- К десяти — после обеда.
- После обеда — к 18:00.
- Завтра — через неделю.
- Неделя — месяц.
- Месяц — полгода.
- Год — никогда.
- Точно — может быть.
- Вероятно — вероятность равна 0,5.
- Может быть — нет.
- Нет — а кого вы еще найдёте за такие деньги?
Общение с заказчиком
- Невозможно в принципе — невозможно в принципе.
- Сложно — элементарно, но предложенная сумма мне не нравится.
- В принципе, реализуемо — я понятия не имею, как это сделать, но предложенная сумма мне нравится.
- Элементарно — употребляется исключительно в ответ на вопрос, легко ли будет пользователю освоить интерфейс программы.
- Ресурсоёмкая задача — мне лень заниматься оптимизацией.
- Передовые информационные технологии — мне лень заниматься оптимизацией.
- Большой объём работы — целый час качал библиотеку из интернета.
- Минимальные требования — запустится, но работать не будет.
- Дружественный интерфейс — поддерживается мышка.
- Простой интерфейс — не поддерживается мышка.
- Полная совместимость — никто не проверял, но чем чёрт не шутит?
- Релиз — бета-версия.
- Особенности — глюки.
- Оптимизация — выкидывание того, что так и не удалось заставить работать.
- Превосходит аналоги — занимает больше места.
- Неделя — 1) месяц; 2) день.
- Месяц — 1) полгода; 2) неделя.
- Год — понятия не имею, сколько.
Я выработал новую тактику: вместо «невозможно» говорю достаточно честную (совсем немного преуменьшенную) оценку времени работы (или того времени, которое понадобится на оценку времени предстоящей работы), после чего у заказчика волосы встают дыбом от нестерпимого ужаса — и представление о невозможности само собою рождается в уму его.
(И мне не раз доводилось слышать о том, что я лучше остальных программистов тем, что никогда не говорю «невозможно», но я думал, что этокакая-то местная особенность, покуда сегодня не увидел на Хабрахабре эту особенность обозначенною в качестве национальной.)
(И мне не раз доводилось слышать о том, что я лучше остальных программистов тем, что никогда не говорю «невозможно», но я думал, что это
Дело в том, что американцы и европейцы — они гораздо лучшие рабы, чем русские. Они беспрекословно подчиняются тому, кто имеет власть над ними — своему начальнику, своему государству, доллару. Они молча проглатывают свою гордость и превращаются в идеальный винтик в этой капиталистической машине.
Хорошо ли это или плохо? С точки зрения машины — хорошо. Машине нужны идеальные винтики. Она их собственно и производит. Но человек — не винтик. И пытаться стать идеальным винтиком — означает перестать быть человеком.
В этом смысле, русские — более человечны, чем те же американцы.
Хорошо ли это или плохо? С точки зрения машины — хорошо. Машине нужны идеальные винтики. Она их собственно и производит. Но человек — не винтик. И пытаться стать идеальным винтиком — означает перестать быть человеком.
В этом смысле, русские — более человечны, чем те же американцы.
Вы хотя бы с одним американцем или европейцем в реальной жизни общались? Или только по шуткам Задорнова выводы делаете?
Увы, американцы и европейцы психологически более уверены в себе и открыты. Наши, к сожалению, в большинстве своем замордованы, но любят делать какие то высокие выводы и рассуждать (при том о пустом, об империи, о каких то высоких материях и прочем, прочем, прочем). И кстати, про человечность, знакомый англичанин отчисляет какую то «копеючку» от своего дохода на благотворительность. Русские находят тысячи поводов на улице даже денег не подавать. :(
Увы, американцы и европейцы психологически более уверены в себе и открыты. Наши, к сожалению, в большинстве своем замордованы, но любят делать какие то высокие выводы и рассуждать (при том о пустом, об империи, о каких то высоких материях и прочем, прочем, прочем). И кстати, про человечность, знакомый англичанин отчисляет какую то «копеючку» от своего дохода на благотворительность. Русские находят тысячи поводов на улице даже денег не подавать. :(
Да, я был в Америке.
Не хочу вдаваться дискуссию, но вся хваленая американская открытость и уверенность — фальшивая. Фальшивые голливудские улыбки, которые люди носят как маски и даже после смерти не могут перестать улыбаться. Уверенность скорее похожая на наглость. Открытость, целью которой является втереться в доверие, а потом контролировать информационные потоки всего мира втихаря. Благотворительность, когда Америка сначала грабит полмира, а потом с барского плеча отдает 10 долларов голодающим африканцам.
Да, все мы знаем цену американской «человечности».
Не хочу вдаваться дискуссию, но вся хваленая американская открытость и уверенность — фальшивая. Фальшивые голливудские улыбки, которые люди носят как маски и даже после смерти не могут перестать улыбаться. Уверенность скорее похожая на наглость. Открытость, целью которой является втереться в доверие, а потом контролировать информационные потоки всего мира втихаря. Благотворительность, когда Америка сначала грабит полмира, а потом с барского плеча отдает 10 долларов голодающим африканцам.
Да, все мы знаем цену американской «человечности».
По моему, вы делаете далеко идущие обобщения из частных случаев.
Как ни странно, я с таким поведением не разу не сталкивался. Что я делаю не так? Может задачи ставлю по другому или другие?
Как ни странно, я с таким поведением не разу не сталкивался. Что я делаю не так? Может задачи ставлю по другому или другие?
Аналогично. Много очень лет уже работаю, и программистом, и ведущим, и техдиром итд. Ну ни разу не сталкивался с такими случаями/людьми. Согласен что скорее всего это частные случаи, и это тупо лень. Сталкивался — не знаю как решить, но это обычные рабочие моменты. Хочу, но не знаю как.
С Макаревичем случай совсем про другое, он про наш великий советский сервис, который клиента во внимание не берет, в отличии от.
С Макаревичем случай совсем про другое, он про наш великий советский сервис, который клиента во внимание не берет, в отличии от.
А я сталкивался. И таким человеком был русский программист. Было это 5 лет тому назад. Больше таких случаев не встречал.
И да. С зарубежными коллегами не работал.
Так что подтверждаю тезис статьи :)
И да. С зарубежными коллегами не работал.
Так что подтверждаю тезис статьи :)
основная особенность наших программистов: думать почему проблему решить нельзя.
Программист должен быть инженером, т.е. решать то что раньше не умел.
Плюс в деве (даже веб-деве) очевидно что сделать можно всё, было бы время и потребность. Это постулат.
Не думаю что в среднем на рынке программист < инженер.
«Плюс в деве (даже веб-деве) очевидно что сделать можно всё, было бы время и потребность. Это постулат.»
Сделаете так, что бы во всех основных браузерах посетитель при нажатии на кнопку закрытия вкладки получал сообщение «вы уверены, что хотите покинуть сайт»? Конкретная формулировка задачи, реальна слышанная на фрилансе. Кроме поиска уязвимостей или разработки плагинов под каждый браузер (которые пользователь ещё должен установить) пока иных путей не вижу :( Но даже тут правильнее ответить не «невозможно в принципе», а объяснить, почему и зачем. Выяснить, с какой целью возникла такая задумка, предложить альтернативы… и далее по тексту.
Или подобная шутка, вроде с баша:
xxx: Привет. Не знаешь, JS умеет с файлами на диске работать?
yyy: Только через переполнение буфера
Сделаете так, что бы во всех основных браузерах посетитель при нажатии на кнопку закрытия вкладки получал сообщение «вы уверены, что хотите покинуть сайт»? Конкретная формулировка задачи, реальна слышанная на фрилансе. Кроме поиска уязвимостей или разработки плагинов под каждый браузер (которые пользователь ещё должен установить) пока иных путей не вижу :( Но даже тут правильнее ответить не «невозможно в принципе», а объяснить, почему и зачем. Выяснить, с какой целью возникла такая задумка, предложить альтернативы… и далее по тексту.
Или подобная шутка, вроде с баша:
xxx: Привет. Не знаешь, JS умеет с файлами на диске работать?
yyy: Только через переполнение буфера
После появления модуля «fs» в API Node шутка устарела.
Эм, ну сообщение не точно такое будет, но это реализуемо.
window.onbeforeunload, не?
Плюс в деве (даже веб-деве) очевидно что сделать можно всё, было бы время и потребность. Это постулат.
Предложите хотя бы сторону в которую копать, чтобы обеспечить невозможность пользователю скопировать в локальный файл картинку с сайта. Вариант «не размещать картинку» не предлагать :)
Например разбивать картинку на 1000 частей, или css image data, или рисовать её html5 canvas, или мало ли.
Только это всё бестолку, ведь можно делать скриншоты :)
Только это всё бестолку, ведь можно делать скриншоты :)
Я как будто живу в параллельной вселенной. Работаю разработчиком в командах лет 8 уже. Опыт, за копеечным исключением, только с русскими разработчиками. И НИКОГДА не слышал, чтобы программист отказывался решать задачу.
Либо задача несложная — тогда программист просто берёт и делает. Либо решение неочевидно и программисты вместе начинают предлагать варианты по её решению. Находится опитмальный, дальше, опять же, программист берёт и делает.
Да, иногда бывает, что задача занудная и неинтересная. Тогда программист может делать её 3 дня вместо одного. Но никогда не скажет, что это невозможно.
Если бы я сказал, что задачу выполнить не возможно (именно в таком ключе как в статье, без сверхобъективных причин), то на следующий день сам бы уволился из-за профнепригодности.
Либо задача несложная — тогда программист просто берёт и делает. Либо решение неочевидно и программисты вместе начинают предлагать варианты по её решению. Находится опитмальный, дальше, опять же, программист берёт и делает.
Да, иногда бывает, что задача занудная и неинтересная. Тогда программист может делать её 3 дня вместо одного. Но никогда не скажет, что это невозможно.
Если бы я сказал, что задачу выполнить не возможно (именно в таком ключе как в статье, без сверхобъективных причин), то на следующий день сам бы уволился из-за профнепригодности.
У японцев другая проблема (ой;) я сказал запретное слово;)
Полное отсутствие инициативы и готовности взять на себя хоть какую-то ответственности за решение.
Доходит до анекдотичного. При смене хоста VPN в окне терминала надо было нажать [yes] в ответ на вопрос в диалоге «принимаете ли вы новый public key». Японец (в Японии) два месяца наотрез отказывался это делать, ссылаясь на то, что у него в инструкции не написано, что он может нажимать yes в данном диалоге, и никто из его руководства — тоже.
Дело в том, что в японской деловой культуре инициатива наказуема прямым и непосредственным образом. Если бы что-то пошло не так — человека бы выгнали с волчьим билетом, и больше не взяли бы никуда. Он проявил ошибочную инициативу!
PS. А во времена самурайской Японии ваш разработчик взял бы задачу, сказав «Хай» (Да), обнаружил бы через три дня, что залача не решаема, и сделал бы себе сэпукку в конце рабочего дня. :)
Полное отсутствие инициативы и готовности взять на себя хоть какую-то ответственности за решение.
Доходит до анекдотичного. При смене хоста VPN в окне терминала надо было нажать [yes] в ответ на вопрос в диалоге «принимаете ли вы новый public key». Японец (в Японии) два месяца наотрез отказывался это делать, ссылаясь на то, что у него в инструкции не написано, что он может нажимать yes в данном диалоге, и никто из его руководства — тоже.
Дело в том, что в японской деловой культуре инициатива наказуема прямым и непосредственным образом. Если бы что-то пошло не так — человека бы выгнали с волчьим билетом, и больше не взяли бы никуда. Он проявил ошибочную инициативу!
PS. А во времена самурайской Японии ваш разработчик взял бы задачу, сказав «Хай» (Да), обнаружил бы через три дня, что залача не решаема, и сделал бы себе сэпукку в конце рабочего дня. :)
> два месяца наотрез отказывался это делать
Ну это скорее какая-то итальянская забастовка. Значит, у него были свои причины так отмазываться.
Конечно, тенденция есть, но до такого бреда не доходит.
Ну это скорее какая-то итальянская забастовка. Значит, у него были свои причины так отмазываться.
Конечно, тенденция есть, но до такого бреда не доходит.
Ну я же написал. Он сказал, что в имеющейся у него инструкции нигде не указано, что он можеть нажимать [yes] в таком диалоге, и никто из его руководства также не имеет никаких указаний это сделать, поэтому, спасибо-пожалуйста, верните как было, пусть это и означает аренду на полгода серверной стойки в сингапурском датацентре, мы заплатим, только чтобы вот тут ничего не нажимать.
У нас в компании даже существуют специально нанятые японцы, для того, чтобы разговаривать с японцами же. На их языке и их ментальном представлении.
У нас в компании даже существуют специально нанятые японцы, для того, чтобы разговаривать с японцами же. На их языке и их ментальном представлении.
НЛО прилетело и опубликовало эту надпись здесь
Так нет же, в том-то и дело, что ему, лично ЕМУ, очень нужно поднять этот VPN, это остановило всю ЕГО работу.
НЛО прилетело и опубликовало эту надпись здесь
Это я вам уже просто самый конец истории рассказал. Никто не взял на себя ответственность за получение public-key, и для продолжения работы пришлось, в спешном порядке, отдельно для одной Японии, установить VPN-сервер по старому адресу на полгода, пока они там у себя в Японии выясняли, кто же должен нажимать yes. :)
НЛО прилетело и опубликовало эту надпись здесь
Думаю, это просто от того, что в совке человек привык завоёвывать благоприятные для себя условия, тогда как на западе они даны по умолчанию, и у человека есть желание и возможность самореализовываться более здоровым образом.
Ну вот, а буквально месяц-два назад а здесь же читал статью, что главная доблесть разработчика — уметь не делать то, что можно не делать. И тоже очень убедительно все было.
А не дадите ссылку?
Но сомневаюсь, что даже там было сказано что-то вроде «отпирайтесь без реальных аргументов, просто отказывайте заказчику и всё».
И вообще. Уметь говорить «нет» надо, определённо, но к месту — и уметь свой отказ обосновать.
Но сомневаюсь, что даже там было сказано что-то вроде «отпирайтесь без реальных аргументов, просто отказывайте заказчику и всё».
И вообще. Уметь говорить «нет» надо, определённо, но к месту — и уметь свой отказ обосновать.
Попробую найти, но не обещаю.
Здесь ведь тоже аргументы у отказников есть: невозможно, не вписывается в концепцию и т.д.
Здесь ведь тоже аргументы у отказников есть: невозможно, не вписывается в концепцию и т.д.
Да, перевод как раз этой статьи и был на хабре не так давно… Спасибо, теперь нашел как и обещал: habrahabr.ru/post/178553/
В статье очень много «Я», может из-за этого минусуют, не знаю. Но в итоге проголосовал положительно, потому, что это действительно правда. В инженерное среде, тоже достаточно часто такое же отношение к проблеме.
Кстати сейчас подумалось, а бывают иногда еще обратные ситуации, когда исполнитель приходит и говорит:" давайте сделаем такую штуку, она не сложная объективно полезная, порадует заказчика и я сам ее готов сделать (возможно с небольшой помощью)", а в ответ административный ресурс находит аргументы и контр аргументы почему это нельзя сделать (как правило потому что это изменяет уже накатанное спокойствие и затишье ). Это наш менталитет, наши люди не очень любят работать видимо потому что, всегда считают, что достойны лучшего и что это лучшее кто-то на блюдечке им должен принести. Но безусловно это не про всех, есть много талантливых и деятельных наших соотечественников в любой сфере деятельности.
Кстати сейчас подумалось, а бывают иногда еще обратные ситуации, когда исполнитель приходит и говорит:" давайте сделаем такую штуку, она не сложная объективно полезная, порадует заказчика и я сам ее готов сделать (возможно с небольшой помощью)", а в ответ административный ресурс находит аргументы и контр аргументы почему это нельзя сделать (как правило потому что это изменяет уже накатанное спокойствие и затишье ). Это наш менталитет, наши люди не очень любят работать видимо потому что, всегда считают, что достойны лучшего и что это лучшее кто-то на блюдечке им должен принести. Но безусловно это не про всех, есть много талантливых и деятельных наших соотечественников в любой сфере деятельности.
НЛО прилетело и опубликовало эту надпись здесь
Так я у человека и не отбираю это право, я же не законодательная власть и не прокуратура. Это было просто предположение. Пока читал пост заметил излишнюю концентрацию на «эго», автора, это не плохо и не хорошо, там был вопрос за что минсуют карму, я предположил, что кому-то эта манера письма может не понравиться, Все люди разные.
НЛО прилетело и опубликовало эту надпись здесь
Очень редко задача менеджера проекта звучит как «нужно сделать то-то и то-то». Обычно это звучит как «Мы продали заказчику такую-то фичу, она должна работать вчера. Это ведь элементарная задача, даже я вижу это, так что ты должен сделать ее позавчера». И ответ разработчика «Это невозможно» — это «Невозможно сделать задачу позавчера ввиду отсутствия в компании машины времени».
Разработчик, будучи опытным в своей специализации и зная свою часть проекта уже прикинул сколько всего придется переделать для того, чтобы реализовать эту фичу и не нарушить концепцию системы, которую он выстраивал, возможно, годами. И работать по ночам у него желания тоже мало.
Программирующий менеджер сказал «Ах так???», в пику «упрямому» разработчику не спал ночь, воткнул в систему костыль, который потом еще и поддерживать придется, но зато доказал.
Все люди разные, и я не стал бы категорически делить людей на «наших» и «не наших», причем наши, понятное дело, хуже — они думают при получении задачи, а не стоят по стойке смирно. Бывают отличные разработчики, которые любую идею принимают в штыки — не спорю, но держат их как раз за то, что они же потом эти идеи потом и блестяще реализуют просто найдя для нее более органичное место в системе, чем то, которое придумал менеджер. И хороший менеджер это должен знать и умело пользоваться.
Справедливости ради стоит сказать, что я уверен — такие личности, которых описал автор, существуют, но ошибка утверждать, что они имеют конкретную национальность.
Разработчик, будучи опытным в своей специализации и зная свою часть проекта уже прикинул сколько всего придется переделать для того, чтобы реализовать эту фичу и не нарушить концепцию системы, которую он выстраивал, возможно, годами. И работать по ночам у него желания тоже мало.
Программирующий менеджер сказал «Ах так???», в пику «упрямому» разработчику не спал ночь, воткнул в систему костыль, который потом еще и поддерживать придется, но зато доказал.
Все люди разные, и я не стал бы категорически делить людей на «наших» и «не наших», причем наши, понятное дело, хуже — они думают при получении задачи, а не стоят по стойке смирно. Бывают отличные разработчики, которые любую идею принимают в штыки — не спорю, но держат их как раз за то, что они же потом эти идеи потом и блестяще реализуют просто найдя для нее более органичное место в системе, чем то, которое придумал менеджер. И хороший менеджер это должен знать и умело пользоваться.
Справедливости ради стоит сказать, что я уверен — такие личности, которых описал автор, существуют, но ошибка утверждать, что они имеют конкретную национальность.
Программирующий менеджер сказал «Ах так???», в пику «упрямому» разработчику не спал ночь, воткнул в систему костыль, который потом еще и поддерживать придется, но зато доказал.
Бывает хуже — программирующий менеджер думает что решил задачу. На самом деле кастыль ее «решает» путем пораждения фатальных багов, с которыми он потом придет к разработчику и правка которых будет очень болезненна.
НЛО прилетело и опубликовало эту надпись здесь
В самую точку. Читая первый абзац уже кинулся отвечать, потом увидел что написано именно то, что хотел сказать. В любых костылях, продавленных менеджментом, в конечном итоге будет виноват разработчик, вне зависимости от того что говорилось и обещалось при обсуждении костыля. Потому разработчик и не желает в очередной раз наступать на эти грабли — наперед знает чем закончатся такие доработки.
Завидую вам со страшной силой — хороший у вас рынок труда и требования, если так просто можно увольнять разработчиков :(. А у нас в Москве довольно частое явление, когда приходится работать с теми ребятами, котрые есть — потому что если уволить специалиста а потом зайти на рынок, то на нем не просто пусто — на нем даже мертвых с косами нет. Их тоже уже кто-то трудоустроил.
И вообще, в последние пару лет вопрос «как найти и нанять хорошего разработчика» постепенно заменяется вопросом «как найти и нанять хоть кого-то, кто может писать код, и как с ними жить».
И вообще, в последние пару лет вопрос «как найти и нанять хорошего разработчика» постепенно заменяется вопросом «как найти и нанять хоть кого-то, кто может писать код, и как с ними жить».
Специалист в конкретной области как правило сразу видит какие-то глубинные проблемы, которые не дают решить задачу в общем виде. Поэтому надо сразу указывать ограничения в духе «нет, нам не нужен 100% аптайм, 99.5% достаточно» или «нет, 1000 посетителей в секунду не будет, максимум — 100». При такой постановке задачи многое становится возможным.
А ещё нужно не требовать ответа сразу: «Так, вот такая есть задача, нужно сделать это и это. Потрать, пожалуйста, пару часов на исследование и скажи мне к вечеру оценку времени. Нет, не сейчас, а к вечеру. И если что-то невозможно, то оценку без него».
А ещё нужно не требовать ответа сразу: «Так, вот такая есть задача, нужно сделать это и это. Потрать, пожалуйста, пару часов на исследование и скажи мне к вечеру оценку времени. Нет, не сейчас, а к вечеру. И если что-то невозможно, то оценку без него».
А специалист в конкретной области сам не в состоянии предупредить, что задачу сумеет сделать, но с 99,5% аптайма и 100 пользователями в секунду?
Ну, знаете, как в той сценке про несколько разноцветных параллельных линий, три из которых перпендикулярны друг другу, и все должны быть нарисованы одним фломастером.
Либо, если не в состоянии — попросить таймаут на пару часов, или сколько там надо на изучение задачи.
Ну, знаете, как в той сценке про несколько разноцветных параллельных линий, три из которых перпендикулярны друг другу, и все должны быть нарисованы одним фломастером.
Либо, если не в состоянии — попросить таймаут на пару часов, или сколько там надо на изучение задачи.
А это не его дело решать самостоятельно, допустимо там 99.5% аптайма или нет. А задача ведь ставилась скорее всего в духе «должно работать абсолютно безотказно!». Абсолютно? Невозможно, валите лесом.
Тут уже вопрос в том, должен ли техник обладать коммуникабельностью и ответственностью для того, чтобы начать обсуждать недомолвки и непонятки, или же это дело менеджера. Мне кажется, что скорее менеджера, потому что если такие вопросы решает не менеджер, то непонятно что он вообще решает и зачем нужен. По крайней мере на фразу разработчика «невозможно» надо отвечать «почему?» и «а как возможно?», а не «так, быстро делай» и «ты уволен».
Тут уже вопрос в том, должен ли техник обладать коммуникабельностью и ответственностью для того, чтобы начать обсуждать недомолвки и непонятки, или же это дело менеджера. Мне кажется, что скорее менеджера, потому что если такие вопросы решает не менеджер, то непонятно что он вообще решает и зачем нужен. По крайней мере на фразу разработчика «невозможно» надо отвечать «почему?» и «а как возможно?», а не «так, быстро делай» и «ты уволен».
А это не его дело решать самостоятельно, допустимо там 99.5% аптайма или нет.
А его никто и не просит решать. Хороший инженер будет предлагать конструктив в виде «я смогу так и так», обычный инженер — молча работать работу в а-ля японском стиле, ленивый инженер будет уходить в неконструктив, посылая работодателя в лес и заставляя бегать вокруг него с уговорами «ну почему», «ну а может все-таки», «ну пожалуйста».
Вообще, конечно, здорово что мы — инженеры — пока что можем себе это позволить :) благо спрос на нас высок. Но в принципе — посылать в лес неправильно.
Проблема в том, что часто менеджеры не озвучивают собственно бизнес-задачу, а требуют технически реализовать выбранное ими решение. Сложно предлагать конструктив, не зная, а какую собственно задачу нужно решить.
А пусть он не трогает бизнес-задачу. Пусть он ее оставит своему менеджеру — должен же он хоть что-то полезное делать за свою зарплату?
Конструктив от инженера должен исходить в основном именно на техническом уровне. Мол — вот ваша задача, если я реализую так и так, вам подойдет? Нет? Следующий вариант. Да? Отлично.
На то ведь он и инженер?
Конструктив от инженера должен исходить в основном именно на техническом уровне. Мол — вот ваша задача, если я реализую так и так, вам подойдет? Нет? Следующий вариант. Да? Отлично.
На то ведь он и инженер?
Честно, не вполне понял, за что статью плюсуют.
Автор, вероятно, немало обжегся на работе с русскими разработчиками — но насколько корректно свой опыт взаимодействия с ограниченным кругом лиц экстраполировать на нацию? Этакий IT-расизм, ведь статья пропитана идеей, что русские программисты ничего не хотят делать.
По работе в нескольких компаниях (совсем маленьких и огромных) я пересекался только с русскими разработчиками, и ничего подобного описанному в статье я не видел. Мы создавали хорошие продукты, качественно настолько, насколько возможно в существующих ограничениях, и без системы мотивации вообще! Она была просто не нужна для 99% коллектива, людей не только образованных, но и ответственных, понимающих свою роль в проекте. Понятно, что не все всегда идеально, но чтоб искать причины не делать задачу — ни разу и никогда я такого не видел. Скорее даже наоборот: часть функционала, который делали по просьбе заказчика, потом оказывался не нужным, хотя мы это понимали изначально.
Человек может (в каком-то смысле даже должен!) лениться, искать пути оптимизации своих трудозатрат, но если он отказывается делать свою работу и ищет миллион оправданий — на мой взгляд, это уже за гранью элементарной культуры. Но еще большее бескультурье — это относить к этой категории всех русских программистов скопом.
Автор, вероятно, немало обжегся на работе с русскими разработчиками — но насколько корректно свой опыт взаимодействия с ограниченным кругом лиц экстраполировать на нацию? Этакий IT-расизм, ведь статья пропитана идеей, что русские программисты ничего не хотят делать.
По работе в нескольких компаниях (совсем маленьких и огромных) я пересекался только с русскими разработчиками, и ничего подобного описанному в статье я не видел. Мы создавали хорошие продукты, качественно настолько, насколько возможно в существующих ограничениях, и без системы мотивации вообще! Она была просто не нужна для 99% коллектива, людей не только образованных, но и ответственных, понимающих свою роль в проекте. Понятно, что не все всегда идеально, но чтоб искать причины не делать задачу — ни разу и никогда я такого не видел. Скорее даже наоборот: часть функционала, который делали по просьбе заказчика, потом оказывался не нужным, хотя мы это понимали изначально.
Человек может (в каком-то смысле даже должен!) лениться, искать пути оптимизации своих трудозатрат, но если он отказывается делать свою работу и ищет миллион оправданий — на мой взгляд, это уже за гранью элементарной культуры. Но еще большее бескультурье — это относить к этой категории всех русских программистов скопом.
Знакомая ситуация, когда разработчик говорит, что что-то сделать не получится. Это скорее всего значит что ему это делать не интересно. Делать хак не всегда выход, но есть же знаменитая русская смекалка и на десяток обычных разработчиков есть один такой, который наоборот только такие задачи и любит. Когда надо найти хак, нетрадиционное решение, обходной путь. И тут оба уже этих качества становятся особенностью наших программистов. С одной стороны они не любят задачи, которые им не интересны. С другой стороны, если задача интересна — они горы свернут и свой фреймворк напишут, чтобы сделать невозможное.
Мои хорошие знакомые писали софт для очень крупной гос.организации и диалоги были в духе «Нам надо 7 красных строго перпендикулярных линий три из которых будут зелеными и несколько прозрачными». Заказчик ставил такого уровня задачи и платили большие деньги. Программисты вешались, но им платили премии чтобы они стойко переносили этот ад. Хаки писались над хаками и, возможно, некоторым из ребят, работавшим над этим проектом, до сих пор снятся кошмары.
От таких заказчиков и личной лени и вырабатывается скилл «увиливания от задач». Частенько бывает полезно задачу отложить на недельку или постараться от нее спрыгнуть, может заказчик передумает ее делать. Ведь частенько бывает, что приходится делать и потом переделывать и переделывать снова. А если разработчик чует дурную работу, которую надо будет переделывать — он постарается скипануть.
От таких заказчиков и личной лени и вырабатывается скилл «увиливания от задач». Частенько бывает полезно задачу отложить на недельку или постараться от нее спрыгнуть, может заказчик передумает ее делать. Ведь частенько бывает, что приходится делать и потом переделывать и переделывать снова. А если разработчик чует дурную работу, которую надо будет переделывать — он постарается скипануть.
Не везло вам с сотрудниками, у меня пока на памяти не было попыток соскочить с реализации фичи. Количество коллег за мою трудовую практику довольно большое было, в большинстве своем адекватные люди, которые вполне справлялись с поставленными задачами. Так что моя статистика говорит о том, что ваши разработчики — исключение (меньшинство) называйте как хотите, но под правило, что это национальная черта, на базе собсветнных наблюдений, уж извините, узколобо выходит.
Я открыл статью, увидев фото Макаревича. Подумал, неужели он что-то сюда написал?
Теперь у меня вопрос:
Причем здесь Андрей Макаревич?
Кстати, А.Макаревич — публичное лицо. И у него нужно спрашивать разрешение на публикацию. Впрочем, как и у любого другого.
Теперь у меня вопрос:
Причем здесь Андрей Макаревич?
Кстати, А.Макаревич — публичное лицо. И у него нужно спрашивать разрешение на публикацию. Впрочем, как и у любого другого.
вместо того, чтобы начать думать как решить проблему они часто начинают думать почему проблему решить нельзя.
Я вот иногда ищу некоторые экзотические решения для своих экзотических, но простых, проблем.
Часто попадаю на форумы MSDN. Там люди со значком MVP (признание от Microsoft), говорят что это не поддерживается, сделать невозможно и нереально.
Захожу на Стэковерфлоу – там говорят, что прямым путем сделать нельзя. Но, есть работающий хак…
Так что не только у наших разработчиков такое
Спасибо за статью.
Увидел себя со стороны. Много думал.
Хорошо, когда задача ставятся человеком, который знает, в каком направлении находится ее решение. Но иногда вместо ТЗ на входе просто «хотелки», без четкого описания и тем более направления развития.
Иногда задача не имеет видимого решения. Тогда нужно искать решение и, главное, обсуждать его совместно. Некоторые руководители от этого отстраняются, мол, как делать — это задача исполнителя.
Увидел себя со стороны. Много думал.
Хорошо, когда задача ставятся человеком, который знает, в каком направлении находится ее решение. Но иногда вместо ТЗ на входе просто «хотелки», без четкого описания и тем более направления развития.
Иногда задача не имеет видимого решения. Тогда нужно искать решение и, главное, обсуждать его совместно. Некоторые руководители от этого отстраняются, мол, как делать — это задача исполнителя.
В социологии и психологии есть основное правило: индивидуальные различия больше групповых. То есть два случайно взятых русских программиста в среднем отличаются друг от друга сильнее, чем все русские программисты от всех американских программистов. То есть про культурные различия можно говорить лишь на уровне тенденции, понимаю, что в каждом конкретном случае все может быть не так. В целом я с вами согласен. В русской культуре более выражена тенденция «к избеганию неудач». Соответственно разработчик боится взяться за задачу, решение которой он не видит «прямо сейчас». И ему легче рассказать, что это невозможно, чем попробовать решить.
В японской культуре избегание неудач еще выше. Но там есть социальный механизм — как только руководитель что-то сказал делать, он взял ответственность на себя. И если разработчик приложил достаточно усилий, а задача не решена — виноват руководитель, а не разработчик. То есть разработчик отвечает только за «усилие», а не за результат.
В японской культуре избегание неудач еще выше. Но там есть социальный механизм — как только руководитель что-то сказал делать, он взял ответственность на себя. И если разработчик приложил достаточно усилий, а задача не решена — виноват руководитель, а не разработчик. То есть разработчик отвечает только за «усилие», а не за результат.
Вот, допустим, я работник британской звукозаписывающей студии. Ко мне приезжает популярный исполнитель индийской музыки. Да я вообще ни сном ни духом, что у них там круто, а что нет, в плане европейской культуры это дикари. Я знаю как сделать сочнее звук отдельного инструмента, хорошо там встроить второй вокал и прочие технические тонкости, планы сбалансировать.
Но я в жизни не полезу в их дикарские вкусы, потому что не знаю что они там любят. Вдруг вдохи попашие на микрофон у них имеют огромную культурную роль, а вот это дребезжание это знак высшего мастерства игры на этой народной хрени, а сам исполнитель все это в деталях объяснить не может, с английским туго и вообще он Творит, какие тут объяснения.
Я будут просто брать деньги, которыми сыплет очередная папуасская звезда, улыбаться, и делать как они просят, закрыв глаза на все остальное, если лох саморазводится, то зачем ему мешать.
У папуасской звезды свой папуасский понт — эвон где я записываюсь, на рояле самого Элтона Джона и с гитарой Хендрикса и на пульте за 100500100500$. И обязательно про это еще в местечковой газете нужно рассказать, потому что ушами все эти понты не услышать.
И все довольны.
Но я в жизни не полезу в их дикарские вкусы, потому что не знаю что они там любят. Вдруг вдохи попашие на микрофон у них имеют огромную культурную роль, а вот это дребезжание это знак высшего мастерства игры на этой народной хрени, а сам исполнитель все это в деталях объяснить не может, с английским туго и вообще он Творит, какие тут объяснения.
Я будут просто брать деньги, которыми сыплет очередная папуасская звезда, улыбаться, и делать как они просят, закрыв глаза на все остальное, если лох саморазводится, то зачем ему мешать.
У папуасской звезды свой папуасский понт — эвон где я записываюсь, на рояле самого Элтона Джона и с гитарой Хендрикса и на пульте за 100500100500$. И обязательно про это еще в местечковой газете нужно рассказать, потому что ушами все эти понты не услышать.
И все довольны.
Фраза «это невозможно» в переводе на понятный язык обычно означает «сильное неприятие поставленной задачи, сопровождающееся нежеланием обсуждать причины неприятия». И проблема, стоящая за высказыванием такой фразы, многогранна.
К «русской душе», пожалуй, относится только одна из многочисленных граней проблемы — то, что на подобные высказывания нет культурного табу.
Остальное же — вполне интернациональные корни, при том некоторым национальностям кое-что из этих корней (судя по прошлым публикациям здесь на Хабре) может быть даже более присуще. Например, нежелание обсуждать детали проблемы и «жаловаться» явно не менее присуще индийцам и многим другим азиатам, для которых это почти равноценно демонстрации слабости.
Неприятие задачи может быть мотивировано, в том числе, причинами, которые сложно четко сформулировать, от того подробная аргументация будет звучать невнятно, а этого разработчик хочет, по возможности, избежать. В итоге смутную аргументацию, связанную, например, с его прошлым опытом, когда простые задачи оборачивались большим геморроем, он легко готов заменить на легкую грубость и безапелляционность.
Аналогичная ситуация — когда он действительно не знает, как именно решить задачу сходу, а акцент на детали в требованиях его раздражает, т.к. для реализации важны не они.
То есть велика вероятность, что если разработчик (или кто угодно — мне, например, такие фразы чаще приходилось слышать от бухгалтеров среднего возраста) отвечает на изложенную задачу фразой «это невозможно», то это является признаком, что он оказался в психологически сложной для себя ситуации. Не все из них требуют уважения (психологически сложно может быть и перебороть лень, но мы вроде бы говорим об исполнителях не из худших), но вопросы вроде «я не спрашиваю, в чем проблема, я спрашиваю, как/когда это будет сделано» способны только усилить проблему, добавив в нее конфликтную составляющую.
Исполнителя можно попросить высказать не аргументы, а сомнения. Вот тогда можно услышать те самые вещи, про которые по-русски можно сказать «я жопой чую, что будет геморрой», например. Или «это ведь все, наверняка, придется почти сразу переделывать». Или еще что-то. А уж услышав это — обсуждать нечто конкретное, а не переводить ситуацию в конфликт.
К слову, увольнение в ситуации, когда исполнитель имеет так и не высказанные причины для неприятия задачи, его ничему точно не научит — он будет даже в чем-то рад, что этот предполагаемый геморрой теперь будет расхлебывать кто-то другой.
К «русской душе», пожалуй, относится только одна из многочисленных граней проблемы — то, что на подобные высказывания нет культурного табу.
Остальное же — вполне интернациональные корни, при том некоторым национальностям кое-что из этих корней (судя по прошлым публикациям здесь на Хабре) может быть даже более присуще. Например, нежелание обсуждать детали проблемы и «жаловаться» явно не менее присуще индийцам и многим другим азиатам, для которых это почти равноценно демонстрации слабости.
Неприятие задачи может быть мотивировано, в том числе, причинами, которые сложно четко сформулировать, от того подробная аргументация будет звучать невнятно, а этого разработчик хочет, по возможности, избежать. В итоге смутную аргументацию, связанную, например, с его прошлым опытом, когда простые задачи оборачивались большим геморроем, он легко готов заменить на легкую грубость и безапелляционность.
Аналогичная ситуация — когда он действительно не знает, как именно решить задачу сходу, а акцент на детали в требованиях его раздражает, т.к. для реализации важны не они.
То есть велика вероятность, что если разработчик (или кто угодно — мне, например, такие фразы чаще приходилось слышать от бухгалтеров среднего возраста) отвечает на изложенную задачу фразой «это невозможно», то это является признаком, что он оказался в психологически сложной для себя ситуации. Не все из них требуют уважения (психологически сложно может быть и перебороть лень, но мы вроде бы говорим об исполнителях не из худших), но вопросы вроде «я не спрашиваю, в чем проблема, я спрашиваю, как/когда это будет сделано» способны только усилить проблему, добавив в нее конфликтную составляющую.
Исполнителя можно попросить высказать не аргументы, а сомнения. Вот тогда можно услышать те самые вещи, про которые по-русски можно сказать «я жопой чую, что будет геморрой», например. Или «это ведь все, наверняка, придется почти сразу переделывать». Или еще что-то. А уж услышав это — обсуждать нечто конкретное, а не переводить ситуацию в конфликт.
К слову, увольнение в ситуации, когда исполнитель имеет так и не высказанные причины для неприятия задачи, его ничему точно не научит — он будет даже в чем-то рад, что этот предполагаемый геморрой теперь будет расхлебывать кто-то другой.
В моей практике был случай, после которого я скорее соглашусь с автором статьи.
Десять лет тому назад, когда я был юным web-программистом, наша менеджер придумала для одного из наших сайтов помечать фотографии не категориями, а тем, что сейчас называется «облаком тегов». Я и мой коллега встали на дыбы — да где вы такое видели! что вы ещё придумали! вот категории это понятно, а это что такое?! Ей понадобилось немало сил, чтобы уговорить нас — и ничего страшного, реализация была ну, чуть сложнее, чем привычная. Было неловко за свою горячность, но с тех пор я стараюсь всё же делать, то что меня просят.
Анализируя свою мотивацию, мне видится, дело именно в непривычности и ещё некотором факторе Х, который я не могу пока вычислить. Ведь многие разработчики совершенно самостоятельно исследуют дома новые технологии, гоняют их на своих серверах. Однако, бывают случаи, когда непревычная область вызывает сильную неприязнь и не желание ей заниматься.
Десять лет тому назад, когда я был юным web-программистом, наша менеджер придумала для одного из наших сайтов помечать фотографии не категориями, а тем, что сейчас называется «облаком тегов». Я и мой коллега встали на дыбы — да где вы такое видели! что вы ещё придумали! вот категории это понятно, а это что такое?! Ей понадобилось немало сил, чтобы уговорить нас — и ничего страшного, реализация была ну, чуть сложнее, чем привычная. Было неловко за свою горячность, но с тех пор я стараюсь всё же делать, то что меня просят.
Анализируя свою мотивацию, мне видится, дело именно в непривычности и ещё некотором факторе Х, который я не могу пока вычислить. Ведь многие разработчики совершенно самостоятельно исследуют дома новые технологии, гоняют их на своих серверах. Однако, бывают случаи, когда непревычная область вызывает сильную неприязнь и не желание ей заниматься.
Предыдущая статья была хороша и все примеры увидел в реально жизни. Ваш же пример на мой взгляд натянут. За 5 лет работы лидом и много лет до до этого старшим разработчиком подобное если и замечал то редко. Да есть стремление к перфекционизму, но такого жесткого неадеквата не встречал. А причина вашей ситуации совсем в другом. Ваша «проблема» не стала проблемой человека к которому вы обращаетесь. Чтобы человек начал что-то делать это должно стать его проблемой и в этом проявляется умение руководителя. И против вас тут будет как раз играть нелояльность по умолчанию характерная для «наших». Ну прибыль какая-то, ну премия, а у меня тут он какие завитушки и изящное решение в прошломесячной проблеме никто не заценил и тут еще этот хочет чтобы я влезаал в задачу не по своему профилю, я то конечно могу, но ведь если им понравится могут потом постоянно таким нагружать. А вы как он такой сякой не смеет рвать части тела ради благой цели и почему-то еще размышляет вместо того чтобы начать вджобывать.
Это называется разговор слепого с глухим. Вы не слышите один одного и то что вы все еще программируете не делает вас ближе.
Причин у этого может быть много, но я не вижу с описанной ситуации что вы поняли что в первую очередь были неправы вы, вы недостаточно осмыслили ситуацию и пошли самым простым путем. Я напишу руководство что все должны шагать строевым шагом и каждую среду петь оды Луне и все разрешится. Во только если ситуация не меняется, возможно в постановке вопроса что-то не так и причина глубже?
Если у вас есть выбор и вы несовместимы и не пытаетесь совместится с мировоззрением «наших» программистов, есть выход конечно проще не нанимать таких и не браться такими управлять. Если выбора нет, нужно искать способ стать «своим», завоевать уважение и понять мотивацию сотрудника. Путь этот не простой, но ведь руководителю за вредность «кефир» полагается?
Это называется разговор слепого с глухим. Вы не слышите один одного и то что вы все еще программируете не делает вас ближе.
Причин у этого может быть много, но я не вижу с описанной ситуации что вы поняли что в первую очередь были неправы вы, вы недостаточно осмыслили ситуацию и пошли самым простым путем. Я напишу руководство что все должны шагать строевым шагом и каждую среду петь оды Луне и все разрешится. Во только если ситуация не меняется, возможно в постановке вопроса что-то не так и причина глубже?
Если у вас есть выбор и вы несовместимы и не пытаетесь совместится с мировоззрением «наших» программистов, есть выход конечно проще не нанимать таких и не браться такими управлять. Если выбора нет, нужно искать способ стать «своим», завоевать уважение и понять мотивацию сотрудника. Путь этот не простой, но ведь руководителю за вредность «кефир» полагается?
>Это даже не лень, не отсутствие квалификации.
Любая новая штука (какая бы она крутая не была) для работающего проекта/агрегата… да чего угодно работающего, выполняющего круг своих задач — это модификация.
Видимо, у многих с данной культурной особенностью в голове засело правило инженера — Работает — не трогай!
Любая новая штука (какая бы она крутая не была) для работающего проекта/агрегата… да чего угодно работающего, выполняющего круг своих задач — это модификация.
Видимо, у многих с данной культурной особенностью в голове засело правило инженера — Работает — не трогай!
Все в общем-то просто. Проблема (как часто бывает) чисто лингвистическая. :)
Когда русскому программисту говорят «сделай это» — он понимает задачу как «чисто сделать» (закодить) известными и понятными методами.
(Это конечно верно не для всех, есть достаточно умные ребята, которые поведут себя «по западному» — но это уже личное достижение, способность думать в разных культурных контекстах.)
И его «не могу сделать» — означает «не могу, с имеющимися знаниями, имеющимся инструментарием, и в точности как запрошено».
Если решение задачи имеет принципиальный приоритет, а вот начальные условия можно менять, то это должно быть произнесено явно.
Например:
"- Нам нужно решить такую-то задачу, исследуй вопрос, какими техническими средствами это можно реализовать."
В этом случае «размораживаются» параметры обучения и поиска инструментов (корме имеющихся у него сейчас). Но замечу, все остальные параметры, как то «изготовление несуществующего пока инструмента» или «изменение формулировки задачи» — остаются замороженными. Для их размораживания потребуются другие фразы.
Когда русскому программисту говорят «сделай это» — он понимает задачу как «чисто сделать» (закодить) известными и понятными методами.
(Это конечно верно не для всех, есть достаточно умные ребята, которые поведут себя «по западному» — но это уже личное достижение, способность думать в разных культурных контекстах.)
И его «не могу сделать» — означает «не могу, с имеющимися знаниями, имеющимся инструментарием, и в точности как запрошено».
Если решение задачи имеет принципиальный приоритет, а вот начальные условия можно менять, то это должно быть произнесено явно.
Например:
"- Нам нужно решить такую-то задачу, исследуй вопрос, какими техническими средствами это можно реализовать."
В этом случае «размораживаются» параметры обучения и поиска инструментов (корме имеющихся у него сейчас). Но замечу, все остальные параметры, как то «изготовление несуществующего пока инструмента» или «изменение формулировки задачи» — остаются замороженными. Для их размораживания потребуются другие фразы.
Как-то, как мне кажется, это все по-детски, слабо и бесхарактерно. Лишь отмазки и т.п. Разве можно так чего-то достигнуть?
Для меня всегда было очевидным: есть проблема — надо решить.
Почему многие этого не понимают я не знаю. Точнее, они наверное понимают, но делать этого не хотят.
Для меня всегда было очевидным: есть проблема — надо решить.
Почему многие этого не понимают я не знаю. Точнее, они наверное понимают, но делать этого не хотят.
Если есть кто-то разбирающийся в социологии/психологии или знакомый лично с социологом/психологом: проясните, пожалуйста.
1) вы плохой тимлид
2) у вас плохой разработчик.
Возможны как первый, как второй, так все три сразу.
1) Вы сами написали, что хотите чтобы разработчик решал проблему, а не сюсюкал почему это нельзя. А сами ее не решаете. Да, вы, конечно, закодили это сами, но это значит, что вы хороший разработчик (отличный, чего уж там), но не тимлид. Вы просто поругались и может силой заставили делать.
Задача тимлида, чтобы все и всё работало. Я вот хочу чувствовать, что мои действия приводят к моим доходом. Но вот оратору сверху, на это начхать, у него другие ценности. Вы как хороший тимлид должны это понимать и использовать. Тогда у вас все разработчики будуд хорошими, потому что сейчас…
2)… да, сейчас у вас плохой разработчик. Ты (разработчик) можешь быть гением, можешь быть создавать невероятные вещи, но если ничего из этого не приносит прибыль, для начальства ты плохой. Это для начальства, для меня, например, ты очень даже хороший. Но вот если ты не пытаешся сделать, то чего делать не умеешь, не пытаешся этому научится, придумать что-нибудть (вообщем, все то что нужно топиккастеру), то ты не разработчик даже. Потому что я не знаю, как, вообще, можно на этой стезе продвинуться без постоянного вопроса в голове: «А как я могу это сделать?».
Но все может быть и подругому. Обычно это вот так:
Начальник: Мне нужно чтобы мы получали весь список сайтов которые посетил пользователь до того как пришел к нам.
Разработчик: Это невозможно
Начальник: WTF! Да как так. Я раньше тоже программировал. На Бейсике. Что значит невозможно.
Разработчик: «много технических подробнестей»
Начальник: ААА! Ты ничего не пытаешся сделать… Ты пиписька! *уходит делать сам*
— спустя 1,5 дня
Начальник: Вот я сделал! Показывает поле в который пользователь сам должен забивать все посещенные сайты.
Разработчик:… ?!&#!!!^
По своему опыту скажу, описанные программисты и инженеры встречаются. Но мне все же приходилось больше работать с людьми, которым нравится решать нестандартные задачи. И имхо настоящих программистов мотивировать деньгами практически невозможно — тут нужно иметь дар убеждения.
У меня был такой же случай, но не в разработке, а в поисковой оптимизации. Когда мне поставили совершенно дурацкую, бестолковую и трудновыполнимую задачу. Я отказался, меня уволили. Не жалею.
Если я работаю, то для меня важен результат, чтобы я своей работой мог гордиться и понимать зачем я это делал, а не знаиматься всякой ерундой лишь потому, что начальнику моча в голову стукнула. Наверняка, ваши разработчики были перфекционистами и понимали, что сделать хорошо на инструментах которые они знают, нельзя, а делать дерьмо на других технологиях они не хотят. Даже если это кривое дерьмо потом принесет фирме деньги.
Поэтому есть выход. Если задача действительно важная, то перфекционистам надо дать время разобраться в проблеме и ни в коем случае не ставить сроки ее решения. Потому что если тебе в незнакомой области поставили срок, то легче послать всех нафиг, чем браться за работу, сделать кривое дерьмо и оправдываться потом.
Если я работаю, то для меня важен результат, чтобы я своей работой мог гордиться и понимать зачем я это делал, а не знаиматься всякой ерундой лишь потому, что начальнику моча в голову стукнула. Наверняка, ваши разработчики были перфекционистами и понимали, что сделать хорошо на инструментах которые они знают, нельзя, а делать дерьмо на других технологиях они не хотят. Даже если это кривое дерьмо потом принесет фирме деньги.
Поэтому есть выход. Если задача действительно важная, то перфекционистам надо дать время разобраться в проблеме и ни в коем случае не ставить сроки ее решения. Потому что если тебе в незнакомой области поставили срок, то легче послать всех нафиг, чем браться за работу, сделать кривое дерьмо и оправдываться потом.
Какая-то повальная мода пошла — брать людей из ближайшего окружения, проецировать их характер и поведению на нацию, обзывать это менталитетом и писать на эту тему статьи.
Ау, люди, если уж фломастеры разные, то что уж говорить о людях.
Ау, люди, если уж фломастеры разные, то что уж говорить о людях.
Какая-то надуманная статься, слишком капитанская и ИМХО что-то в ней осталось за кадром.
Если я сам матёрый кодер, лид и архитектор, то я не даю неразрешимых задач, в принципе, при таком раскладе описанная ситуация не возможна вне зависимости от национально\рассово\религиозно\сексуальной принадлежности исполнителя!
Если же такая ситуация произошла, это каг-бэ намекае на то, что у аспадина насяльника кимоно-то херовато.
ИМХО проблема национального менталитета всё-же имеет место быть. Ведь это токмо у нас звукорежиссёр на все уши мастер, проявляющий инициативу по поводу и без повода, хотя в последние годы дела идут на поправку… Программист работает работает программистом, и не надо на него перекладывать вопросы архитектуры, креатива, финансов, это есть чисто рюский заморочка.
А там давно ребята есть, которым платят только за то, что они руководят процессом записи или разработки программного продукта, не суть важно.
Я не пипец-какой манагер, но уже достаточно давно получаю деньги за то что иногда даже ору очень громко на звукорежиссёров и творческих личностей, которые, именно за это мне и платят :-) Ибо в итоге так получается быстрей, дешевле и качественней, чем ждать инициативы от звукорежиссёров\программистов и даже самого себя.
Если я сам матёрый кодер, лид и архитектор, то я не даю неразрешимых задач, в принципе, при таком раскладе описанная ситуация не возможна вне зависимости от национально\рассово\религиозно\сексуальной принадлежности исполнителя!
Если же такая ситуация произошла, это каг-бэ намекае на то, что у аспадина насяльника кимоно-то херовато.
ИМХО проблема национального менталитета всё-же имеет место быть. Ведь это токмо у нас звукорежиссёр на все уши мастер, проявляющий инициативу по поводу и без повода, хотя в последние годы дела идут на поправку… Программист работает работает программистом, и не надо на него перекладывать вопросы архитектуры, креатива, финансов, это есть чисто рюский заморочка.
А там давно ребята есть, которым платят только за то, что они руководят процессом записи или разработки программного продукта, не суть важно.
Я не пипец-какой манагер, но уже достаточно давно получаю деньги за то что иногда даже ору очень громко на звукорежиссёров и творческих личностей, которые, именно за это мне и платят :-) Ибо в итоге так получается быстрей, дешевле и качественней, чем ждать инициативы от звукорежиссёров\программистов и даже самого себя.
А мне одному стало интересно, какого рода задачу отказался делать исполнитель из топика?
Примеряю подобную ситуацию на себя, вспомнил, что с самого начала работы приучил себя никогда не отвечать менеджерам «это невозможно», так как какой бы сложной задача не была (сейчас не будем о теоретически нерешаемых, речь об обычных прикладных задачах в вебе), ее можно реализовать, тем более, если подобная уже была реализована где-то. «Невозможно» обычно значит «я пока не знаю как» или «я, конечно сделаю, но в те сроки что вы мне дали — никак не справлюсь».
Упертость конкретного разработчика из поста больше похожа на поведение обиженного ребенка, связано это с какими-то его внутренними тараканами, да еще вероятнее всего ситуация вырвана из конетекста. И уж точно никак не вписывается в рамки тезиса «вот главная черта характера отечественных программистов».
Примеряю подобную ситуацию на себя, вспомнил, что с самого начала работы приучил себя никогда не отвечать менеджерам «это невозможно», так как какой бы сложной задача не была (сейчас не будем о теоретически нерешаемых, речь об обычных прикладных задачах в вебе), ее можно реализовать, тем более, если подобная уже была реализована где-то. «Невозможно» обычно значит «я пока не знаю как» или «я, конечно сделаю, но в те сроки что вы мне дали — никак не справлюсь».
Упертость конкретного разработчика из поста больше похожа на поведение обиженного ребенка, связано это с какими-то его внутренними тараканами, да еще вероятнее всего ситуация вырвана из конетекста. И уж точно никак не вписывается в рамки тезиса «вот главная черта характера отечественных программистов».
какого рода задачу отказался делать исполнитель из топика?
Точно! Задачу в студию! Это многое прояснит.
Опишите хотя бы в общих чертах.
Я использую слово «нерентабельно».
Полностью поддерживаю. Не понимаю, почему пост набрал столько плюсов. Контекст бы не помешал.
Так что, будет описание задачи, или там все же был случай похожий на habrahabr.ru/post/185638/#comment_6460098?
Автор вроде уже был на сайте с утра, но может времени не было расписать.
Очень интересно услышать, что за проблема там решалась.
Автор вроде уже был на сайте с утра, но может времени не было расписать.
Очень интересно услышать, что за проблема там решалась.
Буквально вчера был вот такой разговор (цитирую не дословно, догадайтесь сами какие реплики мои)
— Можешь кое-что сделать?
— Да
— Сделай, пожалуйста, вот это и вот это
— Нет, я это делать принципиально не буду
— Почему?
— Потому что это бесполезная трата времени
— Можешь кое-что сделать?
— Да
— Сделай, пожалуйста, вот это и вот это
— Нет, я это делать принципиально не буду
— Почему?
— Потому что это бесполезная трата времени
А это не было бесполезной тратой времени? Без иронии и подколок. Просто как человек это аргументировал?
Это *было* бесполезной тратой *моего* времени.
В детали вдаваться не буду. Это тоже будет напрасной тратой моего и вашего времени.
Просто не надо считать отказ сделать что-то «основной особенностью разработчика»
В детали вдаваться не буду. Это тоже будет напрасной тратой моего и вашего времени.
Просто не надо считать отказ сделать что-то «основной особенностью разработчика»
Ваше время куплено человеком, который тратит его так, как он сам этого хочет. Когда у вас будет хватать компетенции самостоятельно принимать подобные решения — вы уволитесь и устроитесь куда-то на его должность.
Да, я понимаю, что вам неприятно это читать, но так и есть. И я покажу вам простой пример.
У меня на даче работает таджик, получает он за это кроме еды еще 30к рублей и меня не волнует его мнение по поводу куда и какие цветы сажать. Какие-то цветы я хочу чтобы были по центру газона, там жарит солнце, и ему, естественно не хочется там работать. Он утверждает, что цветы там выгорят, что это пустая трата времени и все такое. Его работа копать лунки и тыкать туда рассаду. В этом деле он профи. А вот какую рассаду и куда сажать — это моя забота, ему же просто не хочется копать под солнцем.
Да, я понимаю, что вам неприятно это читать, но так и есть. И я покажу вам простой пример.
У меня на даче работает таджик, получает он за это кроме еды еще 30к рублей и меня не волнует его мнение по поводу куда и какие цветы сажать. Какие-то цветы я хочу чтобы были по центру газона, там жарит солнце, и ему, естественно не хочется там работать. Он утверждает, что цветы там выгорят, что это пустая трата времени и все такое. Его работа копать лунки и тыкать туда рассаду. В этом деле он профи. А вот какую рассаду и куда сажать — это моя забота, ему же просто не хочется копать под солнцем.
я хотел бы оспорить тезис "… ваше время куплено человеком и он вправе тратить его..."
если я разработчик — это вовсе не значит последнюю ступеньку в должностной иерархии.
моего непосредственного начальника я лично интервьюировал при приеме не работу и советовал брать.
кто ж виноват в том, что я лучше него умею программировать, но зато он лучше умеет управлять коллективом?
иногда надо уметь сказать «нет», вместо того, чтобы бездумно выполнять самые дурацкие просьбы.
если я разработчик — это вовсе не значит последнюю ступеньку в должностной иерархии.
моего непосредственного начальника я лично интервьюировал при приеме не работу и советовал брать.
кто ж виноват в том, что я лучше него умею программировать, но зато он лучше умеет управлять коллективом?
иногда надо уметь сказать «нет», вместо того, чтобы бездумно выполнять самые дурацкие просьбы.
Вы же сможете привести пример подобной «дурацкой просьбы», да?
примерами нельзя доказать некий тезис.
поэтому специально не буду давать вам тему для обсуждения «кто прав кто виноват».
у разработчика бывают ошибки и есть специально обученные тестеры, которые эти ошибки вылавливают.
у разработчика есть также специальные методики и паттерны — как минимизировать количество ошибок.
я утверждаю, что и у начальников бывают ошибки и манагеры в силу тех или иных причин отступают от правильных паттернов поведения. в таком случае — надо вовремя указать на ошибку.
я же не обвиняю тестера, что он нашел проблему в моей программе — наоборот, чем раньше проблема обнаружена — тем лучше.
поэтому специально не буду давать вам тему для обсуждения «кто прав кто виноват».
у разработчика бывают ошибки и есть специально обученные тестеры, которые эти ошибки вылавливают.
у разработчика есть также специальные методики и паттерны — как минимизировать количество ошибок.
я утверждаю, что и у начальников бывают ошибки и манагеры в силу тех или иных причин отступают от правильных паттернов поведения. в таком случае — надо вовремя указать на ошибку.
я же не обвиняю тестера, что он нашел проблему в моей программе — наоборот, чем раньше проблема обнаружена — тем лучше.
примерами нельзя доказать некий тезис.
ох уж эта женская логика…
"Тезис – это выдвинутое оппонентом суждение, которое он обосновывает в процессе аргументации. Тезис является главным структурным элементом аргументации и отвечает на вопрос: что обосновывают."(с) Логика
Вы же сами захотели оспорить мой тезис =) причем в качестве примера привели ваш уникальный случай, когда начальник отдела — менеджер, а не технический специалист владеющий навыками программирования.
Заметьте, что указывать на ошибки, и отказываться что-то делать по тому что это невозможно — это две большие разницы. И в этом соль и сахар рассказа :)
Ответ «я это делать принципиально не буду» и «потому что это бесполезная трата времени» может быть дан разработчиком в двух случаях:
— он не хочет работать
— он понимает что эта задача на самом деле не нужна заказчику / эта задача будет стоить слишком дорого
В первом случае — не вижу смысла держать таких разработчиков (вдруг завтра баг в продакшене а он откажется его фиксить «из принципа»).
Во втором — разработчик должен уметь объяснить заказчику почему он так считает.
— он не хочет работать
— он понимает что эта задача на самом деле не нужна заказчику / эта задача будет стоить слишком дорого
В первом случае — не вижу смысла держать таких разработчиков (вдруг завтра баг в продакшене а он откажется его фиксить «из принципа»).
Во втором — разработчик должен уметь объяснить заказчику почему он так считает.
1) Прошу не обобщать на всех разработчиков. Я например прошу время на обдумывание для сложных задач. Я знаю что за время разговора решение может и не вырисоваться.
2) Такие ответы означают, что в данный момент они не знают как это сделать. Да, неправильно выражаются.
Выход из сложившейся ситуации: дать время подумать.
Как? Сначала выслать задание в письменном виде, разработчик сможет подумать как его можно реализовать, у него могут появиться вопросы, которые можно обсудить в частном порядке. Иногда и проходит 1-2 дня прежде, чем приходит решение.
P.S. это можно занести в списки антипаттернов общения тимлид-девелопер
2) Такие ответы означают, что в данный момент они не знают как это сделать. Да, неправильно выражаются.
Выход из сложившейся ситуации: дать время подумать.
Как? Сначала выслать задание в письменном виде, разработчик сможет подумать как его можно реализовать, у него могут появиться вопросы, которые можно обсудить в частном порядке. Иногда и проходит 1-2 дня прежде, чем приходит решение.
P.S. это можно занести в списки антипаттернов общения тимлид-девелопер
Работаю в компании уже много лет. У шефа (давно) присутствует пара революционных идей технического плана, но реализация этих идей тянет за собой много не очевидных проблем.
Опытные разработчики (типа меня) всегда старались «съехать» — увильнуть от реализации под любыми предлогами. Зато как только появляется новый разработчик, и он соглашается на реализацию — это безошибочный признак, что он через полгода уволится ;-) Вот такие «проклятые» задания. Так никто шефу и не смог реализовать его идеи :-)
Некоторых удалось отстоять, перебрасывая на более актуальные проекты.
Опытные разработчики (типа меня) всегда старались «съехать» — увильнуть от реализации под любыми предлогами. Зато как только появляется новый разработчик, и он соглашается на реализацию — это безошибочный признак, что он через полгода уволится ;-) Вот такие «проклятые» задания. Так никто шефу и не смог реализовать его идеи :-)
Некоторых удалось отстоять, перебрасывая на более актуальные проекты.
Даже залогинился на Хабре в кои-то веки. Автору респект, но я думаю, что он сам осознаёт что это внешние проявления чего-то более глубинного — менталитета. Я годами наблюдают разницу даже не между разработчиками «нашими» и «западными», а просто разницу между людьми. Европейцам важно мягкое и по возможности бесконфликтное разрешение ситуаций, т.к. они гораздо раньше начали решать вопросы совместного проживания на ограниченной территории и весьма в этом преуспели! Они не боятся сложных проблем, поскольку даже провал не будет стоить им жизни. В этом смысле ошибка в «наших» краях ещё сравнительно недавно (даже 15-20 лет назад) могла стоить жизни не только автору, но и его семье, а много где и до сих пор может стоить. Отсюда стремление к тому, чего не хватает — Стабильности. Именно так, с большой буквы, поскольку «наших» может устраивать стабильность даже в достаточно извращённой форме как «кое-какая зарплата за кое-какую работу, которую человек делает кое-как». Есть страх риска, страх начать, вложиться в новое в широких слоях населения. Но в то же время те, кто перестали боятся риска, в потере страха обгоняют тех же самых европейцев и готовы на любой риск это может принести сказочное богатство… Тут сыграли свою роль и исторические события, и религия, и количество носителей языка, и география, поскольку от региона к региону вес этих составляющих разнится. Но по сумме получается, что в Европе легко найти магазин где за прилавком стоит хозяин, а ездит он на недорогой практичной машине среднего класса, а «у нас» за прилавком продавец, работающий сутками за гроши, но владелец на джипе. Это не хорошо и не плохо, так есть. Безбашенные и готовые на риск люди быстрее перестраиваются при изменении ситуации, они будут более успешны в неожиданных ситуациях и такая готовность на риск позволяет держать хоть какой, но контроль над значительными территориями (тут, наверно, есть сходство у населяющих все большие по площади страны), но увы, им будет до невозможности скучно жить в обществе ориентированном на стабильность (оттуда слышны возмущения на количество правил и законов в Европе, стукачество и т.д.). В общем, я не вижу тут никакого однозначного решения, поскольку это даже не проблема, а такие проявления неких более глубинных установок. Возможно, через 30 лет я смогу написать об этом книжку, но читать её будут скорее всего не те, кому 20 лет, а те, кому 60 и восклицать «да, именно так». Мне кажется, что осознание этих проблем является некой ступенью в развитии, которой все достигают.
Мне кажется, глубинная проблема, на которую обращает внимание автор — то, что люди не видят связь между результатами своей работы, и наличием денег у директора на зарплату.
И им это даже не интересно: «в договоре прописано эн рублей в месяц, значит директор заплатит эти эн рублей — какое мне дело, откуда он их возьмёт».
Собственно, даже здесь в комментариях такую точку зрения высказывали.
Не возьмусь утверждать, что эта точка зрения сугубо-российская, но действительно, у россиян она встречается чаще, чем у европейцев.
Наверное, дело в том, что во многих российских предприятиях (по старой доброй советской модели?) действительно нет связи между результатами работы и финансовым положением: работа оплачивается не довольными клиентами, а «инвесторами» (будь то госзаказы, гранты, венчурные фонды), которым качество продукта в общем-то без разницы — и поэтому действительно неважно, что сделано, важно, как обоснованы траты перед «инвестором».
Взять даже хабрастатьи о стартапах. «Путь к успеху» в них выглядит так:
1) придумать классную идею
2) получить под неё инвестиции
3) ???
4) продать стартап подороже
Ни о качестве продукта, ни о проработке клиентской базы — речь обычно не заходит.
И им это даже не интересно: «в договоре прописано эн рублей в месяц, значит директор заплатит эти эн рублей — какое мне дело, откуда он их возьмёт».
Собственно, даже здесь в комментариях такую точку зрения высказывали.
Не возьмусь утверждать, что эта точка зрения сугубо-российская, но действительно, у россиян она встречается чаще, чем у европейцев.
Наверное, дело в том, что во многих российских предприятиях (по старой доброй советской модели?) действительно нет связи между результатами работы и финансовым положением: работа оплачивается не довольными клиентами, а «инвесторами» (будь то госзаказы, гранты, венчурные фонды), которым качество продукта в общем-то без разницы — и поэтому действительно неважно, что сделано, важно, как обоснованы траты перед «инвестором».
Взять даже хабрастатьи о стартапах. «Путь к успеху» в них выглядит так:
1) придумать классную идею
2) получить под неё инвестиции
3) ???
4) продать стартап подороже
Ни о качестве продукта, ни о проработке клиентской базы — речь обычно не заходит.
Даже если взять «прямые продажи», то часто от разработчиков сумма денег, получаемых фирмой, не зависит. Менеджмент заказывает фичу, менеджмент принимает фичу, менеджмент пытается с её помощью заработать денег. А увеличит или уменьшит входящий денежный поток фирмы эта фича от разработчика не зависит (при условии, что явных багов нет и т. п.). Максимум что он может делать для увеличение прибыли — снижать время на разработку и поддержку фич, увеличивая свою производительность либо за счет роста профессионализма, либо за счёт снижения качества, в общем делая, чтобы фирме эти фичи доставались дешевле. При этом, кстати, менеджмент далеко не всегда доводит до разработчиков приоритеты фирмы на краткосрочную или долгосрочную выгоду. А если доводит, то фокусируется на краткосрочной.
Как вы и пишете, от разработчика зависит время и качество выполнения фичи, а значит, и денежный поток тоже зависит — ведь он зависит от количества фич, сданных в эксплуатацию в единицу времени.
Статья автора о том же самом — что можно отказаться делать фичу (с подробным обоснованием почему она невыполнима), можно сделать её «на отвяжись», можно сделать её так, чтобы менеджмент принял с первого раза. Экономическая выгода компании от разработчика во всех этих случаях разная.
Статья автора о том же самом — что можно отказаться делать фичу (с подробным обоснованием почему она невыполнима), можно сделать её «на отвяжись», можно сделать её так, чтобы менеджмент принял с первого раза. Экономическая выгода компании от разработчика во всех этих случаях разная.
В том и дело, что он скорее не зависит, а как-то неявно коррелирует. Какие-то быстро и идеально (технически) сделанные фичи могут вообще убить бизнес (скажем защита от противоправного контента :), а могут на него не повлиять никак (фича, которой никто не пользуется). В общем, плохая реализация может убить хорошую идею, но вот хорошая реализация плохую идею хорошей не сделает.
Переделка сайта по манифесту разработчика — хороша для статьи. Но только про ссылку на англ. версию надо убрать или же все-таки эту самую англ. версию сделать.
А вобще по статье — интересно, какое-то зерно истины тут есть. Хотя, как мне кажется, применимо все сказанное от случая к случаю, т.к. не все халявщики, просто не всегда могут нормально изъяснить причину — почему нельзя. А вобще, как сказал Эйнштейн: «Если Вы не можете объяснить что-то шестилетнему ребенку, значит, Вы сами этого не понимаете» — очень часто в этом и кроется причина почему подчиненный не может объяснить начальству, почему нельзя сделать. Хотя, опять таки, в ваших примерах были отмазки со стороны инженеров.
А вобще по статье — интересно, какое-то зерно истины тут есть. Хотя, как мне кажется, применимо все сказанное от случая к случаю, т.к. не все халявщики, просто не всегда могут нормально изъяснить причину — почему нельзя. А вобще, как сказал Эйнштейн: «Если Вы не можете объяснить что-то шестилетнему ребенку, значит, Вы сами этого не понимаете» — очень часто в этом и кроется причина почему подчиненный не может объяснить начальству, почему нельзя сделать. Хотя, опять таки, в ваших примерах были отмазки со стороны инженеров.
На мой восточно-западный взгляд (Израиль), разработчик никогда бы так не поступил бы так, если бы хоть когда то работал фрилансером.
Замечаю на собственном опыте что пытаюсь переносить опыт фрилансерской работы на постоянную работу в коллективе.
Замечаю на собственном опыте что пытаюсь переносить опыт фрилансерской работы на постоянную работу в коллективе.
Знаете, я занимаюсь программированием, но в отношении достаточно сложных научно-технических проектов. И похожая ситуация возникает в одном из проектов достаточно часто часто. Приходит научрук и говорит: «А давай замутим такую функцию софта!». Идея логичная и аргументация правильная. И выглядит всё просто.
Но я понимаю, что это нельзя делать. А почему?
Потому что софт, который работает — управляет большим количеством аппаратуры. Он крутиться на нескольких компьютерах и выполняется во множество потоков. Так получилось, что я его единственный программист и разработчик на данный момент. И знаю до каждого винтика каждую железяку и кусок программы. Архитектуру всего этого продумывал когда-то не одну неделю, на основании возможностей железа и прошлых версий нашего софта.
Я знаю как сделать предложенную научруком функцию. Но я так же прекрасно знаю о последствиях. О том что сделать её вставив органически нельзя, а вставленные костыли разрушат архитектуру комплекса, которую я выстраивал последний год. И каждое следующее изменение после этих костылей будет убивать всю эту архитектуру, сводя софт к хаосу в котором один человек уже не сможет разобраться.
А вот тут начинается самое сложное. Как убедить в этом научрука. Он хочет непосредственных причин почему это нельзя сделать. А причины то привести сложно. «Ну да, изменить пару классов», «Ну да, добавить пяток глобальных переменных», «Ну да, перенести рассчёт из трэдов в основное тело программы», «Ну да, у нас поменяется формат файлов», «Ну и что?».
Важно соизмерять возможности новой «фишечки» и возможные затраты и ущерб, которые она в дальнейшем нанесёт.
Но я понимаю, что это нельзя делать. А почему?
Потому что софт, который работает — управляет большим количеством аппаратуры. Он крутиться на нескольких компьютерах и выполняется во множество потоков. Так получилось, что я его единственный программист и разработчик на данный момент. И знаю до каждого винтика каждую железяку и кусок программы. Архитектуру всего этого продумывал когда-то не одну неделю, на основании возможностей железа и прошлых версий нашего софта.
Я знаю как сделать предложенную научруком функцию. Но я так же прекрасно знаю о последствиях. О том что сделать её вставив органически нельзя, а вставленные костыли разрушат архитектуру комплекса, которую я выстраивал последний год. И каждое следующее изменение после этих костылей будет убивать всю эту архитектуру, сводя софт к хаосу в котором один человек уже не сможет разобраться.
А вот тут начинается самое сложное. Как убедить в этом научрука. Он хочет непосредственных причин почему это нельзя сделать. А причины то привести сложно. «Ну да, изменить пару классов», «Ну да, добавить пяток глобальных переменных», «Ну да, перенести рассчёт из трэдов в основное тело программы», «Ну да, у нас поменяется формат файлов», «Ну и что?».
Важно соизмерять возможности новой «фишечки» и возможные затраты и ущерб, которые она в дальнейшем нанесёт.
Я тоже как менеджер проектов в анамнезе сталкивался с подобным.
Ну раз вы так поставили вопрос.
С точки зрения социологии: есть Хофстед, и различия в культурах по нему по измерениям, в частности «коллективизм-индивидуализм», и по измерению power distance (отношению между начальником и подчиненным). Зря вы выкидываете из рассмотрения отношения начальник-подчиненный — именно это одна из причин отказа. С точки зрения социологии это выглядит как «я не буду делать это для тебя, потому что ты мне приказываешь» (особенно если возраст у начальника меньше).
С точки зрения психологии: отрицание, отказ, — это защита (причем примитивная достаточно, а КонтрКонтрАргументы — это интеллектуализация — более сложная защита). Защита личности от… новизны! Новую фичу прикрутить, это ведь надо сделать что-то необычное (а ведь отказ происходит именно от новых фич). Люди (чаще постарше) к этому бывают не готовы. Они привыкли писать что-то известное им, а что-то, что они не делали, вызывает у них попаболь.
Просьба воспринимать мой коммент как одну из возможных интерпретаций упомянутых автором явлений, не более.
Если есть кто-то разбирающийся в социологии/психологии или знакомый лично с социологом/психологом: проясните, пожалуйста.
Ну раз вы так поставили вопрос.
С точки зрения социологии: есть Хофстед, и различия в культурах по нему по измерениям, в частности «коллективизм-индивидуализм», и по измерению power distance (отношению между начальником и подчиненным). Зря вы выкидываете из рассмотрения отношения начальник-подчиненный — именно это одна из причин отказа. С точки зрения социологии это выглядит как «я не буду делать это для тебя, потому что ты мне приказываешь» (особенно если возраст у начальника меньше).
С точки зрения психологии: отрицание, отказ, — это защита (причем примитивная достаточно, а КонтрКонтрАргументы — это интеллектуализация — более сложная защита). Защита личности от… новизны! Новую фичу прикрутить, это ведь надо сделать что-то необычное (а ведь отказ происходит именно от новых фич). Люди (чаще постарше) к этому бывают не готовы. Они привыкли писать что-то известное им, а что-то, что они не делали, вызывает у них попаболь.
Просьба воспринимать мой коммент как одну из возможных интерпретаций упомянутых автором явлений, не более.
Бывает встречаются такие люди, которые на любую просьбу или предложение первым делом говорят категоричное НЕТ. Их потом обычно можно переубедить, но вот это сходу категоричное нет просто вымораживает. Расцениваю это как самодурство, воспитанное в семье такими же родителями. А может быть, это какая-то психологическая защитная реакция.
Разве это особенность именно отечественных разработчиков? Попадался на глаза не так давно юмористический текст с перечнем типов работников, одним из которых был такой вот «человек-roadblock». Текст вроде был англоязычный.
А вообще старая же шутка, что «настоящий программист это тот, кто в любой ситуации способен объяснить заказчику почему то, что он просит, сделать невозможно» (-:
А вообще старая же шутка, что «настоящий программист это тот, кто в любой ситуации способен объяснить заказчику почему то, что он просит, сделать невозможно» (-:
Предположим, что в программировании есть некая область, решение задач в которой невозможно. Логично предположить, что с течением времени сообщество программистов выделило бы под такие задачи некий ресурс, и аккумулировало их в этом месте, чтобы направлять туда нерадивых «манагеров» непосредственно сразу после постановки задачи. Но такого списка, на сколько я в курсе, нет… В отличии от других областей (математика, физика). Можно как-то апеллировать к алгоритмическим задачам, но я не верю, что только русскоязычным программистам впаривают доказать равенство классов P и NP =) Очевидно, что произнося работодателю слово «это невозможно» сотрудник признается в собственной некомпетентности и не более того.
Кстати, даже для нерешаемых задач есть способ решения. Например, вам поставлена задача написать программу, которая будет делить числа А и Б при любых А и Б. Вспоминаем, что на ноль делить нельзя. И вместо того, чтобы блистать своими знаниями решаем задачу для всех остальных случаев. Заказчик доволен.
Кстати, даже для нерешаемых задач есть способ решения. Например, вам поставлена задача написать программу, которая будет делить числа А и Б при любых А и Б. Вспоминаем, что на ноль делить нельзя. И вместо того, чтобы блистать своими знаниями решаем задачу для всех остальных случаев. Заказчик доволен.
Бывают задачи в принципе решаемые, но не решаемые с использованием конкретного стэка технологий и/или инструментов. Скажем, доступ к файловой системе из JavaScript-скрипта в браузере.
«Нарисовать 7 взаимоперпендикулярных красных линий, две из них зеленым цветом и одну — прозрачным» (-;
P.S.
> В отличии от других областей (математика, физика)
А что, есть что-то подобное в физике? В математике нередко есть возможность однозначно доказать отсутствие решений. В прикладных вещах такой возможности нет (хороший пример написали выше о доступе к файловой системе из JavaScript).
> В отличии от других областей (математика, физика)
А что, есть что-то подобное в физике? В математике нередко есть возможность однозначно доказать отсутствие решений. В прикладных вещах такой возможности нет (хороший пример написали выше о доступе к файловой системе из JavaScript).
Любой рисунок есть суть проекция пространства сколь угодно многомерного на двумерную плоскость. Поэтому мы, теоретически, можем изобразить проекцию семи-мерного пространства, в котором все линии будут перпендикулярны друг-другу. Что же касательно цвета… есть условные обозначения. Пусть "---" это красная линия, изображенная зеленым цветом, а "-+-+-+" красная линия, изображенная прозрачным цветом. Тогда рисунок вида "---+-+-+-----" будет набором черных символов на белом фоне изображающим красные линии зеленого и прозрачного цветов! :)
Пример с JS хорош, но опять же, начальство, которое предлагает методы (способы, инструменты) решения задачи либо достаточно хорошо в них разбирается, и тогда не будет просить получить доступ. Либо не разбирается вовсе, и тогда не будет ограничения в виде «только на js» :)
Я к тому, что необходимо всегда строить диалог. Искать хоть какие-то решения, а не отворачиваться к саперу со словами «это не возможно, не мешайте».
P.S. в физике считается невозможным превысить скорость света, или что-то вроде того. Не владею информацией =)
Пример с JS хорош, но опять же, начальство, которое предлагает методы (способы, инструменты) решения задачи либо достаточно хорошо в них разбирается, и тогда не будет просить получить доступ. Либо не разбирается вовсе, и тогда не будет ограничения в виде «только на js» :)
Я к тому, что необходимо всегда строить диалог. Искать хоть какие-то решения, а не отворачиваться к саперу со словами «это не возможно, не мешайте».
P.S. в физике считается невозможным превысить скорость света, или что-то вроде того. Не владею информацией =)
Обобщу в двух словах. Нужно думать не о самой проблеме (какая она сложная и тд), а о ее решении.
И про японцев. Разве ситуация с индусами не похожа (изначально по крайней мере)? Существует мнение что у индусов никогда нет проблем, всегда «да насяльника, все будет сделано в лучшем виде, никаких проблем», вместо того чтобы задать уточняющие вопросы или взять время на анализ задачи. В итоге результат будет заранее непредсказуем.
И про японцев. Разве ситуация с индусами не похожа (изначально по крайней мере)? Существует мнение что у индусов никогда нет проблем, всегда «да насяльника, все будет сделано в лучшем виде, никаких проблем», вместо того чтобы задать уточняющие вопросы или взять время на анализ задачи. В итоге результат будет заранее непредсказуем.
Возникает секундная пауза, а потом разработчик говорит, что это сделать невозможно. Я удивляюсь. Всё дело в том, что это программирование малость из совершенно другой области и разработчик специалист в этой области, а я — специалист в другой.
— Это нельзя сделать, потому, что это никогда и ни за что нельзя сделать!
— Да я не спрашиваю почему это нельзя сделать! Я спрашиваю: как это сделать?!
Внимание на экран:
за полтора дня я разобрался в совершенно другой области программирования, нашел способ как сделать штуку (в гугле готовых решений не существовало), написал код, оттестировал и поставил.
Без конкретики какая-то непонятная история. Нет конкретного описания задачи. Всё могло быть по другому, не так как описывает автор.
Знаю, так как я несколько раз попадал в ситуации, когда говорил «так никак сделать нельзя».
И это действительно сделать было никак нельзя. И это в будущем так никто и не сделал.
Вариант 1.
Менеджер-программист из «совершенно другой области» просит сделать задачу, которую сделать нельзя. После объяснений, что задачу нужно упростить, что-то выкинуть, выясняется что выкинуть ничего нельзя в общем-то,
т.к. фирме нужны деньги, юзерам нужно то-то и то-то и всё сразу.
При этом после недели препирательств я советую (т.к. это уже вообще-то не в первый раз происходит) менеджеру-программисту из «совершенно другой области» начать программировать в этой
области (реально заняться этим, начать изучать, понемногу писать код), иначе ничего у него не выйдет.
Если при этом менеджер-программист из «совершенно другой области» последовал бы моему совету, он бы выкинул половину требований, о остальное отложил на потом, с эстимейтом раз в 200 (!) больше чем вообще изначально кто-либо что-либо предполагал про эстимейт.
Может это и случилось у автора, просто он не заметил как упростил требования, и были проблемы коммуникации с разработчиком. «Не заметил как упростил требования» звучит немного неправдоподобно, но на самом деле
такое очень даже бывает, особенно если в истории участвовали несколько человек и есть проблема коммуникаций.
Вариант 2.
Менеджер-программист из «совершенно другой области» написал нечто, что как-будто бы работает, ну у некоторых людей телант писать код, чуть менее чем на половину состоящий из багов, но при этом они
как бы не бросаются в глаза, тестеры их не сразу замечают, юзеры не жалуются, а если жалуются баг мелкий и отправляется в самый низ топа (мелкий не потому что проблема не большая, она просто огромная,
просто она — edge case — затрагивает малый процент юзеров, которым «повезло», и которые теперь останутся один на один со своей бедой). Особенно всё описанное имеет место быть когда в софте уже полно багов,
и новые просто никто не замечает, ни программисты ни саппорт ни юзеры.
Вариант 3.
Менеджер-программист из «совершенно другой области» написал нечто, что потом будет тяжело поддерживать, или вообще нельзя будет поддерживать, прямо скажем костыль, просто с точки зрения
разработчика который в проекте, это вообще не код. Ведь его придётся выкинуть, или переписать весь остальной проект под него, к тому же как вообще этот код можно рассматривать как код,
когда по легенде он принесёт 100 рублей, а на поддержку (переписать половину всего проекта) в относительно ближайшее время уйдёт 10 тыс рублей? Может в ближайший месяц код создаст больше проблем чем эти 100 рублей.
При этом менеджер-программист из «совершенно другой области» постоянно вспоминает про это сто рублей, которые должен принести код (вернее это по его расчётам он должен их принести, как оно на самом деле
будет никто не узнает), но про будущее ничего знать не хочет.
Вариант 4:
Всего понемногу из каждого из вариантов выше.
Вообще если такие истории повторяются ни раз и не два, и программист оказывается каждый раз прав, то в итоге когда ему поставят ещё более нелепые требования, он начнёт общение по поводу этих
требований ни с чего либо а с фразы «так никак сделать нельзя»
p.s.
По моему опыту, совершенно не сказал бы что это "основная" особенность наших разработчиков (или наших менеджеров :) )
Варианты 1 и 2 по большому счёту совпадают. А вот если вариант 3, то программист был не прав — не его, на самом деле, дело, оценивать рентабельность и прочую целесообразность — оценить расходы на создание и поддержку его дело, а вот оценивать доходы и, тем более, говорить «невозможно» вместо «нерентабельно» (то есть принимать бизнес-решение по сути) — это уже превышение полномочий.
В «варианте 3» эмоционально описано что нерентабельность видна невооруженным глазом, без необходимости проводить расчы. Разработчик мог не располагать вообще цифрами (суммами денег), просто понимать что каждая следующая фича будет делаться в 10 раз дольше, или что нужно будет переписать половину всего проекта, он мог сообщить об этом менеджеру, вместе с фразой «так никак сделать нельзя», а мог и не сообщить, если разговор как-то не зашёл в это русло.
Варианты 1 и 2 по большому счёту совпадают
Вариант 1 про упрощение задачи, её смог упростить менеджер, только когда сам начал писать код (а до этого считал что все функции нужные)
Вариант 2 про то что менеджер написал код с a) багами, б) не обрабатывающий edge-cases. (б) Это нечто среднее между багом и упрощением задачи :)
Противоположность моему опыту и наблюдению. Как раз наоборот, русских разработчиков постоянно обвиняют в изобретении велосипедов, активное использования незадокументиованных функций и нестандартных решениях.
То ли автор попал на ограниченную выборку разработчиков с описанным в статье перекосом, поспешно сделав вывод о «всех русских разработчиках», то ли он так завуалировал свои слова, что они стали выражать уже совсем другую мысль.
То ли автор попал на ограниченную выборку разработчиков с описанным в статье перекосом, поспешно сделав вывод о «всех русских разработчиках», то ли он так завуалировал свои слова, что они стали выражать уже совсем другую мысль.
«Я не против революции, но я враг разгильдяйства, которое некоторые прикрывают именем свободы! Что за дурная появилась манера? Если я говорю, что палуба грязная и ее надо прибрать, вы устраиваете митинг. На тему: убирать или не убирать? Я ненавижу ваше словоблудие. Морду бы вам бить за такие вещи… „
© Моознунд, В.С. Пикуль
© Моознунд, В.С. Пикуль
«Это нельзя сделать, потому, что это никогда и ни за что нельзя сделать!» — по моему это состояние называется «козлить».
Вот тут подробнее. Там же рекомендации как поступать при таком поведении.
P.S. Прошу извинить за управленческий цинизм.
Вот тут подробнее. Там же рекомендации как поступать при таком поведении.
P.S. Прошу извинить за управленческий цинизм.
Да-да, ой как знакомо и тоже закончилось увольнением сотрудника, к счастью по собственному. Перед этим боролся с ним месяца 3.
Замечательно расписано!
Замечательно расписано!
Если это «эта статья — самое важное, что я в жизни сделал», то у меня для тебя плохие новости.
Спасибо за ссылку в конце статьи с собранной страничкой, последнее время подозрительно часто слышу фразы 2 и 3 в нашей команде. Сие печально.
По моему многолетнему опыту работы в и с капиталистами.
Американцы и канадцы также выёживаются как описано выше со ссылкой якобы на русских или белорусов.
Думаю дело в зажратости, расслабленности и конечно принцыпе Питера. Здесь они также тупят и брыкаются изо всех сил при постановке элементарной задачи. Пытаются пустить все силы на доказательство того что её делать не надо, невозможно и если уж позарез надо то это надо делать в другом модуле, за который отвечает другой человек или отдел, ну или на худой конец уж не как не на перле а конечно на питоне чтобы потом при переходи на новые версии иметь головную боль и прочий нечеловеческий интим.
Думаю проблема не в менталитете конкретных национальностей а в заболоченности человека (превращение в халявщика — потребителя) как специалиста, отдела или компании в целом. habrahabr.ru/post/162517
И как правильно в своей ссылке заметил автор этой болезни все национальности(не будем трогать японцев), отрасли, политические строи покорны.
По моим наблюдениям японцы habrahabr.ru/post/177893/ конечно безропотно долбятся в закрытое окно пока не продолбятся или не упадут, но не замечают открытой форточки, потому что -ни шагу назад. Американцы трудоголики исторически и тоже неплохо и часто неэффективно долбятся. Европейцы более расслабленные не говоря уже о многих странах где то маньяна то сиеста.
Но главное что халявщиков везде полно и они проявляются в любом человеке при определённых внешних и внутренних условиях. Ещё обладатели совкового менталитета движимые как-то мифическим (взрошенным советской пропагандой) зачастую завышенным эго, часто подсознательно руководствуются принципом, «Служить бы рад, прислуживаться тошно ». Это очень характерно контрастно заметно в сфере обслуживания и особенно ресторанов на западе и в России. Поэтому если он сам придумал что эту абстрактную задачу надо решать именно таким способом он всё сделает отлично и быстро. А если придёт к нему какой то корнеплод с горы и скажет: «делай так и так, потому что я знаю как лучше» получается то что мы наблюдаем.
Американцы и канадцы также выёживаются как описано выше со ссылкой якобы на русских или белорусов.
Думаю дело в зажратости, расслабленности и конечно принцыпе Питера. Здесь они также тупят и брыкаются изо всех сил при постановке элементарной задачи. Пытаются пустить все силы на доказательство того что её делать не надо, невозможно и если уж позарез надо то это надо делать в другом модуле, за который отвечает другой человек или отдел, ну или на худой конец уж не как не на перле а конечно на питоне чтобы потом при переходи на новые версии иметь головную боль и прочий нечеловеческий интим.
Думаю проблема не в менталитете конкретных национальностей а в заболоченности человека (превращение в халявщика — потребителя) как специалиста, отдела или компании в целом. habrahabr.ru/post/162517
И как правильно в своей ссылке заметил автор этой болезни все национальности(не будем трогать японцев), отрасли, политические строи покорны.
По моим наблюдениям японцы habrahabr.ru/post/177893/ конечно безропотно долбятся в закрытое окно пока не продолбятся или не упадут, но не замечают открытой форточки, потому что -ни шагу назад. Американцы трудоголики исторически и тоже неплохо и часто неэффективно долбятся. Европейцы более расслабленные не говоря уже о многих странах где то маньяна то сиеста.
Но главное что халявщиков везде полно и они проявляются в любом человеке при определённых внешних и внутренних условиях. Ещё обладатели совкового менталитета движимые как-то мифическим (взрошенным советской пропагандой) зачастую завышенным эго, часто подсознательно руководствуются принципом, «Служить бы рад, прислуживаться тошно ». Это очень характерно контрастно заметно в сфере обслуживания и особенно ресторанов на западе и в России. Поэтому если он сам придумал что эту абстрактную задачу надо решать именно таким способом он всё сделает отлично и быстро. А если придёт к нему какой то корнеплод с горы и скажет: «делай так и так, потому что я знаю как лучше» получается то что мы наблюдаем.
Основная особенность наших разработчиков