特别是第三项已经被证实是成功的,因为大多数公司没有技术团队可以做数据分析看板,以建立推荐引擎,搜索分析等等。第三种方式全们我可以专注如何完成和扩大我们的开源成果,保证我们努力建议的社区不被破坏。这也有助于明确什么得到了什么还没有。
第二课:支持还是咨询,还是客户成功
在 Lucidworks
的初期,我们的主要产品是知识,在咨询时间使用“一包到底“的保险制度做开源。当然我们有一个商业产品,但主要赢利点是获得知识底层代码的聪明人。我们销
出很多咨询和订阅支持,这些通过我们的技术布署非常有利于丰富的知识获取,但不利团队的长期发展,因为问题一旦解决,我们就失去了价值。即便长达一年之
久,因为 Solr 只是一时工作之需,客户们认识到他们不需要中断或修复保险。
在那段时间发生一件有意思的事情,尽管我们认识到 Solr
没有崩溃(很多方面,它毕竟只是一个软件),我们的客户不断的问怎么处理更难的事情。比如,他们把基础搜索运行起来,他们就想知道怎么把自然处理语言或者
其他客户反馈的东西集成进来以提高相关性。这些问题往往需要一到两个小时的时间在电话里指导他们,另外他们向产品管理团队反馈了大量用户最关注的信息。基
于这样的知识基础,我们成功解决了我们的支持模式,我们称之为客户成功模式。
过去,我们把收到的任何困难问题倾向于变成咨询服务。现在,我们对待这些问题就好像是普通的技术支持一样并且一直和用户交流确保问题得到解决。(但任何超
过一天的服务仍可能变成咨询)类似的问题或建议更多地被反馈到我们的产品中让它变得更好。此外,我们对于用户需要的支持功能变得更具有预见性,不再需要等
待电话来催我们了。虽然明显,但是我看到很多建立在支持服务层面的开源公司在对待这类问题的方法是转移话题或“自助服务”,这样造成的结果差别大家都很明
白。更好的结果应该是你仔细专注于客户的需求服务,这样你的产品才能变得更好。因为只要你真正用心于客户关心什么,大家才能真的好,包括你的销售团队。
第三课:管理人员的部分
和许多其他公司一样,你不可能仅基于一个产品自身获得成功或导致失败,除此之外还决定于你身边的人。在开源世界,雇佣员工的一个关键问题是找到能平衡公司
的开源属性和你支付薪水的商业事务的人。假如你是完全开源的,这很容易做到两方面的完美平衡(假设将人实际支付的单独支持)。如果你免费中伴有付费,这可
能更有挑战性,因为有时来自于闭源世界的人不太了解开源这边的事(今天已经很少见了,源于开源的普遍性)同时那些开源工作者可能不会理解或者不想从事任何非开源的工作。
社区中很多你想要聘用的工程师往往天各一方,这是做开源的人所要面对的挑战也是机遇——需要你建立一个能很好支持分布式远距离办公环境的公司。我们遇到了
一个有趣的挑战,特别是刚开始的两年。它来自于过去在办公室工作的工程师,但他们并不是因为这种“眼不见心不烦”的理由被那些在家办公的员工困扰。而是因
为我们的大部分员工在过去时间是分散的并且也习惯于了异步,分散式的交流方式,他们有许多根深蒂固地开源开发传统,还没有习惯集体办公和各种开发工作流程。
当然,交流和文档是很关键的,但是你可能不会认识到重要事件的发生,直到你认识到一些重要的连接断裂事件。幸运地是,有许多很不错的工具可以使用,让协作
间时减少任何潜在的摩擦,但是面对面的聚会一定要保证其充足的预算,这样的聚会我们一年要做好几次,要是团队更小聚会还可以更频繁。
最后,你必须意识到并不是所有人都具有远程工作的能力。比如,那些需要高度协作或者视觉导向的工作,最好面对面来做。对于我们来说,服务器端团队多数人员
都是远程工作的,而我们的产品管理团队和 UI
团队中的绝大部分都是集中办公的。后者能够从“嗨,过来看看”这种快速的沟通中获益良多,因为大家都在同一间屋子里办公,而前者通常得益于拥有大段不被打
扰的时间。
我们还在吗?
就像任何未充分了解创业就去做的人一样,在你去寻找一种可复制和扩展的商业模式的过程中总会经历多次的起伏。对我们来说,得到的教训是难于抗争和严峻的挑
战不仅仅是建立一个能够销售的产品,还有如何雇佣优秀的人才以及怎样建立一个广泛的用户社区。除了那些,如果我从过去10年的开源社区贡献学到了什么的
话,那就是:你永远不会知道下一个好点子来自哪,因此去拥抱它并且像骑马一样牢牢抓紧它的缰绳吧。