首页 文章 精选 留言 我的

精选列表

搜索[程序人生]，共10010篇文章
优秀的个人博客,低调大师

2016年 智慧城市新项目让威海人生活更精彩

乘公交车可以刷手机支付、看病可以提前网上挂号;周边吃、游、购、娱有什么优惠，手机“摇一摇”就知道;企业可以通过云平台免费获知行业内的最新信息……2016年，一批事关生产生活的智慧城市新项目将落地实施，切实服务市民生活和产业发展，不断提升企业管理和城市建设信息化、现代化水平。 以信息技术为载体的智慧城市建设，是提升社会管理服务精细化和便民化水平的有效途径。“坐公交车前查查手机APP，踏着公交车的时间点出门，不用等车的生活太方便了!”说起智慧城市建设带来的变化，市民陈晓光赞不绝口。去年，我市在智慧城市建设中大力实施便民惠民项目，推进了智慧交通、智慧城建、智慧供热、市民网、智慧旅游等19个项目建设，越来越多的市民感受到了智慧生活的方便与快捷。而19个政府部门的政务数据对外开放，尤其让创新创业者们有了更可靠的信息渠道。 “今年的智慧城市建设将更加注重服务百姓生活和产业发展，除了在原有基础上继续推进市民网、市民卡、智慧教育、智慧旅游、智慧交通5个续建项目建设外，还将推动企业融合服务平台、智慧医疗、智慧环保和摇一摇4个项目立项实施，进一步扩大智慧城市服务面。”市经信委信息化推进科相关负责人介绍。 预防接种和车辆登记这种事也可以进行网上操作了。今年市民网将新增210项政务和300项便民服务，并将研发教育、文化等10个专题服务模块，90%以上服务事项将覆盖全市域。一张市民卡将串起百姓生活的方方面面，水、电、气、暖、通信、有线电视等公共事业缴费服务和各类政策性补贴发放等功能，都将纳入市民卡中，年内实现市民卡乘车、停车场支付应用，并全面覆盖环翠区、高区、经区和临港区。而对于乘公交车出行的市民来说，在原来用手机APP查询车辆运行情况的基础上，通过开通手机支付平台，今年有望实现刷手机乘公交车。 只要用微信“摇一摇”，就可以通过手机获取周边“吃、住、行、游、购、娱”等优惠服务。这样的智慧生活将有可能在今年变成现实。“我们将利用蓝牙、移动互联、物联网等技术，在旅游景区、车站、商铺等重点区域铺设相关硬件设备，今年计划接入500个商户、市区公交车及站点、AA级以上景区等。”市经信委相关负责人说。 智慧医疗方面，今年我市将搭建市、市(区)、镇(街道)、村四级智慧医疗卫生网络，全市公立医院和基层医疗机构接入率100%。建设人口健康信息综合平台和区域影像、心电、双向转诊、远程会诊等应用系统，实现全市公立医院和基层医疗机构服务协同。全市二级以上医院全部接入统一预约挂号系统，居民看病网上挂号率达到30%以上。此外，通过智慧环保建设，空气质量预报准确率提高到90%以上，预报天数由1天增加到7天。 服务产业发展也是今年智慧城市建设的重要内容。依托云计算中心，我市将改造升级工业设计云平台功能，建设面向产品设计、生产制造、市场营销、经营管理、政策服务等各环节应用的企业服务云平台，由政府购买部分服务，免费提供给本地企业使用。“按照这一思路，我们还将推动完善中韩跨境电商服务平台，建设鱼竿渔具云制造大数据平台，汇聚相关行业内的数据信息，为本地企业提供行业数据分析、指数发布、跨境交易、协同研发、商务智能等一体化综合服务。”市经信委相关负责人说。 本文转自d1net（转载）
2017-07-02
优秀的个人博客,低调大师

技术人生第5篇——浅谈如何成为技术一号位？

