创业公司的个人“可伸缩性”方案

引言：创业公司最有吸引力的地方就在于其指数级增长的可能性。快速高效地增长让投资人和创业者都能获益。为了实现这种指数级增长，你也需要具有快速的成长性。你需要变得更高效，能为客户为公司创造更多价值。
本文选自《互联网创业核心技术：构建可伸缩的web应用》，下面我们看看在一家创业公司工作会面临的主要挑战，如何实现个人成长，使工作绩效和工作乐趣都最大化。

加班不是一种伸缩性方案

　　在巨大的压力、有限的资源、压缩的工期、严重的不确定下工作会让人神经紧张，而这正是创业公司工作的常态。创业公司是一杯让人情绪爆发的鸡尾酒，引人入胜又让人筋疲力尽，同时又收获满满，不过也要小心不要让创业变成一场无目标的比赛，让工作变成一种无思考的冲动。 
　　工作时间越长工作成果越多似乎是一件自然的事。给自己多一点压力，每天都工作很长时间，甚至周末都在工作，你精力充沛、目标明确、充满希望、相信未来，看起来这是正确的做事方式，似乎做出的牺牲也并不大，而且那种被需要的感觉也很赞，感觉自己就是一个英雄。 
　　问题是这不是一个长久之计，加班工作是实现个人生产力伸缩性的一种非常糟糕的办法。超过正常工作时间的加班时间越多，精神状况就越差，创造力越低，注意力越分散，眼界和决策力都会退化。另外，你还会渐渐变得多疑、暴躁、易怒。你会讨厌那些工作时间比你少的人，面对越来越多的工作你会变得无助和沮丧，甚至会开始厌恶那些你曾经挚爱与渴望的事业，只有一种方式可以压抑这种焦虑，那就是更疯狂的加班。这是一种病，被称为过劳症。 
　　过劳是创业公司工作的大敌，它会偷偷地占据你，使你变得盲目，最后被它控制。就像一个死循环，你越努力工作，就会越累，就越不能找到高效的工作方法，你就越需要更努力的工作。每个人都或多或少有过过劳的体验，就我自己而言，真是一种糟糕透了的感觉，花了好几个月的时间才完全恢复过来。我的体会是，3～9 个月的高强度工作（在极大的压力下每周工作45 到60 小时）就可以体验到相当程度的过劳了。 
　　　　　　　　　　　　　　　
　　上图所示为加班对劳动产出的影响。开始的时候，劳动产出会随着加班时间增加，但是用不了多长时间，加班的劳动产出会逐渐下降，然后随着加班情况的持续，劳动产出会变得和正常工作一样。再往后持续加班只会导致更少的劳动产出，直到最后受不了以闪人告终。

提示：如果你在一家创业公司工作，那么很有可能你已经或正在体验过劳症的感觉。坏消息是没有一种快速简单的方法可以从这种症状中恢复。少一点工作，多一点锻炼，多花一点时间陪陪朋友和家人，即使这样，要完全恢复还是要花几个月的时间。还有一种较快速的方法是休个长假（3 到6 个星期），或者干脆离开这个项目换一个轻松一点的工作。在你的职业生涯中一定会经历几次这样的过劳症，然后才会学会如何在这些症状的早期就发现它并通过自我管理的方式避免。

　　不要让自己陷入超级能干然后不久崩溃的循环之中，以一种更有效更健康的方式将努力程度维持在一个可持续的水平上。每个人的情况都不相同，动力不同，干劲不同，个性不同，职位不同，我个人的经验是，每周工作超过50 小时就很危险，每周工作超过60小时大概1 个月左右就会出现过劳症。 
　　你的时间是你最珍贵、最难以转换的财富之一。你的一个小时就是恒定的60 分钟，没有办法对时间进行伸缩。与其试着工作更长时间，不如寻找一些方法在每周的40 个小时里为客户为公司为同事创造更多的价值。这句话听起来有点像一句空洞的口号，不过真的要学习一下如何更聪明地工作，而不是更努力地工作。

自我管理

　　使自己生产力最大化的方式是将自己当作一个项目来对待，自己的任务就是项目的任务。项目管理的时候，有三个杠杆对项目进行平衡：范围、成本和时间。 
　　任何时候，增加或者减少范围、成本或者时间中的一个，其余两个变量都必须调整以达到新的平衡。如果你增加工作量，就必须投入更多资源或者延长项目时间。如果你想减少时间以提前交付项目，就必须缩减工作范围或者增加资源。如果减少了投入的资源，就必须砍需求或者延期。 
　　　　　　　　　　　
　　上图所示为项目管理三角，并且加了一些额外的说明以帮助记忆这些应对策略。首先，需要接受的事实是项目管理是一个关于权衡的艺术，花更多的时间和金钱却做更少的事情。当你用这种方式思考工作的时候，就会发现一些其他的办法去平衡项目而不是加班加点。

