背景在华为云专家团队拜访某企业时，遇到了这样的一个问题，随着业务的扩张，新员工不断加入，其开发组长要对每一位新人交代相关的知识点、工作方式以及团队信息等，工作量在短期内激增……在一个项目中,随着时间推移、业务的扩张，项目中的核心成员，如项目经理、开发组长等往往都会面临如下几种情况和挑战：新员工加入，需要诸多方面的培养（培训），以便能快速进入工作状态。 老员工的离职，导致项目中缺少能了解和掌握关键技术和业务的人员。员工在工作了一段时间后，对自己的规划有了新的想法，从而想要转换工作方向。那么，项目负责人应该如何应对这些事件呢？问题分析一个项目在从小到大的过程中，项目团队也势必扩张，面临新员工的加入。新员工对刚接触的项目不够熟悉，所以针对新员工的培养（培训）是非常有必要投入人员配置的。项目发展过渡到平稳期的时候，可能会因为公司体质、薪资待遇、员工身心疲惫等原因，出现老员工的离职等情况，如果离职的老员工是核心骨干，就可能导致某些如业务无人知晓、关键技术断层等风险，当然在此期间，也包括老员工随着项目的延续，慢慢产生了对原来工作厌倦，或者因认知的提升以想要寻求一些新的工作内容，进而做了转型的打算。所以上述问题，如果没有得到较好的解决，将会影响到项目的进度和造成不必要的开销，甚至对于团队内部成长、自组织能力的发展建设也是不利的。所以问题的关键，仍旧是新人的培养。解决措施一般来说，在针对新员工加入所带来的内耗、关键核心人员的离职风险、个人发展转型等情况的应对，可以从团队信息、工作方式以及知识管理三方面来通过建立信息管理库进行解决。DevCloud是集华为研发实践、前沿研发理念、先进研发工具为一体的研发云平台（更多了解请见附件或官网），也是笔者目前在使用的。以DevCloud为例，在DevCloud中提供了Wiki服务。Wiki本身是一种以知识库文档为中心，共同创作为手段，依靠众人不断地更新修改为实现的多人协作的工具。我们可以通过Wiki来管理和搭建项目或团队内的信息管理库，以达到有知识点可留存，有基本信息可查的目的，参考如下：团队信息用来记录项目团队的职能划分，职责担当等。当新人入职时，可以通过在Wiki中的团队信息，了解团队的组织分工等。这样一方面可以让新员工对团队人员分工有所了解方便日后的交流，另一方面也能让具备较高能力的新员工根据团队组织分工现状提出改善意见等。工作方式团队需要制定团队内的工作方式，如对开发流程、代码的管理、需求的变更等，团队统一按照要求进行工作。当有新员工加入，可以通过Wiki中的工作方式，了解相关流程等进而快速开展工作，同时也减轻了老员工在工作方式上对新员工的培训所带来的消耗。知识管理知识管理对于项目和团队是最重要的，大部分的产品都需要技术相关的输出整理，无论是基于现有项目进行维护，还是重构，开发新的应用，做知识整理都是不可或缺的。这种必要性在于，当新员工加入后，可以通过知识管理的学习了解项目所用技术框架，进而快速上手工作；当老员工离职，团队因有了Wiki对技术、框架、业务等知识的相关管理，可以较好的应对离职所带来没有backup、没有其他人懂某项技术、没有其他人知道某段业务逻辑等带来的影响；当员工内部转岗或转变业务技术方向时，可以帮助其相关知识，有助于更好的帮助提升跨专业技能。更多关于Wiki的相关内容请参见，参考附录。参考附录Wiki网站:维基百科DevCloud使用指南：DevCloud Wiki使用指南关联文章项目团队人员变动频繁，如何对新人进行有效培养和管理？

