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

2019-03-18
333

1. 项目需求

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

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

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

2. 项目时间

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

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

3. 项目开发安排

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

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

4. 项目功能优先级

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

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

5. 关于测试

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

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

6. 人员管理

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

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

7. 需求变更

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

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


ຂຽນຄວາມເຫັນຂອງທ່ານ