Как оценить сотрудника?

По результатам. Надо только знать какие именно результаты следует оценить и какой линейкой их измерять.

Как начинается новое улучшение в программном продукте? Анализ, проектирование и исследование вариантов, выбор варианта и вот материалы для маркетинга уже готовы.

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

Либо на этом этапе мы выясняем что овчинка выделки не стоит и невозможно объяснить почему надо выбирать именно наш продукт за наличие этого улучшения, может ли оно пойти как мелкий "+" или навалит нам работы на поддержке.

Эта работа не для каждого. Многим я ее не доверю, но она вполне по силам некоторым довольно профессиональным сотрудникам. С очень высокой вероятностью они ее сделают не хуже меня. Прежде чем применять к кому-либо такое утверждение, я много раз проверяю "насколько оно соответствует действительности?" Действительно ли вероятность настолько высока?

В принципе, этой работой будут фактически заниматься и менее профессиональные сотрудники. Вероятность ошибки - больше. Время на задачу - тоже больше. Но если ошибутся - есть кому поправить, контроль не дремлет. Запоминаем, ждем следующего раза и помним про этот. Надо только балансировать обучение и сроки сдачи. Если не ошибутся и сделают все быстро - значит обучение идет, запоминаем, ждем следующего раза и помним про этот.

Дальше в работе над улучшением идет проектирование, кодирование, тестирование, создание заготовки документации по GettingStarted/Concepts/Reference, FAQ, примеры, заготовки блогов, видео для вебинаров. А при необходимости и изменение описания под сроки, выделение доделок "на следующий релиз". Все это должно укладываться в методологию: сроки, планирование релизов и итераций, размеренная работа по итерациям, размеренная выдача улучшений в продукт.

Вся эта работа начинается сразу, с новичка. Задачи подбираются специально так, что бы у сотрудника были знания (или он мог их довольно быстро получить). Подбираются так, что бы можно было без ущерба для релиза увеличить сроки и начать учить. Новый специалист - это даже бОльшая создаваемая ценность чем "улучшение". Кодирование, тестирование, заготовки доки, faq, релиз/итерации/задачи - все должно сразу делаться с таким же качеством, как это делаю я. Можно медленнее. На простых задачах это вполне по силам с самого старта. Даже можно ошибаться и не знать - есть наставник, который должен держать качество отдач как свое и должен держать баланс между обучением и сроками, между сложностью задач и знаниями новичка, между "молодец" и "ща я покажу как надо было все делать".

После выпуска начинается этап сопровождения и контроля своих предсказаний ("тут все понятно"/"тут все просто"/"у меня работает"/"640 килобайт хватит всем"), коррекция материалов для сотрудников сопровождения, улучшение FAQ, добавление выявленных ограничений/забытых недоделок в доку, исправление новых найденных ошибок, фактическая личная работа с вопросами. Полученные знания должны анализироваться и давать обратную связь на предыдущие этапы: почему используется не по назначению, почему клиенты не понимают как использовать, почему натыкаются на грабли, откуда такой трафик вопросов и ошибок, что забыли в доке, почему не покупают. Делаются изменения в проделанной работе и в своей голове. Публикуется результат. goto 1. 

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

Но по факту, это разница может восприниматься как "ахез" или "ну вот подняли зп", хотя в головах должна быть явная дистанция, понятная на каждом уровне "профессионализма" с четким видением "да, я понимаю, что я делаю аналогичные задачи в 4 раза медленнее чем Вася для получения того же качества, в областях NNN я вообще не разбираюсь, а заниматься задачами YYY по проекту я просто не успеваю (своих задач хватает на весь день). поэтому моя работа соответствует маленькой зп".

О конкретных ориентирах можно договориться. Можно не использовать в ориентирах слова "хуже" и "лучше" - все должно делаться на одинаковом уровне качества, очень высоком. Можно сделать разницу только в "дольше" или "быстрее". За счет быстрее будет возможность заниматься новыми областями и задачами. За "быстрее" в ущерб качеству можно вылететь из команды. Так же как и за "долго" на простых задачах. Обучение - такая же работа как и написание кода. Что бы делать ее так же хорошо как программы, надо так же хорошо разбираться и в работе сотрудников.

ЗЫ

Это не готовый рецепт. Претензии не принимаются. Ищите моск.