从0到1设计一款B端产品,我的反思和总结

28 评论 14856 浏览 147 收藏 12 分钟

笔者负责了一款B端产品从0到1的设计过程,包含需求沟通、产品规划与设计、产品开发、产品测试和产品上线和运营,笔者对各个方面存在的问题进行了反思总结,与大家分享。

很多产品经理入行后,可能一直在做迭代优化的工作,没有机会参与到从0到1设计一套产品的过程。

相比较他们而言,我是比较幸运的,在刚入行进入现在的公司一个月后,因为公司产品人员的短缺,加上我们老大一直看重我,想让我快速成长,直接让我负责公司接的一款新的产品。

所以我经历了这款产品的需求沟通、产品规划与设计、产品开发、产品测试和产品上线和运营的整个生命周期,下面我也会从这几个方面来阐述。

一、产品需求沟通

产品的需求沟通,因为这一款产品是铁路行业某甲方定制的关于施工安全的产品,所以我们要去和甲方爸爸沟通需求。

在沟通之前,我根据以前学习的知识,提前梳理了产品功能要点,准备好了录音笔,信心满满老大的陪伴下去找甲方爸爸进行需求沟通。我天真的以为需求沟通的过程一定会和想象的那样,开始需求沟通的时候,我才知道我想多了。

需求沟通的现场就像是在菜市场一样,大家每个人都有自己的想法,当有人突出自己的想法时,就会有人出来反对,这样导致了沟通效率非常的低,讨论了三个多小时,我才记录了不超过五条的需求记录,后来因为甲方爸爸们有其他的事情,这场需求沟通会就结束了。

没办法,我只能回去反复听录音,进行需求的记录和梳理,当我把需求梳理完后,拿给甲方爸爸确认需求时,还好甲方爸爸比较认可,让我们依据现有的需求去设计和开发。

二、产品规划和设计

在产品规划和设计阶段,由于对客户的用户场景没有了解到位,又因为在与客户沟通需求的过程中,专注于客户提的需求,并未从产品角度对用户提出的需求做出自己的判断、并未在用户需求的基础上做出超越用户需求期望的产品、并未考虑客户提出的需求是否就是客户真正的需求,这样导致了产品上线和运营过程中,很多甲方提出的需求和我们依据判断做出的功能并没有用;

同时甲方应该关注的但是没有提出的需求,并没有规划到一期产品中,比如说时数据统计和查看,统计数据导出功能等;

在产品设计过程中,并未对产品需求进行整体规划,急于用axure画出产品的原型图;在用axure画产品原型图的时候,过于在意产品原型的逼真性而忽略了产品各功能之间的业务逻辑,以及一些重要的功能需求。

在输出需求产品需求文档时,因为缺少软件设计经验,所以对于产品很多功能点的业务规则考虑的不够细致、和完全,导致在开发过程中增加了开发的成本。

在产品设计的过程中忽视了客户使用时的体验,增加了用户使用的时间成本。

三、产品开发阶段

在产品开发阶段,由于是第一次负责与开发进行沟通,因为经验的不足和对于产品底层的业务逻辑不熟悉,导致在于开发和UI进行业务沟通时不自信,从而影响了产品的开发;

由于产品规划和设计阶段,需求文档中对于需求写得不是很详细,增加了与开发沟通的时间成本;

另外在需求文档更新后,并未于老大及时确认,导致给开发的需求版本不完整,导致在后期于开发团队沟通中出现扯皮现象。

四、产品测试阶段

1. 平台测试阶段

在平台测试阶段,对测试的流程不熟悉,不知道从哪些方面和角度进行测试,只能够测试大的功能点,对于每个功能点细节方面的要求不熟悉或者不知道,从而使产品在细节方面还存在很多的问题。

2. 联合测试阶段

在联合测试的时候,沟通协调出现了问题,导致在现场测试过程中出现了很多状况,浪费了很多的时间。

例如,在进行测试之前未提前告知各方我们测试的时间,测试的功能点是什么,导致在现场测试出现问题时,不能够及时的找到解决问题的人员,从而在现场浪费了很多的时间。

五、设备安装和移交阶段

在设备安装和移交的时候,由于在最开始时并未将移交的流程和注意事项列清楚,导致在设备移交和安装过程中影响了安装效率和以及设备上线使用的进度。

六、数据上传阶段

在处理地图数据期间,出现了失误的地方:

