Dojo
最新
最佳
搜索
订阅
解道Jdon
架构设计
领域驱动
DDD介绍
DDD专辑
战略建模
领域语言UL
领域事件
商业分析
工作流BPM
规则引擎
架构师观点
数据工程
产品经理
系统思维
微服务
微服务介绍
微服务专辑
模块化设计
SOA
API设计
clean架构
SpringBoot
分布式事务
事件溯源
Kafka消息
Kubernetes
DevOps
编程设计
GoF设计模式
模式专辑
面向对象
函数式编程
编程语言比较
编程工具比较
形式逻辑
前端编程
Reactive编程
Jdon框架
Rust语言
人工智能
Web3
模因梗
幽默梗
程序员吐槽
面试技巧
Java入门
数字化转型
认知偏差
道德经
更多话题
最好的PM与最坏的PM - PavelA
22-03-27
banq
与我共事过的最好的 PM 积极寻找机会将团队与领域专家和客户联系起来,不断努力反驳团队的假设前提(
第一性原理
)。
我共事过的最糟糕的 PM 100% 专注于内部,以避免影响交付进度。
培养整个团队的清晰度是游戏手册的一个重要部分。
将开发人员和设计师直接与他们可以提出问题或举行研讨会的人联系起来,要比自己来回传递所有信息更有价值(而且更快!)。
PM/PO作为交付产品的接受者 "的模式只有在PM本人是领域专家的情况下才会起作用(虽然效果不好,但还是起作用)。
我看到新手PM试图把自己变成领域专家,这样他们就能使这种模式为他们所用。
问题不在于领域专家,而在于垃圾模型。
公司试图通过要求他们的PM是领域专家、工程专家、用户体验专家来支持这种失败的模式。
但是,如果
项目
管理人员知道如何在团队的决策和实验之间建立紧密的反馈回路,他们就能使那些已经在团队中的专家做他们的工作。(项目经理负责交付进度)
为了公平起见,我曾与无数的设计师和工程师共事,他们对客户的需求同样缺乏好奇心,没有读过验收标准。
这不是一个团队的运作方式。你需要共同的目标和共同的方法。
我看到的另一个趋势是,企业将PM委派到一个 "狗屎伞 "的角色,所以现在除了做首席设计师、首席工程师、首席研究员、领域专家和Scrum大师的工作之外,他们还在做主任的工作(没有权力)。
最好的 PM应该将他们的团队与领域专家和客户联系起来
产品经理
产品需求与商业分析BA方法