论技术部资源有限性

在互联网公司经常会遇到这种情况，需求方（产品，运营，市场）经常性的吐槽技术部做的东西太烂，不好用，要个东西等好久才能做出来。
这是出现在各个需求方与技术部之间的矛盾。从根本上讲，是技术部资源的有限性，也可以说人员能力不足（资源质量差），或者人手确实紧张。所以技术资源有限性属于根本问题，或者说需求方认识到资源有限性是根本问题，假设一个人的资源不受限，那么他可以做许多事情，唯一的限制就是自己。

这里描绘一个理想场景，需求方在有需求的时候，同时能考虑自己的需求之于公司总体上的投入产出比，自己需求对于别人需求的优先级如何，自己需求能否有更优的解决方案（比如是否可以用Excel等现有工具解决）。
而技术人员在接到需求之前能对公司的整体业务场景有认识，对公司的诉求和目标了解，在接受到需求后，能够多想一步，对需求方的真实诉求有剖析，回归到诉求本质，要解决的根本问题是什么，而不是在接到需求后抬手就做，最终返工概率极高，或者设计不充分，造成后期扩展困难，不得不重写。
这个理想场景是不存在的，要求所有人都有真正的智慧，并且抛弃利己主义，一切以公司利益为重。
那么再回归一点现实场景，公司人员不是非黑即坏，个体之间建立良好的信任体系，有充分而且高效的沟通，诉求大体上是伴随公司一起成长。这已经是一个接近完美的组织体系了，这需要领导者有超高的智慧，选择合适的人，营造正确的企业文化。

再排除掉以上两种场景后，剩下的就是大多数公司遇到的场景，可以想像成这是一个班级，有各式各样的人，无论高矮胖瘦，聪明与愚钝，管理者也是平庸的。那么这就需要一种制度将团体效率最大化，不存在英雄主义，不依赖于优秀的个体这种不切实际的幻想，而是通过合理的制度发挥群体最大效率。
典型场景是，需求方不一定是以公司利益为准，要么是出于上级的直接要求，或者是个人利益，要争取资源达成自己的“假性目的”。技术部作为资源提供者，也并不考虑需求方的深层诉求。例如需求者要求造一个方轮子（需求者的上级要求做一个新颖的轮子），技术不考虑方轮子需求的现实意义，因为自己的本职是快速实现需求，所以一个简陋的木质方轮子做出来了；又或者是一个有追求的技术，作出了一个可以快速更换各种材质轮圈甚至支持不同轮圈拼接使用的方轮子。从狭义层面来看，双方都没有错误，需求方确实设计出了新颖的轮子，生产方或者迅速或者做出了有扩展性的轮子。但本就有限的资源，就被浪费掉了。

面对这种情况的时候，我曾经一起共事过的COO提出过一种方案，即独立技术部作为一个单独的事业部或者子公司，集团内其他事业部有需求的时候，利用购买制的方式为他们提供开发服务。当时我没有理解，多年后我终于悟出里面的道理。简单的讲，是让需求方意识到使用技术部是有成本的。部分需求方认为技术部就是提供服务的，是公共资源，自己不去争取，也是让别人用掉，就算东西最后做出来不上线，也无所谓。举个例子，如果馒头是免费的，你会先拿上5个，可能吃两个就饱了，剩下3个丢到也无所谓，但是如果馒头是收费的了，你考虑自己2个就够，就不会多买，因为花的是自己的真金白银。所以利用收费的方式达成利益一致，意识到资源价值，是这套方案的精髓。
接下来我论证一下这套方案的弊端。这里是纯理论层面，没有进行验证。如果说需求方就是和技术部看不对眼，那么有没有可能会把需求交给外面去做，而对于外包公司，在时间有限的情况下，做出来的东西可想而知，而且还要和公司内部做数据对接。这就是在已经是一团乱麻的基础上，又仍了一堆杂草，乱上加乱。
我对这个方案进行了升级，把金钱替换成credit，可以叫做积分，每个月的全部积分是技术部的全部工时，月初通过协商发给各个需求方，需求方再提需求的时候，利用积分兑换。这样的好处是避免引入外部混乱，也减少一些金钱的恶臭。但是讨论之后发现也是漏洞百出，1，这个credit的总量是技术部定的，这无可厚非就是总人工时，但是当需求方兑换一个功能的时候，这个功能需要的积分也是技术部定的，作为需求方我怎么知道你开发有没有糊弄我，明明是2块钱的萝卜你说成是2000块的人参；2，需求的优先级怎么定？看谁出的积分多吗，还是看谁嗓门大？

