На сайте ведутся работы Как оценивать работу программиста? Выпуск от 29.10.2009 г. | ОБЩАЯ СТРАНИЦА | Бизнес-форум TRIZ-RI
9737
СОГЛАСЕН С ОБРАБОТКОЙ ЛИЧНЫХ ДАННЫХ
Все категории » ОБЩАЯ СТРАНИЦА » Подборка инструментов и рекомендаций многолетней "выдержки".

Как оценивать работу программиста? Выпуск от 29.10.2009 г.

Ваши данные (просмотреть)
в избранные темы
Политика конфиденциальности

Обсуждения-аналоги

Скрыть / Показать Сортировать по дате
Создать аналогичное обсуждение...

Авторы

Скрыть / Показать
2009-10-29 13:39:40
Редакция » Всем

Уважаемые Коллеги!

Мы публикуем периодическую подборку проверенных временем инструментов и рекомендаций. В помощь уважаемым Руководителям и Владельцам бизнеса. Для быстрого просмотра,  н е с п е ш н о г о  обдумывания и твёрдого принятия решений.

Тема выпуска: КАК ОЦЕНИВАТЬ РАБОТУ ПРОГРАММИСТА?

================================================================================

Как быть Руководителю, принимающему на работу программиста? А когда он уже принят - как проверять его работу? Традиционно IT-отдел - "терра инкогнита" за семью печатями... Наконец, как принимать работу у внешних подрядчиков - разработчиков программ, web-сайтов, пр. технических "хитростей", если... Если квалификация специалиста в данной области объективно выше квалификации уважаемого Руководителя.


Становится сложно оценивать его работу (в том числе - загруженность), не вникая в "детали" предмета, - на фоне хорошо подкрепленных "отмазок" о "принципиальной невозможности". В IT-отделах что-то хронически не "масштабируется" и не "конфигурируется"... Устранение сетевых сбоев подменяется объяснением их причин ("Это происходит потому, что...") и ссылками на внешние обстоятельства... Любая задача объявляется "творческой", поэтому "сколько на это уйдет времени - неизвестно"...


Посмотрим несколько характерных обсуждений на нашем Форуме:

...чтобы стимулировать не только безошибочную работу в срок, но и творческую инициативу в решении сложных задач программирования. Но прежде формализуем работу программиста понятным для Руководителя образом.

Нередко - даже опытные! - программисты забывают о том, что их программа должна решать определенные бизнес-задачи. В итоге получается нечто монстроподобное, что трудно сопровождать... О том, как подрядчики понимают "техзадание" Заказчика, и как должны понимать. На чем акцентировать их внимание, чтобы не забывали... Пошаговый Алгоритм действий, прозрачный для обеих сторон.  

Целых ТРИ нити обсуждений по данной теме. В каждой из них рассматриваются разные задачи и варианты решений. Разбираются конкретные примеры и приводятся детальные таблицы с прописанными функциями программиста, нормативным временем выполнения и указанием "что на выходе".

А если у Вас останутся вопросы, задайте их нам на этом Форуме.

================================================================================


ГОТОВАЯ МОДЕЛЬ ЗАРАБОТНОЙ ПЛАТЫ ПРОГРАММИТА

Кроме того, мы выпустили актуальный пакет, содержащий работающую МОДЕЛЬ ЗАРАБОТНОЙ ПЛАТЫ ПРОГРАММИСТА и, в том числе, ПРЕМИЮ ЗА КРЕАТИВНОСТЬ (т.е. за производство идей).


Если у Вас работают программисты и Вы - не Google, то этот пакет для Вас. Мы тоже используем. Опытом готовы делиться на этом Форуме и не только.

================================================================================

Для тех, кто хочет углубиться в "предмет" своего программиста - посмотреть, полистать, понять в целом - несколько статейных "хэлпов" на ту же тему (не говоря уже о готовых кейсах): 

"Если есть в бизнесе хоть одна область, которую считают неподдающейся упорядочению, то это разработка программного обеспечения для компьютеров. Разработчиков программного обеспечения все (в том числе они сами) считают этакими ковбоями и свободными художниками. Свою работу они традиционно считают творчеством и художественным самовыражением, ничуть не похожим на труд инженера.


Слово "хаос" будет недостаточно выразительным, чтобы описать, что творилось в отделе разработки программ компании Hewlett-Packard несколько лет назад. Неудивительно, что новые программы Hewlett-Packard неизменно появлялись на рынке с опозданием, с превышением бюджета и с ошибками.


Какое-то время руководители отделений компании просто терпели, предполагая, что такой беспорядок просто органически свойствен разработке программного обеспечения. Но несколько лет назад они решили, что хаос в разработке программ не обязателен". Вот что было сделано.

Для решения некоторых задач программирования в качестве "инструмента", облегчающего разработчику абстрагирование от конкретики, предлагается использовать "абсолютно тупого героя", которому поручается некая деятельность. Поскольку этот герой непроходимо туп (мы даже пишем его с маленькой буквы, чтобы и тени величия в нем не наблюдалось), то задача поручить ему деятельность, которая, тем не менее, должна быть выполнена - нетривиальна. Тем не менее, надо описать решение так, чтобы тупой (несколько тупых) смогли качественно и незатратно порученную задачу выполнить.


И еще несколько материалов о полезных "упрощениях" при разработке программных продуктов: 

С Уважением, Редакция Форума "Рекламное Измерение"

[Нет ответов на это сообщение]


Яндекс.Метрика