从自己的从业5年互联网项目说起,分享和沉淀自己对于项目的经验和总结。只是个人班门弄斧一家之谈,如有不同意见,轻拍讨论。
对于笔者经验来说,互联网公司的业务对于开发来说,可以分为两种,一类叫日常,另外一类叫项目。项目就是比较大的一个业务集合,比如上线一套优惠券能力、打通一次支付宝到钉钉的登录、一次退款功能升级等等,日常是相对项目来说的日常维护,比如修复一个页面按钮不能点击的BUG、解决一次下单接口的性能优化。
日常和项目没有明显的边界,一般从业务价值、参与人数、系统复杂度等等方面去分类。总体来说,要达到立项标准,是会投入更多资源。
正常来说,对于内部项目,需要有产品、业务、开发和测试的TL参与,有PD、运营、设计和测试参与。根据项目的大小和情况,可以适当选择参与的范围,比如有些纯后端的项目就不需要设计参会与了,一些后台性质的项目可能也不需要测试参与。但是有个原则,但凡对业务方有影响的,都应该拉会同步沟通,有些无法参会的,可以单独在做沟通或者邮件同步。
对于多方项目,比如多个组织合作,或者是内外部的项目,就需要在内部的几个重要角色基础上,再加上合作方的产品、业务、开发和测试的对标资源,有外部客户的,还要拉上外部客户一起。
有些项目比较复杂,可能需要好几轮沟通才能达成一致,因此可以制定不同的沟通与会圈,比如在项目初期沟通,可以只拉上每个业务的运营或者产品,再多次讨论后,已经确定要落地执行了,再拉着全员一些沟通和需求评审。在PRD评审后,就可以拉着开发来出具体的技术方案和可执行计划。
对于一个项目来说,最重要的就是要明确业务价值和业务目标,简而言之,就是做个项目是为了什么,可以实现一个新的业务上线,引流xx个用户,实现xx的gmv,或者性能优化了xx秒,节省了xx台机器等。
业务价值可以很大,但是业务目标一定是可衡量的,因此下面几个业务目标是有存疑的:
a.这个项目,我们要实现移动端应用启动变快。
–要变多快,目前现状是什么,要达到多少ms的启动,启动变快了对用户的价值是什么?
b.这个项目,预计给我们带来5亿的GMV
–明显的拍脑袋的目标,这个目标如何实现,如何拆解和量化?为什么做了这个项目能实现这个目标?目标是否过于模糊?
对于内部项目来说,即实现业务的是一个团队内部的人,就必须要有一个明确的项目负责人,我们很一般称之为PM,PM的角色可以是专门的职位,比如我所知道的一些证券公司就有项目经理的职位。但是大部分小步快跑的互联网公司为了业务快速发展和节省成本,是没有专门项目项目经理,有的部门会由产品经理或运营来担任,有些偏技术性的项目中,会由程序员开发直接担任。
一般来说,如果是跨团队合作,PM必须有一定的团队间沟通和协调能力;团队内则由内部的骨干来担任即可。
在完成目标对焦和PM指定的情况下,就必须像庖丁解牛一样,对整个项目的具体明细开始拆解,其中包括重要的几个因素:里程碑(重要节点)、项目模块拆解(子项目和子任务)、任务分工和责任人(接口人)。
完成了项目拆解和排期后,就进入严格意义上的开发阶段,此时需要PM来协调资源和保持跟进沟通,同步项目进度和同步项目可预期或者不可预期风险。
一些较为重要的项目可能需要做到一天一同步,可以用群、邮件的方式,快速的收集和整理各个接口人的进度,严格按照时间点、百分比和完成度来对子任务进行标准。把控当前落地和预期的差额,进而分析出项目整体进度和风险。
最终完成项目整理进度-整体风险-明细进度-明细风险等产出报告。
下图是笔者常用的一个项目跟进表:
根据任务的大小,一般普通型项目做到每周五整理更新,然后邮件或用群同步给相关的业务方和领导。
除了PM角色外,很多投入的人就不关注上线后的业务结果了,但是PM还是要对整体结果产出要负责,这里有多方面,一方面是要拿到上线本身的结果,即项目完成并且顺利上线,另外一方面是要拿到项目上线后是否符合或超过预期的效果,比如我们既定的目标。
搞个kickoff,不仅仅形式上的一个需要,也是让整个项目在“仪式感”上有个美好的开头。也是让各方充分get到项目要启动的背景、业务价值和实际的投入。俗话说,完事开头难,既然开头都perfect了,那剩下的就更水到渠成了。
阿里有一些项目取别名的文化传统,比如以前非常知名的”御膳房“、“凌霄”、“飞天”。有些名称和项目几乎没有关联,但是用一个有意思的名词,可以让整个项目灵动起来。
比如取“日进斗金项目”就比“多方结算项目”高大上,取“方舟计划”就比“软件订购交易系统迁移项目”更有意思,取“南天门”就比“统一商品接入后台”要更为优雅。
当然,也要注意命名的一些基本原则,不图花哨,不能有违规,不能低俗恶趣味等。
业务价值、投入资源和人力、有哪些巨大不可控的因素,一定要在项目评审的时候,就说清楚,同步清楚。比如政策性的风险,有些可能或者或多或少的和政府国家政策相违背,比如最近出事的多个P2P贷款项目;还有一些由于leader的kpi还未达成共识的,再畅想业务前景的时候拍胸脯保证,在项目需要投入人力的时候,一声不吭,这种是必须在项目启动前就要同步出来。当然,这种情况需要PM或者业务发起方的准确判断,要提前做好各种上下游以及资源的准备和协同。
对于PM来说,对大里程碑和子任务都必须有一定的掌握,尽管可能PM不一定熟悉某些子任务的具体情况,但是对子任务明细要有一个大致的评估,而不至于失控。另外也要时刻保持警惕状态,审查每个子模块和子任务的进度以及风险,在一定的范围内去做适当的推进。在出现项目节点风险时候,及时和上下游以及老板保持协同,快速减小降低和消灭风险。
一般情况下,推动和完成一个项目只要大家目标一致都比较容易,也能取得比较好的结果。