2022年3月
    还记得碰见的一项任务，需要在某个时间节点之前完成某项功能的开发。在这个任务中，对于任务的描述没有任何问题，通过学习，清晰地将需求描述清楚了，可能会存在的开发问题也先与研发做了沟通。
    但在需求评审的时候遇见了问题，研发对此需求的场景并不认可。原因在于，尽管该需求的实现有价值，但依据部门产品的规划，此类功能会并至其他产品完成，该需求的实现一是占用了许多时间，二是后续发挥作用的时间会很短。这个点是我之前没有考虑到的，在定义产品需求时，需要首先从大的产品战略出发，本意在需求实现之前就应该定义好，但此事还是没有落实到位。
    不过延伸出来的收获是，如何说服其他人接受你的观点。在认定研发的结论是可行的之后，后续的步骤是要尽快定出一个方案，说服需求提出方。今天的感受是借力打力，可以依赖于你的上级。对于本人而言，在具体对接时，一是受限于资历，二是受限于本人能力，有可能自己的方案无法说服其他人，特别是其他部门的人。比较容易考虑执行的是，可以先说服你的上级，一是摆出事实，阐明当前面临的问题，二是提出你的解决方案，你的上级，若同属于一个部门，隐含的点在于你们的利益应是一致的，他更容易接受你的观点，且相对于你本人而言，在他接受你的观点后，提出的论据与判断更具有说服力，更易被他人接受。
    今天就是如此，在会议上与上级达成共识后，面对需求方，被说服也就自然而然了。

    2022年6月
    与研发交底，涉及到功能时，需要对每个想要的效果都描述清楚，而不是参考XXX；每个人都有每个人的理解。例如参考XXX的选中效果，这个就很不好。