项目开发心得1

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

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

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

你们需要《编码规范》

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

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

This is a must..

呵呵，对于多用户操作这一块还真没注意。

编码没有规范,该注释的地方没有注释,自己写的代码最后自己都看不明白,这样的人就应该让他滚蛋,他不具备做程序员的基本素质,技术不行可以提升,态度不好难以胜任,只会给后续的维护人员增加无谓的工作量.
需求不是那么好搞的,客户也不是那么好伺候的,你以为他跟你白纸黑字签了需求,就能100%只按需求做了.到时候客户来提需求变更,你丫跷着二郎腿跟他讲这个不在我们签的需求里,所以要改得延期两周经费另算,你看他会不会理你.10个客户9个不晓得自己的业务,或者说他们是描述不清,也可能需求人员理解错误,更甚者他们跟你讲得是一套做起来是另外一套.所以不要听某某主任或什么官在酒桌上跟你拍板,那都是忽悠.真正需求的精髓只有一个字——"陪",就是人家上班你去陪着,人家去哪你去哪,看他究竟天天在干什么,怎么干的.也许我这话讲得不太中听了,不过我的感觉是这样.

呵呵，看来summerfeel经验还是比较丰富啊。后来我们的客户给我们发送了一些他们在现场的操作视频过来，我们看了之后的感觉就是：哦，原来他们是这样操作的啊！
"陪",就是人家上班你去陪着,人家去哪你去哪,看他究竟天天在干什么,怎么干的.也许我这话讲得不太中听了
这样倒是不错的主意，能把客户的实际情况摸得比较清楚，不过就是代价太高了吧，得拍专人或者腾出专门的时间去跟呀，呵呵！

第一个问题是因为没有和客户沟通好，无法比较确切的明白客户需求。在开发过程中，一定要经常和客户沟通，说不定他们就有什么想法，这个时候，有的要坚持，有的则需要变更。
但是每次的沟通都需要双方签字确认，同时将结果添加到原有的需求中，并及时调整项目计划。

流畅的沟通是完成项目的重中之重。
我的一个项目还不是外包，仅仅是公司内部之间的货，其他部门A提出的项目需求，我们完成了，最后被老板批评了，原因是部门A没有理解老板的思路，就按照自己的思路给我们部门出了需求书。结果项目延期2周，10个工作日。