Showing posts with label Team Management. Show all posts
Showing posts with label Team Management. Show all posts

Sunday, May 24, 2009

Programmer Is Not Just a Coder

When I first got into the programming field, I heard the debate on whether programming is an art or science. For my understanding, the debate ended (at least in my mind) with the consensus that it is both. So when I got my master degree of arts in computer science, I was very happy about the name.

But over the years, I have heard enormous times that people consider programming a routine work. Instead of "programmers", they were then called "coders", which implies that you are just writing code, with everything else stripped from you: requirement, design, testing, deployment, etc., as if those are other (more important) people's business. Also, programming, in the minds of some people, becomes a labor-intensive low level, low tech work.

There are many problems in this thinking, but the single most fundamental error in this is the view of "coder". A program cannot be finished without the programmer considering each and every phase in the programs' life cycle. Yes, the programmer may not actually perform those tasks, such as requirement gathering, architectural design, testing, deployment, but these elements must be embedded in the program itself before it can achieve the intended result. This requires active involvement on the programmer's side. This leads to the understanding of how the cognitive processes works for programmer to acquire the knowledge in the development processes as a whole; not only the knowledge of how to do general design, etc., but the knowledge of what have been done or need to be done.  These are a set of complicated processes. 

One of the most important and useful tool to ensure the success in this kind of cognitive processes is empowerment. So instead of calling them coders, we need to encourage them to participate in all areas of activities in software development.  Recent Studies has shown that without empowerment, people simply lost their ability to get ahead of the game.  This study shows, according to this web page, that,

Executive functions help people maintain and pursue their goals in difficult, distracting situations. The researchers found that lacking power impaired people’s ability to keep track of ever-changing information, to parse out irrelevant information, and to successfully plan ahead to achieve their goals.

In our context, executive functions are ability to handle issues coming up from those phases in software development life cycles; those are truly difficult and distracting situations.

So the programmers deserve the respect and empowerment from the management in order to do their work. If you are thinking about trying to get your software development project done, please empower your programmers.

On other token, however, the programmer themselves will have to recognize this as well. You are much more important than who you think you are!

Friday, January 23, 2009

敏捷项目中的团队管理

当我管理一个开发团队的时候,其中一个头痛的问题就是如何度量团队中个人的表现,以便在年底公司正式的Performance Review时能够公平地对员工作出评价,这对公司,经理和员工都是一个很实际的问题,与员工的经济与职业前途都密切相关。

虽说软件开发是属于创造性的行业,但其中还是有不少体力活的成分在里面,不是人人都那么争先恐后地去干的。于是我们挖空心思地去找一些可测量的参数用以衡量这个劳动强度,但可找到的不多,能找出来的有点也很难量化。比如,各程序员解决Defects的个数。在实践中,如果你的团队中有一个人能持之以恒地解决比其他人多的Defects,你心里知道他的表现是最好的,你也很愿意年终评定时给他高奖金和升工资,但作为一种机制,你不能够很科学地说Defects的个数是一个绝对的参数,也就是,你不能在年初就跟你的下属员工说,你们中解决Defects最多的人就是最好的,到年底肯定会升职长工资。最简单的理由就是Defect的复杂程度各有不同,很难将其归一化。

其实用什么参数才是最好可能并没有一个肯定的答案。选择和判断最佳表现其实也是一个“可能性的艺术”,是在动态中根据情况决定的。因此,在敏捷 实践中,对员工的评价也应该是化整为零,在每个Sprint中对员工的表现作出评价,以各个领域内积分的形式,使员工自己知道自己的客观表现。如果认为这些参数不能充分反应,员工也有机会及时向领导反映,而做领导的,也可以马上根据实际情况对记分进行加权修改,在第一时间解决问题,而不是留到年底再来慢慢回忆。