[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