例如,最开始时,未彻底该清楚超软件和服务器的功能点和与我们平台业务相关的功能点,导致在测试阶段的数据处理,出现多次的问题,从而在测试阶段浪费了很多的时间;

在处理正式地图数据时,专注于处理地图数据,而未考虑地图数据的整理流程,导致地图数据上传至服务器上无法使用;

在处理地图数据之前,未将地图数据在服务器上的命名规则理出来,导致数据出现问题,影响了测试和数据上传的进度。

七、产品上线运营阶段

在产品上线运营阶段,主要任务是监控平台日常数据和测试平台的bug,不断完善系统,因为考虑的不全面,只注重PC端和安卓版app的功能测试,忽视了对苹果版本各版本的测试;

监控的日常数据未及时向对应的相关负责人汇报,导致相关负责人对平台的数据运行情况不知情,不了解等。

八、自我反思与总结

通过这个项目的需求沟通、产品设计、产品开发、产品测试到产品上线,我了解这个产品整个生命周期。

这个项目让我学到了很多的知识,从开始对于软件产品的知识的空白到有了一定的了解,让我知道了在产品需求沟通、产品规划和设计、产品开发、产品测试以及产品上线过程中需要怎样去考虑问题,更让我知道了自己的很多短板。

在和客户进行产品需求沟通时,一切先以客户为中心,将客户所表达出的所有需求都记录下来,然后对客户的需求进行整合和思考,并依据自己的理解提出自己的建议,向客户反馈,进行需求确认。

在产品规划和设计时,不要急于画原型图或者把产品表现出来,而是要花时间理清楚各需求之间的逻辑关系,然后将各需求之间的功能需求进行优化组合,将所有的业务逻辑关系理清楚之后,再考虑产品的表现方式和输出原型图和需求文档;在编写需求文档时,尽量全面的将自己考虑到的细节列出来,进行组合。

在产品开发的过程中,要非常熟悉产品的业务逻辑,在与开发沟通过程中,要先搞清楚问题,然后在进行沟通,提高沟通的效率,同时在进行问题反馈的时候,要有理有据,最好让开发能够直观的看到问题在哪里,能够直观的了解产品需求。

在产品测试时,首先要明确测试的目标和所要达到的效果,然后列出测试的流程和测试要点,但是在测试的其他方面,还要继续学习。

在产品上线运营时,首先要从产品需求开始梳理产品现阶段是否能够满足上线要求,整理上线前所需要的各种数据,了解数据是否准备充分和完整,及时协调各合作方进行配合,将数据准备和工作及时汇报,让领导了解到具体的进度。

1. 工作方式与思考方式

  1. 做事之前缺乏计划性,即使做了计划,有时并未按照计划实施;做事习惯一步到位,未有将事情按照轻重缓急进行合理的安排和协调;
  2. 思考问题没有框架意识,思考缺乏层次性,导致思考问提升容易忽视细节;
  3. 做事急于完成工作任务,缺乏必要的思考,当出现问题时,急于询问,缺乏自己寻找解决问题方法的意识;
  4. 学习浮于表面,并未深挖学习的内容,知其然,不知其所以然。

2. 思考与改进

  1. 最主要的时改工作方式和思维意识,做事之前做好计划,并严格执行;接收工作任务之后,不急于做事,而是要先思考,搞清楚问题之后,再执行;思考问题要梳理框架意识;
  2. 工作学习过程中遇到问题,不要急于询问他人,首先要自己想办法去解决,多尝试几种方法去解决问题;在解决问题和学习的过程中,要静下心来,仔细思考,要知其然,还要知其所以然。

3. 工作技能学习提升

  1. 在完成工作之余,学习公司现有的产品,了解和分析个产品中的业务逻辑,在熟悉公司现有产品的过程中,提高自己的逻辑思维,加深自己对产品业务逻辑的理解;
  2. 学习现有的产品视频资料,完成交互设计师系列课程的学习,并尝试将在课程学习到的知识用在实际的工作中,提高自己的工作效率和工作技能;
  3. 了解行业最新的行业知识,以及行业中同类产品的知识,加深对行业知识的了解,拓宽自己的知识面。

 

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

