搜索到
158
篇与
香蕉你个不呐呐
的结果
-
-
-
-
Debian 11 (bullseye) 国内软件源 1．使用说明 一般情况下，将/etc/apt/sources.list文件中Debian默认的软件仓库地址和安全更新仓库地址修改为国内的镜像地址即可，比如将deb.debian.org和security.debian.org改为mirrors.xxx.com，并使用https访问，可使用如下命令：sed -i "s@http://(deb|security).debian.org@https://mirrors.xxx.com@g" /etc/apt/sources.list修改之后再运行apt update更新索引。2．国内常见镜像站点阿里云镜像站deb https://mirrors.aliyun.com/debian/ bullseye main non-free contrib deb-src https://mirrors.aliyun.com/debian/ bullseye main non-free contrib deb https://mirrors.aliyun.com/debian-security/ bullseye-security main deb-src https://mirrors.aliyun.com/debian-security/ bullseye-security main deb https://mirrors.aliyun.com/debian/ bullseye-updates main non-free contrib deb-src https://mirrors.aliyun.com/debian/ bullseye-updates main non-free contrib deb https://mirrors.aliyun.com/debian/ bullseye-backports main non-free contrib deb-src https://mirrors.aliyun.com/debian/ bullseye-backports main non-free contrib腾讯云镜像站deb https://mirrors.tencent.com/debian/ bullseye main non-free contrib deb-src https://mirrors.tencent.com/debian/ bullseye main non-free contrib deb https://mirrors.tencent.com/debian-security/ bullseye-security main deb-src https://mirrors.tencent.com/debian-security/ bullseye-security main deb https://mirrors.tencent.com/debian/ bullseye-updates main non-free contrib deb-src https://mirrors.tencent.com/debian/ bullseye-updates main non-free contrib deb https://mirrors.tencent.com/debian/ bullseye-backports main non-free contrib deb-src https://mirrors.tencent.com/debian/ bullseye-backports main non-free contrib网易镜像站deb https://mirrors.163.com/debian/ bullseye main non-free contrib deb-src https://mirrors.163.com/debian/ bullseye main non-free contrib deb https://mirrors.163.com/debian-security/ bullseye-security main deb-src https://mirrors.163.com/debian-security/ bullseye-security main deb https://mirrors.163.com/debian/ bullseye-updates main non-free contrib deb-src https://mirrors.163.com/debian/ bullseye-updates main non-free contrib deb https://mirrors.163.com/debian/ bullseye-backports main non-free contrib deb-src https://mirrors.163.com/debian/ bullseye-backports main non-free contrib华为镜像站deb https://mirrors.huaweicloud.com/debian/ bullseye main non-free contrib deb-src https://mirrors.huaweicloud.com/debian/ bullseye main non-free contrib deb https://mirrors.huaweicloud.com/debian-security/ bullseye-security main deb-src https://mirrors.huaweicloud.com/debian-security/ bullseye-security main deb https://mirrors.huaweicloud.com/debian/ bullseye-updates main non-free contrib deb-src https://mirrors.huaweicloud.com/debian/ bullseye-updates main non-free contrib deb https://mirrors.huaweicloud.com/debian/ bullseye-backports main non-free contrib deb-src https://mirrors.huaweicloud.com/debian/ bullseye-backports main non-free contrib清华大学镜像站deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye main contrib non-free deb-src https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye main contrib non-free deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye-updates main contrib non-free deb-src https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye-updates main contrib non-free deb https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye-backports main contrib non-free deb-src https://mirrors.tuna.tsinghua.edu.cn/debian/ bullseye-backports main contrib non-free deb https://mirrors.tuna.tsinghua.edu.cn/debian-security bullseye-security main contrib non-free deb-src https://mirrors.tuna.tsinghua.edu.cn/debian-security bullseye-security main contrib non-free中科大镜像站deb https://mirrors.ustc.edu.cn/debian/ bullseye main contrib non-free deb-src https://mirrors.ustc.edu.cn/debian/ bullseye main contrib non-free deb https://mirrors.ustc.edu.cn/debian/ bullseye-updates main contrib non-free deb-src https://mirrors.ustc.edu.cn/debian/ bullseye-updates main contrib non-free deb https://mirrors.ustc.edu.cn/debian/ bullseye-backports main contrib non-free deb-src https://mirrors.ustc.edu.cn/debian/ bullseye-backports main contrib non-free deb https://mirrors.ustc.edu.cn/debian-security/ bullseye-security main contrib non-free deb-src https://mirrors.ustc.edu.cn/debian-security/ bullseye-security main contrib non-freeDebian全球镜像站列表：https://www.debian.org/mirror/list
-
-
-
PMO如何进行合理的绩效考核？ 绩效考核是绩效管理过程中的一种手段。绩效考核是企业绩效管理中的一个环节，常见绩效考核方法包括 BSC、KPI 及 360 度考核等。绩效考核是一项系统工程。目前 PMO 在实际工作中往往承担着项目考核和部门考核的角色，但是对于自身的考核与价值衡量体系还没有完全建立，建议可结合PMO 实际业务特点，根据平衡记分卡从财务、内部流程、客户满意度、员工成长四个方面的进行考核与价值衡量。(1)财务方面通过历史数据可测算出 PMO 管理后项目进度偏差率、成本偏差率，当 PMO 发展相对成熟到控制型阶段，可采用进度偏差率不超过10%、成本偏差率不超过 15%等指标进行考核，便于 PMO 将指标进一步分解到项目进行约束和管理。在财务方面，PMO 的价值主要体现在：通过测算，可计算出项目成本降低与工时节约的额度，成本的降低，项目按时高质量的完成，正是 PMO 控制与管理为公司带来的直接效益。(2)客户满意度可将客户满意度作为 PMO 考核的一个指标，进而将该指标分解到各项目，便于 PMO 在公司内对该指标的统一分解与考核。在提升客户满意度方面，PMO 价值主要体现在：由于 PMO 将项目按照阶段分为售前项目、研发项目、售后服务项目，对项目每一个阶段单独立项与考核，明确了项目的考核标准与成本计量，分工细化有利于为客户提供更加优质高效的服务。同时由于部分项目前期 PMO 顾问对用户进行项目管理的培训，使得客户提前了解项目研发与管理的全貌，有利于加强用户对我们工作的理解与认同感。(3)内部流程方面在内部流程方面，PMO 可设置部门内部的工作规范，尤其是立项、结项管理，规定业务办结时间，如 5 日内完成立项审批、结项审批等，提高办事效率。在内部流程方面，PMO 的价值主要体现在：如通过项目协调会、引进国内外先进管理理念与流程，优化与改进流程节省的质量成本、会议时间、审批时间、返工时间等，通过测算，可得出PMO 在内部流程优化后节约的总成本。(4)员工成长方面员工成长方面，PMO 可把提供内部培训的时间、自身从业人员参加培训的时间、培训满意度等方面作为考核指标。其价值主要体现在：PMO 通过在企业内提供项目管理培训、经验交流会等为企业内部培养了项目经理团队，做好了人才储备，项目经理的能力与管理水平将直接影响项目的成功与否，项目经理梯队的建设为企业关键人才的选、用、育、留建立了良好的机制，为企业可持续发展，起到了重要的作用。 随着项目管理理念的普及，以及各公司对项目管理的日益重视，只要组织选择合适的 PMO 类型、提升 PMO 从业人员自身管理能力与水平、明确其工作职责、不断提升PMO 的价值，高效运行的PMO 不仅会成为组织级项目管理体系建设的执行者，还会成为组织级改革的推动者和公司战略决策的支持者，为公司的运营发展、统一协作创造更多的效益和价值!虽然在 PMO 在实际运营与管理中还存在诸多问题与困境，相信 PMO 人员也会在企业的发展中实现个人发展的双赢!
-
-
受控环境下的项目管理 PRINCE2是什么?PRINCE是PRoject IN Controlled Environment(受控环境下的项目管理)的简称。PRINCE2描述了如何以一种逻辑性的、有组织的方法，按照明确的步骤对项目进行管理。它不是一种工具也不是一种技巧，而是结构化的项目管理流程。这也是为什么它容易被调整和升级，适用于所有类型的项目和情况。PRINCE2 由英国政府商务部(OGC)所有，于1996年开始推广。它不仅是英国事实上所有类型项目的标准程序，现在已迅速发展成为国际标准。世界各地的许多企业将其作为他们管理项目的首选方法。1.为什么要使用项目管理方法?许多项目失败的原因各种各样，其中包括没有充分注意“商业论证”的有效性(为什么要进行该项目)，不重视质量，计划不足，与利益各方缺少沟通，时间与成本通算不正确，缺少监督和控制，职责不明确等等。如果没有一种项目管理方法，委托项目的、管理项目的和参与项目工作的每个人对项目应如何组织、何时应完成都有不同的见解。他们不清楚自己的职责、职权和义务，因此在项目进行过程中一片混乱。而且，如果没有一种项目管理方法，项目很少能按时在预算成本内完成一特别是大项目。一个优秀的项目管理方法一如PRINCE2一将指导项目通过一系列严格控制的、良好管理的、可见性的活动达到项目目标。2.PRINCE2的优势是什么?PRINCE2之所以迅速发展的原因之一是许多企业认识到建立适合自己企业的项目管理标准是一项耗时耗财的工作。他们至少要花费6-12个月、成千上万个工时来建立一套方法，而这只是最初的成本。之后他们必须在内部实施该方法，对参与项目的每一个人员进行培训一这又要花费相同的成本。已获得培训的人员持续前进，当新员工加入时，他们必须对新员工重头培训。采用现有的最佳实践标准，调整使其符合本企业的需要所节约的成本，是十分诱人的。PRINCE2提供一套很容易调整适合客户使用的标准，但更为重要的是按照PRINCE2标准建立了一套成熟的考试机制，使个人能够获得PRINCE2资格证书。目前全世界已有几万人获得PRINCE2从业资格证书(Practitioner Certificate)，从而形成一种良性循环一越多的人参加PRINCE2考试，采用PRINCE2的组织就会有越大的收益;越多的组织采用PRINCE2，希望获得资格证书，使用PRINCE2的人就会越来越多。3.使用PRINCE2的益处是什么?使用PRINCE2有许多好处。它除了可重复使用、可升级、非常灵活之外，是在成百上千名有经验的项目经理们的帮助下，总结他们多年积累的实践经验和专业技术建立的。PRINCE2开发于1989年并从此不断地进行完善。它包含了项目管理领域已经证明的最佳实践，得到广泛的认可和理解，为所有的项目参与者提供了一种共同语言。PRINCE2能使整个项目流程均在有效控制、组织之下，在决策关键点时，予以重新审视项目计划和业务状况，并自动管理和控制对计划的任何偏离，能够对资源进行控制，因此在整个过程中，股东和高级管理者只是在恰当的时机介入项目，而对具体的项目来说，引入PRINCE2还具有许多益处:PRINCE2对每一层极的角色与责任定义明确，又加入了例外管理的形式，减少了不必要的官僚会议;在项目规划方面，PRINCE2从高级长期规划到低级中期，层极明确，同时将项目管理的技术性工作和管理工作进行了区分，职责更清晰;在项目中PRINCE2使所有参与者对项目风险都有了充分的认识;而变革管理的方式帮助管理者减少风险。使用PRI NCE2，项目管理者能够在项目开始前搭建参考标准作为项目启动的先期条件，同时以明确的结构来委任人员、授权以及交流，并且将项目切分为可管理、控制的各个阶段，以便更精确的计划;使用PRINCE2，能够督促各方面人员完成定期的、简短的管理报告，而对于直接应用项目结果的人员，PRINCE2能让他们参加制定所有关于项目的决策，如果这些人员有需要，也可以完全监督项目每天的进展。所以说PRINCE2的引入对于项目的具体实施，对于管理者、实践者而言，都有了更具体的操作、执行指导，在效率方面具有很大的优势。{dotted startColor="#ff6c6c" endColor="#1989fa"/}PRINCE2 2017中文版.pdf 下载隐藏内容，请前往内页查看详情
-
-
-
-
决策：产品经理的取舍之道 本文主要的感悟来源于B端和平台业务，大抵是不适用于所有产品的，尤其是To C的产品或业务。在现实情况下，兼顾业务实现、管理质量、用户体验等多方价值的“完美”产品是很难存在的，由于商业行为天然存在的逐利性，投入产品设计和研发的人员资源总是有限。在B端业务中，由于其目标行业、覆盖场景的范围，因资源问题需要做出的取舍尤其常见。下面展开谈谈常常会遇到的决策场景类型。一、以业务为中心or以用户为中心C端产品更接近日常生活，知名度更广、声量更高，所以市面上大部分产品经理的分享习惯以用户为中心的框架来设计产品，但实际上在2B的业务中，单纯以用户为中心的设计会有诸多不足。产品或者说信息系统有整体性、逻辑性、时效性等特点，得以支持复杂度高、需要多角色协作的业务活动，但其本质仍是解决问题的手段之一。如果在特定场景有更高效率、更低成本的手段能解决问题，产品设计就不是第一优先级的解决方案。所以，产品的第一优先级仍是解决业务问题，而不是用户体验。（仅说明优先级，不是用户体验完全不重要的意思）经常会有同学抱怨，内部系统如OA、财务结算平台、订单管理等怎么怎么难用，体验怎么怎么差。其实究其本质，这些系统的出现不是在满足操作者的使用体验，而都是为管理质量和管理效率服务的。这个就是典型的为业务服务而非为用户（操作者）服务的场景，体现也是B端业务与C端业务主要的区别（B端是客户（付费角色）与用户（使用角色）分离的）。这时候有人会犯嘀咕：“不对啊，我做的业务也是To B的，但是用户使用体验我们也很重视啊”。那基本上就2种可能：用户操作体验已经差到对业务目标流程有阻塞（如成交）或显著的导致成本增加了（如客户咨询量）。业务红海，业务本身已经没东西可以卷了。二、扩展性与过度设计前些年阿里中台带来的中台风潮，一直到今年阿里拆中台的尘埃落定，“中台”这个词或多或少的会出现在产技人的视野里。“中台”本身偏技术概念，产品经理没有这个能力和背景展开，这里要讨论的是伴随“中台”而来的扩展性。扩展性“指一个软件和系统能够让其他程序员在未来能增加新的功能以及修改现有功能，并且新增功能的同时还必须不损害现有系统或软件功能”（wiki释义）。白话点讲，就是当前的设计是否能兼容或者快速适应未来业务的变化。看似是技术同学的工作范畴，但在部分To B复杂业务场景中，花大量时间接触业务方，理解并抽象业务的角色是产品经理。扩展性设计的过程是在抽象业务，抽象程度越高扩展性越强，配置越灵活，但是否抽象程度越高就是越好的设计呢？不尽然。一方面，配置灵活带来的是更高的开发和测试成本，于业务而言，配置的大多数场景可能存在理论里的“伪场景”，所以很大一部分可能是无用的投入。另一方面，越抽象越通用的设计，在一定程度上是“牺牲”业务细节的，进而“牺牲”一部分的业务效率。高扩展性的设计，适用于需要快速试错的业务方向，但对于大多数业务知识相对稳定的场景，需要谨慎权衡，否则可能会因为过度设计，让本不富裕的开发资源雪上加霜。提到抽象设计，这里推荐一本书：《“图解”产品：产品经理业务设计与UML建模》。笔者认为是目前市面上对产品最友好的领域设计和UML建模的工具书，过去DDD（领域驱动设计）的相关书籍和文章主要面向的是开发人员，序言之后很快就进入技术设计层面的讨论，读起来十分痛苦且收获有限，于非技术同学十分不友好。三、长尾需求是否要被满足面向C端的长尾场景做的产商品服务，近些年获得成功的案例屡见不鲜，但面对B端业务的长尾需求，应该是怎样一套决策逻辑？这里总结下笔者的分析链路：长尾需求出现的原因是什么：线下业务不规范？没有引导用户导致的奇异使用姿势？长尾需求是否能通过非产品手段解决？长尾需求是否是阶段性的，是否在未来可能成为主流？是否有其他不可抗力：如大客户需求依赖？政治需求等等面对长尾需求需要谨慎取舍，因为长尾需求很可能一不小心就做成ROI极低的“私人定制”。隐藏内容，请前往内页查看详情
-
过滤需求，给产品做减法 一款好产品，关键是把一个功能做到极致，解决用户的最大痛点。但在现实场景中，往往是随着时间的推移，产品功能变得越发臃肿，最后变成All in one的“超级App”。或许很多时候，产品经理无法决定产品的最终走向。但我认为，只要产品经理还相信产品的力量，可以通过一些方法和技巧，让产品变得更好。比如在设计中做减法，去除一些不必要或不重要的功能和元素，让产品回归本质。本篇内容就具体聊一聊，给产品做减法可以从哪些方向尝试，供大家参考：一、明确产品核心目标首先，明确产品的核心目标和关键价值。了解产品的核心功能和用户需求，确定产品最重要的方面是什么。如果产品只用于解决用户一个核心痛点，该做什么。这将有助于区分关键功能和次要功能，并帮助你决定哪些功能可以被减少或去除。很多目前功能非常强大的App就是非常好地解决了用户一个核心痛点，比如微信的熟人沟通、支付宝的购物付款、小红书的好物种草等。二、制定产品路线图产品整体规划，用于在达成产品核心目标过程中，明确产品落地的节奏，确保每个阶段可以解决一个核心问题。产品规划的明确和共享，有助于管理老板或业务需求，让各方信息同步、行为统一。避免打哪儿指哪儿、看心情加功能的情况出现，降低产品由于缺少计划性变得凌乱、臃肿的风险。三、识别核心功能，去除冗余功能确定产品的核心功能是什么，即最重要、最不可替代的功能。通过专注于核心功能，可以去除其他次要功能，从而简化产品。检查产品功能列表，识别和去除不必要或重复的功能。消除冗余功能可以减少用户的困惑，并提高产品的易用性。四、优先级排序根据产品的核心目标和用户需求，对功能和元素进行优先级排序。将关键功能放在优先考虑的位置，确保产品的核心价值得到满足。次要的或较少使用的功能可以被较低优先级实现或暂时搁置。实操方法包括需求清单、需求分类、需求评审会、需求评分等。目的是确定出需求优先级并让大家达成共识。五、精简用户界面简化用户界面，去除非刚需求频道、复杂的图形元素、按钮和菜单选项。采用更简洁、直观的设计，使用户能够更轻松地理解和使用产品。设计用户界面可以遵循用户体验五要素原则，从战略层、范围层、结构层、框架层、表现层系统化解决体验问题。六、简化工作流程分析产品的工作流程，寻找可以简化或合并的步骤。通过减少用户需要执行的步骤，可以提高产品的效率和易用性。比如在收银台页面默认选中面额最高的优惠券、月底后台系统自动对账等。想实现这点并不容易，需要产品经理深入理解业务，才能设计出更简单、合理的产品流程。七、考虑可配置性为产品添加可配置选项，以便用户根据自己的需求进行个性化设置。比如频道展示样式、系统报告推送时间与表单字段都可以设计为可配置选项。这样一来，用户可以自定义产品以满足其特定需求，而不需要内置所有可能的功能。八、建立成本管理机制成本管理包括六个部分：成本预算、成本计划、成本控制、成本核算、成本统计、成本分析。在产品规划阶段，就需要制定成本计划，并有意识思考成本控制方案。产品、设计、研发每个团队的成本都需要被细分记录，通过成本控制产品边界，聚焦核心问题。写到最后给产品做减法，不是一次性的决策，而是一个持续的过程。需要定期评估产品功能，根据用户需求和市场反馈及时调整，不断优化产品的功能和特性。通过给产品做减法，可以使产品更加专注和精简，提供更好的用户体验和更高的商业价值。美国现代主义建筑大师路德维希·密斯·凡德罗提出过一个经典的设计理念——Less is more（少即是多)。核心思想是以简约精炼代替繁复奢华，但又绝不是简单得像白纸一张。产品思维是透过现象看本质的能力，并通过产品化方案，从根源上解决问题的思维方式。之前的文章，是从需求层面，给大家介绍了获得需求，给产品功能做加法的方法。即，如何贴近用户，获取需求；如何分析需求，将诉求还原为真实需求。但有限的资源无法满足无限的需求，所以，给产品功能做了加法之后，还要收拢需求，给产品做减法。这篇文章，将从产品定位和需求评估层面，看如何给产品功能做减法。一、确定定位，挖掘优势，迭代产品产品定位，我们获得需求后，落地执行前，第一个要考虑因素。只有符合产品定位的需求，产品才具备落地价值。因此，我们也常说：产品定位，指引着产品前进的方向。1. 什么是产品定位产品定位，是用户、需求、场景、边界、优势的合集，它告诉我们产品迭代过程中，要“有所为，有所不为”有明确定位的产品，会规范产品目标，合理地利用有限资源，来实现产品迭代。而一款产品，如果没有定位，只会随着产品功能的迭代，而变得臃肿不堪，最终被市场所淘汰。所以说，产品定位是规范产品在不同时期，为了什么对象，在何种场景下，解决了什么问题，创造了什么价值。2. 如何确定产品定位我们在确定规划产品时，也是从用户、需求、场景出发，但竞品也能够通过对应的方法，挖掘到对应的用户需求。此时，我们就要利用产品定位，来区别于同类产品，突出产品的核心优势。所以，产品定位的确定，要从产品优势出发。下面我将从“点、线、面”的角度介绍下，如何从产品优势出发，并以此确定产品定位：点——功能上，从人无我有，人有我优的角度出发，来确定产品定位；如，QQ音乐和同类产品相比，有版权优势，所以它的定位“千万正版音乐…”也从这个优势入手的。面——生态上，考虑是不是从上下游或与其他产品联动组合的角度，服务于用户的，并以此来确定产品定位；如，微信支付，作为第三方支付工具，就是非常依赖于微信提供的入口，所以产品从生态层面介绍自己是“集成在微信客户端的支付功能”。3. 紧跟产品定位特性产品定位具有三个特性，我们在产品的整个周期，都需要关注着三大特性：① 产品定位可变性不是一成不变的，它会随着产品生命周期的成长、用户边界的扩大，而相应变化的。所以，产品团队要定期思考产品优势、产品困境、产品的生命周期这几个角度，对产品进行综合考虑，并及时调整产品定位；② 产品定位差异性一旦定位明确之后，我们就所有产品功能需求，都要尽可能与产品定位相契合。只有顺从产品定位，利用产品优势，产品功能才有立于市场，不被竞品所模仿和超越的核心竞争力；③ 产品定位指导性要解决的问题太多，可资源是有限的，所以，尽可能保证每个版本只解决一个核心问题，以最大化利用资源。而产品的版本迭代，也遵循产品定位和产品优势，解决当前产品生命周期的最需要被核心的问题，所以说，产品定位对产品进化和迭代具有指导性。二、从必要性出发，选择收益>成本的需求只有落地自己认可的需求，才拥有不断优化产品方案的动力。需求在转化成产品化方案之前，除产品定位之外，还要从必要性、成本、价值等角度，对需求进行再次判断。1. 必要性：一定要落地吗？收到需求后，要先找到第一需求人，从用户、需求、场景这三个角度，全面了解需求。在了解过程中，要带着问题去评估需求：“这个需求，一定要做吗？”只有是自己认可的需求，我们才能够去说服团队，需求是要投入的。而说服自己和团队的最好方式，是通过数据来论证需求因此，我们在了解过程中，还需要思考需求量化的方式。如，功能性体验优化需求，我一般会和客服明确有多少用户投诉，每天有多少用户使用；用户使用过程中每天会浪费用户多少时间，如果有1万个用户使用，那优化1秒后，这一万用户一天能够提升3个小时。2. 成本：考虑实现成本？判断需求是否可行，要从技术和产品角度出发，评估团队成本和用户成本给产品带来的影响，以此来判断需求是否有落地的价值。① 团队成本指在需求上投入的资源，包括人力成本和资金成本这两块。互联网行业，大部分产品都是虚拟产品，因此产品在没有资金成本的情况下，开发人力的投入和开发时间，就是唯一的成本。而在工作中，我们很多需求会受困于技术难点，无法实现预期方案。这时，我们可以通过调整预期上线时间，或增加开发人力，来曲线救国，但效果如果不如预期，就需要重新审视这个需求，是否真的要做。② 用户成本新功能上线，或新版改版，就有可能产生影响到用户使用，导致用户投诉或流失的用户成本。用户的使用习惯是非常强大的，所以，涉及用户使用习惯的调整，要非常谨慎。如，前段时间上线的微信8.0版本，“我的小程序”路径从下拉页面迁移到了右上角“更多”中，从二级页面变成了三级页面，也因此，让很多用户产生了投诉和不满。而这，就是用户成本。但在最新的8.0.2版本，又恢复了原来下拉就出现“我的小程序”模块。这也说明了，微信这种体量的产品，在用户面前，对需求和功能的设置上，必须要更谨慎。3. 价值：需求收益是什么？产品价值是产品的收益，主要从用户价值和商业价值这两个层面，来评估需求落地之后的收益的：① 用户价值看是从能否解决用户问题，能否提高用户使用效率，是评估是否产品价值的首要因素。前端优化、功能需求、提升产品口碑的需求，都属于有用户价值的需求。② 商业价值纯后台需求、数据型需求、效率优化型需求等无法直接触达用户，或用户无明显感知的需求，就需要判断需求，是否具有商业价值。商业价值，则是通过是否“开源”和“节流”来判断的。开源，是从团队或公司角度分析需求，能否赚钱，用户是否愿意为此功能付费；节流，是功能上线后，能节省多少的内部资源或时间。单独的价值和单独的成本，是难以权衡利弊的，只有当收益明显大于成本时，需求才具落地的可能性。三、写在最后产品不可能满足所有用户的所有需求，要合理利用资源，让有限资源优先服务到相对重要的需求中。所以，我们在收到需求后，落地执行前，自己要先评估需求，过滤需求。首先，从产品定位出发，看需求是否符合产品定位，需求能否利用产品优势，为产品添砖加瓦。其次，要从必要性、成本、收益等角度综合评估，当产品具有实现的数据支持，且收益明显大于成本时，需求才有可能落地。
-
-
DFX设计与实现 什么是DFX产品设计需要具有大局观，需要考虑到各方面的需求，任何只考虑单方面的需求，就会造成产品开发的失败。DFX是Design for X(面向产品生命周期各环节的设计)的缩写，其中X代表产品生命周期的某一环节或特性，如可制造性（Ｍ－Manufacturability）、可装配性(A-Assembly)、可靠性(R- Reliability)等。DFX主要包括：可制造性设计DFM: Design for Manufacturability，可装配性设计DFA: Design for Assembly，可靠性设计DFR: Design for Reliability，可服务性设计DFS: Design for Serviceability，可测试性设计DFT: Design for Test，面向环保的设计DFE: Design for Environment等。DFX设计方法是世界上先进的新产品开发技术, 这项技术在欧美大型企业中应用非常广泛, 指在产品开发过程和系统设计时不但要考虑产品的功能和性能要求, 而且要同时考虑产品整个生命周期相关的工程因素，只有具备良好工程特性的产品才是既满足客户需求，又具备良好的质量、可靠性与性价比产品，这样的产品才能在市场得到认可。DFM是DFX中最重要的部分，DFM就是要考虑制造的可能性、高效性和经济性，DFM的目标是在保证产品质量与可靠性的前提下缩短产品开发周期、降低产品成本、提高加工效率。DFX的目的是提倡在产品的前期设计中考虑包括可制造性、可装配性等相关问题。传统的产品开发方法通常是设计—生产制造—销售各个阶段串行完成。由于设计阶段没有全面考虑制造要求，加之设计人员对工艺知识的欠缺，总会造成在产品生产时出现这样那样的问题，如元器件选择不当、PCB设计缺陷等，导致设计方案多次修改、PCB不断改板、生产多次验证等，使得产品开发周期延长、成本增加、质量和可靠性得不到有效保证。DFX基于并行设计的思想，在产品的概念设计和详细设计阶段就综合考虑到制造过程中的工艺要求、测试要求、组装的合理性，同时还考虑到维修要求、售后服务要求、可靠性要求等，通过设计手段保证产品满足成本、性能和质量的要求。尽早发现并解决相关技术问题，优化设计，从而提高产品竞争力；DFX体现了团队合作：由于技术的复杂，产品设计人员需要借助团队中其他专业人员协同设计，在产品需求分析、设计阶段进行充分沟通与交流，使得产品满足DFX的各种要求；DFX不再把设计看成为一个孤立的任务，利用现代化设计工具和DFX分析工具设计具有良好工程特性的产品。DFX带来的价值：企业通过早期进行DFX设计，充分考虑产品生产/制造/销售时候可能存在的问题，减少了产品的返工。通过充分分析客户的需求，可以设计出更简单更可靠的产品，总计起来其主要价值包括：产品设计更改次数少缩短产品开发周期提升产品质量减低产品成本DFX开发流程：在集成产品开发中，其主要流程如下：Charter开发阶段在Charter开发阶段，需要充分识别关键DFX需求，输出DFX需求清单，例如：DFX领域DFX分类DFX描述价值描述优先级开发工作量可服务性可制造性可采购性…DFX是产品包的重要组成部分，一般从质量属性目标、需求基线、设计规范/指南/设计案例等方面进行建设。质量属性目标：指基于客户视角，聚焦重要目标，定量和定性具体要求。是对各领域DFX能力的关键衡量标准，每项是定量或定性的要求，具体体现内外部客户的期望，各DFX质量属性标准必须纳入各产品、平台开发的基本要求中，每个开发版本需要落地关键的DFX质量目标，评估DFX竞争力。质量属性目标主要包括：详细定义（内外部）客户可感知、可验收的DFX要求树立比较基准和标杆，能比较当前差距和改进效果定义标准分级，牵引产品逐步改进需求基线：从设计的角度，明确支撑质量目标达成的设计需求。通常可以将质量属性目标逐个转成DFX需求。需求基线主要包括：1、DFX需求基线是对各领域DFX需求的管理活动2、产品通用的DFX需求整理输出为基线需求，产品绝大部分的DFX需求都来这需求基线3、基线需求也要分级，建议划分为必须支持和建议支持两类4、各DFX需求基线必须纳入各产品包需求；设计规范/指南/设计案例：公司内部设计规范、checklist，指南、案例以及共享平台。设计规范、指南和设计案例主要包括：设计规范：设计规范是该领域在设计时必须遵守的设计原则，是从以往实际工作中提炼和总结出来的。一般有对应的checklist在设计完成后进行自检并在评审时再次检查。设计规范上应该明确各设计应该如何做。各领域应该根据对应的质量标准和需求基线，特别是经验总结，制定各自的设计规范，譬如《xxx结构件设计规范》，《XXX硬件设计规范》《XXX PCB设计规范》等等设计指南：设计指导书是对具体设计方法等的说明。主要是针对不同情形下的推荐设计，并说明为什么要这样设计，供设计人员明白设计原理并选择合适的设计。不同与规范，指导书不是强制要求；各领域可以根据实际情况整理设计指导书，供员工在设计过程中进行学习。如《XXX结构件设计指导书》《XXX产品通用设计指南》设计案例：也可以是经验总结，是在每个产品交付后，组织各部门人员进行的总结；总结在开发过程碰到的关键问题，，每个总结大致包含如下内容：问题单号和问题描述、问题具体表现、问题分析过程、问题是如何解决的/验证结果、经验总结（后续如何避免该类问题）等；根据经验总结，定期组织进行各设计规范、检查checklist刷新。并进行案例评比。概念阶段在概念阶段，需要正式的、完整的进行各领域的DFX需求收集，包括：DFX需求基线库和各领域提出的新DFX需求，经过需求管理评审纳入开发的需求，需要对DFX需求进行充分分解，确保DFX需求能够落地，包括：1，各质量目标从产品层面需要有唯一责任人；2，DFX需求分解到各个领域；4，原则上TR4所有需求要完成开发，并转测试；5，例外情况PDT决策；6，TR4A，TR5，TR6确定需求完成情况，要求100%完成计划和开发阶段计划和设计阶段，基于细分市场评估DFX竞争力，需要定义关键DFX的质量目标，并对DFX需求进行详细设计，整理输出关键DFX设计说明。完成设计后，还需要组织各领域进行评审，确保产品在关键DFX领域有足够的竞争力。还可以设立DFX专项开发，专门进行DFX的优化和设计，并基线化DFX能力，确保DFX工作能够顺利展开。
-
-
-
WBS工作分解结构 一、WBS 工 作 分 解 结 构 的 定 义① Work 工作：可以产生有形结果的工作任务；② Breakdown 分解：是一种逐步细分和分类的层级结构； ③ Structure 结构：按照一定的模式组织各部分WBS 分解步骤：项目→任务→工作→日常活动三、WBS的作用①确定项目范围：明确和准确说明项目的范围；②分配项目工作：为各独立单元分派人员，规定这些人员的相应职责；③预估项目成本：针对各独立单元，进行时间、费用和资源需要量的估算，提高时间、费用和资源估算的准确度；④把控项目进度：为计划、成本、进度计划、质量、安全和费用控制奠定共同基础，确定项目进度测量和控制的基准，确定工作内容和工作顺序；⑤转换项目价值：将项目工作与项目的财务帐目联系起来。四、WBS分解原则①100%原则：100%覆盖项目的可交付物，每一层分解的子任务也要100%覆盖它的父级任务范畴；②元素互斥：WBS结构中各个元素是相互独立不交叉的；③围绕产出：在列举WBS工作包时，要按照期望的产出物计划，而不能只是规划行动事件；④工作包粒度，可交付、可分配、责任到人。五、分解方式①按产品的物理结构分解②按产品或项目的功能分解③按实施过程分解④按项目的地域分布分解⑤按项目的各个目标分解⑥按部门分解⑦按职能分解六、IT项目WBS分解具体步骤①提出需求：获取用户提出需求时的初始需求文档；②需求确认：所有项目参与人员，会议讨论需求，确认所有主要项目工作，确定项目工作分解的方式；③分解项目：如果有现场的模板，应该尽量利用；④Sitemap制作：画出WBS的层次结构图；⑤制作详细WBS：将项目细分，详细到可以对该工作包进行估算（成本和历时）、安排进度、做出预算、分配负责人员或组织单位；⑥WBS审查：验证上述分解的准确性；⑦WBS版本确认：建立一个编号系统；⑧WBS更新：随着其他计划活动的进行，不断地对WBS更新或修正，直到覆盖所有工作。
-
