前谷歌工程团队负责人：如何打造一个完美的产品
一个产品能脱颖依靠的是执行力，而不是那些少得可怜的新思路。Niniane Wang曾带领过谷歌和微软的工程团队，在带领团队、管理项目有着丰富的经验。此次，他将自己的经验一一分享出来，并且对软件开发者提供了一些优秀的建议。
曾有一位谷歌工程师想到了一个浏览器扩展的好点子。于是他展开工作并在几周内开发出原型，随后他在网上搜索是否已有类似的产品，结果不尽人意。他的想法在网上到处都是，甚至还有多种同概念的衍生品。
事实证明，这种情况很普遍。即使用很少的时间久能开发出产品，但你也立刻发现每个创意都曾被一种或多种方式实现过。因此，若你想让产品能成功，就需要依靠卓越的执行力，这才能确保产品能脱颖而出并取得成功。如何以最佳方式来执行项目？以下就将针对软件开发的每个阶段提出一些建议。
功能规划
很多时候，一个产品能具备绝对的竞争优势，有可能是因为其使用了一项新技术，而该技术尚未被别人所用。例如，随着智能手机计算能力的日益提升，Instagram才能处理复杂的图像。在此之前，只有PC才能完成这样的工作。随着浏览器渲染功能日益强大，我们公司才能扩展浏览器内置的编辑器功能，如曲线文本、文本路径和拖拽编辑框等。
所以，技术发展中机遇就显得尤为珍贵，这往往能为你的产品带来新功能，还能在竞争中脱颖而出。当你发现新技术时，需要先评估需要哪些资源，如高存储或是宽带连接速度，然后再确认你的用户群是否与这些资源相互匹配。
例如，如果你要采用一项依赖HTML5的技术，而你又知道HTML5已经普及北美地区的75%的用户。那么，你就可以在此道路上走下去，开辟新功能，大大提升产品的竞争力。
原型
在你还处在初期阶段，尚未确定功能组合和原型时，有可能会陷入两种常见的问题。有趣的是，两种陷阱截然相反。
第一个问题是，有时人们在为原型做技术选型时，往往为了扩展产品线而需要重构。这就是为什么Google Linux架构里会出现唯一一个.NET项目的原因，直到它被迁移前一直需要特别的照顾，全新的PHP项目也是如此。作者表示，如果他们想让项目成功扩大规模时，就会遇到一些不得不解决的难题。
这个问题主要在于，假设未来你和工程团队有充足的时间和资源，想轻松地依照可扩大规模的架构重新打造这款产品。你会发现，实际时间比你想象的要紧迫很多。也许需要数月或数年才能重新打造一款产品，而在这期间，你产品的功能肯定止步不前，你的用户也失去耐心抛弃你，投到竞争对手的怀抱中。
而第二个问题与第一个相反。曾吸收过规模化的惨痛教训的开发者，他们一开始会把时间浪费在寻找和聘请规模化专家的准备上。即使他们拥有非常棒的MySQL数据库，但也会花大量时间去研究 Cassandra和Reddis，以防产品初期获得爆炸性的成效。这种做法其实就在拖延产品进度。
为了避免上述两种问题，我建议的解决方案，是从一开始就选择哪些成功产品的解决方案。虽然它不是最优化的解决方案，但却是一个行之有效的方案。确保你选择的技术能满足大部分用户。此外，你还要确定该技术可以获得开发者的支持，这样才能聘请到精通的开发者。一旦做了这些事，就不要再考虑其他方案，专注将产品做到最好。
微调
当产品完成原型阶段并确定了功能组合后，就应该开始去完善产品。要时刻记住最终用户与产品的计算公式为:
User satisfaction = Rewards from using your product – Irritations
（用户满意度=使用的好处-烦恼/麻烦）
如果你已经解决了前两个问题，就说明你采用了先进的技术，并开发了完美的原型。而接下来就要专注于为用户减少烦恼。
当用户使用产品时，若把常遇到的小烦恼集合到一起，就会让用户觉得体验很差。例如：一个没有反馈的按钮，用户按了之后没有反应，是应该继续按，还是等待。或是一个加载时间超长的页面，用户还看不到加载进度。当种种问题汇集到一起时，用户就会被这些小细节所惹恼，最终对产品失去兴趣。
最完美的用户体验通常是通过以下几点结合实现的：
- 先分析参数，再提升用户体验；
- 测试使用性能；
- 亲自试用后，再修改痛点。
总体而言就是检测延时、错误率、保留或转换到业务目标等。为了减少网页延迟，确保运行YSlow，并遵循Steve Souders所述的JavaScript、CSS和HTML最佳标准。此外还可以通过分析工具实时监测真实数据，如NewRelic，可以监测服务器延迟并自动收集用户的崩溃和错误报告。
对于用户体验，我觉得《Don’t Make Me Think》和《Rocket Surgery Made Easy》两本书在描述过程中发掘漏洞方面很有用。
最后，最完美的用户体验往往来自本人（家庭或朋友），他们会积极地使用团队的产品。如果工程师、产品经理、测试和用户体验设计师，每天都会在使用过程中完善产品，那么必定会消除产品硬伤，最终将打造出一个与众不同的完美产品。
