团队管理

测试小组、测试小团队、测试部等等是以一个独立的team存在，然而这里说的独立并不是真正的独立，只是以一个组织的模式去倒退。下边是集体的一些思考，仅供参考。 试用范畴试用于刚建设的测试部门、测试小团队、测试小组，处于所有还需优化和晋升的阶段试用于成长中的小型测试部门，处于变革和稳固阶段测试团队人数大概在40人以下有肯定的流程制度撑持对于测试中心建设不太适宜，但有些内容可参考（因为测试中心我感觉更多的要体现各种体系建设）## 建设思路 1、 基础设施 基于业务自身，进行流程、制度、标准优化设立监控点，建设执行、查看、监督机制基于产品状态，优化测试环境基于客户化场景，建设场景案例库目标：夯实基础设施2、人才梯队建设 打造外围、骨干、根底成员三阶能力建设不同等级的人员进阶晋升计划目标：打造强业务团队 + 为公司其它部门提供人才输入3、组织能力建设 建设黑盒、灰盒、白盒领域专家技术团队晋升测试设计、专项测试（自动化、性能、平安、稳定性、兼容性）能力业务或岗位进行备份目标：打造整体对接+深度对接+广度对接的测试对接模式4、组织气氛建设 举办不定期及定期的团建流动（模式最好是调用团队的力量，全员加入）举办不定期及定期的茶话会（模式不限：技术交换、生存履历分享、自拍游览分享、观影流动、棋牌游戏）注：局面不要太强烈哈轮岗治理（外部轮岗+内部轮岗）目标：建设建设良好的沟通反馈机制5、技术平台建设 这个临时不具体说，后续会独自整顿。 兼容性测试稳定性测试性能测试自动化测试白盒测试安全性测试测试工具开发目标：晋升测试部门整体技术和作战能力6、常识体系建设 测试框架体系整顿测试文档治理（各种计划、报告、打算、技术、模板、流程、制度等文档归档）错题库建设场景库建设目标：测试常识积攒，厚积薄发7、其它方面团队建设比方： 组织绩效建设（绩效指标、衡量标准等）日常人员治理（沟通治理、事务管理等）测试环境治理（设施治理、环境保护等）测试平安治理（人身安全、环境平安等）。。。。。。（还有一些内容，可依据理论状况定）

王玥 连界董事长、翻新策略专家、产业生态投资人王玥学生是国内出名的翻新策略学者，产业生态投资人，在北京大学国家倒退研究院、人大商学院、香港大学SPACE中国商业学院专任导师，译作经典著作《企业生命周期》，推出《翻新+法》、《转型》等书籍；王玥学生创建的连界，旗下包含连界翻新和连界启辰资本，以产业服务综合体“翻新飞地”为载体，连界保持于帮忙国央企及上市企业组建策略翻新体系，实现翻新增长与生态布局。同时，连界以母基金加直投的形式与投手型基金深度单干，笼罩二十余家上市公司以及200+高成长我的项目。 —文 | babayage编辑 | 笑 笑作为间断创业者，王玥横跨征询、培训、投资等多个畛域——甚至还开了一家书店。交换后刚才发现，业务多元尝试的表象之下，暗含着一以贯之的价值理念：面向产业公司，提供增长服务。 立志服务中国版李·亚科卡 大学期间，学校激励理工科学子多多浏览工具书，用业余时间晋升例如“如何把机械制图做好”这类业余能力。可就读于汽车业余的王玥偏偏爱看杂书，一本名为《援救沉船：李·亚科卡自传》的人物传记更是间接左右了他的人生方向：“李·亚科卡是福特‘野马’之父，也是援救克莱斯勒的英雄，这本传记让我对企业家这个群体产生了浓重的趣味。”下定决心来到汽车行业，更重要的起因源自王玥实习期的一段经验：在某汽车国企负责领导助理的角色，不堪称不受器重，但大至企业外围竞争力，小至员工的工作状态、精神面貌，都让王玥感觉到暮气沉沉。最触动他的一幕，是在偶然间发现有个别员工会成心在白车身上制作瑕疵，以此宣泄不满。“中国的李·亚科卡在哪？我心愿服务这样的企业家，而不是在稳固却有望的气氛中蹉跎。”毕业抉择之时，他的背后有保研机会，有曾经过关的GRE、托福问题，但最终他抉择走进社会，“一门心思想好好锤炼一下”。 2022年·玥堂主复盘成长之路： 以企业生命周期实践来掂量我当年实习的那家企业，应该是处于官僚晚期：企业气氛很好，领导并没有特地大的架子，常常带着我去打乒乓球、踢足球；但另一方面，气氛看似不错的背地，是人人都晓得有问题、却没有人裸露问题，最重大的问题是管理体系残缺、企业文化齐备，但翻新隐没了，我过后参加了图纸绘制工作，发现基本没什么翻新。我很庆幸本人浏览了很多人物传记，绝对同龄人更加理解“哪些因素对人的成长更有意义”，这也间接决定了我第一份工作的抉择。 2001-2004 征询公司打工人卷王级致力，锻压式成长 2001年，王玥抉择加盟某征询公司作为事业人生的终点。这家公司的开创团队阵容奢华：老板是罗兰贝格中国区的第一任总经理，另三位合伙人别离是麦肯锡前合伙人、贝恩征询（Bain Capital）中国区合伙人、BCG纽约办公室做到最高职位的中国人。在清华科技园边上的一个老破小办公楼里，抱定“打造中国麦肯锡”的信心，四位单干人拉来了一批志存高远的青年精英独特上路。对于应届毕业生来说，征询公司的工作模式绝似锻压：疾速成为精钢，或者疾速宣告报废，“大部分行业都会为年轻人提供绝对宽松、容纳的起步期，但征询行业客户是用钱买成果，人家按人天给钱，就算你是个小毛孩子也得给客户足够价值的回报”。王玥还记得第一次为客户提供BPR（Business Process Re-engineering，流程再造）服务，他没日没夜地梳理、绘制客户的各种流程，可不久便发现这基本不是客户须要的，“画流程不是什么难事，客户办公室的人能画得更准、更利索，他们须要的是你们来找到现有流程的问题，并且通知我改良办法”。超高压的本职工作之外，王玥还被动请缨整顿几位合伙人多年来积淀的心得笔记，在我的项目制、深度定制化的服务信息中，尝试提炼标准化、结构化的知识库。这项工作简直吞噬了王玥3年间全副的业余时间，但他排汇的营养、取得的成长，也远超同侪。2004年，这位“卷王之王”带着远超工夫线的历练，正式开始了人生第一次守业。 2022年·玥堂主复盘成长之路： 年轻人进入征询公司的利弊剖析：利，首先是疾速、全面的认知商业逻辑，绝大部分工作都是从钉子做起，视线局限在部分的部分，而征询公司开局就是大视野；其次，高强度的成长环境，真刀真枪的实战气氛，你必须要以解决问题为目标去排汇大量商业常识；第三，疾速锤炼商务交际的根本生存技能，表白、礼仪、如何让人违心与你交换、如何实现一次胜利的汇报……弊，首先是广度无余、深度有余，征询模式决定了你不可能只深刻做某个畛域；其次就是隔靴搔痒，一个外来人，挑毛病容易治病难，都说征询行业有三拍：拍胸脯保障、拍大腿吹牛、拍屁股走人，人造的模式缺点注定了会有如此负面的印象；第三，征询企业——除了头部企业之外——现金流十分不稳固，并且增长极度依赖“人”。这些问题当年我就意识到了，但年老的局限在于，会以“头疼医头”的模式去优化迭代，短少跳到更高层次上纵览全局的能力。所以，我的第一次守业，次要围绕如何躲避征询公司现金流不稳固、过于依赖“人”这两个问题构思的。 2004-2015 创建凯洛格征询年入3亿的遗憾与不甘 2004年，25岁的王玥拉上两位征询行业的年轻人，从如何去工商局申请执照学起，开始了蹒跚学步的守业历程。吸取前一份工作的教训，凯洛格将征询与培训合二为一，通过高端导师培训，解决咨询服务内容薄弱、服务周期长、现金流不稳固等问题；与此同时，为了防止传统培训行业，企业被明星导师绑架的常见Bad Ending，王玥向影视圈大佬求得真经，致力打造“牢牢把握优质剧本创作源头+一直造就优质新人导师”的推陈出新模式，相当程度上升高了征询培训模式对明星个体的依赖。王玥的好友评估他有一种“生而为守业”的优良直觉，能锁准行业外围因素、指标动摇、伎俩敢想敢做，在他洞察到培训行业的外围资源是“高权威性常识而非高知名度导师”之后，王玥飞赴美国、敲开了哈佛商学院的大门。“咱们没有先例。”“这些公司是不是哈佛商学院想服务的？”“相对是。”“那你为什么不让我试试，我代表哈佛商学院，服务中国1000家最优良的公司？”“……咱们为什么不试试呢？”颠峰期间，凯洛格年收入破3亿元，成为征询行业的景象级新军。然而，回顾这段守业经验，王玥却有着不小的遗憾和不甘。 2022年·玥堂主复盘成长之路： 若干年后当我成为了一名投资人，常常说不要与趋势为敌。明天回想起来，当年的大趋势必定不是做咨询服务。已经有敌人介绍我参加一位互联网大佬的创业项目，我过后本人的公司做得很红火，我敌人在美国读博、通电话时我就感觉到他也不想回来守业，最终咱们都错过了最大的那波浪潮。前几年我遇到那位大佬还聊起过这件事，小小感叹了一下。除了互联网还有别的机会，咱们服务碧桂园的时候它还没有走出广东，对方认可咱们的服务品质、邀请咱们加盟，可我感觉本人这生意挺好，也没许可，地产的大浪潮就此错过。当你做得足够杰出，趋势会被动向你招手，但即便如此，错过的人也肯定很多。所以无论什么时候、什么年龄段，都要致力尝试从时代的整体视线判断将来。当然无益的心得体会也有很多，比方交朋友要跨界、多多益善。当我发现国内外征询、培训行业都困囿于“庙破和尚肥”的明星效应，就找到了影视圈的敌人帮我出主见。某位驰名影视公司的CFO跟我介绍了好莱坞以编剧制均衡明星的力量，而另一家近年来非常火爆的影业公司老板教会我，如何通过对新人的造就机制，给明星施加压力，“年轻漂亮演技好的人并不缺，让他们时刻能看到后浪，天然就会谦卑、敬业”。 2015-2017 守业邦合伙人在双向学习中修行毕业 凯洛格倒退日渐成熟，王玥也打磨了一门企业翻新策略课程并亲自主讲，可越讲越有心虚之感，“说到底，征询公司的人都在讲他人的案例，可你本人做了什么？你本人做成过什么？”工夫曾经跨入21世纪第二个十年，王玥意识到，咨询服务这条路迟早要面对一个微小的时代改革：技术对商业模式的颠覆及重塑，猛攻传统咨询服务模式将无奈逾越这一鸿沟：“那时我讲课，一会讲85度C、一会讲美团颠覆，讲来讲去都感觉不能再脱离实战，肯定要与翻新走得更近一些。”他将本人的想法与守业邦创始人分享，后者用一份“守业营总教练”的诚挚邀约来表白认可，除了培训之外，还将成立孵化器和天使基金。2015年，王玥正式加盟守业邦负责合伙人，以及BANG CAMP守业营总教练。在他的率领下，BANG CAMP作为守业邦旗下守业CEO造就我的项目，每年孵化培养近300位创始人，“玥堂主”这一江湖别号便成名于这一时期。现在许多赫赫有名的品牌，其创始人都曾在BANG CAMP承受过系统性的守业培训，然而回忆起那近4年的时光，负责总教头职务的王玥反而认为最大播种在于本身的学习、成长以及毕业。 2022年·玥堂主复盘成长之路： 那段时间，本人也系统性地梳理了多年来的常识体系，也从内部获取了十分多的一手信息、高级认知，所以挂着总教练的名义，其实也是翻新路上的一名学生。更重要的是，在守业邦，我真正回归了本人的守业初心：我要做的不是征询、培训，这些服务模式都只是伎俩，真正的价值是服务产业，服务实实在在的企业。我察看到了一个机会：一次翻新中国大赛，某位试图打造机械设备共享平台的创始人，没有吸引到投资人的趣味，但现场一位从事于机械设备生产的巨头企业，当场决定投资这一我的项目。我忽然意识到，咱们做翻新中国做了那么多年，除了投资人、创业者之外，还该当引入一股力量，就是传统企业、尤其是代表产业高度的领军级企业。因为我本身的工作经验，服务了很多产业领军企业，因而我晓得他们的问题和痛点，一谈到翻新大家就只会想到创业者和资本，实际上产业巨头也有十分强烈的翻新需要，并且具备搀扶翻新的能力。在那家企业负责人举手决定投资的霎时，我找到了本人真正要做的事件：传统产业，须要有可能接触到翻新力量的平台。这就是连界的发心，也是连界名字的由来：连贯产业界和翻新界。 2018—至今 创立连界同生共死，押注MEI畛域科创人：您为何抉择以独立守业的模式来实现您的构想，在守业邦是否会失去更多的资源反对？ 王玥：翻新的特殊性在于，它在晚期是投入、是赔钱的，之所以企业天天喊转型、改革、翻新却不见功效，无非是大家习惯了传统模式下安稳活着。真正有改革动机和能力的人都是孙猴子，他肯定会蹦到里面去。来到守业邦前我不是没犹豫过，股东和董事会成员是红杉、IDG、腾讯，还有有数圈内大佬坐镇，这是不是资源？是，但也有可能是束缚，他们的一句倡议可能就会变成体系内的清规戒律。最终我还是下定决定，要进来做。走之前我给其中一位董事发了条微信，说我感觉本人要做的事挺有意思，心愿有一天能比肩红杉。他给我回，“等那天来了，你得跟我喝酒”。以上是我本人的经验，从主观案例来看，第二曲线、翻新曲线，也尽量要与传统业务全面切割。连界打造的产业园区叫翻新飞地，飞地这个符号形容了第二曲线的成长模式：既属于，又拆散，置信有过第二曲线策略落地的敌人都能了解。 科创人：依据您翻译的企业生命周期实践，企业处于非翻新阶段的时候，其价值规范、行事准则，都与翻新期截然不同，打个比方的话像是猫和狗，不同阶段的企业讲着齐全不同的语言，连界如何和谐产业巨头与翻新企业的价值抵触？ 王玥：您对于语言的这个比如特地形象，鸡同鸭讲的确是一个普遍现象。这也与上个问题无关，我系统性的总结下，连界在与产业客户单干时的三准则：第一是做增量，外部改革我不做，第一曲线革新我不碰——碰这种事大概率就是先烈，要被祭天的；第二是体外做，不能在你的外部孵化，后面提到了这个话题；第三是一起做，我不再是一个简略的征询参谋，而是要投资参加、撸袖子一起干，可能你给我200万服务费，我反倒还要投500万进去。这样一来就形成了正向循环：客户更信赖你——你更理解客户策略和行业Know-How——你能更精确的整合资源给客户——客户给你的服务费更多。从第一份打工开始做咨询服务，到创建连界服务两个世界，服务的目标没有变，伎俩、内容丰盛了很多、深刻了很多。人类技术进化史绘卷（点击放大查看全图）科创人：作为产业服务商、投资人，您更关注哪些产业畛域？ 王玥：我的一位好敌人帮我手绘了一幅人类技术进化史的绘卷，几十万年跨度，从山洞到火星，其中最重要的三条主线是MEI，material、energy、Information，资料、能源和信息。这三个畛域是咱们最关注的，眼下优先深耕的是资料畛域——连界三准则中的“一起做”决定了咱们不可能什么都做。中国在大力发展本人的科技产业，注定会带动一轮新资料的彻底暴发，很多重要会议重复提到，要多投入新的根底建设。明天通过新冠疫情，咱们当初经济遇到了临时的艰难，须要从新去启动经济的新增长点。这背地都是对新资料产业化的一次从新触发和粗浅反动，市场曾经摆在那儿，这么多畛域外面对底层资料和新资料都是一个很大的要求。新资料行业的倒退，还将对其余基础产业畛域产生重大影响，比方能源畛域，汽车作为耗能小户，如果可能在轻量化这个方向上产生冲破，自身就是对能源畛域的减负，轻量化资料的重要性远非资料翻新这么简略。 P. S. 由新书店创始人王玥荐书 《企业生命周期》举荐语：不是因为我翻译它而举荐，而是因为它帮忙了我和太多的创业者。《创新者的困境》举荐语：全面形容了新兴技术挑战传统产业的全过程，创新者必读。《邓小平时代》举荐语：一位起起伏伏的领导者，如何在风云变幻之际，发自内心的舍弃集体荣辱、帮忙国家、达到最终现实。

