做项目需要激情，而保持激情的是团队成员。其实，每个人刚进入团队时，都是怀揣着梦想和激情的。梦想一般不会灭，除非被现实碰碎；一般都会根据自己的经历不断的调整梦想，因此碰碎的可能性是比较低的。而团队的激情，会在得不到回应中慢慢磨灭；因而个人认为保存团队激情的方法，至少其中一项应该是快速回应每一个团队成员，哪怕是拒绝。
在开始一个项目时，首先要做的应该是系统架构，网络怎么组、C\S还是B\S、要使用那些开发语言、数据库用什么等一系列架构。当然，也要考虑一下部署问题、生产环境和测试环境的搭建。目前，至少在深圳，发现云是一种趋势，因此这里给一个建议，如果有条件尽可能把数据保存在公司后台服务器，这样做可以保证数据的一致性，在条件允许的情况下可以做数据挖掘，也就是大数据分析，如果和客户产生纠纷时可以直接拉取出来数据作为证据同时也避免用户随意篡改数据；这样做会增加后台压力，但是这个要比放在客户本地带来的麻烦小很多。按照正常的思维会考虑断网的情况，就是局域网可用互联网不可以，无法连接到公司后台服务器的问题，其实这根本不是问题，不连接互联网就是单机系统，不在我们项目的维护范畴，这点可以在使用协议里明确写出断网概不负责；如果你还是纠结，那么就思考一下，在网络膨胀的现今社会，断网的可能性有多大。有些系统是各种平台的支持，完成一个闭环，如果其中一个无法联网，那么闭环就不完整了，这样一来有维护那一环本地处理的必要吗，再说它在断环的情况下还能完成完整的业务吗。
确定完系统架构后，就应该进行功能架构了。功能架构，确定需要哪些模块，它们都做什么，刚开始肯定不能具体描述，可以先决定一个粒度很大的功能上的架构，比如用户管理模块、更新升级模块等。功能模块划分好后，就可以分配给适合的团队成员。
团队成员在接到模块分配后，可以和大家讨论一下模块的整体架构，从而确定一套合适的框架，因而可以着手开发框架。
例会是很有必要的，频率根据项目的具体情况决定。例会上，大家把粗粒度模块细化的每个功能上，并且提出自己实现的思路，如果感觉不错就可以采用。大家汇报一下取得的成果，宣布一下接下来要做的事，然后把自己碰到的问题提出来依靠团队力量解决一下，最后精细化模块、填补之前设计上的缺陷。
例会要固定，不要朝令夕废，甚至如果刚好赶到节假日，大家进行网络会议。通过例会，可以了解大家的进度，以便于项目进度的控制，同时通过团队的力量解决一下自己无法解决的问题，并且使得项目不停的完善。
例会不宜太久，久了浪费时间。例会上大家尽量只谈项目，快速解决遇到的问题，有些耗时的不是所有团队成员都参与的问题可以组织一个讨论组来专门讨论。
如果感觉这样太严肃，需要讲一些生活上的事情改变一下气氛，也要一笔带过，不建议过多讨论。大家可以在中午吃过饭后，找一个角落，坐下来聊聊天，聊聊生活，聊聊八卦，促进大家的交流；声音不要过大，不愿意聊的可以午休或做自己的事。
项目在刚开始的时候，没必要引入黑盒测试，大家都各自进行白盒测试就行了。当项目进行到基本功能完成进入迭代的时候，就需要引入黑盒测试，然后贯穿以后的开发。如果团队中的测试人员充足的情况下，当然在现在的国内好像不现实，可以直接交给测试组，不要告诉他们太多具体实现，把他们作为什么都不懂的用户来培训；测试人员不足时，程序员就要兼职，最好是两个使用不同语言的成员之间互测，其次两个开发不同模块的成员互测。测试很繁琐，因此寻找测试点并分级，着重测试优先级较高的测试点，那些优先级低的测试点可以少做或不做，必要时发出去进行公测。
项目做到一定程度，就可以发布出去了。这时候，就要去做部署，以及为以后版本升级做准备。或许会碰到很多诡异的问题，比如测试环境没问题而生产环境不正确、生产环境的负载均衡和集群问题等。
最后，就是坐等反馈。第一时间获取用户的反馈，并做出快速回应，将有效且可行的问题指定解决方案，并入到当前迭代版本中。
