运营企划：
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.只公布是不够的。有多少人在真正使用你的软件？这才是衡量成功的终极标准
以上摘自《程序猿的修炼——从优秀到卓越》一书，括号中面是博主自己的理解