创业公司项目管理中必踩的那些坑 | TAPD经验谈

 导读 

“组织结构混乱”、“团队协作不透明”、“项目交付不及时”、“人员流动性大”……

创业公司成长迅速,业务蓬勃发展,团队不断扩张。这本是令人高兴的事情,却会给团队和项目管理带来不小的挑战。无论你是什么岗位,肯定都有属于你的小烦恼。

本期「TAPD经验谈」pick了创业公司中的敏捷研发管理老司机,有着十年项目管理经验的老司机,某金融科技公司原项目总监 莫敏 ,来给大家介绍他们团队实战过程中的填坑经验。

我叫莫敏,之前是某金融科技公司的项目总监,也是PMO负责人。

从BAT某大厂刚到这家公司时,我曾信心满满,觉得让我大展身手的机会终于来了,毕竟我的项目管理经验也还算丰富,帮新公司提升研发的效率和质量,简直是小case嘛~

却没想到,在创业公司做项目管理,就是一个不断打怪升级的过程,总是会面临接踵而来的挑战,其中也不乏一些难搞的大boss。

 公司进了个BAT出身的COO 

这家公司的研发团队最初是矩阵型组织架构,北京、上海和深圳都有研发部门,分别负责保险、金融和支付三个方面的开发工作,研发管理相互独立。

2016年底,公司引进了一位从BAT大厂来的COO,考虑到当前公司主要问题是欲望大于能力、战线铺得太开,而且资源也在各部门出现不同程度的浪费,业务和资源收缩势在必行。

COO决定使用职能化的组织架构解决这个问题,当然也包括了研发部的调整。

在历时三个月的组织调整后,200多人规模的研发部被调整为两大主线:业务线、基础线,业务线支撑公司业务,包括支付、地推系统和餐饮系统;基础线提供基础研发支撑,包括前端、测试、运维、中间件等。

因为这样一次组织架构的调整,新的问题开始暴露出来:

每个业务线的开发习惯和工具都不统一。

就像一个军团,大家用不一样的枪和弹匣,操练不一样的步伐,你要是调到我的团队,拿了我的配枪都不会用,相互配合起来就特别麻烦。

我想第一步先把大家的规范、流程、工具进行统一,但是业务线项目属于棕地项目(棕地项目,指好几年的老项目),原来的研发的习惯已经养成,要重新适应新的模式会比较困难

这是我第一次觉得事情没那么简单,那段时间,我愁得掉了不少头发。

 小试牛刀:小范围推行协作工具

思来想去,我觉得凡事只要踏出第一步,就会好起来,那么我的第一步应该选择哪个项目呢?

就在我思考这个问题的时候,对敏捷和工具饶有兴趣的小邓同学(Web前端组组长)找到我,说:

“莫老师,你有什么比较好的项目管理工具推荐吗?”

“你先说说,你要解决什么问题?”我饶有兴趣地进行反问。

“我先说说我现在用的工具吧。”小邓同学继续说下去。

“JIRA工具不太好用,不好理解,为什么每次创建都是创建问题,再在里面选任务还是缺陷?”讲到这里,小邓同学有点沮丧。

“你再讲讲你的痛点吧”我继续问道。

“&……%&%&%*&%……%%”小邓同学倒豆子一样把问题说了一大堆。

哈哈,得来全不费功夫。

初步了解一下小邓同学的需求,他希望解决Web前端组面临三大方面的管理问题:

1)缺少一套直观管理工作过程的工具;

2)各项管理制度与流程上的空白;

3)缺乏人员的专业化分工与团队化管理,导致长期松散的“作坊”式结构。

第1项表现得尤为突出,因为眼前的日常工作要持续稳定地开展,长远的建设类工作也需要步步为营地推进。公司突如其来的革新,给小组及受命上任的管理者都带来了很大的挑战。

很长一段时间以来,Web前端组在计划、任务、执行无法得到清晰透明的体现,沟通/协作上也是极其原始低效的方式要维持工作的有序开展,总是异常艰辛。

一套行之有效的研发过程管理协作工具,已显得迫在眉急、刻不容缓。然而尝试过各类工具/平台都不甚理想,总有一种“缺胳膊少腿“的感觉。

难怪小邓同学那段时间总是愁眉苦脸的。

经过研究,我对Web前端组采用了 培训、工具导入、敏捷反馈、持续改进、逐级扩展 的方式,推行TAPD。

一开始用轻量化的前期使用【看板】功能,以月为单位对小组日常工作进行工作任务发布、检查项细化、成员关联、截止日期确定,文件关联,过程跟踪等,以评论进行过程沟通。

持续跟进使用28天之后,团队的习惯已经养成,每个人都会及时去流转自己的工作,团队使用热情高涨。