题图来自Unsplash,基于CC0协议。

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 我一直心存疑惑,为某个客户单独定制的产品,是否是正真意义上的产品?如果是单客户,是以客户满意,快速交付为目标!而一个真正意义的商品要考虑市场和通用性!

    回复
    1. 这就是saas产品爆火的原因

      来自辽宁 回复
  2. B端相对C端来讲,不像C端那样重视极致的个人用户体验。
    B端重视用技术实现业务流程的优化和再造,去提升企业业务运营、经营管理的效率,根本目标直指降本增效。
    B端对业务的理解和深化积累及其重要,否则在业务主导的情景下,极易被灵魂拷问业务逻辑是否合理、价值在哪、带来多少产能提升,减少多少人力。

    来自广东 回复
    1. 说的不错,确实是这样

      回复
  3. mark

    来自江苏 回复
    1. 谢谢支持

      来自新疆 回复
  4. 其实有想法的甲方在需求讨论过程中能提出意见,还是比较好的;最可怕的是那种前面过方案都感觉挺好,等开发了一半以上,才开始各种提想法的

    来自浙江 回复
    1. 我们的甲方是我们开始开发后就没有问过了,项目还是有我们主导,就是开发结束后,上线运行的时候发现了一些问题,但是都在放在二期了

      来自新疆 回复
    2. 那感觉合作起来还是挺舒服的

      来自浙江 回复
    3. 是的

      来自新疆 回复
  5. 反思部分有同感,建议拿到需求后:搞清楚需求目的——梳理场景——画出流程图(框架图)——出方案

    来自河北 回复
    1. 嗯嗯,谢谢建议,产品升级改造的时候,梳理需求,我就是这样搞的

      来自广东 回复
    2. 都是被逼明白的,哈哈,加油

      来自河北 回复
    3. 😂😂😂

      回复
  6. 尽快从服务/软件外包型的公司离开。一个产品如果被先入为主的设置了“甲方”,多半做出来的产品是很糟糕的。因为你内心中已经有了2个矛盾的小人:1个是你作为产品经理的直觉,这个直觉来源于你的经验也好,市场调研也好,用户同理心也好,总之作为产品经理个人的那部分东西,不断积累这个东西就有你个人的产品方法和产品观。
    另外1个是作为甲方爸爸,不断以威严的形象在你脑中浮现,逼迫你不断的去听录音,然后若有所思,实际蒙圈的猜测甲方爸爸的意图。
    两个小人交锋结果必然两败俱伤,结果就是作为你自己的那个小人偏体鳞伤,根本就涨不到。

    以上是我面试了不下30个外包性公司产品经理,而无一幸存之后得出的结论

    来自广东 回复
    1. 嗯嗯,谢谢你的评论,我可能没有描述清楚,虽然这个产品是甲方定制的,但是这个产品后面的功能需求都是我们说了算,甲方只是给建议

      来自江苏 回复
  7. 很真实,认识很深刻,自我剖析也很清晰~希望能像你一样尽快转行成功

    来自湖北 回复
    1. 谢谢支持哈,相信自己,一切可以的,有问题,可以互相交流!

      来自江苏 回复
  8. 很多都感同身受!点赞

    来自湖北 回复
    1. 嗯嗯,是啊,会遇到很多的事情,而且是意向不到的

      回复
    2. 我刚才看了你的提问,我想问一下,你们现在和甲方有没有就某一版需求文档签订合同,如果签订合同了,甲方要改需求的时候,你就把那一版需求拿出来,就说当时确定的需求就是这样,如果要改,或者加钱或者怎么样;一般签订合同会允许甲方更改百分之几的需求,多了就不行,所以,如果签订了合同,你就当时的需求做,给甲方说可以修改几个需求,如果多了,就不行,或者就加钱。这个改需求肯定要控制,不然你会累死和被折磨死,反正开发完,他们不付钱,你不给源码,等他们甲方催的时候,你不用急,他们急,在这过程中你要把把门要求更改需求的记录和资料收集和整理好1

      来自新疆 回复
  9. 感谢分享

    回复
    1. 谢谢支持!

      回复
  10. 我是从ui转向产品,第一个产品是公司研发性项目,客户业务不明确,给客户推业务方案,完善业务之后定需求,不断的被开发挑战,不断的修改,挫折很多成长也很大,到目前为止产品还没有正式开发完成。

    来自上海 回复
    1. 我是从人力资源管理转的产品,可能挑战性比你还大,慢慢学习,慢慢成长呗,一起加油!

      回复
    2. 我也是UI想转产品,可以加您个好友吗, 🙄

      来自广东 回复
  11. 写的还不错。比较实际

    来自浙江 回复
    1. 谢谢支持哈,不断总结才能成长啊😁

      回复