初创公司软件开发面面观：程序员、外包、平台（初创软件公司怎么接项目）

“

对于初创公司来说，软件开发的要点有哪些？程序员的重要性到底有多大？外包、内包能够包治百病吗？

主要结论

• 就算要失败并重试，初创公司的速度也一定要快，更重要的是一定要专心聆听客户心声。初创公司的程序员需要迎合客户而非代码本身，这样才能创造出足够简单直观的软件，进而改善客户体验。

• 为实现品牌的扩张和公司规模的扩大，初创公司的程序员必须在前瞻性思维引导下用狂飙的速度和激情进行尝试。

• 初创公司的程序员必须在速度、成本、质量、用户体验、设计、伸缩性等要务之间进行权衡。

• 初创公司的程序员必须能顺利应对安全弱点和失败。

• 初创公司的程序员可以是创始人、公司员工，或外包的供应商，重点在于恰当的心态。

对大部分初创公司来说，技术是最关键的分水岭。无论将技术视作自己的精髓（例如谷歌或优步），或希望通过技术促进自己的核心业务（例如Zenefits或Zappos），对初创公司来说，软件开发很可能成为连接客户痛点和公司收入流的桥梁。毕竟餐巾纸上规划的构思和蓝图需要通过软件的形式交付到客户手中。

初创公司实景

初创公司会面临动态、不可预测，甚至混乱的环境，这就迫使创始人必须快速行事，快速失败，更快速地学习经验教训找出市场利基（Market niche），从中获得可持续收入。60%的初创公司撑不过头五年，接受风投注资的初创公司中75%终将失败。这主要是因为初创公司面临的风险较大，错过了市场机会，或其他业务方面的原因。

为了获得推动，初创公司需要快速发展出自己的第一个客户，并用更快速度发展出前十个客户。但这一切可能需要2年时间。考虑到收入，需要尽可能快地将1个收入来源扩展为10个，只要达到百万级收入，就可轻松实现15%的月增幅。

要快速获取客户并获得收入，这种想法背后的原因在于，最适合的团队会借助每个客户和每分钱的投入对产品进行完善。各种紧迫情况会迫使团队更加立足于基础，专注聆听客户的想法和反馈，用尽可能最简单的方式实现这些反馈，并周而复始地一直这样做下去。

如果你的团队只是专注于他们自己觉得酷的地方，而非专注于客户的实际想法，那只能说你入错行了。只要你的一切行事以客户为基础，而非以代码为基础，客户会让你在这场游戏中顺利获胜。

这和父母养育孩子的过程很相似：如果你希望自己的孩子以后能有出息，就必须在孩子成长和转变过程中付诸足够关心。你也许认为孩子以后会成为气象学家或NASA的专家，但这仅仅是因为你自己觉得这些职业很酷，只有朝着整个社会（而非你）需要他扮演的角色方向上培养、引导和教导，你的孩子才能最终获得成功。

程序员极为重要！

团队中的程序员能够对最终的成功或失败造成多大程度的影响，这一点很难量化，但很明显软件和制造软件的人在先于对手抢占市场方面扮演了一个关键的角色。这里有些例子。

为初创公司写代码和为老牌公司写代码的过程截然不同。初创公司有着独特的文化，并会扩展到业务的每个角度，从财务到销售，从运维到软件开发，全都包含在内。你的产品必须简单并且便宜。你必须精准地专注于客户，并不断根据客户体验快速完善自己的产品。没什么是孤立的，没什么是“神圣不可侵犯”的。这里有些例子。

不是随便哪些代码都可以这样做，也不是随便哪个程序员都愿意这样做。无论程序员是否同时也是创始人，都必须首先和客户而非代码“联姻”。尤其是软件必须采用这样的一种心态：

理解客户的想法，并采用差异化的技术满足客户的需求：

你的软件必须能颠覆现有技术或企业，通过更简单、更直观、更稳健的各种“更”改善用户体验。

因此对程序员来说，如果初创公司的业务领导谈到某个健康追踪应用的上市时间，针对某个在线花店谈到更平滑、直观、不受干扰的客户购物体验，或谈到要为放款人立刻提供针对特定客户量身打造的报价方案；程序员需要知道这些要求意味着什么，以及如何通过软件开发工具、方法以及功能实现这些要求。

这并不是说与项目有关的所有程序员都需要理解业务的方方面面，并理解将这些内容转变为技术决策的方法，但技术领导者必须心里有谱，同时也要能解释给技术团队。这样整个团队才能通过大量小决策的积累最终产生大成果，成功实现“创造客户想要的产品”这一愿景。

