Loading...

感謝大家的參與,IBYT 公開上線 2 天就破 2,000 人次參與體驗,在過程中,也有一些朋友好奇 IBYT 的起源與發展,因此特地寫了篇文章,除了感謝大家,也回應朋友的問題,分享我們是如何 run IBYT 這個 side project 的(這篇文章大約需要 15 分鐘的閱讀時間,文長,慎入!)

什麼是 IBYT?

IBYT 全名是 Identify and Build Your Talent,意思是「辨識並強化您的天賦」,願景是「幫助工程師有意識成為自己想要的樣子」,因此,我們過去、現在、未來在做的事情,都會圍繞並從這個核心出發。

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 如何設計選項與計分。

過程中也有過這類的取捨,是要情境式發問還是用累積量表或其他方式。例如:

  1. 情境式發問,例如(簡單舉例)
    拿到專案經理或產品負責人給的需求後,我會先:
    A. 看有沒有看不清楚的地方
    B. 看有沒有不懂或不熟的技術
    C. 放在一邊,有時間再看
    D. 確認交付時間
  1. Likert scale(又稱累加量表) 拿到專案經理或產品負責人給的需求後,我會先確認有沒有不清楚的地方,並主動詢問交付時間。

非常不認同 有點認同 沒有意見 有點認同 非常認同

那因為蠻明確不會想要類似 yes/no、不是 A 就是 B 的那種問答方式(會有引導的意味),所以在與 Youchi 討論後,我們都蠻認同以情境發問比較能了解差異。

在方向確認後,就開始設計問題,原本是想說,應該 35 題差不多,結果後來設計到 50 題都還覺得有點不夠(但怕再多下去會影響體驗,所以沒有再增加)。

在設計問題的過程中,我們認真的去拆解軟體工程師每天工作會遇到哪些決策情境,依著不同決策情境,列出常見的反應,更為了確定這些產出是有說服力的、合理的,還認真的邀請 AC 強大的助教社群,跟我們走了一場 proof-of-concept (POC)。

*AC 助教平常的角色,是協助學生解決學習上與技術上的問題,並以社群機制激發學生學習動能。AC 助教通常為已畢業的 AC 校友或外聘的專業工程師(工作經驗從一到十年都有),助教任職的公司為外商公司、中小企業與新創等。

POC 的執行方式

Proof of concept,在產品開發上,為了驗證一個概念或理論是不是有需求、可用性、可行性,所做的一個最小化測試。那這次我們的目標比較不是驗證需求,而是去確認問卷題目的正確性,而一般填寫問卷的流程如下:

  1. 開場 / 歡迎及了解相關注意事項
  2. 填寫問卷
  3. 問卷填寫完成,將使用者的選項回傳到某處
  4. 依據答題結果分析角色
  5. 讓使用者有方式知道自己的測驗結果

當然~如果最好的體驗,是在同一個地方就能走完流程。不過考量是在 POC 階段,希望能在不動到工程師的情況下進行概念驗證,因此我們運行的方式很單純,就是將題目與選項放在第三方軟體上(TypeForm), (1)~(3) 讓現成的問卷系統幫我們解決,再使用 TypeForm 串接 Google Sheet。先事先在 Google Sheet 上寫好公式,並依照答案計算結果(4),最後再串 Mailchimp,也是現成的寄信服務,讓使用者能知道自己的測驗結果(5)。這邊要特別感謝 AC 學習教練 Yunju 大力幫忙 (5),我對這超不熟,如果由我來做.... 大概現在還沒串好吧 (?)

然後 (4) 的部分真的就是自己去研究 excel 公式,再跟 Youchi 一起討論確認公式有沒有不合理的地方。

在上述流程都準備好後,很棒的是不用自己找一群人,而是可以直接發給 AC 的助教,請身在不同產業與領域的助教們玩玩看並提供建議。

這裡的作法是:

  1. 請助教們玩完幫填一個簡單的問卷
  2. 再依照問卷上的建議選擇幾位助教進行訪談(原本只需要訪談 6 位,但看到許多助教的想法太棒,就訪談到 10 位)
  3. 依照訪談結果做問卷與題目的優化

在 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.. :D

專案轉折

在開發過程中我們有幾個重要的決策點

  1. 聚焦定位,是與社群連結的方式,而不是行銷工具
    原本的設計是,在開始測驗之前,就可以選擇要匿名測試還是登入測試。其中一個原因,是覺得這樣更有帶入感,以及之後可能會發展測試紀錄,大家可以看自己的成長軌跡。

    一開始曾想,IBYT 除了可以幫助工程師了解自己,還可以是很好的行銷工具,讓大家更認識 AC。但在後來的產品對焦會議,Bernard 提到,這不是他想做這件事的初衷。他的初衷,是希望能與社群建立更多連結,了解產業概況以及社群會不會對認識自己這樣的議題有興趣...等。

    因此才改成,使用者開始測驗都不用註冊,只將註冊放在最後完整報告那段。這樣看到簡易報告就滿意的人,到簡易報告就停止沒關係。但對於認同這個測驗的價值,想看完整報告的人,他還是可以有一個方式去留住自己的記錄。

  2. 首波僅顯示第一角色
    一開始的網頁版本,其實在測驗結果是會呈現兩種角色的。當時的設計目的,是希望大家不要被一個結果定型,而是可以去了解更多可能,並思考自己想要的發展。

    但在邀請 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