“如果你手中有一把锤子，那么你看上去所有的问题都像钉子。” ——马克·吐温
这句话提醒我们，不要过于依赖单一的工具或方法，而要根据问题的实际情况选择最适合的解决方案。
目前，我所在的团队很优秀，创新能力和执行力都很强，在已经保证完成业务目标的前提下，还能自研定制开发了属于自己的项目管理工具- Muggle，我们亲切的称呼它：麻瓜，在整个部门内推广和使用。
在推广和使用过程中，发生的一些问题，引起了我的本篇主题的思考。
对于项目管理，我们使用过哪些项目管理工具？他们的设计目的是什么？发挥了什么作用？有什么优缺点？为什么要选择这种工具？
这些问题，你肯定思考过，也吐槽过，但是我们真的有认真想过：项目管理工具，到底是为谁服务这个问题吗？
为了管理者？为了团队成员？为了客户？为了部门、组织、企业？
或者换个思路，是为了管理报表，还是为了协作需求？
现在项目管理工具，五花八门，各展神通，按照设计目的来分类如下：
-
一、基于看板方法的工具：基于看板方法的项目管理工具，非常适合视觉管理项目。通过拖拽卡片来组织任务，非常适合需要可视化任务流的团队。其优点在于操作简单直观。
-
二、功能全面的企业级工具：支持动态项目进度、沟通、变更、问题、风险、质量、交付、验收等多方面的管理。其优点在于能够实现项目管理的全面覆盖；缺点可能在于操作相对复杂，学习成本高。
-
三、面向研发团队的工具：研发团队主要使用的项目管理系统，支持软件产品研发全生命周期闭环管理，支持敏捷和Scrum方法。其特点在于简单易用，支持私有部署、定制开发等版本，适合研发团队使用。其优点在于专注于研发项目管理；缺点可能在于对于非研发项目的管理支持有限。
-
四、高度定制化的、自研的工具：适合需要高度定制视图的团队。其优点在于高度可定制性，可以按需定制功能；缺点可能在于设置过程可能较为复杂，需要付出很多成本。
-
五、适合小型团队的工具： 提供了任务管理、日程安排、文件共享等多种功能，，适用于各种规模的团队项目管理。其优点在于简洁直观、易于上手；缺点可能在于对于大型复杂项目的支持有限。
-
六、“无所不能”的工具：无需多言，你知道它是谁，猜的没错，就TM 是Excel ，这个搅屎棍～
为什么会有这么多项目管理工具的出现？
当然，是为项目团队而开发的，协助项目团队管理项目：目标和进度，主要服务主体是项目团队，是为了解决问题项目生命周期中遇到的各种各样的问题，例如
- 项目信息可能分散在多个地方，如电子邮件、即时通讯工具、文档等，遇到变更时，导致团队成员难以快速获取准确的项目信息；
- 沟通也可能变得困难，因为团队成员需要花费更多时间去寻找和整理相关信息，从而降低了沟通效率；
- 任务分配混乱和模糊，团队成员不清楚自己的职责和任务的优先级，任务的追踪和进度更新也变得困难，导致项目管理者无法及时了解项目的实际进展。
- 资源（如人员、时间、预算等）分配不合理，导致资源浪费或资源短缺等等非常多的问题。
- 以上问题进而导致团队无法更好的更好地应对变化，如调整任务、更新进度、重新分配资源等，可能就造成及时发现和处理项目风险，决策效率低下；
- 另外团队也可能会难以形成一个统一的团队文化和工作模式，导致缺乏协作和团队精神，协作效率下降，
当管理者知道了有这么一个工具，需要用工具去提取对项目、对团队的各项数据，于是就提出了很多管理性需求，这样就慢慢让传统的项目管理工具越来越庞大，越来越复杂，使用越来越困难，困难的让团队失去了项目管理工具的主动权。
围绕管理，让团队配合，无形之中，团队就增加了很多为了满足管理需求的工作，如：填写工作日志，估算进度，精确填写工时，填写风险，上传里程碑报告等等。长此以往会导致哪些问题？
1、团队成员可能会觉得这些额外的管理任务增加了他们的工作负担，尤其是在他们已经有很多工作要做的时候，导致他们可能会感到压力，因为需要投入更多的时间和精力来完成这些任务； 2、填写各种报告和文档可能会分散团队成员的注意力，使他们无法专注于实际的项目工作，而且这些额外任务不能直接给团队带来直接收益，团队被动执行，耗精气神； 3、一边要满足项目工作，一边要满足管理需求，团队可能会存在更新不够及时，实际情况无法及时反馈到系统中；应付性操作，仅仅为了在“数据”上满足管理需求，导致实际状况和管理看到的报表不匹配，导致项目管理者做出基于不准确信息的决策； 4、管理需求就像多变的天气，变来变去，甚至会出现过于严格的管理要求，对于倾向于自由、灵活和快速响应变化的团队，也会导致团队成员感到被束缚，降低他们的工作积极性和创造力； 5、项目管理工具复杂度不断的提高，团队的使用没有得到充分的培训和支持，团队成员可能会感到困惑和挫败，他们可能无法充分利用这些工具的功能，从而降低了这些工具的实际效果。 6、最后，如果管理层对项目管理工具的期望过高，希望它能解决所有问题并提高项目的成功率，那么当工具无法满足这些期望时，他们可能会感到失望。
但是如果不能满足管理需求，相关的项目管理工具或团队协作工具很难得到管理层的支持，也就很难申请到相关资源(如：费用等)。
项目管理工具，到底是为谁服务，这是个两难的问题吗？
不，当然不是，我认为答案很简单：只有当我们真正为团队服务时，相关的管理需求也就自然满足了，也只有团队真正认真使用了项目管理工具，管理需求才能得到真正的满足。
因此，回到项目管理工具的原点，回归当初的驱动力，从团队自身出发，打造团队自己的工作平台。同时，这些工具也能兼顾管理需求。
满足管理需求，但是方法不能简单粗暴，直接强压，而是应该长效考虑，从团队的角度深入思考，定期收集团队成员的反馈和建议，对工具进行持续改进和优化，甚至可以鼓励团队成员参与工具的测试和开发过程。
这样就让项目管理工具或团队协作平台真正发挥作用，有效提升组织的协作效能。
所以怎么选型项目管理工具只有两个基本要求：
团队协作
项目经理在项目管理工作中，一个主要工作便是让项目透明化，有透明才有真正的协作。所以，要在项目管理工具中，每位成员每天的工作对相关干系人都可视化；遇到的问题、实际进度要及时团队共享共担；相关完成标准可视化、易理解、易执行。给团队协作提供相关团队决策支持。最后，就是要简单、方便。从团队自身的角度设计具体操作，减少团队的学习和使用成本，不要负面影响团队的正常工作，能正面提升团队的工作效率。
管理要求
管理需求确实要满足，但是前提是不能通过改变或增加团队的工作来满足的，可以在不改变团队自身的工作，利用信息化工具自动收集，并进行大数据分析，从而获得。这里举两个支持敏捷方法工具的例子： 风险管理，风险管理不是靠在系统中识别和记录几条风险就能解决的，真正的风险已经隐藏在日常工作日志中，如：
◦ 某个Task已经在Doing状态停留了很长时间（进度风险） ◦ 某些Backlog的优先级已经被调整了好几次（需求风险） ◦ 每次冲刺评审都没有用户参与，也没有用户反馈（商业风险） ◦ 每次冲刺，记录速率，并重新估算剩余的Backlog（成本风险） 这些实实在在的风险完全可以通过系统日志自动分析得出（建立风险管控模型）,无需项目经理或SM再搞个风险管理文档进行控管。
进度管理，进度不是靠项目经理汇报出来的，真正的进度已经隐藏在日常工作日志中了，如： ◦ Backlog、Task的燃尽速度，关注的是剩余工作的进度，而不是完成的进度。因为整个项目的进度取决于还有多少没有完成，而不是已经完成了多少。(剩余工作进度) ◦ 基于里程碑的计划管理粒度已经不能满足当前的管理需求，进度需要每天真实更新，每日站会能满足这个需求，团队协作看板让每个任务的移动直接关联进度（每日进度更新） ◦ 进度不再是需要重新计算，不再是需要被动汇报，不再是复杂看不懂的图表。而是及时、实时和一线保持一致的可视化的简单视图，对管理者开发和推送，也会有能力请管理者走下来，实时了解和指导（进度走动管理）。
总之，在选择或开发项目管理工具时，务必以团队为中心，确保工具能够真正服务于团队的需求，提高团队协作效率，促进项目的成功完成。
