M产品酝酿了那么长时间，终于大规模的研发了，实属不易，但是摆在K君面前的困难还是不少的。6大模块同时发力，需求欠缺，只有概要需求，时间期限很紧，人员缺失，研发人员，需求人员都存在着瓶颈，并且年底前需要出α版本。想到了这些脑袋就已经大了。
如何做？怎么做？那么多的需求，需求人员对应的过来吗？研发人员一起研发6大模块，还是像以前一样，等待着需求写出来，评审完毕在进行吗？那么到了年底，估计需求还没有搞完呢，更别提演示版了。那么如何去做，需求成了瓶颈，how can we do？
不过K君也很兴奋，因为越是这样，就越有挑战，只有这样，才能磨合出另外的一套山寨敏捷，也是最想做的另外的纯山寨版的流程，说干就干吧。
首先和需求的Z君进行了协商，要求他们全力配合进行，需求需要进行概要讲解，全力配合后面的随时咨询事项。也就是他们可以只写只言片语的需求，剩下的就靠说，只要说能应付过来就可以。剩下的，功能节点设计，都靠讨论进行。其余的细节需求，由研发人员跟上，进行补充。
那么如何保证这样的流程顺利呢？什么样的工具最适合这样的流程，这些的协作呢？没错，当仁不让的出现在K君脑海里面的就是Wiki，比较了几大Wiki之后，选择了HDWiki，大家一起写需求，不再依赖需求人员，需求人员摇身一变，已经成为了产品经理的角色了。
具体编写需求流程讨论后，决定，由需求人员现在Wiki上面编写部分内容，也就是关键的内容，然后研发人员根据这部分需求进行讨论，分析，形成新的功能点设计，讨论的细节，内容，更新到wiki上，这个可以由需求人员和研发人员共同完成。后续再研发过程中的讨论细节点，由研发人员逐步更新完善到Wiki上。最后时刻，由需求人员进行完善。
说的容易，做的难，后续还有很多需要考虑的，还有很多困难，但是慢慢来吧，K君做好了充足的准备和打算。
也正是因为会有很多的苦难和挫折，所以打算从现在开始，进行记录下M产品的研发过程，记录过程中的痛与苦，记录过程中的思考和挫折。为自己将来的分析提供素材，也为大家提供一个参考。不过对于错，它都是一个经验。