三权鼎立形式的软件开发方式

什么是三权鼎立形式的软件开发方式？估计所有的开发者都听说过瀑布式开发模式，xp测试驱动开发模式等等，这是从软件的开发方法来说；而我要说的，是催生软件最终成型/上线所需要的公司组织架构模式的，跨部门，跨组协作方式的软件开发方法。二者着眼点完全不同。

根据互联网源远流长的来源，几乎从一开始（实际也不长，在国内顶多十几年时间），互联网公司的领导者们就发现了一个尖锐的矛盾，那就是用户体验（UED）和开发出的软件的易用性方面的矛盾。简单来说，就是开发者开发出来的互联网产品，自己觉得相当满意，经过一番颇费口舌的培训和讲解之后，各部门领导和老板也都很满意；然而网站上线，产品发布之后，纷至沓来的互联网用户却不买账，不这么看，他们可能普遍觉得你这个互联网网站/产品，非常的难以使用，自己想浏览的内容很少或者干脆没有，换句话说，这个网站不具有粘性，用户不乐意在这个网站久呆，或者不乐意将网站放入收藏夹下次再来。
这成了互联网初期一个非常伤脑筋的问题，至少老板很受伤，程序员则悠然自得。
为了解决这一问题，聪明的老板马上想到，可以组织一个新的部门，对程序员开发网站进行监督和牵制，同时，还有一个好处，也可以在不懂技术的领导，总监们和技术人员之间架起一个桥梁，起到润滑和交流沟通的作用-于是产品部门应运而生了，这是一群介于技术人员和领导之间的群体。他们本身可以懂，也可以不懂技术，但却引领技术人员，设法灌输领导，老板的思想，同时，最大可能的考虑用户体验。某种意义上，产品人员是一个互联网网站/产品的最初用户，经过了产品人员的把关，再通过互联网站输出自己的产品，思想等，显然比从程序员直接输出要好很多。可以说，在互联网初期，这是一个伟大的变革。
因为产品部门的诞生，非常好的解决了程序员，公司各级领导，公司业务部门（运营，销售，BD等）以及用户之间的种种矛盾。

互联网初期，几乎就是产品和技术两大部门在互相合作。若干年后，一些先驱者开始提出测试驱动及若干测试理论，论证了测试的重要性，这时，QA部门粉墨登场了。至此，三权鼎立的三大部门，产品，技术，QA全部出现，并且巧妙的实现了互相制衡的作用（这一点本文不论述），一直沿用到现在，虽然在实践的过程中，在不同公司文化的沉淀中，产生了各种不同的侧重形式。但是根据笔者的经验，只要是沿用了这种组织架构方式来进行软件开发，那么结果通常就是，delay,delay再delay.
幸好有一句话解除了delay所带来的困惑，那就是在互联网的世界里，大力赞成缓慢发布。

为什么肯定的有delay说呢？我们先来看产品部门。随着时代前进的步伐，产品部门从初期的利大于弊的地位，渐渐的需要重新界定了。
首先，一个众所周知的问题，在这三方中，通常技术人员的薪资比较高，而做黑盒测试的QA人员薪资处于最低或者和产品设计人员持平。因为这个原因，非常容易造成基本产品设计人员和测试人员都是一些初出茅庐的新手，同时为了更好的使用户满意，我们也更趋向于招聘一些不太懂互联网的人，用他们的思维角度去设计各类网页页面，因此，大量产品设计人员的水平可想而知（不包括精细算法，用户行为心理研究等高精尖专的产品设计人员，这类产品人员往往自己以前也进行过编码和程序方面的专业积累，水平令人尊敬）。
相反的，开发人员则很多是在互联网行业有多年从业经验的开发者，然而这种开发模式中，首先假定了开发人员根本不懂UED。
随着互联网时代的不断深入，可以说，现在的程序员，有哪个在开发互联网站之前，自己没有访问过任何网站呢？对于一个网站上基本的功能，例如CRUD，列表页面显示，图片，文件上传下载，视频音频播放等，有几个程序员没有自己亲身访问过呢？用户体验（UED）已经不再是用户和程序员之间的障碍，一个提交按钮应该怎么放置，相信一个初级程序员也懂得。可以毫不夸张的说，大部分程序员本身已经可以担当起基本产品人员的职责。
起根上说，对于那些完全不懂技术的产品人员设计，由于他们本身不具有开发人员的很强的逻辑思考行为，所以设计出的网站，产品的种种功能，基本上都不能自圆其说，可以说是漏洞百出。设计样品交到开发人员手中，稍微揣摩就会发现很多漏洞，这个时候只能再打回重新进行设计，时间首次被delay。然而更糟糕的是，由于各种历史原因，如果遇到在这一环上非常较真的产品设计人员，明知是错，也绝不承认。在这种互相扯皮的状态下，往往是开发者明知道这样行不通，也只好按照错误百出的方案进行编码。其结果可想而知。

