02｜法则一：为什么有些架构活动会没有正确的目标？

以一个普通的员工聊一聊我对项目的重要性问题的看法吧 大致顺序为 系统紧急修复->高优先级业务需求->收益高的技改项目->普通优先级需求->普通系统维护升级 其中，系统紧急修复，例如最近的log4j事件，是无条件全投入的 在无系统紧急修复的情况下，对于高优先级的业务需求，根据投入、收益和分配到的资源决定具体的注意力分配，优先分配给投入少收益大的项目，其次是 投入大收益大分配资源多的项目，这种项目一般为团队中比较重要的项目，这一点主要以公司的整体战略和发展为先 收益高的技改项目排在第二位，注意是收益较高的技改项目，一般公司都会要求在需求之外有额外的贡献，这种技改项目不仅锻炼技术能力，很可能也是你的晋升关键； 普通需求排第四位，这个是本职工作，不出差错即可 最后的是普通的系统维护升级，保证系统的99.999可用，一般都不需要花费太多的注意力，每周固定抽一段时间集中分析处理即可

第一个问题 业务的项目是无穷的，研发的资源是有限的，首先要明确一点是不可能用有限的资源完成无限的需求，必须针对这些项目进行排序优先级，然后再根据优先级来投入资源。 在投入资源的时候，还需要明确行业的趋势及技术趋势，与我们当前的技术能力，这中间是有Gap，需要正面这两者之间的gap，在整个的业务过程中要不断提升技术框架，达到行业水平。 面对业务的项目，我们要从两个角度来完成，分别是现有研发技术框架完成、提升技术框架完成。这两个角度就需要去做平衡，使用60%的研发资源来完成项目，再使用30%的研发资源来提升技术框架，还有10%的研发资源用于团队的技术能力提升。 那如何去判断哪些项目是60%，哪些项目是30%呢？我主要通过两个维度来衡量，分别是【业务价值】和【技术价值】，通过这两个维度去画四象限，把所有的项目划到这四个象限中，对于业务价值低&技术价值低的项目使用外包或者公共服务的方式进行，对于业务价值高&技术价值低的项目使用当前60%的，对于业务价值低&技术价值高的项目使用10%的研发资源，对于业务价值高&技术价值高的项目使用30%的研发资源 第二个问题 轮子的问题需要注意两点，分别是与业务挂钩、固定的迭代周期。技术轮子开始的时候都很好，往后更多的是一个是一个膨胀的系统，无法管理。这个时候需要想办法让整个技术轮子处于可控状态，通过与业务挂钩，能够保证整个技术轮子的资源投入，不会因为员工离职等各种理由中断。二是需要固定的迭代周期，保持技术轮子的活力，控制复杂度，让整个技术轮子形成稳定循环。 第三个问题 通过技术帮助业务成长，这个会让我觉得非常有价值。 回答完这三个问题后，我自己还想到了黄金圈原则，通过why-how-what的方式来思考业务。我们在活动过程中，经常会使用what指导我们做什么，使用how指导我们怎么样做，但是很少去问why的问题，为什么做？或者通过不断的why可以让我们更明确我们的目标到底是什么。

思考问题二: 我在以往的经历过的团队中，设计并实现过许多精巧的“轮子”，也许我的“轮子”并不是很关键，有些“轮子”直到我离开公司，一直在转，并且几乎没有过二次维护。我分别介绍一下失败的“轮子”和一直运行的“轮子。 1）失败的“轮子”： 当时在游戏团队，为了提高玩家体验，要做一个兑换码系统，需要批量生成和核销，在接到任务的时候，只有一个需求：一个兑换码只能使用一次。当时我技术老大跟我说，虽说现在需求只有一个，但是未来，我们可能用到一个兑换码可以使用多次，或者一个兑换码可以被不同的人使用多次的情况，你要好好考虑一下哦！于是我就放飞了自我，研究出8种核销兑换码的类型，并且最后上线了。上线之后，就发生了2次bug，出于责任的压力，我直接把另外7中情况在代码中“屏蔽”了，只保留了满足需求中的情况，上线后就再也没有发现过bug。直到我离开团队，另外7种情况也没用到～～ 2）一直转的轮子： 当时团队需要一个日志报警系统，需要给制定的公众号推送报警通知。于是我接下了这个活儿。封装了腾讯SDK、报警策略、调用接口。。。等等，分别单独封装的模块做测试，然后再做整体的“黑盒”测试，最后就上线了。之后只要是接到优化日志报警系统的需求的时候，先考虑：这个需求到底是不是报警系统该做的，如果不该做的，宁愿单独写一套服务，也坚决不往这个系统里放；如果需求是报警系统里的任务，比如增加“短信”报警，或者增加报警策略，就单独增加、或者修改相应的模块，并做好单独的模块测试，再上线。 这些轮子带来的思考：1）千万不要做过度设计，2）模块划分、测试驱动 是很好的开发策略，3）目标单一，非常非常重要！！

