一.背景
今天和研发主管宋和产品经理支沟通工作安排和进度的时候,了解到了几个问题,梳理了一下,这些问题回过头来看,其实这一直是我们团队一直有的问题,它严重阻碍了研发团队的效率和质量。
1.研发主管告诉我,天天很忙,但不知道在忙什么,忙到椅子都坐不下来,每件事都是紧急的事,都是要马上办的事情,可是领导交代的事情,却没做。我说你现在的工作状态和我在台里的时候很像,你要有一个工作主线,例如用户画像,说了很久了。宋说心里天天记着这件事,但是天天又有新的紧急的事,没有时间。
2.产品经理告诉我,榜单工作做得也很累,文档也写了,评审会也开了,需求一条一条的过,研发当时明确了,也说理解了,可做出来还是错,做的过程中不清楚也不沟通。
一个BUG,上午催了研发不回,下午再催研发说“也不是不能改”,轻描淡写,让人无语。
前端做完了不自测,需求不理解也不沟通,一定等上线后,支亲自测,亲自指出问题,才来想办法改。一问又扯一堆技术细节,这是研发的通病!所以支一直陷在细节里面,非常疲惫。
我想:
虽然团队目前只有10几个人,而且很多人认为,我们还是个小作坊,有小作坊自己的运行模式。但是我认为,团队再小,但岗位工种已经初步完备,工作已经开始是流程化了:产品文档、后端开发、前端实现、测试验收。一个环节出了问题,直接影响下游的工作。但是,又由于每个人的责任心和认知是不一样的,正是因为流程化了,责任心和能力所产生问题就理所应当的向下传递了,这就导致越有责任心的越累,工作效率也非常低。
所以,在梳理出问题后,我思考了如下解决方案:
二.关于研发主管忙得不知道要做什么的问题
针对宋的问题,我的想法是,感觉上每件事都很紧急,其实是因为没有一个紧急工作的评定标准和一个有效工作排期机制,工作无法自己判断主次,又不及时上报沟通,导致自己不知道在忙什么,领导也不知道你在做什么,要求做的却没做。所以应该从制度上解决这个问题。
工作分为规划性工作和临时性工作:
规划性工作是有明确的时间节点,有一定的执行时间跨度,具体执行人在明确的时间节点内,合理的安排自己的工作计划。
临时性工作是突发的,需要这这些种类型的工作做一个紧急性评判预设:
1.影响日活和收入(成本)的工作,例如CDN防盗链被严重突破、客户端闪退,列为紧急工作,需要立即上报并处理
2.政治性问题,涉及到内容安全,诱发政治问题的需求或bug,需要立即上报并处理
3.其他工作,应该主动和上级或产品沟通,获取明确的安排。
上报和沟通不是追责,而是化解责任,不应该有心理负担。
研发与产品、上级沟通很重要。正是因为没有沟通,有些事站在更高层面来看,并不是特别紧急的,急着处理了。有些事看来不在眼前,但是从团队层面上来说,却是应该花精力立即去攻关去尽快解决的,变得遥遥无期。
所以,在设定并全员了解紧急工作的评定标准后,还应该建立一个快速流动运转的需求池,有些产品经理可以决定排序,产品经理决定不了的,让主管来决定排序,这样工作才能有序,大家的目标才能对其。但这个工作池需要高效,否则扭转的效率就低了。
一句话,工作需要密集的沟通,沟通的目的不是汇报,是给预期和了解预期。
另一句话,所有的需求,都应该是由产品来对接,研发永远不能和运营直接沟通。因为产品的责任就包括需求的整理和优先级的设置。研发则应该是在和产品沟通商定后,坚决执行指定好的工作目标。
三.针对产品经理“陷入研发执行细节”的痛苦
首先我坚定一个信念,这个问题在其他研发团队里肯定是普遍存在的,但一定是得到了解决的。
在和彭一的沟通后,我整理出如下方案:
1.产品在输出文档时,不仅仅是解释需求,是要拆解需求形成功能点,最重要的是每个功能点要有“验收条件”。
例如产品设计一个计算器,用户输入1+1,结果必须等于2。“等于2”就是验收条件。
验收条件是对于研发来说是目标,也是紧箍咒。
[if !supportLists]2.[endif]研发根据产品文档各个功能点的“验收条件”,编写实现代码的同时,必须同时编写“测试用例”代码,用于代码自测。
从制度上,如果研发不编写测试用例或谎报测试用例,则应该被严重的警告、扣分,甚至被优化掉。
在**公司,80%的测试用例代码是由研发提交的,测试团队只是站在更高的维度考虑全局产品的稳定性和质量,来编写测试用例。
3.有限次数的轮测机制
为研发设置提测限制,研发自测完成后提测,最多不超过2轮,第3轮提测应该就是完善的代码。再出问题就需要被处理,被考虑是否是能力或态度的问题了。
四.用工具来实现想法、规范流程
为了实现上面的想法,我们必须逐步引入流程性生产工具,当所有工具都开始使用,并发挥价值后,我们就实现了devops。
devops不是开发工具集,是人+流程+工具的一种研发理念。
我越发的感受到,研发能力是在优秀的流程引入并落实的结果,并不是要等研发能力的提示再来引入新的研发流程。
所以,我给自己设定了一个目标,用1-2个月的时间,在今年3月底前,先把研发单元测试、自动化测试制度和所需的Jenkins工具,落地落实。
几个补充:
1.工作任务的拆解,是研发工作中非常重要的一环。一个功能点,必须是限定在2天以内,如果超过2天,那么功能点拆解有问题,需要进一步拆解。
首先工作任务的拆解是产品和研发共同的工作。拆解在评审会上,商讨完成并进入管理平台。
将需求详情的拆解为功能点,并限定功能点为2天,最重要作用是产品迭代“小步快跑”的基础。
在**公司,2周研发执行开发,2周测试和产品验收,几乎都能按计划进行迭代,原因就是工作量的精准量化。产品会知道什么功能需要多久,应该分几个版本。而不是一个需求,一做一个月,然后测试半个月,我们设置的每个月16号迭代,很少有准时的情况,原因就出在这。
2.研发写测试用例
开始研发写测试用例,时间是慢的。一般来说,一般要用1个月的工期,第一次引入测试用例编写,会花到1.5个月。但随着版本迭代,编写测试用例的研发团队迭代效率,会是不编写测试用例的2-3倍。
针对二手代码没有测试用例的问题,彭一解释,只能补,也必须补。因为这些没有通过自动化测试的代码,不知道什么时候就是个坑,必须统一纳入体系中来。