小小总结一下经验，给后续的日志做个纲领。
对外部环境的认识
1、必要性原则：用户（客户）需要应用软件来帮助他们处理信息。
2、“脱机”原则1：用户（客户）通常不会一直坐在电脑面前，他们都有自己的工作要做，而那些工作才是他们真正要做的事情。如果你是秘书，那么，电脑不会帮你做会议纪要，也不会给你安排老板喜欢的度假酒店。
极端一点，假设你是清洁工人，一台多点触摸的 surface 即使再逼真的让你看到街角的一小块垃圾，你最后也还是得用扫帚去清除。
3、“脱机”原则2：不要把用户（客户）想象成电脑专家。下班后他们会回家吃饭、看电视、逛街、看电影。很多搞手机应用的人注定失败，原因就在于他们想象用户会从起床开始到睡觉都一直盯着手机看，实际情况是：没有人会这样。
4、需求原则1：“要求”不等于“需求”。如果有人要求你给他（她）做一个能看电影的收音机，那么，你应当告诉他（她）：“你需要的是一台带收音机的MP4播放器。”而不是立即开始开发“电影收音机”。
5、需求原则2：需求是会发生变化的。所以，你要做的，就是尽早发现这种变化并尽可能提高自己应对变化的能力。
6、很多人还没有意识到“信息”以及处理信息的软件对改善他们工作的重要性。但这不是他们的“错”。
开发的原则
1、技术非常的关键！“技术上没有问题，问题在于…”说这样的话只能证明这人在技术上的确存在问题。
2、但，技术需要用户（客户）的需求来引导。
永远按照需求来选择（甚至学习）技术，而不是相反。
3、限制性原则：技术不可能什么都能实现！参见“‘脱机’原则1”
4、适用性原则：只要分析到位，用户（客户）的需求，技术一定能够实现。参见“必要性原则”
5、“速度”原则：除非编码（Coding）在软件的整个生产过程中占到 50% 甚至更高，否则，任何希望提高编码速度来换取更快进度的努力都会以失败告终。
但是，有编码在整个软件生产过程中占到甚至超过 50% 的项目吗？没有。所以，任何希望通过提高编码速度来换取更快进度的努力最后都会以失败告终。
为什么？参考“需求原则1” 和 “需求原则2” ，以及下面的“管理的原则”。
管理的原则
1、技术相关原则：技术决定工艺流程和工种，由此，决定了团队的构成和所有管理的基础（基础技术假设）。
Web 应用程序是通过在服务器获取数据并组合成网页展示给用户来工作的，所以，你的团队里面要有会制作网页和会写代码从数据库取数据的成员，并且，在进度上，网页要早于代码完成以便集成。
2、因为需求会（而且可能很快）变化，所以，为减少对管理带来的冲击，应当在一开始就选用适应力最强的技术。
3、“最少”原则：任何管理和技术上的努力与技巧，都比不过一开始就明确只做最少的内容。
如果这一点做不到，那么，也许应该试试：
4、“设计优先”原则：尽可能给设计多点时间，这是我们思考的过程。
如果这一点也做不到，那么，也许应该试试：
5、“死亡冲刺”：先做出来再说，有问题以后再改。
不过，请做好足够的心理准备，你要应对的不仅仅是总体成本和维护工作量的上升，更严重的是团队成员的质疑、无休止的加班和逐渐低落的士气。
6、“最小管理”原则：如果你真的是没有办法了，但是还是希望能够对软件的生产过程进行控制，那么，就做好配置管理吧。
只要你每次在任意一台服务器上从配置库获取最新代码都能够在10分钟内完成部署，并且，在生产环境中部署的软件也是这个版本，那就应该差不多了。
7、“国情”原则：适合你的管理方法一定是你从你自己的实践和需要出发摸索出来的，其它的各种理论、方法、实践都只能作为参考。
先记这么多，以后再慢慢完善 ：）
