DevOps 实战笔记
石雪峰
京东商城工程效率专家
37393 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 41 讲
DevOps 实战笔记
15
15
1.0x
00:00/00:00
登录|注册

22 | 产品设计之道:DevOps产品设计的五个层次

多学习基本的设计原则
多跟前端工程师交流
产品终究是给人用的
不要让产品只有专业人士才会使用
站在用户的角度看待问题
领导支持的重要性
资源整合和调动能力
主航道和护城河理论
核心竞争力
产品化的能力
我们的产品的战略定位
产品战略建立在不变的事物上
目标用户和痛点问题的不同导致产品差异
解决特定人在特定场景的特定问题
感知层
角色框架层
资源结构层
能力圈层
战略存在层
产品设计之道:DevOps产品设计的五个层次

该思维导图由 AI 生成,仅供参考

你好,我是石雪峰。
在上一讲中,我们聊到了企业 DevOps 平台建设的三个阶段。那么,一个平台产品到底做到什么样,才算是好的呢?不知道你有没有想过这个问题,反正做产品的这些年来,我一直都在思考这个事儿。直到我听到了梁宁的专栏里面讲到的用户体验的五层要素,才发现,无论什么产品,其实都是为了解决一群特定的人在特定场景的特定问题
那么,回到我们的 DevOps 产品,我们可以借鉴一下梁宁老师的思路,来看看 DevOps 产品设计体验的五个层次:战略存在层、能力圈层、资源结构层、角色框架层和感知层
这么多专有名词一股脑地蹦出来,估计你头都大了吧?没关系,接下来我会逐一解释一下。

第一个层次:战略存在层

在决定开发一个 DevOps 产品的时候,我们首先要回答的根本问题就是,这个产品解决了什么样的痛点问题?换句话说,我们希望用户通过这个产品得到什么?显然,目标用户和痛点问题的不同,会从根本上导致两套 DevOps 产品之间相距甚远。
举个例子,业界很多大公司在内部深耕 DevOps 平台很多年,有非常多很好的实践。但是,当他们准备把这些内部平台对外开放,提供给 C 端用户使用的时候,会发现存在着严重的水土不服问题。
有些时候,内外部产品团队有独立的两套产品,对外提供的产品版本甚至比对内的版本要差上几年。这就是用户群体的不同造成的。C 端用户相对轻量级,需要的功能大多在具体的点上,而企业内部因为多年的积累,有大量的固有流程、系统、规则需要兼顾。所以,整套产品很重,甚至是完全封闭的一套体系,难以跟用户现有的平台进行打通。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