我是一个10多年的开发，一直是开发，我也想往“上”走，但是“上”又是哪呢？也许是性格上的缺陷，或者是学历的不足，最大可能是是“懒”，哈哈！ 思考问题一： 情况1：不该我考虑的不考虑！ 这个情况很符合我现在的工作环境，4、5个的项目（不同的框架，甚至不同的语言），一起堆过来，有时真让人抓狂！！遇到这样的问题，我会先那些提出需求的产品经理讨论项目的重要程度（安排优先级）！如果项目经理直接都说自己的项目重要，那么就把所有的项目预计的花费时间列出来，然后找到他们的领导或者我的领导叫到一起讨论优先级的问题（在我这个开发的视角中，是看不到哪个项目重要的，所以这事儿不该我考虑）。不论找不着上级领导确认，最后都要把最后的计划排期做成excel文档，邮件统一发出来，让所有人知道。 情况2:该我考虑的必须考虑！ 我对项目优先级的判断先把项目需求现做下面的分类： 1）哪个项目既能高效完成，又能带来收益 2）能高效完成，不会产生拖拉的后果，带来的收益并不是很大 3）带来的收益很大，但是占用长期的开发时间 4）既没有收益，又占用开发时间 我的选择是 1 > 2 > 3 > 4。事事难料，难免全篇一律，所以优先级选择还可能根据所处的环境做不同的选择，单基本上不会变。

感觉不同公司情况不一样，不同阶段也不一样，现在大体如下： 1. 涉及公司关键营收的项目，或者说是现在生死存亡的项目，分配50%的精力 2. 对于支撑公司日常运行的项目，分配10%精力 3. 涉及开拓新市场的创新类项目，对其中有盈利能力有增长空间的，或者说公司未来的项目，分配15%的精力 4.涉及开拓新市场的创新类项目，对其中有盈利可能的，或者说可能是公司未来的项目，分配10%的精力 5.对于一些政治类项目，用尽量短平快的方式达到目的，分配7%的精力突击弄完 6.对于一些没有盈利可能的半死不活项目，分配1%精力定期check一下 7.对于一些应该早些下线的项目，分配7%精力早日送走

直接进入思考题环节 按以往的工作经历，项目的重要性可能就是按照领导的喜好，或者是即将到来的最后期限。如果让我来决定，那么可以按照重要且紧急、重要不紧急、紧急不重要、不重要不紧急的优先级来排列。 如果让我自己来选，可能也比较喜欢“极简”设计，但是从某种程度上来看，所谓“极简”或者是“敏捷”的设计，有时候也是在思考上懒惰的结果。 在我参与的架构活动中，我比较喜欢和用户接触，去了解需求的过程，因为这样才能真正解决问题。

项目是否会对产品带来实质性的竞争力提升

如何判断一个项目的重要性？ 要是以前，我会看这个项目是否能让我感兴趣或者勾起我的好奇心，有可能是业务比较有趣或者可以运用新技术。 学完这一课，虽然我不知道公司的战略是什么，但是我会从用户的角度来看，这个项目是否有价值或者意义，再去考虑自己的因素

关于轮子的思考： 在分布式环境下，任何一次系统调用都会增加复杂度。所以我相信，发明轮子的团队一定深刻考虑过引入新项目所带来的复杂度问题。一个好的轮子，一定会有多个应用场景，在全局的角度看，如果这个轮子能收拢同类功能，让大家一键接入，降本提效，整体效率一定是最优的。 思考过往，总结下自己经历过的好轮子变成废轮子的情况： 1、公司经营环境发生变化，团队职能发生调整。 比如一个中台团队，是为了更好满足于公司各业务线的基础需求而建立的。当因监管或其他因素导致公司业务大量萎缩，中台反而成为累赘，中台人力需要转变为业务人力。那这一大坨中台系统，在业务的视角来看，就会成为过度包装的轮子项目。 2、全局规划与局部紧迫性的不匹配。 轮子项目服务与众多业务线，一个轮子想要变得更好，需要沉淀足够的经验后不断演进。当某个别业务线因为自身的特殊性，总是急需一些定制化的功能又不能被满足时，业务团队不得不另谋出路。要么是fork一个分支，要么是重新做一个。从长期来看，必然是重复建设，但在短期内，在业务团队的视角来看，新的轮子各方面都优于老的轮子。 3、KPI导向。 公司从上到下，都不喜欢一件事情写5年。今年从0-1开发了新东西，反响热烈，第二年从1-10，新增了许多特性。第三年就没有了，取而代之的是另一个关注点有点不同的“一站式解决方案”。为了让绩效更好看，貌似大家都爱这么做。 对于控制不了的原因，只能默默接收。对于kpi以及技术先进性等原因，需要与郭老师一样，紧盯目标，甄别伪需求。目标感是学了2篇文章以来感受最深的一点。

第一个问题 1、符不符合公司的战略目标 2、能不能为团队带来正向收益 3、需要各种资源大不大 4、个人是否能获得成长 依照这四个维度综合排序需求，不能成为被别人试错的工具人，做无意义的工作，只是苦劳而不是功劳