[[ blog 이사 과정에서 정확한 posting날짜가 분실됨. 년도와 분기 정도는 맞지 않을까? ]]
Let's consider a software project.
Usually, we have two general way to make up team.
1st : We may organize one team for each project. That is, one team for one project. And this team - actually, team lead if we should pick only one person - is fully responsible for the project.
2nd : one team for each features.(for example, WAP team, MMS team etc...)
We cannot tell which model is better (each model has it's own pros and cons.).
But, in terms of time-critical project, 1st model is better.
In the 1st model, issues detected during project development are definitly under project team's responsibility. So, we don't need to struggle for finding appropriate team to handle those issues. And this project team tends to be active to resolve those. (But, Several teams may suffer same issues with high possibility, because sharing know-how and accumulating knowleges about each feature is difficult)
But, in 2nd model, it is difficult and takes time to know which team should handle those - for this, usually lots of communication overhead is required. So, each feature team tends to be passive. And they want to avoid being assiged to issues, because they don't have responsibility to succeed this project. (But, in this case, each feature team can accumulate know-how about features and expect synergy from this because team becomes expert for the feature!)
We should take attention to main difference between 1st model and 2nd model. That is just "Is there any ONE person who are fully responsible for the project?".
So, we would better to mix up this two models. (ex. 1st model for SW maintenance and enhancement; 2nd one for making product.)
My point to succeed in time-critical-project (ex. making product), (based on my experience..) is,
* There should be only ONE person who are fully responsible for a project and he/she should have enough authority to manage this project. Responsibility of several people means "No one under responsibility".
Does it seems too simple and trivial? But, it is not easy to obey this rule efficiently.
'Essay > Software' 카테고리의 다른 글
[Essay] Test&Debugging Cycle과 Test Engineer의 role에 대한 단상... (0) | 2009.03.11 |
---|---|
[Dev] Clear description of outcome - submodule, subproject... (0) | 2009.02.15 |
[Prog] What is "good code"? (0) | 2008.11.22 |
[Prog] Trade offs (0) | 2008.05.12 |
[Prog] Avoid prematured exception handling... (0) | 2008.04.27 |