软件项目管理的常见问题
本文是《201 principles of software development》和《rapid development》关于项目管理部分的感悟。
一个产品或项目开发得很成功，你借鉴其方法确往往不会成功。但是别的项失败原因却值得我们认真分析和学习。
导致软件开发项目识别的因素主要来源于四个方面：人、管理、产品和技术。
一 与人相关的常见问题
1 团队成员没有充分的激励
2 团队人员的素质不行
3 团队中有害群之马
4 开发中塑造明星程序员，搞英雄主义。
5 项目延期了，还不断增加人力。
6 办公室吵闹混乱
7 程序员和客户在开发过程中逐渐有摩擦，有矛盾。
8 不切实际的项目规划
9 缺乏有力的高层项目支持
10 相关方没有利益投入，包括领导、团队负责人、成员、销售、客户等
11 缺少最终用户的参与
12 办公室政治，有的人关注搞高层关系；有的人关心搜集信息；有的人画地为牢，阻隔信息；有的人各个方面都干一点，其实等于没干。
13 一厢情愿的想法。例如，“大家都表示要加油干，虽然第一个项目节点就延期了，我相信他们会最终按时做好的。”
二 与管理相关的风险
1 过于乐观的时间规划。
2 没有管理好风险，有的风险没有意识到。麻痹大意往往导致大灾难。
3 外包出问题了。
4 没有好的规划。另外，随着项目的进行，没有经常评估进度，没有及时更新计划。
5 迫于应付眼前压力，完全放弃规划。
6 在项目开始前就浪费大量时间，如审批、建立管理流程等
7 前期工作太草率。有些时间紧的项目，需求分析，架构，设计等草草走过，觉得这些又不产生代码。从而导致问题。
8 设计不充分。
9 质量保证措施缺失。
10 管理措施缺失。没有详细计划，包括子任务依赖关系图、显示进度的甘特图、开发里程碑、文档及代码标准、人员分配等。
11 产品还没完全成熟稳定就要求收敛结案。
12 在项目评估的时候常常会漏掉一些不是很显眼的任务。
13 项目前面的节点延期了，重新规划到后期追赶上进度，往往失败。
14 代码混乱，糟糕失控。
三 与产品相关的风险
1 产品需求华而不实。例如产品对于性能会提出要求，要求往往过高，导致开发时间变长。
2 产品需求不断变化。项目做下来，发现最开始需求的25%都变了。
3 程序员开发华而不实的功能。程序员可能对一些新技术比较喜欢，从而开发一些华而不实的功能。
4 进度博弈。项目开发过程中，某个节点延迟了，经理重新安排了时间进度。这个场景可能让人认为以前的时间安排是有问题的，延期是正常的。类似的，后面也会延期。
5 开发中包含有探索研究任务。所有的规划都是对确定性任务的规划，如果项目需要超过目前业界最高水平，同时你
还面临人员素质问题、需求模糊、外包不稳定等其他问题，那么你的进度规划就非常不靠谱，可以扔掉了。
6 用户界面和体验太糟糕。
7 没有真正理解需求。
四 与技术相关的风险
1 详细技术银弹。期望某种技术可以解决目前的问题，如c++(30年前的高级技术)、面向对象等。这些方法救不了你的项目。
2 高估引入某种工具和方法带来的收益。市场上经常有这样的宣传，采用x工具或y语言或z方法，可以提高75%的生成率，这都是夸大宣传。
3 在项目开发中介切换工具链
4 没有使用对代码的版本控制工具
5 对软件技术发展太乐观。1984年，大公司都认为到98年时候的大部分软件将用Ada语言编写，c语言降到4%以下，54%的软件能够复用。到94年的时候，70%的软件将在知识库系统的帮助下进行开发。全部没实现。
6 重复使用的代码模块设计有问题。
总结
人的因素是决定项目成本的关键因素。
有试验证明，不同程序员的效率差距比至少可以达到10：1。
构建团队的原则：1 最出色的人； 2 工作经验匹配； 3 符合其职业发展； 4 团队平衡，需要互补和和谐； 5 尽快清除有问题的人。
另外，团队的规模要与项目规模相匹配。人员需要充分激励，否则可能就按部就班，每个人的激励点是不一样的。
在评估工作的时候，尽量非侵入式的获取评估数据，一旦你让别人有意上报某些数据，这会改变别人的行为，数据往往就是失真了。而且可能会降低团队合作度。
当你设定了KPI目标时，团队就会朝着这个方向努力。但可能造成别的目标重视不够。设置KPI目标要慎重。