提示：管理三角里必须考虑质量这个因素。我建议构建自动化测试，确保高质量的代码是功能范围的一部分。质量不是可以权衡考虑的方面，如果你想保持一个长久的高效率，就不要试图通过降低质量缩减范围。牺牲代码质量就像是跟TonySoprano（《黑道家族》的主角）借钱。当你工期仓促压力巨大的时候，牺牲质量似乎是个好主意，但是或迟或早，你都要偿还这笔高利贷（周末加班就是贷款的利息）。

我们进一步看看如何影响工作量、成本及工期，从而使工作负荷更具可持续性。

1. 影响工作范围

“没有数据支持，观点不足采信。”——W.Edwards Deming

　　工作范围通常是最容易平衡工作负载的方式，也是最有调整空间的地方。要更好地管理工作负载的第一步就是要意识到，当你有一个新的任务，或者现有任务需要增加内容的时候，你需要重新评估完成时间，增加可用的资源或者砍掉一些需求范围。 
　　做任何事情都要花费时间，因此再分配给其他任务的时间就会变少。这似乎是显而易见的，但是学习如何基于成本和价值区分任务优先级是管理工作范围最重要的技能。毕竟，一个创业公司想要生存下去最重要的事情就是做正确的事。要想高效地区分任务优先级，需要知道它们的成本和价值，然后基于相对成本价值率划分优先级。 
　　

任务优先级=（任务价值）/（任务成本）

　　等式里面的任务成本部分通常可以用完成任务需要的时间来估计。虽然大一点的项目包含了财务成本（买更多的服务器或者要使用第三方的服务），但是估算起来并不困难，真正困难的是估算任务的价值。大多数时候，人们估算价值仅仅是基于个人的直觉感受，而不是过往的经验或者实际数据。 
　　这种评估价值能力的缺失导致大多数公司开发的东西根本就没什么人用。我见证过人们仅仅根据某个人的直觉感受产生的愿景，没有任何数据方面的验证，就拼命做了很多没有意义的事。事实上，根据一个没有经过验证的愿景进行创业，可能是创业公司失败最主要的原因之一。这也是为什么精益创业运动提倡收集数据并基于经验进行决策。根据经验收集数据，根据数据做出决策，从而减少开发那些没人用的东西的风险。

提示：如果你是乔布斯或者巴菲特，追随你的直觉也许是一个不错的主意，可惜我们大部分人都不是。所以我们的决策应该基于数据，而不是直觉。

　　改变创业公司的决策模式也许会比较困难，而且也超越了本书的范围，不过我强烈建议你阅读有关精益创业哲学的书。即使你不能改变企业现在的决策模式，你也应该收集一些数据，做一些客户访谈，搞一些A/B 测试，试着帮助你的合作伙伴，确保自己不是在做无用功。

　　另外一个减少工作范围的方式是遵循二八法则，知道什么时候停下工作，而不是为了一点边际效益强制工作。二八法则是说 80%的价值由 20%的努力创造。神奇的是，二八法则在软件开发的很多地方都有体现。

• 80%的功能花费20%的时间
• 80%的代码需要20%的时间
• 80%的用户只使用20%的功能；事实上，研究显示，很多系统有一半的功能从未使用。
• 80%的文档价值在20%的内容上
• 80%的BUG 来自于20%的代码
• 80%的代码变更集中在20%的代码上

虽然二八法则很简单，但是真正理解了它，可以避免花费时间去做那些锦上添花的事，让你在事情“刚刚完成”的时候就停止工作，而不会为了达到所谓的100 分无休止地投入。 
二八法则是一种实用主义哲学。在很多地方都会用到二八法则，运用二八法则减少工作量的思路有：

• 和利益相关者一起讨论，将新特性的范围缩小至80%，延迟最困难（代价最大）的部分功能的交付时间。在实现完整功能之前，尽早实现一些最基本的功能，以进行A/B 
  测试，收集用户反馈。这种最小可用产品的方法适用于任何特性，有些时候，这个最小可用产品就是真实用户所需要的全部。
• 尽可能保持功能最小化及简单化。添加新特性的时候使用A/B 
  测试，确保这些特性有用并能产生期望的价值。根本不会被调用的代码是某种形式的技术债，不会被使用的功能应该被删除以降低技术债务。记住，少即是多，特别对于一家创业公司而言。
• 确保只实现那些绝对必要的代码，不要添加那些“有也不错”的参数、类和方法。所有这些“然而并没有什么卵用”的代码都需要测试、文档、理解和管理。少即是多。 
  测试覆盖到85%～90%的代码即可，而不是100%的代码测试覆盖。有些代码块比其他地方更难以测试，测试这10%的代码可能有些得不偿失。
