• 需求讨论的进化版


    最近一直fix bug,发现自己沟通力度不够,也引起了很多麻烦。

    以前在聚美的时候,一般产品经理会画好原型,写好详细的流转过程,甚至在最开始的时候理清所有逻辑,然后大家讨论大概两次,最后开始动手。

    我也习惯于这种方式的沟通,甚至于做的过程中不断完善细节。

    后来在鱼说的时候,我也积极地去和pm沟通,确定需求,也在思考,但是并没有站在产品或者公司角度去思考一个需求或者比较大的功能。再到后面上层干预能力比较大,自己能决定的事儿也少了,更可怕的是:自己也甘于做一个worker,而不是creater.

    如今,我越来越觉得问题的严重,这种参与感越少的工作让人乏味且导致了诸多问题。需求在诞生之初,就该全程参与,特别是在分工不细的公司团队里面。以前不会出现测试想出新的case,临时又改需求的情况,也不会出现做到一半pm发现自己的设计又二逼了。在一个不稳定的环境里面,我只能尽早地提出自己的想法,简化逻辑,也集思广益,在早期堵住所有能想到的漏洞。

    习惯的个人英雄主义的我,以往都是独自扛下来所有的困难。后来我才发现,所有的苦恼和难度都是自己给自己的。如果在最开始我拉通把整个逻辑跑通,估计难易,完全可以直接否决一些不现实的需求或者做法。pm永远只是pm,参与实现就是越界了。

    痛定思痛,以此为戒。

  • 相关阅读:
    IOC Unity的配置问题
    编译时常量与运行时常量
    Revit二次开发,将插件按钮(Ribbon)变灰或者隐藏
    C#类库读取App.config配置文件
    winform固定窗体大小
    Revit二次开发,获取模型版本信息
    JavaScript:文件保存自動下載函數:Save和SaveAs
    JavaScript:年月日時分秒設置
    JavaScript:字符串の空格刪減和字符刪減功能
    JavaScript:獲取數據の類型
  • 原文地址:https://www.cnblogs.com/freephp/p/4914268.html
Copyright © 2020-2023  润新知