ITPub博客

首页 > 架构设计 > 数据架构 > 多层级多部门的协作项目,还能敏捷起来么?

多层级多部门的协作项目,还能敏捷起来么?

原创 数据架构 作者:DevOps订阅号 时间:2020-07-30 09:18:49 0 删除 编辑


前天中午,王立杰老师(@无敌哥)在IDCF的FDCC认证学员群里抛出了这样一个问题:

某传统企业公司组织架构有很多层级,很多部门协同,把传统项目管理做得很重,很流程。现在涉及跨项目、跨部门、供应商的项目占比超过70%,研发效率低。

面对这样的情况,该如何管理和协同各方?短期该如何做,长期又该如何做?

针对这个问题,群里的小伙伴结合自己的经验展开讨论,一中午的时间里大家聊了超过200条微信消息,我们将本次讨论的部分内容进行了整理,分享给大家。

讨论焦点一:产生这个问题的原因可能有哪些?

1、部门墙导致各方立场不一致,产生推进障碍

多方协同的项目越来越多,且组织层级多,猜测其原因可能是部门墙导致项目中会有太多的声音不好管理,或者可能多方进度不同步,相互成了对方的障碍导致项目难以推进。

2、管理、执行、文化等问题导致好的制度推进不下去

问题可能产生于领导力、团队执行力、团队协作等因素,这些非项目管理能解决。很多团队是制度流程很完善,但团队人员技能遇到瓶颈,或者好的制度流程执行不下去,也没人跟没人管,缺乏监督、缺乏激励、缺乏奖惩,导致恶性循环。

3、上层老板的风格导致的问题

产生这个问题的原因往大了说是老板的风格、目标愿景的导向,企业文化、工作氛围、组织架构设置、分权授权设置是否合理,会不会导致沟通低效、不对称,推进的团队没有权利和推动力,会不会有问题管不了、没人听;往小了说,就是项目本身执行的透明、检视、调整没有做好。很多传统企业都是项目集群管理的壳,敏捷的心。

4、这是长周期项目本身的特性所导致的

长周期项目对供应商或客户依赖太大,需要大量的沟通协调。长周期项目必定离不开项目规划、项目目标、优先级、阶段性,所以很难绕开传统项目管理的影子。一般是内部平台研发或C端采用敏捷,B端交付依旧是瀑布式,瀑布里裹着敏捷,四不像。

长期项目的特点:需求不是连续的,阶段性交付不是均衡的,受制客户或供应商等外部因素很多,变更也很多。如果单独组成独立项目组会导致资源不能合理利用,同样也不利于公司业务平台化架构体系的统一,有可能会产生很多定制个性化。

讨论焦点二:如何诊断具体问题找出原因?

1、定期沟通,过程改进,找出问题

可以先组织各个部门参与定期沟通,过程改进组辅导大家用看板或者其他方式,先确保各项目有优先级,进度可视化,把矛盾和问题暴露出来。而且有了上层的优先排序,下层资源冲突时也可以有参考,辅导方也更容易发现里面隐藏的其他问题,然后再针对更具体的问题进行解决。

2、项目可视化,对照访谈,定位问题

首先需要进行访谈,看是“谁的”“什么问题”,其次用价值流或者其他工具把项目在各部门各个角色的流动画出来,把按角色/部门分的泳道和价值流图结合起来做成一张图,能够清楚地展示项目的现状,尝试找出障碍阻塞,跟访谈结果对照,找到真正的问题。

讨论焦点三:长期/短期有什么能够见效的解决方案?

1、若是偏职能型的组织或以资源为中心的管理团队,这个问题很难根本性解决。若是70%这么高的比例,最好可以整理出一个比较典型的案例来做分析,重新梳理业务,明确如何做到向客户交付路径最短,再根据实际情况调整组织架构。

2、短期来说,可以考虑先选一个项目做试点,尝试项目制管理;长期的话,可以考虑按业务、专长等特性拆分成事业组群进行管理。

3、分类分级分策略,区分重点、非重点,识别各个项目管理的要点。

  • 短期:抓重点项目,职责明确,问题清晰,进展透明;

  • 长期:定制度流程,配QA质量保证,分阶段管理跟踪。

核心是:技术研发类和非技术研发类可以都是项目化管理,但是管理要点、抓手设置是要有区分的。

4、产品研发部分可以采用间断性敏捷方法,排Sprint优先级后,多项目交叉的Sprint切换进行。

5、长期来看,要按照业务做组织改革,跟Spotify里划分tribe类似,尽量把组织解耦;同时仿照类似多级看板的管理流程来管理项目,在不同组织层级对齐不同粒度的项目状态,让项目进展明晰起来。

6、建议短期项目保持,找个长期有价值非高风险的项目做试点,成立虚拟组织,组内拉通绩效,项目群执行的各种敏捷方法跟上慢慢来。

讨论焦点四:长项目周期特性问题该如何解决?

按照一个完整的MVP业务闭环设计方案和迭代,将长周期的项目拆分成小的阶段;短期没有效果的项目可以适当让些资源给短期见效的项目。总之需求部门之间要先通气,统一组织整体的目标,而非各自为战自我消耗。

讨论焦点五:外部因素(供应商)导致的问题该怎么解决?

1、做到可视化,找出等待的原因

经常有开发在等供应商联调,但因为没有透明出来,导致其他项目在等这些开发资源,这就是浪费。其问题在于我们不知道需要等待,如果等待是已知的,那么应该鼓励把等待的任务放到blocker,然后接着做新的任务。所以,不管什么问题,首先还得可视化,才能看到浪费和阻塞,才能说怎么解决。

2、有自己的流程和标准

和供应商一起开发联调,关键自己要有流程和标准,架构自主可控,BA、IA自己设计,共同参与评审。

供应商多,也要约定好接口一个个来,供应商进度跟不上,自己人就先去做其他的,相关功能要么先不上,要么以手动的方式替代,这些只要沟通好还是可以解决的。至于供应商的问题,看如果没有这个功能的话哪个部门最痛,就让哪个部门去推进,供应商肯定也有合同约束的。

讨论焦点六:如何得到上层对改革的支持?

改革自下而上推不动,上层要变革,需要中层有方案、底层可执行。

首先,要让上层老板们觉得这是问题,传统公司基本上是长周期瀑布为主,敏捷只是个装门头的玩意儿。

很多时候执行人员跟老板说有问题,但说服推动的能力欠缺,没有强有力的证据,也没有可靠的建议方案或替代方案,只说问题不说解药,老板无法决策。

改革决策难做,很多时候是卡在不透明,不能暴露真实问题,也有很多时候卡在知道问题在哪里但是没有替代方案。

所以传统管理认为ISO、CMMI、IPD等要求的那些文档,非常重要,做好研发过程的透明化,可视化,让问题真正暴露出来,让上层老板认识到问题的原因,找到证据,是说服老板改革的关键。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31558019/viewspace-2707958/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-10-12

  • 博文量
    61
  • 访问量
    43975