项目管理软件调研

未分类

1. 前言与需求

一款简单方便的项目管理软件是什么样的？

先看下项目涉及到哪些方面：

项目管理软件要么太过于复杂，为团队协作开发了很多个人不需要的功能，要么就过于简单，只是一个To Do List，并不能上升到项目管理规划的程度。

项目本身需要经过多个步骤，有多个参与方，有较长的时间线。

项目按照不同维度又有不同的分类：
重量级项目，参与人众多。
轻量级项目，参与方多，参与人少。

业务开发类项目，软件开发方法基本成熟，完成时间基本可预期。
基础科研类项目，需要调研基础前沿知识，完成时间不可预期。

可以手机，电脑同时使用，简单易用，容易维护，方便各种用户了解参与项目，以及随时了解项目进度。
最好是支持多人协同工作。

所谓的项目管理，目的在于提高对项目的计划和执行，检测项目实施过程中的状态，做好高效的人员分工，从而推动任务的顺利进行。

步骤，人员分工都是人来分配制订的，但是步骤，进度需要分享给所有参与人随时了解。就需要有一个相应的软件或者平台方便大家查阅，并且可以更新进度。为了方便各类小白用户使用，软件还不能太复杂，容易上手。

2. 各类项目管理软件与方法的靠谱评价

主要来自知乎的问答，后面参考文献里有相关链接。

2.1 常见软件概述

软件类型分类

1. 轻协同产品：Basecamp，Asana，Trello，Notion，Teambition, Worktile...

   • 特点：开放面向C端用户，交互做的比较好
   • 缺点：主要是协同功能，很少或没有针对单一垂类客户的功能支持
   • 评价：适合简单的项目/非研发团队做任务管理和协同，不适合人数达一定规模的研发团队进行研发项目管理。

2. 软件研发项目管理软件产品：JIRA/Confluence，ONES Project/ONES Wiki，禅道，redmine

   • 特点：有针对研发团队的功能特性，支持软件研发流程，可以进行需求管理、bug 管理。
   • 缺点：JIRA 比较重度，配置复杂，没有中文界面，且服务器在国外访问速度慢；禅道交互不友好，界面老旧，自定义程度低，不支持任务自动流转。
   • 评价：基本上研发团队只能从上面选。不想付费的、能忍受其交互可以选禅道开源版；对统计报表有需求，希望有自定义工作流，追求更流畅的体验的可以选 ONES Project；不介意英文界面和访问速度的也可以看看 JIRA。需要注意的是，JIRA 是国外的公司，在国内没有服务，有问题也很难响应。

3. 甘特图产品：Microsoft Project，Omni Plan

   • 特点：任务列表和甘特图相结合，对任务时间维度的把控较好。
   • 缺点：重操作，PM 除了需要管理任务还要管理时间条、资源池；对协同的支持差。
   • 评价：Project 只有 PC 端，Omni Plan 只有 Mac 端，所以按照办公电脑类型选就可以。两款软件文件格式高度兼容，界面上都是左任务列表、右甘特图的布局，并且支持日历和资源池，可以生成可视化优秀的报表，可以说是不分伯仲。需要提及的是，Project 只有 PC 端，没有手机端 App，而OmniPlan 有。但是为了支持在更多场景使用，微软发布了 Web 简化版 Project Online，同时支持多人协作编辑。

团队协作的任务分类

站在团队协作的角度，又可分为如下几个类别：

时间管理，任务管理，文档共享，聊天工具，待办事项GTD管理，个人知识管理。

关于团队的即时通讯工具：
其中需要说到的是，关于即时通讯软件像slack及开源替代品mattermost等，比微信的群具有优势的一点是，即使后来加入的人，也能看到之前在某个频道里讨论的所有聊天历史记录，并且可以下载。微信群里讨论各种内容，混在一起，效率很低，不同人希望看到不同的内容无法实现，而在Mattermost里面，因为有频道的概念，可以建立不同的频道，大家还都在同一个团队/群里，但是不影响各自的兴趣不同。这是比微信先进的一点，尤其适合小型的群体或者工作团队，同时又照顾到了更加细分的兴趣主题或者小组。

2.2 简单工具的超级应用

google excel

这些工具要么就是太复杂，效率不高，要么就是同步协调性不够。
Google Excel 是我用过最好的项目管理工具，没有之一。

先说说用Google Excel管理项目的优点都有哪些？简单明了：简单直接到没朋友打开链接url，项目的接下来上线日期，责任人，分工，工期一目了然；上手超级简单，几乎没有啥理解成本，直接就可以用；每个细分功能的工期写的清清楚楚，对着日期哪块没完成，责任人一眼就可以看到；多人共享：解放产品经理生产力，团队效率提升爆表任何人都可以打开url访问，和编辑，每个模块的排期让对应的经理来写，巧妙的给经理压力，让经理自己对自己给出的工期负责。

