我是丹仙仔，我是要成为站在产品顶端的那个男人。
这周倒发生一件令我着实难忘的事。在周五下午的retro，我主动提出需求文档和设计稿目前经常存在不一致的情况，然后这个话题被大家选中，重点讨论，，由于我们的设计和我老大都不在，也就是我代表着他们的立场与我们的研发小伙伴一起解决问题，这也是我第一次这么深入的与大家伙进行讨论。这个问题一直困扰着我，所以我先介绍下这个背景
我们团队产品资源一直不够，自从招了俺介个实习生后就一直没填过坑，眼看着前端、后端、测试的队伍愈来愈壮大，需求的压力也越来越大，而且老大最近还时常需要产品培训、售前方案支持、实施问题解决、技术方案评审等各种事务，也因此苦于对需求设计时间紧张，所以我们的设计同学会承担一部分画图的时间，也就是产品和设计提前沟通明确好需求，由设计直接出设计稿从而省去老大画原型图的时间，这是她们目前协作的模式，也因此，对于我设计的需求，我也是很少出详细的图，会等着设计稿完成后，在增添产品细节，导致我很被动。
在这样的背景下，慢慢衍生出许多问题
一个人是 在我们需求评审的会上，会拿着产品和设计最终定下的方案去评审，在评审会中，难免会有一些需求细节的变动，如果涉及到设计稿部分需要变动的地方，理论上设计稿也应同步更新，但我们的设计最近需求评审不出席，导致需求的变动需要我们转达给设计，此时沟通成本陡然提升，所以会导致需求更新了，设计稿没更新，特别影响后续的开发和测试效率
还有一个流程上的难受之处是说，虽然设计同学直接出设计稿减轻了产品的画图负担，但是变相增加了设计的压力，我们认为设计本不需要出详细的设计稿，只需要在根据需求评审后，对于所需要的设计细节进行补充完善即可，而且如果说产品和设计定下来的最终版方案，在需求评审的时候，不通过的话，反而这个需求的设计稿就失效了，也就是设计提前介入需求，有利也有弊
经过一番坦诚的讨论后，我们想到了两个解决方案
1.一个是需求评审的时候希望设计也能参加，减少沟通成本/
2.另一种方案是需求评审时产品拿原型稿评审，在评审后确定的功能细节在由设计同学补充。
诚然第二种方案是最理想的一种协作模式，这种模式的前提条件是产品资源足够充沛，那自然需求评审是拿着产品自己定义好的交互和功能去评审，最后呈现的设计稿也几乎和最终版无异。
协作方式都得因地制宜，不同的环境孕育出来的都是不同的，不能说那种好哪种不好，有问题就得解决，现在问题的暴露那我们就得思考协作模式的合理性，最终的方式如何定，估计还是得看需求的大小，我现在在做的需求可以尝试以2 为方案 看看效果。
