127.好的管理比好的技术更重要
128.采用合适的解决方法：技术问题需要技术方案，政治问题需要政治解决，管理问题需要合适的管理方法。
129.不要对你读到的所有内容都深信不疑
130.理解客户的优先级
131.人才是成功的关键
132.少量有技术的人比大量没有技术经验的人要好
133.倾听你的队员：如果你和团队成员之间没有信任，那么你们的项目必将失败。信任的第一原则就是倾听。
134.相信你的队员
135.期望优秀和卓越
136.沟通技巧很重要：招聘过程中不能低估沟通和协作的重要性
137.帮忙打水
138.给不同的员工以不同的激励
139.保持办公环境的安静
140.人力和时间是不能互换的
布鲁克斯法则(Brook's Law)指出，投入更多的人来开发一个紧急的项目只会让进度更慢，更多并不意味着更好。投入新的人力时，要考虑训练和沟通成本。
141.不同软件工程师之间的差别是很大的
142.可以优化任何方面
143.自动收集工程师数据
144.考虑每行代码的成本是没有意义的
145.没有完美的衡量开发效率的方法
SLOC(source lines of code)代码行估算法：大家普遍认为代码产出越多越好，但有时候却并非如此。实现相同的功能，代码量肯定越少越好。
FP(function points)功能点估算法：大家可能认为功能点越多表示产出越多、效率越高，但所要解决的问题的复杂程度或难度不同也是会影响产出率的。
没有哪一种方法是完美的，也不要单独依赖一种方法进行考量。
146.调整成本估算方法
147.不要设定不切实际的交付时间
148.避免不可能
149.使用之前必须了解
150.收集生产数据
151.不要忘记团队生产力
152.代码行数取决于编程语言
153.相信设定的时间表
154.精心计算的成本估计也不是万无一失的
155.定期评估时间表
156.轻微的低估并非总是坏事
157.合理分配资源
158.详细地计划项目
159.及时更新你的计划
160.避免驻波
161.了解十大风险
人员短缺不切实际的时间表不理解需求构建了一个糟糕的用户界面试图增加用户不想要的feature没有把握需求变化缺少可重用的接口或组件缺少可外部执行的任务响应时间太差试图超过当前的计算机技术162.预先了解风险
163.选择合适的开发模型
164.方法并不能拯救你
165.没有奇迹般地提高生产力的秘诀
166.理解进度的含义
BCWP(Budgeted cost of work performed)，衡量目前已经完成的工作的预算ACWP(Actual cost of work performed)，衡量目前的实际开销BCWE(Budgeted cost of work expected)，衡量你预期的开销(BCWP-BCWE)/BCWE, 技术状态，大于0表示进度提前，小于0表示进度delay(BCWP-ACWP)/BCWP, 预算状态，大于0表示低于预算，小于0表示高于预算167.通过偏差进行管理
168.不要过度紧张你的硬件
169.乐观看待硬件的发展
170.悲观看待软件的发展
171.认为灾难是不可能的想法往往导致灾难
172.要进行项目的事后分析
七、产品保证173.产品保证不是奢侈174.尽早建立SCM程序175.使SCM适应软件过程176.组织供应链管理独立于项目管理177.通过产品保证轮换人员178.给每个中间产品起一个名称和版本179.控制基准180.保存一切181.跟踪所有更改182.不要绕过变更控制183.等级和时间表变更请求184.使用验证和确认（V＆V）事态发展
八、产品演化185.软件将继续变化186.软件的熵增加187.如果没有破，请不要修复188.解决问题，而不是症状189.变更要求优先190.释放前的错误产生释放后的错误191.程序越旧，维护起来就越困难192.语言影响可维护性193.有时最好重新开始194.翻新最烂的部分195.维护导致的错误多于开发196.每次更改后的回归测试197.相信更改容易会导致错误地进行更改198.构建非结构化代码并不一定对其进行改进199.在优化之前使用Profiler200.保持熟悉度---Manny Lehman软件演进法则201.系统存在促进进化
作者：西东（来自豆瓣）来源：https://www.douban.com/note/740934598/
