毕业后入行产品的这一年,我踩过哪些坑?

9 评论 10368 浏览 51 收藏 11 分钟

本文作者主要总结了自己在毕业后入产品这一行里,踩过的坑和学到的一些知识。一起来看看~

还没毕业的时候,因为毕竟欠缺相关经验,我进入了一家做智能硬件的创业公司实习,从此开始我的产品之路。从去年4月份到现在在这里也有一年多时间了,虽然平时有写工作日志,但还没有系统全面地复盘总结。得承认,还不是因为懒。

很幸运,我的主管也就是我们公司的产品总监,他是国内一流院校毕业的工科生,有10年的行业经验。令人惊讶的是,他好像样样都懂,尤其是技术层面,而且逻辑清晰、思维敏捷,可以快速从复杂的业务流程中理出头绪并得出可供参考的方案,虽然可能不是最优的方案,但能够在短时间做到这点我很佩服。

一开始主要是熟悉当前运营的几个平台,以及业务流程和功能逻辑。那时候我们平台组的产品就我老大和我俩人,遇到问题我只好去问测试和开发的小伙伴,因为老大忙,我也只能挑晚上下班后去打扰,一开始熟悉的速度也慢,跟开发讨论问题都没有底气,自信心明显不足。

开始熟悉

(1)打基本功

慢慢地老大陆续交给我一些我们内部平台和后台系统中某个功能点的设计,单纯的进行某个功能点的设计,跟开发讨论出方案并执行落地、上线,这个阶段的我更多是一名执行者和初级的推动者。

老大其实是做好需求分析和功能设计了,我的任务就是帮他把构想转换成原型交互、文档。这一阶段就是在跟团队磨合,打基本功。

(2)承担责任

后来老大交给我负责我们唯一的对外开放的平台型产品,这个平台其实作为我们很多业务的入口和展示有一定的战略作用,但由于早期的人手不足,在开发上线后一直处于疏于管理的状态,没有及时的迭代。很多业务端的需求还没有实现平台化,而且与市场上的竞品相比有一些差距,平台可以说是“百废待兴”的状态。

(3)需求管理

随着我对这个开发者平台的接手,越来越多的需求直接或间接从业务端导给我,这时就涉及到了对需求的管理以及其优先级的判断,这就对我提出了更高的要求。我需要站在更高的角度去审视整个产品,梳理出所有的功能、业务逻辑,从而去思考我们要做的需求在整个产品中的实现方式。

(4)项目管理与封闭开发

前段时间,我们有一个内部的平台需要开发,因为老板催得紧,我们快速地成立了一个不到10人的小团队赴外地进行封闭开发,我有幸作为项目owner负责项目的整体质量。

从最初的交互设计到与视觉定稿、评审开发、与开发沟通、测试验证,到最后项目按期完工,我发现封闭开发的效率还真的是高,有问题一说大家一起讨论马上就能出方案。这对我来说真的是很宝贵的经验。

(4)竞品分析

这个工作平时做的较少,也没有人要求做,因为我们的产品本身就已经很多需求在排队。我自己会偶尔看看我们主要的竞品的平台,保持持续地关注,分析思考各自的优势与功能的适用场景,并定期更新竞品分析报告,更新的频率一般是一到两个月一次,可以看到竞品最近迭代了哪些功能和内容。

(5)兼容性考虑

同时我负责的平台跟公司其他系统平台是有数据流通的,所以针对某些功能的设计需要考虑到跟其他平台的兼容性。比如:我在新的版本中要增加几个字段,那这些数据结构就变了,因为开发会改变新数据存入数据库的表结构,那对于以前的老数据如何兼容?

因为老数据是没有这些新增的字段的。

踩过的坑

(1)需求理解不一致

开发、测试对业务流程、版本要达到的目的理解不充分,不清楚需求的意义以及它能解决的问题。而且是发生在项目开发阶段之中,评审会已经通过了并且都已讲过的……所以开发过程中的及时沟通还是很重要的。

(2)需求的变更没有保持团队的信息同步