沈旸 神州数码团体副总裁兼CIO国防科学技术大学工学学士学位、上海交通大学工学硕士学位。曾任SAP中国寰球反对核心征询参谋、SAP美国数字转型服务部门技术架构师、企业布局与商业智能团队负责人、神州数码控股有限公司首席信息官。 —文 | babayage编辑 | 笑 笑 在与沈旸的交换中，感触到他有一种独特的“疏离”气质：不执念，不狂热，成长过程中一直以第三方视角扫视人生走向背地的成因。相比起内驱、热烈的理想主义者，他更像一个感性、沉着的观察者，见天地也见本人。 从成长经验感悟信息的意义科创人：您在做人生重大决策的时候，有没有一个一以贯之的准则，或者始终谋求的现实？ 沈旸：从人生轨迹来看，有很多抉择是没有想分明的，有很多变动是随机的。作为80后，成长过程中信息还是比拟匮乏，那时候计算机和互联网还没有遍及，信息只能靠口口相传。当年高考的时候，大部分学生、老师和家长也不太懂填报意愿，在认真填报完第一批和第二批意愿后，我好奇地增加了一个提前批意愿——国防科大的万金油业余：自动化，起初在提前批里就间接被录取了。本科期间同学们就有机会参加磁悬浮、北斗、脑机接口等重大项目，但我过后还是心愿能接触一下新的世界，想出国读书、接触商业化体系。不过2001年9·11事件使得前面几年拿留学签证异样艰难，于是我抉择了去中国商业最发达的上海去读研究生。毕业后退出SAP也有偶尔的成分，在上海交大读研究生期间，有幸在英特尔研发核心做一些与挪动显示芯片测试开发相干的工作，公司就在学校门口的紫竹科技园，业余也还比拟对口。后果2006年底英特尔发售了本人的XSCALE芯片业务，我本来的待业打算被打乱了。恰好过后SAP在寰球范畴内扩张，机缘巧合就退出了进去，人生第一次坐飞机竟然就是国际航班（笑）。在SAP时我做过一个被动抉择，过后大部分同期共事都对更偏业务的财务、销售和分销模块更感兴趣，当然这些也是SAP最外围的竞争力。不过有可能是从小成长过程中信息匮乏的起因，我对数据和信息更感兴趣，于是抉择了数据仓库和数据报表模块的团队，并且专攻最冷门的估算打算模块（PLANNING），这个模块是通过布局来打消企业经营的不确定性。能够把个别的数据报表了解为加法和乘法，而PLANNING模块次要是做除法，属于加法和乘法的逆向工程，门槛也绝对要高一些。冷门模块的害处是一开始常常会坐冷板凳，做我的项目的机会没有其余共事那么多；不过益处是在刚开始的时候能有足够的工夫追随导师，学习得比拟深。起初这个模块的业务火起来后，公司就得在寰球来调用这个畛域的参谋了。2010年去SAP美国工作后，我还是持续在数据仓库、报表和估算这个大的畛域，也经验过SAP HANA内存数据库的初期落地我的项目。起初SAP把企业内的跟企业打算无关的产品合并打造成EPM模块（Enterprise Performance Management）产品，笼罩企业的财务合并和各类业务估算。起初这个产品的客户越来越多，大部分新客户在美国，而大部分新的开发团队在中国，我在美国那边跟中国的开发团队也配合得很不错，于是就开始在美国倒退并率领这个团队。回头来看，我的职业经验的确有很多随机性，职业生涯刚开始的时候，我对这种随机性还是很焦虑的，侥幸的是，数据和信息这个大方向也是我的趣味。不过起初受到量子实践哲学的影响比拟深，这世界毕竟不是决定论的，人得承受概率和随机性。 科创人：小插个问题，没有想过归国守业EPM产品吗？沈旸：过后EPM产品大部分客户机会还是在美国，所以的确没想过回国做这个方向。不过我之前SAP的共事曾经做了，并且做得很好，我感觉本人可能没什么机会了（笑）。很多随机的、偶尔的因素一直影响着我的成长过程，但这个过程中有我始终关注的事件，就是信息的绝对量、信息的获取老本以及信息的传递速度。我在小的时候就喜爱浏览百科全书，初中的时候就开始浏览高中、大学的物理教材，一开始也并不是因为喜爱，而是在非互联网时代，身边能获取的书籍不多，有什么就只能看什么。这有点像小型数据库里的全表扫描，能获取的信息量无限并且获取信息的老本高。如果那时候左近有大型图书馆，并且有好的书单、目录指引和牛人举荐的话，可能会更早挖掘本人的趣味点和特长所在吧。 科创人：如果您有机会回到过来，向过来的本人传递一条信息，您心愿是什么？沈旸：（略忖片刻）联合我本人的成长经验，我感觉这个设想也不是那么迷人（笑）。我感觉认知、常识、高价值信息，都是数字世界的资源，而人的成长取决于数字世界与物理世界资源的匹配水平，如果我很小的时候就懂得大量数字化常识，但一没有计算机，二没有利用场景，这些常识也没有那么大意义。如果真的要传递一条信息的话，心愿通知过来的我，对随机性不要那么焦虑吧。不过这个如同不是一条信息，还是得本人经验过能力感悟到。以前我也会设想，如果很早就有一张人生的全景规划图会是什么样，这个念头被斩断也是因为意识到了信息与物质的匹配度这个要害，一个人即使小小年纪就建立了巨大的意愿，如果没有适合得指引和资源匹配，也未必能走得上来，反而就地取材、审时度势地调整、适应兴许好一些。人生成长和数字化转型有很多情理是互通的，在数字化转型的过程中，并不是数据采集得越多越好，最终还是联合资源和业务指标实现零碎改革。有一个笑话，一个肥皂盒子的生产工厂想检测哪些肥皂盒子是空的，一个计算机博士团队折腾了一个月AI辨认和自动化，后果一个工人搬来一个电风扇把空盒子间接吹走。个人成长，就是要在正确的时候找到正确的电风扇，堆砌大量的信息有时候反而成了解放。超额利润只取决于护城河数据烟囱只会越来越多 科创人：在SAP期间您印象最深的细节是什么？ 沈旸：刚进SAP的时候，一起退出的共事有一大半不是计算机专业，甚至还有不少纯理科背景的，大家有大半年的工夫在承受各种技术培训和我的项目上的培训，包含商务礼仪和跨国文化等，甚至是在异国他乡学驾照。这种多元化和国际化的气氛，使得大家可能解决各种各样的简单问题。咱们在面试物理业余毕业的学生的时候，能够找到很多物理博士毕业的员工跟候选人探讨量子力学；在跟化工畛域的客户沟通的时候也能有专家用细节取得客户在专业性上的认可。但国内做跨行业应用软件和解决方案的企业，很少有资源和急躁投入在这类培训中。科创人：这些简单的培训体系，尤其商务礼仪之类，真的能为企业带来更多的利润吗？如果不是，为什么国外企业违心投入资源去做？如果是，为什么国内企业不去做？沈旸：这种体面、业余是能发明价值的，但它是一个价值金字塔靠上的局部，须要企业扎实的利润为根底。真正的超额利润起源只有一个：护城河。“能为客户发明价值”是及格线，“只有你能为客户发明价值”是高价值线。企业策略决策者该当一直思考并投入资源构建护城河，能够被代替的产品、能够被代替的服务，都不足以保障企业获取利润，更谈不上超额利润。一国内的一些软件企业创立工夫比拟短，另外也须要期待客户的观点产生扭转，还没有足够的积攒打造出本人的价值体系和护城河，置信倒退到成熟阶段时企业肯定也会搭建残缺的培训体系。 科创人：您操盘的神州数码云基地我的项目，将神州数码的数字化转型能力对外输入实现了不俗的营收，贵司在数字化转型方面的护城河是什么？ 沈旸：我感觉云基地的护城河是企业服务教训与IT技术、生态的联合能力，以及对大型企业应用场景的粗浅理解。举一个例子，咱们与开源软件TiDB的社区单干比拟深。TiDB的初期客户大部分是互联网公司，互联网公司的业务其实弹性十分大，比方一下子碰到几千万/上亿的用户，霎时数据量扩得特地大。这类用户谋求的是弹性、伸缩性、高可用性，另外TiDB可能兼容MYSQL协定，使得过来很多业务零碎很容易迁徙到新的数据库平台上。互联网公司用 MYSQL用得特地多，因为互联网里很多海量数据场景，数据的烟囱壁垒不高，很多时候能够一张大表行天下。然而在大型非互联网企业外面，天生会有很多的烟囱，业务有烟囱、数据有烟囱；企业外部利用的用户弹性没那么高，一个企业员工不会忽然从一万增长到十万。所以，在企业外部利用，功能齐全、多表关联、高可用是数据库更重要的诉求。在这方面，一般来讲，PostgreSQL协定的数据库体现得比MYSQL协定的数据库好，咱们外部有很多的企业级利用是建设在PostgreSQL 数据库上的。在美国，PostgreSQL的活跃度差不多是MySQL的一半，然而在中国，可能十分之一都不到。美国那边有基于PostgreSQL协定的CockroachDB和YugabyteDB，不过过后国内还没有相似的产品。所以咱们的团队在TiDB产品的根底上，心愿能增加对PostgreSQL协定的适配，补救这个方向上的空白，使得一个数据库能够同时反对MYSQL和PostgreSQL协定。另一方面，咱们也心愿用这样的架构来撑持咱们的外部利用零碎，心愿用一套分布式数据库加一套低代码利用平台，来实现大部分的麻利利用的构建。当然这个我的项目的难度也比拟大，咱们须要依附更多社区的力量。 科创人：毁灭数据烟囱、数据孤岛是很多数字化产品的口号，但您认为这是不可能的事？ 沈旸：烟囱不是大家成心造成的，而是因为法律和监管方面的因素。比方，法律规定企业的财务数据是不能提前披露的，财务报告进去之前只有多数员工晓得，到了财报公布的时候才要对所有的人公开，并且也不是披露所有的细节数据。人力资源的数据也一样，公司的薪酬数据不可能所有人都晓得，企业里的事务都是由业余的部门来运作的。大家可能会认为数据烟囱是技术造成的，在企业用大量商业软件的时候可能是这样，不是每个商业软件都能对外提供齐全的接口。当初的数据烟囱更多的是权限造成的，即便是所有的数据在同一个数据库里，企业也会给数据的应用加上各种权限，企业的数据复杂度就在于权限和多数据表的关联。数据脱敏、数据关联、数据权限、隐衷计算和平安成了当初的一个热门话题。开源模式必将胜利的理由：最佳实际失灵，分布式翻新崛起 科创人：与TiDB的单干之外，您自己还曾多次表态看好开源模式的发展潜力，是否分享下您对开源模式的价值认知？ 沈旸：残缺的表白是：随着“最佳实际”这一模式在越来越多的行业、畛域内失灵，分布式翻新将成为支流，而开源模式可能高效撑持分布式翻新。“最佳实际”失灵是重要前提，十几年前大家买软件喜爱巨头的全套解决方案，一个工厂、一个供应链把经营体系打磨到最佳，大家间接参考拿来用，效率最高。然而明天行业内一个标杆花了几年工夫打磨出了最佳实际，可能外界的技术和竞争体系又变了，间接照搬上线后可能曾经落后一代了。以CRM为例，传统CRM在挪动社交年代变成了SCRM，以往保护客户是保护一个手机号码，一个客户反馈需要须要填工单、走流程，而明天所有可能就是拉个群的事，这套体系扭转了获客、保护客户的形式。而这也不是起点，这个时代的变动频繁而激烈。 科创人：您偏向于认为是“新的稳固态代替旧的稳固态”，还是“最佳实际这种稳固态的模式将被继续的不稳固所代替”？ 沈旸：我置信是后者，将来一段时间应该还是继续变动的状态。所以开源的价值就体现进去了，时代变动太快，但传统软件开发模式的迭代并没有那么快。哪怕是SaaS模式，收集需要、优化迭代，也是一个集中式的过程，不可避免的存在时间差、存在取舍，而开源这种自下而上的、即时的分布式翻新模式可能更好地解决问题。比如说咱们碰到一个痛点，我有能力解决，我可能当天就开源进来，第二天、第三天行业搭档就能够拿去用了。这个周期比传统开发模式和商业模式都要快得多，以往如果有个小痛点，商业软件走个洽购流程，可能流程没走完问题曾经隐没了。而在开源模式下开发、进而解决问题，周期十分短，只有有成果，越成熟的企业级客户越会有足够的付费志愿。开源模式长处还有很多，比方更业余，商业软件往往无奈做到极致的细分，因为菜太少不成席，麻雀再小也得五脏俱全，但开源软件能够做得极致聚焦；比方，对用户来说判断的工夫老本非常低，一个十分细分的开源畛域最初根本就剩一两家。 科创人：是否分享下神州数码对于开源社区的经营心得？ 沈旸：咱们意识到社区的重要性，开源不止是代码的开源，更是常识组织体系的凋谢和社区的互动。开源这方面咱们其实也是刚起步，也在一直学习的过程中。 科创人：您在采访之初就提到过，您很关注信息流转的速度，尽管大家都喊“天下文治唯快不破”，但您仿佛更激进，认为节俭洽购流程和选型的工夫都有其微小价值？ 沈旸：所有的思考都要围绕世界的实质，物质和工夫，而工夫是最稀缺的财产。开源和信息通明都有利于简化客户的洽购流程和节俭选型的工夫，节俭客户的决策老本也就是节俭产品的销售老本。也正是基于这个思考准则，我也很看好新一代的低代码模式。有些敌人认为低代码就是个利落拽，跟十几年前的产品没有什么区别。但在我看来，将来基于云的低代码，是API+生态的经济组合。将来大家在做开发的时候，会先比拟在利用模块里我本人开发的老本与调用他人服务的老本，会有越多的开发者会基于一个成熟的生态系统实现翻新。 对开源模式将来倒退的预判看好低代码，定制化短期内仍是刚需  科创人：对于开源模式在中国将来的倒退，您有哪些判断和期待？ 沈旸：首先，肯定会有更多业余的开源企业呈现，还会有很多像神州数码这样新的开源生态参与者。咱们一方面可能间接给开源做奉献，一方面可能通过本人的场景教训来验证开源产品，将不同的开源产品进行适配和连贯，疾速填补一些空白畛域，这自身就能给同行带来很大的帮忙。第二，SaaS模式将进入临界点。当初的SAAS很多还是在相互竞争，相互屏蔽接口。中国的SaaS行业将演变为几个大平台的生态圈，平台上会长出越来越多的SaaS利用，底层数据、接口为利用生态一直提供营养，相互集成相互撑持，一个好的SaaS会带动另一个好的SaaS，进而带动另一个好的服务。第三，就是后面说的，基于云+API的低代码会逐步成长起来。第四，定制化需要依旧会是中国特色。跟国外相比，中国的软件定制化比例十分高，即便是同一个行业，不同的公司都有十分不同的治理需要。这个区别可能与国内以后的企业组织构造无关。国外的公司倒退工夫较长，大部分企业的管理层很多也都是受过MBA训练的职业经理人，独特的治理格调很容易被浓缩。另外，很多行业有十分强的行业标准制度，同一个行业的企业在治理行为上差异不大，这样就诞生了很多行业的SaaS解决方案。相比较而言，中国的现代化企业倒退历史还不长，大多数企业都有十分独特的治理格调。再加上中国过来几十年经济倒退迅速，各行各业都有层出不穷的机会，企业也在不停地摸索新的时机和赛道。这就导致了企业治理过程中，通用的解决方案常常满足不了企业要求的状况。

