软件工程师的哪些技能是值得CEO学习的？显然，软件工程师是逻辑的，高效的，注重细节的，有计划的，并且大多数CEO也是如此。但是，软件工程师还有一些更微妙，甚至是令人懊恼的品质，那么CEO是否可以从中学习呢？
1.懒惰
优秀的工程师（不只是软件工程师）是懒惰的：他们喜欢自动化重复性的工作，不愿意做任何不必要的工作。会议和文书工作通常都属于这一类。通过避免不必要的工作，软件工程师可以更高效，并且有更多的时间去做更多有用的工作。
CEO也应该力求高效率的偷懒。删除不必要的活动，把精力和时间放到提升价值的任务中。在大多数情况下，重复做同样的事情是毫无意义的。如果一定要反复做的话，那么用自动化的方法。如果你做不到自动执行的话，那就委托出去！
2.经常失败
软件工程师有着与发明家和科学家部分相同的特质——都饱受失败的风吹雨打。通常情况下，这是有意的，但有时是实验性的。这不是鲁莽，而是一种无畏。未知是一种需要探索的风险，你无法拒之于门外。专注实验和原型能让人快速学习。
CEO让自己适应这种做法将会产生巨大的影响：开拓新市场，尝试不同的方法，甚至研究趋势和预想。关键是要失败得既快又不浪费成本，并且牢记目的。（如果你觉得这听起来有点像精益生产，那么就对了。）
如果你不是时常失败，那么说明你没有尝试任何新的东西。
3.制造问题
软件工程师会积极寻找问题，有时甚至会故意制造问题。问题是变相的机会，但是找不到问题并不意味着没有问题。软件工程师宁愿毁去成果也要看看会发生 什么。他们编写测试只是为了确保所有的边缘情况都有效。他们实施监控系统，这样出了问题就会被警告。总而言之，他们会聆听人们的抱怨——因为这可能会有惊 喜，这和自己找问题是一样的。
初创企业的CEO应该学会如何系统地做到这一点，探索机会空间，直到找到需要解决的正确问题，用正确的解决方案，针对正确的市场，在正确的时间。有助于企业站稳脚跟。而知名企业的CEO在这方面做得很好，他们将制造问题作为持续改进的一种形式。
4.亲自动手
软件工程师往往不喜欢纸上谈兵。他们不仅战斗在编码前线，而且还与用户和客户合作来了解各种要求和投诉。答案不是你坐在办公室就会出来的：它们在工 厂车间，在客户的办公室里。学习软件世界关于用户体验的概念，研究它应该如何适用于你的供应链，以及你的员工。一个新的角度可能意味着意味着一个巨大的惊 喜。
5.忽略人的因素
当软件工程师工作的时候，往往会忽略人的因素，尤其是当他们正在努力实施改进的时候。他们认为，大多数问题起源于系统某处的约束——可以是时间，金 钱，动机，激励，标准，也可以是过程——个人往往无力解决系统。文化，同伴的压力，以及对现状的偏见是需要克服的强大障碍。尚未解决的事情，改变系统是紧 悬软件工程师头顶的宝剑，这些都与人的因素无关。
CEO通常惯于应付政治系统和与人打交道，所以他们可能会倾向于将风险和指责归派给某些个人。有时候可能这也不失为一个不错的方法，但如果你回顾过去的人所运行的系统，那么你或许会发现系统才是问题的根源。
请记住，没有系统是完美的，没有系统是神圣不可侵犯的。
6.杀死你的宠儿
工程师不怕测试自己的想法，并且如果证明是不切实际的，也会毫不犹豫地丢弃它们。他们经常会通过摒弃宝贵的想法和业余项目来“杀死他们自己的宠 儿”，无论这个宠儿有多么地令人着迷，如果它们不能工作的话。CEO可以通过面向现实审核他们的想法，也可以通过客观地评价他人的表现来“杀死自己的宠 儿”。 （显然杀人是犯法的，此处并非真正的人。）
7.发呆
软件工程师常常发呆，但他们称之为系统思考：一种让人将一系列复杂的相互关联的系统视为一个整体的能力。系统思考可以说是从复杂性中生出连贯性和简 单性最重要的（有时也是最恼人的）催化剂。软件工程师擅长系统思考，解决问题通常要求他们平衡包括时间、资金和质量以外的多重约束。虽然这种习性在决定去 哪里吃午饭时让人非常懊恼，但在处理意义重大的问题和寻找机遇的时候，非常有价值。
CEO必须时刻处理多个相互关联的系统和冲突约束。孤立地检查每个部分是不够的——你还必须考虑所有潜在的相关关系和力量。系统思维同时包括从多个 角度出发的，高层次的和细微的思考。由此看来，一个完整的模型可作为一个识别、组织和解决子问题的框架来提供服务。通常，若干个简单的理念和规则就足以让 一个乱七八糟的败笔蜕变成一个整体化的结晶。
软件工程师不是因写代码而获取报酬：而是因思考。系统思考在你写代码的时候是不会发生的（不过有时候，两者可能会同时进行）。所以，如果你看到一个 软件工程师在发呆，经常发呆，那才是真正干活应有的样子。简单又优雅的解决方案不是从天上掉下来的，而是通过不懈地思考和追求得来的。
创造力
给自己一点安静的时间，发挥你所有的想象力和创造力，来承担你作为一个CEO需要解决的问题。分析问题的错综复杂和约束条件。猜想它们之间的相互作 用力。从多个角度加以思考。寻找有助于解释或简化发生了什么或者你想要发生什么的模式和类比。并且当你发现一个可能的回答时，运行一个快速又廉价的实验来 测试。然后重复。循环往复。你的工作，就如同软件工程师的工作一样，是永远做不完的。
作者：小峰
来源：51CTO
