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

8 评论 14939 浏览 131 收藏 12 分钟

经历过4个从零开始到上线的项目,关于项目管理,有一些自己的想法,发现在项目开发时,如果有些问题没有记录清楚,那么以后就真真的有坑。

1. 项目需求

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

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

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

2. 项目时间

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

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

3. 项目开发安排

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

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

4. 项目功能优先级

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

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

5. 关于测试

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

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

6. 人员管理

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

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

7. 需求变更

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

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

以上7点是入行几年来,经历了4个从0开始的项目后的一些总结。只是自己所接触的小公司的情况,没在大公司呆过可能不知道情况,希望大公司的大牛不要喷我。

 

本文由 @土豆叔叔 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 情况都出现过,我外包公司的

    回复
  2. “管件”改成“关键”

    回复
  3. 不是管件

    回复
  4. 既然都说不错,我就收藏了

    回复
  5. 错别字很多,不过都看懂了,非常感谢,写得蛮好

    回复
  6. 写的不错!

    来自浙江 回复
  7. 受教了

    来自广东 回复