认识达内从这里开始

对于程序员和设计师来说，改需求可以说是非常头痛的一个问题，因为这个会大大延长整个项目的完成进度。而对于产品经理啦说，如何通过沟通来说服程序员修改需求就是我们今天要给大家分析的主要问题了。

1.换位思考。

PM常沟通的人应该算是程序员吧，程序员每天都跟代码打交道，他们对于一个需求的理解方式一定和PM是不同的，但是恰好PM写的需求是给他们看的，所以必须要让他们看得懂。这就需要换位思考，既然我的思考方式他们不理解，那么就试试他们的方式来思考。

2.确保理解。

因为大家对需求理解不一致的缘故，后做出来的东西根本不是我初想要的，然后要不就是我妥协，要不就是改代码，反正搞得大家都不会很愉快。这是我曾经踩过的坑，如果我可以确认大家都对需求有统一的认知，那就可以避免这个问题。

上面有提到，画整体的逻辑图，就是帮助其他同事理解我的需求的方式之一，先让他们对项目有一个整体的概念，要让他们先知道我要做的是一个什么东西，我为什么要做这个东西，他们理解需求来源和整体之后，就不会跑太偏了。

我遇到过很坑的，可能也是比较常见的沟通失误，就是讲完需求，跟开发确认是不是都理解了，然后开发大大们很愉快的说理解了呀。

但是做的过程中再确认，就发现，嗯?怎么和我说的不一样啊，理解偏差了啊……

避免这个问题，大概就只能反复和开发沟通吧，就是多讲几遍，给他们灌输，讲一遍，问一遍“我表达清楚了么?”然后好让他们复述一遍看是否有偏差，这样反复确认。麻烦也没办法，总比代码写完了再来改要好，一定要先确保需求没问题再开始写代码。

3.不要放弃对结果的高要求。

如果你想做一个100分的好结果，你把项目交给设计、开发之后，他们出来的结果打个折，可能就只剩下80分、60分了……

PM是一个把控全局的角色，先要坚定自己对结果的高要求，不能自己这里就先给了一个80分，那后面分数就只会越来越低。

举个例子，如果一个设计稿出来，不去挑毛病、不去优化，直接就去开发了，开发过程中还有样式的偏差，那后做出来的页面根本就不能看了。但如果在设计阶段可以有更高的要求，逼一把设计师，出多几稿，对比得出好的，那后面就会稳妥很多。

任何时候，都要想着“我要做到100分，做到好”，那如果客观原因做不到100分，后出来的结果也不会差太多。

4.需求变更咋整呢?就可能心态要好吧，拥抱变化，以不变应万变吧。

需求变更是不可能避免的，因为业务方总会有新想法，老大总觉得做得不够好。

变更一定要及时，一时间先通知开发暂停相关需求开发，将大致逻辑告诉他们。然后再尽快整理文档同步。这样做可以节省下开发不必要功能的时间，时间就是金钱，能省一点是一点。

因为过多的需求变更，引起开发小情绪的时候，等他们冷静一下后再把需求要这么做的理由跟他们讲清楚，理由一定得有理有据且逻辑清楚，加上业务方面和公司利益方面的考虑效果更佳。开发们也是讲道理的，而且相当敬业，所以不会打死PM的。

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益!