作者 | 贺科学 前言 绝大多数的人都有自己的思维定式，都有无形的枷锁束缚着自己的思维，从而导致行为也被束缚，所以在他人看来会有这样的现象：有些事情该做却没有做，有些事情不该做却做了很多。我们抛开公序良俗、社会道德、法律法规等等这些约束人在社会活动中必须遵守的束缚的情况不谈，只谈论在工作方面、或者说“做事”方面可能有哪些无形的东西在束缚着大家，和大家一起探讨如何看到这些束缚，打破这些束缚，从而获取站到更高层次的机会，完成自身角色的转变。 认清每个人自己在日常工作中的思维定式非常重要，有助于转变自己对很多事情的认知，而这种转变也会从根本上带来行为上的变化。也就是说，可以通过理论分析和实践，来共同完成对个人实际生活的影响。 所以今天这篇文章，我们会先讨论业务研发同学，或者说大多数的业务研发同学的自我认知是什么，再看下这种普遍的自我认知之内，是否已经存在着大家视而不见的思维定式；然后再讨论思维定式产生的原因是什么，如何突破这种由认知不到位而导致的自我束缚；最后再探讨业务研发同学应该存在什么样的认知，如何通过实践完成自己从普通开发到技术一号位的角色转变。 业务研发同学普遍的、存在思维定式的自我认知&产生的原因及解决办法 1、业务研发同学普遍的、存在思维定式的自我认知是什么 从上大学选择专业开始，“编程”、“做技术”、“大牛” 仿佛对理工科的人有极大的吸引力。所有信息化相关专业的人毕业以后，这种“成为大牛”的情结依然发挥着重要的作用，让毕业生们从校园走到工作岗位上以后，仍然能够驱动自己不断地在工作中学习和积累（当然驱动研发同学努力提升自己能力的也有可能并不是“大神”情节，而是“残酷的现实” —— “不懂”、“不会”、“做不了” 可能会被“现实打脸”），提升自己的技术水平，朝着自己崇拜的“大牛”的方向持续努力，完成个人成长的第一阶段。 也正是这样的发展路径，逐步地让研发同学自己形成了 “技术人” 的角色认同。 于是，绝大多数的业务研发人员会把 “写代码”、“做技术” 当成是自己工作的主要内容，认为自己是“做技术的”。 这种认知的形成，是周围环境和个人日常行为共同促成的。这种自我认知本身是正确的，但是只有这种认知，是错的，是对个人角色片面的理解。在这种自我认知的驱使下，研发人员的目光会关注编码规范，关注代码性能，关注编码技巧，关注研发效能，也会关注新的技术，关注各种高大上的技术名词及背后的实现原理；但是如果一个研发人员只通过这种认知驱使自己做出实际行动，那么这种行动本身和行动获取的结果，都是不能满足研发人员所处的外部环境对他的要求的。这是为什么说现在大多数的业务研发人员对自己的认知是存在思维定式的原因。 客观来看，大多数研发同学的这种认知，其实只是关注了自己默认角色（研发）对自己的要求（有足够高的技术能力），而没有关注周围环境对自己的需要，这种关注上的偏差，造成了 “实际行动” 和 “环境要求” 两者之间的不匹配，会带来很多问题，并且这些问题只从原来的认知层面做出行动是解决不了的。 2、研发同学的这种自我认知和环境不匹配的原因是什么呢？ 一种情况是，你所处的环境发生了变化，而从最开始你就对环境的要求有错误的认知，没有意识到差异，导致了这种“环境要求和个人行为结果”不匹配的矛盾随着时间的推移越来越大，一直大到无法被忽视的情况下，才会被重视起来，才会做出反思和调整。 但是这种调整是被迫的，不是主动的，可以理解为是一种无意识的应激反应，下次再遇到同样的问题的时候，不同境界的人会有不同的反应： • 没有悟性的同学，会任由这种不匹配继续造成无法忽视的问题以后，再去“无意识”地解决； • 悟性高一些的人，会通过之前的经验，在问题处于一个可以被明显感知但是尚未到达影响无法忽视的阶段即可化解。不过凭借经验并不是一个稳定可靠的办法，因为总有很多事情是没有事先经历过的，在没有经验的支撑下，还是会出现和没有悟性的同学一样的问题； • 悟性最高的同学，会通过现象看到本质，总结出相关的方法论，在事情来临的时候使用方法论分析问题，判断事情发展的趋势，仿佛可以站在更高的视角和维度，去旁观整个过程发生了什么，怎么避免再次发生，怎么降低这种问题的影响或者直接避免这种问题的发生。 针对这种情况，举个例子，比如刚毕业的学生往往不能适应社会工作和生活，再比如男女朋友结婚以后，敏感的一方会觉得另外一方变了，这些都是因为个体所处环境发生了变化，因而对环境中的个体的要求也发生了变化。所以，当你个人所处的环境发生变化以后，比如去了新的公司，比如换了新的团队，比如下属变多了，比如业务换了方向，比如负责一个新的业务等等，要对这些环境的变化有足够的敏感度，要检查环境的变化是否对自己产生了新的不一样的要求。 说白了就是要检视自己的角色是否因为环境的变化而发生了变化，需要用变化以后的角色去处理事情。 另外一种情况是，你所处的环境没有变，但是你自己随着时间的推移发生了变化，从而导致环境对你的变化产生了新的要求，但是由于你没有感觉到这种由自身变化而引发的环境要求的变化，没有做出对应的及时的调整，那么就会导致新的不匹配的出现。 针对这种情况，举个例子，比如刚晋升的同学，环境对你的要求随着你的能力的提升是变化的，要以新的角色去响应这种变化以后的要求，而不能继续用原来的角色和做事方式去做。所以，大家也要对自己个人的变化有足够的敏感度，要检查自己的变化是否引起了环境的不一样的要求，要检查自己现有的做事方式能否满足这种要求的变化，如果不能满足，要分析什么样的角色能满足，然后转变个人认知，以这种角色去做事。 综上所述，“环境变了你没变，或者你变了环境没变”，都需要分析环境对自己的要求是什么，要判断现有的认知驱动的行为是否能匹配这种要求；如果不能匹配，那么要分析什么样的行为可以匹配新的要求，要分析这种行为是哪种角色应该做的，然后就能知道自己要转变的方向了。这个理论和结论不止适用于业务研发，而是普世的，是单纯地讨论“个人和其所处环境的要求是否匹配”的问题的。这些理论分析，实质上是在使用《矛盾论》的理论方法分析 “人与环境” 中的 “人的行为及结果与环境的要求” 的矛盾的分析，这种矛盾是对立统一的，也是随着时间、随着环境、随着个人的变化都会发生变化的。 我们从枯燥的理论分析回到业务研发同学的问题上来，业务研发同学从开始入职到成长成为一个技术不错的技术骨干，往往两种情况都经历过了。 第一种情况，从学校毕业到参加工作，经历环境变化以后，经历了“社会的毒打“ 以后，大多数人都是通过提升个人技术能力来度过这个阶段的，而这种解决问题的办法也为大家经历第二种情况的时候带来了很多麻烦：按照经验，提升个人技术能力即可应对环境要求，但是事实上，随着你个人的成长，环境对你不再仅仅只有技术方面的要求了，继续提升技术能力只能起到提升你个人技术能力的作用，不能弥补环境对你的要求和你的行为之间的不匹配的问题。很多研发 leader 或者技术骨干有过这样痛苦的经历，认为自己技术好就会被赏识，就没问题。但是问题其实本身跟你个人技术好不好没关系，跟你是否能满足环境对你的要求有关系。技术好，只是获取周围环境对你提出新的要求的“资格”，而不是解决方案，而继续提升个人技术能力，不是真正的解法。真正的解法，是认知上的改变，而由认知的改变带来的实际行动的改变。 3、如何做到个人的行为及其结果匹配环境对个人的要求？ 如果说，绝大多数的研发同学都有这种认知误区，并且未来一定会经历“随着个人能力的提升而环境对自己的要求会变化”这种事情。那么如何解决这个问题呢？简而言之就是 “开始要有正确的认知，后面要随时调整自己的角色”。 首先，问题（环境要求和个人行为及结果不匹配）产生的原因是什么，我们上面已经说得非常清楚了，在已经知道原因的前提下，首先要做的其实很简单，就是“正确认知环境对自己的要求”。 业务研发同学面对的环境要求是什么，是 “写代码”、“搞技术”吗？不是，“写代码”、“搞技术”只是你的工作内容（而且只是非常小的一部分），不是环境对你的要求，环境对你的要求是：帮助客户实现业务数字化（不接受任何反驳和讨论，因为理论上的讨论没意义，但是欢迎以任何形式通过实践来检验）。也就是说，所有做业务开发的同学，从你认可了这个理论分析这一刻开始，你不再仅仅是一个“研发工程师”，更是一个“客户业务数字化工程师”，你默认的角色——研发工程师，在目前的大环境下，附加了新的角色和与之对应的职责，在认知上需要改变自己过去毕业就形成的旧的认知，要尝试转变到新的认知上来，理解新的角色所蕴含的要求和期待是什么。 所以，过往我们都说研发工程师，JAVA 开发，前端开发，全栈开发，go 工程师，这些分类都是从你个人掌握的技能来划分的，而不是从你的职责划分的。这种传统的划分方式，对你也起到了很多误导和禁锢作用。要知道，如果你是在业务团队，除了以上的岗位角色以外，不论你的技术栈是什么，你更应该被称为“业务数字化工程师”，这是你过往没有关注过但是其实一直都存在的“新角色”，这个“新角色”会从过往的隐形变为现在的可见、从幕后走到台前。这一角色和与之对应的责任，会让你在原来的工作内容的认知上，感知到新的维度。 在这个认识下，你会意识到，业务面的知识学习、需求分析、领域建模、模型落地、流程优化这些东西的比重和基础性，不低于写代码的比重，甚至更高。虽然我们所有的论述都是在讲业务研发同学，但是本质上，做纯技术平台开发的同学也是一样的道理，你们的任务是帮助业务研发同学数字化，或者更高效、更低成本地让我们帮助客户业务数字化。你的业务需求是技术性的，如果你不能对技术平台的业务需求有足够的建模分析能力的话，技术系统与业务系统相比而言更高的逻辑复杂度和更高的抽象性，一样会给你造成极大的困难。 “帮助客户实现业务数字化”这个要求，并不是让你停止发展你自己的技术，而是要求你对“业务”两个字投入更多的精力，要对它有新的理解，而不是把它当做“妨碍我写代码的事情”。所以用一个比喻来形容，就是：做业务开发的研发同学，不论是什么水平，什么等级，带不带人，都需要“技术”和“业务”两条腿走路。 这是所谓的“正确地认知环境对业务研发同学的要求”的意义：让业务研发同学找到并重视修炼自己另外一条“走路的腿”，并且要利用做业务的过程锻炼这条腿的力量，通过掌握适当的方法论，加速力量的形成，加强这条退的强度，因为终将有一天你需要靠着这两条腿带着很多“一瘸一拐”的业务开发同学往前走。为什么说“一瘸一拐”的开发同学？因为目前来看绝大多数的业务开发同学都只是“在做业务需求”，而不是“在做业务”，做业务方面的能力和技术能力不匹配，因此还做不到“两条腿走路”，最多是一瘸一拐。 举一个所有研发同学都能看明白的例子，来最后概括一下上面的意思：如果你认为自己只是写代码的，做技术的，你只关注写代码，只关注怎么提升你的技术能力，而不去关注业务能力的提升，那么你就陷入了自己认知上的偏见给自己埋下的坑里，这种偏见和以下两种你一看就知道有问题的事情本质上是一样的： 产品经理只需要做产品原型就好了。 运营同学只需要向用户端推送广告就好了。 现在能感受到“研发同学只需要写代码就好了”是一种偏见吧？需求分析？要做！各种沟通的会议？要开！业务发展规划？要做！很多原来被大多数研发同学看成是“干扰我写代码”的事情，其实都是你的角色必须做的事情，而且这些事情的比例甚至比写代码还高。因为帮助客户业务数字化的过程，写代码、做技术只是第一步而已。 下面两个图，是普通的业务研发人员的视角看问题和技术一号位看问题的视角。 普通研发人员看问题的视角，是以资源的视角来看问题的，以资源的视角看问题，就只能对一件事情做有限的行动，最终就只能被当做资源： 技术一号位的看问题的视角，必须转换为 Owner 的视角来看问题，即和你相关的事情就是需要你为之负责的（并不一定是负主要责任，但是一定是要负责任的）： 需要关注的就是上面第二个图中的“职责范围圈”，普通研发同学受限于自己的认知，只能做最里面的写代码的事情，随着技术能力的提高职责范围可以逐步外扩，但是永远接触不到其他角色的职责范围圈，而技术一号位的职责范围圈会逐步扩大到与之相关联的各方的职责范围圈上，甚至有一部分的重叠。这是最能直观表现两者由于认知差异导致的角色扮演的差异，导致的行为及结果上的差异。 业务研发同学如何成为技术一号位 在认识到自己做的事情是“帮助客户业务数字化”以后，在“做业务”方面的要求就会变得和“做技术”方面的要求一样重要了。关于“做技术”，可以在大学里面学到基础的技术领域的专业技能，工作以后也有大量的书籍和项目可以学习，所有的研发对此毫不陌生；但是对于 “做业务”，似乎没有那么多可以参考或学习的东西，更多的是个人经验的积累，那么想要成为技术一号位，怎么办？ 我们先做一个这样的假设 —— “我们可以通过分析一个事物的组成，观察这个事物的生命周期，以及了解这个事物在整个全生命周期内和外界发生的关系及相互作用来全面认识一个事物”。 我们既然想要学习 “做业务” 的知识，来让自己有能力变成技术一号位，所以我们必须全面认知一个事物，在认知的过程中知道它需要什么样的能力，而这些能力是我们需要通过各种手段逐步锻炼的。 所以要想回答研发同学如何成为技术一号位，首先要搞懂一个业务包含什么，它有怎样的生命周期，它和外界的关系影响是什么？ 在数字时代，个人总结分析，从抽象的角度来看，一个业务会有以下方面的信息需要大家了解： 1、什么是业务 涉及一个以上组织，按某一共同的目标、通过信息交换实现的一系列过程，其中每个过程都有明确的目的，并延续一段时间。 2、业务存在的目的和价值是什么 通过创造价值给企业带来收益（可能是经济上的收益，可能是其他方面的收益，例如品牌、口碑、社会形象等） 3、信息时代常规业务涉及哪些方面 价值生产 数字化技术 商业产品 产品运营 产品销售 客户服务 风险控制 综合协调 4、业务有怎样的生命周期 立项 开发 扩张 成熟 衰退 5、业务和外界有什么关系，有什么相互影响 价值的声明，让外界知道业务会对外界产什么什么价值，可以获取什么回报 价值的生产，通过物质或虚拟的生产过程创造价值 价值的传递和扩散，被创造的价值为更多的外界主体所了解，接受，并愿意为创造的价值买单 价值的交换，通过创造价值获取经济收益 价值的反馈，外界主体对价值的反馈 价值本身的提升，根据外界主体对价值反馈做针对性的改进 价值生产过程的改进，根据内部主体对创造价值的成本、效率等的考量而做的各种实际或虚拟的改进 价值的持续输出，持续地向外界受众提供价值，持续获取收益 价值的消亡，随着外界的变化，价值不再具备换取收益的能力而不再被生产 6、让一个业务诞生，尽可能实现它的目标并延长生命周期，需要具备的能力 业务的立项，证明其价值，让业务从无到“可以有”。 业务的开发，让业务从概念变成实际存在的事务。 业务的产出的包装形成产品，让客户以良好的体感感知到业务的结果。 业务的运营，让业务的产出获取更多客户。 客户服务，帮助客户解决使用产品过程中的问题 有机地协调业务的参与各方，按照最优的方式让业务尽可能长地运转下去，通过各种手段延长业务生命周期 7、哪些是技术一号位的职责 业务的价值产生过程中，业务数字化过程中的一切技术相关的事务都是技术一号位的职责 协助业务一号位完成业务落地支撑，参与业务的全生命周期，参与业务的决策过程 利用技术能力，在业务的各方面对业务目标的达成和生命周期的延长提供支持 我们在了解以上内容的基础上，需要知道一个客观事实：“做业务”需要的知识，和“做技术”需要的知识，本质上没有区别，都是个人实践的经验+前人经验总结（书本上的知识），所以做业务的知识会在知识形态上和技术知识一样，具备以下一些特点： • 可以被学会 • 可以通过个人实践获得 • 知识分布的形态以知识树的形式被外界感知 • 知识树的分叉意味着知识会有不同的细分领域，有一定的广度；知识树的层次意味着会有一定的深度 • 系统性学习知识的人，可能会比其他人更深入地掌握某个分支的知识（知识的深度）；也可能比其他人更广泛地掌握多个分支的知识（知识的广度） 技术领域常常会讨论如何权衡个人发展路线上的深度和广度两个方向。同理，在“业务学”上也有同样的情况。不过由于现在所处的数字时代，业务本身就包含着数字技术，所以大家作为业务研发人员天然在 “业务学” 的技术细分领域上有深度的积累，产品人员天然在“业务学”的产品细分领域上有深度积累，运营人员天然在“业务学”的运营细分领域上有深度积累，职业经理人天然在 “业务学”的综合管理细分领域上有深度积累。所以大家要想成为一个业务的技术一号位，要做的是加强 “业务学” 的广度的积累，围绕业务的全生命周期，熟悉它的组成，参与掌握、把控它对外界的影响和交互的过程，并且在自己负责的细分领域内做到全面的负责，就能够成为一个业务的技术一号位。 这个结论目前只是为了让大家在思想上认识到对技术一号位的整体的要求，转变过去的 “研发本位” 的认知误区，至于怎么一步一步通过实践变成技术一号位，还需要继续看其他文章来掌握对应的知识，依靠掌握的方法论来指导实践，避免走弯路。 解决方案咨询技术交流群：搜索钉钉群号 31704055 加入，可获取云原生详细解决方案资料与专家答疑。
2021-07-29
优秀的个人博客,低调大师

