软件开发项目的几种头痛：
1、需求不稳定性！！（头号头痛杀手）
客户需求非常不稳定，客户调研方法也导致获取需求的有效性，准确性，但是仍然有相对稳定的需求，按照哲学理论，运动是绝对的，静止是相对的，相对于某一个客户的某一个阶段，这些需求是稳定的，特别是靠近现阶段的需求，最容易把握，所以，尽可能的缩短研发周期是避免需求变更的一个很有效的方法。一般一个研发周期不超过2个月，最好在一个月完成一个敏捷周期（比较困难哟~~）。
缺点：对于比较大的项目，如果没有良好得总体把握（业务框架和技术框架），很可能会增加重构的工作量，甚至从头再来！（双面刃的选择！）。或许：整体规划，分步实施可以缓解该缺点，但是在没有把握充分信息的项目初期，难度好大（行业专家和技术专家的整合团队做起来就容易许多~~）？？
所以，我们需要“短周期”，但是对于大型项目，好像不太适用~~
2、知识更新换代非常快！！
对于技术的高速更新，在项目的技术选型中也很费思量，原则上：适用就是好，或许这个技术并不先进，但是能很好的解决问题，就好像使用手机，我作为一个普通人（非商业人士），仅仅需要它良好的通话功能就可以了，至于那些上网功能，移动办公，游戏什么的，好像很优先，但是我会选择一个很普通的手机---有良好的通话功能，这就是使用了以上原则：适用就是好。
另一方面，技术的领先本身也有其竞争力（有人会说：客户才不管你用什么技术呢，只要能很好的满足需求就OK，其实不然，如果你卖给客户5年以前生产的手机，他会要吗？当然，除非你送给他。恐怕你也不会傻到做这样的买卖），对实现相同功能相同价位的WEB系统和桌面系统，哪一个系统对客户更有吸引力，我不说你也知道，但这个假设条件往往不成立，WEB系统开发成本相对高，所以他的价位也会适当上浮。
这一段好象不是我的主题哟！~~~
短周期也可以降低项目技术选型的难度。
间接推导出“短周期”
3、人员流动率高！！
软件研发团队，由于外界的原因（诱惑太多）和内部原因（缺乏管理方法，没有凝聚力），团队呈非稳定结构，人员流动是不得不面对的问题，改善这种状况的主要做法还是科学的管理方法和有吸引力的企业文化/前景等等。。。，不过短周期也可以很好的避免人员的流动，如果在2个月以内都无法确定其稳定性的人员，你作为项目经理，可能也不会考虑使用，但是时间长了（比如半年），变数就多了，所谓夜长梦多，常理也。
另一方面，短周期的项目一般能很快看到成果（一系列的小版本的诞生），可以让团队持续有成就感，有成就感在马斯洛的需求层次中可是最高层。所以能持续的有这种感觉，研发团队也就自然有了相当的凝聚力，这不就是团队建设想要的吗？但是也会有失败，那有什么关系，失败是成功的妈妈 J
可以推导出“短周期”，“小版本”。
对于小版本的说明：一个软件项目的规模大小是客户决定的，从总体项目上说，我们必须完成合同上的所有特性，但是在项目管理上，为了回避/减低风险，尊重项目的迭代式清晰的特点，所以可以把项目分成若干个小版本，迭代式完成之。
4、沟通不易：思维性的作品！！
沟通不容易：因为软件产品是思维的结晶，思维是最变化莫测的，这时我有一个很得意的想法，到了晚上，突然又有一个很有创意的解决方法，我会本能的把精力转移到新方法上去。。。思维就是这样很随意，不可预测的。一个人尚且如此，一个团队会怎样，一个团队很长一段时间又会怎样，可变性真的很难把握（正是因为思维的无穷创造力，才会让产品越来越优秀和好用）。团队中每一个人的想法都很重要，但是要做到团队无死角的沟通，几乎不可能（我提出了极限沟通的概念。J ）。从风险管理角度，我们可以改变做法来减低风险的影响，小版本就是一种方法，小版本中不会涉及太多特性，就那么几个或者更多一点（两个月，多了也没法做~~），复杂性/难度就低很多，沟通最不容易的是复杂/难的东西，对于没有太多特性的一个小版本，沟通起来就减低了好多障碍。小团队也是另一个解决方法，团队人数膨胀是沟通的大敌，精锐小分队（不超过10人，最好5~7人）控制了沟通路径的膨胀，同时也能做到角色分工配合，高效率的推进项目。
所以我们需要“小团队”“短周期”“小版本”。
小结：
根据软件开发过程的特性和以上推导，对于规模不大（中，小）的项目，使用“小团队，短周期，小版本”可以提高软件开发成功率。
|
|
|
|
|
|
|
您的位置：
