项目管理是产品经理的必备技能，但这也是很多新手产品经理的硬伤。本文作者结合自身经验从需求迭代、敏捷开发、需求收集和项目方案几个方面分享了新手产品经理管好项目需要注意的几个要点，希望对你有所帮助。

一、前言

项目管理里，相信很多新手项目经理，部分产品和运营，经常被项目需求折磨的痛不欲生，不知为啥需求一直还需要修改，这是一个严肃的事，客户daddy给我们饭吃给钱赚，不能怪客户，更多的去想我们是不是哪里还没有做好呢？

笔者也是刚接手项目管理时长1.5月的练习生产品经理，在这里想和大家交流和分享下自己的学习和思考。

二、需求迭代的方式

1. 常见的客户需求推进方式方式

坑型沟通方式，项目初期沟通，其实客户并不清楚自己真正的需求，需求是在后面项目推进中逐渐明确出来的。

所以像图里一样，初期沟通非常多，后期沟通也非常的多，初期是需求多，后期是因为需求不符合客户需求修改的多。最后就变成了大坑。蓝线是一般沟通方式，所以到后期就容易改需求，增加了项目周期。

2. 迭代式需求推进方式

项目根据功能需求分为多个阶段，在该功能的早期进行项目的需求收集，后期进行需求的确认，这样即使需求沟通不充分，大概率也不会影响项目的推进工作，因为单个功能上来说，其实该动起来相对简单。沟通是阶段性的，尽可能每一个阶段的内容项目干预比较少，这样可以快速迭代项目快速推进。

二、敏捷开发

在国外，敏捷式开发也早已经被Google、Facebook、LinkedIn等企业应用，目前国内很多企业也在使用，所以，并不是一个新的东西。

该图来源于互联网（引用网站已关闭因此没贴上引用来源）

1. 敏捷开发的起源

2001年初美国犹他州雪鸟滑雪胜地的一次敏捷方法发起者和实践者（他们发起组成了敏捷联盟）的聚会，雪鸟会议共同起草了敏捷软件开发宣言。其中最重要的部分就是对一些与会者一致同意的软件开发价值观的表述：

1. 人机交互重于过程和工具；
2. 可以工作的软件重于求全责备的文档；
3. 客户协作重于合同谈判；
4. 随时应对变化重于循规蹈矩；其中位于右边的内容虽然也有其价值，但是左边的内容最为重要。

2. 敏捷开发的四条原则

（1）递增，而不是连续的

敏捷开发里最后交付日期是截止日，除此之外日常交付通过小步快跑快速迭代，意思就是快速制作内容出来和客户确认一点一点地快速确认，不能等待这阶段的任务完成了统一交付。

（2）避免不必要的开销

沟通必带方案，讨论迅速有目的性，减少阻碍项目执行的难点，会议仅限汇报和快速解决问题；

与其讨论要做什么，然后再多个人多次输出方案，还不如尽快确定基础标准，在满足标准的情况尽快去做。在大部分项目里时间：沟通的时间＞＞执行的时间，其实这是很没有必要的，即使沟通也许需要自己准备好方案，不然讨论的时候各种idea浪费的可能是七八个人的时间，1个小时的会浪费的就是7-8个小时。

（3）协作

协作这里必然需要通用的协作工具，一定要用，在管理里这是工作内容有迹可循、高效沟通，在协作软件里完成自己的任务后，不需要花时间去考虑是否这时候会打扰到别人。这里就不推荐工具了，百度一下一大把。

（4）说真话

这里的说真话并不是说，你说话的主观意识的真假，而是基于需求、事务判断的真假，如果你觉得美国人喜欢喝茶，然后就马上告诉团队的人，针对这问题展开讨论和开发，这就是假。所有讨论、需求、执行，必须基于这东西是真实需要的，否则开发出来了也是伪需求，价值不大。

三、收集需求到项目方案的过程

1. 和客户交流沟通

在项目开始前，一般会和客户多次沟通，这时候我们需要明确我们的目的——知道客户想要什么？客户的客户是谁？产品是面向哪些人的？这样交流沟通的时候时刻带着自己所想达到的目标，在沟通中达成目的；

