思考

今年回家无意中了解到我表姐公司产品模式是一种什么形式，因为他们公司的老板是敏捷开发的倡导者，所以公司不提倡写需求文档的方式。

所有的需求文档都写在原型图上进行描写，原型图本身也是一个在线的文档，如有新的需求的变更，也可以更好的维护。

并且他们在接受到需求之后，会开一个需求评审会议，需求评审会议会讲解该需求的背景，以及要实现的功能，如会议技术组长同意，接下来又产品再去出详细的需求说明和原型图的绘画，至于技术实现方面，完成又技术组长进行把控。

至于在现实方面的，如不能实现那么在需求评审会议的时候，技术组长也应该提出不能实现，如需求评审会议过后，需求与技术的交涉都是交由给技术组长进行。

好处：

1、原型图与最终实现的功能相符，并且需求出现需求更改也可以更好的传达两方（测试、开发）看过很多敏捷开发的软件，都特别主要在线文档的需求。

2、少了与技术支持和扯皮的过程，可以让产品经理把重心放到思考产品本身上

3、使用在线文档的随时更改，也保障了文档与功能是一样的。

坏处：

1、少了文档的更改记录，如开发按照需求的第一版进行开发，后续进行了更改了，开发需要重新修改，这样导致开发的任务量加重，同时身处开发的角度，会给领导产生一种，是不是你能力不行，导致功能延期等等。

2、需求评审会议的内容，只是对功能大概的说明了一次，功能的细节后面是后续出问题再交由开发，这样就会考虑公司的产品能力是否极强，如设计能力不强，许多细节未考虑，未更改需求带来一些隐患。

3、大厂的需求评审会议，需要将需要文档写的很详细，然后再交由各个部门负责人进行审核，再这种情况的审核，可以把一些该产品设计考虑不周全的地方，进行质疑、修改。

思考：

1、在线文档的留证据，维护文档变成一个繁琐的事情

2、很多开发组长，以为我嘴上说着不能做，后面又监督开发成员把事情做完。虽然我嘴上不说，但是我还是会做事情，这种情况不利于产品对全局的把控

3、过度站在自身的角度思考问题，而不是站在项目的角度思考问题

4、需求文档需要考虑开发是否看得懂，还要考虑测试是否看得懂，写一份自己看得懂的需求文档很容易，写一份大家都看得懂的需求文档就不是那么容易。

5、需求文档说明编写，需要注意前端逻辑是否清晰一致，后台逻辑是否清晰一致，如有足够的时间，将前端逻辑与后端逻辑分开写是有助于文档清晰化。

6、想起前公司的一款软件，在需求编写的功能里面，会记录