随着团队规模扩大以及对敏捷知识的了解,项目需要用更复杂的方式进行管理,我们尝试使用了【需求】【任务】,根据小组的特性进行了需求分组,使各种需求与任务有了归类,查看起来更直观。

同时导入了一些敏捷管理的专业知识,利用【甘特图】对资源与事项进展开启了全览视角,可视化使得团队Leader能做到更细致的把控与准确的决策。

后期把【wiki】与【文档】与使用了起来,并且跟各项功能进行关联使用。协作效率得到了质的改变。

几个月后,小邓同学向我反馈:使用以来感觉TAPD各项功能设计有着量身定制般的贴合,之前的困扰均能一一化解它不光是一套工具能解决了现实问题,同时还能带来在协作/敏捷管理上的专业知识,从而提升专业度。

登堂入室:制定研发管理流程

在成功地帮助Web小组导入TAPD之后,我信心倍增,我决定把敏捷项目管理流程和TAPD辐射到更多的团队。

前面提到过的团队痛点:公司一开始也没有固化的项目管理制度与流程,每个团队都用其特有的项目管理方法、流程与工具在做事。

地推系统研发团队使用看板,小伍的团队使用JIRA和WIKI,而测试同学则使用禅道。项目管理水平大部分取决于Leader的个人能力。

所以开发团队会出现一个有趣的现象,开发同学早上在白板旁边开晨会,之后在WIKI里面看产品需求进行开发,然后打开禅道进行缺陷跟进并修复。

 “我的整个人都不好了。”开发同学说。

 “需求能否有个统一的地方安置,我团队的需求我都不好管理。”产品同学说。

“工具能不能别整这个多,切换来切换去,太麻烦了。”测试同学如是说。

在分析了这些痛点之后,我开始针对这些问题做下如下措施:

1)   敏捷与TAPD培训 

实施了敏捷项目管理培训与TAPD使用培训,覆盖了所有产品、研发和运营等相关人员。

2)   制定研发管理流程 

为了使研发部流程清晰、统一、有法可依,我制定了需求工作流,并在TAPD上将自定义流程配置出来,各个环节按照流程自运转。

产品需求管理流程

点击查看大图

需求管理流程主要活动

上下滑动浏览

 1   需求内审

1)需求收集:产品组获取用户需求之后,产品经理与需求提出方进行深入沟通,进一步识别需求,明确需求范围。

2)需求初稿:产品经验内部进行头脑风暴,出交互图,需求细节,定出需求初稿。

3)需求池管理:把需求初稿放入TAPD的需求池,对需求池的需求进行分类,并确定优先级。

P.S.优先级一定是按照业务的运营目标进行排序,保证业务价值最高的需求始终最优先被完成。

 2   需求预审

在TAPD里面对需求进行备注说明,对有疑问的地方提前沟通。提高需求会议的效率,带着问题来做需求澄清。

 3   需求评审

1)召开评审会议:产品经理负责召集所有分析和执行相关干系人参会。

产品阐述需求:产品经理阐述本版本的目标及需求,同时需要估评好此需求的业务价值,其他人员对需求提问。

研发PK需求:始终关注需求业务价值,保证业务价值高的需求排在最优先完成。

分配负责人:会上研发定出针对此需求的研发负责人,如果没有明确负责人,需要挂给研发Leader,会后由他进行分配。

需求定稿:会后产品经理修复需求的问题,邮件发各方进行确认,最终形成需求定稿。

2)模块设计图:研发需要对需求进行简单设计,输出模块设计图。

3)评估工作量:研发与测试分别评估工作量,最终汇总给产品经理,形成项目计划。

4)编写测试用例:测试会后开始编写测试用例。

 4   需求实现

1) 需求实现:需求按照项目计划进行研发,研发Leader把握研发进展,解决技术风险和问题。产品经理关注需求完成的输出点,和最后时间完成点,关注关键路径上的研发过程会导致延期的风险。

2)产品体验:产品经理关注在联调之后的可输出物,在此时间点邀请产品提出方进行产品体验,并整理体验问题,放在TAPD的评论中,推动研发修改体验问题。

3)转测试申请:体验问题修改完成之后,由研发提出转测试申请。

4)版本测试:测试人员开始进行测试,提BUG放在TAPD的【缺陷】模块中跟进,研发进行修复。测试完成在TAPD的【报表】输出测试报告,发文告知此次版本测试是否通过。

 5   需求发布

1)申请上线:产品收到测试报告之后,需要进行验收,根据TAPD输出的【报表】-【验收报告】当中,写明验收的结果,判断这次是否可以申请上线。

2)运维上线:如果可以上线,发起上线流程。上线步骤由测试提供,提交运维操作。

3)灰度发布:根据实际时间进行灰度发布。

4)收集反馈:上线后产品研发测试至少观察三小时数据变化和外部反馈。

 6   需求基线