貌似在《凤凰项目》这本书看过一个方案，但是当我快速阅览以及Google之后没有找到原始文本，我只能把我记忆的部分描述一下。总体上是看板卡片方案，需求方把需求写在卡片上，技术人员写上需要的工时。每个需求方有三票，对所有卡片进行唱票，最后按照得票多少进行安排开发（这里面一些细节逻辑我记不清了，希望知道的朋友告诉我一下）。这里面同样是通过票数限定了有限资源，好处是可以通过坐在一起，而且给其他项目投票的方式解决了项目优先级的问题。这种看板方案我们实行过精简版的，但是最后没有实行下去。这里面有几个原因，1，技术部处于弱势地位，没法强制要求需求方接受看板流程；2，而且他们没有必要了解技术部正在做什么，别人的需求是什么样的。归根结底是利益一致性出了问题。

在这里我要插入一个事情，话说隔行如隔山，需求方大多数都不懂技术是怎么运作的，他们不知道重复劳作的事情是最应该交给机器做的，而因为某一次的需求单独开发一个功能有些得不偿失。而对于技术来说，什么ROI，什么转化率，30天留存，也不怎么关心，我也尝试了解别的事业部做的事情，但是讲真，简单走一两遍，很难了解其中的精髓。比如我试着回复一两封客服邮件，但这并不能了解客服工作中的限制点在哪里。我坚信量变产生质变，量没上来之前，我始终是一个门外汉。

需求方通常情况分为三类人，第一类是单纯觉得系统不好用，但是如何改进，是没有思路的，属于思考的比较少的人。第二类是处于自我保护的本能，把问题和坏处甩给技术部的人，可以叫做典型意义上的坏人。第三类是真的有格局的人，能从大局和长远的角度看问题，并提出合理的改进建议，并且自己会试图克服困难。

技术部除了常规的功能开发外，还要做1，功能改善，bug修复；2，底层优化重构；3，试验性项目。
堆积的多数进行中的项目会因为项目切换，造成严重的效率损耗，这就好比让系统多进程处理任务，但是因为进程太多，大量的CPU资源都被浪费到进程切换的开销上了

我们支持实验，但是要把实验的成本降低，其他部门也是这样的，比如一个广告投放，是实验性质的，一下子投100W出去，如果不成功那则是巨大的浪费，不如先投1W，短期效果好再加量完善。技术也是，如果是实验项目，就抱着实验的想法去做，主流程能跑通，一些瑕疵可以先忽略，等实验真的成功的时候再完善。需求方也是，不要把实验想的太大，把精髓总出来，先搞定精髓。

碎碎念

开发部门是否需要一些炮灰，因为如果没有人员流动，其他部门是否觉得开发部门就是养老，缺乏淘汰机制？

绩效挂钩，达成利益一致，或者说为什么会有利益不一致，因为是被名义上分成两个独立的个体，要把个体融合成整体，开发人员要去业务部门最少轮岗一个月
思考到这里，能想到两种解决办法，让技术部轮岗，保留真正懂需求的技术，让技术和需求方融为一体。另外就是需要项目经理观察整个工作流，发现其中的瓶颈，并讨论解决办法（因为我技术出身，所以发现限制点的时候，可以直接提出解决办法）。

现在又遇到新的问题，去轮岗，有的部门不欢迎，会有排外情绪