fbpx

當傲氣阻擋你最好的工作表現時

原文網址

文章鏈結: When Pride Gets in the Way of Your Best Work

此文章來自 The Effective Engineer 作者 Edmond Lau 的部落格。 Soft & Share 獲作者授權翻譯。


Slack 創始人兼執行長 Stewart Butterfield 希望押注於一個名為”機器人團隊”(Bot Team)的想法,以解決該公司最緊迫的產品挑戰之一。1

在公司測試版釋出一年半之後,每天有超過50萬人2使用團隊資訊產品。 但為了保持快速成長,Slack 需要開拓新的受眾,並已超越的技術帶動早期採用者。

但是你如何將 Slack 的價值傳遞給一個以前從沒使用過企業通訊產品的新使用者呢? 你如何解釋直接互動的訊息、管道和服務整合在一個地方的好處,在某人還沒有註冊進入團隊之前?

那就是”機器人團隊”(Bot Team)的想法出現的緣由——新客戶可以通過與由電腦控制的機器人團隊聊天來嘗試 Slack。 通過模擬,他們可以更清楚地瞭解產品是如何運作的。 這是一個合理的假設 — 畢竟,有什麼是比真正下去用更好的方法來瞭解一樣產品?

工程團隊估計,要建立足夠好的機器人能夠與新使用者進行基本互動,至少需要 6 個月的努力。 另外,他們花在這上面的時間越多,他們就越能讓機器人團隊變得更加可信。 然而,有一個風險,假冒的團隊可能會迷惑使用者 — 這些機器人是誰,他們為什麼在這裡? 半年後,這個團隊可能會在情感上如此依戀並投入,以至於即使這個想法沒有那麼好,也很難改變方向了 — 這個想法是否會帶來任何問題?是否能用更好的機器人品質來解決問題?

那麼,這個團隊應該下注嗎?

傲氣對工匠的關鍵作用

作為工匠,我們為自己的工作品質感到自豪。

我們希望把我們的名字與人們喜愛的產品關聯,感受到用戶使用的喜悅,優雅地寫出解決技術問題的程式,做出能可靠地處理大規模資訊流量的系統,甚至是那些巧妙地解決看似不可能的問題的駭客。

我們希望能夠驕傲地指出我們已經建立起來的東西,並告訴人們”是我建立的”,而不必躲在角落,因為東西被指指點點,說程式碼有很多瑕疵或都是複製和貼上的,或產品體驗是多麼牛步或混肴不清。

工作中的自豪感使我們的積極地保持在高水準,這對於建立高品質的產品是不可或缺的。 相反的,如我們對自己建立的東西感到不自豪 — 這種情況可能發生,例如,當業務的最後期限迫使我們增加越來越多的技術債務時,這令我們筋疲力盡而無暇照顧其他細節。

然而,伴隨著傲氣而來的強烈情緒也可能阻礙我們做出最好的成果

在我們的職業生涯中,我們可能都至少經歷過一次這樣的情況:我們承諾做出一個特定的決策 — 也許是如何構建我們的程式碼,使用什麼樣的架構或設計,或者需要建立什麼樣的功能,以及如何構建它 —  直到幾個星期或幾個月後,我們才發現這是錯誤的決策。 然而,無論如何,我們還是會繼續做下去,把那些不再是好主意和我們明知不滿意的專案完成推出。

當我們有意識地以因為我們所建立的是”足夠好”的心態來做權衡取捨,無法割捨是一個合理的選擇。 但是,當我們拒絕改變方向或不願放棄我們已在進行的工作時 — 即使艱難的壯士斷脘決定是更好的選擇 — 那麼我們就會“讓對自己已建東西的情感依戀”阻礙了我們前進

從心理學角度來看,這種情況發生的原因有很多。 我們在處理沉沒成本時遇到了麻煩 — 承認我們可能不得不放棄我們迄今為止投入的所有工作和努力

有時候,我們只是想要個了結——我們只是想把事物打包出貨,這樣我們就可以繼續前進。

但是其他時候,我們擔心自己看起來對同事不好,或者背棄我們做出的任何承諾。 對於我幾個月前才說服同意這麼做的團隊裡的每個人我要怎麼去跟他們說 ? ? 如果我回到我的承諾上,我在別人的眼裡又如何? 在《給予與索取》中,Adam Grant 稱這種現象為”自我形象的威脅”,它可能是一個強大的動機,使我們在錯誤的道路上走得太久。3

我們難以扭轉一個糟糕的決定,這與我們投入的時間、精力、金錢和情感投資成正比。 當我們花費數月甚至數年的時間來做出某種努力或決定時,簡單地拋棄一切可能是困難的,也可能使士氣低落。 即使我們在邏輯上說服自己,重新開始可能是正確的事情,但躲開我們已白費了一大堆努力的感覺可說是蠻困難的。

