提醒小程序的产品文档——大作业心得总结

在上文档这一大块内容之前，我给自己打了“内容很干”的预防针，可是到了课堂上却又并不觉得干寡。而是“干湿不分离”的。尤其是每次最后二爷都会讲到实践中的一些经历和真实做的一些文档。

我最喜欢“一起画”这个模块，视线可以跟着二爷，看资深的产品是如何一步步拆解的。

而在自己动手时，似乎又忘记了课堂上那些条条框框，画完后，讨论随之发现问题，才猛然醒悟，原来课件中的“xxxxx”是这么重要。

课件中重点提醒的几条原则一定要牢记于心：

1 表达要清晰无二义：

任务一开始写的是“已完成”而不是“已结束”。整个任务是由用户灵活配置的多个子任务构成的。这一点我一开始还在借助格子的涂色来区分不同状态。后来，前端小姐姐千竹同学提醒我，可以用结束来代表任务到达截止时间。然后可以再具体去区分完成的程度，是全部都完成还是仅部分完成。

2 扩展流程：

在成长日志页面，一开始只想到状态只有“完成”和“没完成”两种。但是由于任务下面还有很多子任务，所以子任务的完成状态也需要考虑进去。比如 5 个子任务的任务到了截止日期，只完成了 1 个，应如何给用户视觉上的反馈。

3 不画图永远就只是想法而已

一开始画的草图非常粗糙，而且是凭自己一个人的脑洞在瞎画。当直播过程中讲解给别人听时，才发现原来和后端同学理解的“规则和任务之间的关系”有很大歧义。

在没办法当面沟通清楚的情况下，语言也略显苍白。我记得当时是打开了某清单的软件 APP，然后边演示边说明我想要实现的样子，是规则依附于任务而不是独立存在的。

其实没有对错。只是同样的需求，大家因为知识结构不同，而产生了不一样的理解和解决方案。

对比 nil 同学的优秀作业，也有一些反思。还是可以继续打磨的。在做的过程中，发现自己更喜欢画各种图来辅助思考，下笔文档时还是有点顾忌到模板之类的结构。以后还是要定期输出，越写才能越不怕写。

后面 5、6、7 章内容，讲的更偏实操。项目经理那一块内容也很好的和自己实习经历联系起来。其实也是反思，去年 11 月，在某银行出差等数据来做模型报告的数据分析部分。有一次就很硬的跟他嚷起来了，现在看来自己也是莽撞了点。当时我们的项目经理月哥，就把我们拉开，“换场”到办公室外面。分别和我、和 SQL 人员交流我们各自的需求和难点在哪。

还有项目经理宁哥，我很服他的一点就是能心平气和的分析到，数据是怎么流转的，对我有什么影响，怎么样能帮我这个小姑娘在行里的规则之内，取到符合要求的数据。他还会用白板告诉我整个链路是什么样的。以及为什么不能很快的拿到数据。

而那个 SQL 人员只会说"我没办法”、“就是这样的”...“这个不紧急，优先忙上线要测的功能”blabla。等自己心情平复时，发现自己不是急着要数据，而是急一份为什么慢的解释。

所以项目经理周旋于不同的角色之间，需要一颗强大的心脏，可能会被各方问：“为什么是我”“为什么先做这个”等等之类刁钻的问题。

而在能承担更多人的情绪、分担更多人的职责顺序、且让大家心服口服的过程中，就是在向优秀的项目经理靠近的过程。

产品经理和项目经理在这一点上也非常像：和不同性格的人沟通、润滑，身子要软、心肠要硬。

还有一点是，我现在都很感激那段经历，虽然自己只是那个项目组下一块非常小的功能。但是，在春节期间收到公司邮件：项目组被评为那家银行的“优秀团队”，奖励了 10000 元（虽然和我没啥关系，但是还是很开心）。

就很贴合二爷说的，最好的团建就是打胜仗~

现在在做的小程序，我持有的是悲观的乐观主义。最后一定会做出来点什么东西，最次最次，也有自己的后援团来用。只是不知道这个东西能不能更有用一些？

且走着瞧吧。

大作业文档链接：https://kdocs.cn/l/sdXYC54iuLZD

欢迎大家批评指正，大胆质疑。

特别感谢愿意一起做点什么的千竹、flyfree、雁卿、一生何求、Peanut 花生。