项目开发心得1

刚刚工作不久，还没有开始从头到尾开发过一个项目，而是负责对一个开发到后期的项目进行维护和后期开发。本以为这些工作没有什么技术含量，比较枯燥，然而出我所料的是，经过两个多月的维护工作，却领会到了很多软件或项目开发领域中的学问，虽然这些东西的字眼和概念原来在大学的时候遇见过n多次，但是从来理解不了是怎么回事。
1.说说需求挖掘，定义和管理吧。我本来就是刚入行，觉得谈这些上流话题有点不自量力。不过在这里我倒也不打算去网上找些资料把有关需求的内容拿来啰嗦一顿，而是说说自己的体会，知识和经验都是慢慢体会和积累的嘛。这个项目负责开发的人不多，需求一直都是通过和客户之间电话会议来确定的，即客户那边有什么要求经过双方讨论确定再有开发人员实现，完了后再转给测试跑跑看有没有问题。这样一直快要到交付的前一个月，老板以为接下来的就是些简单活，就叫我这个新手去锻炼锻炼，顺便看看人家是怎么开发一个项目的。可是就这个时候，众多严重的问题出现了：因为系统即将要交付使用，客户多少会积极一点去试用。结果经常出现错误或者莫名其妙的故障。比如开发的时候当初压根就没有考虑到多用户的情况，所以整个系统的多个地方都只是以单个用户的方式来编写的，比如一个货品的数量在进入一个页面的时候就取出来缓存并显示，然后这个用户在这个页面上逗留了十来分钟，再对这个货品数量进行修改，如果只有一个用户在使用这个系统的话，数据永远都是一致的，没有问题。但是如果多用户的话，结果就可想而知了。这个项目的测试人员也只有一个，当然没有考虑到在多台机上试试系统运行情况。还有，对真正要试用该系统的用户的场景没有事先了解，所以开发人员照着惯用思维进行开发，结果当然是用户提出异议了。还有，在系统开发前期的时候，没有很好考察定义系统的平均或一般负载，性能要求之类的关键指标，即没有考虑到压力测试。用户那边系统后，发现到了快速大量输入数据时，系统会慢得不可使用。除了这些典型的问题之外，还有客户在快要交付前突然要大范围更改和添加需求，弄得我们手忙脚乱也完不成任务。具体情况就不在赘述了。这些经历给我的体会是：需求果然是很难作的，所以要花心思，动脑筋，甚至花体力去尽量做好（比如可以到客户公司去考察考察，呵呵，不知道这个想法实不实际，个人想法而已）。切记一种姿态就是，客户扔了一个需求过来，讨论讨论过了，然后动手，弄完叫客户大概看看，没事就OK了，而是要多Push客户那边多搞搞，不断跟进（好像客户大部分都不是很积极的，所以项目公司这边要积极和客户联络）。不然开发到后期出了前期没有发现的大问题再修改代价就很高了。

2.第二个体会，可以说就是“切肤之痛”吧。写代码比较辛苦吧，看代码好像也很辛苦，但是看一些几乎没有注释且比较乱的代码，并且这些代码还比较多，会不会很辛苦呢？答案是肯定的！大学时候学的一门课程，叫项目管理。那时候学那门课觉得简直就是浪费时间，很难领会到一些要工作后才能领会的知识，好像学来没用。比如书上说，开发一个项目，一般开发时间只占20%-30%，其余都是维护时间。出来工作后才发现维护时间还真的是很长，如果在这段时间里，一直都是由系统开发的那帮人来维护，到也罢，反正代码写的怎么样，他们自己看。但是万一项目的开发人员离职或者调到别的项目组从而原来的项目叫别人去维护的时候，就会发现优良的编码习惯是多么重要啊。我有时候实在觉得摸不透，就去问原来开发这个系统的人，结果有时候他看了之后自个也不知道怎么回事，还责怪我这样写是有问题的，还不时误会是我写的代码。我心里说，原来你刚不理它一个半月就都会不记得啊，呵呵。这些经历给我的启发就是：写代码的时候，想想以后。该写注释的地方，就算简短，加两句以后别人维护起来也省 了好多脑细胞去想那段代码到底是干啥的。

3.哎，太晚了，明天还要上班，有时间再加上。都是自个感受，写出来备个案。

评论

43 楼 alan3258 2008-09-24  

深有同感，知音呀！我们这里做的也和你那里一样需求每时每刻都在变化，我都快晕菜了

42 楼 liyun_1981 2008-09-20  

letitbe 写道

shewaer 写道

市场是主导，业务是根本，技术是手段

市场是主导，业务是根本——这两个原则几乎所有的公司都是这么认为的
技术是手段——大多数公司都认为技术是可有可无的东西，随便招几个人，加加班，就能搞定，中间的设计编码测试过程可以尽量压缩。

