Week Plan:强介入性的效率导师[转]

  做产品有三重境界,以效率工具这一细分领域为例:

  第一重——发现用户需求,如 Fleep,敏锐地发现团队协作中的关键——聊天,围绕这一需求做足文章;

  第二重——预见用户需求,如 ProcessOn,在以文字为基础的团队协作工具风生水起的时候,预见到美工和设计师用户经过市场教育,也可以采用团队协作工具提升绘图效率;

  第三重——创造用户需求,但效率工具中尚无可一统江山、主导市场话语权的王者,侈谈创造需求尚无现实性。

  湍急的河流中总有鱼儿逆流而上。一般的产品研发,无论何种境界,万变不离其宗的是围绕用户需求讲故事,置用户需求于其他问题之上。然而,效率工具这一细分领域竞争异常激烈,总有理想主义者不按常理出牌,认为用户需求并非第一位的,认为教育用户、教给用户管理时间的方法,要比单纯满足用户的现实需求更为重要,更有长远意义。

  Week Plan 是一个澳大利亚创业团队新近开发的一款时间管理和团队协作工具。同类型工具我们曾经做过专题集中报道,其中有领域标杆 Asana 、Trello、Evernote,国内的佼佼者 Teambition 、伙伴,以及具备特色功能的轻量级工具 Zapier、Fleep、ProcessOn 等等。与这个类型中的大佬和先行者相比,Week Plan 还很不成熟,远远称不上是伟大的产品,但是正是这样一款入门级创业产品,敢于逆流而上,以导师的姿态强势介入用户的自我管理,超越了产品研发需求本位的一般境界。

  理念

  效率工具常见「留白」设计,即工具只提供「杠杆」,用户采用不同的方式撬动杠杆,总能撬起各种不同的需求,如老牌效率工具 Asana、Trello 等,都颇得个中精髓,产品设计上留给用户很大的自由度。

  Week Plan 则反其道而行之,将这种自由度严格地限制在自身希望传达的理念框架之中。其团队受美国管理学家科维的自我管理专著《高效人士的七个习惯》的启发,总结出三条操作性最强的自我管理思路:

  a. 以周为单位制订计划。「Week Plan」,顾名思义。一周七天是一个不长不短的时间单位,一周之初,要对本周的工作做一个全景式把握,然后逐步推进。

  b.「轻重缓急」四象限管理法。科维首创这一方法,根据任务紧急性和重要性划分四个象限:重要且紧急的任务(即将到期的任务),重要但不紧急的任务(人员培训),不重要但紧急的任务(会务报道),不重要且不紧急的任务(个人投稿)。国内团队开发的高效 Todo 也是对四象限管理法的具体应用。

  

  c. 在多重社会角色间把握平衡。科维认为,自我具有多个社会维度,一个产品经理,同时也是一个儿子,一个丈夫,一个自媒体写手,一个登山爱好者。即便在上班时,他也会接到母亲让他代买火车票的电话,也会在研发公司产品的同时心中默默构思晚上要写的微信公号文章。任务与任务不仅在时间上、也在角色上相互穿插,个中平衡如何把握是一门学问。

  功能

  Week Plan 就是把上述三种思维方式用计算机的语言重写了一遍。打开 Week Plan,首先出现的是教学引导 Demo,跟随 Demo 完成几个简单的任务,就可以大致掌握 Week Plan 的使用方法。Demo 步骤完备,但是全部完成还是需要一两分钟的时间,对于那些习惯于在操作中摸索学习、不喜欢记忆太多东西的用户,以及处女座和有消灭红点强迫症的用户而言,显得比较繁琐。

  

  Week Plan 的整体界面结构清晰。左边栏显示用户的角色划分和不同角色下的任务列表,用户可以创建新的角色,每一角色都以特别的颜色进行标记。Dashboard 中给出一个几乎满屏大的周历(这里也允许用户切换成类似 Trello 的栅格视图),用户可以从边栏往周历中拖拽任务,安排自己的日程表。

  

  具体的任务界面与 Trello 等经典任务管理工具比较近似,用户可以自行添加注释、附件、子任务、时间等。特别之处是引入了重要性和紧急性的维度,用户可以把任务标记到不同的象限中,每个象限的任务其任务标题的格式都是不同的,熟练认清标题格式的意义后,可以在周历界面一览任务的性质,但初步测试的感观是不同的格式群魔乱舞,令界面显得有些混乱,并不直观。

  

  Week Plan 的自我管理功能十分强大,同时,也留出了团队管理功能的余地。用户可以组建多个工作场所,将多名用户添加到同一工作场所中,安排以周为单位的团队工作计划。

  

  Week Plan 还提供了「停车场」(Parking Lot)功能,相当于内置的便签,用户可以在这里记下一些难于分类到具体角色的工作,以及自己的突发奇想。

  

  Week Plan 附赠四个谷歌浏览器插件,包括番茄工作法计时器、个人成长日志等,方便用户在使用 Week Plan 的基础上进一步管理好自己的时间,并让时间管理与浏览器行为深度整合。其中,团队十分自豪地推荐他们独创的「我思图谱」(Cogitorama)插件,这个小工具方便用户即时记录下自己碎片化的想法,并对之进行管理。

  

  简评

  与流行的趋势相反,Week Plan 是一个强介入性的时间管理工具,要求用户依照它提供的图式建立自己的时间管理框架。它试图超越产品研发用户需求至上的基本思路,转而用整个产品的生命去传达优秀科学的时间管理理念,承担起教育用户的职责。对于自律能力薄弱或者初学时间管理的用户,Week Plan 可以手把手教会他们遵循怎样的思路安排自己的规划,有潜力成为一名负责任的领路人。

  也正因为如此,Week Plan 产品的气场太强,细节体验存在一些问题,功能方面又贪大求全,对于本就拥有一套成熟的效率方案的顾客而言,Week Plan 可能会慢慢沦为他们工作中的累赘,一些细节过于复杂繁琐,体验不够顺手,在一个产品最基本的层次上反而做得不够完善。

  Week Plan 目前有 10 万+的注册用户,目前只有 PC 端上线,分为免费版和高级版,后者月付费 7 美元,增添子任务、数据下载和 Zapier 连通功能。团队今后还会推出移动端的应用。

  感兴趣的童鞋可以前往其官网测试免费版,注册即赠送为期 15 天的高级版试用权限

