谈谈软件开发管理

——读《卓有成效的管理者》、《人月神话》、《软件随想录》有感

以前我一直觉得自己读书慢，但在 17 年底、18 年初的一个月里，我也读了四本书，其实挺快的。主要还是得肯花时间，以前总想把时间花在写代码、做开源项目上。实践很好，但实践之余看看前人的经验总结，印证、校正自己的实践，也很重要。

看完《卓有成效的管理者》，我开始记录自己的时间用在了哪里，并认真思考「知人善用」；看完《人月神话》，最向往的就是外科手术队伍般的团队；看完《软件随想录》，最向往的就是仿生学办公室，最优秀的程序员组成的团队，并开始认真思考「规格书」与「进度规划」。

卓有成效的管理者

《卓有成效的管理者》主题鲜明，全书紧紧围绕这五点展开：

• 记录并分析时间的使用情况；
  • 知道自己的时间用在什么地方；
  • 找出非生产性和浪费时间的活动，刻意避免、消除此类活动；
  • 消除浪费时间活动的根源；
  • 统一安排时间：必须集中自由时间，完成重要的、有贡献的工作；
• 把眼光集中在贡献上；
  • 并非为了工作而工作，是为了成果而工作；
  • 接到工作不会一头扎进去，更不会一开头就探究工作的技术和手段，而是会首先自问：别人期望我做出什么成果？
  • 管理者必须自问“我可以做出什么贡献”，才能在工作中树立远大的目标；
• 充分发挥人的长处；
  • 善于利用自己、上司、同事、下属的长处；
  • 用人主要考虑其擅长做什么；优先扬长，其次避短；招人时的考虑则是基本素养过关+有一技之长，二者缺一不可；
  • 以了解自己能做什么为基础，以最适合自己的方式做下去；
  • 充分发挥人的长处，才是组织存在的唯一目的；用人时发挥他的长处，组织结构（其他人）补他的短处，这才是 teamwork！
  • 管理者的任务不是改变人，而是运用每一个人的才干；
• 要事优先，集中精力于少数重要的领域；
  • 按照工作的轻重缓急设定优先次序，并坚守优先次序；
  • 重要的事先做，不重要的事放一放，别无他法；
• 有效决策；
  • 有效的决策总是在“不同意见讨论”的基础上做出的判断，绝不会是“一致意见”的产物；
  • 快速的决策多为错误的决策；
  • 需要的是正确的战略，而不是令人眼花缭乱的战术；

卓有成效是可以学会的，即便不是行政意义上的管理者，专业工作者自己也可以使用这套方法。

管理、考核知识工作者，得倚仗、激发他们的主人翁意识、积极主动性，当然，这得基于团队成员都很优秀、上进。如何做绩效评估？对于优秀的团队来说，奔着「绝对不会亏待兄弟们」的目标去就对了，但这只适合小规模的公司。

然而理想很丰满，现实很骨感，人才不够是常态，如何运用现有的人才更好地经营我们的组织？如何管理？如何考评？如何提升？

人月神话

可能《人月神话》里最有名的两个词就是「人月神话」和「没有银弹」了，但令我印象最深刻的却是外科手术队伍般的软件开发团队。

• 软件开发（尤其是大型软件系统）是一件很复杂的事情，概念完整性至关重要；
• 人月神话：向进度落后的项目中增加人手，只会使进度更加落后；
• 时间评估的多年经验：1/3 计划，1/6 编码，1/4 构件（模块）测试和早期系统测试，1/4 系统测试，所有的构件（模块）已完成；
• 尽管高手一个顶十个，在大项目面前，需要的时间依然太长；
• 没有银弹：软件工程中的根本问题（打造构成抽象软件实体的复杂概念结构）和次要问题（使用编程语言表达这些抽象实体，在空间和时间限制下将他们映射成机器语言）；根本问题仍未取得数量级的突破；

《人月神话》最赞的一点是「人月神话的观点：是与非」这一章，官方总结，简直良心。

软件随想录

卷一：

• 乔尔测试；
• 推倒重来一定要三思；
• 抽象必漏定律：所有重要的抽象，都具有某种程度的不严密性；抽象可以节省工作的时间，但无法节省学习的时间；如果只懂抽象不懂底层原理，一旦遇到抽象的纰漏，将束手无策；
• 永远不要聘用那些「可能」合适的人，拒绝优秀的候选人比接受一个差劲的候选人要好得多；聪明、能干就够了；
• 招来了聪明人，就要信任员工，给他们把事情做好的自由；
• 对于公司核心的商业职能，无论多么困难，都要自己做；并不断优化，打造自己的核心竞争力；
• 本杰瑞 vs 亚马逊：
• 先有鸡还是先有蛋：如果存在此问题，就要准备一套向后兼容方案，以打破这个怪圈（要么提供很多鸡，要么提供很多蛋，然后坐等鸡生蛋蛋生鸡，财源滚滚来）；

卷二：

• 管理团队的方式：认同法，使得人们认同你希望达到的目标；设法创造内部激励；
• 浏览器、网页、Web 标准：理想主义与现实主义；
• 不管别人雇你干什么工作，你都会遇到某种很不顺心的麻烦事，但是，实情却是如果你为“麻烦事”找到了解决方法，市场就会为你支付报酬；解决轻而易举的事情是拿不到钱的，要挣钱，就别怕脏，别怕难；
• 循证式日程规划；
• 确定优先顺序；

思考

一定要把好规划的与不好规划的拆分：研发与技术支持拆分。研发是知识工作者，考察成果；工作状态会对效率有较大影响。技术支持是体力工作者，考察工作量；不需要看到头（也不会有尽头）。

设计、编码、测试，这三者是软件开发的完整过程，评估时间、进度管理，不能只针对其中的部分环节。功能规格书定义要做什么，技术规格书定义怎么做。有了做什么，才能、就能评估时间了。设计过程的耗时应该进行评估，操作过程可以优化：自上而下，逐步求精。

不能向团队成员说一句“要提高自己的技术水平”就算完事，要给出具体可执行的方案；不能只说“提交代码之前要自己 review 代码”，要给出具体 review 的规则、考虑的因素。

• 好书阅读（google code style，代码大全）；
• code & design review，重点分析主要矛盾，格式等次要矛盾则通过自动化工具检测；
• 结对编程；
• 定好主题，团队成员做技术分享；

人才不够是常态，如何运用现有的人才更好地经营我们的组织？如何管理？如何考评？如何提升？

软件开发项目管理工具推荐：

• Manuscript：《软件随想录》作者公司的产品，似乎很强大；
• OmniPlan：可以做评估，可以做编排，但无法追踪实际情况，更无法总结历史数据，不过这些缺点未必致命；