感謝大家的參與，IBYT 公開上線 2 天就破 2,000 人次參與體驗，在過程中，也有一些朋友好奇 IBYT 的起源與發展，因此特地寫了篇文章，除了感謝大家，也回應朋友的問題，分享我們是如何 run IBYT 這個 side project 的（這篇文章大約需要 15 分鐘的閱讀時間，文長，慎入！）
什麼是 IBYT？
IBYT 全名是 Identify and Build Your Talent，意思是「辨識並強化您的天賦」，願景是「幫助工程師有意識成為自己想要的樣子」，因此，我們過去、現在、未來在做的事情，都會圍繞並從這個核心出發。
IBYT 的背後的理念，是每個人來到這個世界，都有屬於自己不同的使命及天賦。
差別在於，有些人已能充分瞭解甚至怡然展示自身優勢、而有些人還在探索及待開發的階段。我們相信，人才要成長，就要先認識自己。當你了解自己所處位置與目標的距離之後，才能精準的去學習與準備…
你是戰士、魔法師還是弓箭手？2021 IBYT 工程師特質測驗報告解析
IBYT 是…
透過 Web/APP 領域的 50 題職場情境題，希望幫助在軟體業工作半年以上的工程師，能更了解自己。而對於沒遇過這些情境的工程師，也可以當作一種提前學習，了解在實務中可能會有哪些情境，以及每個選項背後的內涵為何。
IBYT 不是…
- IBYT 不是要將人【定型】，這非常重要，因為這絕不是 IBYT 的初衷與目的。
- IBYT 不是要說哪一個角色比較好，而是想表達，每個人都有自己的特質與強項，只是需要被放在對的地方，並且有方向地努力。而同樣重要的是，一個開發團隊也需要不同的角色，才能發揮最大的產能與價值！所以你也可以參考一下身邊的隊友，是什麼角色，讓彼此的合作更順暢。
來自鐵人賽的契機
在軟體業的 3 年多，我合作超過 20 幾位工程師，經手的專案加起來有 10 多個以上（近一年才開始做產品~）那去年～為了累積作品集和訓練自己的毅力，以及另外一個 LINE bot 產品研究所需，就想說趁著鐵人賽跟著 ALPHA Camp 組的團隊一起，逼自己一定要每天寫一篇文章：PM 觀點 – 30 天 redesign 心目中的 LINE（因為是團隊戰，就會不敢鬆懈 哈）
大概寫到第 24 天吧，感覺遇到了瓶頸。除了發現閱讀量微微下滑 XD （這樣就沒有動力了嘛）還發現，如果要繼續寫 LINE，剩下 7 天寫不完。那怎麼辦呢？既然已經做一版原先想做的筆記與分享（包括如何思考產品、也有去體驗競品功能），階段性任務已達成，那在工程師場域，就聊聊工程師可能會比較感興趣的事吧！於是在第 24 天寫完總回顧後，第 25 天就開始寫自己跟工程師相處的故事了～
這邊其實還有一個轉折，那就是，我們的團體組因故挑戰失敗了，但個人的挑戰還是可以繼續。那這就有點激起我想挑戰的心了。大概天生是沙丁魚的命，最喜歡遇到挫折 (?) 給我一點刺激，會覺得更有趣，並更有戰鬥力（好啦，這邊明明沒有人說什麼，只是自己覺得，原本參加完 30 天，有兩個虛擬的獎章就很滿足了 XDD 但現在只有一個完賽獎章，就有點空虛，因此想說還能不能有什麼漣漪）
不敢說自己很會跟工程師相處（畢竟偶爾還是會吵架 >.<），但只能說，我很喜歡跟工程師相處。我接觸過的工程師的個性剛好相對理性，做事較目標導向，不會有太敏感的玻璃心需要呵護；即使有，我也會花一段時間幫助對方建立團隊認知，並一起找到共同目標，盡量讓團隊望向同一個方向，共同為了產品 / 專案努力。對我而言，這樣的相處是很輕鬆的～就是只要就事論事，接受彼此不同，與對方優勢相處並互相尊重，大概就沒什麼問題了。
這樣一來，團隊運行時，就可以將大部分的時間用來專注並好好實現目標（不過這是個人經驗，可能也跟我現在處於中小企業及公司文化有關係。）
再來～我本身就是興趣驅動者。看待很多事情，都會將它趣味化。例如說，會覺得人生很多關卡，每次破關都會有升等的快樂。再例如，專案是動態的，身為 PM，需要在多個專案之中，動態調整工程師的人力。假如遇到難關，要再依著不同目的安排最適合的工程師處理，這樣的合作模式，讓我覺得… 很像在演神奇寶貝或遊戲王！
痾，更正，很像三國遊戲內的擺兵佈陣。並且發現，其實許多工程師有蠻明顯的特質，好像就是會有某些工程師，遇到問題時，反應不太一樣。有些人會覺得規格拿出來，先做再說，例外情況我會自己搞定。有些工程師會追著問你，為什麼要做這個、價值與意義在哪裡？
因此，在鐵人賽第 27 天，我將自己對工程師的觀察與理解，分成不同特性，寫了篇【談談軟體工程師 – 8 大戰略角色及 7 大能力對應的 26 項指標】，並在工程師社群分享，也的確獲得一些迴響，就～很開心！我朋友還說：這是寫了一篇救了前面 26 篇！…嗯？… XDD
接著是，在 FB 社團分享時，有網友說這好像很適合做心理測驗，ALPHA Camp 的創辦人 Bernard 與 Youchi 閱讀後也覺得蠻有趣的，我們聊一聊後，就決定把這個 side project 做起來了 XDD （至於我跟 AC 怎麼認識的又是一段故事了，當時為了讓自己能聽懂工程師的語言，適逢 AC 剛好要轉線上教育，我就有報名 AC 的測試課程，當課程的 reviewer。再後來，因為合作都算蠻愉快，還轉做產品設計課程的助教，也在裡面認識不錯的朋友～所以算是信任度蠻高的！）
IBYT 發展過程
與 AC 合作的開始
話說，在正式確定要開始 IBYT 之前，我很認真準備一個小小的 pitch。那時候是第一次提 IBYT 這個名字。 Youchi 和 Bernard 還很好奇問，這是什麼意思 XDD 團隊成員念了好多次，才記起這個名字 XDDD （就像 MBTI, 也常被記成 MIBT 之類的 XD）
前面有提到，IBYT 全名是 Identify and Build Your Talent，意思是「辨識並強化您的天賦」，就像解決問題之前，要先知道如何辨識與定義問題一樣，在人才發展也是。首先要知道自己是誰、在什麼位置，其次才是想去哪裡、為什麼想去、以及該如何抵達、需要具備哪些能力等議題。市面上有很多技術型測驗，測試工程師的技術力，卻少有這樣的軟性測驗，能了解工程師的軟實力，而這就是我們想做的事情（在徵才時也是，我們常覺得技術是可以學的，而軟實力是最難得的…）
在 pitch 的過程中，也透過提問等方式，先發散再收斂，去描述 IBYT 可以在品牌扮演的價值與定位。
BTW，之前有朋友問到，因此這邊也一起回覆。其實我曾經猶豫過，是 Build Your Talent 還是 Development Your Talent，後來選擇 Build 是因為，就像開發完要先 build 一個專案才能跑起來吧，我覺得 development 有一個從一個基礎成長更好的意味，而 build 比較是可以從 0 到 1，認識自己後，可重頭開始建立並創造的涵意（不因過去的經歷為自己設限）
啟動 IBYT
在雙方理念相符的情況下，專案就啟動了。以下列出幾個重要時間點：
更細節的時間是：
- 2020/10/20 第一次 pitch
- 2020/10/26 專案啟動，開始搜集資訊並製作題目（中間剛好有同時跑另一個專案）
- 2020/11/21 UI/UX 設計
- 2020/11/25 發送 POC 問卷與訪談（目標：驗證問卷問題）
- 2021/12/8 工程師進場參與討論與開發
- 2021/1/19 內部測試與調整
- 2021/1/27 公開上線與推廣
- 上線 2 天，有 2,000 多人次參加測驗
專案從正式啟動、POC、UI/UX 設計、開發、測試到上線，剛好三個月，約 67 個工作天。
我們是全遠端工作，開發團隊包括：PM/UI/UX x1、Full-stack Engineer x1、Consultant x2
首先非常感謝，在過程中，Youchi 與 Bernard 幾乎是放手讓我將這個網站與內容作出自己想要的樣子，不只提供很好的工程資源（ihower 老師的愛好資訊科技），更是在需要的時候，給我非常重要與關鍵的建議（後面會提到專案轉折點）
整個專案都是用 Notion 管理文件的～專案啟動後，我們就將就所有工作事項列在同一個表格（Notion 很方便的是可以切換瀏覽模式，盤點的時候用 table view，開始走行程時就會切成 board view 跑看板開發，比較了解目前有哪些 WIP）
那最主要的就是列出整個專案大概會經過哪些階段、不同階段要做哪些事情（從設計規劃、開發到產品上線推廣），所需資訊包括預計什麼時候開始與結束、會需要哪些外部資源等，最後就是列出各項目的狀態（這是從產品角度 overall 的時程，那到工程開發，就有獨立另一個開發專用的 borard，讓工程師能聚焦）
除了列表顯示的上述資訊，點進卡片後，每張卡片的內頁還有進一部列每個項目的目標目標、為什麼要做這些事情、要解決哪些問題以及有哪些參考資料等。關於問卷題目的設計上，為了讓結果更 make sense（這邊指的結果，是要能夠更具體地幫助工程師描繪出他們的特質），很認真參考並看完一些相關文獻，也有去參考 MBIT 如何設計選項與計分。
過程中也有過這類的取捨，是要情境式發問還是用累積量表或其他方式。例如：
- 情境式發問，例如（簡單舉例）
拿到專案經理或產品負責人給的需求後，我會先：
A. 看有沒有看不清楚的地方
B. 看有沒有不懂或不熟的技術
C. 放在一邊，有時間再看
D. 確認交付時間
- Likert scale（又稱累加量表） 拿到專案經理或產品負責人給的需求後，我會先確認有沒有不清楚的地方，並主動詢問交付時間。
非常不認同 有點認同 沒有意見 有點認同 非常認同
那因為蠻明確不會想要類似 yes/no、不是 A 就是 B 的那種問答方式（會有引導的意味），所以在與 Youchi 討論後，我們都蠻認同以情境發問比較能了解差異。
在方向確認後，就開始設計問題，原本是想說，應該 35 題差不多，結果後來設計到 50 題都還覺得有點不夠（但怕再多下去會影響體驗，所以沒有再增加）。
在設計問題的過程中，我們認真的去拆解軟體工程師每天工作會遇到哪些決策情境，依著不同決策情境，列出常見的反應，更為了確定這些產出是有說服力的、合理的，還認真的邀請 AC 強大的助教社群，跟我們走了一場 proof-of-concept (POC)。
*AC 助教平常的角色，是協助學生解決學習上與技術上的問題，並以社群機制激發學生學習動能。AC 助教通常為已畢業的 AC 校友或外聘的專業工程師（工作經驗從一到十年都有），助教任職的公司為外商公司、中小企業與新創等。
POC 的執行方式
Proof of concept，在產品開發上，為了驗證一個概念或理論是不是有需求、可用性、可行性，所做的一個最小化測試。那這次我們的目標比較不是驗證需求，而是去確認問卷題目的正確性，而一般填寫問卷的流程如下：
- 開場 / 歡迎及了解相關注意事項
- 填寫問卷
- 問卷填寫完成，將使用者的選項回傳到某處
- 依據答題結果分析角色
- 讓使用者有方式知道自己的測驗結果
當然～如果最好的體驗，是在同一個地方就能走完流程。不過考量是在 POC 階段，希望能在不動到工程師的情況下進行概念驗證，因此我們運行的方式很單純，就是將題目與選項放在第三方軟體上(TypeForm)， (1)~(3) 讓現成的問卷系統幫我們解決，再使用 TypeForm 串接 Google Sheet。先事先在 Google Sheet 上寫好公式，並依照答案計算結果(4)，最後再串 Mailchimp，也是現成的寄信服務，讓使用者能知道自己的測驗結果(5)。這邊要特別感謝 AC 學習教練 Yunju 大力幫忙 (5)，我對這超不熟，如果由我來做…. 大概現在還沒串好吧 (?)
然後 (4) 的部分真的就是自己去研究 excel 公式，再跟 Youchi 一起討論確認公式有沒有不合理的地方。
在上述流程都準備好後，很棒的是不用自己找一群人，而是可以直接發給 AC 的助教，請身在不同產業與領域的助教們玩玩看並提供建議。
這裡的作法是：
- 請助教們玩完幫填一個簡單的問卷
- 再依照問卷上的建議選擇幾位助教進行訪談（原本只需要訪談 6 位，但看到許多助教的想法太棒，就訪談到 10 位）
- 依照訪談結果做問卷與題目的優化
在 POC，有 77% 的測試者認爲結果準確，還有 73% 的測試者對這份測驗提供較高滿意度的評價。
印象蠻深的是，助教們都非常熱心去提供回饋。有些助教會建議說這問卷未來還能夠提供什麼，也好奇這有沒有什麼商業模式等等，這些討論都蠻珍貴的，也都有一一記錄下來，我們也有將可以修改的事項都先調整並回饋到現在的 IBYT 上。
MVP
MVP 是 Minimum Viable Product 中文常被翻最減可行性產品，那我自己解析這個中文翻譯，會覺得這裡的把「可行」超譯成「核心價值」會更精準。
同樣面對一個問題，其實每家公司、甚至是同一家公司的 PM/PO 提出來的解決方案都可能不太一樣。但首先需要對齊的是什麼是 MVP？以及產品的核心價值為何？
Image Credit: An alternative to a Minimum Viable Product
以 IBYT 而言，我們認為 IBYT 的核心是幫助使用者了解自己，所以花比較多時間去思考及驗證題目、選項、計算公式與報告，而花比較少時間去優化測驗過程的介面（雖然還是有簡易設計）。附上亂中有序的 figma 鳥瞰圖 XD
接著就是在工程開發階段，除了將開發相關文件都集中在一起，也有用一個簡單的小表格紀錄設計稿上比較大的修改記錄。
同時有簡單的開發用的看板作為追蹤（IBYT 算單純，所以卡片不多，但測試計畫有超多 checklist.. 😀
專案轉折
在開發過程中我們有幾個重要的決策點
- 聚焦定位，是與社群連結的方式，而不是行銷工具
原本的設計是，在開始測驗之前，就可以選擇要匿名測試還是登入測試。其中一個原因，是覺得這樣更有帶入感，以及之後可能會發展測試紀錄，大家可以看自己的成長軌跡。一開始曾想，IBYT 除了可以幫助工程師了解自己，還可以是很好的行銷工具，讓大家更認識 AC。但在後來的產品對焦會議，Bernard 提到，這不是他想做這件事的初衷。他的初衷，是希望能與社群建立更多連結，了解產業概況以及社群會不會對認識自己這樣的議題有興趣…等。
因此才改成，使用者開始測驗都不用註冊，只將註冊放在最後完整報告那段。這樣看到簡易報告就滿意的人，到簡易報告就停止沒關係。但對於認同這個測驗的價值，想看完整報告的人，他還是可以有一個方式去留住自己的記錄。
- 首波僅顯示第一角色
一開始的網頁版本，其實在測驗結果是會呈現兩種角色的。當時的設計目的，是希望大家不要被一個結果定型，而是可以去了解更多可能，並思考自己想要的發展。但在邀請 AC 助教團隊測試時，我們才發現當時第二角色的公式有點瑕疵，會出現第一和第二角色相同的情形。後來經過種種考量，包括現在沒有足夠的時間去完善這件事，而且這部分還有一點不確定性在，所以我們最後討論果斷移除第二角色，但在文案上強調並介紹說，下一版的改版會有附屬角色，幫助大家更全面的了解自己。
Bernard 與 Youchi 另外還有給幾個很棒的建議，例如，希望在網站的聲明頁簡短分享這個 side project 的故事，同時彰顯做這個測驗的價值（原本只有首頁和關於 IBYT 有介紹），那當我們還在討論要怎麼做時，是愛好的工程師 Nacho 大概看我們在煩惱，就主動提出說，他可以用雷達圖加上角色切換的方式，去做一個互動。當 Nacho 主動提時，其實我有點嚇到（驚喜居多!）因為當時，我的確是在想，如何在不動用到太多工程師資源的情況下去做這件事。而工程師明知道這樣會增加自己的工作量，還是主動提出這個很好的建議，代表他也有投入自己，希望這個服務能發展更好。而這真的也是我很喜歡的合作模式，設計、技術、溝通管理相輔相乘，在有限資源下將產品價值最大化。
一個產品，如果能做到讓團隊成員們能很大方地跟別人分享，這是我們團隊做的產品。從 team bulid 的角度上，已經是在好的方向了
老實說，這一頁，現在是我最喜歡的一頁之一！
另外值得提的地方是，我原本想說這個做完就好了，算是階段性任務。但沒想到 Youchi 主動提說，她認為應該要在網站上點出我的經歷、貢獻與 credit，其實我聽到這也覺得蠻驚喜的！那後來想想，其實大家還是為了了解自己而來，而不是為了 Rafeni 。所以是設計了簡單的感謝區域，也一同感謝相關單位，包括鐵人賽也是我們的感謝對象，因為有鐵人賽，才能觸發這個奇妙的旅程～～
我們學到什麼
此外，在運行中，有個小小插曲是，我與工程師對角色的中英文名字認知有落差 XDD所以延伸意想不到的 bug。後來我們就統一，以前台畫面會呈現的中文來當溝通語言，也加上相關的對照～～名詞定義算是要在早期就確認的事情，所以這個算是疏忽了!
對我來說～最大的學習，大概是我竟然能在 excel 用公式算出角色!!! 也見識到 AC 團隊們的神奇之處。以及，這次算是我做得比較完整的 UI 設計（過往都是出 wireframe，頂多情急之下小調設計師給的 UI）。除了 icon 是以 Flat Icons 調整顏色，其他 UI 設計都是自己一手包辦，也包括設計簡單的 Style Guide.. 等等，只能說，我要求我們其他專案設計師做的事情，我自己真的也有做到哦（戳一下對方 ㄎㄎ）
在問題設計上，也有許多朋友給我們不同的 feedback，我們都非常感謝。邀請大家在填寫問卷並查看結果時，可以帶有 70% 的認真，加上 30% 的趣味，因為這個問卷只是從現有的 50 題去認識部分的你。任何分析結果都不代表全部的你。我們想讓每個人知道自己是的價值。
最大的收穫
除了上述資訊，特別想分享的是，有網友做完測驗後，跟我們說，謝謝我們做這個測驗，安慰到他職涯徬徨的狀態…（平常在開發時，會覺得比較沒有成就感。那看完測驗結果後，他反思，也許是想法沒有充分溝通到，或是沒有從產品端的角度考慮等，有體會到自己比較在乎的點在哪裡）
下一步
下一步～就是繼續分享，並按照計劃做出產業報告了，感覺會有許多有趣 / 有價值的資訊可以參考。同時會繼續搜集大家的意見回饋，讓 IBYT 能帶給大家更多價值！
不知道正在看這篇文章的你，是否已經體驗過 IBYT 呢？
體驗連結：https://survey.alphacamp.co/ibyt/about