导致开发测试信息不对称,变更的需求测试不充分。我们是一个团队,如果真要变更需求,一定要保证大家信息同步,而且开发过程中尽量不要做需求变更……程序猿们会很难受。

(3)周五进行版本升级,线上出了问题

周五晚上进行的版本升级,结果到线上发现有严重的bug,只好晚上熬夜解决,最终看当天是解决不了的,跟老大商量还是决定做了版本回退,血的教训。

(4)伪需求的开发

业务端提的需求,而且还是高优先级插队进来的,我们开发完,后来他们又说其中某个模块又用不到了……需求的真实应用场景没有分析充分,业务端过来的需求有的他们自己都没想好,需要更合适的方法去解决。

(5)早期的思维错误

为了赶进度而出的原型,未考虑完全,存在明显的硬伤,即使评审也问题很多,对开发无益。应该在保证自己工作质量,即使因此delay了也不要为了赶进度强行输出,这样的方案一定是漏洞百出的。

(6)兼容性问题

平台的某个模块升级,而未考虑到跟它相关的老数据的兼容性而出现问题。这个设计缺陷当然就被我们测试leader抓住了,我接锅……

后来老大语重心长地引用《孙子兵法》中“先为不可胜,以待敌之可胜”来勉励我,让先武装好自己,等把自己武装到没有弱点,再去发现敌人的弱点。

周会的收获

每周一早上我们会召集研发各部门负责人的周会,CTO主持会议,老大让我每次都参与旁听, 因为涉及到公司所有业务线的所有环节,我更多时候是懵逼状态,但听的多了自然是对自己的工作有些收获与启发的。

(1)一个需求的导入需要思考

现存哪些问题–>期望达到的目的–>功能使用的场景–>验收要达到的效果–>期望完成的时间点和优先级。

(2)闭环意识

任何时候都要有闭环意识,多思考一个功能/产品在整个业务闭环起到什么作用。

(3)关注原始需求,思考最优的解决方案

因为有些需求,看似是一个需求,要挖掘出他们的根本需求,他们为什么提出这个需求,遇到了什么问题,实际上总有更好的实现方式,最好的做法不是满足客户/用户的需求,而是在满足他们的基础上,让他们感到惊喜。

其他的点

(1)身兼多职

因为我们还是创业公司,人手不多,所以在我们规划版本时需要身兼多职,不仅要规划好这个版本要上的功能,还要做好交互设计并尽可能的去照顾用户体验,同时还要兼任项目经理,保证项目按期完成。

(2)设计

交互设计的能力在这一年中得到了极大提升,最开始用axure连动态面板都不会用,原型丑陋到满屏的黄色隐藏框,因为要做多个弹框,到现在我还保存着最初的原型文件。

(3)运营

因为我所负责的是平台型产品,用户一般是跟我们合作的TOB的客户和一些开发者,所以这里没有怎么涉及到留存、促活以及数据分析,就是做一些日常的平台维护与审核工作。

(4)技术

平时跟开发测试沟通的多了,“技术黑话”不得不去了解,接口、表结构、写死、post请求……

代码打包、部署,以及前端页面的“检查元素”查看请求的后端接口与响应……为了更顺畅地跟程序猿哥哥们沟通,这些还是很有必要加强的。

 

作者:舅本华,微信公众号:舅本华

本文由 @舅本华 原创发布于人人都是产品经理。未经许可,禁止转载。

题图来自 Pexels,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 很真实!! 🙂

    来自广东 回复
    1. 切身体会 :mrgreen:

      来自浙江 回复
  2. 很实用,可否弄个微信群,可以和请教呢?谢谢

    回复
    1. 微信群还是算了吧,就咱们俩多尴尬,可以关注我公号,我都会及时回复的 😡 。

      来自浙江 回复
  3. 1024

    来自浙江 回复
    1. 2的十次方? 🙂

      来自浙江 回复
  4. 受教,已关注公众号。

    回复
    1. 谢谢老铁。

      来自浙江 回复