经历了4个从0开始的项目，对于项目管理的7个看法

1. 项目需求

在项目立项时，一定要多去问，为什么要做？做的原因有哪些？谁是我们的客户？我们要解决他们什么问题？有没有时间要求等。这些都是这个项目立项的支撑点，如果没有这些支撑点，做出来的东西就不够稳定，经不起推敲的。

如果你是甲方，那么想要产品早早的上线，请一定一定不要相信乙方的项目经理所说的任何保证，除非这家公司你是真知道他的能力。在任何情况下，一定要把你们在会议沟通的任何需求和任何想法记录清楚，形成一份清晰的纪要文档，每次会议一定要有讨论结果和解决方案，切记：一定要有解决方案，问题谁都会找，管件是解决方案。

如果你是乙方，那么想要产品早早的交付，请一定一定不要相信甲方所说的每一句话，甚至是标点符号。甲方每一个人都是患有阶段性失忆症的，而且每一个甲方都是*牛的创意大师。他们的每个想法请不要盲目的答应，一定要考虑考虑再考虑，**是当场能画流程图，草图，确定一切正常时，再确定是否能开发，并记录成纪要文档，并邮件告知项目关联的每个人，尤其是甲乙双发的商务人员和项目干系人员。

2. 项目时间

有很多项目时间就是固定死的，需要把项目反推开发进度，但是也有很多是没有时间要求的，大部分是总监或老板，也有可能是商务直接嘴上说说。这时候的开发就看项目经理的能力了，是否能有效的把控项目的开发进度。

项目时间的评估一般是技术经理，我遇到的技术，在做周期评估时候，大部分的评估内容都是超时的。当然，作为项目管理人员，这个时候就是纯经验了，专业的PMP管理人员，并不适用互联网公司那种机动性较强的开发项目（可能我遇到的PMP管理人员是假的，不展开讨论）大部分互联网项目中，不会有那么多的时间去做评估、记录、方法论。大部分的项目都要求快速上线，时间较为紧张的项目中，一开始就知道了时间的局限性，那么合理安排开发顺序就非常重要了，这个下面再说。

3. 项目开发安排

比较排斥分功能点开发。大项目的开发，大部分是几十个功能一起开发，开发时，尽量一个功能模块由一个人（团队）来做，这时候，一定要经常开会讨论，把各功能模块之间的关联关系说明白，写明白，画明白。不然开发时一定会出现，做出来的东西垮功能时的不适用（也就是Bug多）甚至会出现底层架构设计的错误；

看过一篇文章，里面说过，技术在开发功能时，如果是一个功能比较多的项目，一定要按照严格意义上的功能模块进行分配，何为严格意义上的功能模块，看完之后以我的理解，白话的解释就是一个功能，由某个工程师开发时，他要知道这个功能中包含的东西，就算不是他做的接口，也必须知道里面的业务逻辑。这样，在开发的时候，他可以把整个功能模块的业务全部理清楚，交付给测试后的Bug就会相对比较少，如果出现问题，一个人就可以解决Bug（我相信产品经理一定遇到过一个Bug找不到是哪个技术负责的修改的情况）

4. 项目功能优先级

功能开发时，一定有优先级顺序，工期越紧越要搞清楚优先级顺序，在开发时，一定把遵循，业务级**，功能级第二，统计级第三，页面（显示，UI）级*后的原则，项目的使用是满足业务的，业务能跑通，项目才是正确的，其次是让使用人员用的开心，就属于功能级的事情，减少使用人员的使用次数就是好的功能，越简单越好；

