我们理解的简化，是日常操作的简化，而非功能上的简化。
前几日在知乎看到一个问题：Trello等项目管理工具体验如何？
本来利益相关太高不准备答，因为哪怕通篇说Trello好，有一句不好都有贬低对手抬高自己之嫌疑。
但是我发现题主问的是Trello等项目管理工具体验如何，我个人理解，题主是想问：Trello这类项目管理工具的体验——恐怕是对项目管理工具没有了解的。那么正好借此机会，向大家介绍一下项目管理工具究竟缘起何处以及究竟Trello是否能够代表项目管理类的工具。
首先，既然我们把这些产品归为一类，那么就得明确他们的共性——都脱胎于看板式项目管理。那就究竟什么是看板式项目管理？
看板管理，常作“Kanban管理”（来自日语“看板”，カンバン，日语罗马拼写：Kanban，原名：传票卡），是丰田生产模式中的重要概念，指为了达到准时生产方式（JIT）控制现场生产流程的工具。准时生产方式中的拉式（Pull）生产系统可以使信息的流程缩短，并配合定量、固定装货容器等方式，而使生产过程中的物料流动顺畅。 看板管理方法是在同一道工序或者前后工序之间进行物流或信息流的传递。
通俗点说，就是源自车间生产的看板：
车间流水线上，一环扣一环，所有机器同时工作：
当2号机器的生产效率比较低，1号机器比较高的时候，就会堆积1号机器的产出物，造成积压库存、降低生产效率等问题。
所以，车间生产中，需要去判断2号机器所积累的任务量，再决定1号机器是否继续生产。如果2号机器积累的任务太多，1号机器就停产。当然，真正的车间生产要复杂很多，我只是举个简化的例子。
引一段对看板式任务管理的评价：
看板在各个行业领域的应用目的不同，所带来的优势也可能不同。基于看板的模型，有一点是很明确的，看板能够将库存量和实际消耗量对齐，限制生产中任何一点的过量库存。只有当库存消耗时才发出请求信号，让生产端开始交付新一批产品。用需求量来控制生产率，让整个过程变得可视化，避免生产端产能过剩。
而后，这套生产方法在其他领域发扬光大了。比如——软件开发。
这套东西，在过去长这样：
而在今天，就成了我们熟悉的各类看板式项目管理工具，例如Trello，以及Worktile。
随手截了一个我司的bug反馈看板，是不是跟上图换汤不换药？
02 流程化是项目管理工具的内核
先说一点，不少人对任务管理工具的理解局限于ToDoList，这是极其不准确的。这类项目管理工具的最大优势，在于——流程化。而流程化也是一种思维，这种思维是项目管理软件能带来的，最宝贵的财富。ToDoList只是发挥了card／list这一级别的功能，最关键的board反而没有体现。而card／list／board三位一体，才能构成看板式项目管理。
举个例子：
我给你一个项目，把大象装进冰箱里，你打算怎么办？
你可能会想到宋丹丹老师说的——冰箱门打开-大象放进去-冰箱门关上
但是没有这么大冰箱怎么办？
我们需要这个大冰柜
大象从哪里来？
我们要找个买大象的渠道
运输怎么搞定？
得找一辆大卡车
有没有找到一种似曾相识的感觉？在工作中我们常会面对这种困扰——问题总是考虑不周全，实施过程一团乱麻、漏洞百出。这，其实就是因为缺乏流程化的思维。
例如我们得到了这个任务。那么粗略的想一下，大概分这样几步——
大象来源-运输-场地准备-物料准备-实施-后续步骤。
而每一步，又可以细分，例如大象来源——
法律相关-资金准备-前期联系-合同 等
有了这样的步骤，即便会出现状况，也能在最大限度上保证项目的顺利实施。同时，如果前期准备不到位，后期的计划便相应的调整或者延后。这就是流程化的本质。
皮一下，设计了把大象装进冰箱的项目
流程化思维，最好的应用场景就是团队的工作。因为多人配合的情况下，企业会面临很多问题，诸如：
信息不对称
责任不明确
任务进展难以把控
项目流程经验难以沉淀
项目执行过程无迹可寻
其他……
03 这类项目管理工具的体验究竟如何？
要谈体验，自然离不开需求。现在企业的工作和配合是十分复杂的。看板管理工具面临着很多挑战。既然我们也要讨论Trello能否代表这类项目管理工具，那么我就以Trello举例。
首先，看似全能，实则无能
这是Trello的一个空白看板，这里面什么都没有，当然也就意味着你可以配置出任何你想要的项目。但是那只是理想情况下，现在如果一个产品团队，想要以此实现需求管理。你觉得要怎么创建看板？
我相信，项目管理能力也好、流程化思维能力也好，永远都满足二八原则。能够快速上手的人永远都是少数。如果你很不幸的是那“八成”，那么这个空白看板的体验可以说一点也不好。反倒是国内许多厂家，都引入了模板的概念。在一定程度上解决了不知道如何配置的问题。
Worktile的项目模板
其次，标准化的产品如何适应非标准化的需求
这个问题的难度，要比第一个问题复杂很多，可以说是整个SaaS行业都面临的问题。
个人产品，尚不能满足所有人的需求，面对企业复杂的需求，标准化的SaaS产品就更加显得有心无力了。
例如：
任务的流程问题——即一个任务完成某一进度之后，流转到哪里？Trello的逻辑是没有流转，通过手动拖动即可。但是如果是这样一个看板，你又恰巧是新同事，你知道怎么拖动吗？
有人会说让设计师自己认领。
这么做没问题。
在设计上有一个复杂度转移的概念——
过去遥控器按钮很多，但是电视上菜单很简单。 现在遥控器就上下左右确认这几个按钮，但是电视的菜单复杂了很多。 复杂性从遥控器转移到了菜单。
上面的做法，就是将复杂度由产品转移到了制度上，制度的学习、规范，成员的犯错，无疑都在降低着协作的效率。好的产品体验，应该是降低用户操作的复杂度的。如果我为了一个看板要多一项制度，那这可以说很不友好，体验很差了。
类似的问题，不胜枚举。例如：
利用不同维度对任务进行筛选；
项目的分类统计；
不同形式的看板展示；
这一点上我在Trello上没有看到，但是国内主流的项目管理工具一直在试图解决这些问题的。
在Trello的官网上，我看到这样一句话——
Trello绝不会强加你不需要的功能。 对于希望使用除看板以外其他功能的用户，我们有Power-Ups，如日历、card aging和投票， 你可以打开这些功能。它是丰富功能的一种方法，但又不会 搞得复杂化，适合每个人。
我明明要解决住宿的问题，你给我一堆砖算什么？如果我想砌墙可能问题不大，要是摩天大厦真的不行。所以说，Trello简化的思路，会有人追捧，但是这也将Trello局限在了中小团队，或是相对简单的项目流程中。
综上所述，回到我们最初的两个问题， Trello 等任务管理工具体验如何？其实并没有一个明确的答案。关键还是看企业具体的需求。如果只是简单的ToDolist，那么任何一款工具都能有效满足。如果是复杂的团队管理、项目管理，建议亲自体验。国内外的项目管理工具，早已在看板的基础上，发展出了众多复杂而高效的功能；但是也剩下一些问题，还没能得到解决。
回到第二个问题，Trello究竟能否代表这类项目管理工具，我的答案是否定的，而且我很讨厌中国版Trello这个说法。这就好像脊椎动物虽然在身体构造上有着相似性，可是演化的方向完全不同，适应的环境、生存策略也都不同。蓝鲸不能代表脊椎动物，Trello也不能代表项目管理工具。Trello的局限性我在前文已经提了几点。在这些方面，国内厂商的思路和解决方案显然更能适应中国企业的需求。
我们理解的简化，是日常操作的简化，而非功能上的简化。