背景目前，很多互联网企业越发地注重用户声音。用户声音，也可以说是用户对产品甚至说对企业的期望和认可，对于企业的发展来说起到重要的作用。用户声音往往具有量多、琐碎、突发性强等特点，所以很多企业会涉及到组建专门的客服团队，作为用户和产品研发团队的中间纽带，以适应市场提升产品竞争力。该FAQ主要是解决客服工作管理的问题，客服工作如何开展（例如如何解决客户问题让客户满意之类的问题）不在我们FAQ解答范围内。问题分析众所周知，随着物联网时代的到来，数据正成指数倍增长。据IBM研究，90%的数据来源于最近2年，大数据时代已经到来。在互联网初期阶段，某米公司，正是通过管理和接纳了几百上千的粉丝的声音取得了成功。而现在，人手一部手机，一部手机就可以用来代表一个客户的声音，而且渠道也不再是单一化的，用户声音已然成为一种大数据。用户声音在大数据时代不仅仅是量多，而且是个体化的，正所谓“一万个读者就有一万个哈姆**”，用户声音的复杂程度早已不再是千奇百怪、五花八门能形容的了，此外还有突发性强等特点。能否对用户声音的数据进行有效管理将会成为在大数据时代生存和参与竞争的一项基本能力，这也是对企业提出了很大的挑战。解决方案企业的管理者或项目经理，在规划管理日常用户声音大多采用的流程是，先收集用户的问题，然后整理提交需求，再由研发团队进行新需求的开发或者Bug的修复，最后反馈给用户，形成闭环。根据这个流程，可以从客服团队的工作管理、用户声音的分类管理、产品研发团队的协作三方面来解决客服工作管理的问题。客服团队的工作管理企业的管理者或项目经理可以按照团队规模的大小，以及客服工作量的大小，决定是否安排专职人员做接待用户声音的工作。如果团队规模较大，客服工作量也大的话，需组建专门的客服团队来负责管理客户的声音。反之，可以让一个开发团队的成员兼职做客服工作，一般建议由团队最懂业务的人员。团队组建后，由于用户声音量多、琐碎、突发性强等特点，一般企业或团队会使用项目管理工具进行管理。华为云的DevCloud是基于敏捷思想设计的DevOps工具链（更多了解请见附件或官网），在做关于用户声音的项目管理时，以DevCloud为例。当客服团队有用户声音需要处理时，可以在DevCloud中创建一个看板项目（请见参考附录的《Scrum和看板如何选择》），并为其创建对应的工作项（需求或Bug）。如下图：针对每一个用户声音所创建的工作项，建议从名称能看出来客户来源和主要问题。此外，为了能更加方便的查询，建议也为工作项设置相应的模块和标签，然后通过模块和标签等作为过滤条件快速筛选（见下图：过滤查询），然后跟踪工作项状态，直至用户声音得到解决，工作项关闭为止（更多看板项目的操作请见参考附录中  DevCloud项目管理操作指南）。此外，模块和标签的设置还可以在所有工作项的视图中实现分组的效果（见下图：所有工作项中视图）。更多客服团队基于工作项的配置操作还应按实际情况灵活使用。图：过滤查询图：所有工作项视图用户声音的分类管理一般来说，用户声音根据其特点分为两大类，一类是对于产品的视觉、使用、习惯等方面的建议、投诉、表扬的非实时性的，另一类属于实时性的，即需要马上得到回答和解决。这样分类后可以便于管理，以减少人力提升效能。企业的管理者或项目经理可按情况分别处理，建议如下：非实时性对于非实时性，只需要单向收集客户的反馈就行。对于这种情况，可以通过增加一个渠道，让用户以文字的形式选择相关的分类进行反馈，这样对处理用户声音的工作实效性就没有太高要求。像在DevCloud中通过意见反馈即可进入到意见反馈的页面，然后提出反馈意见，如下图所示：实时性对于实时性的处理用户问题，需要提供实时的客服渠道，首先可以将常见问题及答案提供出来，这样能解决一些共性、常见的用户问题。对于个性化的问题，可以先通过智能机器人问答的形式来处理，即通过用户输入的关键字，智能机器人提供相关的回答，最后是通过提供人工客服的方式，回答用户问题。产品研发团队的协作当客服团队收集到用户声音后，需要将需求或Bug等提交到研发团队，然后上线解决、再通知用户形成闭环。但是由于客服团队和研发团队在一个公司内常常是两个不同的组织，所从属的领导也不是同一个，所以为了避免协作过程中的责任划分不清、踢皮球的情况，建议企业的管理者要因此特性制定好协作的工作方式，让双方都能遵循。在DevCloud中可以通过Wiki来记录规则和说明，如下所示：当用户提出反馈意见或建议后，随着时间的推移，可能会需要主动或被动的给用户以反馈，那么就需要客服团队和研发团队能共享关于该用户声音需求的进展情况，形成双向关联。这样的好处不仅是能做到客服方能跟踪需求掌握进展，还能让研发团队了解到真实场景，更加符合用户的真实需求。在DevCloud中，可以通过工作项中的关联功能实现双向关联。如下图所示：当客服团队在所在项目中（VOC管理）创建完工作项（【传习教育】页面加载较慢）后可以通过关联工作项的功能和开发团队的项目（VOC需求）中工作项（传习教育需求）做关联，见下图：华为DevCloud提供了强大的项目管理和跨团队协作能力，更多功能操作请见参考附录中DevCloud项目管理操作指南。参考附录DevCloud项目管理操作指南Scrum和看板如何选择关联文章在互联网时代，如何有效管理用户声音？