史喆 富士康科技团体首席数字官美国辛辛那提大学智能保护零碎核心机械工程博士，曾任北京天泽智云科技有限公司解决方案负责人，负责策略大客户。2020年退出富士康，负责富士康科技团体首席数字官、工业互联网办公室主任，并组建工业互联网办公室，负责团体数字化转型和智能制作战略规划，推动灯塔工厂、数字化平台及工业互联网的落地。 —文 | babayage编辑 | 笑 笑 子承父业，师出名门1978年，高考复原第二年，史喆的父亲考入了西安电子科技大学前身西军电最重要的无线电业余，毕业后调配至无线电厂。自史喆记事起，便熟知与通信、导航相干的技术名词。2008年高考填选意愿，尽管对炽热的金融业余有一丢丢眼馋，但心水的上海财大在全陕西只招四人，“那就学工科吧，清华有点难度，就选了北航”。这当然是自嘲的玩笑，事实证明史喆抉择人生方向的眼光和运气都是上乘：本科就读于可靠性与系统工程业余，不仅是体制内总体单位的优先录用业余，也是华为、中兴、商飞、中车这类大型企业的要害岗位，要说美中不足就是鲜有出国机会（过后不风行出国，大家都抉择读研或进入零碎）；可到了史喆毕业那年，又赶上GRE从纸笔转折考的改革，英语本是短板的史喆拿下了全额奖学金，自此走上了高起点、大跨步的智能制作之路。辛辛那提，自动化流水线屠宰业的发源地，亨利·福特看到德国人“生猪进去，香肠进去”的生产线之后失去启发，反其道而行之，研发出“整机进去，整车进去”的汽车制作流水线。在辛辛那提大学，史喆度过了整个硕士和博士生涯，他师从于世界出名的工业大数据与工业智能专家李杰传授，而李杰传授的老师，便是驰名中外的“2毫米工程”发起人：密歇根大学吴贤铭传授。 Tips·2毫米工程寰球汽车制造业公认的车身品质管制模式，波及薄板件冲压成形、主动装配线、焊接、检测等技术，包含对车身尺寸“全方位检测”、“数据分析”、“实时改良”等分系统，是否利用“2毫米工程”被认为是汽车企业在车身尺寸管制是否达到国内先进程度的衡量标准。辛辛那提大学的独特传统：Co-op带薪实习我的项目，让史喆在读博士期间就失去了在顶级企业工业我的项目实际的机会，一年级寒假他被派到远在Austin的美国国家仪器（NI）总部实习，承当过后很重要的某对外我的项目，二年级时又失去了在伊顿电气和Alstom实习工作的贵重时机，“最乏味的还是与阿尔斯通单干，我的项目启动的时候帮忙阿尔斯通的高铁做检测零碎，就在单干期间《美国陷阱》（阿尔斯通被美国企业强制收买）中的事件产生了，等到最终集成的时候合作方曾经成为了GE。”身处其中的史喆倒是没感到微小挫折，“就是接管方邮箱变了而已。”2016年，工业互联网——或者叫信息物理零碎、工业大数据——在国内风声渐起，史喆感触到一个历史级的时机摆在眼前，毅然决定在博士毕业之前便回国倒退。 To B产品缩小性能堆砌甲方能用好才有价值史喆本没有守业的打算，归国只是参加国内相干科研项目。可在与信软司单干编写了《信息物理零碎白皮书》之后，大家一共计，以校企单干的框架无奈真正解决甲方企业痛点，“既然信息物理零碎的框架曾经确定，还不如咱们本人去做利用和服务”。2016年，服务于央企、大型配备制作企业的天泽智云正式创建，提供工业智能全套解决方案及服务。团队阵容堪称奢华，来自IBM的企业服务团队负责架构，脱胎于美国国家仪器的测试团队负责边缘计算硬件。创立以来，无论资本市场升温或骤冷，坐拥“精兵强将+骨干赛道+头部客户资源”的天泽智云，始终是投资人追捧的宠儿。可即使有着天纵之资，守业该趟的坑，还是要趟上一遍。科创人：在乙方团队负责BD和大客户的这些年，总结了哪些To B服务的粗浅体验？史喆：大家都晓得To B千万不要闭门造车、自说自话，可即使对方认可你的价值，也肯定要把握对方的推动节奏，一边认可你一边回绝你的场景可太多了：首先，“你的能力很强，但你要做的事不是咱们最焦急的”，对于超大型企业而言，数字化转型首先是社会问题，其次是组织问题，最初才是技术问题。其次，“你的能力很强，但你能解决的问题不是咱们最想解决的”，你跟对方说咱们能检测出所有轴承的故障，他却只关怀偷油的问题怎么能连忙解决。第三，“你们做的事很有价值，可它产生的时候我可能不在这了”，不多赘述。第四，“你们能做9999件事，可跟我无关的到底是哪几个，别的我可不掏钱啊”。这是To B洽购的特殊性，一个手机有多少性能是咱们不必的？但大家习惯了购买价格蕴含了这些沉睡性能的老本。但在To B畛域，只有客户能用起来的服务才是有价值的，客户只违心为这部分价值付费。 企业服务没有理所应当决策链要害人是第一责任人科创人：面对有需要但没有第一工夫启动的客户，To B企业可能做些什么推动事件的停顿？史喆：有件事可能是中国To B企业必须要做的：一直进行价值布道、宣讲。中国To B团队很多都源自甲方或者大型乙方团队，对于需要点的把握没有问题，但企业服务畛域真的没有理所应当四个字 ，你要帮客户了解事件的重要性、可行性、危险和老本，帮忙客户攒到足够的资源、打消外部的阻力。有些人睡眠不好，其中一个起因是身材节律和社交节律不统一，解决方案就是调整本人的作息去适应社交。To B就是这样一个情理，要适应甲方并推动甲方向你靠近，两边都须要你去想方法。  科创人：To B的洽购决策链条上，谁是最要害的角色，我的项目责任人还是领有洽购决策权的人？ 史喆：我认为是我的项目责任人，或者更精确的说，是为所存在的问题最苦楚的那个人。当然这里有一个约束条件，天泽智云服务的客户对于数字化转型并没有“要不要做”这一层的顾虑，他们肯定会做，只是选谁做，因而责任人的倡议最重要。到了执行环节更是如此，他和你的指标统一，可能全情投入只为解决问题。我置信随着企业服务的价值被越来越多的企业所认可，不仅市场规模会变大，从业者的老本也会升高，效率和服务质量更是会快速增长。打个比方，咱们守业之初连业余的IoTDB都找不到，只能用MongoDB来做，当初可选的产品就很多了。 数字化转型要害是精确设定KPI“工业智能化就是去除简单过程，间接解决最终问题并带来价值的过程，其指标实现的根底是数据和模型”，而工业智能化落地在寰球范畴内仍处于摸索阶段，“欧美也没有非常成熟的教训，咱们也只能依照咱们的模式摸石头过河”。富士康，工业制作畛域当之无愧的龙头企业，天然也有此苦恼。自2018年起，这家全世界最大的精细制作公司更加器重智能化降级，组建了专一工业互联网的公司工业富联（Fii），并与天泽智云针对工业互联网等相干技术达成了一系列单干，史喆也由此开启了常驻深圳模式，代表公司入驻富士康与其独特布局工业互联网的倒退。2020年，富士康团体董事长刘扬伟制订了F2.0数字转型策略，并首次设立了首席数字官这一岗位，组建工业互联网办公室，负责团体数字化转型和智能制作战略规划，推动灯塔工厂、数字化平台及工业互联网的落地。这一年，史喆正式退出富士康，负责富士康首席数字官、工业互联网办公室主任。 科创人：参加过高起点的乙方守业团队，又在相对巨无霸级别的甲方企业任职，是怎么一种体验？ 史喆：你能充沛的感触到当初坐在对面的那位敌人是怎么思考问题的（笑）。庄重说，不太好比拟，富士康太特地了，一家40年的企业，峰值员工120多万人，眼下要做的事奠基将来5到10年的倒退，占据寰球精细制造业31.5%的份额（据IDC统计），那些物联网、产能共享、智能协同等等咱们这里都有，在这里你要达成的指标是之前齐全没有触碰过的：晋升整个产业链的效力，为了达到这个指标可能有一万件事要去做，每天只能从当选三件解决，每个事都要继续做对，还要跟更多的部门去协调……所在这里要承当的责任微小，但这种微小自身就是意义。与富士康单干之初，还没卸任董事长的郭台铭有一次问我工业互联网什么最重要，我说数据根底和人才根底最重要。他当即就开始大规模招募人才，开始筹备团体内工业大数据分析比赛。这种效率和信心，让所有参与者都对达成指标有着十足的信念。  科创人：如何了解一个企业的数字化推动，能带来整个产业链的效力晋升？ 史喆：所谓龙头企业，其实是一个产业链上最大水平聚合资源的主体，因而它的一举一动都将带来产业链改革。举个例子，苹果对供应链的带动让供应链上每一家企业有了明天辉煌的业绩，甚至成为了行业龙头。当年仅仅是手机后盖从塑料材质到金属及玻璃材质这一变动，就救活了国内一大批机床厂，因为金属或者玻璃材质的后盖必须要机床切割技术，需求量一下子下来了，而在此之前国内很多机床厂的日子不太好过。这并不代表这些机床厂做得有多好，重要的是行业龙头的产品演进，带动了产业链竞争力。国家层面也意识到了产业链竞争的重要意义，2022年《政府工作报告》中就已明确指出，施行龙头企业保链稳链工程，保护供应链产业链稳固。特地要器重作为“链长”的龙头企业，通过龙头企业带动上下游链条上的中小企业，通过产业链稳固供应链，最终实现价值链的集约式、高质量倒退。 龙头企业必须挑战Engineering Method的极限科创人：身为CDO主导企业数字化过程，在您看来，数字化转型的关键因素是什么？史喆：确定KPI，也就是指标，定低了没有价值，定高了是“好高骛远”，所以一个刚刚好的指标是数字化转型主责人最须要费神思考的。此外还有两个要害因素，首先这个指标的制订肯定是多方独特参加、协商的后果，其次这个指标不能是零碎建设的指标，肯定是组织倒退层面的指标。 此外，就是明确两头产出，这又是很难的事件，它没有模板、没有标准化。这里分享一个技术模型，最底层是迷信science，中间层是技术technology，下层是工程办法engineering method。大部分企业没有迷信层，有一部分技术层，但最终要投入发力的，大部分是在工程办法层面，如何将IT技术与组织更好的汇合，造成外围竞争力。因而，两头过程可能是效率晋升、人员精简、老本升高，大部分企业做到这个水平就OK了，但对于龙头企业而言，它最好能带来价值增长、效力晋升，而不是单纯的老本升高。而且，龙头企业要发明的还有社会价值，而不单单是企业价值。举个例子，当初寰球最大的议题是ESG（环境Environmental，社会责任Social Responsibility，公司治理Corporate Governance），如果数字化带来了企业增长，但没有在减碳、环保方面做出奉献，那也不值钱。咱们也制订了新的可继续倒退指标，认为可继续倒退=EPS（earning per share）*ESG。 数字化没有相对的对错最先进的改革也可借鉴西医智慧科创人：面对海量的资源和微小的责任，您的每个角色都意义重大，怎么能建设一套反馈决策推动状况、防止太大损失的机制？ 史喆：我感觉目前没有一个普适的计划，咱们想倒退，想变革，就要不停调整组织构造、用零碎平台来解决问题，同时还要像老中医一样号脉。一个组织的造成通过了很长时间，每一个逻辑、每一个零碎、每一件事件都有当年“它之所以成为这样”的必要性，所以你要把脉把好，从无限的药材里精挑细选配方、制订剂量。这些药方就是数字化，而数字化的外围是尊重机体本来的机制同时晋升号脉能力。  科创人：没有普适的办法，是否能够了解为没有通用的掂量数字化对错、优劣的规范？史喆：我认为是这样，因为数字化并不是明天才产生，它曾经诞生了很长时间，影响了很多事，咱们无奈推断如果换条路走一遍是不是更好，而只能去确保咱们选的路可能走出成果。打个比方，手机摄像头的布局，如果乔布斯没有逝世，苹果的后盖会不会是明天的设计？该当不会，可是不是缩小摄像头的设计就是好的？那也不肯定，从事实来说，用户须要更多的摄像头，你不能自觉定义明天的iPhone就是弯路、就是错的。当然，数字化的劣势就是高频次的迭代优化，明天咱们用的很多零碎，界面早就固定、甚少变动，但背地的零碎仍旧在一直降级、强化。从这一点上说，仿佛有一个很俗但很能形容数字化的老话：没有最好，只有更好。

