点击上方蓝字关注灸哥聊程序员职场

最近，关注我的程序员朋友以及我身边的一些程序员兄弟们向我提出了一个比较有共性的问题：作为程序员，我们是应该完全依赖产品经理的需求文档（PRD）来编写代码呢？还是应该在 PRD 定稿之前积极参与需求讨论呢？又或者是在 PRD 评审时提出质疑和不同意见呢？成为自由人的第一天，刚泡上一杯咖啡，准备在这里和大家聊聊这个问题！欢迎留言交流对这个问题的不同看法！

这确实是一个深思熟虑的问题，我曾经年少的时候也曾为此困惑，但随着我曾经在阿里巴巴的成长经历，我对此问题的答案是有清晰的认知的：作为一个程序员，想要全面发展，绝不能仅仅局限于根据 PRD 编写代码，程序员不能只会根据 PRD 写代码。这里不禁想赞美一些我的前雇主，阿里巴巴培养了很大一批真正全面发展的程序员。

然而，以上结论是有一个前提条件的：如果你只是把程序员当做一份普通的工作，不愿意花太多精力去麻烦，而且你的产品经理又是一个既擅长产品又擅长技术的牛逼人的话，那么我觉得你是完全可以按照他的 PRD 编写代码的，也是可以接受的一种工作方式，如果你认同了我这个前提，那么可以不必继续往下读了，以下内容对你可能是没有太大意义的。

我聊聊如果程序员依赖 PRD 编码没有其他行为动作会有什么样的危害呢？这些危害都是我亲自经历或者亲眼看到的血与泪的教训，分享给大家。

01

首先，因为产品经理的用户需求理解程度、产品设计能力、技术基础知识等多种原因，他所完成的 PRD 中的描述内容是非常有可能存在歧义或者不完整的，如果程序员拿着这样的 PRD ，按照它里面的文字描述内容，直接去写代码了，会导致程序员对需求的理解偏差，是很有可能出现你实现的功能与实际需求不符的情况，如此会浪费时间和资源，对个人、对产品、对团队、对公司都是一种无形的损失，然后进容易进入一个又一个的不断“迭代”直至完全服务实际需求。读到这里，你是不是对产品技术相爱相杀有了一定的理解呢？

02

其次，PRD 中描述的功能可能并不全面或者不准确，有时候会忽略一些关键细节或者边界条件，尤其在非功能性需求上，说实话，这两年确实没有遇到过让我特别“爱”的真正的产品经理。这个时候，如果我们程序员只是依赖 PRD 中的内容来写代码，是会出现功能不完善、存在遗漏、性能问题等 BUG，最终对产品的质量和用户体验伤害很大，然后又要开始一个又一个的不断“迭代”。

03

再者，很多时候你所拿到的 PRD 大部分都是对需求进行了简单的描述，没有提供具体的实现方案或者技术细节要求，如果我们程序员只是依赖 PRD 的内容来编写代码，是会缺乏创新性，局限于传统的解决方式，无法充分发挥自己的想象力和创造力，更无从谈起你的产品系统要具备高性能、高稳定以及技术领先性了，那可能真的是天方夜谭。

04

最后，我们在实际需求研发的过程中，需求是经常随时发生变化的，而 PRD 中的内容可能无法及时更新或者跟上变化。如果程序员只是依赖 PRD 中的内容来编写代码，那可能会导致无法应对变化，需要频繁地修改和调整代码，增加开发的成本和风险。互联网这个江湖中，从来不缺程序员背锅的事件，即使我夸赞的前司也出现过。

如果程序员仅依赖 PRD 编码除了第一部分的危害之外，对一个有追求的程序员来说，对他的全面能力成长也有着比较严重的影响。

01

首先，如果程序员仅依赖 PRD 中的描述来写代码，而不去深入理解需求背后的逻辑和业务场景，是可能会导致技术能力成长的局限性的，可能只会按照文档中的要求来完成任务，而缺乏对业务、对产品、对技术的深入理解和应用。而一个不了解业务、不了解产品、不了解技术全面的程序员还是一个真正的程序员吗？我这里对这部分程序员称之为真正的“外包”。

02

