深圳APP开发公司需要敏捷开发吗

深圳APP开发公司、软件外包公司等等，都是以接项目的形式开发一个又一个项目，那么，敏捷开发适合APP开发公司、外包公司吗？

敏捷开发，是一种从1990年代开始逐渐引起广泛关注的新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。
在一个APP开发公司里，团队还在生死线上奔波的时候，敏捷究竟带给了我们什么。

市场的拓展要求的是客户合作的精神，但是在合同谈判的环节里，又得考虑很多自身利益的因素，敏捷宣言中强调了客户合作 over 合同谈判，可是现实之中，不得不去平衡这两边的关系。举几个简单的场景，合同还没签署，客户希望你能帮他们一起整理产品需求文档；客户撕毁合同，不履行合同条款，同时希望你可以理解；客户在合同范围之外提了一些需求，希望你可以满足；从服务客户的角度上来说，好像我们都应该想办法满足他们，但是回归到自身，如果不懂得拒绝和选择，结果只能是把自己累死。

很多时候我们误以为客户合作就是满足客户的一切需要，想办法为客户提供价值，可是往往却发现，客户也未必就是那个全知全能的上帝，坚持自我有时候往往会显得更重要，客户合作不是一味的迁就，也不是在任何时候去讨好每一个人，理解客户内心的愿望，然后找到一个可以使双方都获得收益的方案，用你的专业和影响力来引导客户，以达成与客户的合作。

市场中的外包合同，几乎都以固定价格为主，对需求和时间都有了严格的限定，这也导致了传统的外包项目多半都是以瀑布的模式进行管理，而我们则在固定价格合同的基础之上，尝试了一些新的交付模式和合作方法，把迭代的概念引入到外包项目的交付中，同时通过把一个合同分拆成多个小合同的方式，基本保证每个合同的交付时间不超过一个月，以此来实现对客户需求变化的积极响应。

 

案例一：

2016年中，在和一个客户进行了两周的沟通之后，完成了合同的签署，当我们在组织人员，准备进行交付的时间里，却发现客户的首款迟迟没有到账，大约在我和客户继续沟通了几次之后，客户的联系人和我沟通，表示老板另外选择了一家供应商，因此想终止和我们的合同，但是却不想承担合同里的违约责任，这件事情在后续的交涉过程中显得异常艰难，而且最后我们也没有收到违约款，事情也就此告一段落。

在随后的过程中我自己也一直在反思，我们一直在提倡客户合作，但是客户并不仅仅只是你所对接的那个联系人，一个企业客户里有各类各样的人，不同的人掌握了不同的话语权，也有不同的诉求，正如我们交涉的客户，和我对接的联系人很信任我们，希望由我们完成他们的软件交付，但是客户的老板却希望以更低的价格来购买一套现成的系统。

当客户并不是一个抽象的概念，而是一个个实际的个体的时候，客户合作并不仅仅是给他们交付价值，而是需要了解客户中每一个个体的诉求。

 

案例二：

今年年初在沟通的一个项目，客户方是一个大公司里孵化的早期创业项目，产品还没有上线，前前后后沟通了五六次，过程中我发现，每当我拿出一版原型的时候，总会激发出他新的想法，并且希望加入到原型和设计之中，这样的场景想必很常见，如果接收客户的想法，那么带来了便是项目工期的延长，如果拒绝，则可能失去这个单子。在赢单和输单的风险之中，我们平衡了很久，最终冒着风险，去和客户沟通把项目做成多期的意向，因为我们不希望把一个可以两个月快速交付的项目，变成一个半年的庞大的怪物。

在与客户的沟通过程中，我们尽力的以快速迭代和交付价值所带来的优势进行解释，并帮助客户梳理了核心的业务流程和应该在早期建设的内容。在过程中我发现，当你在一个领域表现的专业的时候，你可以通过你的专业来赢得客户的信任，并引导他们同意你的请求，很多时候客户合作并不是一味的讨好和迁就，而是给予你所在领域的帮助。

 

研发&交付

在敏捷中，最为适用的便是研发和交付的环节，一套完整的Scrum框架基本可以适应大部分的实际工作场景，我们尝试过两周的迭代、也试验过一周的迭代，不管哪种方式，其本质的核心是用户价值的交付，用更贴切的话来说，便是满足当下客户场景的可工作软件。

很多时候，产品做成什么样子往往是由产品经理来把控的，在敏捷中，我们经常会提到用户价值，但是却没有人会解释用户价值到底是什么，很多时候，用户嘴上说的很多时候未必是他真正想要的内容，“我们要做一个APP”可能只是老板开会时提到的一句话；“这个产品一定要功能强大”可能只是为了做出一些政绩给老板看；“我们要做一个电商平台”可能是因为公司刚刚投资了一个这样的项目，当你真正了解了客户需要的背后的上下文以后，你才知道用户价值的本质是“用户内心的渴望”，是内心深处的“我要…”。这个渴望可能是做好他的本职工作，可能是维护自己在公司的地位，可能是配合公司的战略发展，当了解到用户背后的愿望时，你才知道如何正确的帮助他实现最大的价值。

 

再聊聊看板，之前一直使用leangoo进行团队的任务管理，但是发现大家除了同步一些文件以外都不愿意登陆，而当产品文档比较少的时候，一个QQ群的文件共享就几乎已经搞定了，于是在痛苦和纠结之中我犹豫了一段时间，终究还是顺从了团队的想法，选择他们认为合适的工具去完成合适的工作就好。

 

有人会说，你们没有站会、没有看板、也没有各种meeting，那还能算是敏捷么？我只能说，我们只是选择了那些我们适用的流程和工具，而把更多的时间交给了频繁的沟通与软件的开发。

 

敏捷的核心是四句宣言：

个体和交互 over 流程和工具 。

可工作的软件 over 面面俱到的文档 。

客户合作 over 合同谈判 。

响应变化 over 遵循计划 。

 

在敏捷宣言的基础之上，我总结了一些更具体的内容：

 

个体和交互

客户的诉求和客户负责人的诉求很可能会不一样。

 

了解客户、市场、销售、运营、研发、产品、设计、测试、财务的种种术语和他们思维的逻辑，对彼此领域的了解是建立良好沟通的基础。

 

客户合作

了解你的客户内心真正的诉求，和他们做朋友。

坚持自己的立场，而不是被客户牵着走。

平衡客户和自己的利益，共赢才能持久。

 

响应变化

以迭代的方式快速交付产出。

频繁的和每一个人沟通，了解他们的近况和思想的变化。

预先识别出一些会导致变化的风险，提前准备一些预案，别总想着见招拆招。

 

在小型的深圳APP开发创业团队中，项目管理的过程几乎无法以Scrum所设计的那样顺利进行，而场景的扩充和复杂化，导致很多时候我们不得不游离在Scrum之外，这时候唯一可以继续指引着我们进行决策的，而与此同时，我们也不断的调整自己的工作模式，以适应新的环境带来的种种问题，树木是自然生长出来的，而不是设计出来的，而最好的团队也同样如此。