为什么必须使用 Issue Tracking System管理专案？

◎本文转载自 http://www.openfoundry.org/en/news/8659?task=view

What is issue tracking (project management) system?
Issue Tracking system，顾名思义就是纪录、追踪问题的系统。BugZilla、Trac、Redmine、JIRA、lighthoustapp、Basecamp …等等这几套软体，都是知名的Issue Tracking system。

一套合格的Issue Tracking system 的Issue 至少要可以纪录这些内容：
Issue 的主题
Issue 的内容
Issue 现在的状态（新建立、已指派、已解决、已回应、已结束、已搁置…etc）
Issue 优先权（正常、重要、紧急、轻微、会挡路…etc.）
Issue 发生日期
Issue 希望解决日期
Issue 实际解决日期
Issue 被分派给谁
Issue 的附件
Isuue 的观察者有谁
 

Project Management Tool

其中Redmine、JIRA、Basecamp 并不仅止是Issue Tracking System，更精确的来说，它们应该被称为「专案管理工具」。

它们多半能够提供以下作用：

一个地方可以透明的列出所有需要被执行的项目(Issue List)
一个地方可以列出阶段内需要被执行的项目( Issue Milestone )
一个可以记载内容，状态、优先权、日期、分派者、观察者，且具有「permalink」、「权限控管」，且让大家可以讨论执行项目细节的地方。(Issue Ticket)
可以cross reference 或具有子票功能
一个地方可以整理统合专案现在所有的相关资讯。( Wiki 功能)
一个地方可以看到自己今天需要Focus 进行哪些项目（Issue Personal Dashboard)
一个地方能让Manager 可以看到自己的Member 正在进行哪些项目，这些项目目前的状态是什么。（Issue Query)
 

背后运作的原理

网站程式上线前需要准备的事（四）这篇文章刊出后，得到不少的回响。其中我看到的绝大多数的回应多是多半抱怨PM 根本不称职不尽责，只顾着画规格，然后只按照自己写出来的无法执行的天才（？）规格的催进度。所谓的M 不是Management，而是Magic。即使成员卖了命的加班，专案还是得不到好的结果：超时，品质粗糙，成本过高，scope 过大无法完成。

在我进行开发软体专案时，也发现所谓的其实绝对多数的PM，其实职称与进行的事务完全不合。它们的工作内容往往只有Project Planning，应该被称作是Planner，而不是Project Manager。

一个软体开发专案，最重要的变数有四：成本、品质、时间和规模。真正的Project Management，是能够准确Manage 这四项变因，在可以接受的与变动差异下，完成整个专案，产出预期的成果。

我认为Project management tool 可以协助做到专案中以下几项的管理：

规模管理

专案会无限膨胀，主要多半是因为规模的掌控不佳。而规模掌控不佳，时间和成本就会随之膨胀。

规模之所以膨胀，有几个原因：


没有人知道，到底「总共」有多少事情需要完成。
离目前的时间表，「还有」多少事情需要完成，还有多少时间可以用。这些事情里面有没有可以被「调整缩减」的余地。
所以，专案需要一个工具能提供以下功能：

一个地方可以透明的列出所有需要被执行的项目(Issue List)
一个地方可以列出阶段内需要被执行的项目(Issue Milestone)
一个可以记载内容，状态、分派者、执行者，且让大家可以讨论执行项目细节的地方。(Issue Ticket)

时间管理

一个专案中，最宝贵的资源是「时间」。什么东西都可以用「钱」买到，唯独时间不能。在专案中时间最容易被浪费的地方在：

使用信件往来，交涉的互相等待时间。
没有被压定「完成日期」，「详细需求品质」的工作细项。（陷入不必要的完美，或者是悠哉的怠惰）
不符合期待，修改的来回时间。（没有达到良好沟通，导致方向错误）
类似的事情，重复消耗资源。（没有SOP，每次都要花费一定以上的资源去解决）
所以，专案需要一个工具能提供以下功能：

一个可以记载内容，状态、优先权、预计完成日期、分派者、执行者，且让大家可以讨论执行项目细节的地方。(Issue Ticket)
可以平行讨论，而不是信件顺序往来
明确的完成时间
一个地方可以整理统合专案现在所有的相关资讯。( Wiki 功能)
提供专案相关的资讯以及SOP
同时，专案最好能够搭配举行每日的Standup Meeting，确保每个人正在进行的方向是正确的，以及确保专案资源没有被浪费的迹象。

团队工作管理

一个专案，成员至少会有两人以上。两个人以上，就会有沟通与工作协调安排的问题。专案的工作项目往往是有related 的，少有独支。比如说Planner 没有把规格写完，RD 和Art 就不太容易先动工。没有把Database schema 规​​划好，后续就很难继续开发程式。

这也是专案当中最伤资源的状况：优先权等级为：「block」票。因为A 方没有交付，导致B 方不能交付，连带导致C 不能开始。

而专案当中也有很多工作项目分别是「对最终专案目标很重要，但当下不重要」、「对当下milestone 很重要，对最终目标没那么重要」，「只对合作同事很重要」…etc

如果工作项目不能够按照当下状况调整正确的优先等级分派给团队成员。就很容易会造成所有的人虽然很努力，整体工作效益却非常低的情形。

当然，不只是Project Manager 需要知道全部的人今天要做什么。而被分派到项目的成员，也需要能够知道自己当天所需要执行的项目依序是哪些，按照优先状况完成。如果优先状况有错误，可以及早告知资源协调者(Manager)。

所以，专案需要一个工具能提供以下功能：

一个地方可以列出阶段内需要被执行的项目( Issue Milestone )
一个可以记载内容，状态、优先权、日期、分派者、观察者，且让大家可以讨论执行项目细节的地方。(Issue Ticket)
可以cross reference 或具有子票功能
一个地方可以看到自己今天需要Focus 进行哪些项目（Issue Personal Dashboard)
一个地方能让Manager 可以看到自己的Member 正在进行哪些项目，这些项目目前的状态是什么。（Issue Query)
 

资源调配管理

Project Management，并不是在专案的一开始设下「完成时间」，切出所有「工作项目」，列出「完成目标」这么简单。随着专案的进行，开始会有很多变因出现，造成资源不足，需求改变，规模追加，人力减少…等等的挑战障碍出现。

都在考验着专案经理对于资源调配的管理能力。能不能在预定的时间、预定的预算、预定的人力资源内，如期完成当初设立的目标以及交付达到品质要求的产品。

如果条件不允许，当下必须作出取舍、做出决定，而非死板的捍卫规则与命令。

所以，专案需要一个工具能提供以下功能：

一个地方可以列出阶段内需要被执行的项目，并可以移动改变阶段项目。(Issue Milestone)
一个可以记载内容，状态、优先权、日期、分派者、观察者，且让大家可以讨论执行项目细节的地方。(Issue Ticket)
 

转载于:https://www.cnblogs.com/rflyee/archive/2012/12/23/3099735.html