第一个问题 业务的项目是无穷的，研发的资源是有限的，首先要明确一点是不可能用有限的资源完成无限的需求，必须针对这些项目进行排序优先级，然后再根据优先级来投入资源。 在投入资源的时候，还需要明确行业的趋势及技术趋势，与我们当前的技术能力，这中间是有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、公司经营环境发生变化，团队职能发生调整。 比如一个中台团队，是为了更好满足于公司各业务线的基础需求而建立的。当因监管或其他因素导致公司业务大量萎缩，中台反而成为累赘，中台人力需要转变为业务人力。那这一大坨中台系统，在业务的视角来看，就会成为过度包装的轮子项目。 2、全局规划与局部紧迫性的不匹配。 轮子项目服务与众多业务线，一个轮子想要变得更好，需要沉淀足够的经验后不断演进。当某个别业务线因为自身的特殊性，总是急需一些定制化的功能又不能被满足时，业务团队不得不另谋出路。要么是fork一个分支，要么是重新做一个。从长期来看，必然是重复建设，但在短期内，在业务团队的视角来看，新的轮子各方面都优于老的轮子。 3、KPI导向。 公司从上到下，都不喜欢一件事情写5年。今年从0-1开发了新东西，反响热烈，第二年从1-10，新增了许多特性。第三年就没有了，取而代之的是另一个关注点有点不同的“一站式解决方案”。为了让绩效更好看，貌似大家都爱这么做。 对于控制不了的原因，只能默默接收。对于kpi以及技术先进性等原因，需要与郭老师一样，紧盯目标，甄别伪需求。目标感是学了2篇文章以来感受最深的一点。