在竞争和不断变化的要务之间进行权衡：

技术愿景要求技术领导者必须能在竞争优先权和速度、质量、成本、用户体验、设计、缩放性等方面进行权衡。对每个初创公司来说这些要务各不相同，并且对同一家初创公司，这些要务也会时常发生变化。

例如身处性命攸关的医疗设备行业的初创公司，无疑会先于上市速度或成本等因素优先考虑代码质量。但如果要开发网络叫车应用，上市速度和代码质量很可能同样重要：客户需要每次叫车时有车可乘，初创公司则需要在这个竞争激烈的市场中通过速度保持领先。

技术领导者需要对不同要务进行权衡，但同时也要获得所有团队成员的认同和支持。如果我的初创公司要开发社交应用，同时我雇佣了一位始终坚持提供100%高质量代码的程序员，我可能会错失市场机会。

从2007年到2013年，每当由于快速发布新功能导致网站出现技术问题后，Twitter都会在网站上放一张我们称之为“失败鲸（Fail Whale）”的图片。很明显，对他们来说创新速度的重要性远远胜过质量。

成功仅仅是多个失败粉饰后的结果：

对于技术领导者和支持团队来说，另一个非常重要的心态在于要能接受弱点和失败。初创公司通常需要通过实验找出值得进一步投入的想法、领域，以及特征。对于手头的问题或脑海中的长远目标，并没有哪怕一个已经明确的解决方案，面对这种情况程序员也必须充满活力，不能因此而感觉受挫。

团队的角色：

团队中的程序员实际上是公司创始人以及项目目标实现过程中的“螺丝钉”。你的项目可能需要一名软件工程师和一名质量工程师，或者由同一位程序员担任这些角色。你的项目可能需要架构师，但此人同时也是产品的所有者或业务分析师。对初创公司来说，人员配置方面不存在严格的规定。人员需要接受项目的支配，然而你肯定不想面对冗员造成的开销和瓶颈。

平台和方法论很重要

为实现品牌的扩张和公司规模的扩大，技术团队必须在前瞻性思维引导下用狂飙的速度和激情进行尝试。天使投资人和风险资本投资人想要看到的不光是单点解决方案，而是能够通过发展成功打造出一个平台的公司。这就需要针对不断变化的大环境开发出精彩的代码，并持续专注于为最终用户制造惊喜。

选择能顺应这些需求的恰当平台就成为势在必行的做法。平台可以意味着某种操作系统，某种编程语言，或者在某种编程语言基础上构建的某种框架。犹如房屋的地基，这种平台可以为初创公司提供支撑，但也会造成局限。

在外人看来某些平台似乎挺适合，但面对你的具体要求可能会显得很糟糕。Azure也许很适合Olyve.com但并不适合Proflowers.com。Windows平台也许很适合很多公司，但相比Unix系统，在可伸缩性方面对PayPal来说无异于灾难。选择恰当平台的最佳方法是雇佣足够出色的程序员，并将平台的选择任务交给他们。

一般来说，初创公司的程序员更愿意选择能快速顺应产品及其管理过程中所产生变化的技术。例如一些通用的基础架构，如配置管理、问题报告、追踪，以及规划系统和调度与通知系统。

诸如白板等易于实现的工具，以及能够应对信息快节奏变化速度的技术，可以降低初创公司的培训和维护成本。为了缓解资源缺乏的问题，初创公司通常会大量使用开源解决方案，这也使得他们能够获得大量“前人的经验”。这里有些例子。

对于工具、平台，以及方法论的选择是需要优先考虑的要务，但随着时间的流逝，最终的选择也会不断变化。如果速度是头等要务，那么可以选择包含各类附加功能和服务的云平台（例如Azure云），但这种做法：1，比其他选项成本更高；并且2，无法在不同组件方面获得同类中的最佳产品。后续的发展之路上，随着从客户处获得不同反馈以及公司的继续增长，考虑其他选项可能会成为你那时的头等要务。

在方法论方面，对于初创公司来说必须从整体上确保软件开发过程的敏捷性、持续演化，以及机会主义。敏捷方法论对“变化”持包容态度，可以让开发工作更适应业务战略。

采用快速发布后进行迭代并持续集成的方法，可以缩短将创意构思通过快速开发变成最终产品所需的前置时间。精益（Lean）方法论是敏捷的一个变体，借此可发现软件项目中风险最大的部分，并提供最小可行产品促进下一次迭代的测试和修改工作。

外包，内包，包治百病？

