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

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

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

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

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

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

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

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

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

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

 

转载自：

http://sharong.iteye.com/blog/1070764