学习
实践
活动
专区
工具
TVP
写文章

产品开发 —— 思想 & 价值观

思想 思想源于丰田的生产方式,1996 年 James Womack 和 Daniel Jones 的《思想(Lean Thinking)》一书问世,生产方式由经验变成为理论,新的生产方式正式诞生 思想理念 思想的理念主要包含三部分: 系统思维 大处着眼,小处入手。 价值驱动 增值意义,拉动。 流程速度 增值百分比,效率。 思想的思想体系 思想对生产的思想体系进行了理论升华。 将生产的五大原则升级为思想的五大原则。 1988 年《改变世界的机器》书籍出版,对丰田生产方式和成功进行了全面深刻的分析与总结,丰田生产方式被越来越多的行业和企业所接受和推广。 产品开发是在软件领域发展的主要方式。

41930

产品开发 —— 软件开发 & 产品开发

软件开发 2003 年《软件开发》书籍的问世,标志着理念和实践正式引入软件开发领域,与敏捷软件开发平齐(2001 敏捷宣言),成为新的软件开发方法。 软件开发将生产在制造业的实践映射到软件工程业,并通过类比的方式将生产中的七种浪费与映射到软件开发中的七种浪费。 产品开发 2017 年《产品开发》书籍的问世,从产品角度引入思想和理念,结合产品开发特点和流程,将生产的理念与产品实践进行提炼、适配和优化。 规划需要怎样的数据来验证这一概念; 3. 规划需要构建怎样的最小产品得到数据; 4. 实施后,进入下一循环。 2. 需求分析和管理 解决的问题是如何有效的拆分、规划和沟通需求,确保团队能够一致的理解需求,变因分析和沟通不当而带来的缺陷,并为后面价值小批量的持续流动创造条件。 价值管理闭环: 1.