「技术人生」专题第1篇：什么是技术一号位？

技术一号位系列文章介绍 研发人员经过一段时间的成长和积累（3-5年），往往需要带领团队或者小组承担更大的责任。很多扮演了 teamleader （TL）角色的“管理新人”，在带人做事遇到困难的时候会陷入纠结：要不要放弃这个发展路线继续做一个单打独斗的技术“老人”？特别是在一些环境中，管理新人本身面临着陌生的领域和挑战，如果没有领路人，单纯依靠自己去实践感悟，往往会走很多弯路。 所以本文作者结合多年实践经验，以及结合很多经典理论的输入，总结出了“技术一号位是什么”、“普通研发人员如何一步步成长为技术一号位”、“作为技术一号位需要掌握哪些理论工具来支撑日常工作”等一系列能够引导技术人员升级认知的理论工具。 同时需要强调的是，技术一号位不是岗位，更多的是技术人员在公司中做事的一种心态， 这个系列的文章适合所有想要对日常工作“知其然更知其所以然”的技术人，借助理论工具的指引，结合自己的实践经历，悟到自己的收获，从而加速成长的过程 。大道理千千万万，有缘者得之真谛践于其行而非流于其表。 技术一号位方法论系列文章计划： 《什么是技术一号位》 《技术一号位的方法论【理论篇】—— 如何分析事物本质及分析事物本质的必要性》 《技术一号位的方法论【理论篇】—— 解决问题的规律概述》 《技术一号位的方法论【理论篇】—— 解决问题的规律在技术、业务、组织方面的应用》 《技术一号位的方法论【理论篇】—— 浅谈技术人员如何成长为技术一号位》 《技术一号位的方法论【业务篇】—— 什么是业务，以及业务运转需要哪些方面的支撑》 《技术一号位的方法论【业务篇】—— 什么是指标，如何构建业务指标》 《技术一号位的方法论【业务篇】—— 如何画业务大图、产品块图、兵力投放大图、战役大图》 《技术一号位的方法论【技术篇】 —— 浅谈如何做复杂业务系统的领域驱动设计》 《技术一号位的方法论【技术篇】 —— 浅谈如何做复杂业务的数字化》 《技术一号位的方法论【技术篇】 —— 浅谈如何做稳定性建设》 《技术一号位的方法论【技术篇】 —— 浅谈如何做业务风控能力建设》 《技术一号位的方法论【技术篇】 —— 浅谈如何让技术支撑、保障、驱动业务发展》 《技术一号位的方法论【技术篇】 —— 浅谈如何做分布式系统建设》 《技术一号位的方法论【技术篇】 —— 浅谈如何做秒杀》 《技术一号位的方法论【技术篇】 —— 浅谈如何快速掌握陌生技术领域知识》 《技术一号位的方法论【技术篇】 —— 浅谈一些常见技术问题的解决模式》 未来一段时间，阿里巴巴中间件公众号会持续发布系列文章，欢迎关注。 前言 什么是技术一号位、有哪些关注点、怎么做技术一号位？ 做了研发团队的技术 leader 以后，要处理的事情非常多，如果对自己扮演的角色没有一个清晰的认知，就会出现该做的事情没有做，不该做的事情投入了过多的精力，造成实际行动和结果既不匹配上级的要求，又不匹配下级的期望。特别是对于刚开始带领研发团队的新人 leader 而言，角色的转换和适应的过程，增加了认清自己的角色本质的难度。今天我们抛开纯技术团队的同学不谈（其实本质一样），只讨论业务研发团队的同学，如何以技术一号位的角色来做事。 如何识别自己是不是技术一号位 在开始谈如何做事之前，首要任务是判断自己是不是技术一号位，而要判断之前，首先要明确判断标准，跳出思维误区。这里我们列出一些常见的思维误区。 以下是常见认知误区： 带人的是技术一号位，不带人的不是技术一号位。 级别高的是技术一号位，级别低的不是技术一号位。 以上的认知误区，错误地把是否带团队、技术等级的高低和是否为技术一号位关联起来。虽然事实上带团队的业务研发同学成为技术一号位的概率更大，但是本身这两者不是划等号的关系。 那么什么是区分是否为技术一号位的决定性因素呢？很简单：**对一个具体的业务而言，你作为该业务的直接技术参与者，是否处在技术领域责任链的最顶端。**这句话翻译过来就是，对一个明确的具体的业务而言，多种角色的同学一起合作的时候，你是否是技术序列的最终责任人，即： 谁承担对应的责任，谁就应该扮演对应的角色 。 当产品经理、运营、研发共同做一个业务的时候，某个研发同学独自或者带领其他几个研发同学，或者带领跨 BU 的研发团队，共同支撑 PD 的业务需求。那么这个研发同学就是这个业务的技术一号位，不论他是否带不带人，也不论他带的人在行政上是否从属于他。一般来说，负责单一业务的研发团队 leader 一般就是这个业务的技术一号位；负责多业务线的研发团队的 leader 的下属，是每个业务线的技术一号位，而研发 leader 本身是更高层面业务的技术一号位。 所以，做业务开发的技术同学，不论是什么层级，带不带人，都可能是某个具体业务的技术一号位的。 这一点非常重要，只有认清这个事情以后，业务研发同学才能在做业务的时候，明确下来自己除了需要写代码以外还需要做什么，关注什么；这些关注点需要做到什么程度，才能对上满足期望，对下不让团队走弯路、不和下属抢功。 当你经过以上判断以后，确定自己是技术一号位时，恭喜你，你已经不再是一个仅仅需要写代码的研发同学了。很多研发同学眼中还是只有写代码这一件事情，如果以这种方式做业务，那么就会发现业务过程会有各种没有做到位的事情，会在做业务的过程中“交很多学费”，甚至会因为自己的能力不够而拖慢业务发展。 虽然成熟的研发团队可以通过完备的研发过程管理，来避免个人能力不够而对业务产生太多负面影响，但是本质上强制的规定和“上级要求”只是在依靠行政管理手段在强制一个人做这些事情，并没有唤醒他的创造力和责任心，反而会被认为是“工作琐事”。这些“工作琐事”本质上是需要他扮演的角色来负责的，但是由于他没有意识到自己实际上已经是这样的角色了，而仅仅把自己停留在“研发”的定位上，把“写代码”当做核心任务，这样一来，会让研发同学对那些看起来 “和写代码无关但是是技术一号位必须做的事情” 非常抵触。这种抵触情绪发生的时候，leader 再强调 Ownership 也都没有太多效果，因为不是他不负责任，而是他没有意识到，这是他应该负责的事情。当他的心态和认知转变以后，一些原来看起来不怎么负责的人会变得负责（不排除有人本身就是不负责的人，那么这样的人不是良好的技术一号位的候选人，主管要有识别能力）。 作为业务开发同学，一定要仔细认清辨别自己实质上是不是一个业务的技术一号位，而不用考虑自己的层级，不用管自己是不是业务其他参与者的 leader。当你意识到自己是这个业务的技术一号位的时候，就要迅速切换角色，从原来自己给自己的定位 “写代码的、搞技术的” 转变为 “某个业务的技术一号位”，开始进入角色，发挥出你的价值。这也是很多研发同学通过做业务能迅速成长的原因，抛开技术上的成长之外，他比其他研发同学接触了很多 “做事情需要思考并为之行动” 的维度，这些维度的丰富是普通业务研发同学很难看到、很难感觉到，因此更难悟到的。 不排除有悟性高的研发同学能够自己悟到，但本质还是由于他所处的环境、他面临的问题在逼迫他做出思考，然后为之实践。 如果一开始就知道自己做事情要找准自己的角色和定位，那么就会少走很多弯路。 分析你所在环境的局势 当你意识到自己是一个业务的技术一号位的时候，不用过多怀疑自己究竟是还是不是，而是要本着“就当自己是”的心态来进行接下来的工作实践和思考。需要大家明确的一点是，任何一个工作角色，都有对应的责任，也都有履行对应责任的方法论。我们要做的，不能再像过往做普通研发的时候那样懵懵懂懂去做事，听“需求”指挥，而是要开始寻找或总结一些方法论，要自顶向下地对业务有一个清晰的认知，知道自己比过去多了哪些维度的事情要关心，知道接下来会面临什么样的挑战，要知道自己在挑战中应该扮演什么样的角色，采用什么样的手段去解决业务在不同阶段一定会出现的各种问题。 在开始所有的思考之前，先要做一件事情，就是分析你目前所处的环境的局势。 业务方面 你的大团队的业务大图是什么 你负责的业务的大图是什么 你负责的业务大图是否和大团队的业务战略匹配 你负责的业务和大团队的业务看似没有契合点的时候，你的leader跟你对焦以后的结论是什么 这个业务对客户的价值是什么 这个业务对组织的价值是什么 这个业务对你个人的价值是什么 这个业务是否会在未来承担社会责任，会有怎样的社会价值 这个业务目前处于什么阶段，是刚开始，还是已经成型等待发展，还是已经发展一段时间需要业务规模 这个业务目前存在最大的问题是什么 协作方面 谁在配合你一起做这个业务 和你一起做业务的同学中，分别有哪些角色，他们会在哪些方面和你有交集 和你一起做业务的其他角色的同学，是否对业务大图的理解和你一致 和你一起做业务的其他角色的同学中，谁是业务的负责人；或者关键角色的人员是否对自己是业务负责人有感知 业务上下游的同学段位怎么样，是否能在实际落地过程中跟上你的节奏 业务一号位的KPI是什么，你的KPI是什么，你们两人的KPI是否方向一致，你的KPI是否能支撑他的KPI 团队研发方面 现在是否有一个研发团队支持你一起做这个业务 和你一起做业务的研发团队是否在行政上从属于你 你带的团队人员每个人的特点是什么，有什么短板，在这个业务里面负责什么事情 研发团队里面谁是你的接班人 研发团队里面谁能补充你的短板 研发团队里面，每个人做事都有什么个人的想法？个人的成长目的 研发团队里面的每个人对业务大图是否了解，认知是否一致，目标是否一致 如果你本身已经是专家级别以上了，那么下面这些维度可能是需要你继续深入思考的： 业务方面 业务的愿景是什么 业务的愿景在不同时间维度上拆解以后的关键业绩指标是什么 为了实现不同时间维度的关键业务指标，你准备投入什么样的资源？投入的资源之间相互怎么配合？相互配合的原则是什么 这个业务现在做是否合适？现在做不合适的话，需要在什么时候做合适 这个业务现在做不合适的情况下，哪些因素让你觉得现在做不合适 让你觉得现在做这个业务不合适的因素中，哪些因素是可以通过人为干预让它不再是阻碍性的，哪些是可以通过人为干预增加它对业务的积极作用 业务的现状及瓶颈问题 业务问题的技术解法 业务发展趋势 业务竞合分析 业务发展策略 业务的终局畅想 团队方面 团队的使命是什么 团队推崇的价值观（做事原则）是什么 当前团队的人才梯队是否合理 当前团队的人才储备方向是否完备 当前支撑业务的团队是否未来依然能够支撑业务的发展 当前团队不能继续支撑业务的战略规划的情况下，需要做怎样的调整 协作方面 业务是否可以向其他BU借力，或者借力于其他BU 当前的业务是否和其他BU可以相互配合形成某种合力的优势 当前业务和其他业务如何配合来完成未来的布局从而获取对应的优势 未来的布局落地后，想要形成什么样的局势 局势形成以后，对完成组织愿景，履行组织使命有什么决定性帮助 找准自己的定位，明确自己的定位的含义 当理清楚自己所处的环境以后，知道业务是什么情况，和自己配合的人又是什么情况以后，需要知道自己扮演的角色究竟意味着什么。从我个人的经验来看，技术一号位是负责使用技术能力解决业务问题，提供稳定可靠的技术支撑，确保业务安全合规低风险地健康发展，并通过技术或业务创新来推动业务发展；负责向业务各方提供各种必要的技术支撑，通过合理的数据分析为业务决策提供依据；通过对技术领域的积累和发展，通过业务领域的理解和落地影响业务决策；负责构建梯队完整、能力全面、制度完善的技术团队来支撑业务发展。 应该有什么样的工作原则和要求 1、以业务一号位的视角思考，辅助业务一号位构建合理的业务大图。 2、以技术一号位的角色保障业务落地，协助业务一号位实现业务的客户和组织价值。 3、掌握和业务建设过程中各种角色的上下游协作者合作的专业能力： 在产品方面具备基础的产品规划和设计能力； 在业务方面具备有一定深度的领域知识，或者具备相关的方法论可以快速向领域专家完成领域知识的学习； 在商业化方面能够提供合理的商业化模型设计，包含提供合理的计费维度和技术成本清单； 在产品运营方面能够了解常见的基础运营手段和方法论，能够结合运营策略给运营同学提供准确的专业知识的支撑； 在客户沟通方面，能够有良好的倾听能力，理解客户的诉求，辩证地转换为系统改进的动力。 在技术方面在公共技术服务的基础上完成全维度技术能力建设，考虑技术的投入产出比，不能只做架构或只做核心代码的实现。 在团队方面能够建设合理的人才梯队，储备必要的技术领域人才，推行组织文化，确保成员对做事的风格和原则理解一致，有行之有效的方法论帮助不同层次的同学找到成长的突破口。 履行技术一号位的职责具体需要感知哪些事情及其要点 下面这张图从大方面上列出了一个技术一号位需要感知哪些方面的事情（图中未列出产品运营、售前售后等一系列其实很关键的方面，但是如果技术一号位负责的业务是有商业化需求的，则还是需要关注这些维度的事情的）。 这些事情是必须知道，但不是必须亲自做的，要能够借助团队的力量完成该完成的事情。下面是具体从业务、技术、团队角度来详细理清楚技术一号位需要感知的事情及其要点： 业务方面（后面会有单独的文章详细解释业务方面怎么做） 建大图 定方向 找打法 撑业绩 技术方面 1、技术选型 业务需要什么样的技术能力支撑 需要的技术能力集团或其他BU团队已经具备了并且可以被你复用 如果不能复用，差异点在什么地方 如果不能复用，差异点不是方向上的根本问题，是否可以通过共建或提出合理需求来完成复用 如果不能复用，不能共建，是否可以使用开源项目 如果不能复用，不能共建，需要自研，需要个人具备什么样的技术背景，需要团队具备什么样的技术积累 团队或组织是否已经有了相关的基础框架或效能提升工具 业务是否需要考虑数据安全问题，组织或团队是否有安全防护相关的积累可以复用 业务是否需要考虑业务风险问题，组织或团队是否有业务风险控制的积累可以复用 业务一般情况下都需要数据服务做业务运行期的运转情况的监控和后期业务决策的支撑，组织或团队是否有相关的积累可以复用 技术投入产出比 2、系统架构设计 1）业务场景在技术侧映射出来的特征是什么，对技术侧的影响是什么？ 一般而言，不同的业务场景会体现出不一样的技术特征，对技术反应出不同的需求。 面向B端客户的传统企业级应用，通常情况下对稳定性要求高，对数据安全要求高，需要保证业务操作结果和实际数据匹配。业务流量不大，系统用户对用户体验不如C端用户敏感。针对这类系统，往往通过简单的单体应用做高可用部署即可，使用单一数据库并通过数据库保障业务数据变更的事务，界面契合客户业务。 面向C端客户的互联网应用，通常情况下对流量承载能力要求高，对数据安全要求高，对用户体验敏感，对稳定性要求高，业务流量巨大，特殊的业务场景会出现特殊的流量峰值。针对这类系统，往往需要构建分布式系统做大流量高并发高可用系统架构建设，自顶向下分层优化，从终端层的静态资源CDN化，到应用层的前后端分离，应用逻辑和底层服务分离，再到核心业务层的微服务架构建设，从服务发现服务治理，到无状态应用的规模化部署，从大量基础中间件的使用，到大量公共业务服务的构建，每一层都需要做好对应场景的优化和架构设计。 2）如果业务会在某个发展阶段涉及到大用户流量，对应的系统技术架构是什么样的？ 大流量高并发高可用系统架构 业务流程异步化 使用限流手段确保系统不被突发大流量压垮 使用降级手段确保下游系统不可用时能够快速失败避免请求堆积造成系统无法接受或响应外部请求 使用逻辑隔离或物理隔离手段确保多租户模式下各租户互不影响 使用合理的资源调度策略确保不同规模的租户享受同等技术服务水平 使用合理的资源使用策略确保成本维持在合理水平 使用合理的监控手段提前发现系统承载能力的变化，及时通过扩容或缩容来应对系统流量变化 使用分库分表或根据业务需求采用合适的NoSql数据库来支撑海量数据持久化 使用缓存抵挡大流量对数据库的压力 使用分布式锁处理高并发业务场景下的公共资源抢占问题 使用幂等服务屏蔽高并发场景下的重复请求 使用分布式事务服务确保业务数据的最终一致 使用负载均衡承接业务流量，分配给后端应用服务器，避免单点风险 使用同城双机房来规避单机房风险 使用异地多活技术来规避单个城市的不可抵抗风险 3）如果业务非常复杂，领域众多，那么采用什么样的架构更合适？ 业务复杂的情况下，采用微服务架构 4）如果确定要采用微服务架构来支撑复杂业务，那么领域划分和每个微服务是否匹配，微服务拆分粒度是否合适？ 如果是单体复杂业务应用拆分为微服务，则应该按照业务领域来拆分，拆分后通过服务接口对外提供标准服务。 如果是开始就确定要做成微服务架构，那么要先做领域划分和建模，然后大的复杂的领域单独形成业务服务，公共依赖的领域做成服务，使用合理的服务治理框架，选择合理的服务通信协议，构建业务系统。 3、业务建模 业务领域知识学习。 业务领域建模，使用领域驱动设计完成战略设计（领域上下文的划分和上下文之间的协作模式的确定）和战术设计（领域内的实体、值对象、领域服务、实体工厂、仓储层、数据持久化层的设计）。 业务建模是否合理，是否采用了合适的方法论来应对不同复杂规模的业务？ 面对复杂业务，是否有完整的领域设计和匹配当前阶段的落地路径？ 针对复杂业务，不需要最开始即按照完整的业务模型做落地，而是根据实际业务需求和时间进度合理定制业务模型的落地计划，既确保需求能按时完成，又确保代码落地始终在业务模型设计范围之内而没有腐化。 4、研发落地 略 5、项目管理 项目目标 完成时间 想要取得的结果 项目成员 关键里程碑 风险预警 多方协调沟通 日常进度追踪 6、项目复盘 1）质量保障 代码扫描 代码评审 研发单元测试 团队业务需求沟通及评审 测试用例编写 测试用例评审 基础功能测试验收 上线发布验证 灰度测试 线上验收测试 自动化冒烟测试 每日自动化测试 2）稳定性建设 关键业务流程日志打点 全业务链路跟踪 系统技术指标监控 系统业务指标监控 告警 自动化告警恢复 关键业务场景预案建设 关键业务场景预案执行 值班响应机制 3）风控建设 业务风险点定义 业务风险点识别 业务风险点级别定义 业务风险点分级处理 业务风险点报警 业务风险点触发趋势 实时业务风险控制 离线业务风险扫描 业务风险点诱因分析 团队方面 成员 1v1 沟通 成员优劣势分析 成员做事意愿分析 成员角色定位对焦 成员能力梯队聚焦 方法论的探讨与实践 帮助不同的人看到自身不足，定制不同的成长规划 根据不同人的优劣势和做事意愿，安排调整合理的事情和责任范围，激发做事的主动性，为其发挥出创造力营造良好的环境 业务大图的解读和 KPI 的设定 工作原则和工作要求达成一致认知 明确团队要什么，不要什么，推荐怎么做，不推荐怎么做 要创新不要墨守成规 要思考不要苦劳 要打破思维定式和束缚，不要自我设限 要 Ownership，不要推脱 如何成长为技术一号位 目前还不是技术一号位的业务发开同学，虽然现在的岗位只负责一小部分，但是本质上来讲，只要你负责某个事情，那么不论这个事情大小，你都是这个事情的技术一号位，只是由于事情的难易程度和规模大小，导致很多可能需要做的事情其实并不需要做，但是这些问题并不妨碍你知道技术一号位要做什么，应该怎么做，更不妨碍你以技术一号位的心态去做事。 先确定好心态的问题以后，接下来就需要一些可以被实践检验的方法论来帮助大家打破自己层级的束缚，完成自我突破，从而在成长的基础上获得负责更重要的事情的机会，通过做好更重要的事情来获取更更重要的事情的机会，这样一定会在某个阶段，你负责的事情，需要完全以真正的技术一号位的角色去落地，那么那个时候扮演技术一号位的角色也就是水到渠成的事情了。 作者介绍： 贺科学（晨末），毕业于北京科技大学，工作10年，在企业级应用架构及研发方面有长期积累。擅长分布式系统架构，擅长复杂业务的领域建模及开发落地，掌握领域驱动设计及开发相关方法论，有实际成熟线上产品案例；2014年入职阿里云，先后参与或主导过阿里云控制台、阿里云容器服务、资源编排服务、云分期等云服务的建设。目前带领小型团队负责新零售业务相关的研发工作，累计C端用户过亿，承接阿里巴巴集团内外众多流量业务的积分兑换实物商品业务。 除业务以外，个人精力也投入在“复杂业务系统落地过程数字化”这一命题上，目前有一定思考和实际积累。实际工作中有3年带团队全面独立负责复杂业务系统的经验，所以在技术一号位的工作方面有相关的实践和思考。 联系邮箱：kexue.hkx@alibaba-inc.com。 阅读原文
2021-05-07
优秀的个人博客,低调大师

