记一次失败的敏捷开发经验

自从开始做产品以来，负责的几个产品都是采用传统的瀑布流开发模式，需求分析——页面设计——开发——测试——上线。我本人除了负责需求分析外，还要负责项目管理的工作。几个产品做下来，对于这套流程还算驾轻就熟，公司的开发们也都乐此不疲的写着代码。不过最近一个项目，我们尝试了敏捷开发的工作流程，结果却不堪回首。

这次的项目并不是一个互联网产品，而是一个解决方案，甲方是一家拥有很多运动场的商业公司，希望我们能为其提供一套球场的智能化升级方案。但甲方的需求并不清晰，也不知道自己想要什么，唯一的目标就是让自己的运动场变得更“屌”，更科技化，能吸引更多的人来玩。

也正是因为甲方的这个特点，我们决定采用敏捷开发，先做出几个核心功能，交付到甲方，在甲方场地运营之后，再根据甲方的意见进行改进，逐步迭代，当整体做完之后，就可以把该项目内容打包成一个产品，对类似的客户进行销售。

在和领导分析了这个项目之后，我们决定采用敏捷开发的模式，我的任务就是需求分析，主要就是要多“走出去”，多和客户交流，把产品的其他事情， 如流程图啊，文档啊 ……直接给研发们搞定，也算是试验一种新的开发模式。

怎奈理想很丰满，现实很骨干……整个开发过程多次返工，中断，这期间夹杂了无数次撕逼……

问题1：项目组内部人员问题

我和甲方沟通了需求之后，拉着开发们开会，所有人大开脑洞从甲方的基本需求中畅想了无数的延伸，无数的功能。仿佛做完这单，就可以覆盖全国……

但真正开工之后，问题一个接一个来了，首先，有的开发人员在之前的会上根本没有专心，我们所聊的场景，功能，他完全不知道，还停留在之前的瀑布流工作状态中，等着产品经理把详细的需求给到他……

其次，按照之前我和老板的讨论，由研发出流程图和文档，但真正执行的时候，却没有人做这项工作，后果就是在开发的过程中，不断的找我重新梳理流程，不断的聊场景，聊功能，这样一来二去时间就浪费了。

反思：敏捷开发和传统的瀑布式开发相差还是很多的，瀑布式开发只要在前期将用户需求，产品功能都想清楚，流程理顺，那后期只需要一个牛逼的项目经理把控项目进度，就不会出什么大问题。

敏捷开发则对团队内的所有人要求很高，至少在我们这个项目里面，无论你是UI，还是前端，后端都要对场景了如指掌，这样会省去很大的麻烦。

问题2：销售过早介入

我们这个项目出现的第二个问题，就是在开发的过程中，领导过早的让销售介入了。

领导的本意是希望销售能将我们这个项目变成产品，卖给更多人，但实际的情况确实，甲方虽然都是球场主，但他们的基本需求却相差很多，我们设计的能满足第一个客户的功能，却不是第二个客户的基本需求。

当销售带着客户需求找到我们，并提出要试用时我们的产品时，那场面别提多尴尬了……但销售已经把大话说出去了，我们拿不出东西的话那是丢公司的脸啊……没办法，硬着头皮上吧。

一方面让销售尽量拖一拖客户，另一方面我们快速的开发一个应急版本。

但在这么紧张的时间里，又怎么会做出好的产品，最终的结果当然是客户飞了，而原定的开发计划也被打断了。

内部复盘

我们内部在面对这些问题时也进行了复盘和讨论：

1 .我们认为敏捷开发确实是满足第一个客户需求的最好的方式，只不过我们团队的成员要负起责任，需要每个人都对业务十分了解。不能做到这点的请你离开。

2 .销售的目的就是把东西卖出去，他们才有提成拿，他们不会在乎用户需求什么的。所以只有完整的，可复制的产品才可以让销售拿出去卖。

3 .我们现在是在为一个客户做解决方案，还没有被证明能否应用于其他场景，只有当我们做了足够多的项目，当我们为5家乃至更多的客户做了解决方案之后，这一批解决方案才能变成一个产品打包卖出去。这时，我们针对不同用户只需要在做过的解决方案中挑选合适的功能模块即可。

作者：伯纳乌的新一

关键字：产品经理, 甲方

版权声明

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！