我一直都是自己负责项目，从设计到实施按照自己的节奏和套路来，之前也有过很多心得，只有一个字：快。其中吸收了敏捷和迭代的思想。不论从成本上还是从效果上，都很不错。但是目前这个项目我负责其中一个子系统，一路走来，收获了不一样的感受。
一、即使再大的项目，也应该有个总架构师。
我一直认为一个团队应该有唯一一个核心，具有权威性。这个项目还是比较大的，涉及到IM（移动、桌面、移动app框架）、物流系统、交易系统、资金账户系统。一个人设计不论从精力上还是从能力上都不太可能（当然我可以了，有点傲娇了，但是也没有怎么吹牛）。然而综合很多因素，项目分到4-5个项目组来负责，报表是单独的人负责。这是我最不喜欢做的事情，项目组多了，扯皮和沟通的成本会增加很多，而且复用度会大大降低，维护性也会很差。我理想的结构是
按照业务来划分，容易保证业务的正确理解和效率，尽管对开发人员要求高一点，例如要懂web和移动端开发，但是如果选择好框架，是没有太大问题的。尤其基础的东西应该总设计师来做。
二、测试要及早介入
实际上，我们原来的项目测试做的很不好，很多因素，于我主要是成本，另外项目的性质也有关系，因为我力主快上线，所以很多测试工作都是在上线过程中完成的。如果不是这样，测试应该尽早介入，对于项目的质量和进度都有很好的帮助。
三、要进行真正的测试，保证项目的热度
之所以把这个和二分出来，是因为我认为
真正测试
非常重要，很多测试人员没有规划好测试用例，测试的效果非常差。我认为目前的TFS感觉上还是可以的，看看实践的效果。工具不是特别重要，人才是最重要的。excel也不失一个很好的工具，尤其web版excel，对于协作性提高不少。
还有就是保证热度，这个项目中间应该停顿很长时间。一鼓作气，再而衰，三而竭。当然，测试要跟上，才能保证项目尽快真正完成。
四、文档如果流于形式，的确就会流于形式
从开始做项目就陆续产生很多文档，我对文档并不反对，但是流于形式的文档就的确没有任何意思了，除了浪费大家的时间和满足领导的口味，我实在想不出其它描述。如果文档没有指导工作，没有跟上更新，就说明形式主义或者官僚主义在作怪。
五、只要和人合作，就有学习的对象。
这次和多个项目组合作，还是能学到一些东西，例如加强了对axure的了解，对PRD的了解，从而让我决定用axure来做prd，对于文档的多和乱进行了统一，当然这个方法还需要在项目中实践，至少从整体上高大上很多。三人行，必有我师。
在此，感谢网友臻龙的分享，我在他的基础上进行了增减。
六、还是要尽快上线，如果客户跟不上，就模拟上线，也可以说模拟测试。尽量做到多迭代，快上线。如果花了很长时间做了一桌子菜，才发现咸了，酸了或者辣了，不如先快上一盘，客户没有能力说出他真正的口味，但是挑毛病谁都会。
网友评论