• 创建文档的时候，关注主要信息及高层视图，不必为所有方面创建文档。多画架构图，一图真的胜千言。如果你觉得你的文档是完整的，那么你极可能浪费了80%的时间。
• 如果不出故障就不要试图修复代码。需要修改代码的时候顺便重构这些代码。老代码如果不需要修改就不要动它。你为什么想要重构一个几个月都没人碰的类？就是为了感觉更好一点？我知道这句话听起来有点刺耳，不过这么做看起来真的有点强迫症，对创业公司而言是徒增负担。
• 将手头的任务区分为“我必须要做的”和“我想要做的”，后者会产生大量额外的工作量。工程师们爱学习也爱开发——这样会产生一种偏见，就是只喜欢开发新的而不愿意复用旧的，喜欢尝试新技术而不是用自己熟悉的技术开发。结果就是，在工作中，我们总是追逐最新最酷的技术、框架及模式，而不是用最好的工具。此外，我们又足够聪明，总是能想到办法证明自己的选择对公司而言是最好的。看穿这种偏见可以帮助你减少大量的不必要的工作。
• 不到万不得以不要去做伸缩或者优化。记住，即使你认为自己必须要做，也依然可能落入“我想要做”的陷阱。你不需要对你参与的每个项目都进行水平伸缩，大多数时候这都是浪费时间。据统计，90%拿到种子投资的创业公司都倒闭了。这个统计数据也适用于各种孵化器里的创业公司。剩下10%的幸存者，绝大多数永远也不会伸缩到几十台机器的规模，不需要考虑水平伸缩。如果你在一家创业公司工作，你可以规划伸缩性，但是要尽可能地推迟实现而将精力集中于最紧急的需求上，比如确保你开发的产品是用户真实需要的。

工程师是一群充满激情乐观向上的人，这样的人做范围管理会格外困难。我们想要把所有的事情都搞定，想要所有的事情都做到完美，相信明天下午就能完成所有的事情。我们希望我们的UI 是漂亮的，后端是优化的，数据是一致的，代码是干净的。不幸的是，除非你有无限的资源或者无穷的时间，否则你总要牺牲某些方面为更重要的事情让步。

2. 影响成本

　　还有一种方式可以平衡工作量允许创业公司进行伸缩：增加成本从而减少工作量。你可以将任务和责任委派给其他人或者第三方公司，从而减少你自己的工作范围。如果你的工作太多自己做不完，所有的工作又真的需要做，这些工作也没办法用自动化工具完成，截止时间也不能推后，那么你应该考虑将工作委派出去。 
　　将任务委派给团队里的其他人，你就增加了你的部门的伸缩性。如果你是完成某项任务的唯一人选，那么你就会成为瓶颈并存在单点的风险。针对一项特定的任务让团队里的多个人都拥有处理的能力，这个工作就可以分配给多个人，而不会让自己或某个人成为瓶颈。另外，同一个任务让多个人参与，这样在这个领域获得突破和创新的概率会更大。例如，你的搭档可能会发现一个针对工作流程的自动化或者优化的方法，而你可能永远都不会想到。 
　　为了能更容易地将任务和责任分配给团队的其他成员，你需要确保人们对不同的任务和应用的不同部分都熟悉。因此，你需要让团队成员积极的彼此分享知识并更紧密的合作。 
这里，给出一些实践，有助于项目内部分享知识和责任。

结对编程

　　两个工程师针对一个任务合作工作。虽然这种做法看起来有点低效，但是结对编程可以实现更高质量的设计、更少的BUG，以及更紧密的合作。我并不是推荐所有时间都采用结对编程，但是每周有一天进行结对编程也许是一个分享知识、理解系统、互相学习的好办法。这也是指导团队新成员的一种非常好的方式，新成员可以直观地看到老员工如何思考问题，如何解决问题。

临时讨论会

　　临时组织，用白板或者纸和笔，讨论问题，头脑风暴，获取更好的方案。

持续代码审查

　　团队成员彼此交叉审查代码。代码审查不但可以提高代码质量，同时也是增强合作分享知识的好办法。彼此交叉代码审查让工程师之间彼此提供反馈，落实最佳实践，同时也可以促使工程师不断做出改变，持续进步。 
　　增加成本降低工作负荷的另一种方式是购买第三方服务或者商业工具。通过第三方服务增加团队处理能力有一个非常好的例子，就是使用第三方的监控和报警工具。如果你想自己开发一个监控报警系统，你可能需要花费几个月的时间才能得到一个可用可伸缩的系统。但是，如果你决定部署一个满足同样需求的开源系统，你只需要数天的时间就可以让系统运行起来，但是后续你还要花时间去维护它。如果你决定用第三方的工具，你就可以用花钱的方式节省开发维护这些系统的时间。通过使用第三方的监控服务，持续的金钱投入可以显著代替初始的时间成本及后续的维护时间。类似地，也可以使用各种成熟的商业工具、数据存储、缓存、工作流引擎、视频会议服务，从而降低工作负荷或者增加生产效率。