时间: 2024-07-31 14:34:38

Week Plan:强介入性的效率导师[转]的相关文章

什么阻碍了强人工智能的发展

版本:0.1 当今科学虽然非常发达了,但还是没能很好的理解和解释我们的世界.三个基本问题仍然困扰着我们:最小的是什么,最大的是什么和意识是什么.所谓最小,即最小的物质是什么.虽然我们证明了上帝粒子,快要证明各种粒子的统一和完备性了.但再往小了看呢,这些基本粒子又是什么组成的?这一层一层分析下去,是否有尽头?我们还要不断的了解更小粒子.逼近真理.所谓最大,我们可视的宇宙之外是什么?我们可视的宇宙之内,看不见的暗物质.暗能量是什么?是否有我们的世界和其完全没有作用力的黑物质和能量存在?最大和最小的问

分布式场景下Kafka消息顺序性的思考

如果业务中,对于kafka发送消息异步消费的场景,在业务上需要实现在消费时实现顺序消费, 利用kafka在partition内消息有序的特点,消息消费时的有序性. 1.在发送消息时,通过指定partition hash 2.consumer 消费消息时,需要使用亲缘性线程池进行消费,才能实现消息的基本有序.否则即使通过发送时指定partition,在消费端由于线程池的异步消费,消息之间的处理都是并发进行的,消息就会被打乱. 上面的方式基本可以实现消息的消费顺序性,除了在极端场景下,比如: 1.进

什么是架构

什么是软件架构 前言:软体设计师中有一些技术水平较高.经验较为丰富的人,他们需要承担软件系统的架构设计,也就是需要设计系统的元件如何划分.元件之间如何发生相互作用,以及系统中逻辑的.物理的.系统的重要决定的作出.在很多公司中,架构师不是一个专门的和正式的职务.通常在一个开发小组中,最有经验的程序员会负责一些架构方面的工作.在一个部门中,最有经验的项目经理会负责一些架构方面的工作.但是,越来越多的公司体认到架构工作的重要性. 什么是软件系统的架构(Architecture)?一般而言,架构有两个要

