Page tree
Skip to end of metadata
Go to start of metadata

 

 

mgm技术合作伙伴简介

Mgm是一家中等规模的软件解决方案公司,它是通过帮助其客户取得商业成功而获得自身的成功。创建于1994年的Mgm位于慕尼黑,在全欧洲有大约300个雇员。

Alexander Weiss自从2005年从Bugzilla迁移到JIRA开始就在这家公司工作——在一个客户网站使用JIRA以后,他倡导在公司内部采用JIRA。Mgm技术合作伙伴使用JIRA、GreenHopper、Confluence,而且最近购买了FishEye。在阅读了Alexander的由两部分组成的博客系列(第一部分、第二部分)文章以后——这些文章重点说明了JIRA能够除了追踪错误以外,还能如何用于项目管理——我找到他了解到了更多的有关Mgm使用Atlassian工具的经验。

创建

Mgm在他们的项目的许多方面与客户开展合作。他们的业务的独特之处之一是他们如何使用Atlassian来使客户能够参与这个项目的几乎每个步骤和决策制定过程。每个客户都得到了一个JIRA登录账号——JIRA代替电子邮件进行项目沟通,原因在于它是一个更直接和集中化的交流工具,而且能够容易找到历史记录。他们有一个单独的JIRA实例,现在上面有大约70个项目在运行,同时有大约800个活动用户(员工和客户)。项目范围从只有几个人参与、历时2个月,到涉及内部和客户双方数十人参与、历时长达数年。

项目主管会创建一个项目专用的JIRA精要报表,这样客户能在一个地方找到关于他们的项目的最新信息——不必等待其他人更新。

避免待办事项蔓延

mgm开发团队使用GreenHopper来建立项目工作并对项目工作进行优先级排序。就像我们自己的开发团队所获得的帮助一样,他们已经发现这同样有助于向客户展示项目待办事项,这些项目待办事项已经根据期望值进行了优先级排序。

我们的经验说明,在软件维护和优化项目中——特别是在大型项目中——如果不将客户排除在JIRA过程以外,全员参与会降低开销并增加收益此外,如果他能看到所有正在进行的活动,同时如果他能自己生成一个实际项目状态,这个客户就会得到一个关于“他的”项目的、完全不同的附件。我们已经意识到,一旦他理解了过程透明性的全部能力,这个客户就会感到更加满意而且更愿意对分配给他的生命周期部分负责。一旦他意识到仅仅增加另一个“简单”的需求的结构,他也会因为干扰因素而变得更加敏感,而且通常会开始避免“蔓延需求” 虽然有时例外情况会反证这个规律。

在同一页面上

客户和开发人员需要预先理解细节和例外情况,因此需求必须沟通清楚并存在一个集中的、可以查到的地方。Mgm使用JIRA来保证需求是以一致的、相关的方式阐述的,这样当他们开始工作的时候,开发人员就能得到他们所需的一切。

 

通常我们有责任将需求表达清楚。但是客户能够随时参与提供细节,而且他能(也应该)在细化阶段成为一个有利的部分并通过各自的工作单上的注释来表达他的意见和专业知识。

另一个在需求管理中非常重要的地方是所使用的术语。总是使用客户领域的专业语言来交谈(和写作)非常重要。只使用客户所能够理解的术语!我们发现与客户共同维护一份包含所有领域的专用词汇和术语的词汇表是非常有帮助的。

 

让客户工作

一旦项目启动,客户就能够创建新的关于需求、需求变更和错误的问题——但是它不会停在那里。让客户批准一个错误修复或者甚至执行一个选定的手动测试将更深层次地吸引他们,给客户自豪感并参与到这个项目中,这对许多mgm的项目来说已经成为成功的关键。

根据我们的经验,通过客户在JIRA中直接参与所获得的优点超过了缺点(例如配置JIRA所增加的额外工作)。即使发生了一些问题或者项目过程遇到障碍,一个直接参与他的项目的、消息灵通的客户也会感到更加满意。透明度是个神奇的关键字。

结束语

Alexander提供了许多通过多年使用JIRA进行企业级项目管理所获得的很好的例子和教训。无论你是否销售软件、放弃它、或者为它提供内部操作,联系其它的团队并使你的最终用户参与一个项目——甚至从高层次——有助于设定合理的预期并使每个人都在相同页面上。人们制造软件,同时更好的软件来自于所有相关人之间的更好的联系。

  • No labels