小型创业公司还需要敏捷吗
龚正 GitChat

我是从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之外,这时候唯一可以继续指引着我们进行决策的,便是四句宣言中提到的内容,而与此同时,我们也不断的调整自己的工作模式,以适应新的环境带来的种种问题,树木是自然生长出来的,而不是设计出来的,而最好的团队也同样如此。


CIO之家 www.ciozj.com 公众号:imciow
关联的文档
也许您喜欢