一．背景
今天和研发主管宋和产品经理支沟通工作安排和进度的时候，了解到了几个问题，梳理了一下，这些问题回过头来看，其实这一直是我们团队一直有的问题，它严重阻碍了研发团队的效率和质量。
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倍。
针对二手代码没有测试用例的问题，彭一解释，只能补，也必须补。因为这些没有通过自动化测试的代码，不知道什么时候就是个坑，必须统一纳入体系中来。
网友评论