为什么你的项目推不动（一）
不知道你有没有遇到这样的问题，你交给同事小a一件事，要么进度很慢，要么是收到的结果差强人意，无论你和小a是上下级关系还是合作关系，都会发生这样的问题。
工作中80%的人都和小a差不多，那么这个时候除了换掉80%的小a，有没有什么办法保证事情顺利进行呢？按照涉及多人的互联网软件项目，牛奶总结了三个步骤，如果是两人合作，参考前两个步骤即可。
01 确认目标
确认目标这件事儿几乎是所有事情的第一步，明确的目标能够保证相关人员在方向上是一致的一方面确认目标后，可以具有更灵活的解决方案，不会专注在单一的执行方案上，而是共同的结果。比如你们想要的是提升用户活跃，那么提升的方法有很多，大家不会专注于争辩是否是当前的方案，对新的解决方案的接纳程度也会更高。
另一方面，当合作双方是不同的利益体时，达成统一的目标有助于提高大家共同的工作积极性。毕竟解决自己想要解决的问题比帮别人做自己不想做的事情，心态上积极很多。
02 确认可执行标准
为什么确认可执行标准很重要？
对于相对复杂的事情，我们经常会用经验来判断一个人是否能做一个事情。而执行标准是经验的提炼结果。因而确认可执行标准是保证结果相对可控的必要方法。
什么算是可执行的标准呢？
拿一个相对简单的工作举例：b端业务调研。
如果我们对调研的要求是：产品经理希望调研结果尽量还原业务场景，这句话显然很难保证结果符合预期。
但如果我们提出如下要求：
调研的具体内容包括以下几个问题：
- XX部门的工作流程是什么？
- 他们的组织结构是什么？
- 他们在工作遇到了什么问题？
- 为什么会产生这样的问题？
- 解决这个问题能够给你们带来怎样的好处？
上述的问题就是调研可执行的标准，通过这样方式的调研就能从实际的业务场景和开发该功能产生的价值了解业务。
调研报告请尽量还原用户的话术，并保留好调研录音。
如果没有提供这样的标准，调研人员可能会问：
我们是负责给你们优化流程的，请问您需要我们做什么？
得到的回复大概率是用户根据问题自己思考的解决方案。
这样的问题不利于根据业务分析本质的解决方案，最终只能照猫画虎的复刻别人的想法，成为了一个原型产品经理。但如果我们提供了调研的问题模板，负责调研的同事按照问题做好记录，结果大概率不会太差。
我们平时在工作用到的周报模板、交互走查表、原型文档模板都是可执行的标准。因而确认可执行的标准会大大保证我们的工作符合预期。
03 确认执行流程
有了前两步，可以解决两人合作时结果差强人意的问题。涉及到多人时，确认执行流程很有必要。
我们拿需求变更来举例。
- 场景1：业务同学a和产品经理反馈了需求变更a，过了一段时间，发现软件系统并没有变化。
- 场景2：业务同学a和产品经理反馈了需求变更a，产品经理落实了解决方案，不久后业务同学b和产品经理反馈了需求变更b，产品经理发现变更b和变更a有冲突啊，这该怎么办？
- 场景3：业务同学a和开发反馈了需求变更a，开发解决了问题。过了一段时间，产品经理问：“诶，咱们产品怎么变了？”
以上3个场景的发生，主要是因为没有明确的执行流程，对应场景的解决方案是制定需求变更的流程。
针对需求变更，我们可以制定如下流程：
- 业务方汇总需求变更，并确认变更
- 由统一的业务出口人负责和产品经理对接变更
- 产品经理根据变更绘制原型
- 产品经理将绘制的原型和业务方再次确认，是否满足需求
- 产品经理将具体变更原型进行记录
- ui落实变更设计图
- 技术落实需求变更的开发
看完流程，不知道你有没有发现，所有环节看似连着，但又好像断开了，为什么会出现这种情况呢？
因为我们希望业务做完事情告诉产品，产品做完事情告诉ui，ui做完事情告诉开发，开发最好还能告诉业务，也就是任何一个环节断了，这个事都有可能推不下去，就出现了场景1的问题。
那怎么解决这种情况呢，这时候我们就需要一个负责需求变更的人，可以起到整体进度的跟踪和流转的链接，毕竟工作之后，我们都清楚让一个人做完事情主动推进下一个环节并不现实。
有了统一的需求变更人，连接人时间节点和对应负责人分阶段跟进，项目推动就容易多啦~
#作者#
牛奶，可可爱爱单身产品狗一枚，工业互联网产品经理，微信号：1528120885，微信公众号：产品经理的小红书。分享对产品的思考和总结，一起快乐成长。
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
