当前位置 主页 > 云表格 >

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

2021-05-24 19:53   编辑:admin   人气: 次   评论(

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

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

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

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

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

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

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

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

  最近的一次项目中,开发曾找到我问:“产品狗子,这次文档你改了哪些东西?”

  开发:“丫的!你是让我要重新读一遍需求文档嘛!改过的区域也应该标识一下吧?”

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

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

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

  跟进!红色比较突出,所以每次查看表格看到亮瞎眼的内容时,就知道自己该跟进哪些内容了。

  当然不!工作日志更突出时间,而项目记录表更突出环节。在备注中你可以记下某天需求改动明细,某个同事提出的疑问,亦或者上线后出现的异常……特别是在规则修改类的需求设计中,原型、文档可能都不去设计了,那在表格中备注就十分合适了。

  年月+编号+需求名称+涉及范围”(涉及范围:web端、APP端、后台等)的格式,并建立“需求文档”、“原型”、“流程图”等多个子文件夹。这样后期复盘就很容易查看,也方便自己查找。

  听到很多言论说在中国程序员是吃青春饭的,那么产品经理呢,也吃青春饭吗?

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、社群为一体,全方位服务产品人和运营人,成立9年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里与你一起成长。

  • 最热文章