本篇文章5800字，读完约15分钟
少管理，尽量用技术手段解决问题。
8月30日，我在ego主办的gtlc技术领导峰会上做了主题演讲。这篇文章是基于这篇演讲。顺便说一下，自我活动是专业组织的。
会议的主题是技术领导力。今天有许多首席技术官出席。我记得我第一次听到cto这个名字是在20年前，充满了钦佩。当时，我眼中的首席技术官是这样的:
几年后，我自己的名字终于和首席技术官联系上了。那时，我这样看着自己:
后来，在我长大并与许多首席技术官交流后，我发现在其他高管眼中，我们似乎是这样的:
还是像这样:
但是我已经很多年没有做cto了，所以我去找了一些仍然是cto和技术总监的朋友，问了他们三个问题:
1.你的技术领导过程中最麻烦的三个问题；
2.您的解决方案；
3.你工作中最重要的三个收获。
他们都以极大的热情给了我帮助。
这家初创公司的一位首席技术官写了一封很长的回信，内容非常生动丰富，所以我把原文贴在了这里。
首席技术官的痛苦
1.专横的总统批评和质疑
我认为我做得很好，但我经常达不到一个强有力的首席执行官或其他直接联合创始人的期望。我被批评和质疑，我的自信是疯狂的。
疼痛指数:* * * * *
2.时间紧迫，丑陋已经显现
出于本能，我想设计一个更灵活、更通用、易于扩展和维护的系统，但是需求需要快速上线，而且时间和人力都是不允许的，这导致了许多难看的实现。我经常有重建它的冲动。
疼痛指数:* * * * *
3.工作强度太大了
在高压下工作也很紧张，我觉得我的大脑几乎不能动，但我必须确保我和我的团队能够高效地工作，并且犯更少的错误。
疼痛指数:* * * * *
4.需求变化太快
需求变化太快，技术文件、使用文件等。不能完全跟上。系统存在于每个人的大脑中，信息同步往往不及时，导致沟通效率低下。通常需要阅读代码才能知道发生了什么。
疼痛指数:* * * * *
5.所有部门都有许多紧急需求，他们都觉得很容易。
金融、人力、营销和运营领域的所有兄弟团队都有需求，他们都说需求很迫切。他们都觉得需求不大，开发可以在短时间内完成。
疼痛指数:* * * *
6.讨论策略和需求，不要参与
通常，经过几个共同创始人的讨论，战略和要求最终确定，开发被动地按照顺序实施，缺乏对背景和背景的理解，实施后的操作效果往往未知，根本没有参与意识。
疼痛指数:* * * * *
7.需求直接发送给下属
为了更快，有些需求直接超出了你的能力范围。有时候你不知道什么时候上网。老板突然问了相关的问题，却无法回答。他还被问到为什么他的系统如此无知。
疼痛指数:* * * *
8.各种非常规操作、人工维修
各种奇妙的数据修复需求，以及非常规的操作流程，都需要手动执行，有时需要手动修复错误，而刚才花精力修复手动错误
疼痛指数:* * * * *
9.没有人可以被招募，现有的人已经辞职
总是找不到可靠的开发、测试或做好工作的人突然提出要离开，手忙脚乱。
疼痛指数:* * * * *
10.下属们打碎了篮子，擦了擦他的屁股
下面的弟弟有点疏忽，他又捅了捅篮子，需要帮忙找虫子，擦屁股，到处灭火。
疼痛指数:* * * * *
11.有多重角色
具有多重角色(架构师+核心开发+运营与维护+dba+管理配置+测试结果验收等)。)，我经常不得不在各种情况下快速切换(例如在线，有紧急问题需要检查或修复)，我被问及这样一个简单的问题在出现错误时怎么会出错。
疼痛指数:* * * *
12.家庭投诉
儿媳、女朋友和宝宝抱怨，比如他们怎么越来越不关心我们，可以和你的电脑睡觉。
疼痛指数:* * * *
我也有同感。我真的希望我能有一个系统的方法来帮助他完美地解决所有的问题，但是坦率地说，我没有。
观点1:没有灵丹妙药
在软件开发的管理过程中，只有适度的改进，没有灵丹妙药可以治愈所有的疾病。有些人可能会问，这样的观点有什么用？有用的是，不要试图找到能治愈所有疾病的灵丹妙药。我们最好在工作中适度提高，通过手术解决问题。
我曾经工作过的公司曾经花费了大量的精力来重塑整个软件开发过程，按照软件工程过程来管理它，并使用项目管理系统，但是最终，我还是不得不屈从于事实。
当然，我对我朋友的痛苦仍有一些建议。接下来，我将谈论一个非常激动人心的观点，这也是我今天最重要的观点。
观点2:建立一个优秀的技术团队首先是首席执行官的责任
因为高水平的技术团队是互联网公司的核心竞争力。
许多首席执行官都说我不懂技术，但我想说的是，如果你认为技术是一个麻烦，它将是一个麻烦。
我见过许多有权势的首席执行官试图以销售和运营的方式管理技术。一些技术人员可能会暂时接受这种扭曲，但这就像娶了一个绝色美女回家，只让她为你做饭。
有人说马云也说他不懂技术。让我们看看马云说的话。他说因为我不懂技术，我们公司的技术是最好的。如果我不懂技术也没关系。我们应该尊重技术，热爱技术。今天，当代码农民这个词泛滥的时候，作为一个程序员看到尊重技术，我非常感动。
除了尊重，工程师最看重什么？我有一个朋友的官方号码(道尔的独白)，并写了一个非常有趣的例子:
[一位在线教育的ceo问我，我想找一个技术专家，发现很难。每次我说到最后，人们还是不想来。我问他:你怎么说话的？他回答说:我们的系统不太复杂。我相信你能胜任这个职位，因为你在某家公司有技术背景。我说，“那个人肯定不会来。原因是技术人员最关心的是在新环境中提高自己的技术水平，而没有技术挑战的工作对他没有吸引力。”。】
让我做进一步的分析。首席执行官应该对工程师知之甚少。如果我没猜错的话，首席执行官可能有营销背景。这种谈话就像对销售人员说:我们这里的客户很容易处理，预算也很高。简而言之，人们很愚蠢，而且很有钱，所以快点来。销售人员会很高兴听到这个消息。当技术人员听了他的话后，他的第一个想法是:你的系统很简单，你还是打电话给我。你认为我的水平也很一般吗？会觉得受了侮辱，不想谈这件事。
给一个栗子，我建议这样说话:
我们的技术团队一直在努力奋斗，但是现在当用户数量增加时，系统就不能支持了！
每天，大量用户责骂他们的妻子并失去她们。我们队现在应付不了！
此外，我们的用户增长非常快，预计在未来两年内将增长几十倍。只有业内最强大的系统才能使用！
我问我的知识渊博的朋友，让我来找你！
但是因为我们还没有销售收入，我们不能给你很高的现金，所以我们不敢来找你！
但是这个星期真的崩溃了，所以我敢问你，为了我们热情的用户，不要让他们失望！啊，啊，啊！
观点3:工程师最看重:尊重、成长和挑战。
当然，总会有例外。我要谈谈我自己的栗子。
当我第一次成为一名技术主管时，由于我糟糕的管理才能，我经历了一个特别悲惨的转变过程。
在此期间，我的团队增加了一名新工程师，他是我以前公司的老同事。我刚进那家公司时，他带我去工作。他非常熟悉那家公司的技术环境和系统，我给他留下了非常好的印象。当他加入我的团队时，我认为他会给我很大的帮助，所以根据我的理解，技术人员最关注挑战和成长，给了他所有最新和最困难的工作，但是他的表现远远没有达到我的期望。我们都很难过。
公司及时提供了一个关于人的个性的培训。根据培训老师的说法，人可以分为活泼型、力量型、完美型和平和型，大多数工程师都是完美型。但是我突然意识到新同事很平和。
平和型不喜欢新事物，但它能让熟悉的事物变得越来越好。
我非常开心。当我第二天一早到达公司时，我把他重新分配到只做现有系统的维护、操作和维修。
对于当时的互联网公司来说，系统运行和维护维修的任务非常繁重，而且经常令人头痛，因为典型的工程师喜欢新事物，学习新技术，做新项目。
但从那以后，他在维护方面做得很好，他也很开心。
这个事件是我领导成长的一个里程碑，我获得了比写程序更大的快乐，那就是来自人们的快乐。我意识到:
观点4:最大的力量在于人性。
作为一个领导者，观察人性，随需要而动，充分发挥人性的光辉，必然会带来生活的大和谐。否则，如果没有发挥正能量的渠道，它将不可避免地变成负能量。
前任首席技术官列举的大部分痛苦都与需求有关。在许多互联网公司，特别是面向应用的公司，核心矛盾是需求和需求的变化。
我们应该如何看待需求的变化？
软件业一直把建筑业作为参考和隐喻。例如，建筑和项目这两个词都来自建筑业。
作为程序员，我们当然希望在开发之前尽可能多地确定需求。因此，我们告诉需求方和业务方，事实上，我们开发的软件与盖楼的相同。谁见过原来有5层，最后有20层的建筑？因此，作为业务方，您应该在开发之前确定所有需求。
但事实上，软件毕竟不是架构。
几十年来，需求一直在变化，现在变化越来越大。所以它实际上是可以改变的。
此外，没有人能从一开始就考虑所有事情，并且永远不会改变它。我们能自己做吗？不，那你不能问别人。
传统的软件工程是以实现为中心的，它从零开始就面临问题，所以它注重实现。
但现在我们正在从中国向中国创造转变，创业和创新的整个过程就是创造和探索需求。许多初创企业一直在探索，但最终没有创造出有效的需求。如果一家初创公司在灾难发生后发现了真正有效的需求，那是非常了不起的。怎么可能要求业务部门在一开始就确定需求？
因此，应该鼓励需求的变化。
观点5:传统的软件工程已经过时，企业家精神的核心是探索需求
然而，不断变化的需求会带来很大的问题，这将导致产品和技术的责任界限不清。那我们该怎么办？那就打破界限。
it行业最早流行的组织模式是企业对技术公司，这是最清晰的边界模式，也是效率最低的模式。
最有效的模式是组建一个产品和技术团队，共同为产品目标负责。
当然，工程师也应该参与设计，而不仅仅是编码工具。
每个人都是一个团队，为了一个产品目标一起工作，而不是把我的专业绘画当成监狱。我们不仅要知道自己的特长，还要稍微知道别人的特长，努力成为一个多面手。不懂技术的产品经理不是好的操作员。
观点6:欢迎和支持需求及需求变化是首席技术官的职责
观点7:管理和控制需求以及需求变化是首席执行官的职责
这两个句子是同一枚硬币的两面。
但实际上，大多数情况恰恰相反。每个人都在花费无尽的时间和精力讨价还价，沟通成本和交易成本变得非常非常高。
当然，做到这一点并不容易，世界上最珍贵的东西是信任和真诚。
信任也是生活中非常重要的能力。
作为首席执行官或首席技术官，找到值得信赖的商业伙伴、建立信任和坚持信任是一项非常重要的能力。
坠入爱河很容易，但结婚并珍惜它却不容易。
如何赢得信任？我认为有三个词:真诚、能力和开放。
以下是我采访结果的一些摘录。
[所有问题的健康解决应该基于人与人之间的理解和信任，然后应该应用基于此的系统。如果权力或沟通不足，这只是一个肤浅的解决方案。为下一次和解增加障碍。
首先，技术领导者应该在公司内部树立威信和信任。其他部门的负责人可以放心给你东西，建立一个可靠的形象，同时建立个人关系。例如，我在R&D部门工作时，R&D经常受到销售部门的骚扰，这主要是通过规则来解决的，为了在双方之间建立信任和个人关系，经常需要麻烦运营维护部门。在我的职业生涯中，与产品人员的协调问题处理得很好。首先是在产品人员之间建立信任，毫不犹豫地满足合理的需求，只用三个字回答，没问题。
第二，对于可以优化的需求，提出你自己的想法，并根据原因与产品进行谈判，直到你被说服。
第三，需求之外的额外功能，无论是与体验还是功能相关的，都应该与产品一起讨论和实现。
第四，为了给R&D争取额外的时间，一般程序员的估计时间要么是故意拖延，要么是乐观的，这就需要合理的分析，以便他们能够认识到并在内部和外部达成理解和一致。】
观点8:去他的关键绩效指标
这是kpi
也许管理专家会鄙视我，但我不是孤军奋战:
索尼执行董事杜丽中毁了索尼的绩效考核
我们必须放弃雷军的kpi
很多时候，我看到kpi是一群假装写作的人和一个假装观看的人。当然，我不否认kpi可能是管理销售和一些职能部门的好工具。
观点9:创新是一件小事
创新与技术领导力高度相关。
大多数人可能认为创新就像叶孤城的把戏，需要伟大的头脑，不知何故，一个惊天动地的想法出现了。但是我看到有很多创新，就是做了很长时间的事情，慢慢的磨砺，有一天我偶尔会得到一些东西，比上一代好一点。不要只看最后一个烧饼，更重要的是慢慢磨前面的那个。
例如，我采访的一个朋友告诉我一个栗子。在开发游戏的过程中，他们发现他们使用的开发工具每次都需要很长时间才能启动。
在开发过程中，程序员经常需要调试，每次修改代码都需要很长时间才能重新启动，所以程序员不得不在那里等待。然后他们在这件小事上做了改进，花了很大的力气想办法加快启动速度，结果，他的开发效率大大提高了。
我们有许多这样的平凡小事可以创新，值得创新。
观点10:减少管理，尝试用技术解决所有问题
举一个非常简单的例子。很多年前，一家公司为我开了一个服务器账户，并把它发到我的邮箱里。我发现账号和密码都是我名字的拼法，我说你这样做不安全。另一位技术主管立即表示，他会告诉工程师，密码将来应该加强。我想，为什么要让人们记住一件事，而不是用技术来解决它？
我们给出了一些建议:
开发一个自动生成账号和密码的功能，当然，密码强度应该很高；
密码通过两封电子邮件发送；
用户第一次登录，强行改变密码和强度；
如果一个新帐户24小时没有登录，它将被取消，用户将在给用户的电子邮件中得到通知；
如果一个帐户在一个月内没有被使用，提醒管理员是否清除它。
所有这些都很容易想到，但有必要树立使用技术解决所有问题的意识，而不是使用管理。
因为管理往往是反人类的，所以当我们为用户设计产品时，我们会尽力顺应人性。为什么我们要对员工反人类？
我认为下面这段话很有启发性，摘自《谷歌将带来什么》:
[这仍然是谷歌的世界观:生产出比你想象中更多的电力，创造和管理丰富的资源，而不是控制稀缺的资源。
戈尔在谈论我们不能做什么，谷歌在谈论我们能做什么，从中我们可以看出政治家和工程师在思维概念上的明显差异。
谷歌人会在发现问题后寻求解决方案。他们会识别某些需求，找到某些机会，然后通过创新系统地、合理地、积极地解决问题。】
发这张照片，让我们骄傲地用技术解决所有问题，否则我们会被小偷看不起。
