项目管理经验分享
项目管理经验分享
今年的高项又弃考了，真的没时间看书，安慰一下自己：考过了并不代表什么！就是平时吹水时声音可以大点，没证的只有点头说是的份。平时也接触过不少有证书的同事，高项，PMP，管理水平真的一般般。对软件公司的来，项目管理水平对公司的业绩有着直接的影响。凡是没意识到这点的人，说明他对项目管理的认识还不够，死记硬背一些理论是没用的，还快也会忘记，要真的理解这些理论在管理过程中的意义所在才是最重要的，快速交付才是硬道理。下面谈谈项目中实际工作中遇到的一些与项目管理相关的问题。
项目章程
项目经理一定要有一份这样的东西去把握某个项目的总体的关键信息。有利于工作开展时，任务安排的轻重缓急。项目干系人的识别：在功能设计时，如果某些功能跟重要的干系人有关系的话，如领导所操作的页面，还有统计报表，这些功能一定要设计好点。搞好点，领导很有可能把你们产品推荐给其他同行。一传十，十传百。一些后台操作不是很频繁的功能，可以随便点就行了。业务谁说了算，做需求时就听取多点。 接过很多项目好像都没有这份东西。
质量规划：
记得第一次去做需求时，就遇到这样的问题了，当时使用的原型法，画了一些简单的页面给客户确认，原型列表和功能的数据是随便写的。发给了客户确认。不知道客户看还是没看，当时的情况有点特殊，又不好让客户签名，他们就说看了，大概是这样，先做看看先吧。我看功能页面都很简单，需求也不是很复杂，就开始做了，花了两个星期做出来了，给客户使用的时候，发现跟他们想要的有出入。幸亏他们不是说跟他们想要的完全不一样，又花了一个星期就修改。总花了三个星期。
吸取教训：以后做需求时，借鉴在上家公司的经验，画了原型出来的同时也把对用户的使用的理解制作用例测试，按角色使用场景制做，数据是用客户提供的真实数据，当场给客户讲解，刚开始客户有点不耐烦，有些客户听你讲需求理解的时候，你还没讲完他就说是了，这里时候必须跟他们讲这个环节的重要性。跟客户的合作久了之后，我对业务熟悉了之后，很多业务根本都不用这样需求确认了，去开完会回来就知道怎么做了。效率很高，这也是为什么软件项目一般二期才开始挣钱，如果你知道客户只做一期的项目（有些客户有开发团队），这种可以开高点价格。
失败经验：
后来在泛华的时候，看到大公司的调研团队跟我们公司做调研的时候，也犯了我第一次做需求时的错误。那时候他们来我们公司做需求调研，他们也只有制作完原型跟客户开会确认，确认时我也在场，只是按他们的理解对着原型讲。并没有使用测试用例去讲。在系统上线之后，我们公司的业务部门在使用系统的才发现很多功能和信息都不全，甚至有更加严重的缺失，流程无法走下去。我们公司在开发过程中又拼命的压缩时间，正大把这次合作看得很重，又豪无底线的答应。他们在开发过程测试过程中很明显发现了很多逻辑上的BUG，也不敢说出来，以为需求确认书上有人签名了就行了。按原型做完就算OK了。
**结果：
原型上的描述根本没有业务逻辑，就算有客户签名，客户验收时发现业务逻辑有问题，客户表示我不会验收的，你页面是长得跟需求确认时的一样，但没法工作，没有给我带来工作效率的提高，页面多漂亮都没用，要知道对于我们这种贷款公司，业务部门不能顺利放款，他们肯定的不会签收。多有道理。最后这个项目正大正式宣布失败走法律程序。
**失败原因：1项目管理水平差。2没有专业性（客户说什么就是什么）。3信息系统开发技术水平差，技术积累较少。
原型制做
一般软件公司的开发平台都有标准化的功能实现方式，在制做原型尽量按自己开发平台一样的实现设计，不要设计一些新的操作方式，有利于操作的标准化提前用户的用户体验。提高开发的效率。当然也会有些设计平台上是没有的，这时必须跟研发一起设计，怎么设计好实现又稳定，不是说客户怎么说就要怎么做。我们毕竟的专业的。原则是：1满足需求。2实现简单（都是为了挣钱）。
项目管理
成功的原因总是惊人的相似,失败的原因确各有不同。下面总结一下在之前公司的成功经验:
- 从需求确认:原型法+用例测试。
- 任务分解:所有开发人员开会，并对任务进行分解越细越好，一下用工具记下来，工具有：最简单用xls，project,scrumworks,或一些在线项目管理系统禅道之类。
- 任务安排:把所有的功能按一定的优先级排好，按开发人员的熟悉程度让开发领取任务，或按开发的意愿自行领取。完成时间他们自己估算。一个任务不能超过2-3天，
如果超过的话就要再分解。两周一个周期进行迭代。可以按用例测试来划分。如果两周要完成：用户注册的用例 - 开发实施：每天上班前面用10几分钟，汇报总结分享经验，如昨天做了什么，完成的程度，是否遇到困难，怎么处理的？有什么经验分享。明天做什么？同时更新任务表。如果有任务开展不合理的情况立刻调整。
- 进度跟踪（监控）：每天测试会对任务表中已经完成的任务进行测试。测试出BUG提到禅道之类的管理工具中，开发人员每天都会看禅道立刻修改。
- 内部验收：两周一次迭代，两一个小的历程测试。对过去两周的功能的测试用例进行测试。看看有没有跟用例的业务有出入。有的话及时调整再分解任务紧急处理。
- 外部验收:交付给客户试运行并验收。
