Комментарии 153
Да тут и думать нечего, херачим по полной. Никакой оптимизации, повторного использования кода, абстракций и прочей ереси.
Это ведь саботаж, разве я неправ?
В нормальной ситуации программист идет к директору вместе с эйчаром и говорит, почему такая система мотивации тупая. А не начинает саботировать.
говорит, почему такая система мотивации тупая.
Я говорил с новой ХаРэ, ей пофиг, выслужиться хочет.
Все зависит от оплаты. Если опытному программисту за малое кол-во строк кода начнут платить как новичку (ну ведь мало же строк), то это уже кидалово со стороны руководства
Ну а что до разговора программистов и руководства — да, очевидно нужно говорить, но тут в том и смысл что руководство не хотело вникать в особенности работы, оно хотело получить готовое решение
А насчет «пусть подходит и говорит почему система тупая» — да, конечно, отлично, потом пусть ещё к бухгалтерам зайдет и объяснит как правильно деньги считать, потом уборщице расскажет как правильно пол мыть, потом ещё охране устроит ликбез по самообороне. А то они ведь все глупенькие и неразумненькие, им объяснять надо как им их работу делать.
Есть какие-то профессиональные рамки, как у автослесаря, так и у программиста. За них нельзя заходить.
А у дурака-директора в это примере есть?
Если у него цель была развести работников как лохов и платить им меньше повесив на них чувство вины, то он — сам себе злобный Буратино.
Во-вторых, мы все отвечаем за собственные поступки, и не отвечаем за поступки других. Если чувак в соседнем отделе, например, ворует из общего холодильника продукты, это не оправдывает вас, если вы тоже будете их воровать, верно? Так почему профессиональная некомпетентность кого-то из руководителей должна оправдывать саботаж кого-то из подчинённых?
Так почему профессиональная некомпетентность кого-то из руководителей должна оправдывать саботаж кого-то из подчинённых?
Потому что в данной истории эта некомпетентность напрямую отражается на их зарплате. Попытка объяснить закончилась результатом "ей пофиг". Они по-вашему должны были согласиться за ту же работу получать зарплату меньше?
Тут в комментарии habr.com/post/401355/#comment_18709019 уже разъяснили — разговаривать в такой ситуации с директором это напрашиваться на увольнение с «волчьим билетом».
разговаривать в такой ситуации с директором это напрашиваться на увольнение с «волчьим билетом».
Почему? Если, конечно, начинать про творческую работу вещать, то директор пошлёт лесом (без всяких увольнений, конечно же). Но если просто взять и объяснить, почему мотивация по строчкам кода — глупость, практически любой директор выслушает и попросит предложить что-то адекватное.
У вас в воображении директора какие-то монстры, причем недалекого склада ума. А это не так. Они во-первых обычные люди, во-вторых, по профессии управленцы. А это значит, что выслушивать, давать оценку предложениям и принимать решение — это их обычная работа.
Попробуем тогда сменить контекст. Представим директора, который вырос из программистов и сохранил живость ума и интерес к этому. Его правая рука — программист, творящий гениальные вещи в бизнес-моделях, левая рука — программист, который собаку сьел на нейронных сетях и системах непрямой логики. И вся верхушка такая же. Эта компания решает организовать отдел продаж, для чего нанимают специалистов-продажников во главе с неплохим начальником. И естественно пытаются покрыть их работу системами автоматизации.
Через какое то время это руководство обнаруживает, что продажники заняты обычным для них делом — вместе с поиском покупателей/продавцов нужных вещей обстряпывают собственные делишки, умело задерживают договора в стадии подвиса, чтобы договор не ушел без «интереса» — отката в пользу продажника, растягивают или концетрируют платежи, чтобы получить максимальную премию за договор, и так далее.
Директор-программист понимает это и организовывает контрмеры — блокировку левых аккаунтов, предупреждение контрагентов по факту о прекращении откатов, и так далее. Без увольнений. только контроль и профилактика.
И вот к директору придет начальник продажников и начнет рассказывать, просто брать и объяснять, почему мотивация по чистоте сделок и минимуму откатов — глупость, что людям нужно дать проявить творчество в работе, что воровать естественно и непостыдно… Его не поймут. Директор-программист не поймет вора, точно так же как директор-вор не поймет программиста, разные вообще представления о процессе и доверии.
Программист не может доверять вору — он не может уложить в уме что воровать это нормально, а вор не может доверять программисту — у него в уме не может уложиться что человек может преследовать не личные, а общие интересы.
И там и там нет монстров. Там просто разные уклады ума, и если человек вырос из IT-он сам все поймет что надо, если же он как обычно закончил Высшую школу менеджемента — он поймет только что ему втирают какую то дичь, которую вот щас директор по персоналу объяснит четко и внятно, что это за фигня и подстава.
по такой схеме их зарплата наоборот, увеличилась в два раза
Ну так им же поставили цель — вы должны работать хорошо, а для этого от вас нужно больше кода.
Уменьшение зарплаты это логичное следствие написания переиспользуемого кода. В этом месяце написали 1000 строк новых функций, в следующем вызываем с нужными параметрами одной строкой из сотни мест. Разница в 10 раз.
а с директором они вообще не разговаривали
"Вот этими сказками я уже сыт по горло"
"Инженеры-конструкторы тоже постоянно на творчество ссылаются"
"Действуйте!"
Судя по этим фразам, ему об этом говорили, в том числе и директор Татьяна Владимировна. И ему это не понравилось.
Он предоставил полномочия новой HR, поэтому программисты разговаривали с ней. Вполне могло быть и так, что когда программисты к нему пришли, он сам отправил их с фразой "Этим вопросом занимается специалист, разговаривайте с ней".
причем с катастрофическим снижением качества продукта.
О каком снижении качества вы говорите? Что так кардинально изменится, если добавить папку "vendor" в репозиторий?
Копи-паста тоже не снижает качество продукта в момент копирования, он работает как работал, она просто увеличивает сложность поддержки. Снижается качество кода, как текстовой модели предметной области. Но с учетом количества кода в зависимостях ее даже применять необязательно.
О каком снижении качества вы говорите?
Там черным по белому написано:
Да тут и думать нечего, херачим по полной. Никакой оптимизации, повторного использования кода, абстракций и прочей ереси.
«Вот этими сказками я уже сыт по горло»
«Инженеры-конструкторы тоже постоянно на творчество ссылаются»
Ну а что тут не так? Это же не гейм-дизайнеры были. Творческая составляющая в работе программиста бизнес-приложений — это где-то 3-5% его работы. В основном как кнопочки расставить, и какой цвет меню выбрать. Что творческого в том, чтобы сделать таблицу БД по заданному списку полей, сделать под неё модель, форму и настроить биндинги/валидацию/авторизацию?
Чем-чем, а творчеством тут можно смело пренебречь.
Там черным по белому написано
Ну так это решение они приняли после разговора. Повторное использование кода это прямое снижение зарплаты. Они это сделали не "из-за некомпетентности кого-то из руководителей" и не потому что они из вредности хотят систему обмануть, а чтобы не терять в зарплате, о которой они договаривались при устройстве.
Творческая составляющая в работе программиста бизнес-приложений — это где-то 3-5% его работы.
"Творческий" здесь антоним формального и абсолютного. Это не совсем правильный термин, но для противопоставления этого достаточно. Три строки кода это много или мало? Когда-то много, когда-то мало, зависит от контекста. Под творчеством понимается способность человека анализировать ситуацию и давать оценку — много/мало, правильно/неправильно.
В этом проблема всех формальных метрик. Потому что они не формальные, а контекстно-зависимые. Это будет работать если контекст всегда и у всех одинаковый.
Поэтому нельзя сделать программу, которая по метрикам будет правильно анализировать работу программистов (и других аналогичных профессий). Замкнутый круг — для анализа метрик надо анализировать контекст, а как его анализировать, другие метрики вводить? Выход только в создании ИИ, аналогичного по возможностям ЕИ, который сможет структурировать и анализировать произвольную информацию.
Ну так это решение они приняли после разговора.
Ну и тем не менее, это профессиональная подлость. И это никакими снижениями зарплаты нельзя оправдать. Тем более что в статье написано, что они зарплату этим удвоили, а не просто сохранили. Не нравится работа — меняй, а не вреди.
«Творческий» здесь антоним формального и абсолютного.
Очень сложно найти работу, в которой всё формально и абсолютно. По сути, это лишь повременная работа вроде сторожа. Все остальные такие же, пусть будет творческие.
Вот, например, работа сантехника творческая? Как правило, все считают, что нет. Даже сантехники. Но я вот недавно менял радиатор отопления, сантехники сначала мне предложили интерфейс, вот тут разместить вентили, чтобы было удобно перекрывать, а вот тут сделать байпас. Потом во время работы у них одна гайка разломилась, кусок остался в радиаторе, пришлось по ходу дела костыль разрабатывать — надпилить её изнутри, вставить туда зубило и газовым ключом его провернуть. И знаете что? Всё эти решения ничем принципиально не отличаются от тех, которые в своей работе принимает программист. И нормируется работа сантехника ничуть не точнее, чем работа программиста. Вы просто исходя из опыта оцениваете, сколько времени и других ресурсов потребуется на реализацию поставленной задачи (решение которой вам изначально вполне понятно, если только вы не работаете над каким-то редким наукоёмким проектом), накидываете проценты на риски, и считаете её стоимость.
Можно затратить целую неделю чтобы найти баг (ошибку), а затем написать меньше одной строчки кода для исправления этого бага, как итог недельных трудов!
А оценивать зарплату по количеству строк кода не подлость?!
Нет, не подлость. Это некомпетентность того, кто придумал систему мотивации. Но даже если бы и подлость, то что? Васе навредило руководство, Вася навредил своим пользователям. Это означает справедливость? Нет, это означает, что Вася — такое же говно, как и его босс.
Васе навредило руководство — нет же, зарплата у Васи сохранилась.
Вася навредил своим пользователям — тоже нет, пользователи получили свой товар.
А если есть подозрения, что товар у Васи получается не того качества — так можно же придумать метрики для измерения качества… Oh, shee…
А если есть подозрения, что товар у Васи получается не того качества
Качество товара — это такое же обязательство, как и сама поставка товара.
Факт поставки (непоставки) товара легко проверяется. Согласно акту выполненных работ Вася написал программу. Программа ТЗ соответствует.
А вот есть ли связь между качеством Васиной программы и попытками Васи накрутить себе счетчик… Разве что вместо разработки лайфхаков Вася мог бы делать что-то полезное и получать за это деньги… Но ведь ему платят не за полезную деятельность, а за ее имитацию.
Факт поставки (непоставки) товара легко проверяется
Ну вот поставили вам китайские игрушки, по накладной товар поставлен. А у них краска слезает через месяц, или съедается ребенком.
Приняли вы программу, которая соответствует ТЗ, подписали акты. А в процессе эксплуатации выяснилось, что через через час работы на реальных данных валится с out of memory, надо перезапускать, а через месяц после накопления данных формы стали по пять минут открываться.
Какой из этих (самых обычных, и часто встречающихся, между прочим) вариантов легко проверяется на этапе приемки?
через через час работы на реальных данных валится с out of memory
через месяц после накопления данных формы стали по пять минут открываться
Заказчик не слышал про тестирование. Жаль.
Но какая, чорт возьми, связь утечек памяти в программе и стиля написания программы?
Заказчик не слышал про тестирование. Жаль.
Допустим, слышал. Но я вот, например, ничего не слышал про существование в природе методик тестирования, которые позволяют за приемлемые затраты получить гарантированный результат качества. Минимизация проблем обеспечивается в первую очередь культурой разработки, а не тестированием.
Но какая, чорт возьми, связь утечек памяти в программе и стиля написания программы?
Хм. Ну даже и не знаю, как вам объяснить. Какая связь между ездой с нарушениями правил и аварийностью? Вот примерно такая же.
Какая связь между ездой с нарушениями правил и аварийностью? Вот примерно такая же.
То есть связь проследить сложно.
Езда без водительского удостоверения — это нарушение правил, да. И с непристегнутым ремнем, да. И без страховки, да. Означает ли это, что если удостоверение оставил дома, это как-то повлияет на аварийность?
В некоторых странах недопусимо употреблять алкоголь за рулем совсем. В некоторых — допускается некоторый уровень алкоголя, до 1-2 бутылок пива. И аварийность у них почему-то не выше.
Связь между копипастой кода (и другими способами просто увеличить количество строк) и утечками памяти такая же.
Минимизация проблем обеспечивается в первую очередь культурой разработки, а не тестированием.
Возражений не имею ;)
Если где-то платят за культуру разработки и умеют уровень этой самой культуры адекватно измерять… Рад за них ;) У придуманных героев рассказа другие ценности.
Ну и тем не менее, это профессиональная подлость.
В чем именно вы видите подлость? Не общими словами, а конкретно на примерах — до изменений было то-то, после изменений стало то-то. Я вот не вижу ничего, что можно описать этим словом. Для пользователей ничего не изменилось, для программистов изменилось то, что они сами захотели.
Тем более что в статье написано, что они зарплату этим удвоили, а не просто сохранили.
Ну так от них же требовали работать лучше. Да еще и каждый месяц нормы удваивали.
Не нравится работа — меняй, а не вреди.
Убегать из-за каждой неприятности? Ее может уволят через 3 месяца, зачем из-за этого работу бросать.
И да, никто никому не вредил. Продукт продолжал выполнять свои функции. Ну отложили рефакторинг на неопределенное время. Думаете в других местах плохого кода не бывает?
Вот, например, работа сантехника творческая?
У сантехника критерии соответствия результата задаче более простые, и видов задач гораздо меньше. Написано "установить одну батарею", значит в результате нужна одна работающая батарея, входы-выходы стандартизированы, требуемые детали стандартизированы.
Вот если бы программистам ставили задачи "установить библитеку jQuery", и они бы их пачками устанавливали в разные приложения, тогда да, творчества (анализа) тут мало.
А если бы некие сантехники придумывали способы, как подвести воду к нестандартному объекту в нестандартной местности, то это были бы уже инженеры, и работа такая более творческая.
Так что не сравнивайте так, пожалуйста. Программист — это едва ли не единственная профессия, где нормой считается делать кое-как, лишь бы работало.
Разница в том, что спрос на услуги сантехников ниже, чем на услуги программистов. Поэтому сантехники вынуждены конкурировать друг с другом, и скоростью, и качеством. А программистам это не обязательно.
Не общими словами, а конкретно на примерах
Конкретно на примерах, обсуждая изначально выдуманный кейс, это сложно :). Но фраза «никакой оптимизации, повторного использования кода» и т.д. на практике практически всегда приводит к тому, что продукт начинает работать плохо, баги кочуют из одного участка программы в другой (код-то дублируется, а не вызывается из общей библиотеки/класса/сервиса) и т.д. Уж кто-то, а мы все прекрасно знаем, как подобный подход ухудшает качество работы пользователей. Другое дело, что многие программисты занимают позицию «задачу выполняет? Ну и достаточно, чего вы ноете, что тормозит/глючит? Подождите, перезапустите, и работайте дальше». При этом, конечно, недовольны, если то же самое вытворяет, например, Eclipse, или, чур меня тьфу-тьфу-тьфу, Atom.
Убегать из-за каждой неприятности? Ее может уволят через 3 месяца, зачем из-за этого работу бросать.
Ну проблема же не в эйчаре. Ведь вроде как речь о том, что начальство не слушает программистов. Это системное.
У сантехника критерии соответствия результата задаче более простые, и видов задач гораздо меньше.
Вы знаете, об этом можно спорить бесконечно. Да, наверное, в какой-то мере проще. Но принципиально никаких отличий нет. Вы можете установить одну батарею, вроде как всё просто, но вы должны ещё предложить варианты этих батарей пользователю, определить её мощность, учитывая целесообразность, допустимые размеры и кошелек пользователя. Делать ли за батареей отражатель? А какие крепления под батарею, и сколько их? Даже в такой простой задаче есть масса вариантов.
А позовите этого же сантехника класть вам тёплый пол, например, там уже и нехитрая инженерия добавляется, ведь нужно рассчитывать плотность укладки и температуру теплоносителя, исходя из площади помещения, характеристик стен, остекления и т.д.
Написано «установить одну батарею», значит в результате нужна одна работающая батарея, входы-выходы стандартизированы, требуемые детали стандартизированы.
Ну так и у программиста бизнес-приложений в общем случае то же самое. В чём может проявляться творчество в работе «сделать печатную форму» или там «добавить вот такой-то документ с таким-то бизнес-процессом прохождения»? Как расставить поля на форме или как назвать поле в базе данных? Это примерно то же самое, что и «вам вентиль тут повесить, или на 10 см в сторону». У программиста же там нет пространства для придумывания чего-либо, вся эта работа делается также по типовому шаблону.
за батарею, которая плохо греет из-за завоздушивания, а криво повешенную вообще заставят бесплатно заново перевешивать
Ну вот только не надо говорить, что вы никогда не слышали про халтурную работу сантехников) За программу, которая неправильно считает цену из-за багов тоже платить не будут.
где нормой считается делать кое-как, лишь бы работало.
Потому что если оно работает, то оно так и будет работать. Программы не ржавеют и не портятся, если их не менять. А батареи не перевешивают каждый раз, в отличие от программ.
Это я не к тому, что это правильно, а почему требования разные.
"Вынужденно добавили в программу лишних строк" не эквивалентно "это считается нормой", и это не норма.
Другое дело, что многие программисты занимают позицию «задачу выполняет? Ну и достаточно, чего вы ноете, что тормозит/глючит? Подождите, перезапустите, и работайте дальше»
Ни разу не слышал, чтобы кто-то так говорил в отношении своего проекта. В крайнем случае между собой решат, что это не приоритетный баг.
Ведь вроде как речь о том, что начальство не слушает программистов.
Речь о том, почему они начали писать длинный код. Я считаю, что у них были обоснованные причины.
ведь нужно рассчитывать плотность укладки и температуру теплоносителя
Ну так и задачи такие оцениваются индивидуально, исходя из контекста, а не из количества закрученных болтов.
В чём может проявляться творчество в работе «сделать печатную форму» или там «добавить вот такой-то документ с таким-то бизнес-процессом прохождения»?
Вот если бы печатные формы продавались готовые, то сравнение было бы уместно. А ее надо придумать, бизнес-логику процесса написать, да потом еще и изменения вносить. Часто ли сантехники новые конструкции батарей изобретают?
И как я сказал, под творчеством имеется в виду анализ контекста. Выбор между кучей возможных способов сделать одно и то же. Любые ли 1000 строк для генерации формы должны оцениваться одинаково? А 900 это лучше или хуже?
Ну так и задачи такие оцениваются индивидуально, исходя из контекста, а не из количества закрученных болтов.
Ну мы же не спорим, что измерение работы программиста по строкам — идиотизм. Это и так понятно. Контекст нашего спора был в том, является ли нормой, что программист включается в этот идиотизм и всячески его поддерживает в своих интересах в ущерб качеству работы.
А ее надо придумать
Да не надо там ничего придумывать. Форма, минуточку, это пачка из списка полей и CRUD-операции над ней. Всё придумывание — это дать им название и расставить по порядку. Это сугубо механическая работа. Точно так же механически цепляются правила валидации.
Выбор между кучей возможных способов сделать одно и то же.
Давайте честно, эта дилемма стоит перед программистом один раз. Тогда, когда он учится использовать платформу. Если вы не учитесь, а работаете, у вас есть тот способ, который вы выбрали — например, вы с базой можете работать или через какой-то набор адаптеров SQL, или через ваш любимый ORM. И вы ваш любимый метод будете использовать всегда, а не плодить в своём коде зоопарк из разных подходов. Если вы дописываете существующее приложение, у вас вообще количество вариантов ограничено одним, не зависящим от ваших предпочтений. Тем, который выбрала в своё время команда разработки или архитектор.
всячески его поддерживает в своих интересах в ущерб качеству работы
Ну то есть, по-вашему они должны были продолжать писать переиспользуемый код ради высших целей и получить во второй месяц 1/10 зарплаты? Ведь как мы выяснили, договориться об отмене у них не получилось.
Я бы вот не согласился на уменьшение зарплаты, а попытался бы показать на примере несостоятельность метода, раз словами объяснить не получилось. Можно считать это уважением к другим программистам, ведь если просто уволиться, наймут новых работников и продолжат применять эту систему.
Всё придумывание — это дать им название и расставить по порядку.
Ну вы же про творчество говорили. Там нет творчества, которое у художника. Там есть неформализуемая оценка, которую за неимением лучшего слова называют творческой составляющей.
Давайте честно, эта дилемма стоит перед программистом один раз.
Она стоит перед ним каждый раз, когда он придумывает имя переменной. Можно ведь однобуквенными переменными нафигачить, на методы не разбивать, значения хардкодить. Я это имел в виду, а не архитектуру приложения.
Ну то есть, по-вашему они должны были продолжать писать переиспользуемый код ради высших целей и получить во второй месяц 1/10 зарплаты?
По-моему, их начальник должен был пойти и сказать, что это полная хрень, и объяснить, почему. Без слов «творчество» и «невозможно оценить» (потому что да, все руководители за этими словами в устах инженера ничего кроме «я так и не научился оценивать собственный труд» не видят). А со словами «смотрите, эту задачу можно сделать быстро вот так и долго вот так, и в этом случае получится в два раза больше кода. Вы действительно хотите замотивировать программистов делать больше?» И директор ему бы гарантированно сказал: «Упс, да, это не сработает. Какие тогда есть предложения?»
Она стоит перед ним каждый раз, когда он придумывает имя переменной.
Я не согласен. Вы-то всё это сделать можете, но ведь никогда не будете. Сантехник тоже имеет возможность выпендриться, и пустить холодную воду петлёй через кладовку. Но он так делать не будет. Также и программист не будет упражняться в придумывании нестандартных схем, а сделает так, как это принято по гайдлайну (или при его отсутствии — по best practices) разработки на его платформе. Переменные все именуются механически. Переменные-индексы i,j,k. Переменная для хранения суммы — Amount. Поле для хранения суммы в классе С++ — m_amount :)
Переменная для хранения веса — Weight, переменная для хранения средней зарплаты — AverageSalary, и так далее. Нет там ничего неформализуемого.
По-моему, их начальник должен был пойти и сказать
Так ходили же. Про "творчество" до этого было, от других людей. Они ходили к HR, и ей пофиг.
А со словами «смотрите, эту задачу можно сделать быстро вот так и долго вот так»
И директор ему бы гарантированно сказал: «Упс, да, это не сработает. Какие тогда есть предложения?»
"А откуда я знаю, я же в этом не разбираюсь. Вам лишь бы не работать."
Если бы директор хотел узнать предложения программистов, он бы сразу их спросил.
Также и программист не будет упражняться в придумывании нестандартных схем
Причем здесь нестандартные схемы. Я говорю про варианты стандартных схем. Вы же не будете утверждать, что по описаниию бизнес-задачи можно определить единственный вариант исходного кода, который ее решает?
Даже с формой не все так просто, понадобился там сложный datepicker с диапазоном — какую библиотеку выбрать, использовать библиотечный вызов с длиннющим конфигом или в обертку вынести, сложный валидатор отдельным классом сделать или заинлайнить так как он больше нигде понадобится...
Нет там ничего неформализуемого.
Ну и как вы формально проверите, что в этом месте обосновано имя переменной n, а в другом нет?
Как определить, что вот этот кусок кода лучше в метод вынести?
Если бы можно было это автоматизировать, давно бы сделали. Но пока требуется участие человека.
Вы же не будете утверждать, что по описаниию бизнес-задачи можно определить единственный вариант исходного кода, который ее решает?
Не буду, но буду утверждать, что из равнозначных вариантов, подходящих для решения, есть всегда какой-то один, который программист выберет без колебаний, и сколь-нибудь существенное время на выбор варианта реализации он тратить не будет. Разве у вас сходу нет готового ответа на все эти вопросы…
понадобился там сложный datepicker с диапазоном — какую библиотеку выбрать, использовать библиотечный вызов с длиннющим конфигом или в обертку вынести, сложный валидатор отдельным классом сделать или заинлайнить
..., если вы это делаете не в первый раз в жизни? Вы сделаете это точно так же, как делали в предыдущем проекте.
Ну и как вы формально проверите, что в этом месте обосновано имя переменной n, а в другом нет?
А, да без проблем:
bool CheckIsNameValid(string Name) {return true;}
Причём я не шучу. Если программист следует общему гайдлайну, там нечего проверять. Любое выбранное им имя окажется уместно, а нюансы рефакторинга «вынести это в метод», как правило, несущественны.
Если программист следует общему гайдлайну
А как вы это проверите? Речь ведь о возможности формальной оценки качества работы, с результатом "Вася пишет код лучше, Петя хуже, Васе платим больше, Пете меньше".
а нюансы рефакторинга «вынести это в метод», как правило, несущественны.
Ага, то есть копи-паста теперь вас устраивает? А как же профессиональная подлость и все такое?) Про оптимизацию опять же, Вася сделал два последовательных цикла, но читабельно и независимо, Петя один, но фиг разберешься. Такое тоже программой не проверишь.
Я согласен, если программист только клепает формы и ничего больше, пользуясь готовым кодом, то за них можно формализовано платить по количеству форм и полей в них. Но мне сложно представить вакансию с такими требованиями, обычно наоборот, и швец и жнец.
А как вы это проверите?
Для этого у него есть начальник/тимлид, у которого есть и необходимая квалификация, и необходимая ответственность, собеседовать людей перед наймом в команду, чтобы убедиться, что они подходят. И проводить review проекта в процессе разработки.
Ага, то есть копи-паста теперь вас устраивает? А как же профессиональная подлость и все такое?
Не передёргивайте. Я пишу про доверие «по умолчанию» качеству кода квалифицированного программиста, а не про то, что писать говнокод — это нормально. Если вы взяли к себе в команду программиста, которому вы не доверяете, ну кто же вам виноват? Тогда придумывайте, как его контролировать :)
Но мне сложно представить вакансию с такими требованиями, обычно наоборот, и швец и жнец.
Ну и зря. В разработке бизнес-приложений все тотально занимаются тем, что клепают формы, репорты, бизнес-процессы и синхронизацию/интеграцию. А это едва ли не 90% рынка ПО.
Ну то есть человек. Я о том и говорил.
> клепают формы, репорты, бизнес-процессы
Ну так в этом и сложность. Нет заранее готовых бизнес-процессов, которые можно купить и подключить, как батарею.
Нет заранее готовых бизнес-процессов, которые можно купить и подключить, как батарею
А, понял, почему вы не понимаете :) У вас просто неправильная аналогия. Вы сравниваете бизнес-процесс с уже готовым изделием, которое можно купить и юзать. А бизнес-процесс — это не готовое изделие, это… труба. Труба для данных. Сантехник вам тоже нигде не сможет купить готовую трубу. У него есть несколько сотен разных фитингов, переходников, уголков, разветвителей, и заготовок для труб (разных производителей, разных диаметров, с разными характеристиками, армированием и т.д.) которыми он может свой flow направить туда, куда заказал пользователь. Вот это всё он компилирует в готовый продукт.
Идите работать, нечего тут дискутировать! У нас есть специалист по мотивации, он разберется с вашими задачами. У вас есть профильное образование по психологии? Что? Есть? Не слышу? Ах нет? Ну так идите отсюда и не лезьте со своими идеями.
Тоже мне, умники нашлись!
У меня специалист по персоналу есть, пусть он и занимается этим делом.
А надо было сразу увольнять тех программистовИ писать код самому
И в серьёзных обучающих программах ещё рассказывают про то что замотивировать разными плюшками по сути невозможно, можно создать условия в зависимости от возможностей компании и наблюдая попытаться заинтересовать людей в работе немного меняя их роли и давая обратную связь (а также возможно убирать тех кто совсем не вписывается) :)
Очевидно, определение целей компании далеко выходит за рамки компетентности программиста.
Ну так же не бывает в реальной жизни. Вы пишете продукт, вы знаете, что это за продукт, кто его использует, для чего использует. Вы всегда знаете, чем занимается ваша компания, что она продает, производит, какие услуги оказывает. И вдруг вам говорят: «Теперь меряем вашу работу по строчкам кода». Вам для однозначного понимания того, что вам спустили неверную систему мотивации, не нужно быть в курсе каких-то хитрых стратегических планов правления компании. Достаточно лишь той информации, которая вам доступна как обычному разработчику.
Почему когда директор просит с программистов свое — это нормально, и саботаж этого признается чуть ли не преступлением, мол как они могут вертеть на фигу такую хорошую систему? А когда программисты просят свое — это прям ах и ох, как вы можете, и верчение директором их просьб считается нормальным? Хотя ему как директору проще повысить программисту зарплату в Х раз, чем программисту выполнить работы в Х раз больше.
И пока директора будут саботировать просьбы персонала — персонал считает своим правом саботировать просьбы директора. «Они делают вид что платят, мы делаем вид что работаем» (с)
И пока директора будут саботировать просьбы персонала — персонал считает своим правом саботировать просьбы директора.
Можно и так, кто же спорит. Но речь шла не про саботаж просьб директора, а про саботаж своей работы, сознательную порчу продукта, который они выпускают. И в этом случае, повторюсь, самым правильным и умным решением проблемы будет увольнение таких сотрудников, и найм новых, как только этот факт всплывёт на поверхность. Не нужны они такие в профессии.
саботаж своей работы, сознательную порчу продуктаА саботаж ли это?
Директор ясно дал понять, что продукт будет тем лучше, чем больше в нем строчек кода (иначе почему бы он стал именно за них платить?) А директору уж явно виднее, что лучше для продукта, чем рядовому программисту.
И Вы хотите чтобы даже самый развитый программист, доросший до средних должностей начальника отдела, вышел на борьбу с ними аки рыцарь в белых доспехах, прыгнул через их головы и доказал директору, что их работа не помогает, а вредит производству и прибыли?
Прыгали. На моих глазах прыгали. И расшибались напрочь, ибо они пытаются противостоять людям, облеченным властью, и в конфликте двух человек, один из которых поет дифирамбы и облечен за это властью, а другой приходит и каркает, что все плохо — выигрывает первый.
От компании зависит, бывает и так что то что считает важным условный руководитель группы/отдела на самом деле компании не нужно, а выясняется это иногда "случайно".
Помнится было замечательное французское кино про такой отдел, названия только не помню.
– Понятно. Короче, теперь у нас грейды.Можно подумать, «грейдер» от какого-то другого слова:
– Грейдер?
– Блин, колхоз восьмое марта. Грейды, от английского “grade”, видимо.
Гре́йдер (англ. grader, от англ. grade — нивелировать, выравнивать) — прицепная или самоходная машина для планировки и профилирования— как раз для разработки планов и профилей для программистов.
По моему единственный способ заинтересовать не только разработчиков а вообще весь персонал — дать опцион, хотя-бы самым ключевым сотрудникам.
Если пропорционально росту компании будет увеличиваться и прибыль сотрудников — все будут действительно работать на результат, метрики конечно тоже нужно собирать для понимания того что твориться в компании.
На счет мотивации — вполне неплохо работает мотивация без денег, да премии и повышения хороший инструмент чтобы продвинуть важные проекты, но если мотивацию привязывать только к деньгам — то один фиг найдутся желающие сломать эту систему.
Плюс не надо путать мотивацию и закручивание гаек — по сути директор желает получить больше прибыли за счет сокращения зарплат сотрудников, что и привело к противоположным результатам. Скупой платит дважды.
Если пропорционально росту компании будет увеличиваться и прибыль сотрудников — все будут действительно работать на результат...
А если дела компании пойдут не очень хорошо, такая положительная обратная связь не выйдет ли боком?
Кроме того, всё остальное можно купить за эти деньги.
Сужу по себе — ушел с унылой, хоть и высокооплачиваемой работы на более интересную но менее прибыльную, и не жалею. На старом месте почти каждое утро просыпался с ненавистью к окружающему миру. Хорошие деньги эту ненависть могли чуть приглушить только 1-2 дня после зарплаты. Оно того не стоило.
Знаете, я вот программист, уже лет 15 программист. И я считаю что задачи и проблемы надо решать эффективно. Эффективность может измеряться по разным параметрам в зависимости от ситуации и целей.
И вот в связи с этим у меня вопрос: Вот у хитрых программистов проблема, в очередной раз навязали метрику. Они понимают что причина проблемы вероятнее всего в недостаточном понимании директором процесса разработки да и вообще слабого понимания зачем им нужен IT отдел ну и желания как то формализировать финансы по нему, то ли мотивировать то ли сэкономить. Вроде первичное и самое эффективное решение очевидно, нужно Коляну или другому самому «хитрому» вытянуть директора и очередного hr-a/консультанта в переговорку и все обсудить. Выяснить и подтвердить корни проблем в взаимодействии и решить как их пофиксить и как проверять. Ну как баг зафиксить или задачу сделать. Даже если не получиться — риск минимален а займет пару часов от силы. Вместо этого мудрим с привлечением пользователей, сами себе ухудшаем код, гамбиты с менеджерами проектов и прочие «хитрости». И страдаем пока директор сам не догадается что стоит пообщаться с программистами напрямую. Мы же гордые, чего это мы должны на всякую директорскую глупость идти и общаться, пусть сам увидит как это плохо работает, а мы поможем.
Этим Колянов с Серегами точно результат нужен был, хоть то в удобной им системе мотивации, хоть в «не трогайте нас, платите сколько договорились и дайте делать работу»? Почему-то у меня ощущение что им нужно было что-бы никто не лез в дела IT отдела от слова вообще (мы пишем хороший код, правда непонятно зачем и для чего), и особенно им нужно было доказать что они самые хитрые и смогут саботировать любую систему мотивации.
Я прям представил как я бы так баг фиксил, сидел бы и смотрел в монитор, да еще грузил бы проц на полную и сервер ребутил каждые пару минут, в надежде что багу надоедять такие жесткие условия он сам вылезет, извиниться и уползет из программы, ну или сервер сам как нибудь там починит чтобы его больше не мучили.
P.S. В формализируемые системы финансовой мотивации каждого разработчика не верю, всегда будут недовольные. Верю в рыночную систему определения ЗП (баланс между желаниями работника и желаниями работодателя).
У нас была рабочая система где "всё работало" — не без недостатков, но работало. И в какой-то момент пришли "новые залётные" и начали менять "под себя" — и получилось… не как в статье, но тоже не очень хорошо — многие процессы поломались и теперь идёт затыкание дыр. Потому что цель у "залётных" обычно не результат, а устроить движуху. Это обычная проблема, когда залётные что-то там прочитали/услышали и сразу начинают применять, потому что это "модно и современно" (ну или ничего иного не знают/не читали). "Залётные" не спрашивают у участников процесса "что не так?" — им это неинтересно и они в принципе не задаются этим вопросом. Складывается впечатление, что они "творят" по принципу — "авось проканает".
P.S. Рыночная система определения ЗП — не работает. Какие бы ни были у работника навыки выше определённой планки з/п не прыгнет по идиотской логике — "ну как мы тебе будем платить зарплату в 5 тысяч евро, если у нас во всём городе/стране максимальная — 2000?" или ещё "лучше": "во всей стране средняя полторы тысячи — мы тебе и так переплачиваем". Лично столкнулся с подобным идиотизмом. Переезд в другую страну, увы, не вариант.
Боюсь, что в какой мнибудь Тагиле, пришедшего на соискание работы собеседника, потребовавшего себе з/п в 5000 евро и соцпакет на руки быстро отошьют стандартным — "мы вам перезвоним".
Если взять клубнику, разложить по коробам разного цвета и с разной ценой, а сбоку на приступочке — маленькое лукошко с клубникой по 1000, то, если по рынку ходит человек с зарплатой в 10+килоевро, есть ненулевая возможность ему это лукошко продать. Психология потребления штука очень своеобразная. В начале 2000х сигареты «Парламент» подросли в продажах из-за единственного маркетингового решения — поднять цену до премиум-уровня.
А если это очень хорошая клубника? Без канцерогенов и ещё фиг знает вредного чего, но с прекрасным вкусом? Таким, что вы никогда не пробовали? Упакованная в золотой пакет с ленточкой и пушистой игрушкой?
Попрошу отметить, что работодатель покупает не ягоду на один раз, которую съест и всё, а работника на продолжительный срок. Но при этом продолжает применять понятия, как к единоразовому товару. Мало того — товару, на котором ещё и хочет сэкономить. И регулярно, несмотря на то что с опытом обычно характеристики улучшаются, пытается за счёт работника ПОНИЗИТЬ издержки.
В своём посте на тему того, что отношения не совсем рыночные, я как раз и имел в виду то, что работники обычно в ХУДШЕМ состоянии, в процессе поиска работы: у потенциального работодателя есть HR, юристы, менеджеры, чтобы вылизать каждый договор и "отфильтровать неугодных", а у работника — всего лишь навыки и, примерно, 10-30 минут уделённого времени, чтобы доказать, что ты крут, людям, которые — просто некомпетентны в вопросе (если до технического интервью дойдёшь — компетентны, но чтобы до него дойти надо потратить время ;))
у работника — всего лишь навыки и, примерно, 10-30 минут уделённого времени, чтобы доказать, что ты крут
Как я заметил, те кто приезжает на собеседование на очень дорогой машине, и зарабатывает больше, чем те кто приехал на обычной.
И регулярно, несмотря на то что с опытом обычно характеристики улучшаются, пытается за счёт работника ПОНИЗИТЬ издержки.
Работодателю от работника нужны ведь не характеристики, а получить нужный ему результат при минимальных издержках. Есть тысяча причин, почему «самый лучший» не означает «самый выгодный».
Работодателю от работника нужны ведь не характеристики, а получить нужный ему результат при минимальных издержках.
Не обязательно. Ему может требоваться максимально быстро, а может требоваться максимально качественно, и то и другое не получится совместить с максимально дёшево. И каждый работодатель выбирает, что ему из этих трёх важнее, а чем можно и пожертвовать.
«что работники — обычно в ХУДШЕМ состоянии» — я и нанимал, и собеседовал и сам искал работу, пока статистика такая — найти человека на проект сложнее чем устроиться на хорошую работу самому. Найти человека в свою компанию на долгосрок — еще сложнее. Учитывая время входа в средний проект и другие факторы, давая свое согласия работодатель, инвестирует в работника где-то 3-6 его ЗП, даже с испытательным и даже если уже в первый месяц понятно что человек его не прошел и пора расставаться. Работник рискует только 2-4 неделями на поиск новой работы, хотя чаще и ими не рискует так как работодатель обязан предупредить заранее. Так что нет, нормальное состояние, даже в чем то выигрышное. И навыки важнее договора, который обычно типовой, да и его прочитать можно вдумчиво и спросить и изменить если что не устраивает, хитрых уловок там обычно нет, смысла просто нет, раб программист обладает эффективностью стремящейся к нулю, ну а если критично то можно и дать на проверку внешнему юристу фрилансеру, не такое уж это и дорогое удовольствие учитывая возможные последствия. И договор вот он на столе, а навыки еще проверить надо, что тоже риск, собеседование далеко не полностью проверяет.
Но обычно я не меряю у кого хуже или лучше позиция, цель собеседования — понять подходим ли друг другу, компания и работник. Это общение равных, тут глупо давить или понтоваться. Как и покорно отвечать на вопросы, не интересуясь компанией. Ну а если одна из сторон это не понимает то она либо новичек в собеседованиях либо проблемы с адекватной самооценкой. Это и кандидата и «собеседующего» касается. А значит такие же проблемы будут и при работе, а значит нафик. Ведь суть вы указали правильно, это долгосрочное сотрудничество а не купили/продали клубнику выторговав максимально хорошие условия и разбежались, риск дальнейших прохих отношений не учитывается так как их и не будет.
«отфильтровать неугодных» — ну все логично, вы же тоже не отправляете резюме в каждое рога и копыта и не отвечаете согласием каждому hr-у? Кстати, обычно работа hr-a в основном заключается в том что-бы найти и заинтересовать, и на это уходит процентов 90 времени, а не отфильтровать тех кто сам обратился. Исключение госы где работники нужны раз в год и для галочки.
«за счёт работника ПОНИЗИТЬ издержки» — ну не за счет, а с учетом. Сэкономить на ЗП работника после найма 5-10% просто глупо, упавшая мотивация сьест гораздо больше эффективности. Ну а так да, если вы придете на собеседование на позицию которая обычно стоит 3К и попросите 5К то скорее всего скажут нет. Особенно если это аутсорс и заказчик платит 4К, да и в продуктах тоже умеют считать деньги. Фишка в том чтобы находить позиции где готовы платить 5К и иметь достаточные скилы для нее. То же и с повышением ЗП, TerraV верно описал принцип.
залётные что-то там прочитали/услышали и сразу начинают применять, потому что это «модно и современно» (ну или ничего иного не знают/не читали). «Залётные» не спрашивают у участников процесса «что не так?» — им это неинтересно и они в принципе не задаются этим вопросом. Складывается впечатление, что они «творят» по принципу — «авось проканает».
Они делают это, чтобы показать начальству «смотрите какие мы — крутые, и какие лохи — кто тут давно работает».
Да. Потому что подспудно они начальствоми и наняты, чтобы "всё поменять и получить конфетку". Проблема в том, что чтобы получить конфетку — надо для начала въехать в текуущий процесс, чтобы не наломать дров, а это время. Плюс — из работников обычно никто не будет откровенничать с "залётными" вот так запросто: они прийдут и уйдут, а работнику тут ещё работать. Если же начальство нанимает "залётных", а время идёт и ничего (движухи и изменений) не происходит — начальство спрашшивает уже "залётных": какого хрена вы делаете, мы для чего вас нанимали? Вообщем, для залётных куда ни кинь — всюду клин. Жадность начальства, неадекватность залётных, интровертность работников — и вот вместо конфетки фигня какая-то получается. Неудобоваримая =)
Но если людей наняли значит проблемы были, и «старожилы» их не решили, а то и не воспринимали как проблему и не хотели решать. Или не обладали достаточными возможностями и авторитетом чтобы решить. И это как ни странно тоже их вина. Не было лидера который бы взвалил на себя и тянул решение проблемы или убеждение руководства что это не проблема, нет его и сейчас чтобы обьяснить руководству и «залетным» что они совершают ошибку. Может это и не так, но в основном происходит в таких ситуациях именно так. Можно найти такого лидера, а лучше просто всем пообщаться со всеми сторонами, проявить инициативу, может они и все правильно делают, но вы этого не видите, человек не может быть профессионалом во всем, хороший программист может быть плохим менеждером даже если он проработал 10 лет на этом продукте и наоборот. Ну или уволиться, одному или всем. Тоже вариант, рыночный. Можно еще потерпеть и привыкнуть, перестроение процессов всегда боль, даже если команда всеми руками за, а уж если против то сильная и долгая боль. Тут что комфортнее надо выбирать. Но выбирать нужно. Просто выбрать и признатся в первую очередь самому себе что выбор сделан, и сделан самостоятельно, а не его навязали, сразу проще становиться. Сорри за нравоучения, но как же это жалко и нелепо когда взрослые люди ноют и думают что все решают за них, а они лишь беспомощные винтики в этой бездушной машине. Начальник дурак а от нас ничего не зависит. Сколько раз это видел, и каждый раз не понимал зачем так себя унижать. А начальники в это время жалуются на безинициативных сотрудников, погрязших в рутине, и на необходимость нанимать новых, которые ничерта не разбираются и не скоро разберется но у них хотя бы есть желание исправить проблемы.
Да, напрягает это слово, «залетные», в духе «он не из нашего района, что он может вообще знать» своячество этакое, сами создаете границу и формируете конфликт как те программисты в посте. От которого все потом будут героически страдать. Зато гордо и независимо и своей тесной компашкой.
Это все конечно же ИМХО из моего общего опыта на десятках проектах на разных позициях и с разных сторон этой «баррикады», делать выводы по одному коменту почти невозможно, все предположения.
Для того, чтобы решить проблему — необходимо:
- Понять в чём именно проблема
- Иметь ресурсы и полномочия её решить.
В случае "местной" команды — у них есть первое, но нет второго.
В случае "залётных" (уж извините буду продолжать использовать, для краткости) — у них есть второе, но нету первого и это сильно хуже (ИМХО), чем предоставить ресрсы разрабам.
Статья раскрывает проблему как "слишком дорого платить разрабам", что выглядит не как проблема, а как самодурство, а потом ещё и впривлекают "специалистов", которые в принципе отказываются вникать в проблему, а сразу переходят к решению.
Приведу интересный пример из мира не айти)
Я когда-то колымил грузчиком. Наш бригадир старался не брать заказы с оплатой по часам. Объяснял он это так:
'мы работаем быстро и аккуратно, без перерывов и перекуров. Не хочется за свою работу получить меньше, чем какие-нибудь алкаши, которые бы весь день потратили на то, с чем мы за час справились'.
Вот тут примерно то же самое — зачем программисту тратить своё время на то, чтоб сделать лучше, если ему заплатят больше за то, что он сделает наотъе… сь
Эта статья сделала мой день! АГромное спасибо :D
К середине текста от слога и быдло стиля, стали вытекать глаза. Программисты в общении к гопники получились.
Вам везет — только глаза. У меня от прототипов уши сворачивались.
Не гопники, а пролетарии умственного труда.
Вспомнил как у нас для QA ввели KPI, в течении недели они начали тратить мое время, потому что, по их мнению, я должен был разбираться какой из этих дубликатов, был первым и закрыть только последующий, т.к. у них за дупы штраф. Короче, это хотя бы было на уровне отдела, поговорил с их начальницей и больше они подобных вопросов не поднимали.
СБ и нужно, чтобы выявлять и перкращать подобные вещи.
СБ должно обеспечивать безопасность, а не играть роль надсмотрщика с кнутом над рабами.
последующие действие это «мошенничество совершенное группой лиц по предварительному сговору»
А в чём собственно мошеничество? Что незаконного в том, что одну задачу из десяти пунктов, разбить на десять задач по одному пункту?
Тем более, что в реальной жизни пользователи часто валят в одну задачу несколько задач для разных отделов IT. И приходится разъяснять, что вот это вот для тех кто пишет функционал, а это для тех кто создаёт отчёты, третье же это вообще для тех поддержки.
— В чём мошенничество и преступление в том, что такой неудобоваримый комок разбили на несколько задач для разных отделов?!
А если задачу разбили на несколько человек выполняющих каждый свой пункт задания в качестве своей индивидуальной задачи.
— То в чём здесь реальная уголовка?!
– Ну и прекрасно! – сказал довольный Колян. – Только наглеть не надо, давай и через пользователей задач нафигачим.
А дальше идет описание того, как они шантажом заставляют заказчика генерировать дополнительные задачи.
Воздействие на представителя заказчика с целью получения дополнительной прибыли сотрудником в ущерб предприятию это мошенничество.
Не факт, что внутренние разделение задач дало им дополнительную прибыль, но они уже начали мошенничать с представителем заказчика.
PS если мотивация СБ, любой ценой найти и назначить виновного и посадить, чтобы красиво выслужиться, то эти действия начнут наносить РЕАЛЬНЫЙ ВРЕД бизнесу, так как люди предпочтут не вмешиваться даже когда всё реально идёт под откос, чем потом разъясняться с СБ настроенной найти козла отпущения.
Если у СБ её эффективность измеряется количеством пойманных, то не будет ли у неё прямого интереса выдавать реальную необходимость за «злой умысел»?
СБ должно анализировать нетипичные ситуации. То от заказчика поступало одно количество задач, то вдруг после того как это этого стала зависеть зарплата программистов, оно резко возрастает. Задача нормального СБшника пообщаться с представителем заказчика и ненавязчиво поинтересоваться с чего вдруг?
Мошенничество, то есть хищение чужого имущества или приобретение права на чужое имущество путем обмана или злоупотребления доверием
А в это время