以下英文内容来自First Round Review，由网易创业Club重新删减排序整理后加上原创中文解说，不是翻译哟。为了便于理解，我们把中文内容放在相应英文段落的前面。最后，跳过全部英文也不影响阅读的完整性。

原文作者是Jocelyn Goldfein，她曾经在Facebook和VMware担任工程总监,现在是一名天使投资人。她对创业项目在超高速增长时期的工程团队组建很有经验。

文/网易创业Club 傅昊

很多工程人员对于软件的开发、部署和交付流程都有自己的偏好，但是，基于个人和团队偏好的策略是正确的做法吗？

在本文中，Goldfein对于软件产品（包括2B型产品和2C型移动应用）的开发策略给出了两个用于决策的依据：

A）基于用户需求来决定软件开发策略优先级；

B）基于用户风险偏好来决定部署模型。

Goldfein的内容从给自己吹吹牛开始了：

G小姐本人在2C的Facebook和2B的VMware工作过。管理过小型和大型的项目团队，开发并交付过免费的消费者应用和昂贵的企业级软件。

I’ve been around the block and shipped a lot of software. I’veworked at tech companies ranging from three to 10,000+ employees. I’ve builtsoftware that’s been given away for free and sold for $50M license fees — andjust about every price point in between. Every one of these products wasdeveloped and delivered differently, and after having the chance to compare andcontrast them all, I’d love to reveal the one true way to ship software.

来对比一下2B和2C初创在软件开发和交付上的不同要求：

在VMware还是小型初创的时候，它必须为目标企业用户提供可预期的交货时间以及高可靠性的产品。只有如此才可能敲开天生保守的企业客户的大门。

在Facebook的初创期，它需要建立的是基于先发优势的网络效应。所以对于早期Facebook的产品交付主要的要求就是一个字：快。

Consider two of my past lives:

· When it was a startup, VMware needed to offer predictabledates and high reliability because they had to convince conservativeenterprises to buy operating systems from an upstart new vendor. (At the time,virtualization sounded like science fiction!)

· In Facebook’s startup days, they needed to move quicklybecause first-mover advantage meant everything for a product based on networkeffects.

上面的鲜明对比说明了一件事，软件交付流程的选择不应该基于个人和团队偏好，而是应该基于项目所处阶段和公司所希望实现的目标。

在不同阶段和目标下，所应使用的软件开发、交付策略可能截然不同。

开发团队应该具备对交付时间的可预测性、产品可靠性与快速扩展性进行动态取舍的意识和能力。

如果开发团队认准一条“金科玉律”闷头走下去，很可能会撞到南墙还不明白咋回事。

My fellow engineers, please stop asking “Is this process good or bad?”and start asking “Is it well-suited to my situation?”

所以，正确的软件开发、交付姿势应该怎么找呢？

A）基于用户需求决定软件开发策略优先级

用户/顾客是你未来变现的基础，从商业上而言，如何实现未来的规模化变现是最重要的事情。那么，这就意味着你的软件开发、交付策略应该服从于公司自身的商业目标。

To determine “the right way to develop software,” you’vegot to understand what matters for your product and how to optimize for that.This isn’t based on personal preference. Ultimately it stems from your company’smission, and the way you make money is a reasonable proxy for that.

如果有人掏钱买你的产品，这意味着他们“很需要”它。你的产品卖得越贵就说明它对你的用户越关键。很自然的，它的可靠性、功能性和交付时间的可预测性就是最为关键的因素。宕机、延迟、bug都是不被允许的。

对于低价或者免费类的软件或者应用，你必须通过良好的用户体验让他们“想要用”你的产品。你应该在优先考虑提供良好的用户体验和风险应对措施的前提下追求发展速度，允许一些可以被感知到的bug的暂时存在。

As a rule ofthumb, expensive software means predictability is key while shipping. Customersneedyourproduct. If you have a lower (or no) price tag, focus on UX. Users who don’tneed your product have to want it.

Chances are, if you sell software at a high price tag,you are selling to businesses that are buying your software based ontheir need. The moreexpensive your software is, the more mission critical it is for your customers,the more likely you have to optimize for reliability, functionality and apredictable schedule. You might think business customers would like yoursoftware as soon as possible, but because they have a lot of dependencies —deployment, training, integration — it is generally much more important to themthat you be predictable than yoube fast. Larger dealsizes also go hand in hand with fewer customers, meaning that each customer hascomparatively more power over you and satisfying their needs is more crucial toyour startup’s survival.

Well, what if your customers aren’t demandingenterprises? As you charge less and less (from millions to thousands, tohundreds, to freemium and free), your market goes higher volume and involvessmaller businesses or consumers. For these products, schedules can be less importantsince people will generally accept your latest enhancements whenever theymaterialize. The influence of a single customer is small, so you mightdeprioritize a niche platform or bugs that affect only a few people.

