親和力部門的八項重要任務
這一篇是我給自由軟體鑄造場電子報的稿件,刊登於第九十二期 (2007/11/11)。
親和力部門的八項重要任務
在前一期當中,我們提到了親和力部門在執行長的授權下,有八項重要的任務要執行;在本期當中,就讓我們來一一細看,這些任務應該要怎麼進行。
在公司內部提高對親和力議題的體認,並提供員工們設計具親和力的產品或服務所需的相關訓練。
親和力部門的理想成員,是要由整個公司各個部門的人員所兼任的,這些兼任親和力部門成員的人,就是提高公司對親和力體認的重要種子,也因此他們在親和力部門的「兼職」,必須要有執行長的認可,而不會影響到他們原本工作崗位的考績,或者增加他們的業務負擔;這些成員平日的重要工作之一,就是與他們各自主要所屬的部門同仁,溝通與親和力有關的考量,並且在親和力部門定期(例如每週)舉行的會議上,互相交流各自部門的狀況、遭遇的問題、解決的方法等。
在例行會議中,除了促進各部門間對於親和力認知的互相熟悉外,還有一個重要的目的,是要弄清楚各部門對於親和力議題的體認程度為何。接著,再根據這些資料,規劃一系列的教育訓練。教育訓練應包含概念與實做細節,概念的課程可以同時針對所有的公司員工⸺包括各部門各級主管施行,因此宜短不宜長;實做細節的訓練則需要針對不同的部門予以客製化,以解決各部門實際會遭遇的問題為優先。在這個任務中,親和力部門主要扮演的身份是訓練課程的規劃者,而不需要是實際的授課者;儘管授課者可以外包,但是同仁對相關訓練的熱中程度、課後的反應及回饋、相關教材的統整與再利用、課程的安排與講者的溝通等,卻都是親和力部門得自己來的。
除了實體的課程外,在內部網路經營相關的知識庫,或者是舉辦定期的刊物等,其實也都是不錯的選擇。親和力是很活的東西,而且在日常使用中總是會不斷遇到相關的困難,所以親和力部門務必得鼓勵整間公司的同仁樂於分享、表達自己遭遇的情況,讓這個管道暢通了,纔有辦法落實親和力。
為公司所提供的產品或服務,發展親和力方針,並在技術上及經濟上可行的前提下,交由產品開發部門來負責實現這些方針。
第一個任務執行約三至六個月後,親和力部門就差不多能夠掌握公司整體對於親和力議題的敏感程度了。同時,此刻親和力部門也應該能掌握公司的目標、企圖、內部文化等屬性,所以應該要開始擬定公司內部的親和力方針。這個方針應該要以淺白、概括的方式撰寫,說明為什麼要這麼做、通用的程序、相關的其他規定或文件等,擬定完成後並由執行長頒佈施行;當第一份親和力方針訂定後,必然還會遭遇一些意料之外的狀況或反應,或者出現此方針無法處理的情境,因此接下來還應該要聽取同仁們的反應,將此方針予以修改、調整。
當親和力方針公布之後,包括教育訓練以及其他的相關任務,纔能夠有個依據;因此親和力方針應盡早制訂、發展。這個方針的制訂需慎重(所以我們會需要來自各個不同部門的同仁,一起來參與親和力部門),但是也不用吝於訂正⸺祇是每一次的訂正也都必須慎重,妥善製作相關文件,說明修改之處、前因後果等,務必顧及實際執行、使用這份方針的人(也就是所有的同仁)的感受,盡可能地協助大家度過這樣的過渡期。
在所有的部門當中,與此最為相關的部門,應該屬研發部門了。因為對於整個公司的親和力方針來說,最重要的就是讓製作產品的單位⸺研發部門⸺能夠把這些方針實現在產品上。這件事不能靠親和力部門來完成,因為掌握產品的並不是親和力部門,而是研發部門。也因此,在執行這項任務時,親和力部門與研發部門間的合作,就更為重要了。
在發展上述方針時,或者在產品或服務的設計及測試部門中,帶進實際有生理功能限制的人參與。
既然實際把親和力方針實現在產品上的是研發部門,那麼親和力部門究竟在這個階段能做些甚麼呢?
有一件值得做的事,就是在產品研發初期,就將有各種不同需求的使用者帶來實際參與⸺使用者經驗研究、焦點團體、深入訪談等都可以,這些資訊能夠協助研發部門預先避開一些錯誤。在選擇參與測試的人時,多找一些明顯有不同需求的人⸺像是有各種生理功能限制的人⸺尤其在初期更能獲得寶貴的資訊。
事實上,不僅是研發初期,稍後當產品處於推出前的測試階段時,也應該找類似的人再來做一次測試。這些互動的流程應該要根據前述的親和力方針加以標準化,而親和力部門應該謹記在心,要做這些事的目的是要協助公司、協助開發及測試團隊,而不是找麻煩或扯後腿;換句話說,溝通再溝通,以及提供真正有效的資源、解決方案,也是親和力部門必須要處理的。
在未來的產品開發及升級過程中,投注充分的產品開發及工程資源,以迅速地辨識並處理各種已知的親和力問題。
為了要協助開發及測試團隊,親和力部門也必須投注部分的資源在這個環節。確實,研發部門及測試部門纔是主角,但是這些部門也會有在親和力部門擔任職務的同仁,所以這就是個好的施力點。
這項任務的重點是藉由流程跟文件,來確保每一個遭遇到的問題都能清楚地留下痕跡⸺他們怎麼來、怎麼解決,都要有明確的描述與相關流程。而其他部門(例如客服部門)也能參與這個流程,將來自使用者回應的親和力議題,納入追蹤管理,將這些已知的議題加以處理。如果可以的話,不要把他們拖到下一個主要釋出版本,否則對使用者來說並不是個太親善的事。
藉由提供訓練、方針及技術解決方案等方法,讓開發社群能更輕易地建立具有親和力的產品或服務。
在上述的資源投入下,將能累積出豐富而有價值的親和力方針,以及與之相關聯的技術解決方案。在不透露公司機密的前提下,是可以試著把這些文件或細節予以公開的;尤其當公司產品或技術,有明確的相關開發者社群(例如開放源碼的軟體)時,這樣的公開將可以協助整個社群一起成長,最後公司仍然能從社群中受惠。
因為常見的問題也許人人都會遇到,但不見得人人都會去處理、或者能用最佳的方式來處理,但是一旦相關的議題被明確指出,並且提供可行的解法後,往往陸續就會有更多人提供更好的做法,或者整個社群有可能把某樣工具或組件予以改善,讓這些問題從一開始就能避免。這些對於公司日後要維護、更新產品時,都將能省下不少力氣。
針對產品及公開提供的服務,撰寫文件說明各項具親和力的設計。
不單是這些技術解決方案可以開放給社群,還有一種文件也相當重要,那就是針對各項產品及公開服務,說明各種親和力考量與設計。這樣的文件主要是給使用者看的,除了能夠協助使用者更融洽地使用各種產品外,也能夠幫助使用者更明確地看到他們自己的需求。日後如果需要改善產品或服務流程時,這樣的文件也能夠協助使用者把問題明確地指出。如果公司想要參與或經營使用者社群,這種文件也會是一個很好的開始點⸺還有甚麼會比明確表達「公司很重視使用者」還要更好的呢?
而且像這樣的文件,對於公司來說也是宣傳的材料。畢竟公司的確在親和力上投注了不少資源,要是沒有人注意到,就太可惜了。揭露這樣的文件,也能夠使相關同業、其他使用者感受到此一議題的重要性,而引起良性競爭,這對整個業界環境來說,將會是好事。
針對與產品或服務有關的親和力科技,支持贊助內部與外部(例如大學等學術單位)的研究發展,藉此提升最新的科技進展。
前面講了這麼多,包括參與開發者社群或使用者社群,好像都只有提到公司內部的事。但是親和力不可能祇靠公司內部就能做得很完善,因為還有太多未知的議題,以及尚無定論的爭議,而這些並不適合閉門造車地、一相情願地用試誤法來找出答案。以國內的情況來說,多數的公司養不起私有的、屬於自己的研究機構,來研究相關的理論及科技,但是我國的高等教育機構多如過江之鯽,其實也是個可行的合作方向。
親和力部門可以在學術界找到些固定合作的伙伴,支持贊助其研究計畫,讓親和力相關的研究進行下去。此舉不但可以協助公司獲知無法自行實施取得的研究資料,另外也能夠讓未來的員工⸺那些還沒出社會的在學學生⸺也能及早體認到親和力議題的重要性。這對於兩方來說都是互蒙其利的。
支持邁向親和力的標準實做,例如像全球資訊網協會針對瀏覽器、網頁內容和編輯撰寫工具,所發展的一系列指導原則。
最後一個重要的任務,在優先順序上並不亞於前七項任務。因為全球資訊網協會多年來已經努力地在發展一系列親和力指導原則,而面對這些指導原則最好的方式並不是去跟他打對台,而是與之順應。如果公司發展了一套親和力解決方案,但是實做細節上卻與全球資訊網協會制訂的標準實做相違背,那麼日後一定會自食惡果;因為現今的網頁編輯軟體、瀏覽器、使用者代理等,莫不以全球資訊網協會的推薦標準為努力方向,公司的產品及服務也應該要這樣。
另一方面,全球資訊網協會的推薦標準,可以說是在泛用性及細節上都有著最嚴格的要求,所以很適合作為公司制訂自己的親和力政策或者是發展技術實務細節時,相當好的參考依據。當然這些推薦標準的目的之一是要維持泛用性,所以有哪些應該要採納、哪些可以不處理,這也會是親和力部門的工作之一。
在做這件事時還有個風險,就是有一些細節可能在評估之時沒有需求,但是隨著公司產品、服務的演變,日後還是有可能會再度變得重要。另外即使是全球資訊網協會,也在不斷地改善其推薦標準;WCAG 1.0 到 2.0 版間,包括整個指導原則的哲學、架構、內容都變得很不一樣,這個時候公司應該要如何順應?這也是親和力部門需要處理的任務。
花了這麼多篇幅解釋親和力部門,但是要在這個專欄中提供一份像食譜一樣的步驟,讓各間公司成立這樣的部門,是不可能的。因為所有的親和力考量都是要因人制宜的⸺每間公司內部的文化、組織架構不同,面臨的使用者族群不同,就要採取不同的做法。「沒有一套至高無上、一定不會錯的辦法」正是親和力的重要精神之一,唯有實際地去為每個關係人設想,才能訂出好的、正確的辦法與方針。
由於這個主題將越來越抽象,所以在這個專欄中,接下來我們就要回歸到現實面,開始深入研究,每個不同的領域中,有哪些跟親和力有關的技術實做細節。