对产品经理而言，「功夫」是真的越快越好吗？

笔者注：本文是因近期迷茫、焦虑，而根据进现阶段+以往工作进行的整理与思考，不针对任何公司和个人，只是想通过事例来表达自己的想法。因为经验和认知有限，难免会有主观、片面的情况，若有不同见解欢迎在下方留言，不胜感激。

你是否有这样的经历：没有时间思考多种方案、用户的需求也来得及仔细打磨就出了需求文档，随后技术GG们就哼哧哼哧开发了，在开发过程中或等到上线后，就出现了一大堆问题……

如果有，那恭喜哇！你可以继续往下看了，说不定我们会有很多共同话题。

————分割线————

当你向团队反馈时间安排比较紧时，你的leader可能会告诉你：

我们这是敏捷开发，追求的就是快，快速产出、快速落地、快速迭代，这样才能占领市场！

确实，很多事实也在反映，只有在竞争激烈的资本市场中快速的落地（上线），才能够抢占市场，这也恰恰应证了那句“天下武功唯快不破”。

可是，功夫是真的越快越好吗？

一、标准规范的工作流程

敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。

在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。

这是百度百科对敏捷开发的解释，从上述的文字中也能找到几个关键词“用户”、“迭代”、“切分”。

笔者认为这段说明文字比较中肯：因为“用户”，我们可以给产品进行“定位”；因为“迭代”，我们可以根据产品周期制定“战略”；因为“切分”，我们可以实施“有效的项目管理”。

而且大多数情况是这样的：很多产品经理说不清产品的定位，只知道产品的功能；不参与战略的制定和讨论，只按领导文件办事；被所谓的“有效控制时间”的项目管理笼罩着，却没有从项目管理的有效复中整到正反馈。所以，你经历的可能不是真正的敏捷开发。

二、以用户为中心

跟各位说一下自身的经历：在成为产品经理后，笔者很少像上学时那样自诩“我们的产品是以用户为中心”——因为自家产品（某些功能）是结合竞品分析后设(chao)计(xi)的，而这种现象在笔者后来的实习、正式的工作中是屡见不鲜的。

竞品分析是产品经理一项重要的工作，可是在现实中大家只为呈现出更好的竞品分析报告，而忽视竞品分析最初的意义——“研究为什么设计这个功能”、“研究如何与用户行为/场景进行对应”……

转而替代的是——“这个功能是怎么不错的”、“我们也要这样设计”……

所以，很多的产品成了市场上个别产品的复制品，仅仅通过不同的运营方式来吸引用户；也因为不具备差异化的功能，最终湮没在这个市场的洪流中，处在半死不活的状态。

一个公司研究自身的用户，创建自己的用户画像，并结合用户使用场景设计产品的功能就显得至关重要了。

这里要说说之前设计考勤类产品的一个故事：

那时候我们的研究的主要对象就是钉钉，钉钉在班次功能里有一个“晚走晚来”（前一天晚下班，第二天可以推迟上班）的功能，当时我们也准备在自家产品的增加这个功能。

后来我们团队几个人就先抛开钉钉的这个功能，一起讨论自家产品的用户（自己公司的同事）是怎样的？他们的上下班考勤具体是如何的？可以得出什么样的需求？

经过对考勤、申诉数据的分析以及电话访谈，我们得出了产品的用户类型分为3大类：技术、市场、其他。

• 技术类经常会加班但是第二天还是要准时下班；
• 市场类偶尔加班但第一天晚走第二天可以晚来；
• 其他的基本就是准时上下班的用户。

通过以上分析，我们就认定了该功能应该去做，可是要不要做成和钉钉一样的呢？比如时间跨度、默认值等，经过电话沟通和申诉数据对比，我们确定了一些市场部门的同事下班晚走一小时，第二天可以晚来半小时。

于是，我们就将班次默认时间设置成“晚走1小时，晚到0.5小时”。

如果当初为了追赶时间，就草草添加一个功能，那是不是就没有现在这个更适合我们用户的产品功能了？

三、有效的项目管理

之前有过一段工作经历，项目没有具体的deadline，全凭技术同事的心情或者高管意念去主导。

