27添加评论分享收藏感谢收起赞同 132 条评论分享收藏感谢收起登录注册最新博客推荐博客全链路项目管理删除起因
互联网的产品有一个特点：快，发展快，消亡快，反馈快，等等。一个产品特性带来的领先优势并不多，竞争对手可很快也可以推出一样的功能。因此，要在竞争中保持优势，就需要持续地推出客户需要的功能，要做到这样，就需要持续选择对的事情，快速地把事情做对。从这个角度来看，我们需要解决的问题就是：如何帮助产品快速地交付价值。这句话有两层含义：第一是价值，高效地完成不应该做的事情没有意义，因此首先要找到有价值的事情。第二才是快，要能快速地把对客户有价值的事物完成，并交付到客户的手上。全链路项目管理要做的事情就是：识别价值，并且让价值更快地在组织内流动起来，尽快地向客户交付价值。要做到这一点，项目经理就应该把视角从研发扩大到整个价值链。
什么事有价值的，这个问题是每个企业在探寻的，在这里，想要讨论的是，在现有人力的情况下，我们如何通过一些方法帮助我们提升识别价值的能力。同时，如何在现有人力的情况下，通过工作模式的调整，让识别出的价值能被更快地创造出来，交付给客户。
什么是商业模式？按照《商业模式新生代》的定义：一个商业模式描述的是一个组织创造、传递以及获得价值的基本原理。
商业模式的核心是价值，按照《精益企业》所说，根据产品所处的不同阶段，把价值的发现过程分成探索和拓展两种，探索新的商业模式和拓展已经验证过的商业模式。这两个过程有着本质的不同，需要不同的组织能力，流程和思维模式。企业一开始通过商业模式创新来探寻新的机会，一旦找了市场匹配点，验证了商业模式之后，接下来就是要对商业模式进行扩展和规模化，想办法降低成本，提高效率，以及提升客户数量和市场占有率。
但是在许多有一定规模的企业里这两种模式是同时存在的，一方面既有的成熟业务支撑了公司的利润；另一方面，为了寻求新的增长点，需要尝试新的业务模式。所以我们需要在探索商业模式和拓展已经验证过的商业模式之间取得平衡，并且能够把业务从探索转移到拓展。
探索商业模式
对于一个新创意，可能最紧迫的就是需要知道我们所设想的这些功能是不是有人要，我们所设想的客户存不存在。这个阶段需要解决的就是商业模式是否有价值，是否具备成长性。
对于价值，我们需要回答的是我们的业务是否能够解决某个问题，对于客户是否有价值。如果是，我们就可以说找到了一个市场匹配点。
对于成长性，我们需要验证的是我们可以多快的获得新用户，是否是一种可重复的、可扩展的销售过程。
验证商业模式是否可行最直接办法就是把产品做出来，按照所设想的方方面面去实践，根据效果来判断是否可行。但是这样做的代价可能太大了，除了时间和金钱成本，最大的成本可能是机会成本。一个产品的成功除了一个有才华的团队以外，我们还应该采用一些科学的方法来提升成功率。
在精益创业中， 我们采用一种系统性的方法，建立“开发-测量-反馈”循环，通过迭代的方式来寻找市场匹配点。首先我们提出一个设想，然后思考如何验证这个设想，接着实现这个设想，通过测量来验证结果，从而来判断设想是否可行，如果可行就进一步强化这个设想，如果不行，就立刻进行调整。精益创业核心在于通过科学的方法识别和验证假设，从而快速对商业模式进行评估。
在《精益创业实战》中，作者列出了三步的解决方案：
1.&&&&&& 把A计划写下来。A计划通常都会失败，但是这是珍贵的灵感。写下来之后，需要描述一下你的设想，这时候通过“商业画布”或“精益画布”来分析你的设想是否可行，但目的并不只是提供最佳解决方案，而是形成一套完整的商业模式，并保证模式中所有元素都能相互配合。
2.&&&&&& 找出计划中风险最高的部分。创业者真正要做的事情就是持续而系统地降低公司的风险。商业画布本身也会随着验证的过程不断调整，这个风险点可能会随着验证的过程，随着商业画布的调整而发生变化。
3.&&&&&& 系统地测试计划。通过客户访谈，针对解决方案进行访谈，MVP，针对MVP进行访谈，验证客户的生命周期等方式，逐步用较小的代价来验证产品的可行性。
商业画布上的商业模式
我们选择用商业画布来做计划A，并且通过不断地迭代来更新这个计划。
商业画布分成9个模块，分别是
1.&&&&&& 客户细分
2.&&&&&& 价值主张
3.&&&&&& 渠道通路
4.&&&&&& 客户关系
5.&&&&&& 收入来源
6.&&&&&& 核心资源
7.&&&&&& 关键业务
8.&&&&&& 重要合作
9.&&&&&& 成本结构
商业画布是一个很好用的商业模式分析工具，以上9个模块就是这个工具的基础模块。不同背景和职责的人，组成一个团队，通过脑暴，用便利贴，共同描绘和讨论一个商业模式中的各个元素。很多在头脑中的设想，可以通过商业画布视觉化出来，同时，不同角色的成员通过商业画布来理解其他成员的想法，并最后达成一致。
最后可能会生成好几个不同的商业画布，这些商业画布上的商业模式可能分别服务于不同的客户，有不同的价值主张，不同的渠道通路等等。
在完成了商业画布之后，可以尝试着来讲解这个商业模式，一方面，向其他人推销你的想法，另外一方面，也可以用来吸引员的注意力。同时讲故事可以让你理顺整个商业模式的思路，并且帮助人们想象未来的场景。
理顺了思路，让其他人了解了我们的商业模式之后，就应该把我们的商业模式放到不同的场景下面去试着去推翻，从而优化我们的商业模式。
场景分为两种：
1.&&&&&& 不同的客户结构。
2.&&&&&& 商业模式未来可能的竞争环境。
在第一种场景下，我们模拟我们不同的客户，它们在使用我们提供的服务或产品的过程是怎样的，他的诉求是什么，痛点是什么，我们的商业模式是否能够满足他的需求，他会从哪里购买我们的服务。
在第二种场景下，我们设想未来行业会怎样发展，会有哪些新的技术趋势和行业趋势，这些趋势可能对我们的商业模式带来怎样不同的场景。我们把商业模式放到不同的场景下，看看是否依然拥有竞争力。
找出你的商业模式中风险最高的部分
新的商业模式需要解决两个问题：风险性和不确定性，这两者最大的区别：是否可预见。准备好了商业画布，我们就需要找出我们的商业模式中风险最高的部分。并且有计划地降低这些风险。
风险的量化方式：首先，确定选择正确并且取得成功的可能性，然后加上选择错误时将会付出的代价。通过这样的方法，排列每一个商业画布中每一个模块的风险优先级。
系统地验证商业模式
设计好了商业模式，排列好了商业模式中风险的优先级，我们就需要进行系统的验证这些商业模式，然后通过验证的结果来调整或者推翻我们的商业模式。
针对商业模式做访谈
做MVP毕竟还是需要投入的，因此，在开始做MVP之前，可以花一点时间针对商业模式做一下验证，找更多的人来帮你完善你的商业模式。比如，找到你定义出来的目标客户，了解下他们对你的价值主张有没有兴趣。
针对价值主张进行访谈
价值主张常常是最大的风险，那就应该首先尝试降低这个风险。那么访谈的主要目的就是依据你的目标客户，找到访谈对象，验证这些价值主张是他们所需要的，切实能够解决他们的问题或痛点，根据他们的反馈来修改和调整价值主张。如果访谈了10个目标客户，他们都不需要先前设定的价值主张，那可能就需要重新调整商业模式或者放弃掉一些商业模式了。
针对解决方案进行访谈
正式做MVP之前，你应该先做一个“Demo”版，以便验证你的解决方案。
验证解决方案
找到访谈的客户，向他展示你的“Demo”，可以是手绘草图，可以是CAD模型，可以是简单的交互图，或者任何足够表达想法的道具。通过讲故事的方式，向客户介绍你的“Demo”，目的就是让被访谈者能够切实体会到产品的使用过程或者了解产品具有的功能。通过这个过程来收集客户的反馈，对产品的功能进行调整，也有可能发现用户不同的需求，或者对用户原有的需求得出不同的结论。在展示的过程中也需要关注被访谈者对于哪个功能比较有兴趣，访谈者也可以进一步讲解一些你认为的亮点功能，看看能否吸引到被访谈者的注意力。
测试产品的价格
还是要了解一下用户原意出多少钱买这个产品。如果直接问客户原意付多少钱，那客户多半会报出一个他认为的相对低价。因此测试产品的价格可以试试用你希望卖的价格来问，这可能是一种不错的找出刚需用户的方法。
解决方案访谈总结
这时候，可能就已经验证了有人对于某个功能是感兴趣的，并且愿意支付一笔你觉得还不错的费用，而这些人可能就会成为你的早期用户。针对价值主张的访谈结果被进一步验证，对于你进一步开始做MVP就更有信心。同时，增加和删除某些功能也更有依据，并且可以适当地根据反馈调整一下价格。
通过MVP做试验
有了前面的验证，就可以开始做MVP了。
MVP应该尽可能地减小范围，目的是减少开发时间，能够用更小的代价更早地开始验证。同时，缩小范围有助于向客户传递你最想传递的价值主张，并且不被其他的东西所干扰。MVP要做的是跨越多个层次的纵切，而不是每次实现一层。
评估MVP的方法很多，但是要谨慎看待一些虚荣指标，比如PV/UV等，这些指标只能告诉你现在咋样，但无法告诉你下一步该做什么。
可以尝试通过用户的生命周期来做周期上每一个环节的漏斗，然后通过划分群组来分析结果。所谓群组，就是有一个相同特征或多个相同特征的一组用户，比如“注册日期”，比如“套餐类型”，“操作系统”等，通过划分群组分析来得到每个群组使用MVP的情况。
针对MVP做访谈
虽然有了实际的线上数据分析结果，但是尽可能也对用户进行访谈来获取用户更详细的使用反馈，看看用户是怎么获取到你的MVP的，在使用MVP的过程中遇到的问题和感受到的特点是什么，用户能否体验到我们想通过MVP所传递的价值主张，客户是否真的原意为你的MVP掏钱。
继续迭代MVP
有了这些反馈，继续迭代和优化MVP，通过重复前面的步骤，继续优化和丰富你的产品，同时不断调整和调整你的商业画布，完善你的商业模式。
拓展经过验证的商业模式
当产品获得了早期用户，并且跨越了鸿沟，吸引到更多的实用主义者的时候，产品的功能不可能再像MVP时候一样专注，无论需求的数量还是团队的规模都会变大，一些在验证商业模式环节还没有设定的岗位也会有新的人员加入，发表意见的人也会变多，团队会开始抱怨不再像原来一样高效，团队成员开始感觉无力，做事情的时候总感觉在被很多人拉扯，大家的方向和目标似乎都不太一致，最后总是要老大出来拍板才能结束。这些都是小问题，更大的问题是，竞争对手进步很快，也在不断扩大市场份额，我们想加快，却不知道要应该在哪里加快。
我们要做的就是尽快调整我们自己。
统一目标和优先级
首先要做的就是让大家有一个统一的优先级，能够按照这个优先级完成所有的任务。
统一需求池
首先需要解决需求源头的优先级，虽然在形成优先级的时候会有争执，但是在形成了优先级之后，大家可以按照讨论好的优先级来工作。
所有角色提需求都先进入需求池，需求池由产品经理负责，统一排定所有需求的优先级，当然产品经理在做这些决策的时候是需要开发，测试和总监等角色的支持的。
设计组织能力
把问题分层，依据不同角色的职责，拥有的信息量，专长的方面，把责任分解到不同层级的组织角色上，同时保证在横向上的同步
战略层：由各部门总监组成，需要解决方向的问题，做出假设，定出优先级，分析反馈结果，最后调整策略。
管理层：由各部门主管组成，需要解决资源分配的问题，依据战略层定下的假设和优先级分配资源，执行验证并收集反馈结果。
执行层：由各个虚拟团队组成，需要解决快速交付的问题，依据管理层分配好的资源和任务，快速地完成任务得到结果，每个虚拟团队组成。
在影响地图上，可以清晰地看到某一个功能，是解决了哪个角色的哪个需求，并且帮助到了我们的什么目标。
影响地图是一个分析的工具，但是在使用了这分析工具之后会带来一系列的好处：
1.&&&&&& 产品的优先级排列更有依据，优先级的排列不再依据功能而是依据要达成的目标
2.&&&&&& 产品的里程碑设定更容易，依据需要完成的功能更容易获得完成的里程碑目标
3.&&&&&& 易于建立“开发-测量-认知”循环，依据目标分解应对策略，根据策略执行结果来判断目标是否达成是否需要调整策略。
当然，影响地图也可以用在商业模式探索的时候，只是在探索的过程中，对于很多需求和角色的认知都还是模糊的，可能不一定能得到很好地效果。所以我比较推荐在拓展阶段使用这个工具。
加速价值流动
整个企业的运作由许多的过程组成，价值经过这些过程，然后交付到用户的手上。我们要做的就是让整个过程加速。
要分析价值流，首先要画出已经存在价值流来描述当前状态。对于产品的交付过程，可能包括销售，市场，运营，交互，视觉，设计，开发，测试，产品，运维，等多个角色。
比如下图是我们常见的产品开发过程：
正常情况下，价值就通过这样的过程流动。但实际情况是：
许多环节都可能发生返工，造成每个环节的浪费，解决的方案通常是增加更多的评审环节：
于是价值的流动路径就变得更长了，可是问题依然没有解决，返工虽然减少了，但是依然存在。我们就需要分析问题在哪里：
所以，要解决这个问题，就需要另外一个逻辑：
那么，我们应该做的就是缩短迭代的周期，让每次交付的内容减少，通过这种方式来减少出错的概率和返工。这样，我们可能就省掉了部分评审时间，可能只需要相关的人员在座位上一起看一下就行了。这样，环节就减少了，价值通过这些环节的速度就变快了。
同时我们需要统计一下每个环节花费的时间：
前面阶段花费的时间比较多，通过减少一些迭代的内容，来缩短整个价值流。
采用敏捷的工作方法
采用Scrum的工作方式
Scrum和Kanban之争也持续了很久，Scrum由于时间盒的存在，必然存在库存，而Kanban由于关注价值的流动，节奏感较弱，所以看起来可能不像Scrum那样有冲刺的效用。笔者还是比较习惯于Scrum，但是Kanban的好处依然需要用起来。
每个Sprint的时间多长，没有具体的定论，按照规范也是1周到4周，但这个也是依据产品类型和团队的情况而定，如果能做到每周上线，那是最好的，但这个也会受到工程工具的影响。
但是，由于存在不同的环节分工和现有的组织构架，完全按照Scrum来落地会遇到困难，所以实际上的工作模式看起来更像是价值流上，每个环节的冲刺，产品经理完成需求阶段Sprint A的处理之后，交互开始Sprint A的处理，然后产品经理开始Sprint B的处理，但是每个环节的Sprint的周期不同：
当产品团队大到一定规模，小团队模式的Scrum就需要扩大成为LeSS，在多个团队之间使用统一的Backlog和统一的Sprint周期，统一排定所有需求的优先级，跨团队协同也通过这张统一的Backlog。
采用DevOps的工程实践
想象一下，如果每个开发人员在软件开发的过程中，能够每天提交一次代码，每次提交代码都经过了UT和静态检查，通过了之后自动部署到测试环境，在测试环境上自动地进行测试，测试通过之后自动部署到生产环境的灰度发布，灰度没有问题之后，自动切换到全量发布。这样每天生产出来的价值都可以很短的时间内交付到客户的手上，同时也能更快地获得反馈。但是要做到这一点需要很大的努力。
1.&&&&&& 自动化测试覆盖率几乎要达到100%，这里的覆盖率指的是需求的覆盖率，不是代码分支的覆盖率
2.&&&&&& UT的覆盖率要达到100%。
a)&&&&&&&& UT是代码的一部分，不是所有代码完成之后才开始写。
b)&&&&&&&& 但是对于Legacy Code，如果不进行重构就要UT覆盖率达到100%，比较容易造成浪费，一方面是为了达到覆盖率UT质量较差，另外一方面，会造成许多难维护的UT代码。
3.&&&&&& 能够自动化部署和回滚。
4.&&&&&& 能够自动化监控和健康检查。
5.&&&&&& 严格的SOA构架，向前 兼容
6.&&&&&& 数据库向前向后兼容
7.&&&&&& 标准化的PaaS或者IaaS，CaaS
完全做到这样，需要很多的条件，但是我们可以通过一个环节接一个环节的完善来趋近于这个目标。
以试验性的方式进行产品开发&&&
产品在拓展阶段，不再需要像在探索阶段一样All in地专注验证，但是通过测试获得反馈的模式依然需要持续下去，不过方式有所转变。这个时候，我们已经有了一定数量的用户。
对原有功能或产品进行优化，有若干个候选方案的时候，可以选择进行A/B测试。花很长时间争论哪个好坏，不如放到线上试试，根据实际的数据结果来判断和选择。
建立反馈循环
《精益创业》提出产品需要建立“开发-测量-反馈”循环。无论是探索还是拓展，都需要建立反馈机制来验证执行的策略是否正确。依据这种反馈来调整策略，通过这种尝试，接着测量反馈，然后调整的策略来找到最合适的策略并执行下去。
建立数据反馈
数据是比较客观的反馈结果，透过数据看到的问题也会更加直接。数据的建立会有许多维度和方法，比如AARRR模型，比如客户生命周期，这些都是很好的参考，重要的是选择适合自己的数据指标。
第一关键指标
第一关键指标，就是一个在当前阶段高于一切、需要集中全部注意力的数字。
数据分析有很多维度，但是有一个数据是最核心的，这个数据真实地反映了当下的战略目标，同时数据结果是能够生成可执行的调整任务的，任何和这个核心数据相违背的策略和做法都应该被避免，要保持这个专注度，第一关键指标（OMTM）就是一个很好的方法。
销售环节的数据
销售环节的数据从一定程度上能够反映销售的产出和市场对于产品的接受程度，比如客户数量的增长率，比如销售额的增长率，比如付费转化率，等等。
市场环节的数据
市场的任务有一部分是无法量化的，比如品牌价值，但是有许多是需要量化的，通过这些量化的指标来判断效果和进行调整。比如：推广渠道的ROI，渠道转化率，渠道引流增长量，渠道引流量占比，等等。
产品研发环节的数据
网易杭研建立自己的核心体系，从用户故事到子任务，通过统计研发过程中的各项数据，来反映从需求到交付的过程中，需求在各个环节的流转情况，通过这些数据统计来发现产品研发过程中的瓶颈，从而进行优化。
建立客户反馈
虽然已经有了数据反馈，但是从客户那里拿到的直接反馈也需要收集，这些都可能会成为我们后续改进的方向。我们要做的就是建立客户反馈的渠道。比如QQ，微信，销售渠道，官网的反馈功能，客户访谈，等等。建立反馈渠道不仅仅是提升客户体验，更重要的是，为我们持续优化自身的产品提供依据。
建立组织的反馈
Scrum中的Retrospective就是通过回顾的方式来调整组织的工作模式，我们应该形成回顾的工作模式，通过5Why的方式来探究问题的根源，通过解决根源问题，来提升组织的协作，形成持续改进的团队文化。
建立调整机制
负责产品战略方向的团队，需要定期地回顾这些数据反馈，客户反馈和组织反馈，通过这些反馈结果及时调整组织的策略，产品的策略，通过建立这样的反馈调整机制，建立一个良性的反馈循环。
虽然在实际的产品开发过程中，未必会按照这些环节顺序，但是根据笔者的观察和实践，不少产品会以不同的顺序和方式完成这些环节。比如，商业模式还没开始设计，销售人员很可能就已经能够带回来客户确切的痛点，并且我们已经有产品满足这样的需求了。因此我们在实际操作的过程中不必原样照搬这些步骤，可以根据自己的实际情况来做。
本文来自网易实践者社区，经作者曹靓授权发布。利用 DevOps Services 开发和管理项目
设置场景MeterPal 是 Phil 领导的一家虚构的创业公司，Phil 与其 5 位大学同学一起启动了一个有资金资助的 Kickstarter
项目，共同开发了一种具有移动和社交功能的新的计时停车方法。他们与 JKE Banking 达成协议，处理他们的微支付交易。作为回报，他们参与
Money that Matters
慈善计划。在有人支付停车计时费用时，他们可将该费用舍入为最接近的美元数，并将这些资金提供给预先选择的慈善机构。Mayor of Innovationville 希望部署他们的智慧计时停车解决方案。Phil 和他的团队受到鼓舞，快速将他们的解决方案投入市场并不断获得了用户。他们选择采用一种敏捷开发流程，Phil 是产品负责人，Sarah
是项目研发管理经理。在过去，该团队主要使用白板和便笺来采集项目信息。他们从未发现采用、安装和配置一个敏捷协作工具来支持其开发的时机。在奥兰多举办的 IBM 技术峰会期间，敏捷教练 (scrum master) Sarah 了解到了
DevOps Services。（参见 ，获取有关 Innovate 和 DevOps Services
的更多信息的链接。）她参加了一次开放的 DevOps Services Live 实验，对该工具的简单性留下了深刻印象。她知道产品负责人 Phil
有点担忧新应用程序的采用，因为 MeterPal 项目的发布日期离现在只有 12 周。Phil
希望在早期冲刺阶段实现尽可能多的商业价值。因此，Sarah 已准备好展示 DevOps Services 中包含的功能如何为协作开发提供支持。DevOps Services
将帮助团队：继续使用 scrum 敏捷实践，因为 DevOps Services 包含一个 scrum 模板来帮助执行敏捷开发灵活地与 Uma（一位有时在家里工作的开发团队成员）合作。云中的一个工具使 Uma 能够与团队协作，甚至在她不在办公室的时候。她能迅速高效工作，因为可以从 Web 浏览器访问基于 Web 的 DevOps Services，无需在本地安装该软件。返回到办公室后，Sarah 说服团队为他们的项目试用 DevOps Services，团队使用 DevOps Services 启动了 MeterPal
项目。创建一个
DevOps Services 项目在项目 MeterPal 的第一次冲刺开始时，Sarah 要求 scrum 团队转到 DevOps Services 并进行注册。（请参见 ，以便获取相关链接。）他们在不到 3
分钟内就完成了任务，因为注册表只需要一个有效的电子邮件地址、一个用户 ID、一个密码和一些基本信息。Sarah 访问 DevOps Services，使用她的帐户登录，并为创建一个项目做好了准备。她输入项目名称
(MeterPal)，将它设置为公开可见状态（公共项目在
DevOps Services 上是免费的），然后选择 scrum 流程。Sarah 还选择了 Jazz 源代码控制选项，因为团队决定将他们的源代码存储在
DevOps Services 云上。图 1. 在 DevOps Services 上创建一个公开的 scrum 项目几秒之后，就已经在云上创建好了 MeterPal 项目。Sarah 邀请其他团队成员立即加入该项目。他们全都收到了 DevOps Services
发来的一封电子邮件通知。通过一次简单的单击，他们就被作为团队成员添加到 MeterPal 项目中。Sarah 立即在 DevOps Services 上创建了 MeterPal 项目。该团队能够通过 Web 浏览器访问一个简单但功能强大的云环境，执行：敏捷项目规划重要阶段、案例和任务跟踪源代码控制配置一个
DevOps Services 项目现在 Sarah 希望在 DevOps Services 上配置 MeterPal 项目。她创建了一个与项目目标一致的时间表（发布计划在 12 周内进行）。Sarah
简单地输入一个项目开始日期，以及冲刺的数量和时长，如图 2 所示。不同的冲刺使用相应的开始和结束日期自动创建。图 2. 在 DevOps Services 上创建冲刺阶段然后，Sarah 为第一次迭代创建一个冲刺订单，她称之为 Sprint 1。您可以注意到，DevOps Services 自动创建了一个产品订单。团队可从其 Web
浏览器查看项目计划，如图 3 所示。图 3. DevOps Services 上的敏捷项目计划Sarah 开始使用 DevOps Services 还不到 10 分钟时间。在此阶段，无需任何进一步配置。云中的 MeterPal
项目已可供团队使用，为他们的敏捷、协作式工作提供支持。云上的上下文中协作借助 DevOps Services 上配置的 MeterPal 项目，产品负责人 Phil 可向产品订单添加新的阶段和案例。团队可执行典型的 scrum
活动，比如订单排序和整理、冲刺规划，或者将案例分解为任务。DevOps Services
还帮助将源代码与计划连接起来。借助这种可跟踪行，很容易理解每个案例的实现过程。图 4. MeterPal 项目的主页开发人员 Darryl 从冲刺订单中获取一个任务。他的目标是为 MeterPal 网站创建一个新页面。Darryl 在 DevOps Services 上打开 Code 选项卡。从他的 Web 浏览器，他创建一个新 HTML
文件，如图 5 所示。DevOps Services 在线编辑器支持 JavaScript、HTML、CSS 或 Java 的开发和语法突出显示功能。Darryl
还使用 Web 编辑器创建一个样式表，但他决定从另一个项目导入一个现有的文件。图 5. DevOps Services 上的源代码编辑器开发人员可以从 Web 浏览器进行工作。如果他们愿意，还可以选择从 Eclipse IDE 进行开发。在 Uma 从家里工作时，她的工作效率不受影响，因为她可远程访问云上的项目。从她的 Web 浏览器，她与团队协作处理案例和任务。Uma
甚至可以从移动设备访问项目信息，当有人在工作项目中提到她时，她会获得电子邮件通知。产品负责人 Phil 最初很不愿意对 MeterPal 项目采用新工具。他的担忧是，团队需要花费太多的时间来学习
DevOps Services，而不是将精力集中在案例实现上。但 Phil 现在可以证明，团队采用 DevOps Services 时的生产力未受影响。而且由于可以从 Web
访问订单，Phil 能够更高效地与利益相关者（甚至是远距离的利益相关者）进行协作。DevOps Services 支持在云上执行上下文中的协作，帮助 MeterPal
团队构建更好的产品。产品信息集中存储并可从实时仪表板访问。人们可开始讨论重要阶段、案例或任务。他们可执行评审和访问实现代码。对于 MeterPal
团队，DevOps Services 环境改善了上市准备速度。结束语MeterPal 的其他团队常常联系 Sarah（敏捷教练）。每个人都听到了 MeterPal 项目对 DevOps Services
的成功使用。没有漫长的学习曲线，没有痛苦的安装和配置。借助它简单的 Web 界面，DevOps Services
支持团队执行任务跟踪、敏捷规划、源代码控制和部署。团队成员可将精力集中在真正重要的事务上：产品开发和交付。而且因为公共项目在 DevOps Services
上是免费的，所以其他许多团队也对采用该工具完成其计划很感兴趣。
相关主题 了解
的更多信息了解 DevOps Services 上的 查阅 DevOps Services 观看 YouTube 上的
或 了解本文中使用的
项目了解 （在奥兰多举办的 IBM 技术峰会）的更多信息。免费加入 ，开始在云中就软件项目展开协作。下载并试用 。它可供多达 10 位开发人员免费使用！浏览 ，以便获得技术资源、最佳实践以及关于针对软件和系统交付的 Rational 协作式和集成式解决方案的信息。
添加或订阅评论，请先或。
有新评论时提醒我
static.content.url=http://www.ibm.com/developerworks/js/artrating/SITE_ID=10Zone=Rational, DevOpsArticleID=1003627ArticleTitle=利用 DevOps Services 开发和管理项目publish-date=