谈谈软件开发管理

2018-02-10 Piasy 更多博文 » 博客 » GitHub »

管理

原文链接 http://blog.piasy.com/2018/02/10/Thinking-About-Software-Development-Management/
注:以下为加速网络访问所做的原文缓存,经过重新格式化,可能存在格式方面的问题,或偶有遗漏信息,请以原文为准。


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

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

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

卓有成效的管理者

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

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

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

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

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

人月神话

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

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

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

软件随想录

卷一:

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

卷二:

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

思考

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

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

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

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

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

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

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