Комментарии 41
НЛО прилетело и опубликовало эту надпись здесь
Спасибо за опыт, давно было подобное ощущение, но до исследования все руки не доходили.
Вы пробовали анализировать корреляцию «продуктивности» специалиста с годами работы в должности, годами работы в компании или какими-то другими факторами?
Вы пробовали анализировать корреляцию «продуктивности» специалиста с годами работы в должности, годами работы в компании или какими-то другими факторами?
Кхе… знал бы прикуп — жил бы в Сочи :) Четкого ответа у меня нет. Есть наблюдения. Скорость освоения информации — этот параметр заметен уже через пару месяцев совместной работы. Если параметр высокий — то выход на высокую «продуктивность» в проекте получается довольно быстро. Если же скорость освоения информации низка — то события в проекте и в мире технологий будут происходить быстрее, чем человек подстроится под них… в таком печальном случае, скорее всего, человек неправильно выбрал профессию.
К вопросу о том, в чем причина разброса в продуктивности — покопался в книге Джоэла Спольски, на 95-й странице нашел абзац:
«Пятнадцатилетний опыт программирования убедил меня в том, что все лучшие программисты способны легко разбираться сразу с несколькими уровнями абстракции. По отношению к программированию это означает, что у них нет проблем с рекурсией… или со сложными алгоритмами… Я пришел к выводу, что понимание указателей — это не квалификация, а способность. „
«Пятнадцатилетний опыт программирования убедил меня в том, что все лучшие программисты способны легко разбираться сразу с несколькими уровнями абстракции. По отношению к программированию это означает, что у них нет проблем с рекурсией… или со сложными алгоритмами… Я пришел к выводу, что понимание указателей — это не квалификация, а способность. „
> У каждого блока известна его оценка, est, которую проставляет ведущий разработчик, и потраченное программистом время, spent.
смущает немного такая оценка. не могу сейчас четко сформулировать, но что-то тут не то.
ведь разработчики работают во взаимодействии друг с другом. а значит, еще важна структура команды… как-то так.
смущает немного такая оценка. не могу сейчас четко сформулировать, но что-то тут не то.
ведь разработчики работают во взаимодействии друг с другом. а значит, еще важна структура команды… как-то так.
Спасибо, интересно очень
>> работаем практически только с сильными программистами.
То есть вы уволили часть программистов. Почему об этом не написано прямо?
Тогда вся статья свелась бы к одному предложению: «уволили тех, кто работает меньше, сэкономили 100%, половину сэкономленных средств отдали тем, кто остался».
То есть вы уволили часть программистов. Почему об этом не написано прямо?
Тогда вся статья свелась бы к одному предложению: «уволили тех, кто работает меньше, сэкономили 100%, половину сэкономленных средств отдали тем, кто остался».
Оставшиеся в радостном испуге начали нажимать на кнопки еще активнее.
Я не сомневаюсь, что статья для некоторых читателей Хабра очевидна. Ну а теперь попробуйте объяснить то же самое не-программисту. И Вы услышите вопросы: а чем программисты такие особенные? почему все профессии как профессии, а программисты вечно ворчат о своей уникальности? ))) Вот статья о том, как я искал эти аргументы, и почему не так просто их донести.
НЛО прилетело и опубликовало эту надпись здесь
Значит, мне придется Вас разочаровать: оплата каменщика чаще всего именно сдельная. Это действительно приводит к халтуре. Качество формально проверяется, но халтура остается. К счастью, несущие конструкции в крупных зданиях не держатся на кладке.
Возвращаясь к теме оценки «скорости» программиста. На моей практике, сотрудник, который сначала пишет «костыли», а потом дорабатывает изначально неверно написанный код, тратит в сумме больше времени, чем сотрудник, который сразу пишет правильно.
В идеале считается, что качество кладки не зависит от каменщика, вернее что оно не ниже требуемого ТЗ, СНиПами и т. п. В строительстве качество обычно легко можно проверить на соответствие требованиям, да и сами требования чётко формализованы (например, статическая или динамическая нагрузка) и квалификация (а значит и сдельная зарплата) каменщика напрямую зависит от скорости работы. Качество кода же или архитектуры субъективное понятие, практически не формализуемое, да и ситуативное, в одном случае важно оптимизация производительности, в других сложность расширения функционала.
Думается, что прозрачная и понятная система формирования оплаты будет еще и хорошей мотивацией служить, что в свою очередь тоже будет влиять на результат.
ошибочный подход к мотивации в интеллектуальной деятельности
Я всего лишь говорил о том, что мотивации прибавится от того, когда понимаешь как оценивается твоя результативность и что ее вообще оценивают. А не так во многих компаниях прибавляют зарплату всем примерно одинаково. Я это писал не с позиции менеджера, а как разработчик. С позиции, что для опытных разработчиков такая оценка их труда принесла реальную прибавку к зарплате, и уверен, что это не могло не повлиять на мотивацию.
Награда губительная для творчества
habrahabr.ru/blogs/arbeit/69569/
habrahabr.ru/blogs/arbeit/69569/
Рекомендую почитать Элию Голдратта, начните с книги «Цель». Очень интересно, каких результатов вы сможете достичь применяя теорию ограничений.
НЛО прилетело и опубликовало эту надпись здесь
А качество кода как учитывать? Я сейчас даже не о багах, а о той же масштабируемости.
Лично сталкивался с прораммистами, которые именно очеь-очень быстро лепили всё из костылей — и оно даже кое-как работало.
А потом через месяц нужно что-то сбоку прикрутить, и понимаешь, что нужно всё выкинуть и написать с нуля.
Лично сталкивался с прораммистами, которые именно очеь-очень быстро лепили всё из костылей — и оно даже кое-как работало.
А потом через месяц нужно что-то сбоку прикрутить, и понимаешь, что нужно всё выкинуть и написать с нуля.
Думаю кадры должен подбирать человек, который владеет знаниями и идеями архитектуры и в период вникания нового человека (ведущего разработчика) смотреть за качеством и за тем, как человек понимает/перенимает стиль и идею. Думаю если не запускать первый месяц-полтора проект — можно держать в голове решения и оценивать/корректировать их.
Отчасти верно, конечно.
Но есть такие люди, это просто склад мышления такой — быстрее, примитивнее, «в лоб» и на отъе*ись. Даже если стоять за спиной с палкой и тыкать пальцем в шаблоны, помогает лишь частично. Всё равно качество не дотягивает до уровня вдумчивых и аккуратных коллег. И стоит через какое-то время ослабить контроль — идёт неизбежный откат к старому.
Но если взять по ним узкий статистический срез, не видя всей картины — они нередко чемпионы по скорости.
Но есть такие люди, это просто склад мышления такой — быстрее, примитивнее, «в лоб» и на отъе*ись. Даже если стоять за спиной с палкой и тыкать пальцем в шаблоны, помогает лишь частично. Всё равно качество не дотягивает до уровня вдумчивых и аккуратных коллег. И стоит через какое-то время ослабить контроль — идёт неизбежный откат к старому.
Но если взять по ним узкий статистический срез, не видя всей картины — они нередко чемпионы по скорости.
Ну, если они дают на выходе рабочий и вменяемый код, то такие работники полезны, когда поджимают сроки. Примитивный код часто имеет свои преимущества (читабельность, скорость работы), а шаблоны — не законы, а рекомендации, их применение везде и всюду тоже не всегда полезно. Так что надо не стоять над ними с палкой, а подбирать им соответствующую работу. В конце концов, одноразовый код типа write only (когда не важны ни скорость работы, ни удобство поддержки и расширения, лишь бы работал) тоже часто бывает нужен.
Угу, есть такое. Поэтому статистику лучше считать по окончании проекта (ну или хотя бы за длительный интервал времени, чтобы снизить роль стат флуктуаций).
не туда написал — ответ на коммент
извините, не совсем понял математику.
вы осуществили декомпозицию задачи на равные блоки.
вы вручили блоки с разной специализацией (где-то ближе к ядру, где-то ближе к gui) соответственно талантам программистов — как бы вроде бы исходя из критерия «специалист K сделает блок со спецификой X быстрее других в команде»
так что ли?
какие ещё детали и методы?
просто в статье только и видно, что «лид-программер щёлкает плоские блоки толпами и быстро, так что ядро оставили нубам». это заставляет думать, что вы не смогли донести и раскрыть метод.
вы осуществили декомпозицию задачи на равные блоки.
вы вручили блоки с разной специализацией (где-то ближе к ядру, где-то ближе к gui) соответственно талантам программистов — как бы вроде бы исходя из критерия «специалист K сделает блок со спецификой X быстрее других в команде»
так что ли?
какие ещё детали и методы?
просто в статье только и видно, что «лид-программер щёлкает плоские блоки толпами и быстро, так что ядро оставили нубам». это заставляет думать, что вы не смогли донести и раскрыть метод.
]]] Давайте посмотрим, как оплачивается работа, скажем, каменщика на стройке. Его зарплата чаще всего
]]] пропорционально зависит от выработки: поработал в 2 раза быстрее, получил в 2 раза больше денег.
Опять старая ошибка. Аналогично и программированию, объём результата не пропорционален пользе.
Если каменщик выложит высокую стену (больше сколько-то рядов) пока не затвердеет предыдущее, на следующий день стену надо сносить и делать заново, ибо она уедет.
Программист аналогично, если он написал за час 10кб кода то за 2 часа он мог спланировать приложение лучше и написать 5 килобайт кода которые работают в 10 раз быстрее и которые поддерживать в 30 раз дешевле, и на исправление багов в котором уйдёт в 50 раз меньше времени (а значит и денег)
]]] пропорционально зависит от выработки: поработал в 2 раза быстрее, получил в 2 раза больше денег.
Опять старая ошибка. Аналогично и программированию, объём результата не пропорционален пользе.
Если каменщик выложит высокую стену (больше сколько-то рядов) пока не затвердеет предыдущее, на следующий день стену надо сносить и делать заново, ибо она уедет.
Программист аналогично, если он написал за час 10кб кода то за 2 часа он мог спланировать приложение лучше и написать 5 килобайт кода которые работают в 10 раз быстрее и которые поддерживать в 30 раз дешевле, и на исправление багов в котором уйдёт в 50 раз меньше времени (а значит и денег)
Думаю, качество кода тоже проверяется. А вот подход, когда оплата идет _только_ за качество (и неважно, сколько времени займет разработка, пусть весь мир подождет), приводит к плохим последствиям. Если продолжать аналогию с каменщиками — то вы на стадии котлована отдали миллион за квартиру, чтобы через 1.5-2 года въехать в нее, а пока снимаете, и платите ого-го сколько в месяц. И вот проходят два года, вы приезжаете… а там по прежнему котлован. Но видели б вы этот котлован! Стеночки гладенькие, на дне — ни одного окурка, само дно по уровню выровнено…
Это само собой, ибо есть простая формула где время = деньги, но есть и порог целесообразности. Не выгодно строить дом 100 лет, но в тоже время за месяц дом хороший не построишь. (А плохой не продашь Дорого)
Я лишь призываю более широко смотреть на продуктивность и на эффективность, эти вещи связаны конечно, но это ни в коем случае не одно и тоже. (Уж слишком часто я встречаюсь с таким заблуждением.)
Я лишь призываю более широко смотреть на продуктивность и на эффективность, эти вещи связаны конечно, но это ни в коем случае не одно и тоже. (Уж слишком часто я встречаюсь с таким заблуждением.)
Автор, а вы бы еще привели наглядную статистику, сколько было народу, сколько они получали (в процентном отношении от самой маленькой з/п). До и после сокращения.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Об экономии денег в проекте