14 项目管理工具：一切管理问题，都应思考能否通过工具解决
你好，我是宝玉，我今天想与你分享的主题是：一切管理问题，都应思考能否通过工具解决。
早些年我在做项目管理工作的时候，除了制订计划外，还要花不少时间去跟踪计划的执行情况。
项目管理上出了问题，管理者总是喜欢从流程规范的角度去想办法，于是为此设定了不少流程规范，例如每天要写日报，根据日报更新项目进度，每周要开周例会，看看项目有没有执行上的问题。
对任务进度的量化也是个很困扰项目经理的事情，需要频繁地去问程序员：“你这个任务进展如何，大概完成比例多少？”，从程序员那得到的答复通常都是个很乐观的数字，例如80%。第二天以为他能做完，结果一问是90%，就这样要持续好多天才真的算做完。
所以后来我得出来一个结论：一个任务，只有0%和100%两种状态是准确的，中间状态都是不靠谱的。
除此之外，还有个问题就是，项目的进展并不太直观，除了项目经理每天看计划表，对计划有一个大概了解以外，其他人可能只有在到了计划设置的“里程碑”时，才对进度有比较直观的感觉。
项目成员手头事情做完，如果和计划有出入，也不知道自己接下来该干嘛，都要跑去问项目经理，所以项目经理对于很多事情都要从中协调，日常有很多繁重的任务管理工作。
后来我发现其实很多管理者都有类似的困惑：任务不好量化难以估算，项目成员对当前项目进度缺少直观感受，管理者要花大量时间在任务管理上。
这些年，随着软件项目管理工具的发展进化，发现当年困扰我的这些问题已经不再是一个主要问题，因为通过工具就能很好的解决这些问题。
这也是我这些年项目管理和技术管理的一点感悟：
一切管理问题，都应思考能否通过工具或技术解决，如果当前工具或技术无法解决，暂时由流程规范代替，同时不停止寻找工具和技术。
下面的微博即是一例，当遇到问题时，不仅从流程上思考有没有问题，更要考虑是不是可以用工具或技术手段来解决。
在这里，我还是先带你看一下项目管理工具软件发展史，通过工具的演化，你可以更深入的了解到工具是怎么解决这些管理问题的。
项目管理工具软件发展史
在没有项目管理工具的年代，都是怎么管理项目的？
早些年，我除了好奇过大厂是怎么开发大型软件项目以外，还好奇过像登月这种超大型项目是如何做项目管理的。正好前不久看了余晟老师写的一篇文章《“阿波罗“登月中的工程管理一瞥》，让我有机会一窥究竟。
其实这种大项目的项目管理并不神秘，就是像我们专栏《11 | 项目计划：代码未动，计划先行》那一篇讲的，这种大项目也是采用WBS（工作分解结构）把所有任务一级级分解，再排成计划，按照计划有序进行。
但阿波罗项目是个超大型项目，所有的任务分成了A、B、C三级，到C级已经有超过4万个任务。要给这四万多任务排出项目计划就太不容易了，一共要几十名分析人员来协调和跟踪所有的任务。最终列计划的图表贴在墙上超过100平米。
在没有项目管理工具的年代，要制订一个项目计划非常之不容易，需要专业人士花大量时间，而且每次修改调整，都要再花费大量时间精力。
最初的项目管理软件：项目计划工具
直到后来像微软的MS Project这样的项目计划工具软件普及，才让制订计划变成了一个相对容易的事情，可以方便的对分解好的任务排出计划。
早些年软件项目的开发以瀑布模型为主，瀑布模型的这种按阶段划分的开发模式，和WBS （工作分解结构）这种将任务层层分解的理念不谋而合，MS Project 这种软件可以非常好的将所有任务分解、制订计划，按照计划跟踪执行。所以那时候，会使用MS Project就是项目经理的标配。
MS Projec虽然解决了计划制订的问题，但还是有些不足之处。例如不方便跟踪任务进度，进度不直观等。
再加上后来敏捷开发开始兴起，很多项目都开始采用Scrum的方式来进行项目管理，开发变成了迭代的方式，以前单纯的项目计划工具，就不能很好的满足项目管理需要了。
基于Ticket的任务跟踪系统
传统的项目计划软件还有很多问题无法解决。比如，很多人都有过以下类似的项目经历：
- 产品经理口头让开发对产品做一点小改动，开发也答应了，后来就把这事忘了，或者测试都不知道还有这事，也不记得要测试这个模块；
- 代码审查的时候，发现组内某个同事的代码没有写单元测试，但是因为任务紧，只能先上线，于是叮嘱他后面一定要把单元测试代码补上，结果还是忘了。
日常项目中像这样的小事情不少，如果不记下来很容易忘记，如果用传统的项目计划软件排进去又很麻烦，直到后面有了基于Ticket的任务跟踪系统，才很好的解决了这个问题。
Ticket跟踪最早源于客服的工单（Ticket）系统，每次客户接到一个问题，就创建一个工单，后续和客户的每一次交流和处理，都要更新工单内容和状态，直到结束。
最早在软件项目中，应用Ticket跟踪系统的领域是测试领域，用来追踪Bug，后来逐步衍生到整个项目管理领域，不仅跟踪Bug，还用来跟踪需求、开发任务等。
也有很多系统用Issue来表示Ticket的概念，无论Ticket还是Issue，表示的都是一个工作任务，可以包括软件的Bug、功能需求、某个模块的开发、系统的重构任务等。
那一个Ticket应该包含哪些主要信息呢？
一个Ticket，应该包含：
- 标题：摘要性的描述Ticket内容；
- 类型：属于什么类型的Ticket：Bug、需求、任务；
- 内容：Ticket的详细内容，例如，如果是Bug的话，除了要写清楚Bug内容，还需要重现步骤。如果是需求的话，要有需求的描述，可能还需要额外的文档链接辅助说明；
- 创建人：谁创建的这条Ticket；
- 优先级：这个Ticket的优先级高还是低；
- 状态：Ticket的状态，例如：未开始、处理中、已解决、重新打开、关闭等；
- 指派给谁：这个Ticket被指派给谁了，谁来负责；
- 历史记录：整个Ticket改变的历史信息，用以跟踪；
当然除了这些外，还有一些其他信息，例如创建时间、附件、标签、版本等。另外现在的Ticket跟踪软件都有强大的定制功能，可以增加额外的辅助信息，例如你是基于敏捷开发，还可以加上Sprint、故事分数等信息。
Ticket的这些内容，基本上可以包含一个工作任务所需要的所有内容。有了Ticket之后，无论大到一个功能需求，还是小到一个Bug，从它创建，一直到完成，整个过程都可以方便的被跟踪起来了。再也不担心像任务被忘记等前面提到的这些情况了。
基于Ticket去跟踪任务，不再需要通过日报、一对一会议的方式来收集任务执行情况，负责Ticket的项目成员在完成任务后，会直接修改Ticket的状态，这样其他人就可以看到Ticket是否已经完成。
Ticket通过各种不同状态，例如未开始、开发中、完成等，可以很直观的了解任务的进展，这就避免了任务难以量化的问题。
Ticket跟踪系统和敏捷开发也是很好的搭档。在敏捷开发中，产品Backlog（产品待办任务列表）是一个用来放所有产品的待办任务的清单，在每个Sprint开始前的迭代计划会议上，从产品待办任务清单里面选取一部分任务到Sprint的待办任务清单（Sprint Backlog）中。
当使用Ticket跟踪系统后，就可以把所有产品的待办任务用Ticket都记录起来，当我们在迭代计划会议上选取好任务后，就标记为要在当前Sprint完成，这样后面就可以方便的筛选出属于当前Sprint的所有Ticket，这样大家就可以从Ticket跟踪系统知道我们这个Sprint有哪些Ticket需要完成、进展如何。
如果将当前Sprint中，从开始到结束，每天记录一下Sprint Backlog中未完成Ticket的数量，绘制成一张图表，横轴表示时间，纵轴表示剩余Ticket数量，就可以通过图表直观地看到还剩下多少工作。
这种用于表示剩余工作量的工作图表也叫燃尽图（burn down chart），可以直观的预测工作将在何时全部完成。
基于Ticket的任务跟踪系统，很好的弥补了项目计划工具的不足，让项目中大大小小的各种开发任务都可以方便的记录跟踪起来。燃尽图也可以直观的了解剩余工作情况。
如果说美中不足的话，就是整体的Ticket状态还不是很直观，例如不能清楚的看到哪些任务在进行中，哪些任务待领取。
基于看板的可视化任务管理
看板本来是在1940年由“丰田汽车”发明的生产管理系统，其中一些理念被借鉴到软件开发中，尤其是其可视化的任务管理方式，很好地解决了早期 Ticket跟踪系统不直观的问题。
所以现在的Ticket任务跟踪系统几乎都会有看板视图，通过看板可以很直观的看到当前任务进展情况。
参考上图，可以看出，在看板视图上的所有Ticket，可以很直观的看出哪些还没开始，哪些进行中，哪些已经完成。
这种可视化的任务视图，不仅是对项目经理，可以很直观看到进展，对于普通项目成员也是很方便。
- 从“待选取”栏选择一个Ticket，拖动到“开发中”栏，表示这个Ticket已经选取，开始开发了。
- 手头上的Ticket开发完成后，就可以将Ticket拖动到下一栏——“测试”栏。
- 测试人员看到新加入“测试”栏就可以从测试栏选取Ticket进行测试。
- 如果测试没通过，Ticket就会被拖动到“待选取”栏。
- 如果测试通过，Ticket就会被拖动到下一栏——“待部署”栏。
- 部署完成后，所有“待部署”栏的Ticket就会被拖动到“完成”栏。
整个过程完全不需要项目经理从中协调太多，尤其是结合每日站立会议，可以让项目成员自发有序地按照看板开展日常工作。
借助Ticket跟踪和看板可视化，项目经理可以从繁重的任务管理中解放出来，可以抽出来时间做一些其他更重要的事情。
以上就是项目管理工具的一个演化简史，可以看到，每一次工具的发展进化，相应的很多项目管理工作就可以得到简化，很多早期的项目管理问题，也就不再是问题了。
有哪些项目管理软件可以选择的？
在了解完项目管理工具的发展历史后，再给你介绍一些目前国内国外主流的项目管理软件，帮助你根据自己项目需要进行选择。
如果单纯是项目计划工具，功能最好、最全的应该是微软的MS Project，但遗憾的是只能运行在Window上，不支持Mac平台。如果要在Mac上使用项目计划工具，可选的有OmniPlan和Merlin Project。
而且这些项目计划工具，现在也都支持了看板视图。不过如果只是单机支持的话，意义并没有那么大，需要在线版的Ticket跟踪结合看板视图，才能让整个团队可以一起浏览操作，发挥其最大效用。
基于Ticket的任务跟踪系统，最有名的应该是Atlassian公司出品的Jira软件，功能全面，体验很好。Jira主要是在海外比较流行，因为访问速度和使用习惯等原因，国内用户要相对少一些。
同类产品也很多，微软的Azure DevOps （以前叫TFS, Team Foundation Server），和微软系的产品如Visual Studio、Azure可以很好的整合。
代码托管平台GitHub本身也集成了一套Issue跟踪管理系统，虽然没有Jira那么强大，但是对于普通项目来说，足够用了。尤其是对于开源项目，完全可以基于GitHub的Issue进行日常的项目管理。
国内同类的软件有：
- 禅道：为数不多提供开源版本可以自己搭建的；
- Worktile：集成了即时消息软件；
- TAPD：腾讯出品，可以和腾讯的服务很好整合，例如企业微信和腾讯云；
- 云效：阿里巴巴出品，可以和阿里的服务很好整合，例如阿里云和钉钉；
- DevCloud：华为出品，和华为云有很好的整合。
还有一些其他产品，这里就不一一列举。
那么该如何选择适合的工具呢？
从功能上来说，基本上，上面提到的每一款产品都能满足日常项目管理的基本需求，建议从项目特色、团队成员、价格和服务等因素综合考虑。
例如说你的项目完全是微软技术栈，就可以考虑使用TFS；如果你深度使用阿里云和钉钉，那么就可以考虑阿里的云效；如果你想自己搭建，那么就可以考虑Jira或者禅道。
这些产品都有免费版本，可以先试用，你可以仔细对比后，根据自身的情况再最终决定。
总结
今天我带你一起了解了软件项目管理工具的发展历史：从完全手工方式管理项目，到借助计划工具分解安排计划，到基于Ticket跟踪管理任务，再到基于看板的任务可视化。每一次工具的升级，都是对项目管理工作的一次简化。
合理的使用项目管理工具，可以帮你极大提高管理效率，起到事半功倍的效果。我也列举了一些目前国内外主流的项目管理工具，希望可以帮助你做出选择。
最后，对于日常项目管理的问题，你也可以多思考是不是可以由工具或者技术手段来解决的。
课后思考
你在日常项目中，有哪些应用工具或者技术解决项目问题的例子？或者你觉得可以用工具或技术解决的问题？你现在项目中用的是什么项目管理工具，有什么优缺点？欢迎在留言区与我分享讨论。
感谢阅读，如果你觉得这篇文章对你有一些启发，也欢迎把它分享给你的朋友。
- J.M.Liu 👍（46） 💬（1）
我觉得辅助计划工具是从项目规划和任务分解出发，以任务之间内在逻辑关系为依据组织任务，优点是能够清晰地看到整个项目的蓝图，缺点是结构化程度太高，不够灵活，不能适应项目执行期间遇到的变化。基于tickt的管理跟踪系统是从项目执行的角度出发，以执行周期为依据组织任务(如一个sprint)，注重任务的状态跟踪，优点是灵活，缺点是缺乏结构化，各任务之间的关系不明确，容易只见树木不见森林，因此不适合做项目规划和任务分解。因此，需要将二者结合起来用，在规划和任务分解阶段，用项目规划工具，生成蓝图，最后把分解后的任务做成一个个tickt，做项目跟踪
2019-03-28 - 易林林 👍（18） 💬（1）
完全手工方式管理的优点在于自由空间大、项目结构松散，比如临时添加需求、临时添加人员、临时改变策略等。一旦管理者没有足够的能力去驾驭项目的整体架构，随着项目时间的推移，项目不是越做越简单，而是越做越难，可能到处都是窟窿，根本没法持续下去，并且责任和义务大部分集中于项目管理者。 尽量采用软件工具管理的优点在于对需求、人员、进度、里程碑等可以进行事无巨细的分解或者组合，明确每个人的职责，明确每件事完成的要求，既可以让参与人员看到长期目标，也可以让他们看到短期目标，而不是遥遥无期。可以这样讲，没有路标的100公里总是比有路标的100公里来得费尽得多，还有就是很容易让参与者失去信心，丧失斗志。 宝玉老师在上面提到了部分工具，能否把项目管理每个阶段用到的典型工具分享一下，谢谢。
2019-03-28 - 熊斌 👍（5） 💬（1）
之前我们项目经理是从IBM出来的，非常擅长使用Excel,我们的项目wbs都是他用VBA做的工具。 不足之处是，无法有效追踪项目进度。 追踪进度的时候，需要问参与的相关人员完成情况。作为开发，我要是完成了20%，为了数据好看一点，我可能会报50%......
2019-10-31 - 胖虫子 👍（5） 💬（1）
说的好好，但在现实中，往往只有最后一个完成时间，明明完不成，硬上，项目经理就是天天催
2019-04-22 - Charles 👍（5） 💬（1）
我们在用云效，用云效之前用过tower主要用看板和任务管理，还自己搭过jira之类的 云效相对来说更加健全一些，主要解决需求管理、版本任务、bug、测试用例、代码管理、持续部署等大部分项目管理的问题 优点：因为用他云服务，所以整合度挺好的 缺点：因为不算他特别核心业务，所以感觉细节问题还挺多的，部署也经常失败，但是最近好像有改善 另外，问老师一个问题，文章中讲到ticket做完到待测试，这一步测试人员是否马上应该跟进测试，但是很多ticket其实是有关联的，所以到底是一个版本计划内的任务全部完成再测试还是一个一个ticket分开测试？如果是单个ticket测试的话，这个ticket是否需要保证和其他模块无关联或关联性较少？
2019-03-29 - alva_xu 👍（3） 💬（1）
ms-project这样的计划工具，适合于项目整体计划的把控，人财物的协调。 ticket系统适合于每个阶段任务的安排、变更和任务跟踪。 两者一个全局一个局部，在敏捷项目里应该结合起来使用会比较好。项目整体计划抓大的WBS ，不作过度深入的WBS，而ticket系统可以跟踪管理局部的变更，是计划管理的子集。 所以我的经验往往是先做一个全面的迭代计划（用甘特图）,基于此做人员安排和工作安排，并拿此作为汇报的依据向领导汇报。 当然，这种模式适用于项目整体目标清晰，时间节点容易规划、每一阶段工作都容易估算的项目。
2019-04-01 - 纯洁的憎恶 👍（3） 💬（1）
工具是流程的进阶，它使流程规范真正发挥作用的同时，将其“副作用”控制在合理范围内。 Ticket、可视化看板等工具灵活、便捷、高效，不仅可以用于软件工程，也可以简单改造后用于多种琐碎而重要的协作中。但是对于很多传统企业，市面上缺少针对性强的现成产品，而这些企业自身也没有精力和意愿，非常深入的做一款适用于本领域管理工具。毕竟这种工具只有一两人用的意义不大，这个组织都用起来才最有意义。 PS：我看燃尽图好像是根据ticket数量的历史变化情况，线性的预测未来的工作进展。但工作真实进展很可能不是线性的，这是否说明燃尽图的剩余工作预测存在天然偏差呢？
2019-03-29 - 小老鼠 👍（2） 💬（1）
1、如何管理好成员学习新技术？新工具？ 2、如何确定ticket的状态，比如完成，是真完成了还是假消息:-( 3、项目经理更重要的工作是什么？
2019-09-11 - 哈哈 👍（2） 💬（1）
现在正在学习使用码云企业版自带的任务管理，我认为这个软件最大的优点就是1)买了企业版就自带了 2)可以和git联合使用，可以指定任务相关代码库、分支
2019-03-28 - dancer 👍（2） 💬（2）
jira 禅道都用过，比较喜欢用jira的看板。另外燃尽图不错，做事会有成就感！
2019-03-28 - bearlu 👍（2） 💬（1）
老师，看你这个课程。我刚好遇到类似问题，我们公司做C++静态代码检查是这样的流程。大家上传代码，然后我用PVS检查，然后查出问题，找到对应的提交代码的人。现在领导叫我，写些工具能自动化找到对应提交代码的人，但是我觉得这样不合理，我觉得提交前不合理就不然提交，我也这样和领导提过，但是领导说这个成本很大？我现在不知道怎么做，听他说做个工具，还是要坚持提交前做检查。
2019-03-28 - busyStone 👍（2） 💬（1）
请问新的这些工具还能看到并方便的编辑任务依赖么？ 有没有工具可以直接通过修改状态就自动换看板的? 另外，像同一个需求需要多端，安卓，苹果，PC同时开发的，请问有没有好的方法来建立任务? 之前都是一样建一个，有点烦。 多谢！
2019-03-28 - Felix 👍（2） 💬（1）
工作以来一直用的jira，之前经常使用看板，去年开始我们转用仪表盘了，它可以利用jira中自带的小工具个性化定制想要的东西，公司用jira的同学可以一试
2019-03-28 - 西西弗与卡夫卡 👍（2） 💬（1）
正好和项目经理讨论这个话题。因为项目涉众比较多，如何及时高效披露项目路线图和进展就成了问题。就有同事拿着时间表跑过来过来问，你们进度是什么，一看是去年已经完成的计划。这不是同事的问题。主动披露项目进展、资源使用情况，是项目组的责任之一。有时候需要汇报，但按时凑齐人不容易，如果是多方汇报，那就更耗费时间。 比较好的实践是给项目设定一个主页，里面包括蓝图、进展、资源使用以及问题等。关心的人可以自己订阅。 再好一点的方法是将上述实践做成流程和工具，以便每个项目和团队不用为采用什么样的协同机制而太操心，更多精力放在业务之上
2019-03-28 - Geek_long 👍（2） 💬（1）
公司用的jira。
2019-03-28