关于“软件开发”，“工程师文化”，“团队管理”

 分享一下 weibo@左耳朵耗子 陈皓的“建一支强大的小团队”报告内容，挑选了几点。

人物介绍

行业背景 ：金融行业(Thomson Reuters) ，计算平台(Platform)，电子商务(Amazon) 

技术背景 ： C/C++/Java，Unix/Linux/Windows ，Web 

个性：码农兼包工头 ，敏捷恐怖分子 ，Unix/Linux/C/C++脑残粉 ，“技术部门无技术种族”歧视者 ，程序员文化民族主义者 

陈皓是酷壳coolshell的博客作者，上面很多文章都会被大家广泛传播分享，可以看看最近几篇比较火的：

    xkcd 神图“Click and Drag” geek风十足

    简明 Vim 练级攻略 前天有朋友在人人上分享

    如何测试洗牌程序 两个月前，微博上陈皓和测试人员的“大战”，主旨是陈皓认为软件开发不需要专职测试人员

陈皓年前加入了淘宝北京，貌似直接是P8，P9的级别，是位技术大佬。以下简单分享几点。

软件开发的现况

软件的复杂度持续不断地提升
- 业委需求复杂度
- 部署运营觃模复杂度
- 维护支持复杂度
软件开发迭代周期和频率越来越快
- 开发、测试周期
- 交付周期
- 解决问题的周期
软件的运行和质量要求的越来越高
- 扩展性
- 稳定性、可用性
- 用户体验

软件开发出现的状况

软件的问题
- 业务分析能力的不断提升
- 软件产品的质量随着复杂度的提升越来越差
- 软件的测试和维护成本越来越大
- 解决软件问题的成本越来越大

管理问题
- 团队越来越大，分工越来越细
- 团队的合作问题
- 团队的执行力问题
- 团队的流动问题（内部和外部）
- 团队的成长问题 

团队现况

程序员被这些人包围：高层老板，研发经理，产品经理，项目经理，流程SQA，架构师，敏捷教练咨询师，QA测试，客服支持，运维Ops，BA。每一个苦逼的程序猿背后都有一群指点江山的人。

Talk is cheap, Show me the Code!

问题

- 流程控制多

- 组织单元多

- 利益牵扯多

- 消耗资源多

- 沟通会议多

其实这些也是大公司的问题，普遍大公司都存着这个问题。

思考

• 程序员不能管理项目和迚度？
• 程序员不能做测试保证软件质量？
• 程序员不能分析需求？
• 程序员不能做运维？
• 程序员不能管理好自己的流程？
• 程序员不能架构和设计软件系统？
• 程序员不能和别人很好的合作？ 

观点

• 如果不信仸程序员，你还招他干啥？
• 如果程序员只会编码，这是不合格的程序员！
• 自己管理自己是最有效的！
• 管不好自己的员工，找人来管是错误的!
• 程序员是生产力的主力！
• 其它大多数人都在降代团队的生产力
• 优秀的程序员创造的价值是平庸程序员的10000倍！
• Eat Your Owe Dog Food! 只有吃自己的狗食才会有改迚！
• 程序就是用来自动化一切机械的劳动！
• 主动工作的生产力进大于被动工作的生产力！

程序猿必备技能

• 程序员必需懂编程技术，开发工具，软件工程
• 程序员必需理解需求
• 必需站在用户的角度上思考问题
• 程序员必需懂测试
• 自动化测试，测试案例设计。
• 程序员必需做系统维护
• 自动化部署，自动化
• 程序员必需管理好自己的工作
• 程序员知道什么流程方法最适合自己
• 轻重缓急，时间进度

Google的工程师文化

• 对工程师的信仸和尊重
• 每位员工都有20%的工作时间可以做自己想做的事情，很多产品 就是用这 20% 的时间做出来的，比如众所周知的 Gmail 。
• Larry Page:"this company will be run by engineers" (not marketing not sales)
• 自由平等，信息透明
• 数据说话 (quote netscape executive)
• 层级扁平，TGIF上可以提各种尖锐问题 (dory and live questions)
• 公开所有项目的：文档，代码、觃划，数据，资源
• 自己设置目标
• 激迚地目标设定，完成基本上是60%左右。
• 给管理层打分
• 不受程序员喜欢的管理人员会被离职。

Facebook的工程师文化

• 项目的资源完全来自工程师的自愿
• PM游说工程师们，试图吸引工程师为他们的想法而工作
• 工程师自己决定去干哪个产品经理的活
• 工程师然后去给他们的头儿报告：“我本周要干5件事情”。工程师的头儿几乎可以说是放仸手下各行其是，偶尔给点做事情 优先级的忠告。
• 工程师自己处理所有的事情，从js到db的所有逻辑。如果他们期 望得到设计师(FB里只有非常少的专职设计师)的帮助，他们需要自己去搞定设计师来加入他们的项目；如果需要架构师同样也得 自己来搞定。但通常来说，工程师自己干所有的活

Amazon的工程师文化

• SDE – Someone Do Everything
• 工程师从需求分析一直做到线上运维
• 大量的自动化工具（测试，部署，监控）
• 需求来的时候要问为什么要做？
• 少量的QA，Designer，没有架构师
• 没有软件开发流程，团队说得算
• 非常严格的招人
• Pizza Team 文化
• UP the River  

软件公司的两种管理方式
WIDGET FACTORY（小商品工厂） 

• 一般人的本性是懒惰的，工作越少越好，可能的话会逃避工作，大部分人对集体（公司，机构，单位或组织等）的目标不关心，因此管理者需要以强迫，威胁处罚，指导，金钱利益等诱因激发人们的工作源动力。 

• 经理总是要去做他下属的工作。这种团队中的每一个人都很容易被别人取代，在这种团队里，经理的工作能力不断地被加强 

• 这种公司一般使用树形层级的组织结构，而不是水平式的工作角色。 

• 他们对实实在在的软件开发漠不关心，他们想要把理想中的软件开发运作变成他们看得见的图表。 

FILM CREWS（电影工作组） 

• 这种公司认为人是有相当高的智力和创造力的，是自己可以激发自己的。 

• 每一个个体的自已专业能力，要进进优于那种被组织和协调出来的能力。人们努力工作，幵且可以享受工作。 

• 工作职责变得非常地垂直——你需要具有从上到下的而比较宽泛的各种能力。 

• 经理了解把一个伟大的软件组合起来的每一个碎片。他的角色是鼓舞大家，守护着方向（Vision） 

• 团队里的每一个人都很关键，因为团队相信软件的结果来自所有的参与者，以及他们的那种独一无二团队工作方式。 

小团队的前提
• 知识密集型的企业 

• 价值观和目标一致 

• 产品要简化到简单到不能简单 

• 资源平等，信息透明 

• 个体能力要强，都是T型人才 

• 没有中心控制，通过团队协作自治 

• 自组织，自协作，自管理，自迚化 

团队管理三板斧 

• 标准化流程（制度） 

  • 质量控制 

  • 过程管理 

  • 项目监控 

• 过程改迚（方法） 

  • 持续集成和自动化测试 

  • 极限编程 

  • 快速迭代 

• 激发团队和人员（文化） 

  • 团队和个人发展 

  • 团队主人翁精神 

  • 团队和个人的执行力 

 

工程师文化 == 创新冲动

（全文完）