Ask the GeezersManagement Q & A |
|
Thursday Jan 11, 2007
Productivity Measurement @ Software Engineering
Question: I don't see how we are measuring individual's productivity in the software engineering field (for different functional roles). If we don't have a good way to measure an individual/team's productivity, how do we measure the manager's performance? Sin-Yaw: It is a matter of fact that "productivity" in software is ill-defined and hard to measure. For both individual contributors and managers, we measure two things: skills and results. Skills are further divided into soft and hard ones, while definitions for results are usually pretty straight-forward. To understand your own performance, ask yourself what skills you have better than others? Do you deliver more, better, and faster? Then take the answers to these questions to you boss. Amiram: Gaps exist between theory and reality. What we are supposed to do and what we actually do could be different. We, managers, are supposed to set goals, challenging but realistic, to each developer individually and for teams. We are supposed to follow progress, report, adjust plans, and take corrective actions when necessary. When goals are accomplished, expectations are met, and performance is measured. When goals are met earlier, with better than expected quality - we have outstanding performance. When goals are not met, expectations are not met, and poor performance is observed and recorded. As I said, sometimes this process is not followed, which makes it harder to determine the individual's and the team's performance. Mike: Sun in general is not measuring productivity by any formula. We are more or less using a subjective measure here at Sun. That is to deliver often and deliver significant things often. You might still get recognition if you work on something for an extended period and come out with a more than significant result, but you can get challenged because you don't prove to people that you CAN deliver regular significant results. One thing to note is that funding at Sun is planned on quarterly basis. The way it operates is somehow similar to how investment banker practices. Investment bankers choose to put money on enterprises that have a return-on-investment quicker than others, and stop investment on the ones that have a longer turn around time. At Sun, if a group has reputation for delivering significant things in a way that doesn't cause a lot of problems (regarding quality, service etc), that group is more likely to get funding in the future. On the other hand, the groups with bad reputation will have more limitations in their operations than others. The group that has the worst reputation that I know of was not even allowed to review their own code. So at Sun you build up your reputation if you are productive by delivering good things fast. There are some more arbitrary measures other companies use like how many lines of code one writes, how many function points (a given purpose/idea) one has. We don't do that at Sun. Some numbers we can examine would be: the amount of work (ie number of files changed), number of bugs resulting from the code and number of hours spent. The point to think about the "number of bugs" is not to confuse "productivity" with "negative productivity". If you cause trouble that take others' significant effort to correct, you won't be considered productive even if you stay up all night yourself on the job. People that are truly productive very often have time to help other people. Productive people not only produce a lot themselves, but are also able to help others produce and share ideas. So one of the main things for a manager is to create an environment where people can be productive. It should also be an environment that people know where to ask help to produce. Posted at 09:03AM Jan 11, 2007 by Wen Michelle Lei in General | Comments[0] Comments:
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||