真好笑！乱扯谈！正确的理解应该是市场和业务是必要条件，而技术是充分条件，二者加起来才是充分必要条件！

41 楼 freedomstyle 2008-09-18  

     实际应用下，怎么能不考虑多用户同时操作的情况呢？？？

40 楼 feohoo 2008-09-18  

对付人不能像对付技术一样。任何的需求确定应该让客户签字画押，在需求的最后签订基础上，需求尽量不变化（但是这样的可能性比较小），所以呢，需求是致命的一步，开发的系统在一个公司做需求都两个月，还都是项目分析人员去干的。说的命名规范，更是有切肤之痛的感觉，在曾经年少时搞的一个东西，那时候做到后面是想晕，《需求说明书》《规范说明书》，《设计报告》，《实现说明书》，《更改报告》，《测试报告》，《项目结题报告》有必要写好

39 楼 fantasybei 2008-09-09  

superloafer 写道

谢谢kimmking的建议，一个公司开发团队确实非常需要规范，这样维护起来才能把花费的精力减少，也减少了错误隐患。反正我经过这次体会之后，是一定会渐渐养成一个好的开发习惯，尽力做到规范，因为以己推人，也不想自己开发的东西到时候被别人痛批。不过有时候说起来容易，真的要做起来也有难度，我想这时候就必须PM出面干预会比较实际吧。比如我看到国外有个公司写了一个通知，意思说不要在JSP页面写JAVA代码了，PM的通知大概是这样写的：
"No more java code in jsp, otherwise, you'll be gone tomorrow!"
这句话应该有点威慑力吧！治理公司和治理国家一样，要有怀柔策略，但不得已时，也要用一用强制力，呵呵！

kimmking的意思是说，楼主你把你发的文章的格式整理下，瀑布寒....

38 楼 letitbe 2008-09-07  

sklst 写道

开发人员没有负责做好手上的工作，留下维护人员来擦屁股，验收测试走过场到了实际使用就爆出一大堆问题，典型的项目管理混乱。

根源是公司不重视技术。
期望一个不重视技术的公司突然重视技术是不现实的，就像狗改不了吃屎。
所以走为上策。

37 楼 letitbe 2008-09-07  

shewaer 写道

市场是主导，业务是根本，技术是手段

市场是主导，业务是根本——这两个原则几乎所有的公司都是这么认为的
技术是手段——大多数公司都认为技术是可有可无的东西，随便招几个人，加加班，就能搞定，中间的设计编码测试过程可以尽量压缩。

36 楼 guooo 2008-09-07  

。。。 写道

把需求拿去给客户签字画押

35 楼 vzless 2008-09-06  

把需求拿去给客户签字画押
严重同意！老师上课就这样说的，你要添加新要求  那以后再说 这个就是版本1.0  新加就是新版本 以后再说

不过咱也得吧问题想清楚了 ，像这种问题好多就要考虑多线程了

34 楼 PlayGod1984 2008-09-06  

第一个问题我觉得项目经理应该考虑到，问题都是常识阿

33 楼 zhouyl203 2008-09-05  

。。。 写道

把需求拿去给客户签字画押

需求给客户签字是肯定的，但是如果在实施阶段，客户提出些小问题（如果工程大了话，很多小问题工作量就不少了，修改了之后还要测试等），这些问题不是bug也不是什么大的新需求，只是操作上方便、显示更好看等等（这些问题不要指望用户在签字的时候就都跟你提出来）。


这个时候你怎么办？也要求走需求变更？开玩笑！！

维护是一项很大工作量的事情！

项目管理流程是要按要求走的，但是死走是不行的，做事情还是有例外的！

32 楼 jdlsfl 2008-09-03  

沟通的重要性体现出来了

31 楼 xuyao 2008-09-03  

这个问题很复杂，总之需要尽量多和客户沟通，前期的成本花费一些比以后再改低的多。

30 楼 sklst 2008-09-02  

开发人员没有负责做好手上的工作，留下维护人员来擦屁股，验收测试走过场到了实际使用就爆出一大堆问题，典型的项目管理混乱。

29 楼 shewaer 2008-09-01  

市场是主导，业务是根本，技术是手段

28 楼 xx521 2008-08-31  

说的有道理 啊!现在需求需要可户确认啊~哈哈

27 楼 cuiyi.crazy 2008-08-30  

其实签字是一个很好的手段，如果理解成我签字了，所以客户提出了变更，我可以用白纸黑字来对抗----这个想法是很不对的。

但是实际上签字的实质确实为了对抗，但是这个对抗是一种柔性的东西，比如对于工期或者财务的进一步交涉的依赖，当然要适度。

总之一句话，尽量为自己争取到一份有利的保障，尽量让客户理解你。

