《网站做的好与坏要用户说了算》之计划变更原则

计划赶不上变化，这个世界上唯一不变的就是变化，这个是很重要的哲学思想。是被绝大多数人认为正确的道理。再完美的计划，在执行的过程中总会出现这样或者那样的问题，就需要不断的进行调整。但调整的原则往往是：如果战略不能变（研发目标及时间期限），战术（开发模式及方法）可以根据实际情况灵活转变。

战术转变的指导思想应该是，时时刻刻以最终用户能否稳定便捷的使用我们的产品为指导思想。将软件项目中最核心、最重要的流程做好、做稳定、做便捷是关键，要知道评定产品好坏的评委是这些用户，而不是项目经理或者是程序员甚或是公司高层。开发方法上可以适时调整选用最简单、最便捷的方法实现项目目标。什么阶段的目标，在综合分析了自身资源、时间、成本等多个开发要素的前提下做出最适合当前的解决方案是根本的指导原则，QQ不是从开始建立的第一天就那么强大的。不管是CMM还是RUP最终仅仅只能是项目管理思想的一种表现形式，关键的问题不在死抠流程，而是要熟悉管理思想。只要能够打胜仗（让使用者满意），不管你是使用CMM、RUP正规军的管理方法，还是使用诸如XP甚或其他的土八路的管理模式。黑猫白猫抓到老鼠都是好猫。在项目攻坚战中合理使用迂回战略，能打的时候集中兵力去打，打不下来的需要改变一下战术再打，关键是能够完成任务（让用户满意），而是否能够完成任务，不是程序员及项目经理说了算，而是最终的用户说了算。用户本身是最终的使用者，得到用户的肯定的项目是好项目、是好产品。一个能够创造用户价值的产品才是一个好的产品。一个不能被使用者认可的产品，在高水平的开发者都是需要反思自己的价值的。

软件底层做的再好，用户使用层面上体验差、甚或不能完成用户基本目标，或是完成起来非常费力，最终产品都会被评定为“不理想”的产品，用户不仅仅否定的是产品，也会否定你的公司及你的团队，这个损失是无法弥补的。而暂时因为为了满足用户需要，而采取的紧急预案，虽然一定程度上打乱了“系统架构”，但与上面提到的损失相比就变的可以接受的多了（但最根本的还是做好预防工作，避免风险的发生，及早扼杀在摇篮里）。那这是不是说软件底层架构不重要呢。当然不是！软件底层的拓展性是否强、耦合度是否松散、是否能够在此基础上进行各种业务的拓展，这点非常重要。但如果在固定的时间和成本下，如果要控制好项目的质量，那么有的时候是需要损失一下系统的灵活及拓展性的，因为以后你还有机会迭代，惹火了用户，用户根本就不会给你补偿的机会，而是断绝和你的交往。请认清这一点。有的时候鱼和熊掌是很难兼得的，这个就需要看用户到底是喜欢吃鱼还是喜欢吃熊掌了。

那是不是损失了灵活性，满足了用户的需求就算完事了呢。当然不是！重要的是要将这块的内容记录下来，纳入下步重构及迭代的计划中去。而且项目经理需要制定一个专门管理这种事件的流程。确保将耦合度比较紧的代码纳入到下步的迭代工作中去。

一个软件项目的开发是无止境的，总有很多很多完善的空间和余地，但不论怎么去做，要知道我们的目标是什么，用户的需求是什么。让使用者能够轻松完成既定需求，同时又能给使用者一个很好的体验这个是关键。往往很多的项目失败是没有清楚的搞清楚哪些才是真正的用户。程序员往往有一种对新技术的眷恋，喜欢用最新的技术来完成某项工作，希望在项目的开发中能够借助控件的魔力做出更加绚丽的功能、也可以学到一些新的知识。当然任何的项目经理都不会排斥使用新技术、新方法，但这确实在很大程度上给项目带来了诸多不可预测的风险。这点需要进行权衡，需要在合适的时间、合适的进度中予以适度的调整。对于研发部门的管理人员尤其需要注重对项目小组的知识技能培训及培训效果考核，一项新的技术在没有被很好的培训掌握后，冒然的推出出来，只会增加项目的诸多不确定因素。如果作为项目经理的你已经采用了“不成熟的新技术”并为此付出了相当代价，需要调整系统开发模式的时候，请记住任何打乱系统设计架构的开发方式都应该在后续的工作中被重构或迭代。

笔者坚持项目经理应从多个角度做好项目的计划工作，既要做好WBS及责任矩阵分解后的项目计划、资源计划、财务计划、质量控制计划，更要做好风险管理计划、验收计划、项目的沟通计划、阶段性评审计划等。笔者的经验是计划的执行过程中，不论是质量控制、沟通、阶段性评审、验收、风险管理等都需要有一个标准的流程与之相配合，而这个标准的流程是在团队中不断改进的过程中逐渐形成的，而不是照搬照抄拿过来的。确定好项目的里程碑及各种可能出现风险的识别因子，做好风险的应急事件处理方案，并定期演习演练，让大家明确发生问题了以后应该找谁，应该按照什么标准原则及方法去处理。所以当项目出现风险的时候总会被暴露在相关的流程中，项目经理在对其进行及时的调整。调整的指导思想是“关注用户的需求，网站做的好与坏最终是用户说了算，用最简单的方法，解决最复杂的问题”。所有上述的内容都是为了说明应让问题及早的暴露出来，而不是等到最后项目快交付的时候，告诉上层或者用户，在指定的时间内完成不了任务，任务需要延期完成。（这个尽量少说，少做。因为你失去的不仅仅是团队的信任，更重要的是失去上层的信任及用户的信任），不要轻易的答应别人，但经过慎重思考后答应了以后就一定要完成。

笔者提倡建立标准化的研发流程，在这个流程中能够将项目中可能出现的问题及时的发现。而建立流程的一个最便捷的方法就是不断去分析自己团队出现的种种问题。给予重视，在第一时间给予解决和处理，一定不可以拖拉，并及时制定相关规范，谨防再次出现同样的错误。在流程中要求项目小组的成员及时将项目开发中遇到的种种问题进行反馈，将一线遇到的问题能够及时的呈上。予以解决，必要时刻启动应急处理流程。没有应急处理流程的应根据事件的特征，开始制定相关的流程与标准，确保同类事件不再发生。

一个优秀的项目经理一定是具有高度责任心的项目经理、拥有极强的对项目负责的态度以及踏实认真、注重细节、关心用户需求的项目经理。俗话说：“细节决定成败”。关注影响用户使用的细节，踏踏实实做好每一个功能点，让团队认真负责为用户创造价值的做事态度在产品上得以体验，才能做到团队满意、上层满意、用户满意的三赢结果。

 载自：http://hi.baidu.com/olquan/blog/item/6dfd0a14ee34c7f2c3ce79ca.html