1.系统流程梳理
以一个很简单的例子来说明流程梳理对软件开发的意义，比如你要进行一次演讲，但是这次演讲是即兴的，你不是的即兴演讲家，那么在没有准备情况下，你要对着台下的人进行演讲，这个时候你走上台去，脑子里的东西还没有形成有条理的演讲内容，讲完后台下的人都不知道你在讲什么，可能你自己都不知道你刚刚讲了些什么，这就是失败的演讲，没有做好充足的准备。对于软件开发来说也是同样的情况，每一个开发者不应该仅仅拿到的是一些文档，而是应该大家坐在一起，由熟悉该软件业务的管理者或者其他人来进行一次严谨的描述，并进行讨论，加以完善和改进，让参与编码的开发者在这个过程中不仅能够熟悉自己要做的那些功能的细节，还能对这个系统有一个大致的了解和熟悉，只有这样，在开发中才会避免一些不必要的问题发生，而且还能发现一些隐藏的问题，要知道修改问题是需要花费很多时间和精力的，比如编码和业务是有冲突的，本人有遇到过，代码不能跟着业务走，业务也在适当的时候在满足正常场景下根据编码风格做适当的调整。最终达到一种整体和谐的一种美感。在编码的前期要让每一个参与项目的人能够清晰的知道我要做的是什么，最终的目标是什么样的，我要关注的重点有些，还有哪些疑虑我需要讨论或者解决的。准备工作做好后，对每一个团队成员项目的进度是非常清晰的。
2.技术框架的选择
一般选择技术架构有几个衡量的点：
一点：效率。
在开源领域能完成同一个技术目标的框架是多个的，比如在web开发的，最终开发出来的产品是要经过性能这一关的，如果选择有误，整个软件可以说是失败的，因为不能用，你需要重新选择技术框架，并且要重新让每一个开发者在新的框架上进行开发，这是在开发一个新的软件。
二点：成本。
是学习成本，第二个是经济成本，只讨论学习成本，因为本人非常反对使用商业软件，把这笔买商用软件的资金来激励和培养员工效果会，这里不做什么讨论，不是商业上的东西就很安全，开源的东西也很安全，只说一句：大部分情况都是浪费！关于学习成本要考虑到团队和团队人才培养方式，如果项目团队没有什么培训和学习气氛，那么这个团队选择框架的原则是非常简单的，在这种情况下就选择自己熟悉的能有把握的；还有一种情况就是团队中有非常强的开发者或者学习能力非常强的开发者，那么可以选择一款相对最适合整体架构的新技术框架，并加以重视，因为这是新的东西，风险也是非常高的，只要重视了，而且技术上可行的，结果是的；这是根据团队的实际情况进行参考，勇气也很重要。
三点：稳定性。
选择一个合适的软件版本，个人比较倾向于在平台和框架上进行开发，因为有新的特性，有可能心的版本有进行一些优化。
对稳定性的考虑，举一个例子，根据实际情况已经选择要使用一个A框架了，假设A框架有两个版本，V1和V2，V1是稳定版本，V2还是测试版本，V2中添加了一些新的功能，而这些功能正好满足你的项目需要，并且稳定版本是在你编码完成前就会发布，那么眼前有两个选择个选择，选择V1版本并且要选择一个新的B框架来满足项目需要，这种方式风险；第二种选择，选择V2测试版本，最终等到稳定版本发布后进行替换，这种方式也是可以选择的，不过风险相对种选择要高些，有一个优势就是这一个框架就可以满足你的项目需求，成本相对低一点。两种情况我都有实践过。