PM也要有春天

PM也要有春天

——啦啦啦，这里的PM是product manager。虽然我已经忘了我们组为什么当初要把产品经理和项目经理分开来，但是既然接锅了，那就干了！

一、没有前言

后端开发框架搭一半，代码打得正嗨，突然锅从天上来，就当上了产品经理。问：此时该如何选择？

A、接着搭后端框架，后端是技术活，后端很重要！
B、赶紧先把用例写了，后端先停一停。。

很遗憾，我选择了A，拖了两周的工期才交付用例，影响了整体的开发进度。正确答案很显然是B，why？软件生命周期就是答案，可行性分析、需求分析、设计、编码、测试、运维，可行性分析完要开始干活了，那么需求分析就是第一步，没有需求分析，后面啥都干不了。作为前导工作，需求分析当然是十分重要的，如果需求分析没做好，就是牵一发而动全身，连锁反应导致后面的工作无法满足客户的需要，简直就是埋下了一颗定时炸弹。

二、如何入手？

废话，当然是先画个用例图或者写个简单的用例文本。先别急，万事不能空想，知己知彼百战不殆，先做个调研吧，先搞清楚"用户需要什么？市场需要什么？同类产品有什么？" ，不能什么都做，那就确定业务范围；不可能在一次迭代中完成所有的内容，那就需要分个先后，根据业务流程，将重要的、前导的业务先完成，每次迭代完成一部分业务。之后，再开始画用例图，写用例文本，画活动图，领域建模，功能建模，这些该怎么做，相信大家都懂的，不懂就去看书、看课程网站、百度！

三、放弃绝对完美，追求相对完美

进行需求分析的时候，如果一次就能做到十全十美，那还需要迭代做什么？直接贯彻瀑布模型从头到尾走一遭就好了呗。放弃在一次迭代中做到十全十美，而是尽可能地做到十全九美，然后及时交付给设计，先做到了，然后再根据用户的需求变更以及设计、编码、测试过程中的反馈，在下一次迭代中补足那10%的缺陷，才能提高效率。所以，要及时对需求规格文档进行更新，不断地进行优化，为下一次迭代做准备。当然，如何是在设计阶段出现了歧义，与产品经理讨论后，是可以及时进行修改的，如果进入到了编码阶段发现需求的不足，那就暂时留着不足吧。

四、沟通很重要

从本质上来说，需求规格书中不论是文字还是图表，都是一种沟通方式，都是要把产品经理的对业务的建模表达出来，既然是一种沟通方式，那就存在"噪音"，导致信息不能正确传达。如何避免噪音呢？在我看来可以通过如下方式：
1. 制作一个词汇表，对项目中的一些专有名词进行解释，规范项目中一些专有名词的使用，避免误解和误用。
2. 考虑用英文，中文博大精深，有些意思可能传达得不会那么准确，但是英文就相对比较严谨。或者是多进行一些解释说明。
3. 图表制作要规范，必要的文字说明不能少
4. 对需求规格书进行统一的说明和解答，虽然比较费力，但是我们的实践证明效果还是不错的，并且大家提出了不少需求用例中不合理的内容，有助于我的改进。