Re[7]: аттестации
От: SergeMukhin Россия  
Дата: 04.01.04 11:08
Оценка: -1
Здравствуйте, promsoft, Вы писали:

SM>>если горячее питание это подвиг программиста, то надо уборщице сразу давать 10 балов!

P>Организация доп.питания в конторе, где менеджер проекта — не владелец фирмы (а так чаще всего и бывает) вполне может быть подвигом

мы все еще говорим об IT? И при чем тут подвиг повара?

P>>>Сюда же — дополнительные баллы тем, кто сдал в этом периоде серьезные сертификационные экзамены,

SM>>это вообще под большим вопросом, нгужны ли эти экзамены и что такое серьезные?
P>См. флейм про то, нужно ли высшее образование. Сертификация бывает разная.

про ВО речи здесь нет, не надо стрелки переводить, а о сертификации по программированию? и какие Вы считаете серьезными?

P>>>либо написал внутрифирменную методичку, и т.д.

SM>>вообщем устроим ленинский зачет.
P>Зря глумишься. Внутрифирменная методичка — большое дело.

я просто не понимаю, чем методичка может помочь в работе программиста? Последний раз я их вмдел в советской конторе еще до перестройки.

P>>>Затем определяется взвешенный балл каждому. Конкретные весовые коэффициенты — личное дело каждой фирмы.


SM>>а когда работать? все время займет взвешевание, оценивание, головсование и тп и тд.

P>Раз в квартал тайное голосование — 5 минут. Более программиста не отвлекать — остальное делается менеджментом.

SM>>т.е. опять приходим, что оценка — личное дело фирмы. алгоритма нет.

P>Посылки.
P>1.Программист предназначен приносить прибыль работодателю.
P>Именно по тому, насколько он приносит ему прибыль, работодатель и должен его оценивать.

P>2.Прибыль он пожет приносить по-разному. Например, выдавать на гора километры кода.

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

P>3.Поскольку фирмы разные, персонал нужно оценивать по-разному.

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

P>4.Проект должен иметь образ достижения и ограничения.

P>Ты не сформулировал образ достижения ("хочу, чтобы все было честно и само собой").
P>Представь себе ТЗ на софт: "хочу, чтобы оно делало то, что мне надо так,к ак мне нравится".

пп с 1 по 4 общие слова.

P>Стало быть, вот тебе план проекта от сетрифицированного PM, бесплатно

P>1.Определяется заказчик. В частной фирме -это владельцы, или уполномоченный ИМИ на это представитель.
P>Он будет принимать работу.

P>2.Проектная группа на этом этапе может состоять из одного человека. Он готовит на утверждение,


так тут их больше одного может быть!

P>(а Заказчик утверждает) цели, ограничения,достижения и оценочные критерии проекта:

P>Цели: (например)
P>-увеличить ROI
P>-уменьшить текучесть кадров
P>Ограничения: (например)
P>-срок 3 месяца,
P>-N зарплаты тем, кто будет этим заниматься
P>- не более 1 уволившегося с мотивировкой "не нравится система аттестации"

вот-вот, наняли одного социолога на зарплату одного уволенного программиста. Долой социологов! Работу программистам, а не методистам!

P>Достижения: (например)

P>-внутрифирменная методичка по аттестации (чтобы после увольнения того, кто это разработает, все не умерло)
P>-одна полная проведенная аттестация

вот оно! достижение аттестации — сама аттестация!!! тогда достижение программирование — само программирование!

P>Оценочные критерии:

P>-текучесть кадров в течение ... месяцев после внедрения системы, сравнительно с ...до,
P>показывает снижение текучести кадров на 5%

5% чего угодно — ошибка измерений.

P>-статистика по успешно выполненным задачам/подпроектам по подразделениям показывает, что существует

P>четкая корреляция между успешностью подразделения и его средним баллом.

как в передачи "здоровье": все дети, которые посещают бассейн не болеют. Так скорее наоборот, те кто не болеет — посещают. А здесь если проект успешно закончен, мы тут же ему 10 баллов и получаем отменную корреляцию.

P>3.Далее некоторое время на системный анализ (IDEF0 в зубы, карандаш в руки, и вперед) процесса

P>разработки.

ну вот, пусть пишут социологи программы, а мы методички начнем.

P> Вкупе с целой кучей полезной информации получаем список факторов, влияющих на

P>текучесть кадров и результативность подразделений.
P>Выкидываем из этого списка все, что не связано с личными качествами исполнителей, и
P>утверждаем этот список заказчиком.

P>4.Далее для каждого элемента списка разрабатываем методику тестирования/выявления.


P>5.Выкидываем дублирующиеся/перекрывающиеся элементы и порождаем методичку по аттестации

P>6.С соизволения Заказчика начинаем тестовую аттестацию части персонала, случайной выборкой.
P>7.На основе полученных результатов Заказчик решает, закрыть проект по аттестации
P>как бессмысленный , доработато методичку или пустить в промышленную эксплуатацию.
P>8.Проводится аттестация всего персонала.
P>9.Через N месяцев проект оценивается по критериям, утвержденным на 2 шаге.

P>--------------

P>Чем тебе не алгоритм

Одно из свойств алгоритма, что он должен когда-нибудь заканчиваться. Здесь этого не видно.

P>Да, кстати, а размер фирмы какой?


размер какой фирмы?
... << RSDN@Home 1.1.0 stable >>
---
С уважением,
Сергей Мухин
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.