目录

产品研发过程常见问题1：缺乏统一的管理平台

产品研发过程常见问题2：难以量化的需求开发与管理

产品研发过程常见问题3：跨部门协作困难

产品研发过程常见问题4：多项目管理挑战多

产品研发过程常见问题1：缺乏统一的管理平台

随着软件开发实践的不断深入，应用生命周期管理越来越被业界接受为一种经过实践检验的，可以创造高品质的应用程序的，可靠的软件开发模式。但是，要实施整个应用程序生命周期管理是非常复杂的，我们必须借助一些工具来帮助我们完成整个生命周期的管理。

让我们先来回顾一下绝大多数软件研发团队的典型工作情景：

【场景1】：工具满天飞

很多研发企业的管理平台非常分散，不同团队和个人使用工具不同，我们常常可以看到，产品部门收集需求使用Word、Excel，项目经理制定项目计划、进行任务划分和分配使用Project，开发部门管理任务和缺陷使用Jira、URTracker，测试部门管理测试任务使用TestDirector、TestLink，配置管理使用VSS、SVN、CVS、CC等等，这些平台相互是独立的，不仅不可以信息共享，部门之间还产生了有明显的信息壁垒，完全靠手工操作实现信息传递。

【场景2】：研发过程衔接不畅

公司的需求管理、计划管理、缺陷跟踪、测试管理等等各种研发活动，使用不同公司开发的无法整合的工具，这些不同来源的工具，既无法共享项目信息，给使用上带来很多不便，又无法在各种不同类型的数据之间建立关联，导致一些高级管理功能无法实现，比如要实现需求跟踪，需要整合需求管理、任务管理、测试管理三个系统。

【场景3】：一个BUG引发的血案？！

软件开发人员1： 通过代码走查发现一个BUG，需要将这个BUG记入缺陷跟踪系统；

软件开发人员2（代码的作者）：需要根据这个缺陷判断需要如何修改，并评估修改的工作量。如果是普通的BUG，只需要开发人员进行修改即可；一旦发现是深层次的BUG，涉及到数据结构的调整、界面的调整甚至软件架构的调整，这将牵动研发团队的项目经理、系统架构师、数据库管理员、界面设计人员、产品经理；

项目经理：收到开发人员的汇报，很不幸的发现这个问题需要在缺陷跟踪系统中将相关的人员统统拉到一起才可以解决问题；

产品经理：需要根据缺陷评估即将投入的人力成本和由此引发的后果；

系统架构师：评估架构调整的成本并拿出可行性方案；

数据库管理员：调整数据结构，并为由此带来的数据结构升级准备方案；

界面设计人员：重新调整界面，并为原来统一的风格如何调整伤透脑经；

软件开发人员3（终确定FIX BUG的人员）：根据终收到的修改方案，制定修改计划并进行BUG的修改，而且该软件开发人员制订的开发计划需要让相关人员能准确的掌握BUG修改的进度，因为他的计划制约了后续的每一步工作；

版本经理：根据修改结果发布一个测试版本，并知道版本中已包含了此次修改；

测试人员：在拿到该版本后需要对这个BUG导致的代码修改设计针对性的测试用例，这个测试用例可能是自动测试用例，也可能是人工测试用例，总之测试人员需要在测试管理系统来记录这个BUG修改的验证过程；

版本经理（又出现了! ）：一切绪后，向客户发布版本时还需要提供release notes以指明该版本中的这个改动（假设该BUG对用户可见）；

技术支持：收到版本经理发布的版本、操作手册以及相关的FAQ，做好给客户提供支持的准备；

QA：仔细分析代码走查发现的所有BUG原因，如果是典型问题，还需要将该问题写入开发经验库，并通过知识共享的形式分享给所有团队成员；

项目经理（?！）：一切却还没有结束！项目经理的职责还需要从组织级的角度把控项目过程和研发全进程。一个开发人员的代码如果被统计出问题较多，应该对该开发人员开发的代码采取补救和预防措施，要么加强测试，要么给他一些培训，要么他根本不适合这个职位应该走人；对于这个开发人员的上司，他应该如何评价这个犯错的下属，因为几个BUG认为他的工作不称职显然是不正确的，还有他如何衡量这个开发人员的工作量，是否是该员工工作量太多导致了该员工的代码质量不高？他还想知道该员工在引入这个BUG时当时的工作任务是否过于紧迫？当然，他也可能想分析一下这个典型的BUG引入会导致多少额外的工作量产生？

…………………….

这，也太麻烦了吧！

一切只是因为一个开发人员的某行代码的BUG引发的血案？！

拜托！这是研发工作的特点！好吗？!

理由很简单：没有一个集中管理、统一、高度整合的管理平台！