少一些關心並不是解決問題的方法——這隻會導致工作品質下降,工作缺乏動力。

那麼答案是什麼呢? Slack 團隊是如何於機器人團隊( Bot Team )的想法來躲避這種陷阱呢?

在你變得過於依戀之前,儘早和便宜地驗證你的想法

團隊採用了一個聰明的方法來驗證機器人團隊( Bot Team )的想法。

作為 5 天短跑的一部分,他們設計並建構了一個新使用者體驗的外觀,他們讓團隊成員假裝是機器人,通過準機器人的對話方式傳送和回覆資訊。 這種體驗絕對還沒規模化,但是只要對五個使用者進行測試,就能知道這個想法是否有價值。

機器人團隊( Bot Team )的想法失敗了。 只有五分之一的人喜歡與他們認為是電腦的隊友交談,對這種經歷的反饋包括從”她很困惑”到”我不太確定這是什麼”。 他們最終放棄了機器人團隊( Bot Team )的想法,專注於其他能夠說明產品的方式。4

這項測試最終為團隊節省了至少 6 個月的工程努力,他們可以輕鬆地轉向一套不同的想法,並得出更好的結果。 但更重要的是,這種方法意味著團隊避免過於情緒化地投入到機器人團隊( Bot Team )的想法中 — 這種情況一定會發生在執行長倡導的專案上,並且持續半年。

我們在某件事情上投入越長的時間,我們就會對其有越多的情感依附因此,如果我們能夠為評估一個想法減少初始的投資,我們就更願意做出正確的決定,然後離開

在我們走得太遠之前,我們用真實的反饋儘快驗證我們的方向是否正確。

當我們更快地迭代,當我們將反饋融入到我們的迴圈中時,我們對任何特定的想法都沒有太多的情感投入。 畢竟,我們只是在測試不同的想法,看看哪些能堅持下去。 我們不太可能把自己的名聲與任何特定的想法聯繫起來。 這給了我們追求最有可能成功的路線的自由和信心。 這種情感依戀的減少是快速迭代速度的一個好處,而這一點並沒有獲得到普遍的重視。

那麼,我們如何才能建立工作流程來持續得到早期的反饋? 以下是一些建議:

  • 在建構新的東西時,寫一個簡短的設計檔案,突顯細節,並在你的團隊中傳播,以便在你開始建構之前獲得反饋。 在 Quip,這已經成為我們在 Quip 文件上所做的工程過程中的一個正常部分。

  • 當你追求一個冒險的想法,優化學習關於未知的知識,並儘早消除專案的風險。 不要優化你如何完成它或使它規模化。 在我在 Google 工作的時候,我看到的一個常見的反模式是,許多工程師和產品團隊在建立第一個版本時就在應付 Google 的規模——這意味著更少和更慢的迭代和更昂貴的失敗。

  • 建立最簡單和最小的產品版本,以收集使用者反饋。 或者更好的是,像 Slack 團隊那樣更進一步,建立一個表面的版本,你可以先用來向使用者展示以進一步驗證你產品的價值。

  • 在把精力投入到解決你認為可能是客戶的問題之前,把你的研究和對話接軌真正的使用者和客戶,瞭解他們的痛苦和需求。 像 Intercom 這樣的工具使得團隊更容易與使用者接觸並收集真正的反饋資訊。

  • 積極推遲任何與把你的第一個版本推到使用者面前不相干的工作。 儘快完成你的產品反饋迴圈。

  • 對你正在做的事執行持續性的使用者測試來建立一個健康的驗證節奏。 在 Quip,我們有時會每週做 12 個使用者測試來建立對我們選擇的信心。

通過採取先驗的思維模式,我們可以剔除那些最終會失敗的看似有前景的想法,並且為推出我們更有信心的想法而感到自豪。

 

  1.  Jake Knapp, John Zeratsky, and Braden Kowitz. Sprint: How to Solve Big Problems and Test New Ideas in Just Five Days.
  2. Harry McCracken, “With 500,000 Users, Slack Says It’s The Fastest-Growing Business App Ever”, Fast Company, February 12, 2015.
  3. Adam Grant, Give and Take: Why Helping Others Drives Our Success, p113-114.
  4. Sprint, p220-221.

也許你會有興趣

 歡迎訂閱 Soft & Share 

發表迴響

這個網站採用 Akismet 服務減少垃圾留言。進一步瞭解 Akismet 如何處理網站訪客的留言資料

Powered by WordPress.com.

Up ↑

%d 位部落客按了讚: