@
sillydaddy #4
感谢你的回复,你提出的几个问题非常到位,确实是我原文中没有展开讲清楚的地方,我详细说明一下。
**1. 关于“快速交付”与“抽取通用需求”的矛盾**
你问:“研发以敏捷开发的方式,快速交付,不正是你所希望的‘快速验证市场需求’吗?”
这是一个非常好的问题。我原文中批判的,并非敏捷开发所倡导的“快速交付价值”,而是一种**以牺牲长期价值为代价的“短期交付速度”**。
我理解的快速交付,不应是以牺牲代码的质量、团队其他成员的时间、客户的需求、项目的未来成长空间为前提。我举个例子:就拿 ASR (语音识别)相关的项目。我们现状是:
- **技术上**:直接复制粘贴一套旧的、曾经能跑的代码,几乎不考虑因地制宜(不考虑不同用户端之间的区别),更不要说自己测试一下才提交,代码能跑起来就敢提交测试(期待发现问题之后再擦屁股,丝毫不想着提前请教团队大佬)——忘记了这里没有银弹,努力为埋下巨大的技术债添砖加瓦。
- **流程上**:这种交付方式把所有压力都转移给了产品和测试。PM 需要花大量时间为这种“技术捷径”导致的体验问题向客户解释,测试则在无穷无尽的回归测试中挣扎。
一句话说,按部就班地增加“屎山代码”,这应该谁来负责、谁来监督,全靠产品、测试?就如应付你的理发师一样,剪了就完事,不沟通、不用心。
---
**2. 关于“抽取通用需求”的责任归属:是 PM 还是研发总监?**
毫无疑问,定义需求、规划产品路径,毫无疑问是 PM 的核心职责。但抽取通用需求更是要建立领导的高瞻远瞩、优秀的项目交付、和若干相似的项目之上才能进行。
**公司高层没有为“从项目到产品”这条路设置正确的导航和激励**,压根走不到“抽取出产品的通用需求”这一步。
我认为,优秀的项目交付就如同好吃的料理一样,能赢来回头客——难道只靠金字招牌(老板的关系),一个饭馆就能成就百年口碑、做长久生意?
但在我司的现实情况中,问题出在**战略缺位和组织目标错位**上。
- 第一,公司战略层面身体上不认可“项目产品化”。他们将项目视为一次性的“现金牛”,哪怕给客户多修一个隐藏 bug 都觉得亏了。
- 第二,我没有把抽取出产品的通用需求,看作是研发经理的锅。而是指责不用心交付项目(以伺候客户为耻)的现象。我司是研发总监平时叫得欢(好大喜功、多快好省、空中楼阁、好高骛远),一到夜里支持项目就尿遁。
- 第三,如果 KPI 是“项目交付速度和成本”,而不是“产品化贡献”或“技术资产沉淀”。在这种激励下,研发自然会选择最“省事”的方式——复制粘贴、快速结项。
总之,在我司没有严格的 KPI 的情况下,这种现象还出现,我觉得很诡异。