行业背景
互联网效率提升已至临界点,短期内效用提升空间有限。互联网的本质是提升效率和效用,效率发展取决于效率差,效用取决于时长和消费能力。行业规模不断增长,产品快速迭代、信息速率提升为企业的协作效率提出了新的挑战。无论企业规模大小,需求管理混乱,代码管理复杂,协作流程冗长等问题至今困扰着这条链路上的所有角色,亟需项目管理工具进行产研提效。
## 行业痛点
-
流程推进困难:多项目并行推进混乱,PMO 一对一私聊进展效率低;相关进展和风险无处暴露,任务负责人不知从何做起。
-
项目管理复杂:上下游信息的不对称性加剧了项目执行的难度,导致相关方对项目背景和理解存在偏差,从而使得整个项目执行的各个环节中断和割裂。
-
复盘无从下手:项目执行过程的关键信息无处沉淀,收尾后没有复盘阶段;无法有效预防项目风险,同样的问题反复出现。
软件研发解决方案价值点
-
独特节点流工作方式,降低任务的颗粒度,将各阶段各角色的任务分工清晰沉淀到流程中,真正做到流程驱动过程,过程反哺流程。通过看板和人力甘特图功能清晰展现每人每日工作详情,效率加倍。
-
将过程交付物沉淀到系统中进行管理,项目收尾阶段对交付物进行统一复盘和迭代;强大的度量功能开箱即用,不需要其他的数据专业团队,飞书项目可以自动将项目数据转化为实时更新的可视化图表,洞察项目执行中的所有风险点。
理念一:流程驱动过程,过程反哺流程
在软件开发行业,一个项目或产品从立项到开发到上线的流程中涉及项目经理、产品、研发、测试、运营、设计等多个角色,每个角色又有几十到几百不等的人员,如此庞大的团队在协作过程中总是存在各种各样的问题:
- 每个人使用的工具不统一,数据无法打通,进度全靠口口相传;
- 流程不清晰,分工不明确,给项目经理的管理带来极大的挑战;
- 项目管理工具的人工操作太多,流程感太强反而降低了团队效率;
1. 减少微观管理,强调 owner 意识
在协作的同时,飞书项目同样也强调激发所有角色及人员的创造性,在飞书项目中,排期的颗粒度是以天为单位——为什么不是小时甚至分钟呢?飞书项目希望管理者能够减少微观的管理,不要试图去控制团队成员的每一分钟时间和每一个细小的 point。相反,任务明确分工后,应该允许每个人有自己独特的拆解和完成方法,这种粗颗粒度的管理方式鼓励每个人去主动思考,沉淀出可复用的 sop。
2. 自定义流程 + 灵活裁剪
流程是整个团队在合作过程中不断磨合的产物,同时,随着人员的调整、目标的变更以及管理理念的发展,流程总不会是一成不变的,在一次次的实践过程中迭代执行流程,使团队合作逐渐变得高效。同时,先进的流程也应该是灵活可调整的流程。相比其他项目管理工具死板的执行,飞书项目还提供了流程裁剪的功能,通过开关、角色轻松的裁剪流程。
场景一:在研发过程中,产品根据用户反馈,发现需要做一个 iOS 适配的功能,那在这个需求中就不需要 Android 端相关的研发、测试人员参与,那可以通过删除这些角色,进而删除相关的开发、测试节点,一个流程适配多种需求。
场景二: 对于某类技术需求,可能只是优化了底层的代码逻辑,不需要 DA 重新进行埋点设计,那可以通过开关来控制「埋点设计」和「AB 方案设计」节点,关闭开关,即可删除这两个节点。
3. 最好的流程是没有流程感
初期为了避免团队协作的不顺畅,便把每个流程节点安排得事无巨细明明白白,期望团队所有人员可以清晰自己的任务,但在实践中我们逐渐发现,当冗余的流程被摆在台面上,就需要人工操作不断的点击完成系统上的每个节点,仿佛给工具配了个工具人,这和飞书项目的初衷背道而驰。好的流程应该是融入到过程当中,激发人的创造性,而不是束缚了人的思考。飞书项目的愿景是希望流程可以驱动成员,通过任务的自动分发,去提醒每个角色需要完成什么任务和交付物,完成后可以自动流转节点,既遵循了对团队来讲最高效的流程,又让每个角色对流程没有感知。
同时,飞书项目有丰富的第三方集成经验,提供全面的 OpenAPI 接口和 WebHook 能力,在内外部都有很多成功的实践。例如,通过平台提供的 GitLab 插件,关联 GitLab 中的代码分支和「飞书项目」中的项目需求。关联后,即可在「飞书项目」中查看需求所关联的代码分支及其状态。同时也可以通过 GitLab 侧 merge request 而推动需求的节点流转。
理念二:上下文清晰可见,上下游信息拉齐
国内外经济学家都在致力于研究如何消除信息不对称的影响,经济学家认为信息不对称问题固然可以让市场参与者去解决,但更多的是要依赖分工和市场。同样,在生活和工作中,我们也在追求信息的对称以谋求平衡的发展。在组织协作中,每个人接收到的信息参差不齐,再加上团队人员的流动,对信息的感知更是相差甚远。上下游的协作者如果对于上下文不够了解,那么信息的不对称必然导致整个项目困难重重。所以,飞书项目支持一键拉起需求群,将相关角色的人员自动拉到群里,需求的全部进展和上下文都会展现在群聊中,即使在执行过程中有新成员的加入,也可以通过爬楼抓取到“原汁原味”的有效信息,而非口口相传的二手消息。
跟踪需求进展是项目经理的日常工作,每日每周统计进展,催负责人进度,这一机械化的重复工作占用了项目经理 80% 的时间,极大的限制了项目经理的思考、创造和生产力。
飞书项目的自动化通知功能解救了项目经理们。有了自动化通知,自动推送需求相关信息——人员变更/节点状态流转/排期变更等。
理念三:数据变身图表,风险无处藏身
运动员在训练过程中除了每次训练的成绩之外,还要记录健康数据、饮食数据等,这些相关数据能够帮助运动员更科学的调整训练计划也能避免训练所带来的风险。同样,对于项目来讲,项目管理工具就像心电图一样,记录着项目执行过程中的所有数据,通过度量功能可以实时检测项目中的各种风险,也可以在项目收尾阶段对项目收益以及过程数据进行复盘,从质量分析、需求效能等角度不断迭代执行的效率。
多视角管理
把控全局的负责人
“只需接收有效信息,做出关键性决策,工具确实改变了我们团队和我的工作方式。”
作为管理者,我一直在思考团队管理的边界感。我之前总是每天被拉进各种会议,丝竹乱耳案牍劳形的日常工作并没有给团队提效,反而所有事情都在拖延等待着我来做决策。于是我们利用工具把协作流程理清,安排每个节点和任务的负责人,给每个成员足够的发挥空间。
我也会通过视图来查看需求的进展情况,飞书项目可以筛选出当前延期的需求,点进详情页可以了解需求的所有信息和延期节点的负责人,点进需求群即可看到延期的原因,如果有疑问也可以直接在群内沟通。
在遇到重大决策时,我们也支持民主讨论,每个人的视角不同,但都可以对需求的决策产生影响。
跟踪全程的项目经理
“社恐福音!再也不用天天花大量的时间私聊小李他们问进展催进度了,省下来的 80% 时间可以好好思考团队如何提效。”
我是一名互联网公司的项目经理小王,两年的 PMO 工作经验,来到公司后发现项目管理制度比较混乱,每个团队每个角色使用的工具不统一,刚来的时候和大家不太熟,研发的人员资历很深,不好意思去催任务,导致需求总是 pending 。使用了飞书项目后,这一切机械化的工作就交给系统代劳了,我最常使用的功能是自动化通知,还可以一键拉群或者绑定现有群,不用一个个往群里拉人,需求进展直接推送到群内。
同时,需求状态的停留时长会直接显示在视图中,发现 block 点直接使用“催一催”功能,机器人直接推送提醒完成节点。
以前项目复盘时,需要导出找交付物、过程数据,从数据收集整理到导入做表需要一个月的时间;现在所有信息都沉淀在系统里,还有开箱即用的图表模板,一键就可以将表格转化成图表,真的太方便了!
聚焦任务的程序员
“上下游信息齐全,跟版需求的状态清晰,每天到工位后打开甘特图即可规划今日工作安排。”
我们的 app 是两周一个版本,每个版本下会拆解很多个跟版需求,产品评审后的需求进入技术评审节点时群内会有自动通知,我们可以清晰地看到并行的二十多个需求的状态、优先级等信息。
在代码平台提交代码成功后,对应的需求开发节点能够自动通过,代码合入后需求上车节点也能自动完成,项目管理工具并没有想象中的会给我的工作带来负担,反而用起来非常流畅。
“养孩子”的运营
“飞书项目绝不仅仅是产研管理工具,运营的日常工作中同样可以使用节点流来管理。”
我是负责用户运营的小吴,开始我们以为这款“产研”工具和我们运营团队没有关系,后来才发现这工具其实啥都能管。打开飞书项目后,我们看到有运营管理的空间模板,便试着用它来收集管理用户声音。
自此,每周的用户反馈都沉淀在系统中,在周会前我们会整理出相关的度量图表,统计用户的使用情况。
同时,和产品的协作也变得更加清晰且可视化,每个月有多少用户反馈,反馈中有多少有价值的需求一目了然。
结语
在项目管理的世界里,没有一套方法或工具可以解决所有问题,但透明的流程、清晰的上下文和数据化的决策,始终是高效团队的共同底色。想了解更多企业如何在不同场景下实现流程优化与交付提效,可以前往飞书项目官网,浏览更多真实的实践案例与经验分享。