TUhjnbcbe - 2024/9/11 17:03:00
无论是互联网产品还是产品项目，所有这一切的开端都始于需求分析，一份好的需求文档往往是项目成功的先决条件，对一个产品经理或项目经理来说就显得尤为重要。但是，同样是写需求，不同的人写出来效果却截然不同。相比产品菜鸟，高手究竟在哪些方面表现得更为突出呢？同样是写需求，为什么有的人能一次过，而有的人改了又改，甚至还要推倒重来？同样是写需求，为什么有的人考虑全面，而有的人丢三落四，直到评审的时候被怼得体无完肤？同样是写需求，为什么有的人简单易懂，而有的人长篇大论，大家却看不懂？这种情况在我们工作中经常会看到，优秀的需求文档和拙劣的需求文档，就像产品经理的脸面。那么，怎么才能写出一份漂亮的需求文档，结合这几年的工作总结，和大家聊一聊一、准确理解需求，才能有的放矢写需求的大忌之一，就是自嗨。很多自嗨型选手，自傲型的，会觉得自己的理解才是最完美的，用户提的需求或者场景，都是欠考虑的。他们不屑去找用户求证，也不会使用简单的方案先验证需求，而是完美主义的妄想一步到位，他们信奉乔帮主的一句话：用户并不知道自己需要的是什么，直到我们拿出自己的产品，他们就发现这是我想要的。自卑型的，他们不愿意找用户，害怕找用户求证。因为担心自己没有理解用户的需求，会被其他人看不起，怀疑自己的能力。所以即使不理解，也不愿意找用户求证，但是又要交差，最后就只能按照自己的理解硬着头皮上。不能准确理解业务场景，就敢写需求的，最后都会成为烈士。理解了需求是1，后面所有的文档，开发和测试都建立在这个1上，没有1，后面再多的0也白搭。准确理解需求，其实就是要理解需求背后的使用场景，可以使用常用的5W1H框架。what：用户的问题和需求是什么？when：用户什么时候会遇到这样的问题?why：用户为什么会遇到这样的问题？where：用户一般在什么地方遇到这样的问题:who：遇到这个问题的用户是谁？用户群体有什么特征？how：用户当前是怎么解决这个问题的？比如我最近负责的产品，有一个预警的需求，主要是针对平台的异常数据进行预警。预警一般就分为三步：预警的数据从哪来？预警的规则如何设置？产生预警后以怎样的形式发送给谁？前两步我跟用户（公司的业务方）都对的比较清楚。而在第三步通知上，我就犯了理所当然的错误，陷入了自己的想象中。我的想法是，产生预警的消息通知因为需要根据模板来配置的，这就有点类似于