六月底了，又过了半年，前期开发告一段落。这一周主要是做下半年的开发计划，整理思路-->开会讨论-->分配工作-->大家分头整理、写计划文档-->再开会-->再工作-->再分头整理、写计划文档， 最后汇总到我这里，得到一个可执行的开发计划。
我们的系统从2003年就开始投入研发，虽然每年同一时间的开发、测试人员并不多，但也过了6年多了，做了一些小项目，所以已经是好几个功能版本了。我这里说的不是SVN上的版本，而是功能上的，比如标准版、公安版、税务版、烟草版、酒店版、电信版等，web界面各个版本有一些差别，c++开发的后台也有一定的差别。
我来之前，是习惯不怎么写文档的，5年间留下的文档十分有限，而且及其简单。很多功能保留在老开发人员和测试人员的大脑里，好在还有那么一两个没有走。
要整合所有的版本，以减少开发量和维护量，JAVA和c++系统都要这样，不然这点人手马上就手忙脚乱。
要适当文档化，“源代码就是设计”体现在业务流程细节上，大方面业务流程、特殊算法、产品功能规划、系统设计、开发计划与优先级等，一定要文档化；老是把这些东西保存在开发人员和测试人员的大脑里，是一个管理混乱的表现，随着人员流动，新人需要从代码和测试慢慢明白系统的各种业务流程，是极大的浪费资源。
要更加强调软件测试，特别是开发人员的单元测试。
很多时候，开发人员特别是JAVA开发人员，喜欢做出漂亮的WEB界面，然后告诉你完成了，当你细细一点按钮来测试功能，却发现这也不行，那也不行----典型的好看不好用。
靠测试人员来保证软件质量是正确的，所谓QA，但是中国软件公司不注重测试是一个难以改变的现实，小公司就更严重了，全职的测试人员比例太小了，所以想依靠测试组来保证系统质量在小公司是不怎么现实的。
所以我一直强调开发人员一定要做好单元测试，我所指的单元测试不是JAVA组的JUNIT、或c++组的CppUnit，我并不要求细到这个程度，常常只要做好模块功能测试，测试详细一些，尽量不要把一些错误留给测试人员，尽量自己发现大部分BUG，自己解决掉。事实上这个要求是比较高的，常常令人失望。
很多做了四、五年以上开发的人，在实现一个功能甚至一个子系统时，是游刃有余的。而在开发计划制定上却不怎样，常常比较抵触去做，认为不重要，没有技术实现重要，这个想法是错误的。
怎样有条不紊地组织有限的人力，在规定的时间里完成开发任务，并且测试好软件系统，保证一定的软件质量，并不比技术实现轻松。现实中常常是人手有限、时间紧迫，作为一个协调人，怎么制定优先级，怎么把各个开发组、测试组、技术支持组串联起来，怎么说服市场人员和老板取消掉一些不实现的功能点，是需要锻炼的。