高效能使人上瘾，除非你没有真正高效过

Designup

我是Rain，Designup平台的创始人，Designup（www.designup.cn）是一个帮助企业找到优秀互联网设计师的平台，我们的产品从开发到上线只用了短短两个月的时间。测试阶段，我们曾在一天之内解决了200个bug。听起来不太可能，但明道让这些事情都发生了。现在我相信，在高效工作这一点上，选对软件很重要，用对它，更重要。

明道是我三年前就知道的协作软件，身边有不少朋友在使用，觉得不错所以推荐给了我，我也就成为了明道的用户之一。坦白来说，我属于那种典型用户，可靠安全、高效顺畅的Saas软件确实是我的诉求，但它究竟能带给我什么改变，能帮助我的团队提升多少工作效能，这些我都没有一个准确的把握和体会。

直到三个月前，我开始带领团队做一款帮助企业找到优秀互联网设计师的平台Designup，在团队成员共同探索和运用明道的过程中，一次灵光闪现，为我的团队带来了前所未有的高效。

这里要插入一个概念，来自《腾讯方法》一书中关于推进运营产品部工作运转的方法：“故事墙”。

这本书中介绍道，故事墙分为“Ready（计划）—— Play（开发）—— Test（测试）——Done（完成）”四栏，用四种不同颜色的纸片来代表不同的任务种类：黄色代表功能需求，蓝色代表技术任务，红色代表Bug。纸片内容包含任务、执行人、工作量和计划完成时间等信息。任务的优先级程度根据纸片自上而下的位置而定，越往上，优先级越高。

故事墙

故事墙的初衷很好，因为它确实能为团队协作带来改变。

一方面，故事墙能使项目处于不断优化的过程，实现规范中敏捷开发。故事墙能将项目信息完全透明和可视化，团队成员可以清晰地看到整个项目的进度，每个细分任务要实现的功能，以及项目遇到的瓶颈和问题。

另一方面，故事墙大大提高了团队成员的主观能动性。墙上没有自己的任务，或自己的任务优先级不够，会给予成员一定的压力。故事墙的使用改变了管理方式，可以激发团队成员根据自己的任务情况主动去Ready栏领取任务，任务完成后将纸片挪到别的栏即可（认领—完成—确认）。

以此来看，随着产品信息的畅通透明，返工任务越来越少，团队实现了高速有限运转。

但是，腾讯的方法真的适用于每一个团队吗？或者说，真的适用于我们这样的初创团队吗？

我认可故事墙的意义和价值，但当我自己带领一个团队尝试去使用它的时候，我发现这个方法也有“bug”：故事墙不具备即时性、移动性、可回溯性。如果我在凌晨两点发现一个bug，难道要先写到即时贴上第二天再带去贴到墙上吗？如果我在出差途中，应该如何查看项目进展呢？当一个项目结束了，所有的完成性问题又该如何回溯？

我的团队全部技术伙伴都来自国内知名的互联网公司，我们的产品用了54天就进入了测试阶段。按照通常的流程，此时应该要有一个测试部门来专门做产品测试，集中反馈，分批解决。但对于我们这样一个创业初期的团队来说，测试人员只可能是我们自己。而传统的办法，产品经理会列出测试清单，由各个部门伙伴逐一走流程，再进行汇总反馈。我们想寻找新的办法，尽可能地高效。最开始的一段时间，我们尝试使用过故事墙，但随后还是由于上文提到的一些原因，我们放弃了。

就是在那时，我们突然发现明道的任务板块其实非常方便我们建立在线故事墙。我们运用了故事墙的原理，设置了bug、待处理和已完成三个板块。具体的协作流程是这样的：每位伙伴都可以即时在bug板块中提出问题同时可附上截图，并将任务托付给产品经理，产品经理在评估了bug产生的原因之后，可以分发给相应的伙伴，将任务拖拽到“待处理”中，并按照1，2，3的顺序来标注优先级，技术团队的伙伴在自己的任务板块中接收到新的任务，并根据优先级来处理。整个流程减少了不必要的沟通，大大提高了工作效率。

一个优良的概念，结合明道的使用，就这样为我们带来了意想不到的效果。我们就是用这样的方法，在一天内发布并解决了200个bug。不到两个月的时间，Designup就正式上线了。这个速度大大超过了我们的预期。

在明道中进行bug创建

在明道中将bug托付

bug完成

总体情况

我们终于体会到，协作软件无缝对接到工作中并不是一个个体适应产品的过程，而是驾驭它、运用它的过程。明道值得探索的地方远不止于此，怎么样运用它才能最大化地帮助到你的团队，在你们去使用之前，没人能告诉你准确的答案。但如果你相信它的可能性，它一定会给你带来惊喜。

Designup团队中的每一个伙伴从此都对明道产生了依赖，因为高效能使人上瘾，除非你没有真正高效过。