KS系统总结

重构KS系统接近尾声了，写这篇文章，总结一下这次项目中的得失。

 

一、缺有经验，强势，并且有人脉的项目经理

 

我们的项目前期之所以陷入一滩烂泥，我认为主要是出在项目经理身上，没有贬低人的意思，就事说事。由于人员紧缺，项目经理承担了过多地任务，既要做需求，又要做设计，导致开发人员在那干等着，啥事干不了。如果有丰富经验地项目经理绝不会犯这种错误。

 

之所以说到强势，不仅是说对下属地强势，而且是排除掉那些对项目不利地影响。有拍板地魄力，敢于承担责任，杜绝互相扯皮，不能让其他部门或者事情影响了项目地顺利进行。拍板是需要支撑地，必须有人支撑，领导也好，同事也好，良好地人脉是必须的。如果项目经理权力很弱，复杂的人际关系和复杂的级别关系直接会干涉到一线的程序人员，项目很难成功或者说出色的成功。

 

这样的项目经理不好找，一般都是在一线战斗过，跌爬滚打慢慢熬出来的：干过码农，搞过需求，做过设计，斗过测试，哄过领导。

缺啊，所以一个这样的项目经理的离职，代价是惨重的。招聘这么一个人，或者培养这么一个人不容易。

 

二、设计人员不好做啊！

 

设计人员的重要性自不必多说，设计人员真的不好做。我们在开发过程遇到问题，基本都要找设计。设计人员既要回答我们的业务问题，还有帮助我们理清实现思路，例如牵扯到那些模块，涉及那些表，哪些字段。比较严谨地系统，开发人员的自由度是很小的，框得死死地，开发人员不得不问个没完，文档可以解决一定问题，但绝不是全部。所以需要涉及人员既要对业务非常了解，又要设计合理的数据库，合理程序架构。哪个环节都必须清清楚楚，明明白白，不能被开发人员一问一个蒙。如果项目中没有这么一个人，开发人员将面临无尽地返工，工期自然不断拖延。

 

 

三、需求、设计、开发、测试并行 or 需求->设计->开发->测试顺序进行 ？

 

马上就要完工的KS系统，我们是采用边设计边开发的方式完成的。需求，设计，开发，测试顺序进行，至今我参加的项目，没有一个是这么一条线顺序走下来的。基本都是并行进行。

 

前面文章也提到过，我们做的项目前期调研做需求做了很长时间，迟迟没有着手开发，总是希望把需求做的特别详尽，恨不得做好一次就不用改了，可是总是不能调研完，项目时间在无限制地延长，直到大boss发火说，你们别调研了，再调研黄花菜都凉了。这才着手开发，开发的过程中又发现，很多需求设计并不全面，根本无法实现，根本不符合实际。其实，我们是不可能把需求完美到一次成型的。在开发过程中完善需求，完善设计是不可避免的。个人觉得，对于比较大的项目，还是采用原型开发，经过几次迭代使系统趋于完美比较好，或者采用先完成系统的核心功能，让系统跑起来，再去完善边边角角的方式。说来说去，无非是选择软件生存期模型的问题，这个主要靠个人积累，也靠公司积累。

 

 

四、盲目接受新功能，危险！

 

这次KS系统，就一而再再而三地延期，说明什么？对工期计算不正确，估计太乐观。接到一个项目，预估工期一定要保守，必须多算20％左右的工期。千万不能乐观，对待客户，不能人家说什么就是什么。如果工期没把握好，那年你就等着自己加班吧。工作毕竟不是自己编程娱乐，如果没有按时完成，那可是要追究责任的。工期这方面，关系再好，都不能退让，一旦你退让，太好说话，那么你就等着被无尽的压榨吧。

 

有时项目经理拿过来的需求，一定要仔细分析是否可以实现，以及实际此功能对其它模块有多大的影响，因为作为项目经理一般情况下只要客户说要的，他们就会答应给，就好比销售人员一样，所以这个需要开发部门接手时严格把关，否则最终的恶果还是开发人员来吃，因为这个因是开发部自己没有把关而种下的，另外，帮项目经理清场的往往也是开发人员，所以必须严格把控；需求若不变化，不符合21世纪的特色，也不符合中国的特色，这点本没有问题，但问题是不能盲目接受，要把控好哪些可以这次一起变，哪些是需要下次才能变的，否则会影响项目的整体进度，小项目上线晚一两天可能无所谓，但大项目上线晚一天都是要死人的，这个责任不是客户或公司能承受的起的，同时这样也会影响到公司的声誉，基于这样某些需求的变更放到二期或三期开发客户是可以理解的。

 

四、应该有所积累=杜绝重复劳动

 

KS系统重构，基本等于重新开发，从0开始，原来的东西能用得很少，为什么？没有好好总结和提炼，设计的时候不够认真。像权限管理，这个东西本身就是各个系统大同小异的，没有必要每次做项目都重新开发，像数据表格，分页等等，这些都是死的，里面东西是活的，完全可以封成控件，省的每次敲来敲去，贴来贴去的。

这是说的技术，想一些行业公司，比方说做医院管理系统的，做了那么多年，难道接到一个医院的项目，还从零开始开发吗？肯定不是。无论是个人，还是公司，在工作中要好好总结，认真积累，杜绝重复劳动。