{%hackmd DfWYF9cYREebVNN1eEOz-w %} # 考核 **職能評估表填寫說明**: 同仁在自述行為事例時，請以行為事例(STAR)方法描述。 1. 情境 ( Situation )：在什麼情況下 2. 事件 ( Task )：發生了何事 3. 行動 ( Action )：採取了什麼行動 4. 結果 ( Result )：結果為何 5. T & A: "=>" 之前的是T，T 是一開始假設與想像的問題，經過反覆討論與思考後產出 A ## 溝通協調能力 25 % - 能虛心接受及尊重別人的觀點和看法。 - 能利用口語或文字，清晰有條理地表達個人的想法或意見。 - 對非語言的行為具有敏感度，能適時調整自己的應對方式。 - 發揮專業素養與同理心，在各單位對某些看法或實務上有異議時，做有效的溝通與協調，並解決問題。 - 懂得善用良好的溝通技巧來協調與他人間的衝突。 ### 一、色彩管理 方向擬定與開發 S: 初到時被分配了去了解 **電商平台** 與 **供應鏈平台** 在提供什麼服務，並思考如何導入色彩管理 T & A: - 色彩管理需要在哪個環節中引入? => 深入了解另外兩個平台之間的互動與資料交換的行為，從而來思考在哪個流程中引入色管比較好。 - 提供哪些服務? => 思考提供哪些服務會命中品牌、設計師、供應商的痛點，所以須對這些腳色更加了解。 - 供應商要用 CR30 還是自身的設備? => 與熟悉供應商生態的人討論，並且同步工程團隊後再討論並評估難易度。 - 色彩管理知識上的不足，要怎麼解決? => 透過郭老師、同事與 Google 來補足當前所需的知識點。 - 光譜儀廠商有提供 SDK，需先試試能否用 APP 串接? => 研究廠商 SDK 原始碼，並嘗試持續遇到問題並克服。 R: - 色彩管理是要走向 Web 還是 APP，後來決定是 APP 因從團隊組成與產品還在 MVP 初期來看，相對上改動機率高所以從改動成本來看 APP 是相對較低的。 - 初步討論各平台間的互動與行為，流程是設計師或品牌透過 APP 建立專色上雲後，在建立訂單時選擇專色。訂單成立後會轉工單並包含專色資訊，供應商即可依工單生產並做顏色比對。 - 色彩管理向同仁請教與討論並達成共識後，所提供的服務如下 - 用戶透過 APP 來建立專色、專色管理、訂單比對色差 - 用戶在平台上建立訂單時可新增專色，新增後顏色品質會受到保障、不需透過樣品交換來節省時間。 - 供應商透過工單的顏色資訊比對色差，並且留下比對記錄供未來的評分機制使用。 - 色彩管理知識上的不足，要怎麼解決? 整理上課時沒有接觸過的知識，並且於課後額外花時間吸收。實務上遇到的問題都嘗試提問，多數皆有理出答案。上課後才知道上傳設計稿有專色的議題、還有當品牌或設計師沒有樣品時怎麼辦? 這些都問題等於是提前被發現，所以可納入追蹤項目來掌握。 - 廠商提供的原始碼跟跟架上 APP 不同，以此與廠商提出討論，確認是提供這版無誤後。開始研究程式碼並克服相關問題，如第一次 compile 出錯，程式上發現邏輯不正確或 BUG 等。最後成功串接並用 Google 官方 Guideline 來 layout 畫面。 ### 二、分享觀點與想法，使大家更了解彼此 - 有空時就跟大家聊天，讓大家更了解彼此。 - 樂於分享任何遇到的問題、個人的疑惑、工作上的疑難雜症。因為與人交流會使自己對事情的思維轉換，也讓大家共同思考且激發任何主意。 - 有些人比較不習慣在多人的會議上直接表達想法，或者當下還在整理思緒 ...等。雖然透過聊天討論的效率不比直接在會議上討論，但總比不討論好，時常這樣做能讓大家習慣這件事，或許哪天大家就習慣於會議上提出想法討論了。 ## 主動性 20 % - 可以預期到會發生的問題，在問題尚未發生之前，預先採取適當行動。 - 針對工作上的問題，能夠不斷提出新的解決方法。 - 即使沒受到要求，也會付出額外的心力達成工作。 - 能主動將發現的問題與跨部門人員做溝通並尋求共識。 - 爭取自我改善與提昇的機會。 ### 一、色彩管理 color system 引入單元測試 S: Color System 的色彩核心邏輯是由郭老師撰寫，因需求調整程式是很有可能的，避免調整後影響現行的系統就很重要了。另一件重要的是確認系統效能。 T & A: - 老師的系統沒有經過壓力測試，如何確保 API 上線後的品質? => 從現形得邏輯中挑選最耗費效能的，來當作測試指標。另外官網規劃用 API 形式跟 Color System 溝通，所以用 API 做壓測會較接近實際的結果。 - 在封裝老師的方法時可能會誤改既有的邏輯，加上未來會因需求調整程式，如何保證現在的邏輯是對的? => 跟老師討論所有的方法在哪些輸入條件預計會得到什麼結果，撰寫單元測試驗證這些結果。 R: - 被驗證的方法有依賴第三方套件，且在 Linux 環境下需透過模擬器(Wine)執行。所以需比較 Windows .vs. Linux + Wine 差異，首先將老師的方法改寫成能透過 CMD 執行，接著撰寫兩種腳本執行 Windwos 與 Linux 的性能測試包含平行/非平行。出乎預料的是 Linux 的速度竟然是 Windwos 3.8倍，且能耗還比較小。 - PHP 建置 API 的主流框架是 Laravel，了解基本架構與原理後就開始建立工作方法。首先將老師的程式以類別簡單封裝，建立 API 入口。測試環境為 Winows + Nginx +PHP CGI，壓測情境為一秒內有 30 個人同時發出請求，兩個方法的結果為 1.1 s/user 與 1.4 s/user，未來加上實際網路路由延遲加上 1 秒來看，還算可以接受的結果。 - 在網路資源上取得光譜轉換成各種顏色資訊的結果，另外一個是 fogra51 官方公布的標準色光譜資訊。依這些資訊建立了 22 個單元測試，並將工作方法與老師分享。 - 補充: 以上的工作方法或環境，多數是沒有接觸過的。 ### 二、IOS APP 開發方向與基礎架構 S: 有 IOS 開發的需求，但團隊中沒有人會寫 IOS。所以得想辦法來克服，且選擇對團隊最有利的方案。 T & A: - IOS 是較為封閉式的開發環境，哪種方式有利於團隊在較短的時間帶來最大的效益? => 應是團隊內自行掌握一定的開發能力，且同個空間下剛好有人會寫 IOS，所以想讓他帶團隊入門(Jason 為主)。在 Brook 建立專案的這段時間，團隊成員可先自學基礎。 - 如何在速度與品質之間做權衡? => 經考慮基本的軟體品質還是要有，所以期望 Brook 能建立 IOS APP 的基礎架構。 - 現有的團隊配置要由誰來擔任開發 IOS 任務? => 團隊成員技能樹多數都偏後端，讓團隊成員擁有前端知識與開發能力也很重要(還是得看個人規劃)，但掌握前端基礎能力還是利大於弊。 R: - 是否要走原生來開發? 如果沒有跟硬體的 SDK 串接，不一定非走原生。未來時間若充裕也等 Flutter 更成熟時，考慮將廠商的 SDK 改寫成 Dart。就可一套開發系統，產生雙平台下運行的 APP。 - 與 Jason 討論後也表達對 IOS 開發有興趣，所以請他擔起任務。初期與 Brook 請教與學習 IOS 基礎，但因需支援信集界而告終。 - 請 Brook 串接廠商 IOS 的 SDK、IOS APP 基礎架構與教 Jason 建置 UI Layout，但 Brook 沒有建置架構的經驗，這地方是我需要檢討的，所以後來由我建立基礎架構。值得一提的是光譜儀廠商 IOS SDK 封裝的比 Android 好，簡單推測重心是比較偏 IOS。 - 先探索現在 IOS 主流架構的討論聲量，並且我們的產品偏向商務型，簡單來說是用資料與使用者互動為核心。所以架構由外而內是 "User Interactive" 與 "商業邏輯層" 互動，"商業邏輯層" 與 "API資料邏輯層" 互動。以此做為 APP 架構的藍圖，透過程式碼去實現藍圖。 ## 成就導向20 % - 會自我設定明確且具挑戰性目標 - 承受挫折，鍥而不捨，嘗試不同方法解決問題，以達成目標為第一要務。 - 喜歡接受具挑戰性的任務。 - 積極尋求各種方法改善工作績效與提高工作效率。 - 在執行任務過程中，遇到阻礙或困難時，仍然能夠堅持全力以赴，達成既定的目標。 ### 一、color system 與老師取得共識與解決方案 S: 郭老師一開始目的是為了讓團隊具有色彩管理的知識，另一部分是他願意讓我們的系統與他的色彩系統作結合。 T & A: - 如何介接老師的 PHP Web 系統? 用 API 的方式在內網串接，省下改寫的時間。所以需嘗試是否有能力在 Ngnix 駕馭 PHP API。 - 如何讓老師願意分享他的色彩系統? 主要是老師樂於分享，但還是要讓他感受到我們的誠意，同時安全感也是需要的。該如何達成這個目標還蠻抽象的。 R: - 首要目標是先讓正式 Linux 環境透過 Nginx 上與 PHP Web API 做交互，確認是否能駕馭即可。所以先規畫學習目標清單範圍包含 Linux、Nginx、PHP、Laravel、WSL，先在虛擬環境下模擬執行與測試，最後到正美的實際環境部屬來驗證是可行的。 - 在色彩系統上所有的工作計劃都分享給老師，不過其中比較不容易的是課堂上吸收色彩管理知識，每堂課後須不斷的消化與複習，為了往後跟老師能順利溝通且也較有話題。 - 當時是將色彩管理系統的優先度放在最高，每周也都會同步進度，讓老師感受到我們是很重視的。在提到未來的規劃時 "強調" 系統不管怎麼改變，老師的知識才是系統的核心(心臟)。後來老師也同意了這樣的合作模式，老師就像恭麟所說是樂於無私地分享自己的知識，且具有改革台灣在色彩管理的信念。 ### 二、色彩管理 APP 擬定任務清單 S: 當決定已 IOS APP 為主開發時，有些議題尚未釐清、有些流程需重新被討論、且所有的任務清單尚未被規劃。 - 產品在誕生階段的時期，取得共識是很重要的。除了取得共識外，同時也再次思考是否哪裡考量的不足。另外未來若需要支援，團隊的配合度會較高。 - 色彩管理 APP 對應的後台要在哪裡? 由誰跟 color system 串接? => 經考慮色彩 APP 的 MVP 對應需求都偏向用戶端，尚未到獨立成系統的階段，所以放在官網後台是較為妥當的，大家都同意這個決定。 - 因使用者案例有重新擬過，所以原先擬定的流程是否需要調整? => 經檢視後確實需要調整，調整後與團隊重新確認，也取得了共識。 - APP 的 UI/UX 尚未被規劃，那現階段要以什麼方式處理? => 因色彩管理是預計在 MVP 第二階段較加入，那也代表著在官網會投入較多資源，所以 APP 的 UI/UX 會先以工程師角度來做處理，未來再做調整。工程團隊有先討論出一個版本，並且與 Raven 取得共識。 - 色彩管理 IOS APP 透過什麼方式來取得任務清單? => IOS APP 的工作任務可分成 "團隊取得 IOS 開發基礎能力"、"串接光譜儀廠商 SDK"、"IOS APP 軟體基礎架構"、"Color system(PHP)"、"依畫面, 使用者案例, 流程對應於 IOS APP 的功能"、"APP 官網對應的 API 接口與登入機制"，從這些項目能較清楚的看出概觀，進而去規劃任務清單。 ## 團隊合作 20 % - 願意參與、支持團隊決策，並做好份內之工作。 - 能與團隊成員建立密切合作關係。 - 樂意與團隊成員分享資源和意見。 - 以包容的態度支持團隊成員，並增進成員間互動的能力。 - 維護並增進團隊的聲譽。 - 追求團體成功甚於追求個人表現。 ### 一、色彩管理 目標定義與重新定義 S: 對色彩管理 APP 第一次定調後，Jack 問說色彩管理要做 APP 的原因及色彩管理這樣做真的對嗎? T & A: - 當下工程團隊說明對 APP 的看法，但想的不夠充分不足以說服 Jack 與自己。=> 根據藍芽去查詢可行的解決方案，且重新思考整個想法。 - 內部再重新討論當時會選擇 APP 的原因是什麼? => 來自最開始不知是誰發起的想法，但大家認為這個想法是不允許被推翻的。另一部分是光譜儀廠商 SDK 是 APP 版本。 - 思考色彩管理到底要提供什麼，要給客戶什麼呢? => 明確定義我的理解與對色彩管理核心價值的認知。 - 重新以設計師的角度出發，客戶想要的是什麼? => 以前有初步想像過，為了更清楚我們的想像，建立使用者故事來確認。 R: - 團隊未來在某個階段應該要有能承上啟下的產品經理，除了瞭解產品與市場更用於凝聚團隊的向心力。團隊有初步共識，現階段讓大家一起來做。 - 列出三個藍芽解決方案的優缺點，工程團隊評的評估與考量是用 Internet 的產品角度切入，團隊若掌握 APP 未來可用的武器也更多了，所以決定選擇 APP 來做開發。 - 重新定義色彩管理的方向與核心方針，第一步是讓設計師簡單透過數字來認識色彩管理，另外透過推廣、線上知識與現下的課程讓更多人認識色彩管理。第二步是建立社群來創造話題與刺激流量，讓設計師相信色彩管理能 "降低溝通成本" 並 "提高商品價值"，接著透過平台創造 "使用者來驅動供應商做色彩管理" 的情境，是色彩管理的終極目標。到底是第幾步才能達到這個目標，誰也說不準。 - 上述的未來方向與核心方針，有與團隊多數的人討論並獲得共識。接著建立使用者故事與案例，重新擬定功能的流程。計畫先讓設計師對數字有概念，雖然這很基礎但很重要。 - 團隊與 Jack 再次同步，Jack 說想清楚了就趕緊 GO!! 只要目標明確且想清楚後，需要先確認的就直接去確認。注意要讓未來的共事者用自主意志來決定，而不是透過上級交辦下來。 ## 實踐學習 15 % - 除了既有的專業素養，尚能不斷充實相關專業知識與技能，並將之吸收運用於工作上。 - 展現積極探索新事務，發掘當下從事領域相關新知的熱誠。 - 分享並提供知識、技能上協助。 ### 一、色彩管理 S: 色彩管理是團隊其中一個核心項目，所以有請老師來訓練團隊對色彩管理的相關知識。 從第一堂課學習下來，頭暈暈的之外還滿頭問號。主因是完全沒接觸這個領域外，老師是用較進階的方式來授課。且講述一個概念時，會講的深且廣。過程中大多透過疑問在互動並從中學習，當下只能記住關鍵字課後再透過回想來做複習。久而久之下來色彩知識也內化到腦中了，現在對色彩管理已摸索到了冰山的一角。 且用學習到的知識與老師、恭麟一起討論色彩管理的未來方向。未來有機會也能分享色彩管理上個人的學習要點，未來的路上還得加把勁來學習與成長。 ### 二、ubuntu, nginx, PHP S: 因應老師自行開發的色彩系統是透過 PHP 建立的，團隊計畫透過 API 來接老師的系統。 學習作業系統、環境、語言時，大多需要依賴自身的基礎能力做學習，也因如此過程中可能會被既有知識被困住。所以在探索沒有接觸過的系統知識時，個人的基礎知識與好奇心都很重要。學習的過程是很有趣的，在未知上進行探索時很容易再遇到未知，是很重要的成長糧食。 在學習前先對整體目標在釐清，需在 Ubuntu 的環境上透過 Nginx 建立 WebServer，並且讓 WebServer 與 PHP 的應用程式做溝通。有了上述的認知後接著就開始規劃一系列的學習目標，Ubuntu 學習要點是 命令集、apt 套件管理、應用程式環境變數、檔案權限、網路基礎應用 ...等。Ngnix 學習要點有環境設定、多工單工、LB、proxy、web app manager、alies virtual path ...等。Laravel 學習要點有環境建置、安裝核心依賴套件、PHP環境建置、FPM 與 Ngnix交互機制。並將這些知識整理記錄下來，供未來參考與團隊分享用。 最後有與 Alex 在正美的測試環境實際佈署，並成功建立 Laravel 的 Web APP。有紀錄整個過程與步驟，供團隊來參考。 ### 三、IOS 開發 S: 因色彩管理規劃以 IOS APP 為主，所以需掌握基本的開發能力，以解決現階段的需求與問題。 在學習新的程式語言時，我個人的工作方法是先認知 基本由來、為何而生、語言特性、相關環境、專案的檔案結構、生命週期、IDE、主流常用框架，掌握了這些知識後會讓學習事半功倍。 規劃學習清單 熟悉 MAC OS 與快捷鍵、熟悉 Xcode 環境與快捷鍵、IOS Project 屬性設置、swift 語言特性與基礎語法、Xcode layout UI 技巧、IOS UI layout 核心概念、IOS APP 主流架構、IOS 開發問題指南。學習的歷程跟知識要點都有記錄下來，供未來與團隊互相分享，加速團隊進入開發 IOS 的過程。 依賴在他人建立的架構、Library 與框架下，而不去思考它們的目的與本質，長期下來就像吃裹了毒的糖。但有時因為時程關係，會忽略了這個過程，這就是常常聽到的技術債。從無到有建置專案雖然比較慢，但從中會學習的更多。有記錄相關的知識要點，供未來與團隊互相分享。 最後將廠商的 SDK 做封裝、基礎架構的建置、APP 畫面的基礎 Layout。並建置了 IOS APP 專案雛形且訂定架構使用規則，讓未來加入的 member 可更快的進入到開發，且在相同基礎規則下建立功能。進而達成 "降低共同維護的成本" 與 "縮短 APP 的開發時間"。