技术合伙人（或者咱们常说的CTO）被踢出局确实是个常见的景象。依据2014年福布斯杂志统计，世界500强企业CEO的均匀在位工夫为9.7年，CTO的均匀在位工夫少过4年。CTO被称为“最长寿”的CXO。 方云君认为，有两个起因能够解释这一景象。起因一纯正的技术人转型合伙人不懂治理，必“死”无疑 最常见的技术管理者，往往是“技术型的技术管理者”，特点是基本上不太懂治理。一个纯正的技术人员，在守业当合伙人、负责CTO之前，他的成长门路可能是从高级开发到中级开发到高级开发，再到架构师这样一条路，精进于技术而漠视治理素养的积攒，再之后就进去守业。 伊查克·爱迪思用“企业生命周期”来形容企业如何倒退、老化、兴起，企业生命周期可分为十个阶段，即：孕育期、婴儿期、学步期、青春期、壮年期、稳定期、贵族期、官僚化晚期、官僚期、死亡。“技术型的技术管理者”在公司的孕育期到学步期比拟常见，尤其是婴儿期——企业刚刚把产品做进去，推向市场。这个阶段对技术合伙人的要求其实很简略，就是把活干了。当企业进入学步期，便须要技术管理者去参加策略制订。这个阶段，团队规模曾经收缩到了肯定水平，技术管理者必须对研发团队进行治理，并且随着人数减少，管理层级也要减少，并建设一些管理制度流程、应用一些管理工具。但“技术型的技术管理者”往往还沉迷在技术里，对人对事都很单纯，滞后于公司的成长。此时CTO的心田OS：这公司怎么开始搞政治了？！此时其余合伙人的心田OS：好一个愣头青，对公司倒退不上心，就是个干活的。方云君曾接触过一家在线教育公司，过后行业环境尚好，公司虽是初创，但背靠北大资源。这个故事中的CTO，百度背景，大略是P7职级的架构师，真金白银投了不少钱入股这家公司。最开始，他率领的团队倒退顺遂。随着业务进入深水区、团队规模扩充，他手下三个总监，每个总监都带了十几个人。这时，CTO的想法还很单纯，他感觉公司业务发展缓慢了，就要去搞大平台、要建设中台，却没有意识到治理建设的重要性。在CTO看来，CEO只关注业务倒退，不太操心技术细节，做技术改革不须要CEO反对。CEO没有明确反对，员工怎么看CTO的行动？不用说大家也能猜到。可咱们单纯的CTO却只晓得发愁：大家如同不太反对这个事儿……终局可想而知，最初一次CEO和CTO谈话时示意，“和你谈话太吃力！”于是，这个技术合伙人在这家公司呆了不到两年工夫，股份留，人拜拜。起因二单凭技术，CTO不被长期依赖 国内大多数的技术都是利用技术，须要解决的都是短期问题，这一人造属性决定了技术合伙人不被长期依赖。 少数人对于科技公司，总是抱有一种错觉——咱们是一家科技公司，所以咱们的技术是长在CTO身上的。其实不然。中国目前的技术，大多都是搞利用技术，须要解决的技术问题也都是短期问题。在公司最开始的时候，技术可能长在CTO身上，一旦到职，就会呈现十分重大的结果。但当这个团队超过7集体或者10集体，逐步成熟和稳固，技术最外围的局部就不在CTO身上了，而是在最一线的员工身上。如果技术合伙人的价值仅仅是解决短期技术问题，那么人造就不会被长期须要。当技术合伙人跟公司的高层产生矛盾，天然会第一顺位被踢出局。CTO的“吃鸡”之道 CTO不能被动响应问题，也不要当“救火队员”，技术合伙人须要循序渐进，精进技术、学会治理、了解业务、了解策略，直到能将策略转化为具体技术计划，能找到通过技术手段晋升企业经营能力的办法。先把技术和治理搞定。当初倒退得好的技术合伙人，基本上都是追随公司一起成长。所谓“技术搞定”是他单打独斗的能力要强，“治理搞定”是要求技术合伙人能带着技术兄弟们一起把公司最根本的底线实现。技术的特点是服务于业务，所以接下来要熟悉业务、了解业务，这样能力跟业务合伙人一起钻研客户。再下一步是了解策略，说到底就是要搞清楚怎么打造公司的外围竞争力，只有在策略这一步可能在公司外部高层达成共识，CTO能力坐到公司高管的桌子上。最初一步，技术合伙人要学经营，学了经营能力上到台面，作为公司代表被推出去，跟大家见面。 理解更多：方云AI研发绩效 文丨瑞祺责编丨babayage题图源自Pexels，基于CC0协定 文章首发于“方云AI研发绩效”知乎机构号

“太累了，一个月总有三十几天不想下班”，一边自嘲的“打工人”们一边钻研各种花式“摸鱼”办法。为什么一想到下班就没精打采、心灰意冷、感觉本人被掏空？ 职业倦怠（job burnout）是职业心理健康畛域广为关注的问题，而情绪耗竭（emotional exhaustion）是工作倦怠的次要体现。 职业倦怠的重要归因：适度工作“工作狂（workholic）”是一个学术上的名词，由美国心理学家Wayne Oates于1971年首次提出，他认为工作狂指的是那些因工作须要过多而影响到集体的衰弱、幸福、人际关系和社会性能的个体。 四十多年后，马斯克在2018年的一条Twitter中示意：“有更容易工作的中央，但没有人每周工作40小时就扭转了世界”。《纽约客》杂志称适度工作（overwork）这种适度操劳的行为是“cult（邪教异端）”。“感觉如同上班了，但又没齐全上班”，这种随叫随到、24小时stand by的工作状态随着新冠肺炎疫情过后的在线协同和近程办公更加广泛，人们工作和生存的界线越来越难以辨别。 “随叫随到”与准时上下班是两码事，咱们的身材对这两种状况的反馈截然不同——2016年一项钻研发现：晚上随叫随到员工的皮质醇（人体应酬压力的激素，也称压力荷尔蒙）程度比不须要随叫随到的员工升得要快，即便他们可能始终到早晨都没工作可做。2019年，世界卫生组织正式将“职业倦怠”视为一种职业景象，官网的定义为“因长期工作压力而未能胜利治理”的一种综合症，其特色是疲惫感、对工作的负面情绪和业余效率升高。它让你感到没有兽性，身心疲乏，并质疑你当初为什么承受这份工作。 适度工作的前世今生尤其是不付薪水的那种 16世纪：玩命干活被认为是美德“致力工作（hard work）”这个概念，起源自16世纪的“新教职业道德”——欧洲白人新教徒所持有的世界观，认为致力工作和谋求利润仿佛是美德。 工业时代：有额定抵偿的就义员工每周都有固定的工作工夫；超过这一时间的工作意味着雇主得领取抵偿。 牛津大学组织行为与领导力传授Sally Maitlis示意：起初，工业革命产生的效率驱动以及咱们贬责的生产力形式，进一步嵌入了致力工作的价值，当然往往以就义集体福祉为代价。 20世纪中叶：无偿加班景象再次出现办公室文化蓬勃发展，中产阶级的受薪业余人才队伍一直壮大。以无形产出掂量的工作岗位数量有所缩小。在古代工作场合中，工作不再像在工厂车间一样参差划定，工作何时“实现”的含糊不清导致了无偿加班。 1980年代之后：工作狂成为身份的象征伦敦经济学院行为科学副教授Grace Lordan强调道，“英国的撒切尔主义和美国的华尔街遍及了越来越长的工作工夫的想法。想要大降职，就得全身心投入职场——加班成了身份的象征。” 21世纪初：程序员成为工作狂主力尔后的在90年代末和21世纪初，随着科技初创公司们成长为Google和Facebook等巨头，并且势力转移到硅谷，工作狂的身份开始不再是西装外套而是连帽衫。 为什么一提起下班大家就说“累”？在美国，超过25%的男性和11%的女性每周工作超过50小时；在韩国和日本，极其加班景象突出，很多员工每周工作超过60小时；在欧洲，加班绝对弛缓，英国劳动者每周均匀无偿加班7小时，荷兰员工均匀每周加班3~4小时。而在我国，依据国家统计局的数据，2021年前三季度，全国企业待业人员周均匀工作工夫为47.8小时。比《劳动法》规定的“均匀每周工作工夫不超过44小时”多3.8小时。 多出的这不到4个小时显然是适度工作，但在额定的工作量之外，这一景象背地蕴含的文化冀望、“制作”批准和同辈压力，更是造成职场倦怠的次要起因。 1、文化冀望马克思在《资本论》中提出：机械本是缩短劳动工夫的最无力的伎俩，但会变成一种伎俩，最的确地，把劳动者及其全家的生存工夫全副，都转化为能够利用来增殖资本价值的劳动工夫。 员工的思维和价值观念往往在很大水平上影响其退职场中的行为表现，体现为一种“工作态度”，制约着人们的工作过程。其中对适度工作问题影响较大的工作态度次要包含集体主义、职业虔诚和勤奋三个方面。这三种价值观念自身都没有错，但不可漠视的是，它们在被过分强调或是被不顾理论“滥用”的状况下，就会容易产生适度工作问题。 在日本，加班是一种重要的“职业货币”。天普大学（Temple University）东京校区亚洲钻研业余主任杰夫金斯顿对此解释说：致力工作表明你是一名虔诚的员工，致力工作、花很长时间给老板留下深刻印象，被视为一种真正的美德（梦回16世纪）。 来自柏林SRH利用技术大学（SRH Hochschule）的研究员塔瓦斯（Ian Towers）在其2006年的学术论文中指出：挪动技术晋升了人们的冀望——管理人员和共事都心愿员工随时都能工作。 2、隐形的胁迫，被“制作”的批准常识工作者的常态化加班机制，是互联网产业的金融化、常识技术的迭代化和工作的弹性化的后果，体现为资本的荫蔽劳动管制与劳工的无限自主性的互构。 互联网企业的劳动管制机制具备隐蔽性与低压性，体现在通过我的项目制与弹性工作制度的运作，加之严格的绩效考核、末位淘汰与文化策略等，以期实现常识工作者对于常态化加班的接收。 如迈克尔·布洛维在《制作批准》一书中形容的工厂中造成的自愿性遵从（voluntary servitude）生产秩序十分相似，常识工作者也演出着相似的“赶工游戏”。如果老板要求长时间办公和无偿加班，员工就很难表态并说不，也如Grace Lordan传授所说：“高层是机会和降职的看门人，如果他们置信出勤率，那么在他们之下的人会发现很难不加班。”  3、同辈压力（peer pressure）长时间工作也可能是同辈压力的产物。Grace Lordan传授示意：“咱们喜爱追随别人，在新工作的第一天，你会寻找适宜的非语言社交暗示。如果有人工作到很晚或周末，你更有可能模拟这种行为。”   纽卡斯尔大学商学院将来工作传授Abigail Marks也提到：“人们总是胆怯失去工作，胆怯有人会比他们做得更好。如果其他人都这样做，那么你也必须这样做。这深深根植于员工心中。”  工时≠生产力管理者须要扭转思路如前所述，许多企业都依赖加班，是因为管理者把工时和生产力画了等号。只有有管理者置信工时等于生产力，就会有员工违心就义自我和休息时间来获取降职机会。 亨利·福特将工作工夫削减到8小时，起因是这样能够进步员工的工作效率。社交网络公司The DraugiemGroup已经钻研效率最高的员工有哪些习惯，后果发现10%的效率最高的员工工作工夫并不比其他人长，甚至每天工作都有余八小时。他们工作效率高的秘诀是，每集中精力工作52分钟，而后劳动17分钟。 对此，作家Alex Soojung-Kim Pang也曾做深入研究，在他的《劳动下：为什么你工作的越少，产出越多》一书中，外围论断是：“整体而言，偶然长时间工作确实会晋升效率，但长此以往，这些益处就会隐没。因为代价昂扬的谬误会减少，因而通过缩短工作工夫取得的益处会隐没。” 大量的钻研都表明了缩小不必要的工作工夫能够进步生产力。由此可见，管理者通过迷信的、基于策略的，公正主观的数据智能体系对员工的工作进行评估，是十分有必要的。 客户案例：建设数字化绩效体系让下班摸鱼、上班加班成为过来式 H公司是一家创立于上世纪末的老牌互联网公司（当中一些员工的退职资格甚至比CTO都老），通过二十多年的专一耕耘，成为了垂直畛域中业余、高端及品质的代表。 H公司研发团队面临的问题1、员工没有进取心，大家当一天和尚撞一天钟，管理者变成了技术官僚，全脱产，人浮于事；2、工作工作少，员工多，相互推卸，工作积极性低，不足团队精神；3、团队成立工夫久，团队收入老本高，正处于有序到无序过渡，投入产出比低；4、团队外部和业务部门沟通艰难，负责人只提后果、不提过程，且被业务方吐槽工作不配合，干活迁延，导致工作常常延期；5、公司没有绩效评价，对于工作工作，无奈理解每一个员工的工作态度和成绩品质。 于是CTO找到方云君，心愿能提质增效、激发员工的激情，重塑团队文化；优化部门治理体质，推动数字化降级，放慢研发部门跟上公司的倒退。2020年4月起，方云君和H公司陆续发展几次单干。通过单方共同努力，CEO对研发团队转型成果十分称心，2020年研发团队绩效获得了全公司第一的好问题，CTO升为高级副总裁。让咱们通过H公司CTO的工作汇报PPT一探到底，看看方云君如何利用AI研发管理工具、解决研发团队痛点。 Step 1 制度落地：塑造奋斗者文化首先从员工考勤抓起，考勤数据基于考勤制度和零碎，适宜作为起步基石。公正通明的制度有利于奋斗者文化的塑造，让奋斗者失去实惠，不让老实人吃亏；同时，将员工的投机行为以雷霆伎俩扼杀在摇篮里。2020年上半年，团队从疫情影响中疾速复原，人均工作时长增长显著，早退比例升高到5%，疫情后销假比例维持在2%以下。与2019年第四季度相比，2020年第二季度的人均工作时长增长了17%。 Step 2 找到抓手，造就数字化工作习惯当天工时当天记录，每天上班前复盘当日工作。这一步，便要在考勤数据的根底上，剖析工时数据。用排行榜激发员工志愿，用监控指标发现问题，将数据还原到行为。通过“抓典型、立楷模”的形式，打造数字化工作习惯——接到工作评估工时，实现工作盘点工时。通过数字化工夫治理的人效晋升，员工当日记录工时比例达95%以上，研发饱和度晋升2.5倍。（饱和度=工时总和/考勤时长） Step 3 借力员工画像，精准晋升积极性 接下来便要借力打力、因势利导地进行深入治理，分为两个方向：为了记录工时，员工有了创立工作并细化工作的能源；所记录的数据主动生成员工画像，管理者可能多层次、多维度地认知员工，且借助AI管理工具为员工安顿更适合的工作。从而使治理精细化，晋升员工积极性。 Step 4 治理精细化，为业务如期发展保驾护航通过精细化的研发治理，团队外部的工作数量增长显著，工作按期完成率也疾速晋升，从有余半数晋升到93%。合作效率晋升，整体危险升高，保障业务如期发展。 Step 5 逐渐晋升量化绩效比例，建设数字化绩效体系配合人工智能生成研发绩效模型，实现部门和员工的量化绩效，随着绩效模型在研发侧和产品侧的逐渐笼罩，H公司的研发数字化绩效体系建设也逐步完善。整个研发团队变动显著，从躲活、到等活、到抢活，H公司研发团队的工作效率和积极性产生了质的变动。 理解更多：方云AI研发绩效 文丨瑞祺责编丨babayage题图源自Pexels，基于CC0协定 参考资料1、BBC专栏：How working unpaid hours became part of the job？2、BBC专栏：从加班到零工经济 无间歇工作的代价.3、BBC专栏：Why do we buy into the 'cult' of overwork?4、van der Hulst, M., & Geurts, S. (2001) Associations between overtime and psychological health in high and low reward jobs, Work and Stress. 15(3), 227-240.5、Oates W. Confessions of a workaholic: The facts about work addiction. In Scott K S, Moore K S, Miceli M P. An exploration of the meaning and consequences of workaholism. Human Relations, 1997, 50: 287~3146、崔景怡, 李锡元, 薛莹. 加班行为能晋升员工工作幸福感吗？[J]. 首都经济贸易大学学报, 2020(1):80-91.7、前三季度国民经济总体放弃复原态势，起源：国家统计局，2021-10-18.8、马克思，《资本论》. 郭大力/王亚南译，上海三联书店，2013-10.9、孟续铎. 劳动者适度劳动的成因钻研:个别原理与中国教训[M]. 中国劳动社会保障出版社, 2014.10、侯慧, 何雪松. "不加班不成活":互联网常识劳工的劳动体制[J]. 摸索与争鸣, 2020(5):11.11、迈克尔·布洛维:《制作批准：垄断资本主义劳动过程的变迁》，商务印书馆， 2008 -02.12、刘泓君，硅谷从不996，发表于《财经》杂志，2019-06-03.13、帕蒂·麦考德，《奈飞文化手册》，浙江教育出版社，2018年10月第1版. ...