1)基线管理:产品经理提交所有输出物到指定存放点,并知会配置管理员对其进行基线化操作,配置管理员对所有阶段纳入基线的工作产品进行审计,形成基线管理。

2)项目回顾:项目经理作为流程的执行者,严格遵循此流程进行项目工作推进,每次项目总结的时候,项目组成员都通过回顾过程的方式,来回顾流程当中执行地不到位的地方,持续改进。

因为是集体决议,所以项目组成员都认同并遵守此流程。

有了这些流程之后,大家步伐也一致了,使用了一样的枪支,怎么也像一支统一军纪的正规军了。

自从流程管理在研发部实行之后,我也收到了很多反馈。

改善最明显的前端和测试团队的Leader和我反馈说,他们能够更好地分析资源投入项目当中,原因有二:

1)   每个人团队使用的工具是一致的,人员调用再不需要重新适应新的团队运作模式和工具。

2)   TAPD的成员任务分配能可视化出来每个人的团队投入情况,到项目结束点就可以及时释放出来,资源利用率大大增强。

得到好评的我原以为,自此便可以高枕无忧,顺利走上人生巅峰。

然而,万万没想到,正如约束理论(Theory of Constraints,TOC)所说,解决一个瓶颈,还会出现新的瓶颈,后来陆续又有其他问题浮出水面,这一路似乎非要历经九九八十一难才能取得真经。

唉,说多了都是泪,我得打起精神,继续练功升级去了……

莫敏

某金融科技公司原项目总监

曾任腾讯高级项目经理

有十年项目管理经验

TAPD一站式敏捷研发协作云平台

现已服务数十万创业项目,是美团点评、同程旅游、微众银行、富途证券、每日优鲜等独角兽企业的共同选择。

TAPD为电商&新零售、企业服务、金融、游戏等20多个行业提供专业的解决方案,让创业团队协作更敏捷!

/ 互动时间 /

你在团队协作中有哪些痛点?

在下方评论中告诉我们,

我们将选出三位最走心的小可爱,

送上 腾讯视频VIP月卡1张 

活动截止时间

9月12日23:59

点击阅读原文,提升团队协作效率

原文发布于微信公众号 - TAPD(tapd-tencent)

原文发表时间:2018-09-07

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏Java学习网

技术团队负责人应该具备怎样的能力

技术团队负责人应该具备怎样的能力 正好写2015年终总结,其实今年不太想写的,但是公司层面要求有个人总结要弄,写了个开始就情不自禁多写了一些,谈谈这方面的总结...

3116
来自专栏ytkah

林兴爆料小程序很快可以支持各个 App 直接打开小程序

2132
来自专栏云加头条

崔立鹏:腾讯云为知识竞技游戏提供解决方案

近几个月来,知识竞技类游戏如百万英雄、冲顶大会异军突起。腾讯云率先提供了一站式在线知识竞技的接入方案,并独家提供微信小游戏接入。腾讯云X-P2P产品负责人崔立鹏...

5406
来自专栏新智元

【Google Lens 真正意义】超级通用传感器崛起 :“万亿传感器” IoT 模式被AI彻底改变

【新智元导读】I/O 大会上新推出的 Google Lens 被吴恩达认为是“百度几年前就有了”,但 Computerworld 的专栏作家 Mike Elga...

3314
来自专栏源哥的专栏

程序开发的心理研究

本文只是根据本人的一些经验,还有外界的一些文章,总结出来的程序开发过程中程序员的心理的一些总结,并没有通过严格的验证。

723
来自专栏即时通讯技术

微信七年回顾:历经多少质疑和差评,才配拥有今天的强大

不知不觉,微信已经诞生七年了。 从第一版到现在,微信的演变史,很像一部创业史,很好地诠释了创业者能经得起多少质疑和差评,才配拥有多大的成功。

1271
来自专栏ytkah

微信公众号刷量工具崩溃原来是接口变了

  这两天微信公众号刷点击阅读量的工具崩溃了的消息漫天遍布,原来是腾讯在9月27号晚上将接口key改为了“cookie”,公号刷量工具就不能通过post的方式进...

5328
来自专栏听雨堂

如何评价张小龙在2016微信公开课的演讲

从讲课的角度,毫无疑问这是一堂“糟糕”的课:开场过于紧张、表达生涩、嗯啊等口头语过多、幻灯片配合差、没有互动、没有爆点……如果是我们学校的课前试讲,大概要被老教...

2135
来自专栏PPV课数据科学社区

如何从一开始就设计好数据分析的基本框架

【引子】 Porterfield的最新创业项目是Looker,一个商业数据分析解决方案提供商。主人公在下面这篇文章中向我们讲解创业者们如何可以从一开始就设计好数...

3107
来自专栏nimomeng的自我进阶

《结网》读书笔记

1291

扫码关注云+社区