体验为先
一般的想法似乎是：产品部负责体验，技术部负责实现细节，这两者虽相辅相成，但终究关注点不同。不过我觉得其实技术部也应该关注体验，这种体验是开发体验、运维体验和用户体验，至于实现细节，反倒是最后需要关注的。这样提的原因是，确实有一些技术的人一见到好的新奇的技术就像应用到项目中去（本身没什么不好），却没把体验这件事情做好（这个有点不好）。
现在来说说我对体验的理解。作为开发者，最大的目标绝不只是开发符合需求的产品。产品的开发、实施、上线、维护等过程都涉及大量不同的人，每一个相关的人对这个产品都有自己的体验，都会对这个产品在某一方面上是否好用有自己的看法。就像体验不好的产品会被用户弃用一样，过程体验不好的产品也会被开发者抛弃，只是迟早的事。
开发体验好也就是代码具有很好的观赏性、架构容易懂、代码质量高、具有可伸缩性等，它是开发过程中最需要注意的事情。
代码是开发者之间的交互工具，一个开发者写出来的代码其实就是其他人未来将用到的“界面”，它的体验直接影响到它的用户（所有与它相关的开发者，包括作者）对它的看法。开发体验不好的代码，在完成自己的当前使命之后很可能会很快被开发者厌倦，甚至废弃，如果一个组织不断在废弃旧代码，做重复造轮子的事情，这种开发成本当然很大，其中明显有问题。
这里有一个很有趣的问题，如果牛人写出来的精致无比的代码是否就一定是具有好的开发体验的代码？这还真不一定。如果确实周围的人一个都看不懂这代码，要么就不要把代码写那么好，浅显一点会更好，要么就多找一点能看懂这种代码的牛人。过于美妙而难以理解的代码是定时炸弹，一旦牛人离开就会面临难以维护或者必须重写的风险，这对于公司而言是不可接受的。说到底，体验是人的主观感受，不同的受众就有不同的体验，好的体验的定义也不同。
做好了开发体验，其次要做的是运维体验。运维体验主要包括更新服务、排错、监控的复杂程度等，主要的用户是运维人员。现在搭建一个大容量的网络应用至少需要几十台机器，机器之间的互相依赖如果管理不好就会变成网状，有点牵一发动全身的味道。有些时候开发者相比运维体验，更关心功能是否能实现，这是有问题的。对于互联网企业，不变的是变化，任何一个服务上线之后都会有用户不满意的地方，如果升级的运维成本比较大，开发者/产品负责人就会惧怕改变，这将直接影响服务质量和用户体验，最终还是害了产品。
此外，作为开发者应该时常思考如何量化服务的质量。是不是满足了一定的服务质量指标就好了？还有没有其他指标？在不同阶段这些问题的答案都不一样，比如已有服务基本稳定之后，开发者可能会从最初的服务质量转而关注如何发现服务性能瓶颈上，这时，难以运维（或者说“监控”）的服务就会显示出弊端，甚至变得没法满足运维体验方面的需求，导致重新开发。
所以在代码设计完了之后就开始考虑如何运维它是一个很值得建议的做法。
最后，好用的产品要落实到用户身上，他们的用户体验是绝对产品成败的关键。在这个时候，开发者可能有的误区是追求完美，希望在项目结束的时候就解决所有已经发现的问题，这其实完全没必要。很多大软件（例如微软的各种软件）遗留一堆bug就敢发布，为什么，就是因为开发者应该追求的是用户体验，而不是那些完全不影响用户体验、只有geek可以发现的微小缺陷。
另外，有这种追求完美思想的另一个原因是惧怕变化，希望一次性做完之后再也不去碰这份完美的代码，实际上这也是不切实际的。保持重构才是我们应该追求的目标，无论是针对代码本身，还是各种体验。
我们在某些时候或许可以追求快而放弃一个或两个体验而直接追求用户体验，但最后还是要补课，欠下的总要还。同时，不要一次性就把三种体验追求到极致，它们应该是迭代完成的。
要想一开始就能做到较好的开发体验、运维体验直到用户体验其实并不难，难就难在有没有这样去理解这些事情。说白了，就是有没有在各个环节为他人着想、为未来打基础，这才是一种做产品的开发者。
好久没更新了啊
[回复]