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