回复「变更」送你6个搞定需求变更狠招
无论是真实世界,还是网络段子,产品经理和开发之间的战争似乎从来没有消停过。有的战争发生在三维世界里,造成了人身伤害,有的战争发生在心里,造成了隔阂。
传统的说法是:这是属于沟通的问题,沟通是一门艺术,建议团队都去培训“沟通的艺术”。但我认为:艺术并不总靠得住,今天我们来讨论用科学来解决这个问题。
产品和开发打架的问题,本质是因为双方没有统一决策机制——也就是在什么情况下听谁的。下面推荐给你一套炒鸡简单的决策机制,帮你永远的解决这个问题。(理论支持:Scrum)
一个研发团队只听一个产品负责人的。研发团队只从这一个产品负责人这里接受任务。
如果有一个产品团队,需要由这个产品团队自行选择一个人作为产品负责人。
如果有多个需求方,同样由这些需求方自己选择一个人作为产品负责人。
产品负责人不仅仅负责提需求,还需要设计好用来满足需求的软件。
决定哪些需求先做,哪些需求后做是产品负责人的权力。同时需要请研发团队review这个实现顺序的可行性。
决定如何实现需求(How)是研发团队的权力。
研发团队有权力只对自己产能范围内的需求做承诺。研发团队决定在一个时间前交付多少的需求。
如果研发团队觉得产品负责人的建议不可行,产品负责人需要和研发团队进行协商,通过砍需求,简化需求,或者加人等方法解决问题。
一共5条,是不是很简单?大家可以把这5条作为“团队协议"1.0版用起来哟!(团队协议也就是大家共同遵守的约法三章,用来促进合作。)
小结:
一个研发团队只从一个产品负责人接受任务。
产品负责人不仅仅负责提需求,还需要设计好用来满足需求的软件。
决定哪些需求先做,哪些需求后做是产品负责人的权力。同时需要请研发团队review这个实现顺序的可行性。
决定如何实现需求(How)是研发团队的权力。
研发团队有权力只对自己产能范围内的需求做承诺。
行动计划:
回复“决策”获得打印版的《团队协议1.0》。打印出来贴在大家每天都能看到的显眼的位置(比如看板上)。从此妈妈再也不用担心我上班打架啦!
欢迎你在文章下方留言,说说你见过的打架故事:p
漫画创意&绘画:轻松做软件
风格参考笛子Ocarina作品
END
点 击 图 片 阅 读
跳槽季:跳和不跳之外的第三选择
为什么末位淘汰不适合用在软件研发团队?
“轻松做软件”是IT人的效率公众号
科学工作,少走弯路,快来关注吧!
![640?wx_fmt=png](https://i-blog.csdnimg.cn/blog_migrate/95b7ee7fe2d0011b2f071918769eec0d.png)