B2C退换货项目总结

经过我们项目组全体成员三个月的不懈奋斗，商城的退换货系统终于成功上线了，上午开了结项大会，大家都对这个项目做了一些总结，中午大家去饭馆腐败了一把，哈哈。尽兴之后也得静下心来对这个项目好好的作一个总结，总结在项目过程中的经验教训和个人成长。

项目结束后，大家（包括老大们）都一致认为这个是项目非常成功，我也非常赞同，我觉得用三个词你评价我们的这个团队，那就是激情、团结、自信。项目组成员中有在公司三年以上的老员工，也有入职不久的新员工，还有应届毕业生，虽然年龄不同，工作经验不同，但我们大家有的是相同的激情和高度的敬业精神。都说“态度决定一切，细节决定成败”,从项目初期的编写UC、系统设计到后来的编码、测试阶段，项目成员都非常认真的完成各自的工作内容，成员之间积极配合，经常交流自己的心得，分享经验与教训，这对项目的质量和个人的成长都有莫大的帮助。通过这个项目，使我们项目组成员之间的关系变得更加融洽，更加有责任心，我想这是我们组的最大财富。

在系统设计阶段我们用MindManager仔细的罗列了所以的功能点，这样有助于大家了解项目大致的工作量，为了能够制定出比较合理的项目进度计划，我认为在估算工作量的时候，一天最好按照6小时的工作时间计算，因为8小时的工作制，除去会议和其他异常情况的时间，全身心投入的时间也最多是6个小时，否则，到项目后期，为了赶进度，往往会出现加班的情况。当然，如果系统中涉及和其他部门或者公司合作的，还要考虑系统间的联合调试时间，因为这是一个潜在的风险，就拿本项目来说，当初没有考虑支付宝的接口调用的异常因素，而在开发是时候因为支付宝测试环境不稳定，而导致我们的业务流程不能正常的走下去，严重影响了我们的开发进度和开发效率。

系统设计非常有助于后期的开发工作，在系统设计的时候对每个功能模块至少要用流程图和时序图描述整个功能模块，流程图描述模块的功能和分支流，时序图描述模块间的调用关系，这样在以后的编码阶段，思路就会很清晰，即使有改动也不会出现太大的偏差。

在这个项目中，我认为有一点非常值得推广的就是利用了敏捷开发的思想进行项目的管理，每天举行项目组晨会，这样有几点好处：

1、              大家都可以了解项目进展情况。可以谈谈大家在前一个工作日遇到的问题，大家可以一起讨论，集思广益，给出一些可行的解决方案。

2、              安排当天的任务。我个人觉得这种方式非常好，不会给项目组的成员在心理上形成太大的压力，非常值得推广，但这种方式也有弊端，会把项目进度失控的风险转嫁给PM，PM会承受很大的压力。这种项目管理的方式能在本次项目中获得成功，得益于PM一丝不苟，认真负责的工作态度，这一点非常值得我学习。

3、              了解组员的情绪变化。每天晨会的时候从项目组成员的表情就可以看出他们工作任务的完成情况，如果工作完成得比较好，那么他们会变得比较活跃，反之就比较沉闷，要及时发现成员们的情绪变化，及时给与帮助，帮助他们解决遇到的问题，或者适当减少工作量，帮助他们调整情绪，这样不论对提高项目质量还是融洽团队气氛都是非常有利的

4、              邀请测试人员要参加晨会。这样便于他们了解项目的进度和功能的实现方式以及以后的测试重点，有利于设计和编写测试用例，他们也能向我们提供一些我们在开发过程中需要注意的点，一举两得，何乐而不为呢。

这次项目，开发人员只有5个，而新人就占据了四个，我觉得老员工应该给予新人充分的指导和帮助，PM在分配给新人任务时主要难度适宜，跳一跳就能达到的是最好的，这样对他们来说既有挑战，难度又不是很大，当他们完成任务的时候会非常有成就感，能够增加他们的信心和激情，同时，在工作量安排上也要相对宽裕一些，不至于产生很大的工作压力。

给新员工指导的时候，当场演示解决问题的方法是最好的方式，这样他们能亲身体验，下次遇到类似的问题就能很轻松的解决了，而口头表述太抽象了，不容易接受。

开放和分享向来是公司所倡导的，当你遇到问题时，或者得到一种解决方案时，应该乐于在旺旺群中分享你的心得和感受，这样其他人就会了解该问题的解决方法或者怎么样才能规避这些类似的问题，在一定程度上能够提高开发效率。

在开发过程中往往会出现这种情况，为了一个问题花了几个小时还没有解决，焦头烂额，烦躁不堪，非常影响自己的情绪，我也遇到过类似的情况。我觉得一个问题20分钟解决不了的问题，就要主动请教相关的同事，一个非常典型的例子，一位同事为了调整页面，花了半天时间调试，还没有搞定，濒临崩溃的边缘，第二天找UED的同事帮忙，两分钟搞定了，彻底崩溃，哈哈

勇于主动承担责任，有时候问题多未必是件坏事，比如bug的问题，我们可以反思出现bug的原因，自己忽略了什么，下次应该注意什么，怎么样去解决它等等，思考的过程也是一个成长的过程，换个角度看，往往会变得更加美好。每次做完一个项目或者日常要好好总结，这样往往使自己成长的更快（以前我从来没有总结过，这次一总结发现自己真的成长了很多，哈哈，所以以后还是要学会总结）

以后开发的时候要多多注意并发，空指针，权限校验等问题，特别是空指针和权限的校验很容易遗忘。在从AO层返回的Result要仔细设计（类似POJO），包括它所包含的DO,ResultCode等等，否则到项目后期会发现Result里面的数据很杂乱。

项目测试初期的冒烟测试还是非常有必要的。它虽然不测试每一个细节，只是走功能和基本流程，但他能发现很多低级的错误，使后面的测试工作更加顺利的进行。项目过程中对自己的模块也要加强单元测试的，以前大多走的是正常的流程，而对异常情况测试的较少，导致系统遗漏了很多异常情况。这也算是一次教训，以后自测的时候要“不走寻常路”，这样才是最好的

粗略一写，心得还真多，以后每做完一个项目还是要好好总结一下，这样才能成长得更加快。