2. 收集各个方面的信息，挖掘用户行为后的动机

并非抱着目的，我们就可以做好交流的，因此当我们思绪不够清晰，或者对客户了解不深和对项目信息获取不够时，我们就无法在交流的时候达到我们手机信息的目的。所以，在拜访客户之前，准备好想要提问的大纲，并且以此作为收集问题及信息的来源，

常规的流程，这是属于一般的工作或者演讲、访谈、调查的一般流程；

1. 制定访谈和想知道的内容大纲，并依此设计提问；
2. 根据问题的情况，并针对可能回答的内容，进一步提问内容；预想各类方案；
3. 到达场景时，预设一个符合主题的开场，然后切入正题；
4. 正常提问，并针对或者根据客户想法、客户的目标客户来进行沟通；
5. 最终获取相关信息，并应用在实际产品设计规划中；

3. 观察客户的基础信息和习惯

观察客户是什么性格的人，不同性格的人决策或者思考倾向是不一致的，可以辅助我们出方案，或者有利于我们沟通时针对性获取关键信息，比如偏保守的人，对界面和UI等设计需求偏向保守；

理解客户所在公司的风格，知道客户所处岗位，能够更清楚项目最终决策人对项目需求的诉求，市场和运营大部分的诉求基于基础功能之外能够对营收带来明显帮助。

4. 理解客户

项目里理解客户，和作为产品经理去理解用户其实很像，因为项目里的客户其实就是做产品的时候，很像公司里的领导，你的产品需求挖掘和设计，很大一部分取决于领导思考。

理解了客户，就会更容易去在项目里做出适合客户的产品，需求挖掘更充分，同理心去代入客户思考路径里。

比如，客户是一家汽车销售公司，想做VR的项目，方便客户看车…基本诉求就是，能够在网上看车，那就是VR看车，但是我们需要深入思考的是，这样做合适吗？在市场VR设备这么少的情况下，那这时候如果我们想要拿下这个项目那方案和建议就是：

1. 这样的体验一定很好，客户可以看到自己想要的汽车关键信息，未来一定是非常好的；
2. 但是，目前考虑到市面上VR硬件设备相对较少，做VR看车体验的应用，主要适合在展馆上结合附带硬件让客户体验；
3. 使用Web GL和Open GL技术可以实现裸眼AR效果，并且VR制作的模型是可以复用成本整体更低了；可以在微信小程序、浏览器上观看，也可以代入带客户公司常用的APP里，也可以在电脑上网站打开观看，这样用户受众群体就会非常多；

那其实到最后，很可能在VR项目拿下的情况下，还可以多一个AR效果实现或者手机看车的项目，增加了收入，并且即使最终不行，从客户角度去思考，项目带来的好处，并且为客户的客户去思考，某些角度上会让客户觉得我们下了功课，能增加信任感。

5. 出项目方案

1. 定位问题；
2. 明确用户（用户画像）；
3. 识别需求（同理心地图、思维导图、客户目标用户的体验）；
4. 描述问题&需求（解决问题下的功能型需求、设计需求、呈现效果需求等）；
5. 方案构思；
6. 得出多套方案，出多套原型设计，投票（可行性和潜在影响力四象限分析）；

四、后记

今早6:00被猫吵醒了，睡不着，突然灵感迸发，也想起来了刚有个概念的这篇文章，就干脆写写自己的一些思考，生活中就是这么枯燥和随意。

希望对自己工作有帮助，对自己的成长有比较大的帮助，与其说是长篇大论的说写，还不如说是为了自己总结和提升的一个过程，学习-吸收-转化的一个过程，也希望这个理念对大家有帮助。

五、免责说明

本报告仅代表个人观点，数据来源于互联网公开信息，分析结果属于笔者对这个领域的研究，如果有引用在文中会说明，期待和各位交流。

如需私下交流或侵权等问题，请发邮箱：aigbert.li@qq.com，或加微信Aigbert-Aquarius，欢迎各位指正和交流。

作者：LS邋遢道人，资深运营和产品，连续创业者，现任某公司产品负责人，微信公众号：LS邋遢道人

本文由 @LS邋遢道人 原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议