运营企划：
1.如果没有失败（以及很多经历） ，那就算不上是真正的实验，也不可能有创新
2.重要的创新和改进可能会在任何时候以自下而上的方式来自于公司的任何人——它们不会总是按照神奇的总体规划上预定的间隔自动蹦出来（高手在民间）
3.用Memtest86+测试内存稳定性，用Prime95测试CPU稳定性。有时候确实是硬件的问题。（电源和散热设备也会影响设备的稳定性）
4.建立一种异常和错误报告机制。80%的客服问题在修复了用户报的最多的20%的BUG之后就能得到解决。异常日志才是用户反馈的根本。（在程序中建立完备的异常日志机制，收集系统的异常日志，对出现最多的异常进行修复。根据线上异常日志进行修复是最接近真实问题的修复，而且程序收集的错误信息通常比用户描述的更为精确，几个迭代之后就会令程序的稳定性大大提高）
5.我们可以施加影响，可以建立有趣的环境，可以创造让事情发生的机会，但我们不能预测或者决定结果。在构造社会性的软件时，人是所有问题的根源，但解决问题最终还得靠那些人。（在社区中听取用户的意见，用用户的行为来推动下一步的设计）
6.某些虚拟的评分排名系统，可以刺激用户对软件的使用欲望，即使这些系统不会对用户产生任何实际的好处。将软件游戏化，在用户间的创造一些他们可以相互“攀比”的机制。
项目管理：
1.如果你没能从一个项目的过程中学到一点东西，这才是真正失败的项目
2.将大任务拆分成小任务的方式是解决（项目进度）”只能完成90%“问题的关键
3.找出一种呈现任务状态的方式，以便那些感兴趣的人可以了解
4.MBO（目标管理）之类的东西其实是一种管理上的逃避。通过使用简单化的外在激励因素来提升绩效，管理者们实际上是在逃避更难做的事情，比如培养员工，调动个人主观能动性，建立思维活跃的团队，提升团队凝聚力，以及进行持续的工作流程分析和改进，等等。（趋易避难乃是人的天性，培养一个团队或个人的内在修为才能本质上改善一个团队或个人，从哲学上来说：内因才是事物发展的根本原因）
5.大多数敏捷开发方法都建议：迭代周期不能超过4周
6.我觉得在最开始的3-4年后，你是不是一名优秀的程序员就已经定型了。更多年的历练，只会让你更多地了解到大项目管理和人员管理。3-4年的时间足以看清你的未来。（比尔盖茨）
7.仅仅发布是不够的。有多少人在真正使用你的软件？这才是衡量成功的终极标准
以上摘自《程序员的修炼——从优秀到卓越》一书，括号里面是博主自己的理解