作为一只’前端猿’,随着工作年限的不断增长，对需求和团队管理也逐渐有了越来越多的认知。而很多萌新猿最容易焦头烂额的根源就是需求，当然年轻的BA/PM们也需要在猿视角翻看一波，成为更受猿喜爱的Leader。现在就把这些认知分享出来给大家作为一个避坑避险成长小日记吧。
一.学会剥光需求，笑看“祭天”活动
IT圈的我们都知道，一个产品从业务口拿到需求开始，到项目经理交付产品/项目为止，期间大概要经过产品/项目原型的设计，多轮需求评审，最后确定终版需求，开始UI设计，猿们着手处理研发相关工作，再经过一轮轮的测试和bug处理，才能正式投入生产环境使用。这条流水线上，每一个节点处的角色都免不了和需求打交道。那么，作为一个和需求密不可分的猿，“需求一变更再变、变无可变又回起点”最后凌乱不堪的事情屡见不鲜，我们首先要尝试避免这种情况。
在获取需求的阶段，要学会固化需求、透明需求。举个例子：小猿曾经遇到过一个身份比较特殊的产品经理，在做需求评审的时候，明确说了某个功能一定要添加一个信息脱敏展示的环节，当然小猿也在本子上很认真的记录了下来，并按要求做了前端开发。第二轮测试环节时，客户做了一次初步验收，很不幸，甲方领导特别不能接受那个信息被脱敏而不是整段展示，认为擅自篡改了他们的本意，于是很生气。前面说了，产品经理的身份特殊(此处作为小说内容暂不可见，备好银子可以期待),但是总要有人对’甲方爸爸’的不高兴负责，作为新人的小猿就被推了上去，领导对团队和外部宣称：因为小猿的理解错误，导致了甲方的不满。好惨不惨的是，这时候的小猿并不清楚这些内部关系，所以看了自己记录的需求确认自己没有做错后，不留余力的据理力争，试图证明自己没有误解需求，也没有做错。甚至拿出自己评审时候的本子给他们看，但是没有人看，甚至当时私下里还跟小猿说脱敏需求他们也记得很清楚的后端们在会议上也都不肯出声了，那时候的小猿才知道自己被“祭天”了，甚至气的大哭一场。
可是以后的工作还是要做，需求评审还是要参加，除非小猿不在这个圈子里玩了，否则不可避免的围绕需求展开工作，或许大家都会遇到过这样的事情，BA/PM通过邮件或其它形式发给大家的需求文档上写的模棱两可，而你自己又不能说明你记录的需求确实是在需求评审会议上获取到的需求，所以只能认栽生闷气。可是我们确实固化了需求的，为什么还是没用呢？我们固化需求当然没错，但还需将固化的需求透明化，才不会被卷入纠纷。后来，小猿就养成了评审完成，立刻在会议上做好重要人员的需求确认工作，也就是通知大家自己获得的需求是什么，让自己获取的需求得到需求发布方的无误确认，还有个好处就是后期测试人员也不能质疑是小猿获取的需求有误才导致的逻辑冲突类型bug，测试只能直接去找需求发布方(BA)寻求解决方案,省了很多麻烦事。
所以学会在评审过程中，逐条固化需求，并将自己的疑问也一一记录，如果可以,当即提问搞清需求并做好正确记录，在BA讲解完全部需求后，将自己整理出来的需求笔记按主次轻重做好排列，发到项目小组的群里，公布给所有与会人员，尤其提到BA和PM，请各位确认自己本次会议获取的需求有没有遗漏或偏差，如果有立刻就要追问并做好矫正工作，不仅有利于后续的开发，也有利于后续的需求变更被甩锅时的自我防护。
这样的方式，既不会和BA有尖锐的对立感，也不会影响团队氛围，悄无声息的证明自己没有误解需求,甚至分享出来的需求记录大家后续都可以做参考，还会被认为是个细心负责的好小猿。从那以后小猿再也没有被“祭天”过了。
因此，学会固化需求、透明需求是远离纷争大锅的好办法，即便没有责任问题，也有利于自己后续的版本更新参考和梳理，甚至对后续的维护者也有很好的快速了解和高效交接的帮助作用。
二.与“需求变更”握手言和
我们都知道，固化需求的前提是每个需求都能够清晰明了，但作为猿是躲不开需求模糊的。这个时候，哪怕BA都要烦死你了，也要拿出“放学别走”的气势死缠烂打的追问。遇到不清晰的需求就要有’不给结论绝不分手的坚定意志’，不要去猜着做开发，“厚脸皮”精神会为自己铺下更平坦的开发之路。BA也不要想着让猿带着“差不多”的逻辑去工作，产品原型上的每一个细节都值得深挖，并逐清晰化，否则留下的坑都是自己的坑，耽误的工期，都是BA/PM后面交付时要踩的雷。
猿和BA之间就像是一场交易。猿肯定是乙方，作为乙方，不明确的需求请不要接到自己手里，明确后再接手开工也不迟。甲方是需求持有者，乙方是需求接收者，测试是第三方需求验收机构。第三方验收完成做过了一系列交接工作，项目结束以后甲方再说有问题那么乙方自然是’合理合法’的不需要承担责任。在真正的交易中，验收交接完再要修改或者重做都是要重新计算银子的。理清这些关系，作为猿，我们只需要全方位提升个人能力，和BA之间就不会剪不断理还乱，自然也用不到抱怨和郁闷。
当然，人脑是有局限性的，BA/PM在做产品设计的时候也会有预想不到的地方遗漏在需求文档和产品原型之外，所以需求变更必不可少。这种变更是很明确的设计欠缺导致的变更， BA们也是会意识到自身问题的。而很多人抱怨白干了的需求变更实际上大多数是由于开发初期没有清晰的理解需求导致猿们跟着那些模糊的逻辑进行了编码才会导致 ”白干了,干错了”的现象存在，这完全是可以通过’拿捏需求’来避免的。
拿捏需求的办法有很多，最重要的就是理清业务间的关系。比如说：我们大多数程序猿写写代码会莫名其妙的停下来开始自言自语嘀嘀咕咕，不明白的人会觉得像个神经病，自己跟自己讲话。但实际上我们这种行为就是在针对眼下的需求逻辑进行自我梳理，我们潜意识里就是试图通过对外界的静物(比如对着电脑)不断描述自己的问题，来使自己回想出现这个问题时，都做了哪些步骤哪些事情，你会发现在那嘚吧嘚吧突然就会停下来，因为你好像找到了一点突破口，然后再回到代码里或者业务点，慢慢把这个突破口扒开，干掉，问题就解决了，需求里的业务逻辑也瞬间了然于心。
所以，拿捏需求很简单，可以通过自言自语的方式理清思路，也可以是其它的办法，比如在关键时刻请别人帮忙分析一下难点，尝试解决问题的这个过程中总会有一个点，让你醍醐灌顶恍然大悟，有了清晰的业务逻辑，再进行开发，工作简直是一帆风顺。
但如果因为设计缺失而导致了变更，那不是猿们白干了，因为我们已经完整的实现了已有的需求设计。如果非要说白干了，那也是BA白干了，因为是他们设计并提供的产品原型。所以，猿们要放平心态，拥抱变更，工作里的烦心事都会消失。
三.相亲相爱猿与猿
没有了对“需求变更”的怨气，猿的工作开展就会舒服很多。可有猿的地方就有江湖，猿和猿之间也是有暗自较量的，团队管理者处理不好猿之间的关系，也会导致项目推进状况一团糟。比如猿们工作量的衡量，大概很多人都听过有些领导以每天或每周提交了多少行代码作为猿的KPI考核标准，但是非要用代码行数多少来衡量的话，那一个简单的给margin的设置都可以略过margin:上右下左的简写方式,像下面这样操作代码: margin-top/margin-right/margin-bottom/margin-left，一下子就干出四行KPI来，但技术猿们都懂这是最笨的写法，只是符合管理的KPI要求而已。而好的程序猿追求的都是精简高效的代码，实现同等效果，代码量越少越清晰的猿才是秀儿里的王者。举个最容易理解的栗子：
小菜一次搬一块砖，跑了一百次实现了老板要求的搬砖总量，而大咖自带技能主动组装了一辆车一次就可以搭载一百块砖，只跑了一次就完成了老板的搬砖目标。这能说小菜跑的次数比大咖跑的次数多出很多，所以小菜就是比大咖牛吗？显然不能，这是能力问题，不是次数问题。同理，程序猿的工作量是需要通过实现效果、代码精简程度、用时长短等多维度来考核的，不应该用代码行数多少来衡量猿们的强弱，否则程序质量、代码精简度和高效工作就都不复存在了。
猿的视角看管理，会看出KPI弊端，也能看出人员流动问题、新老员工协作问题。
在人员流动问题上，Leader应当尽可能使核心团队保持稳定；我们之前提到的输出清晰的开发文档和需求文档，是有利于人员流动时更明确高效的迅速完成工作交接，使项目不会在一次次的交接中散架子。但人员流动我们不可避免，重要的是一定不要让新人闷头干，这很容易在猿们都不知情的状况下埋上一箩筐的雷，而且大小不一，挖雷过程过分棘手。所以新人到一个项目里两眼一抹黑，他们需要引路人，最好分配老成员带动新人，让他们知道项目是做什么的，什么角色要做什么，新人要做什么，项目的人员结构如何，遇到什么类型问题应该咨询哪个角色的人都应该让新人被普及到，才能保障新人遇到难题时更高效的解决问题，不至于在问题的环绕下头晕脑胀不知所措，只有让他们进入新项目的工作模式后才能迅速上手发挥新人的光和热。
我以前很不懂为什么很多工作年限多的前辈反而用起新时代产物时畏手畏脚的，甚至表现出抗拒情绪来，后来才知道就是因为他们明白一旦新技术没有调研好，摸着石头过河会有很大的风险导致在项目交付时的一地鸡毛;而那些没经验的新人才会初生牛犊不怕虎的干劲十足极度生猛，项目开工时，就春天里的万物复苏蓄势待发一样，啥技术新就把啥技术往上怼，但是往往到最后都成了霜打的茄子，暴露出很多难以解决的技术新型问题，导致项目进度失控。
所以，在技术经验方面，请尽可能的不要简单粗暴的认为“都是增删改查这种重复的工作，新老猿们差不多都行”，这种想法并不明智。增删改查并不是重复的工作，不同的需求总是会带着不同的业务逻辑，需要的增删改查所附带的程序逻辑自然也大有不同，想随时随地随甲方的把增删改查玩弄于股掌之间绝非易事。增删改查融于业务逻辑和算法中，请不要抛开逻辑和算法让增删改查单飞，飞不高的啦。至少，没有一定的量变、没有强大的逻辑梳理能力和算法输出能力，做不到让需求里的增删改查信手拈来。当然，非要拿最长的工期配最简单的a加b减c乘d来说事，那也是没的谈了。
四.猿江湖的大总管
Leader就像是项目里的大总管，在任务分配和进度管控方面，自然是任务拆分的越细腻越好。我曾在某项目中参与过任务拆解环节，主要是前端任务的拆分，并做排期计划。我会在这个过程中发现很多对需求的新理解和业务逻辑的补充。所以，任务的拆分也是一个对需求深入探索，对技术设计初步预判的过程，技术团队管理者尤其需要这样一个环节，唯一的弊端就是Leader要把大量的时间花在任务需求拆分上，但我觉得leader本身就是为了做好任务分配、量化工作进度的，这不算是额外工作。比如说，单拿一个项目问你一共用多少人天，这样的工期很难讲，但分成多少个模块每个模块多少菜单每个菜单多少页面一个页面多少功能，这样一个功能一共用多少人多久完成很容易更精确的计算出来，再反推一个页面要多少人天完成，一个菜单要多少人天完成，以此类推，估算的整个项目的开发工期一定是相较于笼统估算出来的时间而言，更精确的。
其次，任务拆分的细腻，猿们工作起来也更清晰明了的知道自己每天每小时做什么，即将做什么，做过了什么，极大程度的减免了茫然松懈的状态和消极怠工的情绪。没有人偷懒，也就解决了KPI指标量化的问题，毕竟谁在多少时间内完成了多少任务一目了然，这些猿的工作能力在Leader的眼中也很清晰的呈现了出来。
简而言之，每个人的工作任务都细分到天甚至每小时的程度上，项目井然有序的按流程进行，让大家都预判自己下一步和下下步甚至下下下步要做什么，便于猿们平衡好工作与个人生活，每个人都有条不紊，才有利于团队氛围更融洽。所以要做好项目流程规划和团队管理，这些细腻的任务分解工作很重要。
最后，要注重团队的公平维护，尤其是技术团队。不要让忙的忙闲的闲，Leader们也无心关注调整，那样会给技术骨干造成心理失衡。要知道，会认真干活的猿一定是技术能力成长很快的那部分人才，等他们能力达到预期水平还没有得到提升或岗位状态薪资等等的同频变化时，技术骨干会因为心理失衡离开。长此以往，团队里沉淀下来的都是垃圾，都爱摸鱼都善摸鱼，那这个团队即便再吸纳进来那些会发光发热的新人也很难在这样的氛围里旋转起来。
好啦，这就是小猿的紧急避险迅速成长职场手记分享。愿每个萌新猿都能学会与需求共舞，愿每个年轻的BA/PM都能从“猿”视角出发，去考量项目团队的管理和维护，愿我们都能做一个更高级的“猿”与更好的Leader。