这是一篇PM治理Productlife团队的心得。 Productlife的前身是 C-Camp，而 C-Camp是 UX/UI新手村。心愿可能透过共创工作坊，帮忙大家累积实作上线产品的教训，总共有钻研场与设计场各 4~6周。而 Productlife正是在设计场之后产出的设计概念，并交由目前固定的产品团队进行设计与开发。目前团队组成是 1位PM、2位 Design Lead 、1位 Dev Lead 、4位设计师，2位后端，1位App 前端。 以下为PM的自述：从 C-Camp 到 Productlife 过程中，我一开始按照之前实习和工作坊的一些教训布局工作流程与节奏，却遇到一些挑战，因而理解到个别工作的团队与 Side Project 的团队差别，进而缓缓调整成目前的团队合作模式。 一、找到"弹性施展"与"精准规格"的均衡在工作坊期间，我首先根据产品的性能，产出细节的性能规格以形容用户故事与互动形式，也给了几个概念式的 Wireframe ，但未针对UI进行设计，对于大部分处于职场新人阶段的工作坊成员，这是一把双刃剑： 长处：让成员学会剖析规格，进而专一在产生对应的信息架构与 UI设计 毛病：成员被 Wireframe 限度，难以跳脱既定印象，成为只是产出视觉的工具 因而在工作坊完结后，我决定调整指派设计工作的形式： 第一，同样给定明确指标，蕴含产品指标与设计指标，让设计师晓得如何评估他们最终的设计； 第二，调整规格颗粒度，只给肯定要有的规格，其余全副不讲让设计师有更大的施展空间； 第三，提前 Review，咱们每两周一次 SprintReview 和 Planning，但不把所有该 Review 的货色丢到 SprintReview 才探讨，而是在此之前就必须实现 DesignLead 或是 PM 的 Review 。SprintReview的目标除了让各个设计师 Sync，也是让彼此的回馈能透过一个正式场合表达出来，在正式进到开发之前还有一个微调的缓冲。 二、做"最"有影响力的事件放弃所有"能够做"的需要，集中资源做最有影响力的货色。一切都是假的，只有产品上线才是真的。在与开发团队探讨过后，咱们评估在年中只能开发出一项最外围的机制。 我回头与设计团队屡次探讨了咱们该怎么在最精简的产品规模下提供最外围的体验，然而设计团队的想法善于发散却难以收敛。过后咱们曾经设计了社群探讨以及帮助分享者减少影响力的性能，但最初一一被我删减，设为Pending。 Productlife的愿景是「让每个产品常识学习者能因找到独特学习的搭档而成长」，心愿打造社交优先的学习体验。当我回过头来检视咱们外围的指标，就发现一对一的配对就能够实现最精简的社交性能，但还是能保有透过社交来学习的体验。所以咱们接下来只专一把一对一的配对体验做到最好，别的需要和性能能够略微想想，但临时都不会进行设计。 三、将成员成长也视为团队工作设计团队的成员目前行将交付最终版的设计给开发，在此之前我已经把死线压在3月就应该要交付，为什么会拖到4月了才终于要完结？ 这次凌乱的根因是我疏忽了：团队成员也要有学习的工夫。一味地让设计师赶上该交付给开发的进度，会让这些还须要一些反思能力更稳固的设计师变得节奏凌乱。在问题解决后我透过这个契机，与所有人进行了一对一面谈，并在一对一的过程中理解大家各自冀望的成长门路。 我最初做了一个工作指派上的调整，就是把「学习」也变成工作，这样在布局工作时，就不会排挤掉成长的工夫，同时团队投入在学习打算的资源也比拟容易掌控。 当初咱们有两个学习工作： A.理解 UI设计该留神的所有眉眉角角 B.理解如何以数据辅助设计 四、赋权团队：让成员从"负责"到"担责"在设计团队中，每个人都负责一个设计，最根本的效益，就是彼此能够看见产出的细节有哪些差别，进而向团队成员学习。然而在我眼中让他们负责是一回事，让他们感触到本人有责任，并且违心为此产出超出冀望的后果又是另一回事，在一对一的过程中，成员提及了这种状态就是有 Ownership。 至于要怎么晓得成员有感触到 Ownership，总结有两个层面能够展示这件事： 集体：独立负责一个设计，在各方面都能认真地思考在限度下交付合乎或超出冀望的成绩 团队：会被动沟通来补救规定缺口，甚至被动推动该被器重但未被推动的工作 无论是集体或是团队层面，成员们都曾经展示局部特质，而我都还在致力让两点都能100% 达成，期许将来能打造出一个有良好组织文化的产品团队。 ...

前言可能大家看到【工作效率】，第一工夫会想到是编码技巧、开发环境、效率软件、vscode 插件或者开发环境、CI/CD。 不不不！ 以上那些的确能够进步业务的生产效率，应该说是每个程序员的必备本事，属于技术能力领域，也叫硬实力。（这块有工夫另开一篇分享） 不少程序员，特地是初中级的常有个误区，就是只有技术牛逼就行了。其实不然，但业务越简单牵扯的人越多，软实力就要害。 本篇分享是有来由的，故事要从前些天的需求方找我诉苦说起。 简略介绍下本团队，大略十几人，高级前端较多，采纳梯队治理设立两个小组长别离治理他们 前些天，A B 两个我的项目的需求方先后跟我投诉某个小组长我的项目进度延期。按说对应的需要技术难度并不高，没理由延期太久的。 于是我拉上了需求方、前端开发负责人、服务端、原始数据供应方等相干人员开了个复盘会。 在复盘后发现，其实影响进度的不是技术，而且跨组合作上的问题， **总结了以下几点： 开发对业务了解有余，局部性能实现后返工批改沟通能力有余，造成误会和有效期待小组长工作合成和治理能力有余，资源调度不合理个别成员责任心不强，抱着 xxx 不是我负责，我不论的心态**提炼出关键字后，是【业务理解能力】【沟通能力】【治理能力】【主人翁意识】。这些都是软实力，并不容易量化考核。 作为团队 leader 显然不能对这些问题坐视不管，那怎么去晋升这些能力呢？ 有句话叫陈词滥调，很多理念和方法论大家可能都听过，但并没有真的认可和执行它们。 所以我要做的就是通过个体培训、单聊、设定相干指标、举荐工具和方法论等模式，去一直强化大家的思维。 抛砖引玉，以下是我做培训的思考总结： 晋升对象 / 能力纬度：小组长组员业务理解能力业务理解能力治理能力执行能力沟通能力沟通能力总结能力总结能力主人翁意识主人翁意识工作推动能力 晋升计划-对组长 - 独自交换在平时的工作中刻意化强调这些思维，传输思想认识 -对组员 - 个体培训对组员其实也能够一对一交换，不过高频率会占用很多工夫，培训、分享会的时候去讲这些也是不错的计划 -制订要求及工作剖析和总结能力，能够肯定水平反馈在需要文档和技术总结上。 -验收工作实现状况，作为绩效一部分退出奖惩制度，能够进步大家的积极性。软实力考核能够根据需要技术等文档、需求方投诉、工作品质和进度等方面 晋升方法论业务剖析能力晋升如果没法清晰了解需要/bug 的时候，能够试试 5W1H 分析法 ，问问本人上面这些问题，一一寻求答案后再连串起来 5W1H 分析法 bug需要what什么问题，影响如何什么需要，价值在哪where哪个环境，哪个模块哪里须要when何时产生，触发条件何时须要who相干人员是谁相干人员是谁why起因是什么为了什么how如何解决如何实现指标治理能力人脑不靠谱，请及时记录信息当然每个人的习惯不一样，有的人喜爱用文档，有的人喜爱写纸张上。而我喜爱纸张打草稿，而后要害信息记录到文档里。 草稿也不是胡乱涂画，这里我举荐一页纸工作法,辅助刻意化造就思维逻辑。 一页纸工作法（图片来自网络） 当然，不须要画的这么丑陋 ：） Notebook 便签便签用于记录一些事项的概要，集体的 todolist，能够时不时看一眼。 进步沟通能力推动事项、缩小误会 沟通的实质替换信息并达成共识 沟通通常来说，有两个场景，即发动沟通方和接管沟通方。 发动沟通方【提前梳理好内容】 明确本人的用意和冀望信息残缺，需具备工夫、地点、人物等因素组织好语言通顺性思考好对方可能的发问，并做好答复筹备 发动沟通方接管沟通方直接对话【提前梳理好内容】1. 明确本人的用意和冀望2. 信息残缺，需具备工夫、地点、人物等因素3. 组织好语言通顺性4. 思考好对方可能的发问，并做好答复筹备【提取重点】1.对方用意和冀望2.工夫、地点、人物等因素3.不可本人猜想对方用意4.不做没把握的承诺5.不替别人答复状况，除非你真的理解文字沟通【同上】关注答复状况，如果对方长时间未响应，及时跟进【同上】防止已读不回项目管理平台诸如禅道、ones、tapd 之类的项目管理平台，做好以下几点，也有利于缩小沟通和团队治理老本（每个团队都有对应的标准，这里就不开展讲了）： 迭代治理做好分类需要、缺点形容要清晰进度、状态及时更新

作为一个整体，团队应该蕴含交付产品所需的所有人才。 Scrum团队正在组织其开发工作，并正在抉择团队成员，或正在评估如何使团队的技能取得成长。 一、为什么须要跨职能团队Scrum团队如果不能自主工作，就是因为它不具备实现简单工作网络所需的所有技能。如果依赖团队内部人员的技能，团队就不能真正“领有”手头的工作。这样团队对工作的实现工夫就没那么有掌控力了，并且最终工作的品质也会受到影响。 一致性（Consistency）和缩小返工（Reduced Rework）这两项外围精益准则依赖于短的反馈回路。大多数简单的开发工作都须要有来自不同畛域（如人类工程学、工程卓越和质量保证等）的泛滥人才。很少有人能在一个团队中找到所有这些人才，更不用说在任何一个人身上找到所有这些技能。团队通常围绕着能力畛域进行组织，正所谓物以类聚，人以群分。这有时被称为职能型组织（Functional Organization）。 然而，逾越团队边界协调这些职能的老本很高，因为只有在那些共享当前工作背景的人之间能力存在无效沟通——这通常只有同一个团队的成员能力做到。 一个简单的产品可能须要团队把握许多技能能力“实现”各项性能。如果须要为每项所需的技能都别离减少一个人，那么团队就会变得过于宏大而无奈无效工作。要解决这个问题，通常会有两种抉择：你可能会偏向于不扩充团队的技能组合，而是引入内部依赖；你也可能会抉择把工作交给团队，让他们去倒退和学习所需的技能。但学习是须要工夫的。 部分学习能够导致局部优化，也就是说专家会倒退出优化他们工作的实际和流程。专业化（Specialization）、部分实际（Local Practices）和流程（Processes）都能够成为一个组织的效率起源，但也会在团队的边界处产生问题。 为了解决这些问题，这个组织能够定义“合同”，阐明如何与对方单干（例如，服务申请）。这样的合同能够规定这个组织违心做什么性质的工作，以及对申请的预期响应工夫。任何须要该团队专业技能的人都必须应用这些合同与他们打交道。然而，这可能会减缓整个产品的开发，即便它进步了部分部门的效率。 同时，可能须要在组织内设立额定的协调小组来治理这些边界合同、协商例外情况或确保所有各方理解所需的内容，并确保每个团队依据这些合同的任务，履行对其余团队以及对客户的任务。 新产品或现有产品的新版本，目标都是要为客户发明一个新世界。因为你无奈当时晓得这个新世界会是什么样子，所以你必须在产品开发过程中专一于学习和试验。团队必须从客户应用产品的教训中吸取教训，而不是单纯按预先安排的打算行事。而且，团队必须在整个产品开发过程中整合这些教训。每个人都意识到在流程的某一步骤或某一职能畛域内作为个体工作所带来的部分流动（local flow）、自主（autonomy）和管制（control）的劣势。 然而，这样的工作构造使每个人（除了做最初一步的人）离最终用户更远，从而失去与最终用户进行互动能力取得的宽泛洞察力。（从全局思考问题）这可能导致部分职能不是最优，但整个产品开发流程的优化水平会更高。 因而：每个Scrum团队应该包含交付“实现”的性能所需的所有人才。 在团队创立初期，关注技能的覆盖度是一个很好的终点，但更重要的是，团队成员要对愿景有独特的激情，并违心学习陈腐事物。因为工作会随着工夫的推移而变动，团队不可能从一开始就预见到所有的长期技能需要。 二、如何造就跨职能团队与其因为须要新的技能就去更换团队成员，不如在外部培养人才，并致力建设小而稳固的团队。随着工夫的推移，对团队成员进行穿插培训，使他们的技能组合一直增长，以适应越来越多的能力畛域。这将进步团队作为一个自主团队工作的能力。有了跨职能的团队，就更容易平均调配工作。 团队成员当初有太多的机会去学习次级技能。比方他们能够在产品待办事项（PBI）上应用簇拥模式，这样就能够减少学习的机会，优化流动，有助于性能疾速达到“实现”的状态。次级技能的倒退使团队更加灵便，因而如果有人不在，其余任何人都能够顶上来。这样团队总是能够获得停顿，并且是自主的。 Scrum对如何解决能力缺失的问题没有提及，它置信这些都是常识能够搞定的 ：例如，向其余团队寻求帮忙，或把大的工作外包进来，不过外包进来的工作后果就不好说了，有可能会让团队大吃一惊。如果团队偶然须要这样的帮忙，还是能够了解的。但如果团队发现他们常常要依赖内部的帮忙，那么他们就应该把这看作是一种妨碍，并采取措施（如培训、重组或招聘）来补救这种状况。 例如，一个由软件程序员组成的团队可能会发现自己正在构建一个不属于本人业余畛域的产品，如制药或航空航天。咱们很想在团队中为每个弱势能力指定一个负责人，兴许能够征询内部领域专家。然而，团队代表可能不晓得他们有多少不晓得的货色，甚至可能不晓得该向领域专家提出什么问题；反过来，大多数领域专家把畛域专业知识当做隐性常识（译者注：曾经成为专家潜意识的一部分），所以他们可能也没有方法意识到软件人员真正想要的洞见是什么（译者注：因为专家不会留神到他们感觉天经地义的事件，即隐性常识）。 至关重要的是，团队成员要了解畛域因素对施行的影响，并对业务和解决方案的空间都有全面的理解。亚马逊的Jesse Watson指出，这两个因素（译者注：两个因素别离是业务知识和解决方案）“在一个头骨内”并存是至关重要的。[1]最好是将专家带入团队，并通过穿插培训扩充知识面。但要记住放弃小团队：向团队中减少专家可能会使团队单干减弱到简直没有的境地。 这些团队天然会像“个性团队”（Feature Team，详见后续推出的康威定律模式）那样工作，因为大多数PBI都是以个性的模式（Feature-Shaped）存在的：产生支出的功能性产品增量中的可销售元素（marketable elements of revenue-generating functional product increment）。 如果由跨职能团队来开发产品，那么交接动作天然会从价值流中隐没：团队自身就能够开发任何个性，无需内部反对或干涉。让多个团队参加进来，会造成反馈回路的提早，减少返工的节约（Muda），并在价值流的不同开发阶段之间产生不统一（Mura）。 《哈佛商业评论》（Harvard Business Review）发表了一项对于两家公司的钻研，其中一家是按职能组织的，另一家是按产品组织的。钻研表明，相比之下，跨职能团队交付个性的成果是最好的。 基于汇合的设计是一种技术，它能够让开发人员参加到许多可能与业务相干的学科和畛域中，即便这些学科和畛域最终可能没有用在以后产品中。这种实际拓宽了团队和企业的专业知识根底，并且也让团队不会诧异于须要把握某些新学科。 随着团队整合新的教训，他们会对产品有新的想法。变动将会十分迅速（而且必须容许它迅速）。变动将是常态，而不是例外。这须要小规模的组织，因为在小规模的组织中，每个人都晓得正在产生什么：这些组织可能拥抱变动、跨专业工作、定期交付价值，用一个词来形容就是：麻利。 三、一个游戏组建几个小团队，在游戏中竞争制作和航行纸飞机。每个团队成员一次只能做一个折叠动作，而后必须换到另一个飞机上。任何飞机都不得有超过15个折痕。它必须至多有15厘米长，8厘米宽。它必须有一个至多2厘米宽的钝头。要成为优质产品，测试员测试时，飞机必须程度航行3米。测试员对每架飞机只能测试一次。 试试这个游戏，并利用Scrum Pattern（提醒：簇拥模式）来优化在一分钟长的Sprint中生产的优质飞机的数量。 参考资料： Jesse Watson. “The Hard Thing aboutSoftware Development.” LinkedIn.com, https://www.linkedin.com/puls..., 12 July 2017 (accessed 4 July 2018).Arthur H. Walker and Jay W.Lorsch. “OrganizationalChoice: Product vs. Function.” In Harvard Business Review 46(6), 1968, pp. 129-138. https://hbr.org/1968/11/organ... (accessed 8 November 2017).起源：徐东伟麻利教练 作者：徐东伟申明：文章取得作者受权在IDCF社区公众号（devopshub）转发。优质内容共享给思否平台的技术伙伴，如原作者有其余思考请分割小编删除，致谢。 ...