最关键的软件开发领导者是否同时也是公司创始人？未必。创业团队必须包含一系列互补的特征，这样才能让初创公司从不同角度发现机会，快速尝试，与客户保持足够近的距离。

这一过程需要销售、营销，以及技术的介入。需要创新并形成体系，需要冒险但也要谨慎行事，同时需要维持极危险的“全速狂飙”承诺。这些技能和特征也许并非每个创始人都具备，但每个创始人都会将其视作核心价值。这里有些例子。

程序员到底该来自哪里，这不光决定了一个或全部创始人是否恰巧都是软件工程师，还决定了你想要实现什么目标，要使用什么语言、平台和方法论，想多快速度实现，这其中你能投入多收成本。对于软件或解决方案，到底由公司内部自行开发还是外包，最重要的差别并不在于程序员到底居住在哪里，而在于谁负责领导开发工作。

负责人了解代码吗？最好能了解。负责人了解你的客户和业务吗？要能了解那就更好了。负责人能够100%致力于实现初创公司所需的速度和价值吗？如果能，那就大胆放手干吧。负责人可以是创始人自己或雇佣的员工，也可以是顾问或外包团队的成员，但此人必须能够驾驭公司的技术愿景。

如果软件开发工作是外包的，你只能获得很少的潜在优势。虽然74%的高增速互联网初创公司由于过早扩张而最终失败，但外包至少还有一个优势：可以非常快速高效地扩张和收缩，以合适的规模进行尝试。

此外还有其他一些优势，例如你可以更迅速地应对程序员与代码而非客户“联姻”，或所采取的方法无法满足初创公司对企业文化的要求所造成的问题。如果创业团队中有程序员属于后一种情况，可能在起步阶段就会面临障碍。然而如果雇佣的人员无法满足要求，随时更换代码、供应商，或同时更换这两者，即可瞬间做出动态的调整。

Gigster的创始人兼初创公司软件外包做法的拥护者Roger Dickey认为，如果采取外包的方法，就可以轻松地快速做出5个原型，并根据客户需求从中选择。他认为借此可以规避对代码过度依赖这种对初创公司来说致命的问题。

我同意这一点但也要提醒大家，如果外包，那么你的公司内部一定要有了解技术和业务的人员，这样的人必须能用易于理解的方式促进技术人员之间，以及技术和业务人员之间的交流，并将这种交流运用到开发环境中。

内部开发且创始人身兼程序员职责，和/或由技术人员领导开发工作，这些做法也能带来收益。最重要的问题在于，由于代码本身已成为获得成功的重要组件，你需要对代码获得尽可能多的所有权和控制权。

在寻求天使或VC投资的过程中，可以从技能和态度的角度将创始人描述为你们公司的“独门秘方”，这一点对投资人很有吸引力，毕竟他们更愿意投资人员而非想法。如果你的所有优势都源自某个供应商，对投资人来说就有些危险了。

无论软件开发选择了外包或内部开发的方式，都必须在程序员、其他创始人，以及客户之间维持活跃的交流沟通、信任、原则，以及开放式讨论。可以在公司内部或外部寻找符合这些特征的人，但是要记住，他们对你的成功意义重大。

成功到底长什么样？

成长只发生在旅途中，而非终点线上，这种说法对初创公司来说比任何其他领域都更为适用。成功意味着旅途还在继续，还是“熟悉的配方”，但“味道更多”：更多实验，更多尝试，更大规模，重构，失败……。初创公司在第一阶段会面临不少挑战，就算后续阶段都能获得成功结果也不会有太大区别。

但你的工作要务可能会变为规模、品牌的成长、管理位于不同位置的（更）大技术团队等。面对这些挑战的你依然能从第一阶段所奠定的心态中获益。也许彼时步调已经不那么快得让人发狂，但是对于客户，对于迭代，以及对于集成和沟通交流的承诺始终是不变的。

如果你觉得这样的过程有着独特的乐趣，引人入胜，充满挑战，那么你可能已经变身为成功路上的初创公司创始人。

• 本文由译者大愚若智翻译自InfoQ英文站，原文链接：

• https://www.infoq.com/articles/how-startups-build-software

▽

免费沙龙报名：来深圳一起聊聊分布式架构吧～（戳阅读原文报名）

云计算的发展离不开分布式架构的应用。在最新一期蝴蝶沙龙上，我们将邀请首都在线总工程师周东波、PingCAP首席技术官黄东旭等资深专家来到深圳，一起聊一聊分布式架构背后的那些实践经验与技术细节，内容涉及容器化服务的分布式存储选型、分布式关系型数据库的架构实现等话题。

喜欢我们的会点赞，爱我们的会分享！