工作中的一些思考与想法（2018）

虽说这篇文章不涉及代码，但我认为他确实与一个公司的开发者有关。

三思而行

最近我接到了一个非常紧急的任务，原本有三个人负责一个紧急事务，周日加班做了一天，结果发现搞不定，其中一个人又抽调做另一个紧急事务，这部分事情就交给我，预估是约2.5个工作日后发布上线，据说还是高层的人拍板定的。我一看这个事情就知道不可能按期完成，玩了命加班也不可能，特别是在做事情的过程中，遇到很多部门上的障碍，再加上流程制度的约束，想要保证质量上线，2.5日是不可能完成的。

当然过程中加班确实很辛苦，而且没有加班费，这个没什么。具体到这个事情上面，我认为很多人对这件事情本身的思考是不够的。一件事情紧急到专门抽调人手去做，而且要求多少天之内必须有相应的产出，本身就是一件非常诡异的事情。假如这件事情真的有这么重要，我到公司这几年，为什么从来没做过？既然这么多年都没有做，为什么非要抢这几天？我相信很多人根本就是糊里糊涂的，回答不了我的问题。

一方面团队研发的平均水平确实不高，另一方面研发的人力非常紧缺，这个时候如果不能想清楚再做事，后果是非常严重的。抽调人手紧急上线需求，团队资源消耗巨大，整体觉得疲惫。好不容易拼死拼活干完了，一旦数据不行，整个团队又很懵逼。开始怀疑自己做事情的价值。

其实在我看来根本没有所谓的紧急需求，所有的紧急需求都是大脑短路一时想不清楚的结果，如果一件事情的价值真的能大到很多人认为他紧急，那么这个事情一定是经过深思熟虑提出来的，相应的准备工作可能早就开始了，不会演变成周六觉得不错，周日开始动工这种情况。反而是那种毫无方向，没有准备的人，抓住救命稻草一般的，不经过思考提出的才是紧急需求。

研发是一个特别的工种，他做的事情是产品提出的，因此本质上是产品和研发在配合做事情，产品是占主导地位的，但如果产品本身水平不行，想问题不全面，研发在实现的时候就要反过来找他确认细节，原本产品的工作就落到了研发身上，一般这种情况下，研发加班会比产品多很多。

作为产品，做事情前要多思考。作为研发，我们本身没法要求产品能做到三思而行，但至少我们在接事情时应该动脑子，懂得拒绝不经过大脑的事务，推动需求方细化细节，必要时讲解技术方案中的关键点，帮助需求方理解他要做的事情应该是什么，胡乱接事情，只会害了自己的团队。

目标是什么

在一个产品迅速发展壮大的时候，无论做什么功能，都好像有很多人会用，用户数量都会涨，迅速增长的用户量会掩盖很多问题。当用户量开始下跌，或者增长放缓的时候，就会有很多问题浮现出来，最明显的一个是没有目标，俗称瞎JB乱搞。一个产品解决什么需求，应该做什么事情，本身应该是比较明确的，但总会进入一个迷茫期，不知道应该干什么，于是会做非常多的事情，什么东西都要搬进来做一做，然后整体上看就是东一榔头西一棒子，别人要是挑战这个，他就说自己在试错。

试错本身没什么问题，但在没有目标的情况下试错，就很容易出事，一件事情到底应该投入多少时间去做，目标是什么，达成目标应该怎么样，没有达成是继续做还是放弃，这些都是很关键的问题。如果不想清楚，可能会在一件没有意义的事情上浪费很多精力。特别是把KPI和目标混为一谈的时候，就会出现强烈的KPI导向，导致团队开始不做正确的事，开始搞KPI数据。

什么叫正确的事？满足用户需求，解决用户的问题算正确的事，但拼命的加功能，同时还用各种小红点，弹窗等恶心的手段逼用户体验新作的、对他们没什么意义的功能，就会很恶心人。很多时候用户不是傻逼，这么玩固然能获得一时数据上的增长，如饮鸩止渴，终将害死自己。

什么叫搞KPI数据？一个很常见的情况：假如我们的KPI目标是使用时长增长10%，于是就开始算我们各个功能的时长，每个功能要提升多少，分派下去，每个功能都涨了，整体目标就达成了。于是各个功能就开始各种骚扰用户，逼用户来用，以此来完成KPI数据提升。但一个应用的使用时长高，一定是他解决了用户的需求，让用户喜欢用，如果功能上没有任何变化，仅仅是疯狂拉用户来用，当然不可能真的把时长提上去。

所以做一件事情的目标到底是什么？不忘初心，这个初心就是我们的目标，我很能理解，做一件事情慢慢做变形，与初心相违背的情况，这太常见了，所以我们应该时刻提醒自己做这件事情的目标是什么，反思现在的手段是否与我们的目标背道而驰。

