一个项目的成败与否，或多或少都与项目的需求分析有关，专业的项目需求分析师，在做项目需求分析的时候，很多都能一针见血，而刚从从技术转型的项目经理，在思考问题的时候，多多少少会受到技术思维的影响，特别是在用户讨论需求或者问题的时候，心里面想的主要是能不能做，能通过什么方法更好更快的解决问题，不是说有这种想法不对，只是作为一个项目经理，有时候这样的想法会禁锢我们的思想，可能就会南辕北辙，走很多的岔路，我们要知道项目经理的价值所在主要是如何帮助老板或者客户将他们的想法进行落地，这个时候更多的考虑应该是业务层面的东西，而不是技术方面能否实现，说句不中听的话，这压根不是你该考虑的问题，只不过好处在于你能从整体把控项目的整体范围，不至于造成偏离。

        下面小编就结合实例与大家进行一番探讨。

        当你与用户讨论需求的时候，不知道有没有遇到过以下的场景呢？

        这样的交流方式，是不是觉得很熟悉呢，要是懂技术的用户还可以理解那么一点点，要是不懂技术的用户呢，我觉得他此时肯定是一脸懵逼了吧，头上早就顶着一圈小星星了，那这个时候我们就要考虑了，这位PM问的问题对吗？从技术角度来说呢，一点没错，但是。。从需求分析方面来说，这样就显得角度不对了吧，切入点也偏离了十万八千里了，最后可能花了九牛二虎之力也能把需求搞清楚，但是既浪费了时间，又浪费了精力，实在是一件吃力不讨好的事情啊。

        我们要明白，项目经理不是架构师，也不是程序猿，而应该是一个以业务为导向的管理者，项目的切入点必须要是在业务层面上才对。

        如果我们换个角度，这样开始整个对话呢。

        作为项目经理的你，是不是觉得柳暗花明又一村了啊，后面的交流就不言而喻了吧，可能你们就仅仅花了一半的时间，就能把整个问题交流清楚，而且还是一次非常愉快的交流，这对用户满意度也是一个很大的提升，用户说不定还会给你一个大大的赞。
 

        我们要明白，作为项目经理，当我们采集需求、选择技术方案制定项目计划、确定验收标准的时候，用户的“业务目标”远比“技术实现”要重要很多，而我们要做的就是先要搞清楚为什么做，而不是怎么做。当你get到G点的时候，做起事情来就会很得心应手，而不是感觉寸步难行。

        以上这些观点呢，只适合于初入项目经理的小白哟，至于那些资深项目理，这套理论已经早就烂熟于心了，这就是做事情事倍功半和事半功倍的区别。如果你有更好的观点，还请给小编留言一起交流探索哟！




优培东方送你一张内部需求跟踪矩阵：
                                                            内部需求跟踪矩阵
                 项目名称：                        准备日期：                      

                                                               第1页/共1页