社区首页 >专栏 >工具推荐 | 项目日志模板

工具推荐 | 项目日志模板

前端老王

发布于 2020-11-11 02:15:30

2K0

文章被收录于专栏：前端时空前端时空

“工欲善其事，必先利其器

前言：本文从一个前端开发程序员的角度，对工作中如何记录工作任务、沉淀项目经验等方面进行探讨，可能并不是一套适合所有人、所有岗位的方法，而是希望以此抛砖引玉，结合实际情况，找到适合自己的方法。

如果大家有任何想法，欢迎留言互动~

缘起

日常工作中，我使用幕布 App 来记录项目的开发情况，以前是用「任务清单」或「周报」的形式记录下每周的工作情况、问题和思考，相对来说简洁、直观。

而随着读过的书和写的代码日益增多、~~也随着~~头发~~日益稀疏~~，发现「任务清单」存在一些局限性

任务清单的局限性

视角专注于任务

不可否认，从做事的角度来看，视角专注于任务有不少优点，可以使任务列表简洁、高效，维护方便，释放脑力。

换句话说，任务清单是将项目中自己负责的部分拆解成一个个可执行的任务。

然而这也导致了每次完成一个项目，某种意义上自己只是完成了任务，关注点只局限于与自身相关的任务。

可能一种糟糕的情况就是项目完成了，对自己来说无非写了几个列表页、详情页、几个弹窗，却不了解这些页面解决了业务上哪些痛点。

可能另一种糟糕的情况就是，N 年开发经历，不是有 N 年经验，而是 1 年经验用了 N 年。

项目复盘效率低

不知道大家有没有类似的经历，每当到了项目复盘、年度总结、或者在简历上填写项目经历时，会有一种无从下手的感觉。

虽然借助于「任务清单」来复盘项目，理论也是可行的，但这样会花费较多时间、精力在「任务清单」中查找、整理相关记录。

经验沉淀效率低

这一点其实和项目复盘效率低类似，相关信息过于零散、非结构化。

解决方案的探索

期望

基于以上三个痛点，可以简单整理出三点期望

视角基于项目整体
便于项目复盘
便于经验沉淀

问题

可能存在的最大问题：懒。

主要体现在：

原先只需要简单记录任务相关，现在要记录项目的方方面面，记录量更多、记录复杂度更高。
原先如果同时做多个项目，可以记录在一起，现在需要分别单独维护一个项目日志。
尽可能完整地记录项目中遇到的问题、思考

而这些其实只要克服一下自己的惰性，走出舒适区，就 ok 了。

方案

视角基于项目整体

原则：设想自己的目的是为了推动项目总体进度、提高项目整体质量，尽可能全面且必要地记录项目信息，可以多从项目其他角色的角度出发去思考、记录问题。

例如，思考是否有性能更好、交互体验更好的解决方案？

又或者换个角度，从产品角度，多思考思考需求的原因是什么？目的是什么？设计是否合理？如此思考或许有助于砍需求，或许有助于加深对业务的理解。

又或者再换个角度，从项目经理的角度出发，多关注一下各个关键节点：提测时间、上线时间、可能存在的进度风险等……

把以上这些问题，记录到项目日志中，而重点是这个思考的过程。

总之，在一个项目的合格执行者的基础上，多换位思考，借助于项目日志，或者潜移默化、或者刻意练习地成为一个项目的推动者。

注：需求评审会时，是一个很好的“换位思考”的场合

便于项目复盘

单独记录、整理项目流程，亦可作为下一次项目的 checklist
单独记录项目中遇到的问题，面试中经常会被问到“你在项目中遇到哪些问题以及如何解决的”
记录一些项目信息（项目目标、项目需求、项目例会），以备项目复盘

便于经验沉淀

这一点其实和项目复盘效率低有类似也有交集，都是将零散的、非结构化的信息整理在一起。

不同之处在于：前者的出发点是项目，是为了复盘项目，而这一点的出发点是自身，主要目的是为了提高自身竞争力。

所以，参考了 PDCA 循环（plan 计划、do 执行、check 检查、action 调整），结合了下自身，整出了个 4P 记录：流程（Process）、遇到的问题（Problem）、迭代的规划（Plan）以及总结出的心得、方法论（best Practice）

“注：示例图仅供参考，可以结合实际情况调整

流程（Process）：整理项目流程，亦可作为下一次的 checklist

遇到的问题（Problem）：记录遇到的问题，如何解决的，以及为什么会出现这个问题

迭代的规划（Plan）：结合对项目的反思、思考，列出具体可执行的规划

总结出的心得、方法论（best Practice）：对成功的经验加以肯定，并予以标准化

注：经验沉淀部分使用的是最终版方案内容

项目试水

今年年后负责的一个新项目中，我尝试基于项目的角度来记录工作。

最主要的改动就是，这个日志中只记录一个项目的工作，同时也整合了「任务清单」的优点，改名「工作进度」，换汤不换药。

开发记录：用于经验沉淀，记录开发流程、问题、迭代计划和方法论。
项目概述：简要记录项目信息。
版本需求：简要记录项目各版本需求
开发内部讨论：记录项目例会之外，工作群里的讨论信息，以便交付项目时标明改动项。
相关文档：收集项目相关的各个文档链接，方便查找。
工作进度：相当于之前的「任务清单」
项目例会：简要记录每一次例会的情况，大致了解 done、doing、to do 即可，或贴入会议记录幕布的链接。

以上便是「项目日志模板」的雏形，

首先说说感受，连我这么懒的一个人，都一直坚持维护了 10+ 周直到项目告一段落，说明不麻烦。

然后效果方面，之前的三个小期望都实现了，

视角基于项目整体
便于项目复盘
便于经验沉淀

甚至还有一些别的收获，

加入开发内部讨论模块，可以在项目提测时，标明未更新在 PRD 上的改动项，以方便测试人员测试；
加入相关文档、项目例会模块，可以方便相关信息的查询，节约时间。
保留了工作进度，即「任务清单」，无缝衔接，并在此基础上，为每周简单标记了版本迭代记录，并标明重要时间节点（提测日期、上线日期等），无形间提醒自己要把控好开发节奏。

总之，个人还是很满意这次项目日志的试水。