即刻App年轻人的同好社区
下载
置顶这篇文章终于写完了……
没想到这玩意写了两个多月……
初衷呢，仅仅是我发现并没有哪个需求文档模板能满足我在实战中的需求，如果我把模板发给一个新同学，他大概率还是对怎么写文档一脸懵逼。
另一个层面，我的收藏夹里躺了很多对“大词”的分析。我们讨论社交和社区的区别，我们讨论web3，我们讨论社区团购，但可能我们一辈子的职业生涯都不会跟其中某些词有交集。需求文档呢，应该100%的产品经理都曾遇到相关的问题。
再参考各种文档模板、产品培训，我隐隐感觉这个话题是高手不屑写，新手写不明白的领域。那我正好试一试，看看会不会偷个鸡。
少楠提过“重新发明工具”，那我就重新学习写需求文档。
这篇文章相比怎么写，更多的篇幅放在了为什么这么写的角度。
我认为需求文档没有固定的格式，但是好的需求文档是有比较显然的共性。
知道“为什么要写这个”“为什么这样写”，应该就容易推导出“这个怎么写”。
原文开放了评论权限，恳请有缘人多多拍砖批注，我很关注下面几类反馈:
1.哪里说的不对
2.哪里可以更深入聊聊
3.哪里写的不清楚
4.哪里写的太啰嗦
文章写到一半的时候，突然想起来可以mvp一下，就分章节发到了小红书，结果有两段图文并茂的章节互动挺热闹的，其他部分都是反响平平。可见当前1.0版本写的也不咋地。
还需要继续迭代啊，希望收到一些批注和反馈。
哦对了，我的主要精力还是本职工作，次要精力是玩。这玩意后续一定不会有什么付费转化、私密社群、课程培训什么的。
没想到这玩意写了两个多月……
初衷呢，仅仅是我发现并没有哪个需求文档模板能满足我在实战中的需求，如果我把模板发给一个新同学，他大概率还是对怎么写文档一脸懵逼。
另一个层面，我的收藏夹里躺了很多对“大词”的分析。我们讨论社交和社区的区别，我们讨论web3，我们讨论社区团购，但可能我们一辈子的职业生涯都不会跟其中某些词有交集。需求文档呢，应该100%的产品经理都曾遇到相关的问题。
再参考各种文档模板、产品培训，我隐隐感觉这个话题是高手不屑写，新手写不明白的领域。那我正好试一试，看看会不会偷个鸡。
少楠提过“重新发明工具”，那我就重新学习写需求文档。
这篇文章相比怎么写，更多的篇幅放在了为什么这么写的角度。
我认为需求文档没有固定的格式，但是好的需求文档是有比较显然的共性。
知道“为什么要写这个”“为什么这样写”，应该就容易推导出“这个怎么写”。
原文开放了评论权限，恳请有缘人多多拍砖批注，我很关注下面几类反馈:
1.哪里说的不对
2.哪里可以更深入聊聊
3.哪里写的不清楚
4.哪里写的太啰嗦
文章写到一半的时候，突然想起来可以mvp一下，就分章节发到了小红书，结果有两段图文并茂的章节互动挺热闹的，其他部分都是反响平平。可见当前1.0版本写的也不咋地。
还需要继续迭代啊，希望收到一些批注和反馈。
哦对了，我的主要精力还是本职工作，次要精力是玩。这玩意后续一定不会有什么付费转化、私密社群、课程培训什么的。
产品需求文档写作指南
276 38118
纯外行视角，欢迎拍砖讨论
Manus做产品到底好在哪里
3 00
最近一周都在处理这件事，这个周末也没闲着，终于拽着线头越来越清楚了。
气是消了，不过也没必要删，说点事后的总结：“不同的时间点，对也是错了，错也是对了”。
怎么理解呢？
早期规划、创意阶段，大家互相补位、争先往前冲是对的。
现在整个团队有DDL的紧迫感，把问题清楚地暴露出来、向上传递也是对的。
这种时候边界清楚一点，倒也算不上是不担责，在项目整体视角下，可能反而是效率最高的一种方式。
对我自己呢，以后多个心眼，提升点感知水温的敏感度。
气是消了，不过也没必要删，说点事后的总结：“不同的时间点，对也是错了，错也是对了”。
怎么理解呢？
早期规划、创意阶段，大家互相补位、争先往前冲是对的。
现在整个团队有DDL的紧迫感，把问题清楚地暴露出来、向上传递也是对的。
这种时候边界清楚一点，倒也算不上是不担责，在项目整体视角下，可能反而是效率最高的一种方式。
对我自己呢，以后多个心眼，提升点感知水温的敏感度。
Kira2red: 我工作十来年了，终于还是被职场渣人恶心到了——终于遇到了“不做就不会错”、“大会捅刀子”的场景。 背景是，我们有个硬件需求，涉及A、B、C三个研发或工程团队。A、B跟我一个大部门，C不是。因为组织调整的问题，我们跟C的沟通很不顺畅，可以理解为无法沟通。 这个需求的主要承接方是A-C，B因为对这个模块比较熟，所以在C没介入的时候，充当顾问。A不具备开发能力，依赖供应商提供方案。 原来的需求方案中，A找的供应商X一直支支吾吾、没有明确表示能不能做。我们跟大老板每次汇报方案，老板对方案也不置可否，让我们再想想。 后来大老板给了个供应商Y的联系方式，Y的CEO信誓旦旦地说无法实现，并且把为什么无法实现的原因讲了。这个会上B和A团队的人都在。 会后差不多20天左右的时间，我们内部在打合需求，考虑变更需求，这个过程中A/B团队的人都参与了讨论，大家是明确知道如果原方案不可行的话，我是要变更需求的。我也把什么时候汇报需求变更的计划跟他们同步了。我知道这个需求变更会带来成本影响，比如供应商重新定点等等。所以前置是同步到两个团队的，但是没有正式汇报，所以我没有正式释放配置表，只是口头开会沟通。 好，终于约上大老板的时间，汇报需求变更，好巧不巧，这次汇报会上A/B的参会人都请假了。 3周后，下一次给大老板的汇报会，A团队的负责人出来说：“产品怎么擅自变动需求？怎么还没拉齐就变更了？” 我：“？？？”每次开会你下面的人都在啊，我每周通晒配置表的时候也会说这件事啊，A和B团队给我指派的接口人都是参与的啊，我按照之前约定的流程走了，你告诉我没拉齐？ 大老板也说：“你作为产品，不需要帮他们做可不可实现的决策，应该他们来做。” 我真的头疼，这个决策是我做的吗？首先所有的会议大家都参会了，在我们讨论原方案不可行的时候，没人说话；其次我要变更需求这件事，在上会前已经跟你们沟通过，你们也没人提这个变更有问题。最后到现在就是我自己改需求了。 我跟我老板聊了下，他给我的要求是，需求中只写我要的体验是什么，并且往高了写，不要考虑任何可实现的因素——比如有个方案的准确率很低，我不能说这个方案准确率低，而应该说我要求一个很高的准确率，由下游团队来讲这个方案准确率达不到。 怎么讲呢，我完全理解，也按这个要求执行了。我在这家公司之前都是互联网公司，这家也干了三年了，之前几乎所有的项目制工作都是我作为产品是唯一的接口人，汇报什么的都是以我为主，我已经习惯了产品冲在前面、汇总信息、进行决策的工作，并且我认为靠谱的产品就得做这件事。产品经理是对产品最终负责的那个人，是对产品有最终解释权的那个人，而不是只开脑洞的艺术家。但我也理解在这种组织中这件事的合理性，复杂的链条、复杂的内外部关系，有些人并非主观想这样做，就是能力达不到且不想把自己的无能暴露出来。 在过去的合作中，我跟横向的合作伙伴一直很愉快，除了A几乎所有的合作伙伴都是很负责、很主动。其他模块也发生过这种产品提出来需求，下游分析了半天发现做不到，下游的人找我说清楚，我改配置表，老板问起来大家一起回答下就ok了。我就当A团队自己内部没有充分沟通，而不是A的负责人故意想这么干的。因为A只懂他那块的一亩三分地，也都是问的各种供应商，C的事很难判断。A评估的能行，只是这个需求链条中他的部分能行。 职场中的自我保护技巧我也懂，但我跟这帮人共事三年，从来没想过要在这帮人身上施展这种技巧。好吧，以后跟A团队的任何沟通，字面留痕、会议有会议纪要。麻烦点，也请你们少点事。 最乌龙的是，现在A找的供应商X又信誓旦旦说原需求能做了。反正大老板找的供应商Y，人家CEO反复多次在各种场合否认了这个方案。你们聊吧，我只描述想要的用户体验。 我的亏吃在，如果按照广义的产品流程，我确实有做得不到位的地方。但我们组织本来就是有约定的流程，比如硬件类的需求，产品只需要维护配置表，不需要详细的需求文档，这都是下游团队要求我们这样做的（因为这样他们选供应商的灵活度更高）。包括需求的释放流程、评审流程，也是跟下游团队拉齐的。但就不像互联网公司需求评审、签字画押、项目管理这么规范。现在人家矢口否认，我也没办法拿什么证据。真的恶心死我了。 B也被恶心到了，因为这个需求的实现流程实际上跟他几乎没关系，但是作为这个组织中唯一懂这个的人，他被老板任命做整个技术方案的可行性评估，他要给不属于我们组织的C评估可行性。
0 00
我工作十来年了，终于还是被职场渣人恶心到了——终于遇到了“不做就不会错”、“大会捅刀子”的场景。
背景是，我们有个硬件需求，涉及A、B、C三个研发或工程团队。A、B跟我一个大部门，C不是。因为组织调整的问题，我们跟C的沟通很不顺畅，可以理解为无法沟通。
这个需求的主要承接方是A-C，B因为对这个模块比较熟，所以在C没介入的时候，充当顾问。A不具备开发能力，依赖供应商提供方案。 原来的需求方案中，A找的供应商X一直支支吾吾、没有明确表示能不能做。我们跟大老板每次汇报方案，老板对方案也不置可否，让我们再想想。
后来大老板给了个供应商Y的联系方式，Y的CEO信誓旦旦地说无法实现，并且把为什么无法实现的原因讲了。这个会上B和A团队的人都在。 会后差不多20天左右的时间，我们内部在打合需求，考虑变更需求，这个过程中A/B团队的人都参与了讨论，大家是明确知道如果原方案不可行的话，我是要变更需求的。我也把什么时候汇报需求变更的计划跟他们同步了。我知道这个需求变更会带来成本影响，比如供应商重新定点等等。所以前置是同步到两个团队的，但是没有正式汇报，所以我没有正式释放配置表，只是口头开会沟通。
好，终于约上大老板的时间，汇报需求变更，好巧不巧，这次汇报会上A/B的参会人都请假了。
3周后，下一次给大老板的汇报会，A团队的负责人出来说：“产品怎么擅自变动需求？怎么还没拉齐就变更了？”
我：“？？？”每次开会你下面的人都在啊，我每周通晒配置表的时候也会说这件事啊，A和B团队给我指派的接口人都是参与的啊，我按照之前约定的流程走了，你告诉我没拉齐？
大老板也说：“你作为产品，不需要帮他们做可不可实现的决策，应该他们来做。”
我真的头疼，这个决策是我做的吗？首先所有的会议大家都参会了，在我们讨论原方案不可行的时候，没人说话；其次我要变更需求这件事，在上会前已经跟你们沟通过，你们也没人提这个变更有问题。最后到现在就是我自己改需求了。
我跟我老板聊了下，他给我的要求是，需求中只写我要的体验是什么，并且往高了写，不要考虑任何可实现的因素——比如有个方案的准确率很低，我不能说这个方案准确率低，而应该说我要求一个很高的准确率，由下游团队来讲这个方案准确率达不到。
怎么讲呢，我完全理解，也按这个要求执行了。我在这家公司之前都是互联网公司，这家也干了三年了，之前几乎所有的项目制工作都是我作为产品是唯一的接口人，汇报什么的都是以我为主，我已经习惯了产品冲在前面、汇总信息、进行决策的工作，并且我认为靠谱的产品就得做这件事。产品经理是对产品最终负责的那个人，是对产品有最终解释权的那个人，而不是只开脑洞的艺术家。但我也理解在这种组织中这件事的合理性，复杂的链条、复杂的内外部关系，有些人并非主观想这样做，就是能力达不到且不想把自己的无能暴露出来。
在过去的合作中，我跟横向的合作伙伴一直很愉快，除了A几乎所有的合作伙伴都是很负责、很主动。其他模块也发生过这种产品提出来需求，下游分析了半天发现做不到，下游的人找我说清楚，我改配置表，老板问起来大家一起回答下就ok了。我就当A团队自己内部没有充分沟通，而不是A的负责人故意想这么干的。因为A只懂他那块的一亩三分地，也都是问的各种供应商，C的事很难判断。A评估的能行，只是这个需求链条中他的部分能行。
职场中的自我保护技巧我也懂，但我跟这帮人共事三年，从来没想过要在这帮人身上施展这种技巧。好吧，以后跟A团队的任何沟通，字面留痕、会议有会议纪要。麻烦点，也请你们少点事。
最乌龙的是，现在A找的供应商X又信誓旦旦说原需求能做了。反正大老板找的供应商Y，人家CEO反复多次在各种场合否认了这个方案。你们聊吧，我只描述想要的用户体验。
我的亏吃在，如果按照广义的产品流程，我确实有做得不到位的地方。但我们组织本来就是有约定的流程，比如硬件类的需求，产品只需要维护配置表，不需要详细的需求文档，这都是下游团队要求我们这样做的（因为这样他们选供应商的灵活度更高）。包括需求的释放流程、评审流程，也是跟下游团队拉齐的。但就不像互联网公司需求评审、签字画押、项目管理这么规范。现在人家矢口否认，我也没办法拿什么证据。真的恶心死我了。
B也被恶心到了，因为这个需求的实现流程实际上跟他几乎没关系，但是作为这个组织中唯一懂这个的人，他被老板任命做整个技术方案的可行性评估，他要给不属于我们组织的C评估可行性。
背景是，我们有个硬件需求，涉及A、B、C三个研发或工程团队。A、B跟我一个大部门，C不是。因为组织调整的问题，我们跟C的沟通很不顺畅，可以理解为无法沟通。
这个需求的主要承接方是A-C，B因为对这个模块比较熟，所以在C没介入的时候，充当顾问。A不具备开发能力，依赖供应商提供方案。 原来的需求方案中，A找的供应商X一直支支吾吾、没有明确表示能不能做。我们跟大老板每次汇报方案，老板对方案也不置可否，让我们再想想。
后来大老板给了个供应商Y的联系方式，Y的CEO信誓旦旦地说无法实现，并且把为什么无法实现的原因讲了。这个会上B和A团队的人都在。 会后差不多20天左右的时间，我们内部在打合需求，考虑变更需求，这个过程中A/B团队的人都参与了讨论，大家是明确知道如果原方案不可行的话，我是要变更需求的。我也把什么时候汇报需求变更的计划跟他们同步了。我知道这个需求变更会带来成本影响，比如供应商重新定点等等。所以前置是同步到两个团队的，但是没有正式汇报，所以我没有正式释放配置表，只是口头开会沟通。
好，终于约上大老板的时间，汇报需求变更，好巧不巧，这次汇报会上A/B的参会人都请假了。
3周后，下一次给大老板的汇报会，A团队的负责人出来说：“产品怎么擅自变动需求？怎么还没拉齐就变更了？”
我：“？？？”每次开会你下面的人都在啊，我每周通晒配置表的时候也会说这件事啊，A和B团队给我指派的接口人都是参与的啊，我按照之前约定的流程走了，你告诉我没拉齐？
大老板也说：“你作为产品，不需要帮他们做可不可实现的决策，应该他们来做。”
我真的头疼，这个决策是我做的吗？首先所有的会议大家都参会了，在我们讨论原方案不可行的时候，没人说话；其次我要变更需求这件事，在上会前已经跟你们沟通过，你们也没人提这个变更有问题。最后到现在就是我自己改需求了。
我跟我老板聊了下，他给我的要求是，需求中只写我要的体验是什么，并且往高了写，不要考虑任何可实现的因素——比如有个方案的准确率很低，我不能说这个方案准确率低，而应该说我要求一个很高的准确率，由下游团队来讲这个方案准确率达不到。
怎么讲呢，我完全理解，也按这个要求执行了。我在这家公司之前都是互联网公司，这家也干了三年了，之前几乎所有的项目制工作都是我作为产品是唯一的接口人，汇报什么的都是以我为主，我已经习惯了产品冲在前面、汇总信息、进行决策的工作，并且我认为靠谱的产品就得做这件事。产品经理是对产品最终负责的那个人，是对产品有最终解释权的那个人，而不是只开脑洞的艺术家。但我也理解在这种组织中这件事的合理性，复杂的链条、复杂的内外部关系，有些人并非主观想这样做，就是能力达不到且不想把自己的无能暴露出来。
在过去的合作中，我跟横向的合作伙伴一直很愉快，除了A几乎所有的合作伙伴都是很负责、很主动。其他模块也发生过这种产品提出来需求，下游分析了半天发现做不到，下游的人找我说清楚，我改配置表，老板问起来大家一起回答下就ok了。我就当A团队自己内部没有充分沟通，而不是A的负责人故意想这么干的。因为A只懂他那块的一亩三分地，也都是问的各种供应商，C的事很难判断。A评估的能行，只是这个需求链条中他的部分能行。
职场中的自我保护技巧我也懂，但我跟这帮人共事三年，从来没想过要在这帮人身上施展这种技巧。好吧，以后跟A团队的任何沟通，字面留痕、会议有会议纪要。麻烦点，也请你们少点事。
最乌龙的是，现在A找的供应商X又信誓旦旦说原需求能做了。反正大老板找的供应商Y，人家CEO反复多次在各种场合否认了这个方案。你们聊吧，我只描述想要的用户体验。
我的亏吃在，如果按照广义的产品流程，我确实有做得不到位的地方。但我们组织本来就是有约定的流程，比如硬件类的需求，产品只需要维护配置表，不需要详细的需求文档，这都是下游团队要求我们这样做的（因为这样他们选供应商的灵活度更高）。包括需求的释放流程、评审流程，也是跟下游团队拉齐的。但就不像互联网公司需求评审、签字画押、项目管理这么规范。现在人家矢口否认，我也没办法拿什么证据。真的恶心死我了。
B也被恶心到了，因为这个需求的实现流程实际上跟他几乎没关系，但是作为这个组织中唯一懂这个的人，他被老板任命做整个技术方案的可行性评估，他要给不属于我们组织的C评估可行性。
18 92
2 00
新的牛马技巧增加了
牛马狂喜：手把手教你用Gemini写“车规级”PPT
1 00