26 楼 levis2000 2008-08-29  

superloafer 写道

我觉得所谓的画押好像用处不大，因为客户那边需求变化太正常了，今天他们觉得这样比较爽，明天开会的时候，他们又会说好像这样不行哦，得改。难道还总是跟他较劲说“你昨天还说是这样的啊，这么今天又说不行呢？”。如果作项目真是那么“静态”的话，那作需求有什么难度可言啊。我写这篇帖子其实也是有感而发，没想到还有这么多人讨论，自己又成长很多啦。个人觉得，对于刚入行的来说，除了只是关注代码编写之外，还要用心领悟代码开发中的一些“道”。这里所说的“道”，就是除了劈里啪啦能很快写代码之外，还要不断补充一些其他知识，比如设计模式啊，怎么样才能尽量才能做到可重用，可扩展，维护性高的系统，还有一些好的编码习惯工作习惯等等，反正一下子也说不出那么多东西来，就是觉得在练少林的易筋经的同时还得多研读佛经，这样才能让功力不断提高且不致走火入魔南辕北辙。刚开始接受项目的时候，发现有一个新加的模块会经常被别的程序调用到，一开始也没想这么多，哪里要用到，就往那个程序里加。可是后来客户那边说要改的时候，就老是得去把这地方都改一遍，特烦。后来就把这个模块专门提取出来，其他地方只要调用借口就OK，效率和优雅都提高了很多，那中feel特清爽，呵呵。除此之外，虽然作为“一介”程序员，在平时可以多学学项目管理的知识和艺术，不要总以为这是项目经理的事，我只要负责接任务把它完成就好了，毕竟以后除了了一辈子走程序员的路之外，还想尝尝管理这份菜是不是味道更好一点。未雨绸缪总是好事！新鸟发言，纰漏颇多，不过皆为由衷之言，并非装腔作势，还望老鸟海涵！

变化需求是很正常的事情,但是要走正常的途径。要把需求管理规范在一开始就和客户确定下来。

你们要变更需求是吧，好，那就请你填写详细的符合规范的需求变更文档，要签字画押，我们认为需求变更不规范的，过于简单的，不能指导开发的需求变更，不好意思，我告诉监理这写的太简单，请你重新写。最后写完了，我们认为要求不合理的，还可以在需求变更文档中签上意见，把球给你踢回去。这么折腾几次，客户就不会把需求变更当儿戏了。

这么做当然不是为了给客户制造麻烦，而是为了让自己在项目中占据更多主动，在不平等中争取更多的对等。

25 楼 neora 2008-08-29  

superloafer 写道

本以为这些工作没有什么技术含量，比较枯燥，然而出我所料的是，经过两个多月的维护工作，却领会到了很多软件或项目开发领域中的学问，虽然这些东西的字眼和概念原来在大学的时候遇见过n多次，但是从来理解不了是怎么回事。

恭喜你！不经历风雨，哪能见彩虹？

24 楼 superloafer 2008-08-28  

我觉得所谓的画押好像用处不大，因为客户那边需求变化太正常了，今天他们觉得这样比较爽，明天开会的时候，他们又会说好像这样不行哦，得改。难道还总是跟他较劲说“你昨天还说是这样的啊，这么今天又说不行呢？”。如果作项目真是那么“静态”的话，那作需求有什么难度可言啊。我写这篇帖子其实也是有感而发，没想到还有这么多人讨论，自己又成长很多啦。个人觉得，对于刚入行的来说，除了只是关注代码编写之外，还要用心领悟代码开发中的一些“道”。这里所说的“道”，就是除了劈里啪啦能很快写代码之外，还要不断补充一些其他知识，比如设计模式啊，怎么样才能尽量才能做到可重用，可扩展，维护性高的系统，还有一些好的编码习惯工作习惯等等，反正一下子也说不出那么多东西来，就是觉得在练少林的易筋经的同时还得多研读佛经，这样才能让功力不断提高且不致走火入魔南辕北辙。刚开始接受项目的时候，发现有一个新加的模块会经常被别的程序调用到，一开始也没想这么多，哪里要用到，就往那个程序里加。可是后来客户那边说要改的时候，就老是得去把这地方都改一遍，特烦。后来就把这个模块专门提取出来，其他地方只要调用借口就OK，效率和优雅都提高了很多，那中feel特清爽，呵呵。除此之外，虽然作为“一介”程序员，在平时可以多学学项目管理的知识和艺术，不要总以为这是项目经理的事，我只要负责接任务把它完成就好了，毕竟以后除了了一辈子走程序员的路之外，还想尝尝管理这份菜是不是味道更好一点。未雨绸缪总是好事！新鸟发言，纰漏颇多，不过皆为由衷之言，并非装腔作势，还望老鸟海涵！