在考虑目标用户时，应该结合产品的发展阶段来选择更为合理的开发策略。

如果你预计自己产品的用户数量将在一年内大量增长，那么适度的降低质量、追求速度是可以接受的。

如果你的产品面向的是持续交费用户，你就最好减少犯错误的次数。也就是说，你不得不适度的降低产品的交付速度。

Stage matters here, too. If you are growing quickly,trading off quality might be acceptable if 80% of your users one year from nowwill be new and won’t remember your mistakes. On the other hand, if repeatbusiness (aka recurring revenue) is your game, you’d better make sure currentcustomers are delighted.

B）基于用户风险偏好决定产品部署模型

先评估用户的风险偏好，然后决定你的软件部署策略。

Figuring out your own software development style meansyou have to contemplate your own appetite for risk.

VMware和Facebook的用户风险偏好明显不同，因此两家公司所采用的技术栈和部署策略完全不同。

It’s probably obvious to the world that VMware issubstantially more risk averse than Facebook. Realize that it is not becauseDiane Greene and Mark Zuckerberg have different personalities, nor because oneof them is right and one of them is wrong. They are different businesses withdifferent technology stacks and they appropriately ship software in completelydifferent ways based on how much risk their customers can absorb.

对于基于风险偏好的部署策略，原文用相对零散的语言说了很多，我们提炼清楚意思就是：

一旦你的产品出了问题，如果用户留存率仍然较高，那么用户的风险偏好就比较高。反之，用户的风险偏好就比较低。

对于高用户风险偏好的产品，项目团队更多需要考虑的是在产品开发和生产环境下开发与维护的可扩展性和便利性，你可以把能够在云端部署的部分尽量部署在云端；

对于低用户风险偏好的产品，你的部署环境应该满足把产品出错概率降低至某个水平之下以及一旦出了状况保证修复时间在某个范围之内这两个硬性要求，也就是说保守和稳定性在这类产品部署策略中占据优先地位。

在云端部署为产品的开发运维带来诸多便利性。

Deploying in the cloud means you have total control overthe runtime environment of your software. It means you don’t have to have thewords “test matrix” in your vocabulary, which exponentially reduces testingtime and volume of bugs to fix. You can update whenever you like; distributionis instantaneous and universal (and doesn’t require effort from users.) Codethat you delete actually goes away. You don’t have to worry about fixing bugsin code that you abandoned two releases ago because a user has not moved on.Deploying onto a customer’s device (which includes everything from nativemobile apps to operating systems) means the once and future cost of doing arelease is radically higher.

移动端应用对用户体验要求高，完全做云端部署未必合适。

Of course, you don’t have the freedom to choose to deployin the cloud just because it makes life easier for you. Some products(operating systems or video game consoles) simply can’t exist entirely in thecloud. If you build for consumers on mobile, you’ll probably choose a nativeapp so you can deliver the best UX, because at least in consumer, rich UXtrumps engineering productivity. I know it sounds preposterous, but be preparedfor shipping mobile apps to have more in common with shipping operating systemsthan with shipping for the web. That’s why even if you are mobile first, youwant all of the brains of your mobile apps to live on the server where you caneasily change them.

显然，2B的收费软件对于部署的稳定性和快速修复性要求会更高。

To crystalize how deployment and risk compound: if youhappen to sell on-premise system software to enterprises for lots of money, youhave magnitude-of-pain and lengthy time-to-update both working against you. Youcan count on the same kind of mistake costing you two orders of magnitude morethan if you provide a free web-based service to consumers.

适度保守的部署策略可以有效的降低出故障的概率以及修复故障的所需时间，从而在更大程度上让用户体验保持在可接受的程度上。

保守的程度需要团队根据用户风险偏好对相关方案进行取舍。

Deployment model affects risk, too. When customersexperience problems, the speed with which you fix your mistakes can be asimportant as how bad the mistake was in the first place. When you can push ahotfix to your server and instantaneously solve the problem for every user, youhave an order of magnitude faster remediation than if your release processinvolves a two-week QA window and an App Store review process for the smallestcode change, after which customers install the patch at their own convenience.

C）总结：开发团队也需要抬头看路

开发团队的主观能动性的确非常重要，但无论是管理层还是开发团队都应该清楚的事实是：公司的愿景和所要实现的价值是确定的，在这个层面上讲，软件的开发流程不应该由团队的开发习惯来决定。

软件产品的开发和交付是公司战略和文化的有机组成部分。工程团队可以有自己的个性和偏好，但这应该是在具备战略认知基础上的策略和偏好。

因此，明白公司的商业模型和目标用户的风险偏好是确定合理产品开发策略和部署方案的基础。只有在这个基础上所采用的软件开发策略才能更大限度的让公司面向增长并规避风险。