|
|
# 26 | 为什么加班很久但是没成果？产品开发流程有问题
|
|
|
|
|
|
在刚入行做产品经理时，我工作过的一个团队每天都在加班，工程师叫苦不迭、设计师焦头烂额、产品经理也忙得像“热锅上的蚂蚁”，但就是做不出产品，最后的考评成绩也明显配不上整个团队三天两头加班的付出。
|
|
|
|
|
|
后来，我在几个高效率团队工作过以后，终于总结出了团队加班很久但是没有成果的几个共同特点，我也是在踩“坑”无数之后，掌握了团队执行的黄金宝典。
|
|
|
|
|
|
接下来，我就跟你分享一下低效团队三个常见的“大坑”。
|
|
|
|
|
|
## 第一个“坑”：需求变变变，但新需求并不是来自于用户反馈。
|
|
|
|
|
|
工程师最讨厌的就是产品经理改需求，但是产品经理会理直气壮地说，我的工作是要做对的产品，改需求的目的就是为了更好的产品体验。公说公有理，婆说婆有理，最终就剩吵架了，啥也没做成。
|
|
|
|
|
|
在这里，我并不是说产品经理不应该改需求。相反，我认为产品经理一定要根据用户反馈不断优化产品体验，这也正是迭代化产品开发的核心，即从最小化可行产品（MVP）开始，逐步优化产品体验，作出越来越完善的产品。
|
|
|
|
|
|
而我见过包括工作过的很多团队改需求的原因，往往是因为某个领导觉得不够好，其他组的某个人觉得有问题，或者产品经理改主意了。又或者，产品开发时，产品经理和工程师间缺乏交流，结果开发了一大半才发现已经脱离了原来的产品计划，所以工程师要按照原来的需求重新开发。
|
|
|
|
|
|
**但是，在理想情况下，只有有来自用户的最新反馈时，才会改变需求。**
|
|
|
|
|
|
比如，我们通过用户调查发现用户对现在的设计缺乏信任，或者认为现在产品的体验很差。这个时候修改需求或者产品决定，我认为是非常必要的。
|
|
|
|
|
|
而如果没有用户反馈，修改产品需求就会比较盲目。某个没有经过市场验证的假设，很有可能就会推后整个产品接受市场反馈的时间，而这并不一定值得。
|
|
|
|
|
|
这个时候，产品经理需要勇敢的站出来，告诉他：“我们可以先选定一部分用户进行产品测试，看看他们的反馈如何，然后再决定是否要修改需求，这样的效果会比推迟整个产品的发布时间更好”。因为一般情况下， 产品发布前都会有一个测试期，根据用户反馈做出下一步的产品决定。
|
|
|
|
|
|
当然，这种情况并不适用于所有产品。有些产品的前期投资会比较大，等到产品发布前再测试的风险会很高，所以需要在产品开发阶段就经过层层审批、不断调整产品需求，以确保产品一炮而红。
|
|
|
|
|
|
## 第二个坑： 做决定的人太多，做决定的速度太慢，工程师上班在等产品决定
|
|
|
|
|
|
在前面的文章中，我给你分享了一些产品决定的内容，今天我就跟你分享一下做决定的流程：**我认为，每个决定，都应该弄清楚到底需要什么人、几个人来做，以及为什么需要这些人。**
|
|
|
|
|
|
1. 产品方向策略的决定，我一般会和工程经理、设计主管一起制定方案，然后向上层领导汇报，达成一致。而对于基层的工程师，我会给他们提意见的机会，也会考虑根据他们的意见修改方案，但并不会等到他们同意之后再做决定。
|
|
|
|
|
|
2. 产品优先级的决定（先做什么功能），我一般会和工程经理、技术主管一起做，然后制定整个产品团队的开发时间表。对于每个工程师，我会和他一起商量他负责的几个项目中哪个更重要。
|
|
|
|
|
|
3. 产品功能实现方法的决定，我会和具体负责这个功能的同事一起做。如果这个决定有法律或者政策方面的问题，我会再拉上法律、政策部门的同事一起决定。敏感的功能我会向上层汇报， 涉及和其他团队合作的功能，我会和对方的产品经理沟通。
|
|
|
|
|
|
|
|
|
**明确每个决定需要什么人来做，如果这个人无法改变决定，那就可以不叫他来，这样可以减少做决定的时间，以最快的速度达成统一意见，提高开发效率。**
|
|
|
|
|
|
这里的难点是，产品经理很多时候根基不够硬，或者经验不够多，不敢告诉对方这个决定不需要他做，即使为了礼貌也要把他找来，严重拖慢了做决定的速度。
|
|
|
|
|
|
我的建议是，你可以和团队成员一起商量讨论制定一个做决定的流程，做什么样的决定需要什么人来做，提前把规矩定好，就可以避免这种尴尬情况了。
|
|
|
|
|
|
综上所述，把每个决定结果记录下来，及时和团队成员汇报，并给他提建议的机会，而不是让所有人都参与到做决定这个过程中，可以在兼顾团队成员的主人翁意识的同时，对团队的执行效率产品积极影响。
|
|
|
|
|
|
## 第三个坑： 产品开发计划没做好。
|
|
|
|
|
|
有些团队比较理想主义， 每一步都拖来拖去， 但是却认为到截止日期那一天产品就会像变魔术一样变出来。这是非常幼稚的想法，最后产品往往不能按预期发布。
|
|
|
|
|
|
**产品的开发计划一定要非常精准， 我的建议是至少以星期为单位，每周都要明确每一个工程师和设计师要达到什么样的结果。**
|
|
|
|
|
|
在刚刚决定做一个产品时，产品经理都会先写产品需求文档， 分别给工程师和设计师制定工程计划和设计计划，这个时候你可以把要达到的目的精确到每个星期。
|
|
|
|
|
|
**这里需要注意的是，在制定产品开发计划时，你需要和团队的工程师和设计师商量，看这样的计划是否可以顺利执行，有没有哪些不合理的地方，然后根据他们的意见适当调整。**
|
|
|
|
|
|
如果工程师觉得这一部分需要先拿到设计图才能做，你可以适当调整设计师的设计计划，以确保设计师和工程师之间的合作最优。 如果工程师认为， 设计师得在第三周时告诉他是用行表还是用纵栏，因为两者的数据结构不同，那你就要确保设计师的计划能符合这样的要求。
|
|
|
|
|
|
这些都是在产品开发之前就已经提前计划的， 而不是让设计师和工程师各做各的， 遇到问题以后才修改。好的产品计划可以减少加班，这句话一点都不假。因为产品开发计划精细准确，确保每一步都是最优的，可以大幅提高产品开发的效率。
|
|
|
|
|
|
我给你分享的产品开发流程中的三个“坑”，都是我自己亲身踩过的。把这些内容分享给你的目的，就是希望达到“我试错，你绕坑”的效果，提高你的产品开发流程。
|
|
|
|
|
|
最后，针对现在的“加班文化”，我想告诉你的是，不要让团队成员把加班时间长作为一种光荣，这是一种很危险的文化。这样的文化会助长庸人，让团队不再是结果导向。
|
|
|
|
|
|
比如，工程师开发做得一塌糊涂，但每天在办公室加班上演“苦肉计”，考评时直接说：“我工作这么辛苦，难道不应该给我好评吗？ ”
|
|
|
|
|
|
但我并不是说不能加班， 而是永远不要以加班时间作为衡量团队成员工作质量的标准，否则团队一定无法在规定时间内交付高质量的产品。
|
|
|
|
|
|
## 总结
|
|
|
|
|
|
加班很久但是没成果，是一件非常悲哀的事情，也是产品经理的失误。我给你介绍了三种提高工作效率的方式，来减少无谓的加班时间，确保产品有结果：
|
|
|
|
|
|
第一，要杜绝根据假设以及个人的意见改需求，用户反馈才是修改产品需求的依据。在确保产品的代码质量有保证的前提下，提前发布让更多的用户看到，远远好于因为某个人的临时起意而耽误产品接受市场反馈的时间。
|
|
|
|
|
|
第二，要把每个产品决定需要几个人、什么人参与弄清楚，确保不让不直接相关的人耽误做决定的时间，不要出现工程师干等产品决定而无法开始写代码的情况。
|
|
|
|
|
|
第三， 在产品开始开发前制定出精准的产品计划，工程师、设计师等各部门同事提前计划、提前预估风险、提前调整工作计划。
|
|
|
|
|
|
最后，我要和你说的是， 要倡导结果导向而不是以加班时间为导向的团队文化，这样才能让团队成员把精力花在做事情上， 而不花在“苦肉计”上。
|
|
|
|
|
|
## 思考题
|
|
|
|
|
|
请你思考一下，你团队的效率低下是踩了哪个“坑”？你打算如何解决？你是否还经历过因为其他原因造成的团队低效？
|
|
|
|
|
|
欢迎你给我留言。
|
|
|
|