企业数字化转型失败率高达80%，很大的起因就和认知无关。数字化转型的要害不是数字化技术和设施，而是组织变革使之具备敏捷性和适应性。 麦肯锡报告指出，企业数字化转型成功率仅为20％。 说到数字化转型成功率，大家广泛的意识都是布局和技术决定所有，而实际上，对于一个数字化转型能不能胜利，组织才是最外围的力量。 报告发现，组织文化有余是企业数字化转型取得成功的绊脚石之一。 组织文化的有余体现为三个方面，即各职能和部门绝对孤立、胆怯承担风险、难以造成对立的客户观并立刻执行。 从行业来说，即便是精通数字技术的行业，例如高科技、媒体和电信，也都在挣扎。 这些行业中，成功率不超过26％。在石油、天然气、汽车、基础设施和制药等较为传统的行业中，数字化转型更具挑战性，他们的成功率仅在4％至11％之间。 从公司规模来说，成功率也因公司规模而异。在员工人数少于100的组织中，受访者报告胜利进行数字化转型的可能性是员工人数超过5万的组织的2.7倍。 即使是以技术为核心的公司或部门，也往往会裸露这三个不足之处。比方，员工常常应用他们喜爱的工具和解决方案，而没有合作或共享信息，这有可能会导致需要不对立。 转型胜利的组织部署了更多的技术。 一、如何判断企业有无数字化文化人们通常会犯这样的谬误，认为一家公司降级了技术，便能顺利完成数字化转型。然而，数字化转型与软件或技术无关，重要在于组织的适应性。 为了跟上数字化转型所推动的改革步调，组织必须具备敏捷性和适应性，而组织文化对于任何数字化动作的胜利都至关重要。 如何判断企业是否具备数字文化，无妨从以下列表当中做个抉择： 过来将来「咱们不和客户谈。咱们更违心看钻研报告的内容。」「客户是咱们所有工作的外围。他们理解咱们，咱们也理解他们。」「咱们用数据来掂量咱们的体现。」「咱们用数据来预测和预感客户的需要。」「咱们浏览报告。」「咱们实时做出决策，因为咱们眼前就有咱们须要的数据。」「咱们防止危险。所有新的动作都须要通过审查和批准。」「咱们承担风险，但尽量疾速失败，从谬误中学习。这是成长的惟一路径。」「咱们的部门专一于本人的工作，彼此之间没有沟通。」「咱们依附跨职能的团队来确保新的动作能反映出多种观点。」「咱们招聘，所以咱们能够在外部实现所有工作，即便须要更长的工夫。咱们的需要是举世无双的。」「咱们利用咱们的专家网络，包含参谋，来更快更好地实现工作。」「咱们晓得什么是最好的。」「客户晓得他们须要什么。咱们试图给他们更好的货色。他们还不晓得本人须要什么。」「咱们的高管团队做了所有的决定，员工只有退出进来就能够了。如果没有，他们晓得门在哪里。」「咱们的高管团队会聆听来自整个组织的想法，并专一于沟通新的想法和动作。」「团队之间仿佛有很多孤岛。信息被囤积起来，没有共享。」「咱们的主管定期就新的想法进行沟通和单干，以确保它们是统一的。」「很多部门直到读到新闻稿才晓得新的动作或我的项目。」「咱们重视通过各种办法进行合作，确保有大量的自上而下、自下而上和穿插沟通。」从上述表格来看，以过来的形式对待企业、组织的倒退曾经不占据劣势，以将来的眼光对待组织变动与倒退更贴合数字时代的倒退。前者体现固步自封的组织文化，而后者既关注当下，又放眼将来。如果让你抉择，你会抉择哪一种呢？ 二、改革的要害在员工数字化转型曾经极大扭转了组织的运作形式。要想建设数字文化，做到真正的转型，只有通过扭转领导团队和一线员工的思维形式和技能来实现。 对于全公司而言，领导团队必须要提供一个清晰的倒退愿景和策略，包含具体的指标，这样能力保障公司往正确的方向倒退。对于一线员工而言，要帮忙他们理解在转型中的角色，以及如何推动。 当组织倒退与数字转型策略保持一致，所有人感觉本人参加其中时，真正的改革就会产生。如果治理团队只说了一件事件，兴许是在全体会议上提议，但没有因而而扭转日常经营，则转型打算不会短暂倒退。 但也有另外两种状况： 一是，即使公司决策已定，但各级都不反对翻新，也很难维持。二是领导者压抑改革，员工就会感觉到言行不一之间的脱节，转型也会陷入停滞。组织文化上的扭转不可漠视。技术虽重要，但并不能代表数字化转型的所有。而组织文化一旦垮了，转型便会停滞不前。 三、胜利的五个实际如何推动组织文化的改革，以实现数字化胜利转型？麦肯锡的报告总结了五个办法： 关键因素都具备具备数字化成功率大幅晋升 3.1 延聘精通数字技术的领导者数字化转型产生在公司的方方面面，尤其是人才队伍上。在麦肯锡报告中，有70%的受访者示意企业高层团队在转型过程中产生了变动——最常见的状况是，相熟新的数字技术的领导者退出了治理团队；不到1/3的受访者示意他们延聘了首席数字官（CDD）来反对公司转型。并且，考察结果表明，引入数字化高管的企业转型胜利的几率是其余企业的1.6倍。 3.2 造就员工数字化能力调查结果证实，重视造就普通员工的数字化能力更可能实现数字化转型。 企业扩充他们劳动力打算和人才开发，也更有利于数字化胜利。 麦肯锡报告中提到了能力造就的几个关键点： 首先从新定义集体的角色和职责，使其与企业转型的指标相一致，这也能够帮忙阐释当初的企业所须要的员工能力。另外要施展技术经理和数字业务管理者这两个新角色的作用，让他们补救传统业务和数字业务之间的潜在差距。一般来说，技术经理须要领有业余的技术能力，并领导公司的数字化翻新工作；管理者须要将新的数字办法和流程，转换并整合到现有工作形式中，既须要有业务方面的教训，也须要理解新的数字技术。3.3 制订新的工作机制要施展员工的价值，还要通过建设肯定机制来调动他们的积极性。比方营造一个继续学习的、凋谢的工作环境，或者给予员工肯定的权力，让其在数字化技术采纳方面领有发言权。当员工对数字化可能在哪些方面帮忙企业有本人的想法时，企业数字化转型成功率更高。 另外须要一直激励员工挑战旧的工作形式，并宽容失败。当高层领导和参加改革的领导都激励员工尝试新想法时，企业胜利的可能性更大。最初还要确保部门、员工之间有交换合作。 3.4 为日常工具进行数字化降级为了让企业赋予员工新的工作形式，麦肯锡考察了数字化工具和流程能在多大程度上帮忙转型胜利。如下表所示：他们向受访者询问了自转型以来其企业做的7个构造改革，其中3个改革都波及将数字工具作为新的组织标准的应用。 充分利用数字化工具被设定为组织的新标准，更有助于转型胜利。 第一，采纳数字工具，让企业信息变得更通明、更容易取得；第二，采纳数字自助服务技术；第三，关注公司经营中的技术，批改规范操作程序。除此之外，基于数据的决策的减少和交互式工具的应用也能帮忙转型胜利。 3.5 学会讲好故事正如咱们在传统改革工作中所看到的那样，在数字化转型期间，清晰的沟通至关重要。 更具体地说： 胜利的要害是传播改革故事，它能够帮忙员工理解组织的倒退方向，组织为何变动以及变动为何重要。在遵循这种做法的组织中，胜利进行转型的可能性是三倍以上。第二个要害是高级领导者要造就紧迫感，以在其单位内进行改革，这是良好沟通的外围。其余结果表明，在沟通改革故事时，胜利的组织偏向于传播比其余组织更丰盛的故事。对胜利影响最大的因素是组织要害绩效指标要有明确指标，以及清晰沟通转型的工夫线。 对胜利影响最大的因素是组织要害绩效指标要有明确指标，以及清晰沟通转型的工夫线。 起源：博士悦读内容起源：麦肯锡 4月每周四晚8点，【冬哥有话说】DevOps之庖丁解牛，拆解DevOps的工具及具体实战。公众号留言“解牛”可获取地址 0401《数据库继续交付流水线分享与演示（Azure DevOps+Flyway）》0408《继续交付中的版本治理与基于Azure DevOps扩大框架的插件开发》工夫待定《微服务，多团队合作中的API测试怎么做 - Pact契约测试》0422《BoatHouse端到端流水线展现》

序作为一个大部分工作经历都在7-15人编制的技术团队的公司，深刻体会到合理的成员编制对团队开展高效工作的重要性，对团队每一位成员的成长的重要性，对公司的成本控制的重要性。 本文内容是以全栈式后端开发团队转型前后端分离开发团队为主题，从实际问题、工作流程、成员编制、成本控制等为出发点，做一个总结分析，抛砖引玉一起讨论学习，也希望可以帮助更多的朋友解决问题。 一、开发团队角色 小组型技术团队中，不论是全栈式后端开发团队还是前后端分离开发团队，开发角色基本都包含 后端开发、APP开发、web前端。 1. 全栈式后端开发团队各岗位职责web前端，主要负责编写静态的HTML，把CSS做好及部分特效JS后端开发，除了负责CRUD的技术开发，还要将HTML套入jsp、asp等模板引擎，需要编写JS代码做数据渲染以及大部分表单校验，甚至还需要些HTML，调CSS（如后台管理系统，一般前端是不管的），必要还是得写下接口文档给APP开发APP开发，略2. 前后端分离开发团队各岗位职责web前端，主要负责包含前台系统、后台系统所有的静态的HTML，JS数据渲染、表单校验后端开发，只需要负责CRUD的技术开发，编写接口文档给web前端开发、APP开发APP开发，略二、全栈式后端开发团队常见问题1. web前端工作闲，没技术含量一个月22工作日，web前端开发平均每个月最多只有10工作日饱和工作，剩下时间都在吹水、玩手机，以及考虑跳槽（因为嫌的慌，要么没事做，做的事基本没技术含量，想找个更有发展空间的环境）2. 后端开发套页面，CSS无法统一化管理在套页面时，经常出现渲染出数据后，页面效果不协调，需要优化样式，有些人嫌麻烦，觉得自己能改，就写行内样式，前端css没有统一化管理3. 后端开发套页面，JS无法统一化管理在做表单校验时，经常出现同样的代码多次复制粘贴，几十个页面都有90%类似的代码。（有心的，一般是会抽公共js引用，但实际上还是嫌麻烦，复制粘贴来的快）4. 后端开发并不擅于写页面，开发效率低后端开发在写页面时，经常会出现因为一个JS效果，需要花几个小时甚至一天的时间完成，并且部分效果体验比较差，将就将就即可5. web前端在本地调试带数据渲染的页面比较困难有些问题需要根据后端返回的数据渲染后，才会出现的问题，web前端需要调试，一般都是在后端开发座位上改，后端只能在一旁看着，浪费开发力三、两种团队工作流程1. 全栈式后端开发团队工作流程 2. 前后端分离开发团队工作流程 3. 分析从图中可以明显看出，前后端分离工作流程相比全栈式后端开发工作流程中，web前端与后端开发增加了接口对接的沟通成本，但总体来说，节省了后端开发的工作职责，把这段时间调整到接口文档的编写，可以推动技术文档的完整性，并能加强团队的管理。 四、两种团队开发人员编制对比1、 全栈式后端开发团队组织架构 2、 全栈式后端开发团队组织架构 3、对团队每一位成员要求变化后端开发，前后端分离团队模式提高了web前端和后端开发的沟通成本，但实际场景跟APP开发与后端开发对接是类似的，所以区别不大web前端，除了基本的HTML、CSS，还需要会React、Vue.js等JavaScript框架，技术要求更高，但目前该类技术已经是web前端面试时要求的必须技能技术组长，作为管理者，虽然团队角色并没有多少变化，但由于web前端也会遇到问题，作为技术组长，肯定要能提供一些有用的建议，所以也要加强一些前端知识的学习了解五、总结回到现实，大部分团队尽管看到了这些问题，但一直不愿意转型，主要也还是历史原因，那是否历史原因，所以我们就不做改变了呢？ 管理团队组织架构、工作模式跟管理代码系统架构也是一样的道理。系统架构全新升级，也从来都不是一刀切，毕竟风险太大了。同样也是一步一步来，先从小的系统开始试水，然后再把主项目边缘的一些模块完成切割，最后实现完全转型。 六、交流学习有兴趣的朋友可以私信作者，大家一起交流学习更多的互联网技术。 My Blogblog.guijianpan.com 技术交流