每日一博 | 人生第一个扩展——Github1s

1 灵感 某天看到了一个叫github1s的仓库： 基于Node.JS、Yarn、Python等技术栈，在github.com上面加上“一秒”，也就是github1s.com，就能在VSCode中打开该仓库，非常好用。 同时笔者安装有一个叫Sourcegraph的扩展，就是下面这个： 用过的同学都知道这个扩展是干嘛的，于是笔者就想类似的在这个扩展旁边加一个超链接的扩展直接打开github1s.com，效果图已经在上面了，点击那个VSCode的图标就可以直接打开。 2 动手 由于笔者并没有扩展开发的经验，因此先去看了一下Chrome扩展开发的文档并留下了一篇基础教程博客，然后就可以开始动手了，项目结构如下： 3 图标 关于图标，其实是花了一点时间的，比如，受到该仓库的影响，一开始定的图标是下面这样子的： 然后想了一下好像不太对劲，就改成了这样子的： 至于在扩展管理中显示的图片，改成了一个比较简单的： 这样图标的问题就解决了。 4 显示 下一步就是添加功能到扩展中并且让其显示在Sourcegraph的旁边，首先manifest.json如下： { "name": "Github1s", "description": "One second to read GitHub code with VS Code.(https://github.com/conwnet/github1s)", "version": "1.0", "manifest_version": 3, "content_scripts": [{ "matches": ["https://github.com/*/*"], "js": ["/js/icon.js","/js/init.js"] }], "action": { "default_icon": { "16": "/icons/logo16.png", "32": "/icons/logo32.png", "48": "/icons/logo48.png", "128": "/icons/logo128.png" } }, "icons": { "16": "/icons/logo16.png", "32": "/icons/logo32.png", "48": "/icons/logo48.png", "128": "/icons/logo128.png" } } 解释一下content_scripts，当匹配到matches中的URL时，便会自动执行js里面的脚本，先来看一下init.js，这个脚本的作用就是添加把图标添加到Sourcegraph的旁边： let list = document.getElementsByClassName("pagehead-actions") if (list.length > 0) { list = list[0] const li = document.createElement('li') const a = document.createElement('a') a.href = 'https://github1s.com/' + window.location.href.split('github.com')[1] a.target = '_black' a.className = 'btn btn-sm tooltipped tooltipped-s' a.style.height = '28px' a.style.paddingBottom = '0' a.style.paddingTop = '2px' a.innerHTML = base64Logo a.setAttribute('aria-label','Open with VSCode') li.append(a) list.insertBefore(li, list.getElementsByTagName("li")[0]) } 因为看了一下这里的代码： 就是一个<ul>包含<li>，于是就手动添加了一个<li>，里面包含一个<a>，加上样式、超链接以及一个叫ariaLabel的属性，这个属性会在光标悬浮的时候显示： 这样功能就实现了，剩下的问题就是图标的显示，因为不能直接插入图片： a.innerHTML = '<img src="/icons/code20.png">' 因为这样会被解析成： <img src="https://github.com/icons/code20.png"> 另外也考虑到缩放的问题，因此采用了base64+svg显示： 这样扩展就开发完成了。 5 测试 测试环境： Chrome 88.0.4324.150 Chromium 88.0.4324.150 Brave 1.19.92 FireFox 85.0.1 安装的时候开启开发者模式，选择Load unpacked即可。火狐的话打开about:debugging#/runtime/this-firefox，选择Load Temporary Add-on，接着选择manifest.json即可。 Brave测试： Chrome测试： Chromium测试： FireFox测试失败，因为目前版本（85.0.1）不支持Manifest V3，只支持Manifest V2，修改为V2版本后成功： 6 关于FireFox 上面也说了目前FireFox不支持Manifest V3版本，因此如果需要使用Manifest V2版本，两者比较可以参考官方文档。 7 发布 发布很简单，扩展管理页面选择Pack Extension即可。 如果需要发布到Chrome Web Store，需要注册成为Chrome网上应用商店开发者，可以参考官方文档。 8 源码 Github 码云 CODECHINA
2021-02-16

