Для комментария к топику многовато, поэтому, с вашего позволения отвечу топиком.
Начиная читать статью, был полностью согласен, как нельзя оценивать эффективность, но дойдя до как можно, стал в очень многом не согласен. О чем я? Смотри далее…
Оговорюсь сразу, я не хочу сказать, что это плохие оценки эффективности. Главное при применении этих, или любых других оценок, не увлекаться, иначе эффект будет обратным.
1. Меньше ошибок — более эффективный работник
Данный постулат выдвигает идею: программист не делающий ошибок (экстраполяция требования меньше ошибок), выгоден компании. Вам рассказать кто не делает ошибок? (Ну если интересно, то сюда).
Теперь, посмотрим с экономической точки зрения. Например, вы как разработчики реализуете метод загрузки файла на веб-сервер. Вы проверили базовые вещи: загрузка пустого файла, загрузка маленького файла, загрузка файла чуть побольше. И передали в отдел тестирования. Где специалист по тестированию проверил, как отрабатывает форма загрузку файла размером 2 ГБ. Проверяет он на каналах 10Мб/с, 2 Мб/с, 1Мб/с, 0.5Мб/с. Рассказать сколько это займет времени? А добавьте к этому проверку обрывов связи, отработку переполнения хранилища и много чего еще. К чему это я? Да все к тому, что вы заплатите программисту в 2-3 раза больше за проведенное тестирование, чем человеку отвечающему только за тестирование. Да, программист должен проводить тестирование методом «белого ящика»! Но программист который переходит разумные границы в этом вопросе — зло. Кстати, вот это тоже вспомнилось [1]. Ну и в заключении, как только вы начнете платить программисту за то что у него мало ошибок, он договориться с тестировщиком, а премию они поделят.
2. Генераторы идей много раз эффективнее потребителей идей
Здесь, даже как-то стыдно отвечать… Вот как Вам кажется, кто для вашей компании лучше, человек генерирующий в час 100 идей, загорающийся ими, увлекающий за собой… Но также быстро остывающий и перекидывающийся на следующую идею. Или сотрудник, генерирующий в год, может быть одну стоящую идею, но доводящий ее до реализации.
Ну а «Потому что им интересно изобретать велосипеды, и ни в коем случае нельзя отбирать у них эту возможность. » — даже и не знаю… В ВУЗе, в исследовательском центре, в отделе тестирования… Но разработчик изобретающий велосипеды в рамках коммерческого проекта, в большинстве случаев — зло. [2]
3. Чем более абстрактное мышление, тем эффективнее работник
Мне встречались пару раз «архитекторы», превращавшие простую абстракцию из двух уровней наследования, в иерархии классов уровней на 5-7. И оно вам действительно надо? Рекомендую почитать [3].
4. Эффективность работника прямо пропорциональна его самомотивации
Тут я согласен с самомотивацией. Это та мотивация которая требует расти дальше. Но вот с выводом о том где надо работать… В корне не согласен. Человек «агрессивный», по версии автора, стремится работать в стартапе. Вот, ведь все читающие эту статью, стремятся к расширению кругозора, получению новых идей, может быть и противоречащих вашим убеждениям (т.е. обладающие самомотивацией), но… Перед вами лежит два предложения: поработать в стартапе (сайт, с гениальной идеей, от вас требуется его разработать MySql+Php) и в Intel (разработка компилятора для параллельного языка программирования). Чье предложение вы примите? В качестве еще одного примера, как компания на букву G повышает уровень самомотивации своих работников, настоящих и будущих — [4].
5. Чем быстрее работники выполняют доработку кода, тем они эффективнее
+1
Ну и в заключении:
У каждого человека есть определенный кругозор. Когда этот кругозор сужается до бесконечно малого — он обращается в точку. Именно тогда человек и начинает говорить, что это и есть его «точка зрения». Эдвин Гилберт
Поэтому читайте, сравнивайте, и принимайте свое решение, даже если оно будет оказываться не всегда правильным. Хорошего дня, и эффективных программистов в коллегах и подчиненных.
Использованная литература
1. Victor435. Тестирование ПО: как объяснить руководителю, что 2 х 2=4?
2. HighOctane. Десять советов начинающим программистам совет №6
3. Джоэль Спольски. Не дайте Астронавтам Архитектуры вас запугать
4. http://kitya.livejournal.com/188574.html
Начиная читать статью, был полностью согласен, как нельзя оценивать эффективность, но дойдя до как можно, стал в очень многом не согласен. О чем я? Смотри далее…
Оговорюсь сразу, я не хочу сказать, что это плохие оценки эффективности. Главное при применении этих, или любых других оценок, не увлекаться, иначе эффект будет обратным.
1. Меньше ошибок — более эффективный работник
Данный постулат выдвигает идею: программист не делающий ошибок (экстраполяция требования меньше ошибок), выгоден компании. Вам рассказать кто не делает ошибок? (Ну если интересно, то сюда).
Теперь, посмотрим с экономической точки зрения. Например, вы как разработчики реализуете метод загрузки файла на веб-сервер. Вы проверили базовые вещи: загрузка пустого файла, загрузка маленького файла, загрузка файла чуть побольше. И передали в отдел тестирования. Где специалист по тестированию проверил, как отрабатывает форма загрузку файла размером 2 ГБ. Проверяет он на каналах 10Мб/с, 2 Мб/с, 1Мб/с, 0.5Мб/с. Рассказать сколько это займет времени? А добавьте к этому проверку обрывов связи, отработку переполнения хранилища и много чего еще. К чему это я? Да все к тому, что вы заплатите программисту в 2-3 раза больше за проведенное тестирование, чем человеку отвечающему только за тестирование. Да, программист должен проводить тестирование методом «белого ящика»! Но программист который переходит разумные границы в этом вопросе — зло. Кстати, вот это тоже вспомнилось [1]. Ну и в заключении, как только вы начнете платить программисту за то что у него мало ошибок, он договориться с тестировщиком, а премию они поделят.
2. Генераторы идей много раз эффективнее потребителей идей
Здесь, даже как-то стыдно отвечать… Вот как Вам кажется, кто для вашей компании лучше, человек генерирующий в час 100 идей, загорающийся ими, увлекающий за собой… Но также быстро остывающий и перекидывающийся на следующую идею. Или сотрудник, генерирующий в год, может быть одну стоящую идею, но доводящий ее до реализации.
Ну а «Потому что им интересно изобретать велосипеды, и ни в коем случае нельзя отбирать у них эту возможность. » — даже и не знаю… В ВУЗе, в исследовательском центре, в отделе тестирования… Но разработчик изобретающий велосипеды в рамках коммерческого проекта, в большинстве случаев — зло. [2]
3. Чем более абстрактное мышление, тем эффективнее работник
Мне встречались пару раз «архитекторы», превращавшие простую абстракцию из двух уровней наследования, в иерархии классов уровней на 5-7. И оно вам действительно надо? Рекомендую почитать [3].
4. Эффективность работника прямо пропорциональна его самомотивации
Тут я согласен с самомотивацией. Это та мотивация которая требует расти дальше. Но вот с выводом о том где надо работать… В корне не согласен. Человек «агрессивный», по версии автора, стремится работать в стартапе. Вот, ведь все читающие эту статью, стремятся к расширению кругозора, получению новых идей, может быть и противоречащих вашим убеждениям (т.е. обладающие самомотивацией), но… Перед вами лежит два предложения: поработать в стартапе (сайт, с гениальной идеей, от вас требуется его разработать MySql+Php) и в Intel (разработка компилятора для параллельного языка программирования). Чье предложение вы примите? В качестве еще одного примера, как компания на букву G повышает уровень самомотивации своих работников, настоящих и будущих — [4].
5. Чем быстрее работники выполняют доработку кода, тем они эффективнее
+1
Ну и в заключении:
У каждого человека есть определенный кругозор. Когда этот кругозор сужается до бесконечно малого — он обращается в точку. Именно тогда человек и начинает говорить, что это и есть его «точка зрения». Эдвин Гилберт
Поэтому читайте, сравнивайте, и принимайте свое решение, даже если оно будет оказываться не всегда правильным. Хорошего дня, и эффективных программистов в коллегах и подчиненных.
Использованная литература
1. Victor435. Тестирование ПО: как объяснить руководителю, что 2 х 2=4?
2. HighOctane. Десять советов начинающим программистам совет №6
3. Джоэль Спольски. Не дайте Астронавтам Архитектуры вас запугать
4. http://kitya.livejournal.com/188574.html