设计模块，让设计经理来给出工期排期，客户端模块给客户端开发经理来写排期，测试模块让测试经理给排期。

在明白了这个工作流以后，你就能理解这个表的绝大部分内容了。
就是按照「产品工作流」对应的工种，从左向右排布即可。
每个工种下，写上对应的责任人，和预期完成时间；如果完成了，那么修改为「已完成」即可。

不管是大到一个版本上线，一个App从0到1开始做；还是一个小程序，H5活动，还是网站优化一个小功能，都可以用这个方法。

要点：1、及时检查每天都检查一次项目在要完成的那个时间点，是否完成了。如果出现异常情况，尽快找相应模块的经理/总监级别的人协商解决方案。2、不要红脸项目延期很正常的，各种突发情况很多，一般一个团队只有经过一段时间的磨合之后，才能比较良好的运营，在这期间，多给别人一些理解，也是给产品经理自己铺路。3、相信对接人，给予对方尊重不管是设计、开发、运营，还是测试，产品经理都应该给与对方足够多的信任，然后帮助其解决遇到的延期、没按时间点交付相应东西的产出物等问题，「扶人上路」，别人也会在你修改需求，文档不严谨的时候，给你一些台阶下。

GTD

建议一，尝试用GTD的方法简化这个流程。我目前的做法是用wunderlist来做GTD, 收集篮就是收件箱，有什么想法，有什么要做的分别放进去。然后设计一个“马上做”，“待会儿在做”，“未来做‘和”别人做’列表。列表可以做很多，可以按项目分或者时段分都行。GTD的好处不言自明，就是简单。其实题主的这些想法很好，但是实施起来如果很复杂，我个人的经验是，没做多久就放弃了。所以建议一开始可以简化，等有了需求再慢慢增补。

2.3 思想方法策略的运用

PDCA循环

KPI与制度

不喜欢用KPI和所谓制度去压技术，我比较喜欢在前期解决问题。
让美工、技术更早的进入到项目里。需求确认后，做原型之前，就把技术负责任拉进来一起讨论清楚细节、接口传递方式、相关依赖项等等。做原型之后，让技术再确认，原型和之前讨论的需求实现方式是否吻合，不吻合进行调整。这时就要提前告知美工需要制作的总页面数，如果页面很多，要求美工做一张确认一张切一张，和技术同步进行。原型提交美工后，花一点时间和设计人员说清楚，你要的是什么，哪些需要为技术保留，哪些请直接做成图片，哪些地方是按钮，哪些会进行动态调用别做死在页面上。和技术确认的排期，除非是非常非常确认的时间点，否则，请用动态管理方式，如：页面获取后，10个工作日内完成开发，预计联调测试需要1天时间。留出充分的时间。比如，本来开发到测试完成是11天，多留1天作为机动，以备不时之需。验收测试的时候，请亲自参与，并及时调整测试环境中发现的问题。上线后2小时内，请首先作为用户去体验正式环境的各种情况。随时进行调整。（一般上线后2小时内可以进行简单的调整，若正式环境发现大BUG，那么赶紧下线还来得及）调整完成后，宣传就上吧，呵呵。

产品与项目驱动

在驱动产品和驱动项目这两件事情上，最好还是有所差别。至少产品更关注的是产品、功能、方向和反馈；而项目则更关注进度、质量和测试等。

开始阶段做好了解与评估

如何让团队适应项目开发从计划到落实的节奏。要做好这件事情，根据我们自己的经验，其实重点是以下几个方面：做好评估。几乎所有项目最终未按计划执行，其最根本原因就是在项目开始阶段，没有对需求、技术、产品有足够充分的了解，也就没有后续开发中的可控力度。高估和低估都是有问题的，所以我们常用的做法就是非常重视前期的评估，宁愿多花时间，并且对有模糊边界或者有挑战的问题，留足buffer。将计划落实到可执行的单元和可执行的人。有了评估，然后就是将计划落实到足够力度的任务，以任务驱动开发过程，任务落实到责任人，任务要标明截止日期。在此，通过一定的工具来管理，是十分必要而可控进度的。例如我们基于自主产品 Worktile 的任务驱动方式，就可以很好的将开发计划落实到任务和可执行的人，而Worktile的简报(我的任务简报，让自己的事一目了然)则会以直观的方式来告诉负责人项目整体的状态、执行者的情况、被delay的事情有哪些。总之，工具的辅助需要团队开发想法的驱动。小步快跑，不断迭代。小步快跑，快速迭代，是已经被验证的最好方式，只有在足够小的粒度上设置里程碑，才不会造成整体的项目受到大的影响而被无限期延后，这是管理者需要非常清楚的。另一方面，快速迭代，也有助于发现问题，然后快速解决。

