当公司生存都是问题时，我们还需要敏捷吗？
在创业小团伙中，敏捷带来了什么
自我介绍：龚正，PMP/ACP/CSP，14年开始创业至今 。
我是从2013年开始接触敏捷，在2016年开始进行系统化的学习，并在16年8月拿下了CSP的认证，三年多的时间里，从和人合伙做电商，一直到运营自己的外包小公司，我不断的在尝试着敏捷的思想和方法，在只负责一个团队或者部门的时候，Scrum和LeSS都能很好的为我和团队提供帮助，但是当自己开始运营公司的时候，我发现很多事情已经超出了我所熟悉的内容。
回想起在参加各种培训和会议的过程中，大家讨论各种问题的时候，上下文都是在一个部门、或者是一个团队，不需要考虑太多的收入和成本，没有定岗定薪的烦恼，没有和客户掰扯合同细节的痛苦，也没有每天盯着公司银行账户的焦虑，在一个相对比较太平和安静的环境之中实施Scrum，我们可以更多的关注于团队的流程和成员的个体，但是当我们把范围扩大，场景变得更加复杂，在一个公司里，团队还在生死线上奔波的时候，敏捷究竟带给了我们什么。
市场&销售
市场的拓展要求的是客户合作的精神，但是在合同谈判的环节里，又得考虑很多自身利益的因素，敏捷宣言中强调了客户合作 over 合同谈判，可是现实之中，不得不去平衡这两边的关系。举几个简单的场景，合同还没签署，客户希望你能帮他们一起整理产品需求文档；客户撕毁合同，不履行合同条款，同时希望你可以理解；客户在合同范围之外提了一些需求，希望你可以满足；从服务客户的角度上来说，好像我们都应该想办法满足他们，但是回归到自身，如果不懂得拒绝和选择，结果只能是把自己累死。
很多时候我们误以为客户合作就是满足客户的一切需要，想办法为客户提供价值，可是往往却发现，客户也未必就是那个全知全能的上帝，坚持自我有时候往往会显得更重要，客户合作不是一味的迁就，也不是在任何时候去讨好每一个人，理解客户内心的愿望，然后找到一个可以使双方都获得收益的方案，用你的专业和影响力来引导客户，以达成与客户的合作。
市场中的外包合同，几乎都以固定价格为主，对需求和时间都有了严格的限定，这也导致了传统的外包项目多半都是以瀑布的模式进行管理，而我们则在固定价格合同的基础之上，尝试了一些新的交付模式和合作方法，把迭代的概念引入到外包项目的交付中，同时通过把一个合同分拆成多个小合同的方式，基本保证每个合同的交付时间不超过一个月，以此来实现对客户需求变化的积极响应。
案例一：
2016年中旬，在和一个客户进行了两周的沟通之后，完成了合同的签署，当我们在组织人员，准备进行交付的时间里，却发现客户的首款迟迟没有到账，大约在我和客户继续沟通了几次之后，客户的联系人和我沟通，表示老板另外选择了一家供应商，因此想终止和我们的合同，但是却不想承担合同里的违约责任，这件事情在后续的交涉过程中显得异常艰难，而且最后我们也没有收到违约款，事情也就此告一段落。
在随后的过程中我自己也一直在反思，我们一直在提倡客户合作，但是客户并不仅仅只是你所对接的那个联系人，一个企业客户里有各类各样的人，不同的人掌握了不同的话语权，也有不同的诉求，正如我们交涉的客户，和我对接的联系人很信任我们，希望由我们完成他们的软件交付，但是客户的老板却希望以更低的价格来购买一套现成的系统。
当客户并不是一个抽象的概念，而是一个个实际的个体的时候，客户合作并不仅仅是给他们交付价值，而是需要了解客户中每一个个体的诉求。
案例二：
今年年初在沟通的一个项目，客户方是一个大公司里孵化的早期创业项目，产品还没有上线，前前后后沟通了五六次，过程中我发现，每当我拿出一版原型的时候，总会激发出他新的想法，并且希望加入到原型和设计之中，这样的场景想必很常见，如果接收客户的想法，那么带来了便是项目工期的延长，如果拒绝，则可能失去这个单子。在赢单和输单的风险之中，我们平衡了很久，最终冒着风险，去和客户沟通把项目做成多期的意向，因为我们不希望把一个可以两个月快速交付的项目，变成一个半年的庞大的怪物。
在与客户的沟通过程中，我们尽力的以快速迭代和交付价值所带来的优势进行解释，并帮助客户梳理了核心的业务流程和应该在早期建设的内容。在过程中我发现，当你在一个领域表现的专业的时候，你可以通过你的专业来赢得客户的信任，并引导他们同意你的请求，很多时候客户合作并不是一味的讨好和迁就，而是给予你所在领域的帮助。
研发&交付
在敏捷中，最为适用的便是研发和交付的环节，一套完整的Scrum框架基本可以适应大部分的实际工作场景，我们尝试过两周的迭代、也试验过一周的迭代，不管哪种方式，其本质的核心是用户价值的交付，用更贴切的话来说，便是满足当下客户场景的可工作软件。
很多时候，产品做成什么样子往往是由产品经理来把控的，在敏捷中，我们经常会提到用户价值，但是却没有人会解释用户价值到底是什么，很多时候，用户嘴上说的很多时候未必是他真正想要的内容，“我们要做一个APP”可能只是老板开会时提到的一句话；“这个产品一定要功能强大”可能只是为了做出一些政绩给老板看；“我们要做一个电商平台”可能是因为公司刚刚投资了一个这样的项目，当你真正了解了客户需要的背后的上下文以后，你才知道用户价值的本质是“用户内心的渴望”，是内心深处的“我要…”。这个渴望可能是做好他的本职工作，可能是维护自己在公司的地位，可能是配合公司的战略发展，当了解到用户背后的愿望时，你才知道如何正确的帮助他实现最大的价值。
案例一：
在一个大家都兼职的团队中，Scrum的很多实践就突然变得困难起来，就拿每日站会来说，大家不在一个地方，也不是同一个时间起床，想在固定的时间里召集大家开会就是一个不太可能的事情，为此我们进行过一次讨论。在讨论的过程中我们开始反思，站会的目的是同步工作情况，并识别中工作过程中当下存在的问题，如果从这个目的作为出发点，那么是否可以通过一些更加简单的方式来完成这个过程，在尝试了每天晚上的在线站会、电子看板的实时更新、个人的周报和日报之后，我发现在工作的时间里，大家都时刻在线，并能随时保持沟通，那么站会是否存在的必要性也就没有那么重要了，当然这需要每一个人的自觉性，在自己工作完成的时候及时的反馈，在遇到问题的时候及时的抛出来，一个自觉的推动工作和解决问题的团队里，很多方法和工具反而变得没有那么重要了。
再聊聊看板，之前一直使用leangoo进行团队的任务管理，但是发现大家除了同步一些文件以外都不愿意登陆，而当产品文档比较少的时候，一个QQ群的文件共享就几乎已经搞定了，于是在痛苦和纠结之中我犹豫了一段时间，终究还是顺从了团队的想法，选择他们认为合适的工具去完成合适的工作就好。
有人会说，你们没有站会、没有看板、也没有各种meeting，那还能算是敏捷么？我只能说，我们只是选择了那些我们适用的流程和工具，而把更多的时间交给了频繁的沟通与软件的开发。
财务&利益
在整个敏捷和Scrum之中，从始至终都没有提到如何在团队中进行利益的划分，小到工资定多少，大到奖金如何发，好像一提到利益分配，整个团队就会抛弃他们之前合作友爱的面目，而争抢的焦头烂额，也正是在这一块禁区，让我在敏捷的推广过程之中，遇到了很多的阻碍。
敏捷的三支柱之中，有一个是Transparency，我们可以公开每个人的工作情况、可以公开产品需求的每一个细节、可以公开团队的进度，但是我们却不敢公开利益的分配情况。我们相信每一个员工的自觉性和能力，那么我们是否也应该相信他们在面临利益的诱惑时，可以坚守公平的底线?
在这三年的过程中，我不断的在进行尝试，在团队层面公开奖金额度的时候，团队成员对利益分配的不满的问题就已经开始出现，时至今日，我也依然只是在小范围的团队中，进行公开的利益分配决策，在一个互相信任和合作的小团队之中，这样的方式还是可行的，而我相信，在更大规模的团队中，这样的方式一样也可以实行下去。
案例一：
4月份谈下的一个单子中，我开始尝试财务公开和利益分配决策透明的方式，十几万的一个合同，一共涉及到了销售、产品和研发四个人，扣除完企业的税费之后，大约公司账户上还能有十余万的结余，在进行利益分配的讨论前我很纠结，因为不知道大家会不会因为这件事情撕破脸，于是在一次一起吃午饭的时候，我把这个事抛了出来，在会上我说了一下公司财务的情况，并询问大家对于分配的意向，让我欣慰的是，我们很快达成了一致的意见，但我想这应该得益于团队长时间以来互相的信任。
在一个包含了销售的公司里，如何把销售人员整合到项目团队中是我一直在思考的一个问题，在很多软件服务公司里，销售团队和项目团队是独立的两个部门，分别有不同的考核方式，但是导致的结果是销售为了拿下订单而压低价格，项目团队因为预算不足而牺牲质量，这样往往会陷入一个恶性循环。因此在我的团队里，PO作为衔接销售和研发的桥梁，会起到更加重要的作用，包括了：
参与商务谈判，了解客户的真实情况。
帮助销售一起，把客户的需求翻译成用户故事。
帮助销售进行成本评估，制定合适的报价。
而于此同时，销售也不是一个人独立在外打拼，他们需要：
以团队都认可的价格拿下客户。
帮助项目团队一起，完成软件的交付。
把客户的需求翻译成产品可以理解的内容，并共同完成用户故事的制定。
因此我更希望一个全功能型团队，所包括的不仅仅是开发、测试、产品和设计，也同样的需要有销售、运营、市场人员的参与，在一个覆盖了全流程的团队中，才能从更完整的业务流程中来审视团队运转的过程。
敏捷的核心是四句宣言：
个体和交互 over 流程和工具 。
可工作的软件 over 面面俱到的文档 。
客户合作 over 合同谈判 。
响应变化 over 遵循计划 。
在敏捷宣言的基础之上，我总结了一些更具体的内容：
个体和交互
客户的诉求和客户负责人的诉求很可能会不一样。
了解客户、市场、销售、运营、研发、产品、设计、测试、财务的种种术语和他们思维的逻辑，对彼此领域的了解是建立良好沟通的基础。
团队内尽可能保持一切信息的透明，小到设计方案和工作进度、大到公司账户和个人薪资，但是得平衡好透明的程度。
可工作的软件
可工作的软件不仅仅是没有bug，而是要符合客户当下的业务场景。
需求和软件都是自然生长出来的，不要指望一开始就有完美的设计，也不要指望需求不会发生变更；
不要专注于设计文档和原型，而是专注于和客户的频繁沟通。
客户合作
了解你的客户内心真正的诉求，和他们做朋友。
坚持自己的立场，而不是被客户牵着走。
平衡客户和自己的利益，共赢才能持久。
响应变化
以迭代的方式快速交付产出。
频繁的和每一个人沟通，了解他们的近况和思想的变化。
预先识别出一些会导致变化的风险，提前准备一些预案，别总想着见招拆招。
在一个兼职的创业团队中，项目管理的过程几乎无法以Scrum所设计的那样顺利进行，而场景的扩充和复杂化，导致很多时候我们不得不游离在Scrum之外，这时候唯一可以继续指引着我们进行决策的，便是四句宣言中提到的内容，而与此同时，我们也不断的调整自己的工作模式，以适应新的环境带来的种种问题，树木是自然生长出来的，而不是设计出来的，而最好的团队也同样如此。
来源：gitbook.cn
关键字：产品经理, 创业, 客户, 创业案例
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