人都有趋易避难的心理，因为在没有外界压力下，不少开发GG会选择先开发容易的，后开发复杂的，这就造成了很多项目严重超期，那些不重要不紧急的项目反而会提前上线。

缺乏项目管理是不好的，但是无效的项目管理可能会更可怕。套用《不仅仅是喜欢》的一句歌词来描述“项目管理”，那就是：

你知道我对你不仅仅是时间，项目结束后你要记得复盘……

最近笔者就遇到一个苦恼的问题：当一个项目即将结束后，项目经理会持续不断的增加新项目；且项目安排的时间很挤，每个项目的参与人员可能是重复的。

表面上看，项目经理安排的很好——每个人都“高效”的负责着很多子任务，时间也被高效的利用。

当笔者和需要配合的同事都成为多个项目子任务的责任人时，就感受到了其中的问题：

通常在工作中，很多突发情况都会发生。

一次需求评审需恰好遇到开发GG进行其他项目的bug修复，所以评审延期了，接着出PRD的时间延期了，然后需求开发的时间也延期了，最后笔者关联的其他任务时间也随之延后了……

项目制定的时间也不得不因为各任务的延长而重新规划，并线工作的进程并没有很好的将项目快速完成，算起来和各任务逐个进行基本上差不多。

持续不断的项目也容易产生疲劳，想一想如果你完成一个任务后又会有一个新的任务交给你，那种感觉是不是很丧？

有效的放低效率反而成为了减压的方式，所以一些人也会选择慢做工、加时长的方式。

而管理层看到夜晚一派灯火通明的景象，反而内心会一阵窃喜。

而笔者之前工作的一家公司就将项目管理做到了一种近乎完美的状态，不仅保持着业内领先的技术能力，且整体工作的效率也非常高，这是因为他们采取了“周期性项目管理方式”。

他们会以1个月为一个开发周期，在项目启动时会将所有的责任人召集在一块进行评估（接下来做或不做这个需求）、定期（这个需求需要哪些资源、材料、人力）等。

当确定好时间后，大家就会快速完成自己的工作，以便在截止时间前完成，这样就给自己争取了一些学习、复盘的时间。

同样，在另一个公司通过“测试把控”的方式，也慢慢降低了项目的过分的紧急。

中级bug不修复不上线，并会要求开发重新修复后再提交测试。

在测试的阶段也为开发、产品等同事留下了一定的时间。

对于企业和个人都获得了自己想要的收益——产品的快速稳定的落地，自己也有了可以掌控的时间。

四、时间与个人发展

时间是个人发展的载体，拥有合理的时间配比，才能够在未来进行可持续发展。

例如，笔者之前就因为被强制快速完成设计&不分节假日的工作模式而产生了焦躁的情绪，你也许会告诉我：“年轻人多吃点苦，无所谓”，但笔者很想说：“其实我的基本权益已经被侵犯了”。

当然这属于极端的例子，但作为一名产品经理，仔细打磨产品应作为自己的底线。

留下一定的时间思考产品，为用户提供易用、爱用的产品是每个产品经理为之奋斗的目标。

给自己留下思考的时间，研究用户使用产品的场景，分析需求的实现方式……

每一步都不能以“形式主义文档”的方式去进行，而是真正的将分析的结果为团队、自己未来的设计和规划所利用。

给自己留下生活的时间，个人觉得产品是有灵性的工作，整天埋在自己的一亩三分地里是设计不出好产品的。

感知每一个产品的设计，感悟生活中的点滴，这样才能设计出同样有情怀、有灵性的产品。

五、结语

前段时间潜伏在“脉脉”的匿名区看到了很多人对工作的抱怨，可能这并不是一朝一夕才产生这样的结果。

当看到一位程序员GG患有急性焦虑症后，笔者认为我们应该正视某些问题了。

单纯的只找自己的原因其实也是不负责任的，相信我们每个人在都是对生活抱有热情的。

停下来留点时间复盘自己的工作，慢下来给自己多一些的思考，也许这样才能为用户提供更好的产品，同时为企业带来更多的收益。

作者：兮兮

来源：人人都是产品经理