軟體開發人員努力的方向分類：職場

觀察一般軟體開發人員已經有十年左右了，給我們一般人的印象是，有理想、自戀、不妥協，而偏偏在這個時代要完成一個好用的軟體系統，這三個優點恰巧成為團隊合作的致命傷，所以通常一個技術性高的研發人員常常被貼上為不合群的標籤，而技術性不怎麼強的人也因為團隊EQ特別高而常常會有錯誤的評斷。

如果我們簡單的把技術力與完成力這兩個面向的拆開來看，技術力指的是程式語言(C++,JAVA,VB...)的使用熟悉程度、系統架構分析的能力、開發平台的使用(OS,SQL Server...)、看見未來的發展等等，選擇對的技術方法可以在開發成本上節省不少時間及金錢，但是這些技術成本往往很難去評估的。

完成力這一個面向指的是品質的承諾、使用者的溝通介面、可被實踐應用的系統，這一個面向如果是大眾所使用的系統往往是利用大量的廣告行銷來塑造一個成功的產品，如果是一個專案的話，就是有一個專案經理來串連軟體開發的過程，跟廣告公司的AE，有異取同工之妙。

我觀察的程式開發人員往往在技術力不斷地提昇自己，但是並不會特別在完成力上面特別的努力，也是因為在完成力上面的努力成功無法很簡單的用數字來評量，也特別的看不出成果，他們或許已經覺得非常貼近客戶了，但是客戶無法那麼理性的使用開發人員所假想的系統，那如何要程式開發人員努力去學習完成性呢？

我認為有幾個方法，多多與人交談不要怕無聊，唯有相信別人的看法才有辦法改變自己的想法﹔培養神秘的第六感，不要一直用邏輯推理來想事情，世界上的事情有超過一半以上現在是無法解釋的﹔試著在合理的範圍妥協自己的程式架構，尤其是介面程式部分，雖然可能未來會證明你可能是對的，但是現在你的程式是錯的。

程式開發人員的技術力提昇的風險非常大，好不容易把Windows NT平台搞熟了，VB也用的很熟練，結果有可能一夕之間變成　Linux+PHP或者是C++ 的開發環境，所以，一定要保持隨時學習的心態，而解不光在技術的提昇，也要重視完成力的提昇。

研發團隊的創意管理分類：管理

最近的報章雜誌一直在討論的話題不外乎是不連續式創新（數位雜誌 12）、創新企業管理、廣告創意、即興創意、這麼多『創新』的議題被討論在各行各業之後，本專欄擬發行30期後改為比較實際的軟體開發的個案討論，希望大家多多支持，也給我意見，持續了半年的思考，我會繼續在軟體開發路上努力，隨時『創新』的精神仍會留著，只是希望不要被大眾媒體一炒作後，讓大家失去了理想。

我們重新思考了一下創意的定義，研發及表達可能有用的新鮮點子的過程，一般總認為是在一個人的身上去完成的，而這些點子必須是可執行的，可運用的並且在團隊中達成共識，這些過程，永遠少不了團隊的溝通合作，所以一個大企業，甚至一個小的工作室，基本的創意過程都是一樣的。一個團隊重要的創新過程應該注意下列的事項，去除共同合作的障礙、利用異質人員的排擠心理、整合性思考評估。
　
去除共同合作的障礙，一個團隊一定有不同角色的人，甚至同樣是程式設計師，他們的想法也會南轅北轍，如何破除成見攜手合作，必須去創造一個共同的研究主題，例如類神經資料庫，人工智慧等等，而在系統的開發方面，就不能以研發單位來自居，必須與客戶服務或是業務行銷單位共同思考，簡單地來講，要去除這些障礙就是單位之間的溝通與人員之間不能有高低之別，這樣才能共同努力。

利用異質人員的排擠心理，一個產品要賣的好是一個企業所有人努力的成果，所以一個有創意的專案，必須給所有人思考的機會，如果一項產品全由軟體工程師的角度出發，設計出來的系統常常操作十分的複雜，雖然架構上非常合乎系統設計的邏輯，但是一定不好操作，而一個完全由操作系統的作業員想出來的系統，雖然操作可能十分的便利，但是往往無法程式化或是無法做好事後的統計功能，如果要完成一個良好的系統或產品，事先一定要融合所有人放下所有的專業角度，一起來腦力激盪，藉由不同角色人員的排擠心理，摩擦出新的火花，雖然這個過程的風險極大，有可能每一個專業角色的人員，會覺得不受尊重，但是這是可以讓團隊有『創新』運作的辦法之一。

整合性思考評估選擇，一個好的系統要去執行，除了要有上述的異質人員的結合之外，要整合這些意見，說服每一個人為何要這樣執行是非常重要的，因為討論的過程中有很多人會僵持自己的想法，而不妥協別人的看法，如果是好的創意，應該要有一些選擇方案，並且在事後評估，一個好的創意發想是在執行之後，還能不斷地檢討，創新的過程並不是樹枝狀的結構一步一步執行，應該像是一團的雜醬麵，糊在一起的樣子。

一兩個人做事容易，創意的發想也很簡單，但是一個團隊要經營的好，這些創新的過程非常重要，不然我們研發出來的產品，很可能只會依照競爭者的腳步在後頭追了。

品質對於軟體系統的重要性分類：系統

看看市面上的書有大部分是教程式設計師如何應用工具，如何用 Front Page,Visual C++, Visual Basic, C++ Builder... 或者是如何學習電腦程式語言，但是可能只有不到10本的電腦書籍教大家除錯(Debug)，教大家建立系統的品質，而一套系統的被頻價不好，往往就是一點點的小問題，而被大家獲的好評，往往也只是一點點貼心的設計。

上一期談過程式設計師的風險，如果加上大家對於程式設計的要求『品質』的話，這一份工作實在是非常的艱苦，所以有很多公司把除錯或品質的要求獨立出其他的單位（測試部門），但是往往成效不彰，或者是目標、成就感無法建立更增加程式設計師的負擔，其實品質建立的觀念是每一個人都要建立的，並不是只有程式設計師要負擔的工作。

舉例來說，如果程式設計師只是依照系統分析的文件寫出來一些功能畫面，而沒有加入對於系統來攏去脈的了解，往往少了一份『精神』，這個就是品質的一種，我們通常稱為一項專業領域的知識(Domain Knowledge)，例如汽車維修業，一套良好的維修作業管理系統，當然必須融入汽車維修業的專業知識，不然最簡單的來講，這個系統往往會犯了操作不通暢，查詢很慢或是不符合需求的毛病，而這個專業知識的建立就是一家公司生存與競爭力的所在。

其實一套系統的雛形開發真的非常容易，只要有些許的想法，就可以舉辦一場良好的展示，但是等到系統進入整合的階段，對於系統品質的要求就進入這個階段與狀態，往往程式設計師會覺得當初討論或系統分析就是這樣寫，他們設計的沒有問題，但是往往交付給客戶試用時，就是不對，照成整個架構必需重新翻修或者重寫。因此，如果我們能夠在程式撰寫的同時就用心的注重除錯，用心的詢問客戶的操作習慣，甚至要加入對於專業知識的判斷，等到系統完成時，就是一套良好的系統。

預估開發一套系統在品質方面的成本應該跟程式設計的成本是一樣的，如果要開發一套系統的要注重的三個面向是創新設計、維護能力、品質管制，每一個面向的專業知識都『一樣』重要，而品質方面就是，架構、除錯、測試這三個重點要抓的住。

延伸閱讀：【創新】創新力與執行力必須以專業為基礎