刚入产品经理行业时，根本不知道到底什么是优先级，做的越久越发现，这个问题是真心的不好回答，比如我管理的*早的产品，是一款对C的产品，我们的运营经理三天两头的来找我，要求把某个显示，某个颜色，某个弹框，某个提示语改改，甚至每次开会，提的*多的也是这类问题，这类产品我当时在评估时，**要任是满足功能（某些盈利功能，某些产品代表性功能）其次是交互，好用好玩好看。*后才是用户可能无感的东西做优化。而我现在管理的对B的产品，老板说某客户要加个功能，你看一下。商务说我现在收集发票信息太痛苦了，你给我做个发票管理系统。运营说，我下个月可能要做一波活动，需要一个营销工具，你来看看怎么实现比较合适。你收到此类信息后，发现每个都是比较紧要的事情，怎么破？？**的评估要求就是，那个功能不做你损失**。那个功能做了，对公司贡献**。

5. 关于测试

测试一定要写测试用例，一定要懂项目的业务需要和这个功能的使用场景，测试时尽量能做到角色扮演（把自己当成用户）

曾经看过一篇文章，说张小龙谈论腾讯里面的*厉害的测试，张小龙自己说他要把自己变成一个小白用户需要酝酿很久，而马总（马化腾）只要一个呼吸间就可以把自己变成小白用户。我在要求我的测试的时候，**要务是必须理解里面的业务逻辑，我会把产品设计的想法，场景，用户的要求全部讲出来，告知测试设计的原因，把每个功能点上可能涉及到的东西都会提出来，而测试偶尔提出的问题，我也会在会议中尽心讨论，随时修改或记录。我一直相信产品只是一个人，没有办法把一个逻辑中可以涉及到的方方面面都考虑到，这个时候测试就是产品的一个补漏和补全的作用。测试用例-**版中重要的边界值一定要考虑进去，而为什么说**版只考虑重要的边界值问题呢，因为很多互联网项目中上线都是**位。优化迭代时才需要去考虑各种边界值，容错问题的事项。

6. 人员管理

项目开发过程中，一定存在沟通上的各种问题，小问题，人员自己沟通，大问题，整理成文档，每周做一次总结会议，把所有问题会议上摊开讲，就算是和其他人员没有关系，让其他人员了解一下，有助于对整个系统的了解；

人员才是项目中**的问题，任何一个团队中，只要是人在的地方，就一定会有纠纷和争吵。尤其是在一个项目设计大量的开发人员，需要开发人员之间进行协调时，作为项目管理人员，一定要关注沟通的问题。能由项目牵头沟通的，尽量有一个可以中和的人来去引导整个沟通的过程。如果所沟通问题设计的人员比较多时，建议进行小范围会议来进行头脑风暴形式讨论，并形成会议纪要形式，记录解决方案和讨论内容（解决方案已定要有）很多工程师在解决Bug问题时都会出现抵触情绪，而测试在提出解决方案时的解决一定存在消极怠工的情况。这个时候，项目管理人员在项目后期一定要定期开Bug评审会，评估每一个Bug的优先级，解决方案备注，解决人员的说明，解决时间的去顶等，以Excel的形式在会议结束后邮件发给每一个相关人员。很多时候问题说开了，人与人之间就会很好相处了。项目管理人员切记有团体情况。

7. 需求变更

需求一定是经常变更的，需求变更的事情，大多不是业务层面的，大多是功能层面和使用层面的事情，这类需求变更，成文件形式记录，通报给技术总监和相关技术人员。业务层面变更就要组织相关领导开会确认，之后把变更后的内容告知所有技术人员；

需求变更一般是由甲方提出，甲方包括付钱的，发工资的，商务，业务，运营等。所以这个又老生常谈的问题–需求评估，当然没有谁能一次性把所有的问题想明白。需求变更的产生在产品的生命周期中一定是经常存在的。那么如何避免需求的变更就两个解决方案，一是在需求确立时多搞清楚情况，之前说过就不说了。二是需求管理—任何需求的产品都要文档形式记录，每次需求的结果都要邮件形式告知每一个相关人员，让需求变更人员不要意思提变更，再不济也让他们在提变更时想清楚再提。项目人员在接到需求变更时，又回到第四点说的，优先级，这个需求到底需不需要现在就去改，现在就做，评估清楚再做。