确认需求可行性的4个技巧

最近加入了一个新项目团队，由于不太熟悉新项目团队的协作模式，导致自己在需求可行性确认方面，遇到了效率问题：

1.对于需求实现有疑问时，只能挨个找对应的开发进行确认，效率低；

2.偶尔会有想当然的需求，到需求评估会议时，发生了开发觉得实现有问题，最终导致会议流为讨论会；

3.妄想开发会提前查看你的原型，实际他们却会等到需求会议时才被动“查看”；

犹记得在旧公司，有一开发负责人与我确认需求的可行性，基本上只要与他确认一遍原型，有问题的点当场指出并修正，到了与其他成员的需求实现沟通时，基本上是无障碍了。

现在回想起来，这种模式确实很舒服，但也有优势与劣势：

优势：

1.直接与开发负责人确认——确认扁平化，效率高；

2.需求早已确认好实现问题——因此，需求会议上存疑或者还需修改的较少；

劣势：

1.由于基本上属于开发负责人定了算——因此，各成员评估不会有太大的积极性，并且参与度降低；

2.刚好项目主要都是web＋pc client 应用，开发负责人可作此项目的全量评估——在其他项目不一定行得通，比如这个开发负责人并不熟悉ios/android 机制，如果让他来评估会导致技术盲点；

3.开发负责人偏向于于实现难度进行评估——因此，很难收集到其他成员更好的想法；

啰嗦这么久，谈谈我对于目前新项目团队的问题的处理方案吧。

由于之前从事的是web 应用开发，现在的项目有涉及移动client的部分，很多机制其实是不熟悉的。因此使用两种办法结合处理吧：

技巧一、查看同类应用的处理机制，详细查看每个方法、状态、异常处理；

技巧二、团队再大，一个端还是又一个负责人的，做好需求，不如完整与他过一遍，说不定他有更优的建议；

技巧三、做需求不能想当然，除了小需求点，在原型设计完毕时，最好还是与相应的负责人达成初步的共识，避免在需求沟通会议变成讨论会

技巧四、此外，别指望开发主动看原型，如果你的原型输出完毕了，不妨与私下他们约好一个时间，过一遍相应负责的部分。

以上，就是我个人近期关于需求确认的一些想法。并不适合每个人，但希望能在产品成长路上帮到你