• 《人人都是产品经理》读后感


    之前读书, 一般看的都是技术、算法、数学、哲学这些方面的, 为什么突然想看这本书呢? 身为一个开发人员, 每天打交道最多的, 除了开发和测试, 就是产品了. 还记得我刚来公司的时候, 在和产品的沟通过程中, 听到最多的话估计就是: 你要懂产品, 你懂了就不会做错. 确实有很多需求, 听到后自以为是的觉得自己 get 到了点上, 然后闷头哼哧哼哧的做完了, 结果交到测试手上之后, 发现做的根本就不是人家想要的. 这点上公司的测试前辈教了我很多, 包括如何去和产品沟通需求等.

    后来我想了, 为什么和产品的沟通上总是不到位呢? 其实人家早就告诉我了. 要懂产品. 你在和身边的开发沟通时, 会觉得费尽吗? 不会, 因为同为开发, 他说的你都知道, 你说的他也能听懂. 这感觉有点像代沟, 你和身边的大爷大妈根本聊不到一起, 但是人家大爷大妈凑一堆, 能聊一整个下午.

    所以, 为了之后能够和产品在沟通上更加顺畅, 最好的方式就是, 你也是一个产品. 但是, 术业有专攻, 咱自己几斤几两还是有点掂量的, 做不到专业, 了解总可以吧. 这时, 正巧这本书出现在了我面前, 那没办法了, 你困了的时候, 面前就有个枕头, 还能不用吗?

    通读一遍之后, 书中的大部分专业知识我没做深入的研究, 不过也学到了不少.

    什么是真正的问题

    如果现在提出了一个需求: 一个装满货物的货车, 高3.1米, 要过一个3米高的山洞, 怎么办?

    在拿到需求的第一步, 不是想方设法的解决需求, 而是要先了解这个需求背后更本质的问题, 比如:

    • 为什么要过山洞呢? 可能是为了运货, 所以过山洞并不是需求本身, 只要能将货物运到, 不过山洞也可以.
    • 除了山洞有没有其他的路? 如果旁边正好有一条环山公路, 就可以作为备选方案, 具体考量绕远的路程是否能够接受.
    • 发生的频率有多高? 如果只是这一次的临时需求, 完全可以再叫一辆小货车将货物分摊, 就可以过去. 如果是每天都要发生的, 那可能长远来看, 扩建山洞的长期收益更高一些.

    所以, 当拿到需求的时候, 不应该只关注需求本身, 而应该想一下需求解决的背后问题. 了解的多了之后, 可以解决需求的途径也更多了. 可能在刚听到需求的时候, 要额外开发很多内容, 但其实改个字段就解决了.

    需求也分轻重缓急

    用户的需求总也满足不了, 很多年前, mp3还流行的时候, 手机如果增加了听音乐的功能就会成为一个亮点, 如果有一款手机不支持听音乐, 那也没什么, 毕竟功能还没有这么普遍. 但是现在, 手机带有听音乐的功能, 已经成为默认的标配了.

    那么什么才是最重要的需求呢? 可以从以下几个层面考量:

    • 真实: 需求是否是真实存在的. 比如运营提了个想给后台加上图片 ps 的功能, 这玩意有更专业的工具使用. 即使真的做了, 可能也不会用到.
    • 刚需: 需求是否强烈, 如果不做能不能忍受. 比如做了一款聊天软件, 那么聊天就是刚需, 必须要做. 关于这点我还没有理解的较为透彻, 之后慢慢体会吧
    • 高频: 需求发生的频率高不高. 如果是每天都会发生的场景, 那优先级自然要相对高一些.

    不过现在在做的时候, 需求的优先级一般都不是由我来判断, 毕竟我不是提需求的人, 不过可以在提出需求的时候, 先自己悄悄的判断一下, 当长此以往, 发现我判断的优先级与其真实情况相符, 那我就不一样了.

    思维深度

    在对问题进行剖析的过程, 有以下几种思维模式.

    1. 以方法为中心的思维模式. 这个时候, 通常是别人来告诉你该怎么做, 需要将明确的目标摆在你面前, 通常不会去问为什么. 这个时候容易陷入努力的去做一件错误的事情. 就比如需求没有理解清楚.

    2. 以问题为中心的思维模式. 这种人, 经常会思考为什么, 但是却从来不想该如何去做. 缺少执行力.

    3. 先问题后方法的思维模式. 先弄清楚问题是什么, 然后去想解决方法. 需求就摆在面前, 但条条大路通罗马, 要从这条条大路中找到最合适的那一条.

    明眼人一看, 都知道第三种才是最好的. 但知道和做到是两回事, 做到和做好又是天壤之别. 努力向着美好的前方前进吧. 少年.

    生活中处处皆产品

    举个简单的例子, 房屋装修. 这时候就需要进行需求的采集, 以达到用户想要的效果. 下面是两种需求的采集形式:

    1. 询问想要装修的风格. 比如客厅需要吧台吗? 厨房需要连通吗? 卫生间希望放到什么位置?

    2. 询问生活习惯. 比如平常周末会做什么呢? 一般几点下班回家呢? 平常比较喜欢什么颜色? 喜欢阅读吗?

    相较而言, 第一种需求的采集就相当于直接向用户要解决方案, 而第二种则是通过用户的生活来主动发现需求, 然后应用专业素质来给出解决方案.

    就比如房间的灯光. 通过主动发现需求的过程, 可能就会针对不同的场景给出不同的解决方案. 客厅的开关放到进门伸手就能够到的地方, 书桌放到光线刚刚好而又不刺眼的地方, 如果晚上看书多, 就需要放到灯光的角度等.

    通过主动发现并采集需求, 来给出最合理的解决方案, 而不应该是仅仅去询问应该如何去做.

    总结

    当然, 书中还有很多其他内容, 不过自我感觉现阶段还接触不到, 先选择性忽视.

    本书通读了一遍, 很多内容没有记住, 只是从记忆比较深刻的内容之中挑选了几处. 虽然看过之后, 并不能让咱具备产品经理的职业素质, 但还是受益匪浅. 而且最让我佩服的就是, 我从中学到的很多内容, 早在平常的工作中就已经被各位前辈教导过了. 产品思维的培养不是一朝一夕的事, 努力成为更好的自己吧.

    路漫漫其修远兮, 在平常多用产品的思维来考量自己开发的产品, 倒也不失为一件妙事.

  • 相关阅读:
    bzoj3007: 拯救小云公主
    bzoj4316: 小C的独立集
    PostgreSQL Replication之第三章 理解即时恢复(3)
    PostgreSQL Replication之第三章 理解即时恢复(2)
    PostgreSQL Replication之第三章 理解即时恢复(1)
    PostgreSQL Replication之第二章 理解PostgreSQL的事务日志(5)
    PostgreSQL Replication之第二章 理解PostgreSQL的事务日志(4)
    PostgreSQL Replication之第二章 理解PostgreSQL的事务日志(3)
    PostgreSQL Replication之第二章 理解PostgreSQL的事务日志(2)
    PostgreSQL Replication之第二章 理解PostgreSQL的事务日志(1)
  • 原文地址:https://www.cnblogs.com/hujingnb/p/13437773.html
Copyright © 2020-2023  润新知