Derrick és Harry Projektmenedzsment Blogja

A napi nyolc óra rabsága

Facebook Tumblr Tweet Pinterest Tetszik
0
2014. április 03. - TanacsLajos

8ora5.jpgÚj cikkel jelentkezünk a Bitport-on, melyben a napi nyolc órás munkaidő visszásságait boncolgatjuk. A cikk itt olvasható, jó szórakozást hozzá! :)

1 komment

Ajánlott bejegyzések:

A bejegyzés trackback címe:

https://derrickesharry.blog.hu/api/trackback/id/tr235891588

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

Rakonczai Zoltán 2014.04.03. 21:39:55

Ez mind szép és jó, részben egyet is értek. A "mit tegyünk hát" részben leírtakat azonban kiegészíteném.

Egyrészt teljesítményt mérni kell valahogy.

Méghozzá azért
- hogy tudd kommunikálni a embereknek, hogy mi az elvárás
- hogy tudj visszajelzást adni az embereknek, hogy ki az, aki jól teljesít és ki az akinél változtatásra van szükség
- hogy akin jól akar teljesíteni, annak pontos segítséget tudja adni, hogy tudja, hogy miben kell változtatnia, hogy ő is jól teljesítsen

Másrészt szerintem a cikkben leírt dolgoknál pontosabban kell visszajelzést adni.

Hogyan mérjük pl. egy programozó teljesítményét? Jelenleg objektív mérőszám nincs. Ezért próbáljunk olyan dolgokat mérni, ami a tapasztalatunk szerint összefüggésben van a teljesítménnyel.

Itt van pl egy jó cikk arról, hogy milyen "mérőszámokkal" lehet próbálkozni (nyilván más területeken is lehet hasonló "mérőszámokat" készíteni):
www.nickhodges.com/post/Measuring-Developer-Productivity.aspx

Kimásolok pár dolgot ide, de érdemes elolvasni az egész cikket:

"
A Modest Proposal

So yeah, what I am proposing is a way to measure developer productivity and value via a subjective set of measurements. Think of it as a way to qualify the notion of "you just know that Jason is productive".

Here is the list:

Productivity
Does the developer get a reasonable amount of work done in a given period of time?
Is the developer's velocity on bug fixing sufficient?

Engagement
Is the developer dedicated to his/her craft?
Is the developer committed to delivering software on time?
Is the developer dedicated to company success?
Attention to Quality
To what degree does the developer's code work as designed?
Does the developer thoroughly test code and believe it to be correct before checking it in?
Do a minimal number of bugs get reported against his/her code?
Does the developer write unit tests for all new code?
Does the developer follow the Boy Scout Rule and leave a module cleaner than it was before he or she worked on it?
Code Base Knowledge and Management
To what degree does the developer understand the code base assigned to him/her?
Does the developer take responsibility for his/her team's code base, improving it at every opportunity?
Adherence to coding guidelines and techniques
Does developer's code routinely meet coding standards?
Do code reviews reveal a minimum of problems and discrepancies?
Does the developer use Dependency Injection to ensure decoupled code?
Learning and Skills
Is the developer constantly learning and improving his/her skills?
Does the developer show a passion for the craft of software development?
Personal Responsibility
Does the developer first assume that the error lies within his or her code?
Does the developer understand that he or she is solely responsible for their code working correctly?
Does the developer take pride in their code, ensuring it is clean, tested, easy to read, and easy to maintain?

Again, these seven items are all subjective measurements. All the questions require the evaluator to make subjective judgments. But a good lead/manager is presumably in their position because of their good judgment about such things, and so they should be able to make fair and accurate assessments about Jason's productivity using these "measurements".

Most of the questions ask for a yes or no answer, but all can spark a discussion with management or even the developer being evaluated. You could use these measures on a formal evaluation form. Whatever you do with them, it's probably better than the "just know it when I see it" approach you are probably taking now.
Conclusion

In the end, any evaluation, judgement, or other assessment of the productivity or value of a single developer will be subjective. No one has yet found an objective way to measure individual productivity in our excessively complex profession. But I am saying that it is possible to qualify and make judgments about a specific set of criteria as a small and humble step towards being able to do the thing that our industry has so far found very difficult.

My suggestion is that we accept reality and embrace the subjectivity -- and lack of objectivity -- in measuring developer performance."
Válasz erre 
süti beállítások módosítása