软件测试心得
-
软件测试行业里工程师工作岗位的分类
有按看不看代码分的：黑盒测试工程师、白盒测试工程师
有按主要业务分的：金融测试工程师、通信测试工程师、本地化测试工程师、游戏测试工程师
有按主要任务分的：自动化测试工程师、性能测试工程师、安全测试工程师
有按被测软件分的：手机app测试工程师、手游测试工程师、网页测试工程师、客户端测试工程师
有时也有按被测软件的语言、技术分的：java测试工程师、.Net测试工程师、数据库测试工程师
还有和开发混在一起的：测试开发工程师、测试工具开发工程师、测试架构师
最多的还是笼统的：软件测试工程师、资深测试工程师、高级测试工程师、测试主管、测试经理
此外最常见的就是复合的，如：外包java测试资深工程师、ios手游高级测试工程师，把上面的各类定语随机组合
-
工作岗位类型多导致的测试人员迷茫 - 再看行业的特点
看上面这么多岗位，可以感觉到软件测试行业就是一个大杂烩，什么岗位都有，职业发展道路复杂得难以想象啊。
所以论坛上经常看到测试工程师发帖说“工作X年，迷茫啊”，X的值从1到10不等，至于10年以上的，属于人到中年，也没时间来发帖表示迷茫了，或已转行了，当然这行业在中国一共也没多少年。。。
这个行业有以下特点
- 收入差距极大，有月薪四五千的黑盒测试工程师，也有年薪几十万的资深测试工程师
- 技术差距极大，有只会鼠标点点点的手工测试人员，也有精通程序代码的资深测试人员
- 工作内容差距极大，有人每天点点鼠标，测测XXX信息管理系统，有人测复杂的金融业务，有人写测试工具，有人测服务器、中间件、测socket、测高并发，有人搭建测试平台
- 不同岗位间技术壁垒严重，比如你让一个黑盒手工测试人员去看两个安全测试人员做渗透测试，他很可能完全看不懂这些人在干啥。如果你给一个网站手工/自动化测试人员做一份数据库测试人员的笔试题（考具体数据库的SQL、函数、存储过程），很可能他要交白卷。当然反过来说，要从技术型测试岗位转行去做黑盒手工测试人员是毫无壁垒的，但一般不会有人这么转。。。。
- 入行门槛低，一个其他专业的无关人员通过三个月简单培训，即可掌握普通的黑盒测试方法，成为一名软件测试工程师，拿3-5k薪水
- 黑盒手工测试是主流职业，国内大部分中小型公司都需要大量的黑盒手工测试人员，同时巨头级的金融机构、互联网公司仍然需要资深的黑盒测试人员
所以造成了大量外行人员涌入软件测试行业里的黑盒手工测试岗位，并给人以测试人员技术不行的总体印象。
- 软件测试行业下细分职位的发展路线
首先黑盒测试有以下特点：
- 门槛低，培训三个月可掌握；我做外包的时候，曾有公司将3个月培训的应届生伪装成2年经验黑盒测试工程师派去客户方工作。客户方毫不怀疑，并最终给以好评。
- 技术路线长度为零，一入黑盒不复返，想做技术难难难
- 测试技术知识无更新，仍然是上世纪六十年代左右的黑盒测试方法
- 依赖业务知识作为核心竞争力，如金融测试工程师
- 职业发展路线一般是测试管理方向或干脆转行。可以说绝大部分从业人员如果不想转行的，都想做测试管理，然后可想而知竞争激烈，而且真的只会黑盒测试的人以后越来越难拿到管理岗位。为什么？因为现在有很多人懂一点技术
所谓懂一点技术，就是会做一点自动化测试。
自动化测试有以下特点：
- 人人都在提，职位描述里都有，但大多数人都只懂个皮毛（因为他们做黑盒做久了，技术路线毫无积累）
- 自动化测试工作难找，首先自动化测试对企业来说成本极高，长期投入才能见效，这对国内小公司来说是不可能的，其次，项目适合自动化的不多，比如要做8年的40国语言的本地化测试项目就很适合，但毕竟少，一个极其不稳定的网站就很不适合，但国内大部分是这种。再次，招不到会做的人，你能招到的人基本上有两种，一是做黑盒测试为主，懂一点自动化测试的人，技术上属于基本指望不上的，学习能力基本没有，要靠高手教出来的；另一种是原来做开发，因压力大/无聊等原因转行做自动化测试的人。这种技术上有的还是可以的。但问题是测试思维欠缺。能做，但不一定做得好，经常陷入自动化测试的陷阱和泥潭中。但你如果想要招懂技术、测试思维好的人基本上招不到，当然钱多的巨头是可以把这些人用钱砸出来的。
- 懂自动化测试技术不一定能让你找到自动化测试工作，但对找手工测试工作的帮助极大。所以黑盒测试人员如果怕失业、怕被应届生挤走的，务必学一点点自动化测试来提高表面上的技术竞争力。就算不会做，也要会吹，而且基本上放心好了，一般公司是承受不了自动化测试的成本的，不会真的让你做自动化测试。
- 全靠自学，没人教。我不懂自动化测试的时候看国内的各种自动化测试教程、书籍、视频，都觉得高大上。我懂了之后看这些觉得都是shi。为啥? 他们不教原理，只教工具。 不教思维，只教方法。后果是,你学了皮毛，学了“术”，而不懂原理，不懂“道”。自学者推荐使用英文资料自学，比中文资料强100倍。中文资料当然也有好的，但极少，更多的是某些人为赚钱写的，也有自己就一知半解的人瞎写-害人不浅。英文资料也有瞎写的，但好资料多。
- 高端岗位和开发人员的技能重叠性高。这有个什么问题呢，就是你做黑盒测试懂一点自动化测试的人，在竞争高端自动化测试岗位时，比不过资深开发。去看看互联网巨头里对自动化测试高端岗位的职位描述就发现了，跟你平时用的东西完全没关系。也就是说，自动化测试的从业人员想走高端岗位，需要面对来自转行的开发人员的巨大挑战。
- 可被手工测试替代。对大部分中小公司而言，一旦因为对自动化测试的成本估计不足，在自动化测试上就会陷入陷阱和泥潭。然后基于国庆，很多公司会用大量的手工测试实习生来代替自动化测试。效果也还行。所以除非是很适合自动化测试的项目和对成本有充分估计的公司，一般不会去做自动化。招大量实习生有另一个好处，就是容易产生管理岗位，黑盒测试出身的大多数就等着这种机会来做主管。
- 职业发展路线一般就是一直继续做自动化或尝试挑战巨头公司的高端岗位，更多的人会自动化之后去和黑盒测试人员竞争测试管理岗位，这时他们有技术上的先天优势。
自动化测试的陷阱和泥潭：
- HP公司的QTP广告深入人心，录制回放的自动化现在仍有许多支持者。但这类岗位停留于工具的使用上，对个人来说，技术路线极短。因为这种工具就是为了让不怎么会技术的人使用而设计的。对公司来说，商业工具确实是成本最低的自动化测试解决方案。所以有不少公司仍然用他。但他很难招到愿意为公司牺牲自己的技术路线的人，一般他只能招到懂一点点技术的黑盒测试人员来做这种自动化测试。这里有一个很老的典故：某测试人员来到一家软件公司，技术负责人指着角落里一台积满灰尘的电脑说，这是我们的自动化测试专用机，不过录制的脚本老是跑不起来，现在我们已经不太搞自动化测试了。
- 开源工具单独无法使用，而懂一点技术的黑盒测试人员搭不好测试框架。以网站测试威力，最流行的开源工具selenium，必须和测试执行器（xunit系列）一起用。团队需要至少有一个人有搭建测试框架的能力。实际上很多团队没有这号人。搭出来的测试框架用四个字形容就是一塌糊涂。总之这对后面的人影响很大，如果搭框架的人已离职，你最好想清楚要不要去这种项目做自动化测试。一个蹩脚的框架会让你痛不欲生，产生还不如做手工测试的念头。
- 为什么懂一点技术的黑盒测试人员搭不好测试框架。为什么懂一点测试的开发人员也搭不好测试框架。因为，他们有一个共同特征：不懂自动化测试原理。 比如说，自动化测试要关注可维护性，要设计合理的代码重用机制，以网页测试最流行的开源工具selenium来说，官网就有介绍页面对象模型的使用方法。但一般人看不懂。再比如搭一个好的selenium框架需要很好的编程语言基础。假设你招了大部分转行做测试的初级开发人员或懂一点技术的黑盒测试人员用java和selenium来做网页自动化测试，你跟他说“多用组合少用继承”，他完全不懂你说什么，他反正写java就不管三七二十一继承继承再继承，他娘的他就会个继承，要么他干脆把所有东西塞一个类里面，然后你会看到他们在测试代码里写出几千行的上帝类、写出十几个类的继承链。你跟他说testNG的测试执行机制，他也一头雾水。我看到过某实际项目中使用了5年的自动化测试脚本，里面竟然是用自己的代码重新实现testNG自带功能的，并且除了增加测试代码复杂度以外毫无任何好处（难道是他们初代作者为了提高测试人员不可替代性的大智慧？），还有开发人员异想天开得用spring来封装测试类的（那他肯定没用过xunit系列测试执行器）。还有时候你会看到几千行测试数据和几千行测试预期结果放在同一个文本文件里，然后后来人找不到要找的数据，就胡乱地往这个巨大的文本文件里写一行自己要的数据，他也不管是不是跟前面的重复了。对这种，我只想说一句，那个已经离职掉了的原作者，你回来让我打一顿消消气好不好。
综上所述，基于这些原因，中小公司你想搞用户界面层的自动化测试，多半搞不好。但自动化测试不等于用户界面自动化测试。还可以搞接口，搞单元测试。接口测试是一个很适合做自动化的切入点，如果技术负责人问我怎么开始做自动化，我就会推荐他从接口测试的自动化开始。这一点对公司、对测试人员都有巨大好处，是少见的双赢。
我做接口测试工作时的体会：
- 这他娘的比黑盒测试简单无数倍，薪资竟然比黑盒测试高。
- 太容易了，好爽。
- 不要给我招懂一点技术的黑盒测试人员，也不要给我招转行做测试的初级开发。好吧，只能招到这样的。最后他们做的东西我都要返工一遍，还不如我自己做来着……算了慢慢教。如果不懂自动化测试原理，你烦我也烦。你烦做不好，我烦教不会。
- 做接口测试依赖于开发人员的配合，我们没时间通读代码（对更多的人来说，其实读也读不懂），开发愿意帮助你的话，在这个岗位上你的工作很容易取得成就。
接口功能测试是测试行业的一个黄金点。其后自然而然的你可以接触接口的压力测试，并接触正宗的性能测试。（待续）
https://www.cnblogs.com/yangxia-test/articles/4136717.html
关于测试工程师的职业发展思考
2017年，因华为裁员、中兴员工坠亡等事件，“IT吃青春饭”，“中年危机”…一词又在网络上掀起了一股巨浪。那些面临即将走上IT工作岗位，或已在IT工作岗位的青中老年们，不得不开始正视及思考自己的未来，有些或已豁然开朗、有些或已上岸、有些可能还在焦虑踌躇、有些可能一笑置之、活在当下。作为已在IT工作岗位上混迹十来年的屌丝，也谈自己的一些理解。
哲学上有三个唯心问题：我是谁？我从哪里来？我要到哪里去？这三个问题，相信混过知乎的人都知道，因为已在知乎上被大家玩烂了。当然在万千回答中，也有一些人的一番见解也是非常正视、严肃的。而今天我要发表的不是宗教哲学或人的起源，仅仅想说明在我们的IT职业生涯起始，也许我们该进行的这番思考。
从人的本能来说，活着，自然而然地就想追求幸福。只是每个人对幸福的定义不一样。也许你觉得幸福就是一家人坐在一起吃个饭、也许就是买个甜品慢慢地品尝、也许就是看一场电影…其实，幸福，就是你觉得此刻是最适合的。而此刻，即当下的你；最适合，即当下你的需求被满足了。那么，当下你的需求是什么，未来的需求又会是什么呢？可以先看看马斯洛的需求层次。马斯洛需求层次，将人的需求分成了5层次：
第一层次生理需求；
第二层次安全需求；
第三层次社会需求；
第四层次尊重需求；
第五层次自我实现。
而人只要活着，就有生存需求，即满足生理需求和安全需求；当生存需求得到一定满足后，自然而然就会追求归属需求，因为人是一切社会关系的总和；当生存与归属都得到满足了后，也许有一部分会停留在这一层次，也许有一部分人会往上一层次，追求自我实现，这也是为什么历史那么会有那么人追求名留青史的原因。
再回过头看看那三个唯心问题，首先，我是谁，即认识自我人格特点及可运用的资源；有什么人格强项，有什么人格弱项。其次，我要到哪里去，即明白自己未来想要达到的目标，未来想要达到的层次；比方说30岁、40岁、50岁在工作上达到什么层次，在生活上达到什么层次。最后，我从哪里来，即理解自己当下所处的层次；比如，我的原生家庭是什么情况、我当下面临的最主要问题是什么。从而结合三方面来制定职业规划。比如说，咱们IT测试工程师的例子如下：
下面就IT测试工程师的职业发展路径：激流勇退、退居二线，从技术走向管理和从技术走向领域专家的三方面来阐述发展；
激流勇退、退居二线
IT行业相比其他非金融行业，起薪高；相比金融行业，个人能力占绝大多数因素，无须依赖太多的其他资源，找工作更容易。因此，如果只是想在最初的几年奋斗，获取一笔相对同等年龄段里较高的收入，帮助自己生存下来，可以在有家庭负累之前，努力奋斗在项目化线上，等准备有家庭负累时，考虑退居二线，转岗需求分析师、质量保障工程师、配置管理工程师、运维或客服，甚至跳槽甲方公司做业务人员或者运维人员等生命周期更长一些、压力相对小一些的职业。主要原因是：往小了说，项目容易出业绩，对短期的收入提升有较大的帮助；往大点说，项目接触的软件过程比较全面，帮助积累软件工程过程各个阶段的流程、规范、技术知识，可以快速地掌握一个软件研发的生命周期。对于将来打算往上下游部门转岗、抑或是内部职能协同部门转岗来说，都是打下了坚实的技术基础；再往大点说，合作的人员对象比较广，从外部的客户，到内部的上下游部门、职能系统部门，建立相对比较宽泛的人际关系。这些对于无论是往内部的上下游部门转岗、抑或是职能转岗，甚至于跳槽甲方都是非常好的人脉积累。
从技术走向领域专家
靠技术吃饭，即靠能力吃饭，能力是个比较抽象的东西，无法一眼就能鉴定的。因此，很多公司在招聘高级别的技术专家，一方面，通过面试获取一定信息；另一方面，通过其他的渠道，获取候选人在原公司的工作表现情况。如果技术专家是个善于沟通表达的，那也还好，通过面试的概率比较大。如若不太擅长表达，那就难说了。再想象下，一个在某个领域里已经积累十几年的专家，找工作时，还需要自己投简历，等着意向公司进行简历筛选、笔试、面试，是不是有点low的feel？再想想，即使技术专家通过了面试，进入了目标公司，全新的合作伙伴、全新的领导、全新的工作模式，是不是都需要有一个熟悉并建立信任的过程。好点的情况，就是碰见一个伯乐，给予了比较广阔的环境供发挥，展现自我价值。而通常，都是需要从0开始，从最底层开始做起，也许就由于水土不服，新公司的发展还不尽如人意，从而被打回到了一线。再想想，如果换成猎头公司主动找到你，给你介绍高阶的就业机会，是不是感觉高大上了点。再进一步想想，新的领导也对你的过往和能力有个比较全面和深刻的认识，与你已建立了相对信任的基础；新的合作伙伴，因了解你的过往和能力，或者曾经受过你的影响，与你已建立了比较良好的友谊；新公司的一切发展是不是就有了更好的基础，未来相对的是不是也会有更多的可能性。
说了那么多，其实就是想传达的是：只能通过干活，展现自我能力，影响周围的人，影响的只能是个点；需要学会通过学习、干活修炼自我能力，通过知识传播、与行业技术沟通交流，建立比较广泛的影响，树立领域专家形象。
那怎么做到呢？
1.修炼内功
测试领域，基础设施主要涵盖软件测试过程规范、软件测试技术、软件测试管理、开发技术；应用领域层面主要涵盖被测软件业务行业知识、自动化测试原理及测试框架、性能测试原理及测试框架、兼容性测试原理及测试框架、安全性测试原理及测试框架。因此，首先，需要坚持不懈地学习编程语言及可应用的开发框架知识，建立被测系统的技术知识。其次，前期可通过不断地挑战项目，从项目参与者到项目管理者的进阶路程，以掌握软件测试过程规范、技术及管理；最后，根据发展方向，做到T型人才；在主发展方向上深耕细作，在其他辅助方面做到基础了解；比如，项目测试管理，需要在业务行业知识上深入学习，在自动化测试、性能测试、兼容性等方面做到基础学习，拓宽视野，制定更好的测试方案，以及与其他团队有效协同；
2.及时总结，写博客、做培训，分享传播知识
修炼内功时，利用框架性思维，建立学习框架。对内，及时总结，形成领域知识，增加授课课题，及时参与内部培训，分享经验总结，锻炼授课能力。对外，系统运营自己的博客。一方面，总结梳理掌握的知识；一方面，后续方便后续的回顾；另一方面，分享他人，提供一定的指导作用；建立行业技术讨论圈，树立领域影响力。
3.有条件多参与行业的培训、研讨会议，套个脸熟
有很多培训公司，会定期举办行业技术讨论会，建立讲师资源。或者定期举办培训沙龙。可以多参与，交流。了解讲师资格条件，提供授课课题，争取对外培训或经验分享。
从技术走向管理
管理是一门科学，更是一门哲学。三五人的团队负责人，叫做管理；几十号人的团队负责人，也叫管理；上百人的团队负责人，也叫管理；乃至几千几万的，都叫管理。但是不同团队规模需要的管理能力模型是有差异的。给管理分个层次，把组织一线人员开展工作及为结果负责的团队管理者，称之为一线主管；负责传达公司战术（分解KPI指标），并组织一线主管开展工作，并为KPI执行埋单的，称之为中层管理者；根据公司战略，制定战术（KPI指标）组织中层管理者开展工作，并为公司的某一块运营埋单的，称之为高层管理；制定公司战略，为公司整体经营埋单，称之为公司执行总裁；
大多数IT的一线主管都是技而优则管，技术强、工作做的漂亮，才更容易脱颖而出，同时，也是考虑一线主管需要更多地聚焦于具体的工作开展，正所谓“兵熊熊一个，将熊熊一窝”。因此，一线主管，一方面，要对自己所负责领域的业务、流程、技术的熟练掌握；确保制定的执行策略，高效且贴合实际。也是为了打造执行团队，进行人员梯队培养，积累培训素材；另一方面，由于软件行业的技术更新迭代速度快、产品的生命周期短，因此，还需要较强的学习能力，持续不断地学习行业的新业务、新技术，从而善于发现问题、解决问题，改进工作效率和质量。最后，还需要对上司指令的绝对服从，就好比如将军制定了战术，下达了任务，而任务执行时，将领根据自己的想法随意调整了方案，最后因为局部的方案调整，导致全局的战术发生了变动。这有可能带来了更好的结果，但绝大多数都是带来了更坏的结果，毕竟上司掌握的信息更多，看问题相对更全面点。退一万步说，执行过程，稳妥比风险来得更重要。
中层管理者，更多聚焦于搭班子、建梯队，上传下达、协调沟通，同时需要为新技术、新手段做决策，以及寻找自己的安全壁垒。说白了，就是一来，要建立高效的执行团队，保证工作不折不扣地执行；二来，要建立良好的人际关系，包括与下属、与协同部门、与上级，确保沟通更顺畅，资源协调更容易，从而有效地保障了工作的开展；三来，要持续的行业学习能力、技术学习能力，不断积累行业知识，建立前瞻性视角，确保团队的业务、技术水平与时俱进，跟上行业发展的脚步，以及更好为辅导、协助一线管理者开展工作。最后，因为中层管理者，脱离一线执行，当公司、行业整体发展减缓或者萎缩时，处于最容易被裁减的一拨人，因此，中层管理者相对更缺乏安全感，更急需建立自我核心竞争力，所以不要过早地放弃了技术能力，应时刻保持可管、可做的能力。同时，需要多参加一些行业知识交流分享、培训等，建立广泛的行业人际关系圈。
高层管理者，更多是为公司的运营制定战术，为具体的某一块业务运营埋单。因此，需要对外可营销、拓展业务，维护客户关系，建立有效地客户关系网及资源；对内确保业务被高效落地执行，上有领导支持、下有高效执行团队。
https://blog.csdn.net/Somnus_tester/article/details/79545302
曾经对软件测试很轻视，因为我那时很无知，只是一名普通的中国程序员，这也是那时绝大多数程序员的心态，那时中国程序员最讲究“编程才是硬道理”。
如今却非常热爱软件测试，包括软件测试工具，方法，理论，技术。因为我在3年的测试工作中，深刻体会到软件测试的重要性和趣味性。此时，我已经跳出了“小程序员”的圈子，以软件系统工程的更大视角审视软件测试这项工作。
很长时间以来我一直被下面的问题而困惑，有些问题至今仍然只是具有肤浅的认识，而且，我感觉我做的测试项目越多，阅读的测试书籍越多，我越感到我对软件测试理解的越肤浅。因为我越来越感受到软件测试的广度和深度的无限性，它像大海宽广，像宇宙那样深邃。 为什么要进行软件测试？软件测试的前途如何？软件测试的工具和思想谁更重要？软件测试的最高境界是什么？
软件测试是保证软件质量的重要活动，是软件项目实施的不可缺少的环节。软件测试的直接目的是发现软件中存在的缺陷。此为测试的有效性。
在软件项目没有结束之前的全部软件缺陷主要由软件开发人员负责，因为软件缺陷来自程序员的编程。软件项目结束后的软件缺陷主要由软件测试人员负责，因为软件测试人员没有在软件发布之前的测试中没有发现隐藏的错误。 但这不是绝对的，因为软件项目是一个系统工程，软件质量牵扯到多个部门和人员，以及需求分析，设计，编码等各个环节和过程。软件测试只能证明软件存在缺陷，不能保证软件没有错误。
软件测试不是万能的，因为不可能发现全部的软件缺陷，而且软件的功能和性能不是由测试决定的。此为测试的有限性。
软件测试目前主要以手工测试为主，自动测试工具虽然很多，但实际应用的广度和深度还有很大潜力，自动将有很大的发展空间！。
软件驱动开发的观点说明了测试与编程的关系，测试应该贯穿于软件开发的整个生命周期，编程只是软件开发的一个环节。但往往大家非常重视软件编程，把测试作为编程后的一个辅助环节。这是典型的本末倒置。 软件测试的缺陷管理流程非常重要，报告的软件缺陷的质量，应该由他人验证，做到责任明确，方法简便可行。
软件测试技术不断进步，但总体来看，国内的测试重视程度还不够，但已经发展很快。差不多两年之前，国内计算机书店中关于软件测试的书籍非常稀少，如今却琳琅满目，异彩纷呈。
软件测试是个可以很快入门的职业，门槛不高，但是，不要认为什么人都可以做好软件测试。因为会做和做好是两个概念。软件测试人员最好具有软件开发经验，理解软件工程的知识。这是提高软件测试能力的基础。对于刚刚毕业的学生，如果希望今后从事软件开发，那么，先从事一段时间的测试可能更有利于今后的编程。而对于具有多年编程经验的程序员，如果改行做测试，更容易提高技术。 软件测试不是孤立的活动或过程，需要开发和市场人员的参与和交流，需要软件质量保证人员SQA的积极配合和沟通。
软件测试的技术不断进步，与具体测试技术相比，掌握测试的核心思想比具体技术更重要！测试的最高境界在于运用最简单有效的测试技术，最大限度的发现软件缺陷!
应当承认，目前国内的软件测试工程师的地位和待遇仍然很低，而且不少测试人员存在浮躁的心态（我甚至感到整个软件行业始终存在着浮躁的泡沫）。如何改变这种局面，这应该是个漫长的过程。当整个IT业真正以客户为上帝时，当软件质量成为决定企业生存和发展的决定因素时，当软件测试工程师的测试工作给软件企业带来更大的经济效益时，软件测试工程师才会得到应有的尊重！
软件开发是一项复杂的、创造性的协作式游戏。作为游戏它自然存在着乐趣，所以程序员们才会乐此不疲，前仆后继。首先、这种快乐源于一种创造事物的快乐。其次、这种快乐来自于一种开发出对别人有用的东西时所带来的满足感。第三、快乐源自开发过程中，亲眼看到软件按自己预先设想的那种效果运行时所带来的迷人魅力。第四、快乐源自开发过程中持续学习的快乐。最后、快乐源自开发过程中，我们能象诗人一样，仅凭自己的想像，来建造自己的城堡时带来的快乐。编程的快乐在于它不仅满足了我们内心深处进行创建的渴望，而且还唤醒了每个人内心的情感。不幸的是，同样作为游戏它也有苦恼的一面：首先、苦恼来自追求完美主义。其次、苦恼来自总是由他人来设定目标、供给资源、提供信息。第三、苦恼来自于寻找琐碎的BUG却是一项枯燥的、重复性的活动。第四、人们通常希望在项目接近结束时，能收敛得快一些，然而，情况却是越接近完成，收敛得越慢。最后、苦恼来自当投入大量的辛苦劳动后，产品发布时却面临着陈旧过时的危险。作为软件开发者，我们别无选择，只有适应它们，就这样痛并快乐着地面对每一天。
来自领导的信息只有25%被下级知道并正确理解，从下到上的反馈信息不超过10%，平等交流的信息则可达到90%以上。平等造就信任，信任增进交流。有效地进行适当的意见交流，对一个组织的气候和生产力会产生有益和积极的影响。使顾客满意并和他们面对面地交流，才是蠃得市场的关键。
——引自《管理智典》
管理是一种控制性游戏，在游戏面前，你只有二种选择：或者，你确信自己能蠃，于是投入足够多的能量来蠃得一切；或者，你不进行这个游戏，放弃它。然而，作为软件项目管理者，你也应该知道，早投入、高风险才会有高回报。逃避风险是致命的，因为这也会让你得不到与风险同在的利益，久而久之，你就会面临着被市场淘汰的危险。风险是"遭受损失的可能性"，由条件、结果以及周围的环境构成。风险和问题的区别在于：风险是尚未发生的问题，而问题是业也成真的风险，昨天的风险可能会是今天的问题。风险管理主要包括下面几个方面：
第一、风险识别：
从头脑想像中抽取出各种风险并加以筛选，再加上在整个开发过程中，保持持续不断的风险发现机制，以发现新的风险。
第二、风险分析：
对风险出现的可能性和潜在的危害性进行量化分析。
第三、应急计划：
如果识别出的风险真的出现，你将采取的应急措施。
第四、风险缓解：
为了使应急计划得以有效实施，必须在风险转化为真之前所采取的措施。
第五、持续的监控：
跟踪需要管理的风险，寻找风险出现的迹象。
项目面临的某些风险可能是致命的，发生时会使项目严重滞后或直接废弃。这类风险是最需要管理的，但有效的管理它们也许会使你与你的上级发生冲突(如时间上最后期限等)，对于这类风险往往超出了你的管理权限，可以先将它们列为项目假定风险，然后把它们转交给上级来管理。风险可能出自技术、政治、经济、资源或其它各个方面，几乎无所不在，并且会对项目开发、市场占有率或是达到项目目标(如进度、预算、质量等)造成灾难性后果。但在所有软件项目中，通常会共存五大核心风险，分别如下：
第一、缺乏合理的进度安排
这是导致项目滞后的最主要的原因。首先、它源于开发人员们普遍存在的乐观主义精神，我们总是期待在实现过程中不会碰到困难，然而我们的构思是有缺陷的，因此总会发现BUG。其次、它源于一种错误的认识，人员数量和开发时间是可以互换的，既投入两倍的人数会在一半时间内完成开发工作。然而，这种理论却忽略了随着人数的增加，相应的也会增加新人培训和人们相互交流所需的负担,另外，还有任务重新分配所造成工作中断带来的负担，正如Alistair Cockburn所说："最有效的交流方式是面对面的交流"当3、5个人的时候很容易做到这种交流方式，随着人数的增长，再也很难做到这种交流方式。交流成本的增加与培训新人所需时间成本的增加、以及任务重分配导致工作中断成本的增加，直接导致一种结果：向进度落后的项目中增加人手，只会使进度更加落后。
第三、源于空泛的估算，管理人员特别是高层管理人员为了满足顾客期望的日期而造成的不合理进度安排。如果分配的时间一开始就不够，不管高层领导威胁有多么吓人，工作也无法按时完成，如果人们察觉到管理者可能滥用权力来惩罚自己，他们就会感觉到威胁，没有安全感。安全感的缺乏会让人们反对变化，而在所有成功项目中，变化是唯一不变的要素之一，除非感到安全，否则人们就不会去迎接变化，只会按部就班，这样往往丧失了很多走捷径的好机会，而这些机会原可以大大缩减时间进度的。第四、如果你没有认真估算产品规模，那么你预计的进度就是空中楼阁，唯一的依据只是你的希望。在估计产品规模时，除了正常的时间计算以外，不但应该将"可能需要做"的事情所需工作时间加上，还要将某些"可能不需要做"的事情所需工作时间加上。项目的超期不应归咎于开发者的低效率。
最后、项目的滞后不是一下子造成的，而是在一天天的不知不觉中造成的，有无数种方法可以浪费一天的时间，但是没有任何方法可以拿回一天的时间。高层管理者的不良反应肯定会对信息的完全公开造成压制；相反，仔细区分状态报告、毫无惊慌地接收报告、决不压制下级，将能鼓励诚实的进度汇报，而这会使你在第一时间掌握实际进度，把握先机，及早做出正确的修订，从而避免了晚期才获得这些实际信息时，那种无力挽天时的无奈。此外、也可以在项目管理中设定一个合理的进度安排和一个具有挑战性的期望目标完成时间。期望目标和合理进度不同，期望目标完成时间，可以设为项目完成的成功率在30%左右时的日期，这样很具有挑战性，但不能强迫要求必须完成此期望目标。毕竟，合理进度安排才是更合理的时间安排。另外、需要指出的是现代敏捷方法论对此进行了有效改进，如XP(极限编程)中，就利用用户素材与CRC卡，进行优先级划分并进行快速增量迭代开发，针对原来开发的产品或第一次迭代开发后的原型完成的功能量，来计算功能点，从而估算每个CRC卡的功能点，得到总功能点来推导出比较准确的进度安排。
第二、需求的变化
从项目的角度来说，需求总是向着膨胀的方向在变化。就连去掉某些已经做好的东西，也是一种膨胀，因为它增加了工作量。开发人员交付的是用户满意程度，而不仅仅是实际的产品，用户的实际需要会随着程序的构建和使用而变化。要知道，一个活着的软件必须面对变化，只有死掉的软件才不会有需求变化(没人用了)，我们应该尽早面对现实，而不是逃避，事先为它们做好思想准备。变化是好事不是什么坏事。同样，现代敏捷方法论强调对需求变化的快速响应，如XP(极限编程)就采用快速增量迭代开发，来在短时间内开发出功能不断增强的原型软件提交给用户使用的方法，来快速响应需求的变化。
第三、人员的变更
在我们有些管理者中，总是假设开发者都是可以随便替换的，新员工马上可以取代离去的老员工，多么愚蠢的假设。解雇员工或高的员工替换率最大的影响，是使软件项目失去了连续性。这是在抱着这种假设的团队文化中，大量员工会在项目进行到一半时离开，新来员工往往需要1到3个月的上道时间，在这段时间内，他们做不了什么，还经常需要其它老员工的帮助，从而浪费了其它老员工很多不必要时间，导致项目进展更加缓慢，最终造成项目的很大损失。
另外、还有一种现象在中国软件事业中普遍存在，当正在进行一个项目时，另一个项目由于进度落后或最后期限等原因所致，高层管理者就会从你的团队中抽掉一些人去到另一个项目中补墙。这种拆东墙补西墙的作法，往往导致的结果是两个项目都会落后，因为它不仅十分错误作了团队人员可以随意替换的假设，而且还作了将开发人数与开发所需时间可以互换的错误假设。盲目的认为，投入大量人数后，新人马上会投入新的工作，这样项目开发所需时间就会成倍缩短。在这种组织文化中，是不会形成一支稳定的团队的，成员整天只会忙碌着补自已的墙或为别人补墙，充当着类似消防员的角色，那儿有火那儿就有我们的身影。
同样，现代敏捷方法论非常注重人的能力，如XP中通过权力下放、教练角色、将团队紧密围在一起并结对编程、小团队组成等方式，来组成一个强有力的团队，由于有凝聚力，所以很少有大的人员变动，他们往往可以完成两倍于他们人数所能完成的任务。非常小的团队能够产生非常大的物质生产力，有时候，小团队可以在很短时间内创造奇迹，而大型团队极少能做到。但是，小团队却往往得不到足够的政策支持，从而导致任由团队超编，这是一种病态组织文化所致。作为管理者必须明确知道，拥有一支稳定的、有凝聚力的开发团队是组织最大的财富，而不是障碍。
第四、规约崩溃
这种情况只有两种结果：要么发生，要么不发生，不会有不同程度的影响。但它真的发生时，它会直接毁灭你的整个项目。在项目启动之初，项目各方需要通过一系列商谈来确定需求的范围，规约崩溃就是指这个谈判过程的崩溃。在商谈期间，很多时候当遇到严重冲突时，由于双方都不愿意让步，但又不想放弃这个项目，从而导致这些冲突被掩盖起来。最终项目便朝着一个带着缺陷的、含混不清的目标前进了，被掩盖的问题暂时不会打扰你，但不是永远。尽管你可以含混说明一个产品，但不能含混构造一个产品，所以，最终在项目晚期这些问题将发生，在大半甚至所有预算时间和金钱都已付出的时候，此时，任何一方不再全力支持，都将使项目被取消。任何规格文档中的含糊标志着不同的系统参与者之间存在着未解决的冲突。只要在开发过程中有多个参与者，就一定会有冲突存在。谈判困难而调解容易，如果两个人的利益是完全或部分相斥的，预先做好安排，准备好请双方通过调解来解决冲突。同样，现代敏捷方法论通过客户的积极参与胜过合同谈判的方试，来尽早发现和避免规约崩溃。
第五、低效率
对于项目成功而言，项目人员的素质、人员的组织和管理是比使用的工具或采用的技术方法更重要的因素。团队质量是项目成功最大的决定因素，对人的关注、激励和培养胜过一切。项目管理人员的职责不是要人们去工作，而是给人们创造工作的可能。创造力来自于个人，而不是组织架构和流程，项目管理者面临的中心问题就是如何设计架构和流程，来提高而不是压制人们的主动性和创造力。通过权力的向下委派，从而产生了改进的质量、提高的生产率、高涨的士气，进而使中心的权威实际上得到了加强。就整体而言，组织机构会更加融洽和繁荣。增加加班时间只会降低生产力，压力之下的人们无法更快地思考既也会降低生产力。使用压力和加班的真正原因是为了在项目失败时让人们看上去能好受一些。
正式的过程改进程序需要花钱、花时间，特定的过程改进工作还会延缓项目进度，尽管最终会体现生产力上的收获，它们也不可能抵消花在过程改进上的时间。多种技术的改进程序(如CMM提级)很可能让项目比不实施这些程序完成得更晚，对于人员超编的项目，标准过程会为多余的人们制造出足够的工作，让所有人都忙个不停，尽管很多是无用的，这也导致生产率低下。人员超编的团队往往生产率低下，因为它们团队内部耦合度提高，会议时间、重复劳动和无效工作都会增加。理想的人员安排是在项目的大部分时间里由小型核心团队来做设计工作，在开发的最后阶段再逐渐加入大量人手。如果不大幅度减少调试的时间，就没办法让项目大幅度提前完成，而要成比例减少调试时间，就需要成比例增加设计所需时间，因为绝大多数的错误源于接口缺陷，编码前进行的正规而完善的设计，可以大幅度减少错误。同样，现代敏捷方法论通过注重人、快速迭代开发、自组织的团队和提倡可持续的开发速度，来避免跑的过快导致团队精力耗尽、出现短期行为而导致崩溃的问题，从而保持了稳定的生产率。
精兵简政是失败公司使用的办法，它让员工负担失败的责任。成功公司的目标应该正好相反：兴旺、发达、而人性化。
——引自《最后期限》
企业的最大风险则与价值相关：在低价值的项目上浪费资源，付出高价值的机会成本，就这是企业最大风险。勇于承担风险是好事，但必须由收益来导航，愿意承担多少风险，必须取决于能获得多少收益。真正的项目评估不是倾向于不断削减成本，来提高价值，而是在风险与价值之间取得平衡点。通过不确定的价值和不确定风险组合效果的净收益图，来指导你把资本投入到最适当的地方。我们每个软件从业人员都必须明白：顾客真正需要的，是我们能够给他的、某种他想得到的利益 。
https://blog.csdn.net/suizhituan8337/article/details/80181335