产品经理不停的改设计,作为前端该怎样处理( 四 )



产品经理不停的改设计,作为前端该怎样处理

反例1:一个项目干系人提出了一个重要的需求,这个需求需要完全地改变本阶段的工作目标,团队在没有向投资人请示的情况下接受了这个变更,导致最后无法满足投资人对本阶段团队工作的期待。

反例2:变更请求未通过团队各方代表评估,直接提给开发去开发,最后交付运营才发现性能无法满足要求。如果在评估的时候就请包括运营代表在内的各方代表评估,就可以在开始开发之前有更周全的考虑。
5产品经理可以提建议,但是由研发团队代表(开发代表和测试代表)负责最终决定是否接受该变更(进入本次迭代)

理论支持:《Scrum指南》,团队是迭代待办列表的Owner。

产品经理不停的改设计,作为前端该怎样处理

反例:产品经理说要改,团队就要无条件接受,产品经理说要加需求,团队就要无条件加班完成。导致范围蔓延,交付延期。
6如果研发团队接受变更请求,研发团队可以选择同时请产品经理从当前迭代待办列表中移除同样工作量大小的待办项,产品经理需要按照研发团队的要求进行移除,移除哪些待办项由产品经理决定。
理论支持:《Scrum指南》,团队是迭代待办列表的Owner。

反例:研发团队接受了很多变更,没有提出移除的请求,造成团队常态性加班,带来产品质量风险和团队士气低落。
6最后,免费送给大家一个需求变更管理的流程图

需求变更管理流程图
关注“轻松做软件”公众号,回复“变更”就可以领取啦。

7行动起来,和变更问题做了断!

团队成败,匹夫有责。如果你认同本文的变更管理理念和方法,也希望优化你的团队现有的变更管理流程,你可以做下面的行动:

行动指南
1. 下载第6步的变更管理流程图;
2. 将本文发到你的团队群里,请大家阅读;
3. 组织一个正式的会议,邀请大家对这个主题进行讨论,可以展示下载的变更管理流程图请大家参考;
4. 形成你们团队自己的变更管理方案。


祝你成功!


■网友
就是要不停该设计,就是要不停需求变更,好产品是改出来的不是做出来的,别相信什么"我只做了一遍,大家惊为天人于是就用了于是就成功了"这概率跟中彩票差不多.假如你是一个产品经理,现在让你指导开一个包子铺,我给你一个包子,不让你吃,你如何能知道这包子好不好吃?你是不是要吃了才知道好吃或者不好吃?你是不是吃了这个包子才能知道下回做饭如何改进?好那么问题来了,你都没做出来,我怎么知道哪里不爽? 必须是画出来了才能知道哪里不爽,不爽就要改,这不是明摆着的问题吗?还有,你是不是这家公司的员工? 如果是外包活儿算我没说,如果你是员工,公司发你工资是为了让你付出时间工作的,不是让你只做一版. 对你来说改或者不改应该完全没有区别,因为你的工资是按时间计算的不是按活儿计算的,你想的无非就是懒得改,因为做完了如果不用改了你就可以干坐着拿工资了.当然或许你觉得你的工资不够高以至于必须通过一定时间的干坐着来拟补,那是工资问题不是产品问题...改或不改,产品经理和前端之间的争吵只应该发生在审美上,那么你扪心自问你之所以不想改的原因是因为你觉得你做的很完美一个像素都不能动吗?暗黑破坏神一代本来是回合制的,在马上要发售的时候一个程序员觉得回合制不爽,用一个下午改成了实时式,团队一感觉都觉得好,马上推翻重做.编程,美术,动画,玩法,关卡设计全都要改,但是这世上只有这样的产品才能成功."拥抱变化"这句话不是随便说的.当然,还有一种可能就是产品经理是个白痴,如果是这样,建议马上离职.


推荐阅读