关于对接需求的思考

  1. 产品说想要一个登录注册的功能, 你一想, 好说, 不就是用户名密码嘛, 然后开发完成
    • 产品看到成果后: 我要的是手机验证码登录
    • 结果写好的功能基本废了
  2. 产品又想要一个登录注册的功能, 这回你学乖了, 确认了一下, 是手机验证码登录, 没问题, 然后开发完成
    • 产品拿到成果: 怎么没有验证码? 现在登录注册哪有不要验证码的?

以上情景, 你是否曾经在某个时间点遇到过? 我是经常遇到, 因此我也想过如何来避免这种功能情况.

造成这个局面的原因是什么? 很明显, 因为你们对登录注册这个功能的定义不同. 要想对一个功能达成一个统一的认知, 如何做到呢? 我没有想到什么好的方法, 只能是将功能进行细化.

功能剖析

还是以登录注册功能为例, 可能你接到的需求是: 一个登录注册功能. 而在你拿到这个需求之后的第一件事, 不是编码, 也不是设计, 而是要先化身产品经理, 对这个功能进行剖析, 将相关的内容一一列出. 如:

  1. 使用手机号登录还是用户名
  2. 是否支持邮箱注册
  3. 是否支持微信/QQ/微博等第三方登录
  4. 是否需要验证码
  5. 对密码的强度是否有要求
  6. 对密码的长度是否有要求
  7. 对用户名是否有限制
  8. 用户名是否可以重复
  9. 用户名是否支持修改
  10. 用户名不存在时, 如何提示用户去注册
  11. 是否需要找回密码功能
  12. 在可见的未来, 需求可能会如何演化
  13. 等等

    注意, 在这个过程中, 你要抛弃你的程序员思维, 不要考虑技术上的问题.

当然, 以上功能可能我们并不是都需要, 但却是我们需要考虑到的, 只有确认过, 你才能知道是否真的是不需要的功能. 因此, 一个登录注册功能, 也必然不会是用户名+密码这么简单的事情.

在对需求进行剖析之后, 你就可以拿着剖析的列表和产品确认需求, 在这个过程中, 可能会有你没有想到的, 自然也会有产品没有想到的, 也可能会有你们都没有想到的, 不过没关系, 至少你们对功能的认知达到了统一.

一开始, 分析需求的时候, 可能想的并不全面, 毕竟有些违反程序员的思维, 而且产品经理也不是那么简单的. 只能通过不断的练习, 将你的产品思维提上来. 有什么好的练习办法呢? 我不知道, 如果你知道的话希望能够告诉我. 我在每次分析并开发之后, 还是能碰到当时没有想到的问题. 感觉这玩意就像创作, 全靠灵感…

功能分析

这个时候, 你对这个功能已经有了一定的认识, 你已经知道想要的是什么了, 接下来就可以恢复你的程序员身份了, 开始着手实现这个功能吧.

而在这之前, 还有一些是需要你以程序员的身份来思考的, 你需要考虑一些技术上的问题, 比如:

  1. 如何对用户的密码进行保护
  2. 如何降低密码被脱裤后的危害
  3. 如何防止脚本注册
  4. 如何对接第三方登录
  5. 估算用户量, 是否需要增加缓存
  6. 设计功能, 并给短期的需求演化留出空间(不要实现!)
  7. 等等

至此, 设计编码之前的准备工作已经完成了. 当然, 这并不能确保你能够完全规避 对功能的定义不同 这个问题. 但至少在很大程度上降低了这种尴尬情况的概率.


以上, 只是我能够想到的方式. 如果你有更好的方案, 希望能够不吝赐教.

------------

原文地址 https://hujingnb.com/archives/407

转载请保留原文连接: 关于对接需求的思考 | 烟草的香味

guest
0 评论
内联反馈
查看所有评论
0
希望看到您的想法,请发表评论。x