?

Log in

No account? Create an account

psilonsk


Блог об управлении проектами


Previous Entry Share Next Entry
Заметки на бегу: о важных критериях оценки программистов
psilonsk


Как оценить эффективность (брррррр) программиста, какие его качества важны для успеха проекта и, главное, как на них должен влиять менеджер?

Я могу выделить восемь ключевых качеств, позволяющих оценить программиста.

С1.Умение понять задачу - способность программиста получить на вход требование и на выходе продемонстрировать понимание того, как он это требование будет реализовывать.
Задача менеджера: обеспечить поступление качественных требований.

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

С3. Способность задавать вопросы (при разумном уровне самостоятельности) - программист должен коммуницировать с коллегами, не стесняясь и не боясь спрашивать их совета по сложным для него вопросам.
Задача менеджера: поддерживать в команде культуру общения, поощрять обсуждение задач разных типов.

С4. Умение писать качественный код. Это, пожалуй, самый сложный критерий. Если вкратце, то чем меньше критических ошибок допускает программист, тем лучше. ) При этом требования должны быть выполнены, а необходимые тесты пройдены успешно.
Задача менеджера: давать программисту возможность учиться и решать все более сложные задачи, приобретая необходимый опыт.

С5. Умение программиста оперировать сложными абстракциями.
Обычные люди оперируют конкретными понятиями и простыми абстракциями, поэтому могут решать только простые, очень конкретные задачи. Продвинутые люди умеют абстрагироваться от несущественного и видеть суть проблемы. Для них (до определенных разумных пределов) не важен ни инструмент, ни алгоритмы решения, ни технологические особенности. Поэтому они умеют решать задачи быстрее и дешевле, а их решения эстетически прекрасны.
Задача менеджера: давать программисту соответствующие задачи и контролировать успешность результата.

С6. Умение программиста разбираться в чужом коде - часто приходится заниматься развитием и поддержкой того, что написано другими.
Задача менеджера: давать программисту соответствующие задачи
и контролировать успешность результата.

C7. Мнение коллег о программисте как о специалисте. Это своего рода page rank - показатель, позволяющий ранжировать программистов в команде и за ее пределами. Если много программистов считают коллегу хорошим спецом - это прекрасно его характеризует (особенно при прочих высоких показателях).
Задача менеджера: не забыть интересоваться этим вопросом.

С8. Стабильность мотивированности - не так плох уставший и разочаровавшийся в работе и задачах программист, как плохо, если он в таком состоянии длительное время.
Задача менеджера: быть менеджером. )

Что добавить можете?



promo psilonsk february 12, 2015 18:07 17
Buy for 100 tokens
Ранее в сериале: История первая: договор Ариадны История вторая: лыжи, смоктульки и чаевые История третья: мертвец и розетка ​*** — Послушай, Леша, послушай меня, милый мой друг. Ты же менеджер проектов, так? Ты же не дебил, правильно? Я тебе на пальцах объясняю, а ты понять не можешь.…

  • 1
Не забывать (не лениться) документировать код, хотя это должно входить в С4.

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

Мне кажется для любой функции нужны комменты. Если это геттер/сеттер можно просто пихать комменты под копирку.

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

Но вообще, не только ф-ции надо описывать, а именно что ВНУТРИ нее происходит. Ибо бывают далеко нетривиальные решения, и на распутывание мысли написавшего уходит дофига времени. Не говоря уже про write-only код, который распутыванию без автора подлежит менее чем никак (в плане то распутать можно, но быстрее просто зная что подается на вход и идет на выход - смастрячить свой вариант, иногда тоже такой же write-only. Наблюдал как то в свое время файлик с 6 (!!!) вариантами одного и того же участка ф-ции, который каждый следующий прогер переписывал в том же режиме как и предыдущий (ессно, комментами закрывая предыдущий код, а не удаляя), ну собсно я седьмой написал. Вполне вероятно, что он там уже до 15-16 итерации такой дошел :). Там адовый кусок конвейера 3д движка по сортировке объектов был... Он сам по себе весьма мутный, но зато шустрый, блин.

это была кратка история появления распрыжки в кутри

Ахахах )))) Шикарно :)

ЗЫ. Если честно, то это еще ничо. Вот в думе, там Кармак по жести писал. Кутри уже приличный был свиду. Более-менее. Хотя с его закидонами тоже :)

Edited at 2016-07-07 12:02 pm (UTC)

  • 1