其次，随着时间的推移，产品部门的一些弊端渐渐被放大并传播开来。到现在（2011年），已经形成了一些固有的思维模式。几乎所有的公司都有绩效考核，技术人员需要绩效考核，产品人员和QA测试人员也需要。这就直接带来了部门间的利益冲突。在利益驱动下，不言而喻，产品人员是不希望技术人员按时完成任务的，通常无论技术人员怎样努力，都会被各种设计变化所包围而拖延工期，正所谓计划赶不上变化。那么，此时通常再次delay，而不明就里的领导，显然倾向于把责任归咎于技术人员。往往总监级以上的领导，不懂技术，不是技术人员出身。也不愿意给技术人员话语权，更愿意倾向于产品人员(有更多的共同语言？)。
同时，经常的，还需要产品人员来带领这个项目和团队。可是，如果这个产品人员是新手，正好应了一句老话，兵熊熊一个，将熊熊一窝。
从自己多年开发经验上来说，感觉开发者很多都极具理想主义，并且普遍存在严重的偏执狂症状，表现出来就是自信心极度膨胀，不服输，甚至不认错。还可能一些人完全听不进去产品人员的想法，完全脱离产品需求而追求自己的理想状态。这样的开发思维当然必须改进纠正，但同时，产品设计上的需求，在开发时就频繁修订，必然使软件开发的时间delay。

那么，从产品设计到技术实现这个环节上，就已经形成了必然发生的delay。

接下来QA测试人员隆重登场。然而目前国内所说的测试，基本都是指黑盒测试，大致等同于游戏开发那种游戏试玩者一样。当然，需要进行大量的边缘和阈值等测试。前面已经说过，如果遇到那种漏洞百出的设计，而产品人员又拒不承认，其实开发时，开发者已经知道错误百出，那么测试者一经测试，也会迅速发现这个产品到处都是漏洞，错误百出。此时，他们自然而然的觉得这些错误是开发者造成的，开始抱怨技术人员，这样的软件也好意思拿来送测，你们开发部的人都是吃屎的啊，立即挑出无数多bug，打回修订，或者直接以bug过多为由，不予测试（达不到测试要求），打回重新开发。请注意，这个时候产品部门的任何可能的犯过的错误和责任都被忽略了。软件的完成/上线时间再一次delay。

从上面对三者间互相协作的论述，不难看出，以这种方式来完成一个软件，要想按时完成，实在是有些天方夜谭，痴人说梦。而透过这些文字，又清楚的说明，这三者之间，只有开发者，程序员是最辛苦的一群人，需要耗费大量的脑力和体力，不断对软件进行修修补补，只有最终满足要求才可放行，否则必被打翻在地，不得翻身，寝食难安。而其他二者最大的作用就是监督和质量保证。

最后说一点题外话，软件到底是写出来的，还是测出来的，抑或是产品人员设计出来的？一个成型的软件以最大程度体现了软件开发者的思维模式，逻辑习惯甚至宗教信仰，国家出生地等复杂的因素，在行家眼里，她并不是一堆毫无生命力的，冷冰冰的英文字母组合。富有经验的从业人员，不难从这些跳跃着带有个人和地域色彩的思想和逻辑的复杂的代码中，看到软件开发者们深远的具有自身特质的清晰的影像。
然而这种三权鼎立形式的软件开发方式，往往极大的贬低了软件开发人员，毫无理由的提升了其他二者的地位。。。

三大部门各自的boss在公司中的地位，以及他们是否强势，决定了底下人员的命运。我经历过产品部指着研发部骂娘，也经历过开发部拒不接受产品部功能和需求的。boss底气足不足，决定了大家的命运。

经历了好几个以这种开发模式进行软件开发的公司，结果几乎全一样，都是产品部门比较强势。因为领导基本都是非技术出身，所以显然倾向于产品。
通常都是对技术很不屑。。。

虽然一切都是浮云，但你没踩在脚下的浮云还是常常让你牢骚满腹的，霍霍

印度软件的流程一般是怎样的，有人可以谈一谈不，中国的这种模式，感觉有很多问题，除非，技术主导可能会少一些。

虽然有些偏激，不过确实有时会存在这样的情况。但是lz也基本上是从技术人员角度出发考虑问题的。

虽然产品经理的能力，经验良莠不齐，但是一个好的产品经理对产品的导向确实决定了一个产品的成功与否。

老板一般不是技术出身就对了，有商业眼光的老板才能成功，如果你的老板只是一个技术出身，眼里只有技术的人，那我觉得你还是赶紧闪吧。

不是吧，根据统计，IT公司60%的老板是技术出身，别把技术人员想成只会和电脑打交道的书呆子。我的看法，做技术的人是喜欢挑战的一群，对生活充满激情和热爱的人，这样的人往往更具有商业眼光，所以创业成功指数更高。

无语

支持楼主，说出了我心里面想说却又说不出来的一些想法，说实话，在这种模式下，开发人员的开发活动会非常的别扭，沟通容易阻塞，创意容易被抹灭。

不是所有的技术人员都懂产品，但是技术与产品也不是此消彼长的关系，有时甚至有点相符相乘，很难想象一个基本功不好，不知道颜料的画家，能够画出很好的作品，应该是少的吧？

还有一句话，有人觉得苹果很牛逼，很多好的想法，其实也抄过别人，再加上国内的腾讯越发的给力，让我越来越相信，想出好的想法很容，但是把好的想法执行的完美很困难。