其次，第一部分也提高过，过度依赖 PRD 的描述写代码除了限制了你的产品创新能力以外，对程序员本身的创新能力也有极大的伤害，因为他们会局限于 PRD 文档中提供的解决方案，而不会去思考是否有更好的方法或者更有效的实现方式，这种情况下，他们很难在工作中展现出创造性和创新性。

03

其次，如果一个程序员已经习惯于依赖 PRD 中的内容来编写代码，对他自我学习的动力有着极大的减弱和伤害的。他们会进入一个误区，会觉得只要完成了文档中规定的任务就足够了，而不去主动学习和探索新的知识和技术，对他们的职业发展和能力成长有着极大的伤害，尤其是对刚进入职场的程序员。

04

最后，过度依赖 PRD 中的描述内容编码也有很大可能会降低程序员的沟通协作能力，会忽视和业务人员、产品经理以及相关协作团队成员的沟通，导致在工作中出现理解偏差或者需求误解的情况，影响团队的整体效率和协作氛围。

在我们的实际工作中，尤其现在这个大环境下，每一个程序员都面临着要不断提高工作效率、保证代码质量和个人成长的压力。而单纯依赖 PRD 编码虽然看似简单“无脑”，但会有很多危害和挑战，上面的两部分内容我已经分析过。那么，作为一名真正的程序员，究竟应该如何才能更加有效地工作呢？

01

首先，要明确理解需求。在开始编码之前，要认真阅读和理解产品需求文档，并与产品经理、业务同学以及设计师和其他相关干系人进行充分的沟通。如果文档中有模糊或不完整的地方，应该及时向相关人员提出问题，确保对需求的理解达到一致。如果这个需求的相关干系人没有达成一致不动手。

02

其次，要参与需求讨论和设计过程。作为技术人，参与需求讨论和设计过程是非常重要的，可以帮助你更好地理解需求背后的业务逻辑、业务场景以及业务价值，发现问题并提出解决方案。同时，与产品经理合作，共同制定合理的产品技术方案和实现计划。不能产品经理“一言堂”，我过往的经历对“一言堂”的产品是坚决不容忍的，当然如果是牛逼厉害的产品经理，我会非常“爱”的（此时脑子里出现了好几个人，有点想他们了，是时候回杭州见见老朋友们了）

03

第三，要注重代码质量和规范。编码过程中，要遵循良好的编码规范和设计原则，编写清晰、简洁、可维护的代码。及时进行代码 Review 、代码重构、技术债偿还，及时发现和修复潜在的问题，保证代码质量和可靠性。

04

第四，要持续学习和提升。作为程序员，技术更新换代非常快，要保持持续学习的态度，不断掌握新的技术和工具。参加技术交流活动、阅读技术书籍和博客、参与开源项目等都是提升个人技术能力的有效途径。亦可参阅我之前的一篇文章内容。

程序员如果可以做到更快地写代码和写出更少的 BUG！程序员的速度和质量并存之道！

灸哥漫谈，公众号：灸哥漫谈速度与质量并存：程序员如何做到更快地编码和更少的 BUG

05

最后，要注重团队合作和沟通。在团队中，要积极主动地与协作角色合作，分享经验和知识，共同解决问题，促进团队的协作和效率。同时，要善于沟通，及时向团队成员和上级汇报工作进展和问题，共同制定解决方案。

最近认识一位非常厉害的出版社的技术编辑大哥，还真是有缘，没想到我去年关注的系列书就是出自于他的怀抱！非常有幸认识他，也期待接下来和他的合作。这个系列书中我比较尊重和推崇的也分享给大家！

其中第一个系列是 Spring Cloud Alibaba，这本书吸引我的是他的目录框架，应该是当前图书中最全的知识框架了，对梳理和建立个人的知识体系有非常大的帮助！

另外一本是我自己在寻找大数据学习资料的时候发现的，市面上大数据的书太多，但是都比较散，要么是单一技术组件的讲解图书，要么就是一些场景介绍的图书，但是下面这本书他是非常全面的知识体系，按照体系讲解对应的组件和思考。对我去年全面梳理大数据知识体系有非常大的帮助！这本书的第一章的一个架构图会吸引住你的！