只要有了優秀的程式設計工具、高階的程式語言、豐富的構件庫和輔助程式建立系統，就能解決所有問題？並及時地在預算範圍內交付良好的軟體系統嗎？ 乙個軟體開發團隊如果想要在專案中獲得最大限度的成功，離不開人的因素。
軟體開發團隊中的意見
乙個軟體開發團隊如果想要在專案中獲得最大限度的成功，取決於團隊中的成員能否形成技術性一致意見。但為什麼這點如此重要呢？是不是團隊成員只 要在諸如目錄**的布局上達成一致，或者建立乙個很好的錯誤匯報機制就行了呢？技術性一致意見指的並不是與同事打成一片就可以了（當然，這也不是說在同事 之間建立良好的關係有什麼錯誤）。技術性一致意見是指充分吸取團隊中每個成員的技巧和經驗，其目的是為了開發出更好的軟體。
職業軟體人員也許能夠迅速理解一款好的軟體，至少當他們看見乙個好的軟體時會宣稱自己能夠理解它，但是，在軟體開發者中，很少有人能理解技術性 一致意見。可能許多軟體開發者會說，我們以前使用過一致意見的方法來解決問題，但是效果非常差，他們還會舉出許多例子，比如，一些很棒的構想就是在不斷的 討論中葬送了，最後為了所謂的整體性只得做出妥協；本來 6 個月可以完成的專案最後拖了 1 年：團隊的能力也沒有完全發揮出來。但如果仔細地聽聽他們的意見，你就會意識到他們所說的解決問題的方式根本就不是技術性一致意見，而是折衷。那麼，二者 之間有什麼差異呢？
折衷是沒有前途的
折衷意味著所做出的選擇是一種似是而非的東西。既不是甲，也不是乙，而是乙個介於二者之間的東西。我們可以通過乙個典型的例子來說明。如你的團 隊正在開發乙個圖形使用者介面的專案，一部分人強烈建議直接將控制按鈕放在螢幕底部，而另一部分人建議在螢幕的左側放置乙個控制窗體。在這兩種意見中，一種 是水平放置，一種是垂直放置，形成了兩個極端。那麼，乙個最具有代表性的折衷方案就是，將控制按鈕沿著對角線放置在螢幕的**。
就像上面的例子所描述的，由折衷所產生的解決方案常常要比任何乙個原有的方案都要差勁。但是技術性一致意見就恰恰相反，它所產生的解決方案要比 任何乙個原有的方案都要好。如果不使用技術性一致意見，往往會由於顧忌到每種備選方案的優點，而採用優點均衡的方式，但實際上每種備選方案的優點也就喪失 了。真正的一致意見不是基於那種讓每個個體都做出讓步的折衷，而是基於綜合的，新的綜合體要比原有的任何乙個個體都要好。最後的結局就是，開發出了更好的 軟體。
乙個綜合體是一種具有新穎性的新個體，是整合了原有的每個建議和方案的本質特徵的個體。在上面所說的介面設計例子中，可以明顯地看出，乙個具有 創造性的綜合方案是給控制按鈕窗體加上選項，由使用者來決定是採用水平放置還是採用垂直放置。一致意見的方法不僅僅是將各種選擇方案的優點集中起來，而且綜 合方案還體現了新的特性和功能。通過整合水平放置和垂直放置這兩種方案，我們可以實現終端使用者定製。這樣，最後的軟體產品就整合了各種方案的好的方面，而 不是壞的方面。
形成真正的一致意見並不是一件容易的事情，那些政客和工人談判代表們對此深有感觸。達成乙個技術性的一致意見與達成乙個政策性的一致意見是有所不同的，但是有些本質特徵是基本相似的：二者都需要制定一些約束條件以達成共識，參與者在討論過程中都需要保持一種信念。
真正的信徒
團隊成員必須堅信，從每個人的意見中提取出最好的方面並將其綜合起來，就此形成乙個技術性的綜合體是完全可能的。只有堅信這點，成員們才有可能 堅定不移地尋找最好的解決方案，而不是輕易地折衷或者固執己見。每個成員發表自己對問題的看法，講述方案的優缺點，通過堅持不懈地努力，成員們可以提高形 成具有創造性方案的可能性，而這種創造性的方案會比原有的任何方案都更好。
當每個成員都相信開發乙個好的軟體要比在軟體中使用自己所喜愛的方案更重要時，一致意見式的設計會發揮更大的作用。如果我們注重最終軟體產品的質量，在團隊討論過程中會更容易發現每種意見的優點。
如果團隊中的成員不是獨自炫耀個人能力，而是認同聯合協作的工作方式，那麼對於軟體開發會更有幫助。有些公司願意獎勵傑出的個人，而不是獎勵團 隊；或者晉公升那些慣於單打獨鬥，特別是那些不會也不可能與他人共事，常常乙個人解決問題的程式設計師，而不是表彰整個團隊。這樣的公司會做出如下論斷：最好的 軟體是他們的天才程式設計師開發出來的。這些公司意識不到，除了這種方法以外，其實還有其他的方法可以達到更好的效果。
在建立技術性一致意見時，乙個必須遵循的原則就是：絕不能以貨易貨!對於政客們來說，採用以貨易貨的**方式是一種獲得成功的經典策略，但對於 技術性一致意見而言，這是有害無益的。舉例來說，在上面的介面設計例子中我們可以採用以貨易貨的方式，如果讓我同意你的愚蠢方案，將控制按鈕窗體放在螢幕 底部，那麼你就要同意我聰明的設計思想，加上沒有標籤的圖示。最終的結果就是，介面不是最好，而只是乙個具有兩個普通特性的介面。這種以貨易貨的策略其實 是另一種形式的折衷，而折衷之所以糟糕，是因為在不同方面所做的決策會相互影響。好的技術性一致意見必須將問題分別對待，對於不同的問題分別採用最好的解 決方案，而絕不能因為某個方面固執己見，致使另乙個方面讓步。
尊重事實
一般來說，大家都認為技術決策所依據的都是技術性因素，諸如事實、可測量的數值、應用中需要考慮的事項等。但實際情況是，諸如感覺、意見、直 覺、偏見等，都會對決策的制定或者問題的解決產生影響，這些都是人在做事情時所不可避免的因素。儘管有些人試圖否認、控制、壓制這些非理性的因素，但這些 都是絕不可能完全避免的。
對於那些希望採用技術性一致意見方式來解決問題的團隊，有乙個基本的技巧是必須掌握的：將事實和意見分開。對於乙個協同工作的團隊來說，如果期 望創造性地解決問題並獲得最好的結論，他們必須知道他們已經掌握了哪些資訊，並能夠隨時獲得最好的資訊。發表意見並不是錯誤，團隊成員應該能夠自由地表達 他們的意見。意見是有用的，特別是那些經過深思熟慮的意見，但是成員在表達意見時必須能夠保證他們的意見不要和事實、資料、分析混在一起。就算是事實，也 是具有侷限性的。例如，在美學或者行銷領域中，事實所起的作用可能就會不太顯著。遺憾的是，有些團隊成員一旦形成自己的意見，他們往往就對事情的真實程度 視而不見了。
有時候，把某些東西稱為事實並不意味著它就是真正的事實，因此，團隊必須學會如何單刀直入地解決問題，而且大家還需達成一致——不玩文字遊戲。 我的第一任妻子在我們共同生活的早期就學會了這一點，只要我說出以「事實很清楚地表明……」開頭的一段話，她就會對我所講的東西表示懷疑，因為這意味著隨 後所講的話極有可能只是我個人的看法，而不是基於任何資料或證據所得到的結論。除了這個尷尬的話題外，我有時還會掉入另乙個語言陷阱中，那就是眾所周知的 「95％的科學家都認為……」。有些人可能意識到了，在軟體業中，有一句同樣著名的話：「你知道的，絕大多數的職業軟體工程師，至少 95％以上，都會採用這個方法。」當然，如果你還想繼續使用這個小技巧，你必須改變百分數，例如：「將近 78％的 wordperfect 使用者都知道最好的方法是……」，「如果我們做個調查，2／3以上的c程式設計師都會同意……」。有時候，看上去好像真的有那麼多的科學家、軟體工程師、終端用 戶站在你的背後支援你的意見。
但是，這僅僅是我的看法。
軟體人性化的體現
朱金燦 我想軟體的人性化體現在 呢？我想到了一下幾條，不當之處，還請大家指正。一 穩定性。有人可能認為穩定性無關人性化。恰恰相反，我認為穩定性是最大的人性化。試想，乙個不穩定的軟體，談何人性化呢？軟體的穩定，並不意味軟體不出錯，而是必須確保有足夠的錯誤提示，而不是直接導致軟體崩潰。二 符合業務邏輯 ...
人性化公司
在外企實習了一段時間，在民企公司也工作了一段時間。覺得人性化公司還是非常重要的，公司要想發展最重要的就是員工，也就是人力資源，如何能夠創造乙個良好的員工工作環境，給員工乙個主人公的感覺，公司不好自己都著急呢？新人的優勢 在工作環境方面重要一點 廣開言路。相信這四個字很熟悉了，覺得理所當然了。其實不然...
人性化的HSL模型
hsl色彩模型又是什麼？hsl同樣使用了3個分量來描述色彩，與rgb使用的三色光不同，hsl色彩的表述方式是 h hue 色相，s saturation 飽和度，以及l lightness 亮度。聽起來一樣複雜？稍後你就會發現，與 的rgb模型相比，hsl是多麼的友好。hsl的h hue 分量，代表...