举个我遇到的情况，原来一个同事去一个公司做负责人，他天天搭基础，优化系统，后来不知道什么原因走了，而产品负责人这么评价他「来这么久一个产品也没上线」。这个例子对技术人员应该很具有打击性。

　　不要有求必应

　　和技术合作最多的就是产品人员，个人觉得产品人员思维有点发散，做任何事情都比较着急，天天思考这个功能，那个功能；一个简单的数据需求就问技术要不要弄个后台出来。反正一刻也不会让你闲着。

　　对于一个成熟的技术负责人来说，不能什么都快速答应，因为这是对自己的伤害，第一开发人员就算多一倍也会不够，需求会源源不断的来；第二产品人员很多情况会考虑不成熟，假如你完全按照他们说的去设计，方案会非常复杂，有的时候逻辑性也会显得有问题，会让系统很难有效的持续运转。第三有时候人工完成的时间比开发一个系统完成的时间少得多，所以少开发一些无意义的脚本或后台，比如刚开始产品人员觉得这个数据很重要，过了几天就会突然觉得没用了。

　　这样的例子很多很多，我的意思并不是不去配合产品人员，而是从自己专业角度出发，给出合理的意见，当然需要避免激化矛盾。

　　不要依赖测试

　　在创业团队，由于开发时间要求特别高，开发人员在评估时间的时候，特别喜欢加上测试时间，等同于拿测试时间完成其开发时间，这是一种非常不好的行为。比如说一个项目开发时间要 5天，测试时间要 5 天。看上去好像开发时间只占一半（开发人员好像很高效），但实际上测试时间开发人员肯定还在开发，给测试人员的是一个半成品。另外开发人员知道有测试人员会测试出问题、会把关，初期的开发质量肯定不高，这种案列见过很多。

　　所以不要变现的用测试时间弥补开发时间，有可能的话，开发人员自己负责测试，当然这个实际操作起来有困难。

　　这篇文章有点偏理论，每个公司有其特殊的情况，中心想表达的思想就是先考虑不犯错，然后再考虑更好的改进；在创业早期，追求轻量而不是重量；技术成本非常昂贵，需要效率。

　　在这个高速发展的互联网时代，人们总是喜欢快中求快，希望站在别人的肩膀上做自己的架构。很多开发者和架构师花了大量时间研究知名公司的企业架构，把这些资料当个宝，但拿回家后发现并不是那么回事。究其原因，只能说是参考的架构实践太多，但了解和领悟的架构知识太少。

　　道是事物发展的本质规律，术是事物发展的具体途径。《架构漫谈》系列文章其实就是想和大家聊聊架构之道，希望大家能领悟架构的本质，不拘泥于现有的实践和理论框框，而是以最直接的方式解决问题，无招胜有招。