个人总结-公司业务逻辑如何进行梳理？

1、来源于文档(交接文档、对接文档、需求文档、接口文档)

1. 有迹可循。为什么要留下书面资料，为了后续追溯问题。口说无凭并且记不住。所以往往严肃的需求以及报告都是建群，群聊跟群发邮件来通知到位。
2. 明确，主观情绪较少。言语中往往会掺杂一些对需求的自我理解。甚至很多时候写在文档中是基本需求，但是口头传递希望可以添加一些拓展功能。这部分在倾听者耳中是很难进行辨析的，都会统一认为是对等的需求。
3. 可传阅。文档形式可以通过复制粘贴，同时准确传达给N个人，但是如果通过口口相传，耗时耗力，并且不同人员对于业务熟悉程度不一样，知识维度也存在差异，导致后续者听到的传达信息出现偏差。
4. 基于文档，可以进行文档版本迭代，备注好XX版本新增什么内容，修改什么内容。像开发浏览git分支一样，可以了解到项目的变化。口口相传，人走了，后面人可能因为时间或者描述不清楚，传下来就是残缺不完整的。需求自然做不到位。

如何进行文档需求理解跟沟通？

• 1、需求分析。接到对应文档，浏览文档整体，对于有不熟悉概念的进行标记，对于可能产生的业务逻辑难点，技术难题，进行想象，大胆假设。按照基本的一个需求需要满足增删改查功能为出发点，拓展本次新增功能。
• 2、需求提问。整理你需求分析过程中，需求不确定点以及技术难点，可以复制当前文档，然后进行标注，或者另外起一个文件进行单独提问标记。需求变动是正常的，也是常态。但是需求提出自己觉得逻辑易错点，或者技术难点是有必要的。不同的工作人员因为工作经历不同，或许你的问题提出来，可以得到马上有效的解决。但是同样存在你不提出来，别人的经验是觉得这个是小问题，很容易解决的。对于业务逻辑有歧义，或者技术实现方式想复杂了都是一个接收到对应业务需求的常态。但是在初期没有主动提出，后面变成时间黑洞造成了项目延期，那么就是犯了不该犯的错误。
• 3、需求确认。在你没有办法对你项目负责情况下，最佳的处理方法就是找项目负责人进行需求确认，尽量以文档形式进行需求确认。前期如果就能及时纠正一些需求点的错误认知，那么造成后果是最小的。以及某些需求经过反复再三确认，相当于你不断加深了对业务需求的理解。等到实际动手时候就没什么太大需求问题的返工。如果是重大需求变更，那么你也能有效知道本次需求变更所造成的后果，对项目整体变动有一个很高的评估。
• 4、问题追责。去实现完成某个项目，顺利完成加在你的绩效中。如果出现问题，必不可少需要涉及项目复盘，追溯本次问题出现的原因，以及如何改进。白纸黑字的文档，当时需求提出时候有对应文档，但是你需求理解没有对应文档，不管中间产品还是甲方是如何跟你沟通需求的，最后出现需求理解偏差只能说是你个人理解偏差，你要对你的事物负责。如果你的需求理解进行确认，产品或者甲方通过确认，最后版本是按确认的点进行完成，但是跟他们预期有出差，那么对应责任他们确认不到位需要承担多一些。

2、来源产品(公司内部业务提出者)

1. 明确一个观点。产品是一开始最懂业务的，但是当项目完成之后，开发应该是最懂业务的。所以产品提出需求是初期的过度，开发自己应该掌握业务需求是核心。
2. 产品懂不懂业务？网上出现过产品需要开发实现五彩斑斓的黑的业务梗。以及后续一些夸大梗的程度，产品懂个锤子业务需求。产品就是个传话筒等等。负责合格的产品自然是懂业务的，但是产品不仅仅负责一个业务，往往多产品线时候，产品是多线负责者，你可以咨询产品一些业务需求的信息资料，但是不可能你每次去咨询，产品都能很好的切换产品线场景，针对你提出的产品告知你准确信息。所以个人在经过初步了解之后需要自己总结。
3. 需求来源于产品，产品也是通过理解对应文档或者是需求提出者进行沟通之后得到的业务需求。当开发得到对应的无文档，口头进行布置的业务需求时候，应该个人积极主动的去将口口相传的业务需求进行文档化。让对应需求能够落地，有迹可循。甚至哪怕之前没有对应的需求文档版本，从你这一版开始，应该有一个你之前对项目认证的初版文档，以及本次需求添加的具体文档。按文档说话，不同人去理解需求，然后让他们描述相同的需求，可能都是基于自己的理解出发进行描述的。

如何进行产品经理的业务需求理解跟沟通？