背景目前，Scrum和看板已成为了帮助团队贯彻敏捷的重要方法，我们也能经常看到敏捷爱好者在关于二者在各类社区、场合的讨论。无论是交流分享还是企业的咨询实施，关于Scrum和看板的讨论就一直没有停歇过。那么，对于一个正准备实践敏捷的团队，到底应该如何选择呢？问题分析一般来说，客户会纠结Scrum和看板的选择问题，主要是因为不清楚Scrum和看板方法的区别，不知道哪种更适合目前的项目或团队，也不清楚Scrum和看板方法能应对哪些场景。首先，从Scrum和看板方法的比较来了解两者的不同，见下表：描述Scrum看板方法目的探讨未知，处理新的、复杂项目自我检讨、消除浪费、得到好的效能团队角色产品负责人，Scrum Master，开发团队没有指定的角色度量指标团队速率生产周期、WIP（在制品）多变性承诺在Sprint周期不发生改变变化随时可能发生交付周期固定的Sprint时间盒完成一项工作的时间表： Scrum和看板方法的特征比较如上表所示，Scrum和看板方法在不同方面特征有所不同，企业在选择使用Scrum和看板方法的时候，可以根据上表中二者的特征并结合不同的实际情况，做出选择，具体参考如下情况和详细解释：情况Scrum看板方法团队所做的项目VUCA、需要一定的可预测性√团队优先考虑客户需求的响应能力、经常应对紧急情况改变优先级√项目需要有固定的迭代交付时间（2到4周）√项目的初期探索迎合市场的阶段√团队规模较小（不足5人）或较大(9人以上)√表： Scrum和看板方法的选择情况1：团队所做的项目VUCA、需要一定的可预测性在VUCA（详见参考附录中的解释）的时代，很多团队做的是易变的、不确定的、复杂的、模糊的项目，如互联网项目。针对于这样的特性，团队如果需要在某特定的时间发布或推广产品，以达到一定的市场预期的话。团队一般会将需求进行拆分和细化，如 Epic、 Feature、 User Story 、Task后，制定发布计划。随着拆分为较小的需求后，团队可以通过检查每个Sprint的进度并进行调整，从而预测交付时间，进而确保整个项目成功交付，Scrum是首选的方式。情况2：团队优先考虑客户需求的响应能力、经常应对紧急情况改变优先级Scrum的价值观之一是，承诺在Sprint内对计划不做修改，如果团队经常会应对紧急情况或者修改任务的优先级，那么看板方法因其灵活的工作流程可以更好的适应。情况3：项目需要有固定的交付时间（2到4周）在Scrum中每个Sprint的时间长度是固定（2到4周），并且每个Sprint结束后会交付潜在可交付产品增量，如果项目需要有固定的交付时间（2到4周），那么Scrum是比较好的选择。情况4：项目的初期探索迎合市场阶段以市场为导向的产品，产品越年轻，使用Scrum方式就越可能受益。因为在开发全新产品，尝试实现PMF（产品市场契合）或努力保持产品增长时，通常面临许多未知因素以及大量不确定性和变化。要通过迭代不断的输出增量以获取市场的反馈，进而更快更好的迎合市场的需求，所以Scrum是比较好的选择。（详见参考附录中的Scrum适合你的项目吗？）情况5：团队规模较小（不足5人）或较大（9人以上）Scrum团队理想的规模是2个披萨团队，给出的建议是5到9人，如果团队不足5人，在人员方面可能无法发挥Scrum的最大功效或存在一定上的浪费，那么建议使用看板方法。（Scrum of Scrums 不在此FAQ讨论范围内。）解决措施目前很多企业和团队，都是通过工具在实践Scrum或看板方法，华为云的DevCloud也是基于敏捷思想设计的DevOps工具链（更多了解请见附件或官网），以DevCloud为例，在DevCloud中提供了更加鲜明化的Scrum项目和看板项目的选择，具体可以参考根因分析中针对不同情况选择不同的项目（详见，表： Scrum和看板方法的选择）从目的来说，Scrum主要是为了探讨未知，处理复杂（VUCA）项目从而提升效率，而处理和效率的字眼往往是和时间关联起来的，如要在一个什么样的时间得到什么样的结果，这也是要求了时间把控上或者说做计划的能力，当团队所做的项目为了这样的目的，那肯定是选用Scrum，哪怕团队的规模没有达到Scrum所推荐的5到9人，或者是团队要为估算所浪费的时间开销而苦恼，又或者说在一个Sprint中需求经常变更等情况。因为不管是人数的问题也好、还是估算的问题也好、又或是需求变更的问题都是可以通过团队在回顾中不断的分析、复盘、总结慢慢优化的，如估算问题，那就提高估算能力减少开销；如时间开销问题，可以通过熟练度的提升、形式的改变来较少开销。总之，只要核心是不变的或者说关注点是围绕Scrum目的就应选择Scrum项目，典型项目有：新的应用程序开发、品牌发展、营销活动、具有季度/定时发布时间表的大型企业等。相反，如果团队的关注点就是以优先响应需求的能力，需求是必须要随时跟进和变更的，项目的可预测性、产品市场的契合度等的优先级并没有成为超过响应能力的话，那么看板项目就是一种更好的选择，因为这正是看板方法的优势，让价值能够快速的流动起来，以更快的满足客户的需求，典型项目有：生产支持、补丁发布、UX设计、营销宣传材料、新闻稿等。所以，对Scrum项目和看板项目的选择上，一定参考的是客户认为最重要的关注的点是什么。以目的驱动做响应的选择。另外，在DevCloud的Scrum项目也提供了看板的视图，可以很好的在Scrum的项目中使用看板方法，进而让Scrum可以和看板有效的结合起来，发挥更强大的效能。在DevCloud中， Scrum项目是以Scrum框架为核心的，提供用于处理探讨未知，处理新的、复杂项目的项目类型。Scrum项目提供了类似思维导图的方式，用来整理需求做项目规划，并提供了Epic 、Feature 、Story、Task的四级需求划分，如下图。在Scrum项目中的迭代视图中，未规划工作项相当于 Scrum中的 Product Backlog，当前的迭代相当于Sprint Backlog，可以很好的结合Scrum中Product Backlog和Sprint Backlog两个工件，如下图。Scrum项目提供了通过切换卡片模式转为看板视图，以用来Scrum和看板有效的结合起来，如下图。更多操作和相关内容请见参考附录中DevCloud项目管理用户指南。在DevCloud中，看板项目是以看板方法为核心，为团队提供流程可视化、限制WIP， 加速价值流动，以更快的满足客户的需求，看板项目中提供了非常友好的可视化看板板，默认提供了，新建、进行中、测试中、已关闭等状态列，用来标示任务的状态，可以通过拖拽的方式来实现任务的价值流动。团队在使用看板项目时，还可以修改默认提供的列（修改列名等）和自定义列以实现项目或团队定制化需求。此外，看板项目还提供了很多过滤和显示的快捷和便利操作等。更多操作和相关内容请见参考附录中DevCloud项目管理用户指南。参考附录Scrum适合你的项目吗？DevCloud项目管理用户指南Scrum 指南2007版VUCA 维基百科