风险考虑

产品经理不管项目进度，除非你也是项目经理。如果不是项目经理，千万别揽这个活干。
项目的开发进度不可能总是能够像计划那么理想，所以，计划的时候要能够把风险考虑进去。这样的话，就不会在遇到风险的时候，缺乏对策。

DevOps

随着技术发展而崭露头角的DevOps应运而生.
随着软件发布迭代的频率越来越高，传统的「瀑布型」（开发—测试—发布）模式已经不能满足快速交付的需求。2009 年左右 DevOps 应运而生，简单地来说，就是更好的优化开发(DEV)、测试(QA)、运维(OPS)的流程，开发运维一体化，通过高度自动化工具与流程来使得软件构建、测试、发布更加快捷、频繁和可靠。

DevOps = Culture + Tools

DevOps 集文化理念、实践和工具于一身，可以提高组织高速交付应用程序和服务的能力，与使用传统软件开发和基础设施管理流程相比，能够帮助组织更快地发展和改进产品。这种速度使组织能够更好地服务其客户，并在市场上更高效地参与竞争。

不仅用在互联网公司的研发中, 也可以借鉴其工具和思想服务于传统的业务公司. 工具的目的是为了实现自动化,而服务小组的流程化在机器所不能达到的领域,也起到了类似的作用,加快了业务的进展。

对于研发类组织企业, 若要实现DevOps,
整体阶段:
先从技术入手, 推动跨工具链自动化的发展，
然后推动流程的精简，服务小组的确立，
再考虑组织上的优化与变革,
最后是人的思想与观念的逐步转变。

3. 对比分析

3.1 重量级项目

一个典型的成熟软件研发项目，涉及到如下相关环节和知识，需要有特定的软件来支撑多人协作和项目推进。

可以使用团队协作和特定的软件项目管理软件。
不然无法管理为数众多的功能点，测试用例，数量庞大的研发人员，以及相应的修改情况。

3.2 轻量级项目

对于人数参与较少的项目，则可以直接使用可多人共享的在线excel来管理项目, 结合个人知识管理工具一并进行。

前提是掌握一些方法策略，还有工作流程，人员分工的了解。

4. 结论

4.1 重量级行业项目管理

根据公司的项目类型和人数，关注的重点等实际情况不同，是否企业软件研发项目，采用轻量或者重量级的项目管理软件即可。
例如禅道, Teambition，ONES Project等软件。

4.2 简单易行的项目管理

即时沟通可以建微信群，项目管理用在线 excel, 如国内的石墨文档，支持多人协作。
使用excel需要事先了解和定义工作流，分工，并体现在文档里。

在了解目标达成的意义的前提下，按如下步骤完成：
第一步，目标分解成子任务以及需要分成哪些步骤。
第二步，将这些步骤以及对应的人落实下来。
第三步，将步骤及分工写在在线excel上分享给所有协作人并不断更新。

这样每个人都可以看到全局以及与自己的关系，同时也可以了解自己的部分占全体的哪一步。
工具又及其简单，基本没有上手学习的过程。
唯一要求的就是项目管理的发起者在一开始设计规划时需要做好流程步骤的划分，每个责任人的划分。

5. 参考资料

产品经理怎么管理项目进度？
Google Excel 是我用过最好的项目管理工具，没有之一。
https://www.zhihu.com/question/20102432/answer/506962449

产品经理有什么好的项目跟进方法？
不喜欢用KPI和所谓制度去压技术，我比较喜欢在前期解决问题。
https://www.zhihu.com/question/19608318
https://www.zhihu.com/question/19608318#answer-78920

项目管理软件哪个好？
https://www.zhihu.com/question/21518108/answer/230472963

有哪些好用的个人项目管理软件？
https://www.zhihu.com/question/28794330/answer/42163697

团队合作聊天服务Mattermost在Ubuntu 16.04下的安装配置与试用
https://www.jianshu.com/p/2c69c56feb3d

http://note.youdao.com/noteshare?id=a9d8ec50a3295c4f571524c5c2d6bba3&sub=08A74F11E70B46E8A56ED0D39B1D6BEB DevOps 资源汇总. 企业 DevOps 的成功之路

http://note.youdao.com/noteshare?id=617535c99b834ca6f9867831d29cc465&sub=8122B0403EB54036A38E4C9A42F4AE01 DevOps 工具资源汇总

http://note.youdao.com/noteshare?id=aa655e37bf5cd00aeab9ee2d80711d7e&sub=9BFFF5BB06DC452F81CDCEB3416B2D6F DevOps笔记