• 初期，项目分大小。这里审核项目大小的关键是你是否能负责这个项目？如果可以负责这个项目，那么这个项目算小的，你说了算就可以。如果负责不了，那么项目算大，需要多方参与人员在初期就从自己参与者角度或者实现能力出发，提出尽可能多的的问题。大项目某些产品个人考虑存在不充足的可能性，但是如果他能够回复初期各方参与人员提出大部分问题，包含核心问题的争论，那么该项目的业务认知是到位的，越熟悉一个项目，那么对应项目中的问题也能够很快解决跟处理。这里的导向无疑是产品为主。
• 中期，是指产品需求评审通过之后，在实际实现过程中对于业务逻辑产生了疑惑。这里需要做的是纸质文档，进行提出你的疑惑，你的解决方案是什么？在产品需求评审时候，对应业务逻辑为核定，那么主要是产品去推动项目的落地。实现过程中，应该是开发去推动项目的落地，这时候你提出的疑惑本质是你之前未认真考虑对应需求逻辑，现在需要产品的帮助，那么你需要把你问题思考描述清楚，以便于产品更好的了解你实现中遇到的差异点，以什么形态去修正实现方式比较合适。提出问题，并提出你的方案，然后让产品协助选择，或者是产品提出更贴近业务的方案。中期需要他人协助的步骤是，提出问题，带上你的思考跟解决方案，让产品介入协助，得到目前而言最优的方案结果。第二步骤很关键。没有第二步，你只是提出问题，那么产品的选择是在要还是不要之间选择，保持现状是大多数的选择。带上你的思考跟解决方案，可以帮助产品类比实现效果，能够有效的去衡量问题造成的后果跟影响，也能知道你目前的实现能力，相较而言，会进行考虑，折中选择你能实现，对目前项目改动较小的方案实现。
• 后期。这里主要是迭代。产品的初版已经定型。大部分产品在这时候可能仅仅保留知道这个项目跟这个项目的初版具体实现后的效果，中间很大部分的项目细节，有文档记录那么就是有，没有文档记录那么记不记得住看天意。所以通常在项目初版实现之后需要就本次的项目实现形成纸质文档记录，整理业务需求以及业务需求对应文档，实现的对外接口，为后续做准备。后续迭代中，产品更加依赖开发进行迭代需求的评估。某个功能如果是新功能加入，对目前流程跟数据落库是否会产生影响，需要开发评估对应开发周期，该功能是否可以实现等因素。开发是后期最了解业务的人，完成了业务项目的一个递交。

3、来源甲方(对接追加/聊天中追加)

1. 直接跟甲方对线。小公司或者小项目中该情况存在。直面甲方，你就知道产品为什么难当了，产品的方案初版首先要跟甲方进行核对，是否是甲方想要的自行车，还要内部进行讨论，开发是否可以造出这样的自行车。小项目没有产品，仅只有开发。那么就要锻炼你自己对于需求的提炼，对客户需求的把握能力。一般简单而言的项目涉及业务是否合理，是否可以完成，后端技术是否支持，前端技术是否支持，能不能多给时间完成。

如何进行甲方对线的业务需求理解跟沟通？

• 1、相比较产品，属于内部沟通，你还能说这个功能做不了，完不成去否掉需求。对于甲方，显得底气不足，只能说该功能复杂耗时，或者逻辑明细不合理，最后还是让甲方进行定夺，是否坚持要按这一版本走。
• 2、相比较产品之间的同事关系，甲方乙方是不对等关系，你是服务的提供方，他要你要给，不然就没了甲方，也没了项目。势必是有一些不合理的需求也要硬着头皮完成。甚至你要完成的更好。
• 3、有业务不懂，需要找对应甲方负责人讨要对应文档或者反复浏览阅读对应钉钉或者微信的聊天记录，自我进行再三确定是否该问题之前有提到过，是否是已经确认的。然后再发起跟甲方的通话，往往很多时候甲方也不知道自己需要什么，你还要引导甲方去提炼项目的一些需求，这个需要涉及你的项目功底。总之甲方没有错，有错也要你自己解决，不然要你干吗？
• 4、在聊天中追加的需求。往往聊着聊着就给你加点新需求，我想要…。最佳的方式还是通过邮件发起新需求的添加，对应需求形成一份需求文档。任何这类中间突入起来的需求，都不要直接答应，最好的方法还是先回复了解，内部讨论一下再给答复。你可能当时就你的参与身份角度去思考了这个需求给你带来的变更，并没有考虑其他参与角色，该需求变更带来的他们改动影响。如果一个项目就你一个，那没事了，这个从某种意义来说，你就是项目负责人，你可以负担整个项目，那么你说了算。最后项目跟你有一个能跑就行。

4、询问相关同事

涉及到同事了。首先要明白猴子理论。谁的问题。

• 1、要让双方明确责任、下一个动作的归属，不能他以为在等你，你以为在等他。
• 2.、每次和下属的辅导和讨论控制在5～15分钟之内，每天控制总的讨论次数。
• 3、只能在约定的时间讨论，不耽误自身的责任。
• 4、和下属的讨论一定要见面，至少是电话交流，不能通过邮件。见面和电话是同步沟通。邮件是异步沟通，对方的邮件没回复的时候，责任就在没回复者的身上。
• 5、每次讨论完要约定下次沟通时间。否则可能因为困难，事情会不了了之。

请仔细阅读猴子理论。明白问题在于谁，你向同事进行询问，毫无疑问，你也把这个猴子带给同事，那么后续猴子属于谁，我希望你能有一个清晰的认知。否则别去坑队友。

