Personal "scalability" scenarios for startups

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

Overtime is not a flexibility solution

  Working under enormous pressure, limited resources, compressed schedules, and severe uncertainty can be nerve-wracking, which is the norm in startup work. Startups are an emotional cocktail, engaging, exhausting, and rewarding at the same time, but be careful not to let startup become a goalless game and work a thoughtless impulse. 
  It seems natural that the longer you work, the more productive you are. Put a little more pressure on yourself, work long hours every day, even on weekends, you're energetic, purposeful, hopeful, trusting in the future, it seems like the right way to do things, and the sacrifices don't seem to be big , and that feeling of being needed is also great, feeling like a hero. 
  The problem is that it's not a long-term solution, and working overtime is a very bad way to achieve personal productivity scalability. The more overtime you work overtime, the worse your mental health, the lower your creativity, the more distracted you are, and the worse your vision and decision-making skills are. In addition, you will gradually become suspicious, irritable, and irritable. You will hate those who work fewer hours than you, you will become helpless and frustrated with more and more work, and even start to hate the careers you once loved and longed for, there is only one way to suppress this Anxiety, that's more crazy overtime. This is a disease known as overuse disorder. 
  Overwork is the enemy of startup work, it stealthily occupies you, blinds you, and ends up being controlled by it. It's like an endless cycle, the harder you work, the more tired you will be, the less you can find efficient ways to work, the more you need to work harder. Everyone has experienced burnout to some extent, and in my case it was a terrible feeling that took months to fully recover. My experience is that 3-9 months of high-intensity work (45 to 60 hours a week under extreme pressure) can experience a considerable degree of burnout. 
               image description
  The graph above shows the effect of overtime on labor output. At the beginning, the labor output will increase with the overtime hours, but after a long time, the labor output of overtime will gradually decrease, and then as the overtime situation continues, the labor output will become the same as normal work. Continuing to work overtime further will only result in less labor output, until it ends up being unbearable.

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

  Don't let yourself get caught up in a cycle of being super competent and then crashing sooner rather than later, and maintain your effort level at a sustainable level in a more efficient and healthier way. Everyone's situation is different, motivation, drive, personality, and position are different. My personal experience is that working more than 50 hours a week is very dangerous, and working more than 60 hours a week will appear about a month or so. overwork. 
  Your time is one of your most precious and hard-to-convert treasures. Your hour is a constant 60 minutes, there is no way to stretch it. Instead of trying to work longer hours, find ways to create more value for your clients, your company, and your colleagues in those 40 hours a week. It sounds like an empty slogan, but really learn how to work smarter, not harder.

self-management

  The way to maximize your productivity is to treat yourself as a project, and your tasks are the tasks of the project. When it comes to project management, there are three levers that balance a project: scope, cost, and time. 
  Whenever one of scope, cost, or time is increased or decreased, the other two variables must be adjusted to achieve the new balance. If you increase the workload, you have to dedicate more resources or extend the project time. If you want to reduce the time to deliver the project ahead of time, you have to reduce the scope of work or increase the resources. If the resources invested are reduced, the demand must be cut or postponed. 
           image description
  The diagram above shows the project management triangle with some additional explanations to help memorize these coping strategies. First, accept the fact that project management is an art about tradeoffs, spending more time and money doing less. When you think about work this way, you'll find some other ways to balance projects instead of working overtime.

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

Let's take a closer look at how workloads, costs, and durations can be impacted to make workloads more sustainable.

1. Affect the scope of work

"The opinion is not credible without the data to support it." - 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 better way to develop is to split requirements in a storytelling-like manner, keep releases as small as possible, and develop each release based on user feedback from the last release. By releasing more quickly, you have the opportunity to interact with users frequently, conduct surveys, and collect data from A/B testing. Based on this information, you can redefine the list of features to be developed, rather than developing them all according to a prior plan. Divide a large function into small functions and still follow the law of 28. You will find that the functions that have been developed are usually sufficient for users, and the various functions to be developed do not actually have a particularly strong demand. 
  Also, after breaking the functionality into small pieces, you can use a mocking approach, especially in the early days of a startup. 
  Mock refers to a function that is not actually implemented, but this function will be presented to the user to determine whether the user is interested and then decide whether to actually implement this function. 
  For example, you want to implement an artificial intelligence algorithm that can automatically label product images uploaded by sellers, but this feature may take months or even years to develop. Then you can use the mock method to test, first randomly select some product pictures in the database as examples, then let employees manually label these pictures without artificial intelligence algorithm, and finally analyze the seller through A/B test method behavior and impact on SEO. Through data collection in this mock way, startups can get more valuable information about this feature in a faster way (just a few weeks), and based on this information, you can decide whether to continue developing this feature, Or do something else. 
  Depending on the company and your position, it may be easy for you to control scope, costs, or plans. With various tradeoffs and feedback to business leaders, you can better balance workloads to avoid overwork.

  This article is selected from "Core Technologies of Internet Entrepreneurship: Building Scalable Web Applications". If you want to get more exciting articles in time, you can search for "Blog Viewpoint" in WeChat or Weibo and follow.

                    image description

      

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326612765&siteId=291194637