45310
  • 广告
    关闭

    【限时福利】腾讯云大数据产品,爆品特惠4.5折起!

    移动推送、BI、ES、云数仓Doris、数据湖计算DLC,多款产品助您高效挖掘数据潜力,提升数据生产力!

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    产品开发 —— 丰田生产系统 & 生产

    拉动系统是 1940 年代后期诞生的制造原则的一部分。拉动系统旨在创建一个工作流程,只有在有需求时才会拉动工作。 实施拉动系统的目的是根据实际需求而不是预测来构建产品。 生产 生产源于丰田生产方式,是对丰田生产方式的总结和借鉴。 生产的核心是用最少的工作,创造价值。生产主要来源于丰田生产系统(TPS)的生产哲学。 思想认为产品或服务的价值最终由客户来确定,只有满足客户需求的产品或服务才是有价值的。思想颠覆了传统的大量制造的观念,重新定义了企业原则和价值观。 这样就必须不断地用价值流分析方法找出更隐藏的浪费,作进一步的改进。这样的良性循环成为趋于尽善尽美的过程。

    37520

    也谈“”|洞见

    对大家来说都不陌生了,无论是最开始提取的丰田制造原型,还是后面延伸出来的物流供应链管理,再到近两年颇为流行的创业(Lean Startup),都在不停刷新着“”这个概念。 最近也不乏把当成“热词”来包装的各种理论,以至于很多客户建议我另外给“企业”取个名字。我一般都会礼貌回答说:看看房子(见下图)吧,我们并没有发明什么新东西。 ? 还用思想合适吗?这里我来谈谈自己的理解,抛砖引玉。 这个时候可能会有大牛又跳出来拍一砖:”看吧,还是管理的人不懂!” 那么技术人员真的理解了“小批量”的含义吗?在你的内心深处有理解包括TDD这样的基础技术实践是在践行“小批量”的价值观吗? 什么事情喊口号容易,持之以恒的一万小时是每个希望成为践行者必须经历的磨练。“着眼长远”这一的另一基本原则送给还在坚持的同学们。 ----

    48770

    DevOps 之思维

    ——道格拉斯‧哈伯德 之所以无法衡量,主要的原因是大部分企业所实现的流水线只是一个流程执行的黑匣子,DevOps整个业务链条的过程无法被覆盖,过程数据没有被记录、收集和分析,我们缺乏数据的支撑。 是DevOps的灵魂 “将软件建设的所有环节进行自动化&全面监控”有更重要的任务,那就是通过自动化和全面监控,全面自动记录或收集软件建设过程的数据,这些数据接下来可以发挥巨大的价值——发现持持续交付的过程中 这就是我们所谓的。 通过统一的DevOps平台,对软件建设的过程数据进行收集和监控,然后以直观的看板的形式展现,我们可以更容易发现问题、分析问题、解决问题。 这就是我所理解的DevOps “”思维。 在我规划DevOps产品的时候,我认为是DevOps的灵魂。而大多数的企业和DevOps产品并没有重视“”,我以为我是孤独者。 03 通过收集和监控各个组件、各个过程的执行数据,提供直观的看板进行展示,作为企业持续改进的依据,能帮助企业发现目前项目或研发团队存在的问题,持续改进DevOps团队生产和交付,最大化体现

    49010

    数据驱动进行创业实践

    ---- 1  创业的迭代开发理念 ? 1),创业代表了一种不断形成创新的新方法,提倡企业进行“验证性学习”,先向时常推出极简的原型产品[MVP-minimum viableproduct],然后通过不断试验和学习,以最小的成本和有效的方式验证产品是否符合用户需求 的思维方式把价值定义为“向用户提供利益”,除此之外的任何东西都是浪费。 3),创业团队有2个最重要的假设,分为价值假设和增长假设。       ---- 6 创业的转型类型 1)放大型转型 把产品的某个功能作为产品的全部。 2)缩小型转型 把产品的某个功能作为更大型产品的一项独立功能。 【问题】线上路演功能作为更大产品的一个功能点? ---- 9  开发用户行为数据模块 推荐使用诸葛IO,搭建我们每次转型的核心数据和指标体系,打造我们的用户行为数据体系。 ?

    24620

    数据中台遇到方法

    为什么ThoughtWorks将数据的创新利用和思想关联起来? 我一直挣扎在如何规模化利用数据产生价值,如何在业务价值和IT能力中取得更好的平衡的时候,思想,就像黑暗中的一闪门,徐徐开启,一道光照了进来,给了我启发和方向,众多过去数据项目中正确的经验和失误的教训都一一清晰的和思想关联了起来 将的书和体系很多,我找到一个哥伦比亚大学的原则的报告,一共两页,高度抽象和总结了的原则和思想。附上报告原文 ? 历史 ? 最早被提出来是亨利.福特,他是整合生产过程的第一人。 的思想正式被广泛传播和知晓,是Jim Womack,也就是《思维》的作者。 第一篇以对思想的回顾开始,以此致敬James.P.Womack,让我们从客户价值开始,构建数据中台,打造数据驱动的智能企业。

    41030

    如何建设数据中台:数据创新体系

    本课程结合上一期的案例给大家介绍企业建设数据中台的方法,数据创新体系。 本次腾讯云大学大咖分享课程邀请 腾讯云最具价值专家TVP 史凯 分享关于“如何建设数据中台:数据创新体系”课程的内容。 然后在这基础上,完成进行了一个数据战略的咨询。 那么是怎么来的?这里我就不详细讲了,大家可以去自行去学习的历史,它是来自于生产、制造。 [xqkr0f2bat.png] 那么我们所讲的数据创新体系是什么? 这里我画了两张图来解释数据治理该怎么做?数据怎么做? [0hx4vns42q.png] 数据中台和数据产品交付,时间的关系我就不详细讲了。 这里我们重点把数据智能产品的生命周期快速介绍一下。

    98722

    一步步教你如何入门数据分析

    目录 一、认识数据——产品经理与数据分析 1.1 数据的客观性 1.2 面对数据的智慧 1.3 数据分析中的误区 二、获取数据——产品分析指标和工具 2.1 网站数据指标 2.2 移动应用类数据指标 2.3 电商类数据指标 2.4 UGC类数据指标 三、分析数据——产品数据分析框架 3.1 基本分析方法 3.2 数据分析框架 ——AARRR 3.3 数据分析框架——逻辑分层拆解与漏斗分析 3.4 数据会说谎 四、利用数据——数据驱动产品 4.1 数据应用的场景 4.2 数据驱动产品的方法 4.3 如何培养数据分析能力 正文 一、认识数据——产品经理与数据分析 1.1数据的客观性 数据是量化事物的手段,投射到不同的人身上又会导致解读的结论偏差,因此我能需要“求证”地分析第三方网站提供的调研数据 象限分析 交叉分析法: 案例:多维度的数据分析(ios和安卓下载数分析) ?

    72480

    如何顺利推进生产?

    图片想成功实施生产,就得回到现场,把管理的基础做好。 具体步骤如下所示:1、现场现场改善的方法有很多,比如5S,基础工具的应用、浪费识别、改善提案等方法,经过培训和管理层逐步宣传,可在全厂实施,形成早期改进的氛围。 2、建立价值流操作模式从模范价值出发,逐步推进价值流模式,形成多种价值流管理模式,设置关键绩效指标、单元布局、流动、拉动方式,优化生产计划,建立销售与运作规划(S&OP),问题解决方法的应用等 4、扩展价值流到供应商和客户将模式扩展到供应商,改进和优化整个供应链,继续减少库存。现阶段需要对供应商进行培训,通过项目实施,使供应商真正掌握模式,提高效率,降低成本。 对于已经实施的客户,我们有一种共同的语言,可以优化向上的供应链,而对于尚未实施的客户,我们应该通过来影响他们。

    8630

    竞品分析:什么是画布?(课堂笔记4)

    画布的产生 1.开发原则 丰田生产体系和客户开发法 the Toyota product debelopment system 1、质量就等于效率 2、不靠质量检测来保证质量 3、不以价格来定供应商 有订单再开工 鼓励工人自己解决问题 为客户创造价值 2.方法 Steven Gary Blank 《思步创业法》The Four Steps to the Epiphany 关注价值 减少浪费 以人为本 《制造法 》Eric Ries 商业模式画布 Alexander Osterwalder 画布 Ash Maurya 3.画布是什么? 它来源于丰田生产体系,继承了其关注价值、减少浪费、以人为本的思想,是一种用来组织、梳理、探索商业模式的工具,适用于初创或小规模业务的公司 ---- 三、如何使用画布 1.画布的作用 入门 将模式画布作为一个检查清单来使用 是一种分析产品/公司内外部竞争环境的工具 ?

    96310

    数据分析:对商业模式、创业阶段、数据指标、数据测试方法的数据分析

    本文结合埃里克·莱斯的《数据分析》这本书,结合自我思考,阐述数据分析方法,后续会给出案例进行方法的实践。 1、为什么要进行数据分析? 2、数据分析方法 step1:结合当前的商业模式和创业阶段,选择一个希望改进的KPI,并为该KPI确定一条准绳; step2:找出提升这一KPI的方法; step3:根据实施对数据指标进行测试; step4 移情、黏性、病毒性、营收和规模性等阶段与其他创业倡导者所建议的内容十分相似。 ? 6、数据测试方法——市场细分、同期群分析、A/B测试和多变量分析 测试是数据分析的灵魂。通常,测试就是通过市场细分、同期群分析或A/B测试来比较两个样本的不同。 海盗指标与应跟踪的数据 7.2埃里克莱斯的增长引擎说 在《创业》一书中,埃里克·莱斯提出了驱动创业增长的三大引擎,它们都有各自对应的关键绩效指标(KPI)。

    88350

    敏捷外包开发--- 思维篇

    前言:    本篇主要是在讲述敏捷外包开发, 其背后的主要思维◦ 本文:      许多企业的 IT 部门, 因为人力成本的考量, 同时也为了能拥有更多与更有弹性的人力资源, 而将软件开发与软件测试的工作外包 却往往面临因公司的内部文化上的差异, 而形成许多不必要的沟通, 甚至是不信任◦ 最终, 往往导致企业的IT 部门, 虽拥有成千上百的软件开发与软件测试的外包人员, 却还是无法高效率的交付高质量的产品◦      “敏捷外包开发 甚至是身处于不同办公地点的的外包人员, 均能形成一致的共识, 主动且高效的协作, 而能针对版本质量的现况,, 适时的做出适当的决策, 使产品版本的交付, 能符合高效且高质量的要求◦     所以, “敏捷外包开发 只做单一类型的工作;如: 测试人员只是负责完成测试用例的设计与执行◦ 而是团队中的各个角色, 各个成员, , 共同的参与, 运用集体的智慧, 共同的完成, 产品软件开发过程中的所有事情; 包括: 需求分析 .等等◦ 产品软件的开发, 需能即时反应产品质量的现况:    团队可依产品质量的现况, 做出适当的决策; 如: 依据目前迭代测试的结果, 制订下一轮迭代的迭代计划◦ 结论:       敏捷外包开发的模式

    38960

    敏捷开发: 带病迭代

    前言:    本文主要探讨在敏捷的开发下, 该如何看待与处理所谓的 “带病迭代”? (而不在探讨如何定义带病迭代◦) 本文:    敏捷开发采用迭代的方式进行开发◦许多的团队在这方面往往犯了以下的其中一个错误, 而使得敏捷开发最终以失败收场! 2)     认为迭代是 “带病” 了, 便认为应停止开发下一轮迭代的所有需求, 先将这轮迭代搞 “健康” 了再说◦ 如此的思维, 作法是以 CMMi 的方式在执行敏捷开发;标准的借尸还魂◦最终, 结论:    在敏捷的开发下, 看待与处理所谓的 “带病迭代”, 是期望项目经理需根据: 1)     外部客户, 使用者的变化 2)     产品质量的变化 有智慧的做出正确的 “决策”, “计画 ” 与 “执行’◦ 能拥抱变化, 才是真正的敏捷开发!

    43090

    6种办法实现软件

    最近,我浏览了公司的代码库,发现它有三个版本的仪表板,都是用于分析页面,我很确定客户不需要那样做。这引发了我幼稚脑中的一些事情,我开始在互联网上寻找相关的想法。 就在那时,我发现了这篇古老的论文:“为软件辩护”。 这篇文章提出的观点很大程度上与我共鸣。 六种办法帮助保持软件“” 1. 强类型语言 使用强类型语言有助于以更简单的方式设计复杂系统,它允许编译器精确定位错误和接口,并且可以更自信地使用和更改抽象。 我在某种程度上也不会同意,但不是因为保持软件是错误的,而是因为它很难,尽管如此,我希望在设计系统时牢记这些想法应该可以减少软件的复杂性。

    40110

    敏捷开发: 轻量级度量

    2016, 深圳, Ken Fang  前言:    敏捷开发以轻量级的文档与团队协作, 提高开发的效率。 另一方面, 许多人对于敏捷开发在轻量级的文档下, 如何保证开发的质量存在著许多的质疑与困惑。    本文将从 “度量” 的角度, 运用一轻量级度量的方式, 确保团队在敏捷开发的过程中, 可同时确保效率与质量。 1)      测试用例先行 (流程指标) 敏捷开发, 期望以表格式的测试用例, 使开发人员可清楚的明白到底要开发什么? 结论:   敏捷开发的度量指标主要目的是希望, 项目经理不要再追求浮而不实的表象数据, 而能真正经由轻量级的度量指标, 做好 “数据管理”, 驱动团队去做真正该做的事。

    68180

    扫码关注腾讯云开发者

    领取腾讯云代金券