众所周知，高效的沟通是项目成败重要的影响因素。沟通在项目管理过程中扮演了极其重要的作用，而沟通对象又是完整的基于项目干系人，所以在项目管理过程中干系人管理就显得尤为重要，那么干系人管理的好坏也就会直接影响到项目的成败。 干系人管理是一门较为复杂的艺术，既会涉及沟通，又将涉及管理学，可见其难度之大；而今天我们如果是基于一个创新型的业务，其复杂性又将会提升，创新型业务的特点就是变化快、不确定性大，那么期间必然会对团队的凝聚力产生挑战，尤其是刚组建的团队。那么我们在基于不确定性极大、变化极快的创新型业务时，作为 PM 应如何做好干系人管理呢？ 01、什么是干系人？1.1 干系人的定义 干系人是指积极参与项目、利益可能受项目实施或完成的积极或消极影响的个人或组织（如客户、发起人、执行组织或公众）。 1.2 干系人管理步骤 干系人管理过程中一般会分为五大步骤，分别是干系人识别、干系人优先级排序、干系人期望管理、干系人持续识别、收获干系人认可，一般做好上述五个环节，干系人管理就会比较成功，那么我们分别来看下每个环节的基本解释： 干系人识别：PM 应从多方位识别项目干系人，只要有可能影响到项目成败的人员都属于项目的干系人，例如项目 Owner 、运营、产品、 HR 、法务、财务、行政等均属于项目干系人；干系人优先级排序： PM 应基于项目干系人对项目成败的影响程度大小做优先级的区分排序，具体将在 1.3 中详细介绍优先级排序的评估矩阵；干系人期望管理：每个不同的干系人对于项目都会有自己的期望，例如拿到业务结果、技术能力沉淀、接口能力开放、实现营收等，那么 PM 应该尽可能的了解不同干系人的期望并持续管理期望，在过程及结果中实现多赢；干系人持续识别：项目运转过程中变化是非常常见的情况，那么因为项目目标、实施策略、项目范围等因素的变化，均会影响到项目干系人的变化，所以 PM 应在项目过程中持续进行干系人的识别；收获干系人认可：通过不断的识别、管理干系人的期望，并逐渐实现多赢，最终获得干系人的认可；1.3 干系人评估矩阵 干系人管理过程中，我们可以通过干系人的权力、利益矩阵来针对干系人的优先级进行评估，最终可以根据优先级分为四象限：重点管理、令其满意、随时告知、监督【详见下图】: 四象限的干系人优先级： 1、重点管理：利益、权力都很高的干系人，例如项目 Owner（Sponser） ； 2、令其满意：利益不大、权力很大的干系人，例如业务 TL 、产品 TL 等； 3、随时告知：权力不大、利益很大的干系人，例如项目组核心成员、依赖方等； 4、监督：利益、权力均不大的干系人，例如HR、行政等； 02、创新型业务干系人管理之道创新型项目团队一般都有几个特点： 业务方向变化快，日常调整多人员临时抽调，彼此不熟悉前期目标感不明确正因为有上述这些特点，从项目组人员的角度来看，就会造成项目组成员协作效率低、安全感弱、急躁等问题，这时候对于 PM 在干系人管理中不仅需要用到上面概念性的知识/评估矩阵外，更应该有一些软技巧的实施，帮助快速和项目组融成一片，将项目组快速形成一支作战队伍，向目标推进。 2.1 快速建立信任感 说到信任感，我们都知道需要长时间去沉淀，需要用彼此的坦诚对待去逐渐形成。但是对于一个创业型的业务，你没有那么多的时间去培养彼此间的感情，那么作为 PM 的你应该怎么能与项目组成员建立信任感呢？ 我觉得最重要的就是要学会补位。从敏捷项目管理中可以知道， SM 是服务型的角色支撑，那么在创业型项目的前期，我们也可以做一个除专业性角色外的服务型角色。创业型项目中一定是有部分岗位是缺失或者是在招人的路上的，那么作为 PM 这时候就可以主动去进行补位（注意是职责补位）， PM 可以补位做一些数据分析、产品运营等工作，一方面可以提升自己的业务理解能力、业务 Sense ，另一方面也能和 Sponser 、项目组同学之间不断建立信任感，不断在项目落地过程中带给他们安全感，让大家觉得你很靠谱，跟你一起做事可以很放心，这样你就可以拉进与项目组同学之间的距离、不断靠近甚至逐渐背靠背。 2.2 学会聆听 俗话说“为人处世，多听少说常点头”，其意是更了更好的聆听，也是为降低犯错的概率（言多必失）；但在此刻，我想说的是作为 PM 在前期的时候要不断的与项目组成员去沟通，不断的去聆听项目组成员对于现状的评价及他们眼中的问题，然后从大家口中表述的问题中不断的提炼总结，收口为最重要、影响面最大的 2-3 个问题，然后结合项目管理基础方法论的框架进行调整及优化，从而不断地提升彼此的协作效率、端到端的交付效率等。 进入项目组的前期，你可以先把自己当做一名“消防员”，哪里需要去向哪里，哪里着火了就扑向哪里。 这个过程中，我非常坚信的一点是“二八原则”，也就是如果一位 PM 能将其 80% 的时间花在项目的前期，理顺项目组的问题、解决症结问题，那么等到项目的中后期其实他所需要投入的精力就相对更少了。 ...

写在前面优秀的研发管理者是怎么工作的，如何更加高效地管理研发团队？这些一直是 CODING关注的重要话题，我们不断地打磨 CODING 研发系统来让开发更简单。近期我们精心挑选了几篇硅谷科技公司研发管理者的 README 进行翻译。README 主要用来向团队成员展示项目管理者的工作理念和工作方式，以便成员能够快速地融入到团队当中。 原文地址：https://mattnewkirk.com/2017/09/20/share-your-manager-readme/原文作者：Matt ，Etsy 研发经理译者注：Etsy 是一个网络商店平台，以手工艺成品买卖为主要特色。这是 README 翻译系列的最后一篇。Matt 受到了 Slack 公司 Roy 的启发，在此基础上，他融入了自己的内容：软件开发方面的价值观、重视工作和生活的平衡、开放的日程表、重视和其他团队的工作关系。 正文 从管理者角度来看，无论你是初来乍到还是有新鲜血液注入你的团队，入职这段时间都会有些艰难，同时这个时间段也是至关重要的。如何更好地度过入职阶段我认为有两个重点： 分享期望建立信任既来之则安之。知道你下一步需要做啥吗？如果你知道团队对你的期望，你就可以开始着手进行了。如果不知道，那你需要一定程度的信任来询问期望问题。 考虑到这一点，我写了一份文档和新下属们分享。我和加入团队的下属以及我加入的团队都分享过这份文档。无论哪种情况，我都描述了：我是个什么样的人、我希望如何与他们互动。我给每位新人都强调了这点：我鼓励讨论和反馈。如果我加入了一个新团队，我倾向于在第一次的 1:1 会议上提这一点然后再发送邮件给他们。如果他们是新员工，我会将其合并到一个更详细的入职文档，其中还包含了关键资源、要了解的专用名称、以及第一个月至一年的工作输出预期。 我从在 Slack 公司工作的 Roy Rapoport（ http://royrapoport.blogspot.com/ ）中发现了这招：我发现 README 是一个与新员工开始建立工作关系非常好的方式。这是我的管理者自述文件。正如我鼓励我的下属做的，如果你有任何的问题或者反馈，请告诉我。 什么时候你可以和新下属开始建立信任关系？ 作为你的 leader我非常希望通过聊天来更系统地了解你，在此之前事先了解我的工作理念可能对你更有帮助。我来这里是为了帮助你、支持你、为你的工作提供一个平台，并且为你和团队成员摇旗呐喊。我的工作范围看起来包罗万象，但其实我是为你而来的。 我的日程表里塞满了会议，安排和我一起的会议可能会让人望而却步。如果你在我的日程表上看到了空档，请见缝插针（你不需要先问），并且我会按时出现（除了临时会议，我的谷歌日程表是 99.9% 准确的）。如果发生了紧急事情你暂时没法和我见面，就给我发一个 Slack 消息或者短信，我会腾出其它时间。如果你需要重新安排会议，那也没关系。我尽力开放所有日程的修改权限（我用的是这个插件：https://chrome.google.com/web... ）。你可以按照默认值随时修改我们约定的会议日程，并将其移动到不与其它会议冲突的工作时间段内。 关于 DRI 模型你来到这里是因为你的经验和技能，我不想推翻这两个。我是来帮助你成功的，但不是规定你应该如何行动。如果我认为你判断错误，我肯定会尽量劝阻你，但和我意见不同并不表明你做错了什么。你仍然需要得到队友的共识、赞同和投入。 软件开发和进度我坚信要让团队成员积极参与过程以及改变过程来达到我们的需求和目标。 我曾和敏捷团队以及非敏捷团队合作过、也以 scrum 以及非 scrum 方式工作过。以下是我的价值观： 我重视发生的事情、已经发生的事情以及将要发生的事情的透明度。我重视速度以及主观努力，帮助团队快速前进 (例如，在新功能之前编写测试代码、重构遗留代码、结对编程以提高我们的代码质量和降低公车因子）。译者注：公车因子（bus factor）描述的是因关键人物流失而产生的风险。 我重视学习，我知道在技术栈上进行培训可能并不是最快的产效途径。我重视你的时间，不希望你做任何既对你没有益处也不符合政策法规的事情。反馈是至关重要的在建议匿名反馈的情况下，您可能会听到我依然建议你提供直接反馈，尽管匿名反馈总比不提供反馈要好。我致力于给你明确和及时的反馈，希望你对我也是这样。我认为持续的反馈需要三个属性:  安全(你应该感到安全， 给予和接受坦诚的反馈) 努力(你和我都不应该对反馈感到防御) 效益(接受反馈应该产生影响)  在这些方面如果我做得不好请告诉我，感激不尽。 工作和生活的平衡大部分员工从早上八点（最早）工作到晚上六点（最晚），除非有紧急情况，否则我不希望在你的工作时间之外与你沟通。我尽量在非工作时间不回复邮件和 Slack 消息，并且在任何情况下也不指望你这样做，除非有紧急情况。 1:1 meeting我认为 1:1 会议很重要，这些会议应该由你制定议程。你想谈论些啥呢？最近发生了什么？你在烦恼些什么？除非您真的想谈论项目状态更新， 否则我们不谈它们。对于面对面聊天， 我真的很喜欢一边步行一边进行 1:1 ；对于远程聊天，我很难集中注意力，除非我能通过视频看到你的脸。如果有什么事需要我的帮助，我会做， 但这是你的时间。长度、频率和媒介也由你决定， 但我希望我们每周至少有 30分钟， 最好每周有 60分钟，这个时间还可以更长。被具体议程驱动的聊天我更喜欢安排单独的会议（例如目标、查看项目反馈等）， 这样我们仍然有空间进行更及时的 1: 1 聊天。 ...

CODING 已经通过前四期文章，让大家逐步了解了一些硅谷优秀的项目管理者是如何工作、如何维持团队高效运作的。在过去的十几年中，中国的互联网行业发展过于迅猛，导致很多管理人员都是赶鸭子上架，商场如战场，不给你任何适应的时间，所以很多人还没有从技术人员的身份转变过来就开始带团队，在管理方式上难免会有所欠缺。这也是我们做这一系列文章的初衷，希望通过这些文章帮助研发管理者，自省或者回顾一下自己的管理思维，看看有没有哪些方向可以借鉴。同时也给将要成为管理者的技术人员一点预习材料，为日后踏上管理之路做一些准备。 本篇文章来自于 Forter 的研发 VP：Oren Ellenbogen，同时他还是 SoftwareLeadWeekly 的创始人和 Leading Snowflakes 的作者。本篇文章个人风格比较强烈，Oren 在他自己的 Readme 中展示了很多个人管理风格的喜好和细节，同时也提供了大量的延伸阅读材料以供参考。 系列文章地址：《CODING 告诉你硅谷的研发项目管理之道（4）》 原文地址：https://docs.google.com/document/d/1sx5ssYb_xMrmwPpyjD5xP7RvQ7cHweDYlRGn2SXztKw/edit# 原文作者：Oren Ellenbogen，Forter 研发 VP 译者注：Forter 是一家通过数据分析为金融、电商等行业提供反欺诈解决方案的供应商。 正文先说说我自己，我作为 Forter 的技术 VP ，主要职责有以下几点： 创造出”势必达成“的工作氛围（比如我们可以完成业务方面需要我们做的任何事），同时为股东和其他利益相关者提出相应的合理计划和所需要的支持。通过一流的待遇以确保招到一流的人才。同时我们还希望能在相应的技术领域做出一些品牌影响力。不可否认，在公司成长过程中会有一部分人离去，但只要在问他们“你觉得整个团队的 EQ、IQ、好奇心和效率有没有随着时间越变越好”的时候，他们的回答是“妥妥的”，那就证明我们还是走在正确的道路上。为组员定好合理清晰的框架，平衡公司需求和组员的个人职业发展。通过不断迭代来优化我们所使用的工具和流程，确保组织和业务的可持续发展。为组员提供指导，帮助组员提升领导力。还有一点很重要，就是我是为你服务的，如果你有任何需要都可以直接问我。同时要明确你不是为了我工作的，而是为 Forter，所以当你认为我在犯错误的时候，请直接跟我沟通，我也希望像你一样得到成长。 我认为最重要的事1.我是 1-(wo)man startups（https://venturehacks.com/arti...）理念的忠实拥护者，尤其在我们现在的组织规模下（大概 25～30 位工程师）。虽然我们中的一部分人在自己的领域非常突出，但为了保证组织的敏捷性和快速迭代，希望每个人都能把自己当作复合型人才看待。 你的 take-away 信息： 1. 熟悉公司前进的方向并对如何达成目标所需要的技能有所了解，如果需要学习新的技术栈或者方法论，我会尽我所能帮助你。 2. 你有权要求安排关于新技术的培训或者购入相关资料。 3. 如果你更喜欢在某个领域钻研，那你也可以跟我聊，我们可以一起看看有没有这方面的机会，同时也权衡一下利弊。 4. 我们鼓励组员接受新的挑战和职位。2.当涉及研发如何帮助业务的时候，我的产品哲学是客户第一，产品第二，其他第三。虽然有点老生常谈，但是真正能够做到这个标准的组织还是少数，大部分人都会花非常多的时间在项目和产品层面，但是很少有人愿意真正花大量时间去了解：我们的产品是否真正意义上改善了客户的体验。我们的愿景是让我们的客户成功——请把这句话写下来摆在桌上或者记在脑中 :D。这份材料可以作为参考：https://www.useronboard.com/f... 你的 take-away 信息： 1. 客户能否受益将是衡量你的产出的重要标准。 2. 多花时间去和产品、市场和销售部门的同事聊聊。他们作为前台部门能最直接地了解客户的需求。在新项目开始前，找个机会请他们吃个饭，问问他们是如何判断客户需求和客户在意的点。 3. 我坚信研发要能促进业务的发展，如果你发现有能够改善现在产品的机会，就应该扛起责任，推动各方来完善。 3.在快速发展的组织中，冲突是不可避免的。 你的 take-away 信息： 1. 没有冲突的话，我们将缩在各自的舒适圈内，即使在需要的时候也没人敢提出反对意见。 2. 我很欣赏资深工程师之间的那种信任。当你觉得有什么事在朝着不太对的方向发展时，要勇于提出异议。在提出意见的时候请尽量做到友善和建设性，但千万别憋着。 3. 无论在何种情况下，先认清楚自己的身份：我是这个项目的负责人？还是顾问？还是路人。 4. 在提出问题的时候，一定要就谁能做决定达成共识，然后确定如果这个问题超出权责范围的话应该去找谁沟通。确保每个问题能定论而不是不了了之。我最不喜欢什么毕竟我不是你的父母，不能一直庇护你。在知道了什么事情比较重要后，也应该了解一下如果表现出哪些行为且长时间没有改善的话会有可能会被开除。 ...

