在日常工作中，每周的工作都充实而有所沉淀吗？是否觉得自己在假忙碌？如何有序推进工作进展，有序记录自己的工作？本文作者结合自身实践，讲述了在方法论上对自己工作推进记录的一张表，迭代了四个版本，希望对你的工作与成长能有所帮助。

从技术转产品上的磕磕碰碰

我是技术出身，Java后端，不过从一接触代码我就热衷于去创造一些自己不经意间想到的一些小工具或者小框架，希望做一个可以给同行使用或者有帮助的小产品，或许算不上产品，毕竟当时并不觉得产品能有技术好上多少。

不过现在回过头来看，自己当初做的开源项目InChat，从0.1发布，写技术说明文档，建立QQ群，收集好友需求建议，再持续迭代下去，其实和做产品一样，甚至当时的0.1也是基于MVP的概念，把最核心的工作优先实现并推出市场。

转产品至今有一年了，这期间也慢慢让我看到了自己作为产品的一些优缺点。

沟通、推进、开发协调等等，在自己转产品后从零到壹孵化出一个To B的小产品，在这期间最让我得心应手的就是执行性的工作与技术开发的推进，我擅长根据具体的反馈，参考竞品设计适合的功能原型，对接技术团队交流产品的业务逻辑等等，这让我在每天的工作中都推进很充实。

但是在1.0给到用户后，我开始面临产品迭代上的难题，用户需求与洞察力。

和大多数产品一样，我的产品也是基于领导的想法与资源，才顺利的落地了v1.0，不过后续的产品迭代演进，还是要基于市场、用户需求来确定。

这让我有一段时间的工作过得很混乱，乃至无从下手。

可怕的假忙碌

不知道大家是否也会经历这样的阶段，又是因什么而处于这个阶段。

在产品迭代的过程中，有段时间我多次进行竞品分析，并将市面上的竞品功能一一罗列，在下一版的迭代中也借鉴了部分竞品的功能点，并自己进行了产品设计。

不过在进行产品演示的时候，却换来了一系列的追问：“这样的功能用户一定会用吗？”、“产品目前定位是什么？”、“你的商业模式与这些功能之间有关系吗？”

你自己想的、或者照搬来的东西，不一定是这个产品所需要的。

大约是两周的工作，我觉得好像一无所获，甚至毫无推进，产品的迭代是为了更好的服务用户，让用户购买这个产品，而产品的目标用户是什么样的需求，我并没有系统的去调研，且产品的服务本身是否会因为区域、地域、人文等问题而存在一些特殊的无法复制的功能点呢？

我做的产品的医疗诊后的随访产品，而正是因为如此，在此之后我开始有计划的进行用户调研，比起外出，作为程序员我确实更喜欢一个人静静的坐在电脑前埋头做自己的工作，庆幸的是，我对于交流沟通并不抵触，如果附带目的性，那么我会更加聊得开。

我特意的到医院进行用户调研，如下表，也是最近的一次调研反馈。

表格的由来与演进

正如上面说到的，面对毫无进展的工作，且加上每周的工作总结，我突然发现自己不应该继续工作下去，应该有序的记录并推进自己的工作进展。

由此本文的核心重点“那张表”因此出现，总共用了4周左右，我迭代了大约4个版本，目前觉得较为完善且也适用于各种职业的人群使用。

如下为0.1版本，当时想得很简单，需要记录我每周的工作推进情况，所以有点像甘特图，每个工作都可能持续或者当天完成，这样的表格刚好满足我的需求。

在第二周的时候，我发现我还需要参加一些会议，同时在这周因为涉及产品的v1.1迭代开发，发现自己在沟通交流上耗费了很长的时间，且这些时间其实是没必要的，同时关于产品相关的信息/问题，在日常沟通中要保持记录。

因此，在0.2表上，我新增了会议还有当日的一些工作总结。

在下一周的工作中，我发现自己对于用户需求的调研不够积极，甚至有些排斥，因此基于自己的职业性质，给自己新增了一行“用户调研”，用来提醒自己。

同一周，在自己重新阅读自己本周工作的时候，发现自己的工作内容其实还可以再细分，让领导可以明白本周的主要工作重点是哪几个方面，然后根据他自己的想法有选择的看就好，因此对自己的工作内容进行了整理分类。

如下就是最后的这张表了。

当然，不一定每天都有时间整理，具体时间还是要根据自身的工作量来定，而且不是每一天都有得反思，有时候一次讨论对我来说说其实就是一种业务上的沉淀。

终章

这张表，对我本人而言，从我开始设计并参照着记录之后，我发现我每周的工作量增加了10%左右，通过对工作内容进度的把控，可以有秩序的安排一些小的工作进去，且自己的一些划水时间也自然的减少，自己对于未来一到两天的工作内容有大致的规划与把控，这也是我本次想要分享的。

顺便给一张程序员可以参照的表，具体内容因人而异，核心是让你有效的把控工作内容的进度，特别是多任务并行的情况下。

到点了，去加猫粮了。

 

作者：猫叔记，现架构设计（码农）兼创业技术顾问，不羁平庸，热爱开源，杂谈程序人生与不定期干货。公众号：猫叔记

本文由 @猫叔记 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自Unsplash，基于CC0协议