复盘我的半年产品工作——管理篇

2017-11-14 09:58:00

这篇文章并不是什么高深的产品技巧，更多的是个人在产品工作中的习惯心得。俗话说得好，细节决定成败。Good Luck！

上周，部门的直属领导让我签署了转正申请表，这也标志着我半年的试用期正式结束了。半年来接触了新业务、新环境、新同事，在岗位工作上也遇到了很多问题，幸运的是有一小部分问题成功意识到并不断调整、规避。从今天起，就从多个方面来分享一下自己这半年的工作。

在加入新公司的时候，我恰好读完了刘飞的《从点子到产品》，其中他在书中提到了工作复盘后的成长，从那时起我便决定在自己未来的工作也养成定期复盘的习惯（话说半年的时间是有些长啊O(∩_∩)O~）。在这次工作复盘的过程中，一些好的工作习惯让我尝到了甜头，也辅助了我对过往工作的审阅。

工作日报

谈到日报相信很多朋友肯定会口诛笔伐它，不过此日报非彼日报，我说的这个日报不是写给领导看的，而是写给自己看的。格式与一般的日报相同，在记录当天工作的同时，也可以记下自己当时做某项需求的想法、思考方式，或者自己很傻的行为（有些像日记）。当某天重新看自己设计某个需求的想法时，可能会发现自己当初很二：前段时间在重审一个存草稿的功能时，我就发现了自己当初的设计理念非常反人类！（后续篇章会详细描述）

建议

1、使用云笔记存储

因为本地文档不易保存，多平台查阅不太方便，还容易丢失。使用云笔记的话，不管在公司或者家里都可以去编写。

2、第二天编写昨日的日志

我个人会选择第二天刚上班那会编写昨天的日志，这样顺便也可以把今天的工作计划列出来，快速进入一个工作状态。当然可能是当天下班会想着急回家，这时候的心情也不适合去编写。那如果你担心第二天会忘记的话，就可以当天去写。

3、计划可以列少一点

计划列少一点，不代表今天就做的少。如果列得太多计划，每天都完成不了的话那种心情是不是很糟糕呢？而且还会影响第二天的工作。如果自己的项目评估能力不精准的话，还是列少一点为妙。如果怕自己时间长产生飘飘然的感觉，那就可以定期制定多一点的计划。

修改记录

特殊字体颜色标注

很多人会在编写需求文档时记录一些各版本的修改点，这是非常好的习惯。现在我要说一个故事：

最近的一次项目中，开发曾找到我问：“产品狗子，这次文档你改了哪些东西？”
我满脸无辜地说：“修订记录不是说明了嘛？”
开发：“丫的！你是让我要重新读一遍需求文档嘛！改过的区域也应该标识一下吧？”
我：“大兄弟，请收下我的一个膝盖，我错啦！下次注意！”
开发：“么事！么事！产品开发是一家嘛~”

我不知道开发是忍了多久才告诉我这个问题的，从那之后我每次修改完都会将改变或补充的文字用红色标识。

原型图修订记录

大家有没有想过一个问题，一篇很长的文章你会选择重新阅读一遍吗？因为我个人会比较懒，相对于需求文档我可能会选择看各个版本的原型图，因为图形的识别效率会比文字快很多。那么问题来了：包括我在内有些人在原型的设计中没有修订记录的说明！在这次复盘过程当中我就遇到了问题，每次在对比原型的时候，我就像在玩“图片找茬”游戏。当找不到的时候，我就得阅读那长长的需求文档了，这种撕心裂肺的痛是不可言表的T^T所以，最近我也再抽出时间补之前原型的修订记录，填自己挖下的坑。

项目记录表格

设计

之前我曾写过一篇关于项目管理的文章《产品辣些事，记一次不成熟的项目管理》，在这段时间当中我就应用了一下。我把每个项目的工作细分成“ 需求设计 ”、“ UI设计 ”、“ 研发 ”、“ 测试 ”、“上线 ”这5个部分，并记录编号、需求名称、设计范围、时间、备注等，其中项目状态有“ 未开始 ”、“ 进行中 ”、“ 已完成 ”、“ 暂停 ”。

特别说明一下，每个状态可以添加不同的行背景色，我的背景色设计如下：

为什么进行中的是红色呢？因为产品岗有一个工作职责就是：跟进！红色比较突出，所以每次查看表格看到亮瞎眼的内容时，就知道自己该跟进哪些内容了。

详细的备注

写到这里，可能有些人就会疑问：前面说到工作日志也是记录一些内容，那在项目记录表格中记录是不是重复工作呢？答案是：当然不！工作日志更突出时间，而项目记录表更突出环节。在备注中你可以记下某天需求改动明细，某个同事提出的疑问，亦或者上线后出现的异常……特别是在规则修改类的需求设计中，原型、文档可能都不去设计了，那在表格中备注就十分合适了。