今年工作有一些体会，可能记在工作小结里，也可能随意写在哪个笔记本里，我得把这些心得整理一下，要不然时间久了就遗忘了。在产品生涯中，我可能会接触到各种不同的产品，而那些产品终究会走向过去。

正如我之前博客说的，步入21世纪以来，世界变化的太快了，旧事物无时无刻都在被新事物淘汰，只有把自己当成独一无二的产品，不断升级迭代，才能让这款产品时刻保持核心竞争力。

我将从认知和实践两个维度来进行本年度的复盘工作。

认知

1. 项目和产品是有差别的

早先没有这方面的概念，从我的角度来说两者都要做需求，感觉区别不是很大。八月份的时候被调去做一个紧急项目，要求一个多月就要上线，Leader看了我的产品需求文档，问我一定要追求完美设计吗？我才开始意识到这个问题，两者还是有很大差别的。

1.1 生存周期不同

项目的生存周期包括项目的启动、策划、执行监控和收尾。项目验收交付给用户，并结项后，项目生存周期结束。产品的生存周期类似于人的成长，从出生（产品构思），到成长（产品的版本更新），到去世（产品中止）的过程。产品不存在完成的说法，因为产品是不断更新的，直到被新产品替代，生存周期才结束。

1.2 目标不同

做项目讲究在规定的时间内，利用有限的资源，高质量完成某个特定用户的需求， 而做产品是满足潜在客户一系列通用的需求。

1.3 风险不同

Leader站在公司角度和我聊过这个问题，项目的收益固定，但胜在稳定、风险低，只要想办法在把合同规定的事项完成就行了。产品的收益不固定，投入资源之后，如果做成爆款，可能获得超额的收益，但也有颗粒无收的可能性。

2. 抄并不可怕，一边抄一边创新才可怕

读书那会年少轻狂，有点瞧不起腾讯，腾讯好像总喜欢抄别人的创意，改一改就变成自己的了，然后凭借自己巨大的体量把原创挤走，达成某个领域的垄断。

工作之后从产品的角度看腾讯，心里还是很佩服的，腾讯下面的产品部门集百家所长，自己再做一些微创新，同时内部采用赛马策略，做几个侧重点不同的产品，最后选出效益最好的产品，这种方案赚钱效率无疑是最高的。

工作的时候难免会接触到自己不熟悉的领域，我一般先玩玩行业头部的系统，看看别人是怎么设计的，别人产品团队精心打磨的产品，肯定比我短时间内自己随便出的方案要完善的多。我很多时候要做的就是在他们的设计上结合自己的业务特点做加减法，这其实和走中国特色的社会主义道路有异曲同工之处，批判性地吸收借鉴，才能壮大己身。

互联网行业已经走向下半段，正在从增量市场走向存量市场，大家似乎都有相似的基因，在环境成熟的当下，更多的做一些微创新去服务用户的需求，可能会更有效率。

实践

1. 从场景中来，到场景中去

这句话是我借鉴从群众中来，到群众中去总结的。做需求的过程中有时会忘了“初心”，工作中往往从场景出发，抽象提炼出产品需求，然后可能做着做着着眼点就放在功能本身了。反复修改后产出的功能有时甚至解决不了原先场景中出现的问题，或者只能解决特定的几个问题，而不能为通用性的问题服务，那么这个功能其实是失败了。

举个例子，之前业务方提出需要把展示的数据转化成文字，我设计了一个数据映射的功能，可以把一个范围内的数据映射成文本，比如数据是30，展示的时候要自动转化成异常。我当时没觉得是什么复杂功能，结果执着于交互和设计，把最初的场景忘掉了，最后用户使用的时候，绝大多数场景都是做单值映射，他们只能设置成30-30，转化成异常。

我刚参加工作的时候闹了这样的乌龙，让我吸取了教训。现在把功能设计完后，我会有意识回归到最早的场景做验证，看看能不能解决同类型的问题，这样的思维习惯后期帮我规避了不少麻烦。

2. 不要太“信任”同事

这里当然说的不是不相信同事，团队不建立信任，就没法共同向一个目标努力。我这里的侧重点是哪怕做一个很小的功能，也要做好验证工作，不要对同事太放心。之前有个字段要改个名字，我和前端说了一下，心想这事随手改一下就可以了，没放在心上，也没记录在文档上同步给测试，结果上线了也没有改。

PM要关注产品的全流程，直到上线前也不要放松警惕，细心验证每一个功能，出问题的往往不是大块的功能，一般都是这种细节处没落实到位。

3. 建立版本规划意识

每上线一个版本，我都会把下次要发版的内容整理出来，但如果没有保持更新，这个文档在最后就会变成“废纸”。哪怕给每个需求定好优先级，开发的过程中，也会有一些新的紧急且重要的需求插队，发版文档可能会变得面目全非了，所以持续完善发版文档十分重要。

除此之外，手上会有一些既不紧急也不重要但马上就能开发好的需求，这类需求往往开发很快做好后就可以在下个版本发出去，实际上这类不起眼的需求不遵守约定好的发版规则，会给版本带来混乱，因此建立版本规划意识，消除这种可发可不发的功能的灰色地带，更有助于建立科学的产品迭代体系。

4. 明确分工，给他人留一点发挥空间

我刚工作那会，在系统驾驶舱的设计阶段，顺手把UI的活给干了，后来UI通过同事给我传递了不满的情绪，我和他充分沟通了一下，明确了彼此的工作范围，把这事化解了。

我复盘了一下，把别人的事顺手做掉，产出成果可能没他人专业，除此之外，如果功能出了问题，责任还不好划分。软件开发毕竟是团队性的工作，靠个人单打独斗是行不通的。

说起给他人预留一些发挥空间，我对此有一点小心得，有一些同事可能不是负责该产品相关的工作，对于这部分的业务和技术都不太了解，但某些会议又会邀请他们参加，我往往会向他们寻求一些界面设计的建议，保证会议所有人都有参与感，都感觉自己对产品有所贡献。这种工作方式对我后来跨项目协调工作，请求支持有着很大的帮助。

5. 如果有时间，就多跑一跑

我发现需求一复杂，用办公软件沟通就有些困难了，不怕彼此没法理解，就怕双方以为对方理解了意思，这就容易坏事了。对于复杂的需求可以采用电话进行沟通，当然如果双方都有时间，最好的方式还是拿着纸和笔到对方工位沟通，声音、动作、表情、图画都承载着一定量的信息，往往缺一不可。

在沟通结束之后，提出想法的人最好请求对方再复述一遍，保证双方信息的一致性，重要的信息传递过程中尽量避免中间有人传话，确保信息不会丢失，歪曲。

结语

还是比较庆幸能做自己比较喜欢的工作——产品经理，愿新的一年能但行好事，莫问前程，走好每一步路。