写在前面优秀的项目管理者是怎么工作的，如何帮助研发团队高效工作？一直是 CODING 关注的重要话题，我们不断地打磨 CODING 研发系统来让开发更简单。近期我们精心挑选了几篇硅谷科技公司研发管理者的 README 进行翻译。README 主要用来向团队成员展示项目管理者的工作理念和工作方式，以便成员能够快速地融入到团队当中。 原文地址：https://github.com/molly/manager-README 原文作者：Molly，HubSpot 的技术负责人，一位暖心的女技术主管译者注：HubSpot 是一家为社交媒体营销、内容管理、网络分析和搜索引擎优化提供工具与服务的科技公司。 前几篇我们翻译的是男性研发管理者的自述管理者（https://zhuanlan.zhihu.com/p/...），接下来我们来分享女性研发管理者的工作方式和管理风格。在下文中，除了对技术的持续追求、对高效团队的不懈努力之外，我们也看到了作为女性管理者特有的细腻：比如注重团队成员的心理状况、对多样性的包容。 Hi，我是 Molly。 非常期待认识你！写这篇文档是为了让你更好地了解我的思考方式和工作方式，不过它并不能取代我们之间共同建立工作关系以及相互理解的过程。 我的角色长话短说：作为技术主管，我的职责是确保团队的整体成功和快乐氛围、成就客户、完善产品与业务。更详细的职责如下： 确保你不但职业上成功，同时心理上也能保持快乐。 我希望你能够在团队中提升技术能力、发展职业、享受你的工作，并且秉持团队和公司的愿景。确保我们团队的方向是正确的。 你可能听说过 Dharmesh 关于“对齐向量”的讨论（https://thinkgrowth.org/what-... ）：确保我们团队是一致的，朝着同一方向前进。译者注：Dharmesh 是 HubSpot 公司的创始人。 “对齐向量”是指利用线性代数中的矢量概念来描述团队合作，Dharmesh 受到了 SpaceX 创始人 Elon Musk 的启发：将团队中的每个人看成一个矢量（有力量和方向），当所有矢量的方向调整为一致时，它们的力量加和才会达到最大值。 如果团队成员能力都很强，但各行其道，那只会事倍功半 确保我们能与其他团队各取所需，并且在做正确的事情，而不一定是被要求做的事。我也参与开发写代码。以上的职责按照重要性有先后顺序，如果你事业不成功、工作也不快乐，那我们的团队也不会成功、快乐。当团队出了点麻烦，那写代码很可能就不是我的首要任务。 另外：我的工作不是准确地告诉你该做什么和该怎么做，我不是团队的“官方决策者”。当我向其他人询问反馈时，有人问了这一点，然后说了一些令我心酸的话：你需要对团队做出的决定负责，即使你不是大部分时间在做这些决定的人。 我会认真阅读你的代码，我希望你对我的代码也有所思考。 到一定阶段后，你会全权负责你自己的代码。如果你有一个很好的理由去做些其他事情，你尽管去做，“善用判断力”是 HubSpot 文化的关键部分，它同样适用于敲代码以外的所有事情。 请尽情反馈如果你对我有啥反馈，请告诉我。团队里可能有一些你喜欢的东西、想改进的东西、一些你认为我搞砸的事情、或者我没正确分类的事情。即使你认为它们不值一提，我还是想听听；即使你认为我不想听，我也想听听你为啥会有这种感觉。 我更喜欢面对面的反馈。如果你只愿意用电子邮件或者 Slack，那也 OK，至少比你不提来得好。 如果你有想法但不愿意直接给我反馈，你可以反馈给我的上属，这样他们就可以通过匿名的方式传递给我，而我就可以着手处理它们。 同样地，如果你对一个团队成员有反馈，我建议你直接告诉他们。如果这么做让你觉得不舒服，可以随时让我来转达。 如果你还在纠结反馈的问题，告诉我，我们可以讨论下。 关于一对一我每周会在你的日历上安排三十分钟的一对一会议。如果你需要更多的时间，我会调整。第一次我们可能会安排一小时的一对一会议，只是为了确保我们有足够时间去过一过团队任务和介绍性事务，你不需要专门为此做什么准备。 一对一是你的表达机会，我可能会有一些事情要和你讨论，但首先是你的主场，可以谈谈你最近在做些什么、需要什么、希望改变什么、对团队、同事的感受如何、职业目标等等。这些都是当我们坐在同事的办公桌前你可能不会和我进行的对话。如果你想给我一些事务的状态更新或者你被什么问题卡住了的话，更适合在我办公桌前快速和我聊一下，或者通过 GitHub 的 issue、Slack、单独的事务会议。 如果你认为有帮助的话，我鼓励你写下你想聊聊的事情。在会议时临时想一些事情是有点困难的。如果你有想谈论的事情，但很难口头表达出来，可以提前给我一个粗略的议程。如果你不知道该谈些啥，就直接说你不知道该谈啥，我们就把它作为一个话题。 这些都是我看过的一些有趣的文章，尽管我不一定同意所有的观点:[1] https://getlighthouse.com/blo...[2] https://medium.com/@mrabkin/t... 如果你看在其它事情上有独特的想法，这也可以成为我们一对一不错的话题。 关于绩效在一对一上我会给出你的绩效反馈。如果你十分担心你的绩效，我会让你知道绩效结果。如果你觉得我对你的绩效有些担心，也请告诉我。 工作时间当我在办公室工作时，你可以在 11:00 ~ 17:30 找到我，我经常会比这个时间早点或晚点。在工作日，我经常下班吃完晚饭后在家继续工作。 ...

优秀的项目管理者是怎么工作的？如何帮助研发团队高效工作？这一直是 CODING 关注的重要话题，我们不断地打磨 CODING 研发管理系统来让开发更简单。 近期我们精心挑选了几篇硅谷科技公司研发管理者的 README 进行翻译。README 主要用来向团队成员展示项目管理者的工作理念和工作方式，以便成员能够快速地融入到团队当中。 原文地址：https://bit.ly/welcometonetfl... 原文作者：Roy，现任 Slack 研发主管，曾就职于 Netflix。 上一篇我们翻译的 README 来自一位走“民主路线”的管理者（ https://zhuanlan.zhihu.com/p/... ），这一次的 README 来自一位“硬核风”的管理者——Roy。Roy 在 Netflix 与 Slack 先后有两个 README，下文是他在 Netflix 时使用的。这也是你可以在网上找到的首批管理者自述文件之一，许多人从 Roy 身上得到了启发。 欢迎来到 Netflix，致我的新下属。 Roy Rapoport 2016 年 2 月 13 日 文档说明免责声明：以下内容不适用于 Netflix 或其它组织的在职经理。 我希望通过这份文档快速地向大家介绍 2016 年我是如何在 Netflix 管理研发团队的。它仅代表了 Netflix 文化与我的管理风格的独特融合，并不能代表我在其它组织或者 Netflix 其他管理者的方式。经历过了种种快乐，我在 2018 年 1 月离开了 Netflix，从那时起这份文档似乎就变得不实用了。但有不少人希望能够继续参考它，因此它依然开放给大家。 写这么个文档貌似是有点奇怪，没关系，我们还会有很多机会相互了解。这是我目前能想到的高效介绍一些事情的最好方式。它不仅仅是一个 PPT（译者注：原文是 PPT 格式，为优化阅读体验译者改为文章格式，但内容不变），更是一个信息公告。进入正文前你最好先阅读并熟悉下 Netflix 公司文化（ http://jobs.netflix.com/culture ）。 ...

众所周知，在项目管理的过程中，我们需要非常注重沟通，而每日例会作为沟通管理中的一项最佳实践，非常适配互联网项目短频快的特点。成功地在项目中建立例会制度，能带来以下好处：1）让研发人员相互之间了解各自的任务完成情况，以便于上下游及时衔接，发现进度异常和集成的风险；2）让技术难题和业务疑点及时暴露，并根据问题的普适程度，选择在会上或会后得到支持与解答；3）让产品经理了解研发过程，一方面及时掌握动态，另一方面能对结果和风险抱有更深切的同理心，以便后续能更紧密地合作；4）帮助团队建立秩序感和纪律性，提升组织的成熟度。作为一名在弱矩阵型组织中拥有微权力的 PM ，要在一个尚没有形成惯例、且仅为完成当前项目而临时组建的团队中建立例会制度，笔者建议以如下方式迈出第一步：一、事前摸底可以先通过访谈对话的方式，收集项目组成员在如何透明研发进度和风险方面的认知情况，甚至可以了解一下其所属部门的工作风格，以便采取合适的应对措施。如果有成员曾经参与过项目每日例会的相关实践，务必抓住这个机会，尽量说服 TA 作为你安插在项目组中的卧底，在必要的时候主动站出来配合你，这样的话，其他人也更容易行动起来。可能也有成员曾在例会中经历过糟糕的体验，比如：时间冗长、议题蔓延、信息过载、与之无关等，这时，你一方面要庆幸提前发现了暗礁，在自己组织的例会中要尽量避开（当然，如果你有丰富的项目管理经验，阅会无数，那你能举出更多的失败案例，但无须事事防范，否则过犹不及，让自己处处掣肘），另一方面，也要更加谨慎地实施你的想法，避免对方受到二次伤害，进而对 PM 和改进工作丧失信心。二、承诺约定PM 需要具备一定的主动性，在项目启动之初（比如： kickoff meeting 上）提出例会的建议，可以介绍一下例会对项目及成员所带来的好处，与大家（包括 PO ）约定每天在固定时间和地点同步一下各自的状态，挑选大家都合适的时间，并获得每个人的口头同意。作为交换， PM 须针对大家关切的问题作出一些承诺，比如：确保会议的质量，时间不会超过 15 分钟，会后有文字材料输出用于追溯。不仅是例会制度，绝大部分的改进工作都会要求参与者走出舒适区，做出一定的让步甚至承受阵痛，故所谓“投之以桃，报之以李”：你愿意配合我的工作，我也不会让你失望。针对之前调研所掌握的信息，给项目团队吃下定心丸。三、不见不散可以要求让每个人创建一个日程提醒。但无论设几个闹钟，刚开始几次例会，还是会有不少人迟到甚至忘记出席，需要经过反复提醒才会慢慢养成习惯。守时是职业操守之一，但如果遇到成熟度较低的组织，则需要不断灌输和教育。这时候， PM 一方面需要及时补位，在会前就做好提醒工作，另一方面也可以于会后在项目日志中做好记录，在必要的时候反馈给当事人所属部门的负责人，一起帮助 TA 改进。身处于某些组织文化中的读者，可能会对这种直接了当的反馈方式抱有畏惧心理，但考虑到“如果团队尚未达到理想的成熟度，未来高阶的改进工作将难以开展”这一点，就不应该回避沿途的任何困难。另外，例会地点尽量固定，以便于大家习惯的养成，否则每次换地方都要再通知，成本很高。四、每日三问首次例会一般需要花更多的时间，最主要的一点是 PM 需要向大家讲解和示范如何参与例会。当然，在 承诺约定 环节可以做一些铺垫，但光是口头解释缺乏身临其境的场景感，大家未必都能 get 得到。所以，也不必赘述，只要现场主动参与和切身感受一下，包教包会，屡试不爽。为了争取最佳的投入产出比，我们有必要把例会的环节设置得尽可能的精简，但又不失效果。笔者建议会上所有人站成一圈，每个人（除 PM 和 PO 之外）轮流向团队回答三个问题：1）我昨天做了什么（即：工作进度）；2）我今天打算做什么（即：工作计划）；3）我遇到了什么困难（即：暴露风险）。前两个问题，上下游与之依赖的组员会特别关注，比如：前端依赖于后端的接口实现，否则他自己的功能验证工作会迟迟完不成。而第三个问题， PM 和 PO 会比较关注，他们有义务为项目扫除障碍，比如： PM 需要协调项目团队以外的技术顾问来做支持， PO 需要解答产品功能细节的疑惑，不一而足。通过上述三个问题，信息在项目组内部变得完全透明，成员对工作更有目标感， PO 对成功交付更有信心，妈妈再也不用担心我的项目了！如果组织得当，按每人三句话的速度，一次例会妥妥地被控制在 15 分钟以内。当然，由于例会的时长非常短，为了确保会议的效率和效果，仍然要求 PM 控制好会议的节奏，同时也需要项目组成员全身心投入。五、反馈改进每人分享完自己的三个问题且没有其他公共议题了的话（非公共议题应放在会后单独进行），项目团队的首次例会就进入尾声了。此时，大家的精神状态已经放松下来了，由于是第一次例会， PM 可以在宣布散会前询问一下大家的与会感受，以便后续做改进。也许首次例会并不如你预想的那样完美，比如：有的成员不太善于表达、有的成员会忍不住和其他人开小会、有的成员羞于公开上报自己的风险，等等。但至少你已经迈出了第一步，项目组成员的心中已然被你播下一颗种子，后续免不了还要不停地浇水施肥，帮助他们积累如何高效参与例会的经验，在现有最小可用例会的基础上持续迭代。小结导入项目例会比较适合作为对组织实施效能改进工作早期阶段的一次试探，以投石问路的方式了解组织对轻量级变革的接受情况。如果较难接受，则说明组织的成熟度不高， PM 要做好贴身辅导打持久战的心理准备，反之则能顺利推广并赋能到组织的各个角落。在有赞建立项目管理体系之初，笔者曾倡议试行项目例会，有幸被广泛接纳，辅之以实物看板，简直如虎添翼。曾经有一段日子，某间狭小的会议室，在一个小时内轮番成为四五个项目的每日例会之场所，与会人员络绎不绝，一派繁忙而有序的景象。作为 PM ，每次参与项目管理都是一次帮助组织进化的机会，而每个为新项目所临时组建的团队中，都可能出现你曾经合作过的同事的身影。让他们成为你效能改进工作过程中散在各处的星星之火，从此，你将不再是一个人在战斗。

最近几年一直在做技术管理工作， 期间也是感慨颇多，总结成经验跟大家分享一下（部分资料来源于知乎某大佬的分享），如果你也在做技术管理工作，希望这些对你有所帮助: )向下管理技术人员一般都比较年轻，较少来自生活的压力，他们更注重工作体验、团队氛围、公司福利、扁平化、个人发展前景。所以管理年轻的团队， 需要给他们清晰的愿景，传递好公司的价值观，同时又要做到人性化，为他们考虑，和他们一起成长。一定要让那些让你满意的人满意，不让你满意的人可以选择性的放弃。赋能你的团队成员，看到每个人的优缺点，扬长避短。对下属要严格，认真帮助他分析自己的优缺点，并帮助他提升优点，规避缺点，让他做能够发挥他长处的事情。关注PM，QA，RD的感受，让他们爽，你就会爽，领导总是会从侧面了解你的团队。适时做职员谈话，了解工作状态和诉求，让他多说，自己多听。把对下属的反馈放在平时，不要积怨，不要将加深误会。与其他部门，例如pm提出的需求，采用yes，but模式去回答，而不是以工程师思维来思考。遇到需求先考虑资源是否充足，技术难度等，习惯性的说no。如果能招到一个比你级别高的人，他还心甘情愿在你手下工作，这相当于变相提升了自己的级别。向下多关心，把荣誉给下属。向上管理了解你的老板，知道他们在意什么，了解他们的性格和习惯，是阅读型还是倾听型的。了解自己的不可替代性，在恰当的时候，跟老板提要求。让老板知道你在做什么，但不要太细节。真诚的为公司和老板考虑。跟领导谈的时候要注意，利益要一致，信赖对方，尊重对方的情绪，就事论事。与领导有冲突，事后要理智的分析。要反思，太快下判断，以为领导要搞你，其实他是为了帮助你。从自己的角度出发，看不全面，一定去跟领导沟通，但是之前要站在老板的角度把细节想明白。左右管理让跟你合作的人舒服，尊重他们。做利益交换，达到共赢。自我修养倾向性，给别人确定的答案。当你成为一个20人以上团队的leader，技术会变得不重要，找到懂技术的人，做技术创新和业务创新，变得更重要。给予团队成绩，让团队每个人成功。沟通和协作，增加团队成员参与感。赢得他人的信任，让别人乐于分享他的问题。去关注产品。不断提升技术深度跟广度。