提示：工程师喜欢开发软件。这种喜欢开发新东西的特点让我们产生一种偏见，就是热衷开发胜过复用。开发监控服务、分析报警平台，甚至数据存储系统只是重复发明*的另一种形式。建议你在投入开发之前，先检查一下有没有已经存在的东西可以免费用，或者可以花钱买。

　　增加成本从而降低工作量的做法通常超出了工程师的权力范围，这些情况要汇报给相关的业务领导。完全不必做这类工作是改善伸缩性的一种手段，可以让你百分百地关注用户的需求。

3. 影响计划

　　影响项目管理的三个杠杆的最后一个是影响计划。和影响成本类似，决定某个功能何时发布通常不在工程师的掌控之内，但是你还是可以通过向业务领导提供某些反馈在某种程度上影响计划。大多数时候，截止日期和功能发布的命令都是可以谈判的，也会根据成本进行考量。某些特别的情况下，比如公司需要应对一个激烈的市场竞争，或者公司签了合同需要按时交付产品，那么你可能就要面对一个难以变更的截止日期，不过大多数情况下，事情总是可以商量的。 
　　需要澄清一下，我不是说你应该不遵守截止日期。延期发布通常都是糟糕的，对公司也会有伤害。我是说，在创业公司工作，你和决策者的距离会比较近，你可以在决策上影响交付的成果和时间。不是消极地听从指令，而是积极地向业务领导者提供反馈，让他们知道哪些功能是比较容易快速开发的，哪些功能是比较困难有风险的。这样，领导者就可以更好地理解成本，正确地评估任务的优先级。 
　　为了持续提供反馈，我建议发布节奏更快速，每次发布的东西少一点，这样可以更快速地获得用户反馈，决定是否还要继续原来的开发计划，是否有必要变更开发方向做点别的什么。快速学习是精益创业方法论的精髓。你频繁发布、收集反馈和数据，然后决定下一步的动向，而不是提前做好全部的计划。将产品开发分割成较小的迭代，可以减少风险降低出错的成本，风险和出错对于创业公司而言几乎是不可避免的。 
　　比如，如果要扩展一个电商平台允许外部供应商开通他们自己的在线店铺，可以将所有的需求都列出来，制订计划，然后基于这个计划开发3到6个月，最后将新功能发布上线。开发的这几个月期间，没有任何用户反馈，感觉像悬在真空中开发。既没有办法知道用户是否喜欢你开发的这些功能，又没有办法知道用户想要的其他功能。一次发布需要的时间越长，开发出的东西不符合用户需求的风险越大。 
　　更好的开发方式是将需求按照类似分镜头剧本那样的方式进行分割，将发布控制在一个尽可能小的范围内，每一次发布都基于上次发布的用户反馈进行开发。通过更加快速的发布，你有机会和用户进行频繁的互动，进行调查，收集A/B 测试的数据，基于这些信息，可以重新定义待开发的功能列表，而不是按照事前的规划全部开发。将一个大的功能分割成小的功能，依然遵循二八定律，你会发现已经开发出来的功能对用户而言通常已经足够用了，待开发的各种功能其实并没有特别强烈的需求。 
　　此外，将功能分割成小块后，你可以使用mock 的方法，特别是在创业公司的早期。 
　　mock 是指并不会真正实现的功能，但是这个功能会呈现给用户，以此判断用户是否感兴趣进而决定是否要真正实现这个功能。 
　　比如，你想实现一个人工智能算法，可以自动给卖家上传的商品图片打上标签，但是这个功能可能需要几个月甚至几年的时间才能开发完成。那么就可以用mock 的方法试验一下，先在数据库里随机选择一些商品图片作为例子，然后让员工在没有人工智能算法的情况下对这些图片手工打标签，最后通过A/B 测试的方法分析卖家的行为及对搜索引擎优化的影响。通过这种mock 的方式进行数据收集，创业公司可以以更快的方式（只需几个星期）获取关于这个功能更多的有价值的信息，基于这些信息，你再决定是否继续开发这个功能，还是去做点别的。 
　　根据公司的情况及你的职位，你可能很容易就控制范围、成本或者计划。通过各种权衡及向业务领导进行反馈，你可以更好地平衡工作负荷以避免过度工作。

　　本文选自《互联网创业核心技术：构建可伸缩的web应用》，想及时获得更多精彩文章，可在微信或微博中搜索“博文视点”并关注。