如何在没有系统了解产品的情况下去接需求
马上接手，没有时间去思考，去熟悉产品，让你接这个产品已经过了需求讨论，业务背景讨论的时间。转手给你的人也是忙成狗，仅甩给你一个prd。
在你还没有完全理解你要做的项目前世今生的情况下，你就会被拉到各种会，然后领导一句话，你来跟下，这个项目优先级很高，尽快落实上线。那能怎么办？
我目前的做法是这样。
1. 跟转手给你的人快速了解下项目目前的状态，解决了哪些问题，目前存在哪里问题，是否已经有了解决的思路。如果有最好，如果没有那就要跟相关人员，比如技术人员，业务人员问他们的解法。
2. 此阶段呢，自己尽量起到桥梁的作用，坚信没有解决不了的事情，依靠前期参与的业务同学和技术同学给方案，和信息，将相关联系建立起来，概括起来就是借助其他人的力量，将事情促成，自己在其中倾听，学习。力争通过此项目对产品有深入的了解。
目前接的项目就是这样的情况，待解决问题有3， 目前第一个已经解决，问题 2，3 据反馈是很难实现的，依赖在外部，非我们部门能解，而这个外部理我们需求的概率几乎为0.
跟之前跟过此业务，或者说熟悉此块业务的同学大概了解了她的思路，以及相关联系人，当然也顺便了解了目前的产品特征后（没有时间细致的去系统学习）拿到相关联系人信息， 后先dingding联系，阐述需求。一般会得到基本的反馈，然后就顺藤摸瓜，他也许会告诉你，他不是正确的能够解决此问题的人，接着会告诉他知道的可能联系人。直到你找的真正的联系人。
明确联系人后，可以电话详细解释需求，鉴于自己对目前的需求理解的深度， 我一般会叫上比我更熟悉一起去解释需求。 当然很多时候他们没空，只能自己上，这个时候的自己心是虚的，但是木有办法。。。
需求明确后，就是讨论解决方案，当然方案不可能一次搞定。但是因为有了开始，后续就是顺水推舟，比较方案优缺点，相关方评审，确定排期，启动项目。
自己在这个过程中 没有因为自己对系统的不了解而耽搁项目的进程，当然，整个过程是自己学习了解产品的最好的机会，所以争取自己每次写会议纪要，写的过程中梳理自己不清楚的地方，咨询项目同学。
一个项目下来，产品熟悉了，项目也完成了，但是因在做的过程是学习，熟悉的过程，你能够给出的产品建议不多，但是如果每次会议上你都能get到point，也是可以给出自己的想法的，因为不懂，所以想法可能会幼稚，但是这是这种幼稚，可能就是解决问题的新思路。
或许这是一个可以参考的方法，但是要提醒自己的是一定不能偷懒，线下自己一定要尽快熟悉业务和产品，傻一次可以 不能傻两次。