资源下载

更多资源
Mario

Mario

马里奥是站在游戏界顶峰的超人气多面角色。马里奥靠吃蘑菇成长，特征是大鼻子、头戴帽子、身穿背带裤，还留着胡子。与他的双胞胎兄弟路易基一起，长年担任任天堂的招牌角色。

时间: 2026-04-11 大小: 211.28KB 下载: 56次
腾讯云软件源

腾讯云软件源

为解决软件依赖安装时官方源访问速度慢的问题，腾讯云为一些软件搭建了缓存服务。您可以通过使用腾讯云软件源站来提升依赖包的安装速度。为了方便用户自由搭建服务架构，目前腾讯云软件源站支持公网访问和内网访问。

时间: 2026-08-21 大小: 1MB 下载: 10次
Spring

Spring

Spring框架（Spring Framework）是由Rod Johnson于2002年提出的开源Java企业级应用框架，旨在通过使用JavaBean替代传统EJB实现方式降低企业级编程开发的复杂性。该框架基于简单性、可测试性和松耦合性设计理念，提供核心容器、应用上下文、数据访问集成等模块，支持整合Hibernate、Struts等第三方框架，其适用范围不仅限于服务器端开发，绝大多数Java应用均可从中受益。

时间: 2026-08-21 大小: 5MB 下载: 2次
WebStorm

WebStorm

WebStorm 是jetbrains公司旗下一款JavaScript 开发工具。目前已经被广大中国JS开发者誉为“Web前端开发神器”、“最强大的HTML5编辑器”、“最智能的JavaScript IDE”等。与IntelliJ IDEA同源，继承了IntelliJ IDEA强大的JS部分的功能。

时间: 2025-12-13 大小: 249.54MB 下载: 22次
热门标签
DeepSeek Jdk25 OpenAi HarmonyOS6 Nacos3 SpringBoot4 SpringCloud Docker Kubernetes Service Mesh Redis Gemini3 Rocky

欢迎您来访！

登录后，您将获得更多功能！
热门文章
联系我们

有任何问题或合作意向欢迎联系我们

Email: 99873273@qq.com

QQ: 99873273

用户登录
用户注册