不过 ， 这种方式的实施成本比较高 。 毕竟 ， 这么多关键角色能够在同一时间坐在一起本身就比较困难 。 另外 ， 面对面沟通的时候 ， 为了给对方保留面子 ， 大家多少都会有所保留 ， 这样就会隐藏很多真实的问题 。 所以 ， 一般情况下 ， 像团队内部的敏捷回顾会 ， 或者是版本发布总结会 ， 都是很合适的机会 ， 只需要邀请部分平常不参会的成员就行了 。

• 内部人员走访

如果第一种方式难以开展 ， 我们可以采用第二种方式 。 通常来说 ， 企业内部的 DevOps 转型工作都会有牵头人 ， 同时会成立转型小组 ， 那么可以由这个小组中的成员对软件交付的各个环节的团队进行走访 。 这种方式在时间上是比较灵活的 ， 但对走访人的要求比较高 ， 最好是 DevOps 领域的专家 ， 同时是企业内部的老员工 ， 这样可以跟受访人进行比较深入的交流 。
无论采用哪种方式 ， 我们都需要识别出几个关键问题 ， 缩小谈话范围 ， 尽量做到有效沟通 ， 可通过提前建立一个调研问题列表来达到收集关键信息的目的 。
通过访谈交流 ， 我们就可以对整个软件交付过程有一个全面的认识 ， 并根据交付中的环节、上下游关系、处理时长、识别出来的等待浪费时长等 ， 最终整理出当前部门的价值流交付图 。

文章图片

4、寻找DevOps转型合适的切入点 第一步：寻找合适的试点项目
试点项目是企业内部最初引入DevOps实践并实施改进工作的业务对象 ， 一个合适的项目对于企业积累DevOps实践经验是至关重要的 ， 一般一个合适的项目应该具备以下几个特征：

• 贴近核心业务：DevOps要以业务价值为导向 ， 对于核心业务 ， 管理层的关注度足够高 ， 各项业务指标也相对比较完善 ， 如果改进效果可以通过核心业务指标来呈现 ， 会更有说服力 。 同时 ， 核心业务的资源投入会有长期保障 。 毕竟 ， 我们肯定都不希望DevOps转型落地项目因为业务调整而半途而废 。
• 倾向敏捷业务：敏捷性质的业务需求量和变更都比较频繁 ， 更加容易验证DevOps改造所带来的效果 ， 如果一个业务以稳定为主要诉求 ， 整体处于维护阶段 ， 变更的诉求和意愿都比较低 ， 那么这对于DevOps而言 ， 就不是一个好的选择 。
• 改进意愿优先：如果公司内部的团队认为当前状况一切都非常好 ， 完全瞧不上DevOps ， 觉得自己当前的流程是最完美的 ， 再跟他们费力强调DevOps的价值 ， 结果很可能事倍功半 。 相反 ， 那些目前绩效一般般的团队都有非常强烈的改进诉求 ， 也更加愿意配合转型工作 。 这时 ， 团队的精力就可以聚焦于做事本身 ， 而不会浪费在反复无效的沟通上 。

第二步：寻找团队痛点
找到合适的团队 ， 有了共同改进和意愿 ， 接下来就需要识别团队的痛点了 。 所谓痛点 ， 就是当前最影响团队效率的事情 ， 同时也是改进之后可以产生最大效益的事情 ， 至于如何找寻痛点 ， 我们可以参照上面讲的价值流分析活动 。
第三步：打造可快速成功的改进点
当我们找到了合适的团队 ， 也通过价值流分析识别出了一大堆需要改进的事项 ， 这个时候 ， 一定要注意不要把面铺得太广 ， 把战线拉得太长 ， 这其实是DevOps转型初期最典型的一个坑 。
首先 ， 转型初期一般资源的投入有限 ， 难以支撑大量任务并行 。 其次 ， 由于团队成员之间还没有完全建立起信任关系 ， 那些所谓的最佳实践很容易水土不服 。 如果生搬硬套的话 ， 很可能会导致大量摩擦 ， 从而影响改进效果 。 最后 ， 管理层的耐心也没有想象中那么多 ， 如果迟迟看不到效果 ， 很容易影响后续资源的投入 。