工作量评估

不知道从什么时候开始，互联网公司都开始反复提到几个词“敏捷，小步快跑，快速迭代”，与之相伴的现象是需求变更频繁，去制度去流程化，项目排期极度不合理。

其实我并不认为这几个词有什么问题，我也是部分赞同这几个词背后的理念的，但就好像是言者无心，听者有意一样，总有一些人打着敏捷的旗号做一些错事。

比如高强度的加班，保持每周一个版本。像前面说的那样，一个紧急需求，要求几天内就能上线，很多人说这叫快速迭代，小步快跑，认为这样叫敏捷。

在我看来这更像是要你无偿加班的借口。

一个事情的复杂程度不会因为团队声称了自己要快速迭代，就变简单了。事情本身的复杂程度，和做事情的人的能力，决定了一件事情要做多长时间才能达到完成的标准。非技术人员，往往会觉得技术很简单，不需要那么多时间，所以会认为项目周期太长，这个可以理解。可怕的是现在很多技术人员盲目乐观，或者为了满足团队对他的期待压缩自己的排期计划。

可笑的是还有很多人觉得原本10天的工作量，假如对外声称只要6天，最终结果是8天就能完成，可以省2天。其实这种情况就是自欺欺人，要么是这个工作确实只需要8天，要么是这8天他疯狂加班，把10天的工作量做完了。无论哪种情况，这种人都是害群之马，会把整个团队的风气带坏。假如大家乱评工作量，最后项目风险就不可控。假如大家评少了工作量然后加班，这个团队会因为加班太多流失人才，最终整个团队的水平下降。

流程与制度

一个需求从提出到最终实现，应该是严谨的，经过反复讨论确认细节的，大部分产品当然没有能力准确把握用户的需求，但思考还是要有的，到了研发手里，代码怎么设计，如何和现有的app功能结合，实际的编码，测试验收，代码review，最终发布，都应该有一套完整的流程，其中涉及至少需求提出方，设计师，技术实现人员，测试工程师，代码审核人员五个关联方，如果说一个东西能几天就做出来，要么就是没有严谨的流程，要么就是关联方拿了不少加班费。当然在中国，可能得无偿加班。

既然流程让我们达不到所谓的敏捷，在一些团队，就会出现一种趋势：简化流程，去除制度。

要知道互联网公司的端产品团队的流程，本身就是最少的，不信可以问问后台的研发，一个包可以不经过灰度直接发布到生产环境吗？周五允许发布吗？后台由于其特殊性，对可用性的要求极高，因此很多制度都定的非常死，这些制度后面都有着血的教训。

同样的，广义上的前端团队，其实本身流程就是很少的，这些少之又少的流程，背后同样也是在一次又一次的事故中慢慢总结出来的，如果为了所谓的效率把这些流程简化掉，就好像一个犯错的人不长记性，下次还会再犯同样的错误。

认清自我

我所见到的去流程化，基本上都会对一个部分动手：测试。

从前大家都是很依赖测试的。测出的问题一旦多，返工就很多，周期就会拉的很长，于是大家就想了歪招，把测试干掉。

干掉测试有两种思路，一种是研测一体，既是研发又是测试，这样不就可以减少一个关联方，提高测试效率了吗？另一种是不搞测试，提倡自交付，要求研发人员在设计阶段就能把可能出现的问题规避掉。

对于研测一体，包括产研测一体，我都是不屑于和他们争论的，因为我认为这本身就是一个伪命题。我们的社会之所以能提高生产效率，就是因为人们的工作朝着专业化，精细化在发展，本来社会就是朝着分工明确的方向发展的，所有的研测一体基本上就是在反其道而行之。

而自交付，则对研发的能力有极高的要求，能完整做到自交付，至少也称得上是某个技术领域的专家了，因为他有识别风险和在设计阶段就规避风险的能力。

我所说的认清自我，不是说我们自己要认清自我，而是指公司和团队要认清自我。

产研测三个职位都是有其专业性的，这种专业性是难以同时掌握的。能掌握的，至少也称得上是优秀的人才了。很多公司其实是招不到这样的人的，因为这些公司没有能力留下这么优秀的人才。公司最大的优势就是用制度来为他的许多东西保驾护航。我认为人很容易犯错，但制度能尽量避免人犯错，以及降低犯错带来的损失，如果一个公司招不到优秀的人才，只能用普通水平的人，那么制度是非常重要的，随意的去制度化，去流程化，最终的负面效果是潜移默化的，短期内当然看不出来，时间久了，各种弊病就会出来。

如果你是顶尖的公司的团队，提供顶级待遇，你当然能招到足够优秀的人才，不需要条条框框也能做事。但如果你是一家普通公司的团队，得学会认清自我，认识到自己员工的局限性，用制度约束，同时悉心培养。

人贵有自知之明，公司也是。