DevOps产品设计的五个层次是产品设计的关键要素,包括战略存在层、能力圈层、资源结构层、角色框架层和感知层。在产品设计中,首先需要明确产品解决的痛点问题和目标用户,以及产品的战略定位。其次,需要将战略目标转化为产品化的能力,明确产品的核心竞争力和边界。同时,要考虑产品的护城河,即产品的不可替代性和接入外部能力的重要性。这些层次的考量将有助于产品设计的全面性和有效性。 资源结构层关注产品的资源优势和整合能力,角色框架层强调站在用户的角度来解决问题,而感知层则强调产品的用户体验和界面设计。这些层次的综合考量将有助于产品设计的全面性和有效性。 在产品设计中,需要考虑产品的资源优势和整合能力,站在用户的角度来解决问题,并关注产品的用户体验和界面设计。这些层次的综合考量将有助于产品设计的全面性和有效性。 总的来说,DevOps产品设计的五个层次为产品设计提供了全面的考量,从战略定位到用户体验,都是关键要素。通过综合考量这些层次,可以有效提升产品的设计质量和用户满意度。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《DevOps 实战笔记》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(5)

  • 最新
  • 精选
  • leslie
    一个好的或者成功的DevOps其实要有全栈的能力:超级全能。突然想起这些年自己的职业DBA&&OPS:产品和研发工作中吵架-自己中间协调完后大家没问题了,开发和运维工作中吵架-中间调节然后问题解决了。换个角度解释一下老师的课程:看看是否有理。 1.DevOps要有全栈经历:整个项目的整体任何环节都大致明白,直接全栈经历过一次;【注:我自己就差不多属于这种;从DEV->DBA->OPS-机房运维】 此处其实是同时需要具备3个视角:用户视角、产品视角、项目视角 2.DevOps要有一些能力:产品设计能力、项目管理能力、研发能力。 作为一个内部项目,各种视角的切换之间才能看见问题,可是很多人不会站在对方的角度去思考问题解决问题。记得苏杰老师的课程中有句话很经典“要想否认别人的创新,你先得证明你的创新”。 学习到现在我觉得我已经不是在学习了:享受学习沟通中的快感。老师提及的不少我都学过了差不多的东西,算是把自己这一年在极客时间学习的一堆课程做了一个梳理。极厚薄发提前规划,等待合适的时候去实现。 谢谢老师的分享:期待下堂课的学习。

    作者回复: 非常赞呀,我给你个建议,可以适当的梳理下自己的逻辑和体系,可以从你的留言中整理出来一条主线,然后试着对外MVP输出看看反响,我觉得很多东西单向输入效果一般,有主动思考能力才是最重要的哈,DevOps不是一家之言,我说的也不一定正确,所以一定要三思而后行,哈哈。 实际上,我目前来看,最欠缺的就是DevOps产品的产品经理,你提到了几种视角,其实代表了几种不同的思维模式,能在不同视角中无缝切换,这不是一句简简单单的话而已,拥有全流程的能力自然有助于你更好的换位思考,但是不知道你还记得前面的加餐里面,关于DevOps工程师的技能章节,我有提到过共情能力,这个才非常重要。

    2019-12-05
    2
    9
  • 雷霹雳的爸爸
    就记得那时候做paas采购选型,灵雀时速之类的,我问你们这流水线里有没有啥自选的审批功能,我们老板比较传统,不自己当看门狗心里不踏实,都告诉我还得定制开发,我想我估计是落伍了,然后偶尔看到好像是叫weaveworks把还是啥的,gitops这玩意儿一下子就惊了,心想我咋就没想到捏,PR一统世界不远了的感觉,算是有过眼前一亮的感觉吧 其他时候大都是眼前一暗,好比说我原来在一个公司用bitbucket,PR的approval可以强制,否则不能合代码,感觉挺好,后来到一个公司图便宜咱弄个 gitlab ce吧,这功能咋也找不到,最后弄半天这得企业版才支持,这里用的社区版,好吧,那commit测试不过总可以吧,发现gitlab社区版也没这个和jenkins结合的功能,还得付费版...这玩意儿看起来有些钱还必须得花...

    作者回复: 其实这个问题也简单,要么投人,要么投时间,要么投钱,比如你说这些PR强制评审的功能,我也见过有的公司自己写Webhook来实现,不通过的话自动强制关闭。随着团队扩大,我越发觉得标准化的研发流程和规范至关重要,小作坊式的开发模式不会长久,对于团队成员尤其是新人来说甚至是一种伤害,所以不要让灵活成为混乱的借口哈,你要想办法说服老板想明白这个道理。

    2019-12-05
    6
  • 小谢同学
    个人觉得在devops领域做商业化变现,很难脱离咨询服务去单独盈利,因为市场上都是一些IT大厂才有能力做出一些具有普适性的工具软件,但企业级客户往往需要从方法论开始逐步渗透(0到1),最终可能工具软件都是添头,反而超强的咨询服务才是大头

    作者回复: 其实这是两个方向,工具最大的价值在于快速规模化,但是问题在于DevOps产品很难一套通吃,这就带来大量定制化的需求,导致无法简单的规模化,而咨询则不同,靠的是人天的投入,又极度依赖于咨询师的经验和能力,所以很难做到规模化,所以对于任何一家咨询公司来说,如何平衡规模化和定制化是个永恒的话题。

    2019-12-18
    1
  • DevOps在路上
    azure devops是我目前问过最好的平台,国内coding很有它的风格。对于企业来说,光靠工具真的不能解决根本效率问题,有工具当然比没有好,但是规则制定,是否愿意遵守,不管测试开发是否都理解devops敏捷的价值
    2021-03-28
    1
    3
  • 程序猿爸爸
    博云Mufan DevOps
    2022-11-21归属地:江苏
收起评论
显示
设置
留言
5
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部