如何进行相关同事的业务需求理解跟沟通？

• 找什么样的同事？1、跟项目有关的，产品，或者对应项目负责人或者技术更好的同事，或者业务了解更加扎实的老同事。
• 你需要做什么？你带着你的问题寻求帮助，别人也愿意提供帮助，那么你应该在提出你的问题之前，了解你真正的问题是什么，你要首先自己明确问题，你想得到怎么样的帮助？是技术上无法实现有没有更好的解决办法？还是业务走什么逻辑不知道，需要业务扎实的同事进行答疑？还是产品某个需求告知你，你经过分析感觉需求存在问题，有进一步探讨的必要性。当你清晰且明白你想要什么？你才能让别人知道你想要什么？
• 问题反馈。问题反馈一个是向相关同事明确，这个问题后续还是我来进行负责。以及目前问题是解决还是未解决，同事可以进行评估自己是否需要再次花时间介入你的问题。帮忙不是问题，但是帮忙到最后，变成你的问题，你跑过来向我要问题的进度，谁都不大乐意帮这样的大宝贝。
• 有空可以多看看提问的艺术。其中也是需要你明确问题，你做了什么努力，然后再是提出你问题中你难以解决的关键点。自助者人助之，提问一张嘴，伸手要答案，很难说解决了这个问题，你下次不会再出现相同问题。认知不够深刻。

5、来源代码

1. 好的代码，本身你就能看出对应逻辑是什么，是怎么样的。简单的增删改查，实体类转换，数据库简单的整条数据保存等等。
2. 写注释。不写注释，十年后的你都没办法帮你改这个代码。他能做的就是基于文档重新梳理，然后你这个代码分支弃用，重新编写对应代码。我无法判断你写的代码逻辑是否正确，因为我不信你写的代码，但是对你写的汉字，我还是报以一定的信任。所以代码要写注释，如果有些逻辑变更，及时修改注释，有助于未来的你修改对应代码(填坑)。
3. 文档跟产品都不在了。维护老项目，是很多进去接锅的开发都无法避免的。要文档，没有。对应产品，不在。对应开发指定早没了。那么你手上唯一的线索就是对应代码了。按着controller层，service层，实现层，Dao层一层层去分析吧。从代码逆推出对应想要完成的业务功能。在这一过程中，简单的增删改查你可以默认通过，复杂逻辑没有注释，原地爆炸。记得梳理之后及时文档反馈，记录你本次改了什么，或者梳理出什么，慢慢完善。

6、题外话

1. 为什么编写文档？因为文档有迹可循，可以经得起校验，甚至通过文档，我可以重新起一个项目都问题不大。真的让你维护老项目，还跟你说这是线上的，你敢动吗？ 不感动(敢动)。另外程序员的差异化也在这里。年轻程序员，把项目当一次性来做，对于一次性筷子，你会要求它有产地证明吗？对应每一个项目都应该有对应文档进行维护，因为每一个项目都有做大做强的可能性，有文档，后续才能更好的维护。口口相传需求的项目，除非是很简单经典的，不然可能会做大做强吗?
2. 项目的大局观。其实后端为什么比前端看起来更重要。是因为后端技术吗？不一定是。但是主要原因我觉得还是业务需求掌握。项目越进行到后面，会把逻辑判断放在前端吗？不会，因为跳过前端操作，直接接口进行模拟调用，就跟前端一点关系都没有了。本质还是需要后端。以及复杂操作，跨数据库进行数据落地，调用多服务模块，都是后端进行分析，实现。所以后端开发需要掌握业务，因为有一些东西就是落到这样的。当然前端也可以积极了解业务，不过业务往往是后端进行实现具体的是不争事实。

否需求。技术活。否需求绝对不是靠一句，我做不了，我没办法实现去否的。而是基于目前业务深刻了解，技术能力心里有数，跟相关负责人阐明利弊后做出的决定。应不应该去否需求？按正常正流程中是没有否需求这个说法的，项目实现本身就是为了完成需求。但是按照不同处理方式来对待了需求。

• 1、逻辑过于复杂。你是否能够提出简化逻辑但是实现需求的方案。如果能，提出来属于优化需求。如果不能，需要合理评估逻辑复杂点，是你想复杂了，还是产品或者提出方向复杂了。一般需求逻辑不会是千层饼，一层套一层。应当是简明准确，达到实现目的的。
• 2、技术难以一步到位。技术需要做技术知识储备的原因在此，当需要技术时候，你的技术知识储备能够应用上。当难以一步到位时候，做技术降级处理，提出你的降级方案，是否能达到效果，或者去学对应技术。
• 3、可以实现，但是耗时，得加工期。没有什么不能做的，只是时间需要增加多少的问题。这个时间因素是产品跟甲方密切关注的，他们提出业务需求不管你的技术实现是怎么样的，但是他们对外也有一个项目完成时间的要求。当你提出这句话，他们会进行时间评估，或者同意或者压缩，再或者他们自己把这个不合理的需求给否了。

---

漫漫长路，一个小周跟他一个小陈朋友一起努力奔跑。

---