刚开始做出来的时候它是这样式的：
你别看它丑，但它真能用啊，CRUD不在话下，符合第一性原理🤪
后来在实际工作中，十年间兜兜转转呆过不少团队，每个团队用的任务管理工具迥异。有
- Tower
- JIRA
- Wiki
- TAPD
- 飞书文档
- 钉钉云效
基本上换个团队就要适应一个新的任务管理系统。
实际体验下来，没有一个让我有长期使用的欲望。原因主要有：
- 太臃肿。功能繁杂，对个人来说 80% 的功能用不到。
- 太慢。服务在云上，网络的不稳定让我的心情很不稳定。
- 真实场景实用功能缺失。比如周报不能基于我的任务直接生成么，干嘛还要开晨会，周会，拉进度会。
- 排期管理令人失望。这些工具往往只有一个日期字段，很难满足我对排期的细节描述。比如对前端来说，一个任务通常开发时间和联调时间是分开的。很多任务实际工时是碎片式的，不是 all in 一整段时间。
最近入职了新公司，我又翻出了自己的这个老项目。这一次，我想不如用我自己的吧。用了一段时间越用越香，我想何不做成一款产品呢。如果放在以前，这几乎不可能实现，但现在有了 AI 加持，开搞！
先上一张产品效果图吧：
线上 demo 链接 https://task-manager.dombro.site?demo=1
或者 本地部署 GitHub - dom-bro/task-manager-docker · GitHub
想到即将到来的35岁危机，产品代号就叫age35
以前只有自己一个人用时，功能就是边用边开发，想到哪写到哪，怎么用怎么写，怎么实用怎么来。但当我开始考虑做成一款对外产品时，就得重新规划整个架构。
这几周忙活下来，我发现真正花时间的并不是技术实现，反而是想清楚"这个产品到底要解决什么问题"。下面就是这几周下来沉淀出的几个核心理念。
产品哲学
归于一处
- 需求文档
- 技术方案文档
- 接口文档
- 设计稿地址
- 原型链接
所有和这个任务相关的文档都记到这个小卡片上，点开这个小卡片，就是任务的全部上下文。
实际上，实际开发中上面的文档如果组织合理的话，vibe coding 直接给 AI，你将得到一个非常惊喜的结果。
状态流转一目了然
去伪存真，从模型上来讲，状态是任务最最重要的属性，没有之一。
在团队协作中，leader和项目经理最关心的也是任务状态。
当我想通了这一点后，围绕状态如何全链路打通认真设计了一番。最终确定使用全局状态流管理，其他视图的状态流可以自由组装，而不是随心所欲的造状态。最终实现一份任务数据，处处同步。绝不能容忍去维护重复的任务。
最终实现的效果如下：
我看到的样子
时间轴
日历
leader看到的是这样式的
项目经理看到的是则样子儿的
当我改动自己的任务时，可以实时同步进度到leader和项目视角。
妈妈再也不用担心我为了对进度赶地铁去开早会了
超实用的排期组件
除了状态，任务另一个最重要的属性就是排期了。一个实用好用的排期组件能让人在繁杂忙乱的工作中有条不紊，有理有据，游刃有余。
直接上成品：
功能特色：
- ✅区分周末。“正经人谁不双休啊“
- ✅区分节假日。“排期时千万跳过节假日。“
- ✅区分已被其他任务占用。“如果明天下午已经排给了别的任务，当我点开排期时，我希望心里有数“
- ✅可以排半天。“还有按小时排的嘛，别TM卷死了啊“
- ✅可以排多段。“没有任务是两段时间不能干完的，如果有，那就再排一段“
可以说，这个组件我自己完成的非常满意。
极致轻 · 快
本地部署不上云
这是一个全栈项目，而我又不想去运维一个服务器（压力太大了🥲），那么不如让用户本地跑吧。
怎么让用户跑起来呢，如果让用户先搭建 pnpm，bun，mongodb 环境恐怕直接劝退，最后 AI 给出了不错的方案：docker一键部署。用户只需要装个 docker 环境就行啦。
✅数据完全自主
个人用户数据全在自己电脑的 mongodb 里，团队用户数据全在内网服务器上，一个 bit 也跑不出去。
✅快到没朋友
本地起的服务，零延迟
专为国内产研人员打造，拒绝臃肿
拒绝过度设计，回归任务本质，最终我只为任务模型留下了 5 个字段
- 标题
- 内容（记录相关的PRD、设计稿、技术方案等所有上下文）
- 状态
- 排期
- 备注
实际体验下来，这5个字段足够用了。
优先个人而非团队
优先保证个人用户体验，从一开始就是为个人提效而生的。
虽然我也在努力寻求转化，但我会一直把这个系统对个人用户永久免费，可以任意使用上面的所有功能。