一个测试老鸟的工作总结(2)——研发流程之我见

从一个执行层面的测试做到测试主管这个级别,当你手下管理多个项目和测试人员时,流程成为你必须要考虑的事,一般公司也很少有自己独立的SQA部门进行过程管控,如果是弱矩阵式的组织架构的模式下,基本QA/QC作为一个质量部门存在于公司内,而过程管控流程制定一般也分摊到项目管理者或质量部门中.那我们今天就来讨论一下软件研发流程这个话题,对于大多数普通的人员来看,流程是否完善规范,也是看一家公司的软件研发是否正规的主要标准.对于国内的软件企业,我们一般常见的几种开发模型有: 边做边改模型:没有规格说明,没有

【大话存储】学习笔记(7,8章),FC协议

Fibre Channnel 我们之前引入了SAN的概念,SAN首先是个网络,而不是存储设备.这个网络是专门来给主机连接存储设备用的. 我们知道按照SCSI总线16个节点的限制,不可能接入很多的磁盘,要扩大SAN的规模,只使用SCSI总线是不行的,所以必须找到一种可寻址容量大.稳定性强.速度块.传输距离远的网络结构.FC网络就应运而生. FC网络 Fibre Channnel也就是网状通道,FC协议从1988年出现,最开始作为高速骨干网技术. 任何互联系统都逃不过OSI模型,所以我们可以用OSI

经典软件测试面试题

1.问:你在测试中发现了一个bug,但是开发经理认为这不是一个bug,你应该怎样解决? 首先,将问题提交到缺陷管理库里面进行备案. 然后,要获取判断的依据和标准: 根据需求说明书.产品说明.设计文档等,确认实际结果是否与计划有不一致的地方,提供缺陷是否确认的直接依据: 如果没有文档依据,可以根据类似软件的一般特性来说明是否存在不一致的地方,来确认是否是缺陷: 根据用户的一般使用习惯,来确认是否是缺陷: 与设计人员.开发人员和客户代表等相关人员探讨,确认是否是缺陷: 合理的论述,向测试经理说明自己

软件测试,性能测试,功能测试,自动化测试,接口测试,移动端测试

1.问:你在测试中发现了一个bug,但是开发经理认为这不是一个bug,你应该怎样解决? 首先,将问题提交到缺陷管理库里面进行备案. 然后,要获取判断的依据和标准: 根据需求说明书.产品说明.设计文档等,确认实际结果是否与计划有不一致的地方,提供缺陷是否确认的直接依据: 如果没有文档依据,可以根据类似软件的一般特性来说明是否存在不一致的地方,来确认是否是缺陷: 根据用户的一般使用习惯,来确认是否是缺陷: 与设计人员.开发人员和客户代表等相关人员探讨,确认是否是缺陷: 合理的论述,向测试经理说明自己

测试面试常见面试题汇总一

软件的生命周期(prdctrm) 计划阶段(planning)-〉需求分析(requirement)-〉设计阶段(design)-〉编码(coding)->测试(testing)->运行与维护(running maintrnacne) 测试用例 用例编号  测试项目  测试标题  重要级别  预置条件  输入数据  执行步骤  预期结果 1.问:你在测试中发现了一个bug,但是开发经理认为这不是一个bug,你应该怎样解决? 首先,将问题提交到缺陷管理库里面进行备案. 然后,要获取判断的依据和标

软件测试常见面试题

软件的生命周期(prdctrm) 计划阶段(planning)-〉需求分析(requirement)-〉设计阶段(design)-〉编码(coding)->测试(testing)->运行与维护(running maintrnacne) 测试用例 用例编号  测试项目  测试标题  重要级别  预置条件  输入数据  执行步骤  预期结果 1.问:你在测试中发现了一个bug,但是开发经理认为这不是一个bug,你应该怎样解决? 首先,将问题提交到缺陷管理库里面进行备案. 然后,要获取判断的依据和标