需求讨论的进化版
最近一直fix bug,发现自己沟通力度不够,也引起了很多麻烦。
以前在聚美的时候,一般产品经理会画好原型,写好详细的流转过程,甚至在最开始的时候理清所有逻辑,然后大家讨论大概两次,最后开始动手。
我也习惯于这种方式的沟通,甚至于做的过程中不断完善细节。
后来在鱼说的时候,我也积极地去和pm沟通,确定需求,也在思考,但是并没有站在产品或者公司角度去思考一个需求或者比较大的功能。再到后面上层干预能力比较大,自己能决定的事儿也少了,更可怕的是:自己也甘于做一个worker,而不是creater.
如今,我越来越觉得问题的严重,这种参与感越少的工作让人乏味且导致了诸多问题。需求在诞生之初,就该全程参与,特别是在分工不细的公司团队里面。以前不会出现测试想出新的case,临时又改需求的情况,也不会出现做到一半pm发现自己的设计又二逼了。在一个不稳定的环境里面,我只能尽早地提出自己的想法,简化逻辑,也集思广益,在早期堵住所有能想到的漏洞。
习惯的个人英雄主义的我,以往都是独自扛下来所有的困难。后来我才发现,所有的苦恼和难度都是自己给自己的。如果在最开始我拉通把整个逻辑跑通,估计难易,完全可以直接否决一些不现实的需求或者做法。pm永远只是pm,参与实现就是越界了。
痛定思痛,以此为戒。
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 基于Microsoft.Extensions.AI核心库实现RAG应用
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· Manus爆火,是硬核还是营销?
· 终于写完轮子一部分:tcp代理 了,记录一下
· 别再用vector<bool>了!Google高级工程师:这可能是STL最大的设计失误
· 单元测试从入门到精通