在我不算長的職業生涯中，有很多同事都給過我正面的評價（當然，可能有更多負面的評價，不過我都選擇性的遺忘掉了）。有人欣賞我的命令行技巧，有人則稱讚我代碼寫的比較快，有人說我的Vim的插件配置的很高效，還有人說坐在我旁邊寫PPT效率會變高。而我自己最喜歡一個評價是：有我在項目上的時候，團隊就會覺得安心。

我喜歡這個評價是因為它是我希望自己能展現的一個狀態：成為一個靠譜的職場人。關於靠譜的職場人，《重來》的作者之一Jason有一個很精煉的描述：

Work ethic is about showing up, being on time, being reliable, doing what you say you’re going to do, being trustworthy, putting in a fair day’s work, respecting the work, respecting the customer, respecting the organization, respecting co-workers, not wasting time, not making work hard for other people, not creating unnecessary work for other people, not being a bottleneck, not faking work. Work ethic is about being a fundamentally good person that others can count on and enjoy working with. — Jason Fried

大意是：職業精神就是可靠，言出必行，尊重工作，不要浪費時間，不給別人添麻煩等等。不過，精煉的描述往往失之可操作性不夠強。就好比知道“高內聚，低耦合”並不能幫助你寫好代碼一樣。在這篇文章裡，我打算舉一些日常工作中常見的例子，嘗試通過Specification By Example的方式給靠譜的職場人下一個定義。

在職場中，靠譜的意思就是：成為一個別人會信賴並樂於和你一起工作的人。而人們喜歡和靠譜的人一起工作。

尊重你的工作

人們站在不同的立場看待同一件事情時，必然會產生分歧。這幾乎在項目中隨處可以見，比如對於某個Feature，客戶認為必須實現，這樣在年終的績效考核中才有令領導滿意的成績；另一方面，對於交付團隊來說，技術上難以實現或者工作量太大，難以在有限的時間內完成；開發團隊鍾愛新的流行的技術棧，而客戶則相對保守，需要考慮培訓成本等等其他方面的因素。如果再加上溝通不暢，很容易導致團隊士氣低落，甚至雙方互相抱怨。

一份工作，既是企業（企業中的員工）賴以生存的條件，又是企業和服務對象共同為社會創造價值的載體。這個產品可以解決某些人的問題，提高效率，為社會帶來價值。工作本身就是值得尊重的。如果你被指派到一個項目上，並且作為個人，你不認為這個項目違背了自己的價值觀，那就應該全力以赴去完成它。另一方面，如果你認為項目的價值和自己的三觀不匹配（比如，如果有人出錢讓你去開發GFW之類的工具；或者一個工具用來監控員工的桌面等），你完全可以選擇不去參加這個項目。

新人常犯的一個錯誤是將遵循既有規則當成尊重。舉個例子，在實際交付的時候，團隊中的Tech Lead做出了一項你任務是錯誤的決策，作為團隊成員，你可以據理力爭，表達自己的看法，並提出自己的提議。另一方面，你也可以假裝這個決策是超出你控制範圍的，並且假裝它是正確的，然後低頭來按照決策來實施。在我看來，第二種看似尊重的行為是對團隊和項目的非常的不尊重。退而言之，即使你的提議被拒掉，你也可以從中學到很多之前看不到的知識。一方面可以幫助你自己理清思路，看到自己方案的缺點，另一方面，你可以學習人們在實際項目中，如何對於不同的條件來做妥協。

與他人合作

一個人可以走的更快，一群人可以走的更遠 — 非洲諺語

我們的日常工作中，總避免不了要和不同角色，不同經驗的人一起工作。和單槍匹馬獨自作戰不同的是，在一個群體中，個人的行為需要遵循一定的約定，需要和其他團隊成員一起配合來完成任務。換句話說，要有團隊合作精神。在和其他人一起工作時，第一要義是不要為別人製造更多的工作量。事實上，你應該在自己能力允許的前提下，儘可能讓別人做最少的工作。相信我，你會希望自己和這樣的人合作的。

我們從一個假象出來的場景出發，來看看如何在類似的場景中展現專業性：

CI服務器地址

設想這樣一個場景：你所在的團隊有一個微信群，大家很多問題都在群裡提出並討論。但是一些簡單問題可能被頻繁的問道，比如XXX服務器的地址是啥

而這時候，你可以做什麼呢？“我之前發過郵件給所有人了，你翻一下郵件”。

這是一個可行的方案，但是需要

• 郵件標題的關鍵字 或者
• 郵件正文關鍵字

而要做搜索本身動作，他需要打開郵件客戶端或者在瀏覽器打開Web Mail，如果是訪問Web Mail，他可能還要登錄公司內網（輸入密碼），還可能要查看Okta推送的消息，這又需要打開手機，切換到Okta，點擊確認。如果工作環境網絡有vpn的隔離，情況可能會更復雜。

如果你花費1分鐘幫他搜一下，然後把地址發給他，並告訴他用戶名/密碼就是域賬號的用戶名/密碼，效果則會好很多。

訪問外部API

如果我們把這個場景在稍微複雜化一點：有人在微信群問如何在Postman中訪問獲取所有網點信息的API。要訪問這個API，客戶端需要一個Endpoint和一些特定的HTTP Header。最簡單的做法是發送一個截圖。

不幸的是，Header中有一個叫做x-api-token，它的值是一個256個字符的hash。這時候圖片就變得毫無用處了：你不會期望問問題的那個人用手敲一遍token吧？另一個方法是把API的Endpoint和所需的HTTP Header是分別以文本形式發送給他，（如果這個API需要多個header的話，你可能要複製粘貼好幾次）。

再進一步，你可以通過一個cURL加命令行參數的方式將這些內容一次性發送給他:

$ curl -H "x-api-token: token" -H "Accept:application/json" https://host:port/top-security-resources/1

嗯，挺不錯的。不過如果明天又有其他人問你要這個API的訪問方式，你又要再來一遍，還是比較麻煩。你稍微翻了下Postman的幫助，發現它支持導出，還可以定義一些環境參數等。如果將這些內容都導出出來，然後放在代碼倉庫中，其他所有人就無需每次都找人要各種URL了。

顯然，最後一種方法既滿足當前的需求，又有很好的可擴展性，這樣你就通過一個具體的問題，抽象出一個高階的問題，並且為這個問題提供了一個可行的解決方案了。當然，這種方法的缺陷是會佔用你很多時間，需要你學習額外的知識。不過，如果是我，我肯定願意選擇這種方式。

幫助團隊裡的測試

我記得我們曾經有一個研發平臺項目，其中一個需求是實現租戶代碼壞味道識別的工具：這個工具的輸入是平臺上程序員提交的源代碼，然後我們的工具會分析類和類之間的關係，然後給代碼評定一個分數：比如集成層次不能太深，不能有多繼承之類。代碼本身並不難寫，但是要測試時需要列舉很多case，每一個case至少需要可以能編譯通過，這要求測試同事還要會寫合法的C++代碼，也就意味著他們還需要C++的多繼承，抽象類之類。

我花了一些時間（兩個小時左右）為測試同事寫了一個小工具：通過指定一些參數，比如類的繼承層次，是否多繼承之類，然後這個工具幫你生成一堆合法的可以編譯通過的源代碼：包括多個文件，文件之間的引用（比如頭文件中定義接口，然後在實現代碼中訪問這些接口等等）。測試可以很容易通過它來生成測試用例，然後再來驗證待驗證的工具到底能不能識別這些壞味道。

另外一個有趣的例子是：很久前的一個項目，團隊在開發一個大表單，大表單裡有很多問題，大概分為三個頁面：第一頁需要填寫一些個人信息，比如姓甚名誰家住何處等，第二頁則會填更多的信息，而第二頁的很多問題跟第一頁相關，一些問題只需要在第一頁選了A選項才會出現，而另外一些問題則僅僅為B場景設計等等。

然後某個新需求是在第三頁添加一個新的問題（根據第二頁的某個回答來決定要不要顯示出來）。在實現過程中，開發人員需要手工填很多內容才能到達第三頁，而這個過程還可能出錯（比如第二頁中需要去調用某個API來生成下拉列表內容，那個API有可能會掛掉），一出錯又得重來一次（當時還沒有HMR啊，State管理啊這些高級貨，只能重新刷新）。團隊意識到這個痛點之後，有人就開發了一個Chrome的擴展，這個擴展可以根據預設的答案自動填寫表單（好像是模擬鼠標點擊的方式），直到你想要停下來的那一個問題。這樣就將開發中調試的時間大大縮短，還可以節省很多測試同事的工作量。

事實上，這類的場景在實際項目裡會有很多。通過一些自己的努力，讓團隊裡的其他角色、或者團隊之外的你的下游系統、又或者未來的系統維護者的生活變得輕鬆一些，是

做好Desk Check

在敏捷開發中，當一個Story開發結束之後，我們會把開發，測試，BA，UX聚在一起來做Shoulder Check / Desk Check。這個實踐可能很多團隊都會堅持。但是做的流暢程度則千差萬別，效果也自然大相徑庭。

我現在還記得第一次做Desk Check時候的忙亂，由於事先沒有準備好，當圍觀群眾上來之後，我和peer還沒有把Jira上的卡打開。當逐條過驗收條件（AC）的時候，我們才發現漏掉了一條。然後在跨瀏覽器檢查的時候，發現在Safari裡頁面上有個按鈕在點擊時毫無響應，這時候我和peer打開了dev-tools開始了現場debug等等。

在後來的項目中，我特別注重這個實踐，努力讓Desk Check變得流暢無礙。你前期準備的越充分，在Desk Check的時候就越順暢。比如，在把所有人都召集過來之前，自己先把所有AC過一遍，如果有Feature測試的話，就把測試用例大概過一遍，看看能不能覆蓋所有AC。在Check的開始前，先把Story描述一遍，特別是業務場景，業務價值。這個過程可以對著Jira卡來過，如果有新的討論，也需要順手同步到Jira的comments裡，以便未來參考。由於參加Desk Check的QA和BA可能手頭都有很多任務並行處理，所以你需要快速的將上下文分享出來，讓大家在同一理解水平上，這樣後續的Check才有可能順暢。

如果Story涉及跨瀏覽器，那麼你最好可以將各個瀏覽器都打開，而且切換到需要showcase的頁面上。這些前期的準備工作，可以減少參與者的上下文切換成本，可以讓大家迅速進入到驗收中，而且出錯甚少。事實上，大部分問題在你的準備中都已經解決了，剩餘的小問題則可以在後續的Story開發過程中順手修復。

測試數據準備

BA對系統的理解是基於現實世界中的業務來的，因此在數據準備上一定要小心，比如10位數字的身份證號碼，帶有字母的手機號等等。即使是測試數據，也應該認真對待，儘量避免使用隨機的文本來填寫表單，否則結果頁面看起來會非常不專業。

在有些場景下，比如你需要測試當文本超過一定長度會顯示省略號，你仍然需要仔細設計文本，讓其看起來更為實際。當你讀到一個名稱為“錕斤拷錕斤拷錕斤拷…”的產品時，你會做何感想？

事實上，一些工具可以幫你簡化測試數據的準備，而且可以確保專業性。比如Ruby裡的Faker（Perl中的Data:Faker的Ruby移植版）https://github.com/stympy/faker，它可以幫你生成很多常見的數據實例，比如

require 'faker' 

Faker::Name.name #=> "Christophe Bartell"
Faker::Bank.iban #=> "GB76DZJM33188515981979"
Faker::Internet.email #=> "[email protected]”

使用類似的工具，只需要編寫一些微小的代碼，就可以生成更貼近業務場景的測試數據，從而讓顯得更加專業。

設計中的細節

同樣的道理，UX在設計稿中，需要考慮很多細節，比如

• 常見的拼寫錯誤
• 業務術語的正確使用
• 理解數字的含義
• 視覺一致性（字體的選用，相同元素的字號，顏色暗示等）

這些細節可以讓觀眾體會到你的認真和用心，而由於視覺的特殊性，一個微小的紕漏都可能被放大成嚴重的問題。比如在某一份設計中，所有的標題都採用24號深灰色的Consolas字體，但是在另一處，字號變成了18，而且加粗了。這種錯誤很容易別識別，從而讓人產生不好的印象。

而對於用錯術語，或者沒有完全理解業務時，對數字的解讀則會產生更嚴重的問題。比如在廣告行業，廣告主比較關心的一個指標是Frequency，計算Frequency的方式是用PV（Page View）/UV（Unique View），也就是每個用戶的平均點擊量。頁面的總訪問量肯定比訪問這些頁面的人數要多（抽屜原理），那麼它們的比值也肯定會大於1。如果UX不理解這個業務含義，可能會在設計稿上標識0.68之類的數字。

類似的，如果你在繪製一個Pie Chart，那麼最起碼所有部分之和加起來要等於100%，而且大致的佔比要正確，比如應該避免出現：數值為25%但是視覺上比例卻接近1/3等等。

對開發者友好

此外，在設計稿中，能為不同的場景設計出相應的變體（variation）也會大大降低開發者和UX之間來回討論的工作量。比如在一個產品列表的設計中，列表中的第一個條目展示正常情況（happy path），而第二個顯示當某些元素缺失時的展現（空值，非法值等），而第三個條目顯示當標題超長之後是應該折行還是顯示省略號等。

每一個細節事實上都在為你的靠譜程度打分，也會潛在的影響別人是否願意信賴並樂於與你一同工作。

小結

文章中列舉了一些實際項目中的例子，有關於如何做好開發實踐的技巧，有關於幫助團隊裡的其他人更方便工作的意識，有關於對開發者友好的設計細節。所有這些例子中的技巧，事實上都與這樣一個事實有關：要在職場中成為一個靠譜的人，意味著即使對團隊內部，你也需要扮演一個專業服務者的角色。你需要更多的站在他人的角度來考慮問題，在合理的範圍內，儘量的減少別人和你合作時的工作量。此外，你需要處理好很多細節，職業性體現在很多的細節中，從測試數據中的asdfasdf，到設計稿中的typo，都可能暴露你是否在用心對待工作。

文中提及的這些值得踐行的技巧事實上與具體技術關聯甚弱，你可以很容易的舉一反三，並在實際場景中靈活運用，成為一個專業而靠譜的職業人。

原文：https://insights.thoughtworks.cn/professional/

閱讀更多 ThoughtWorks 的文章

關鍵字: 工作這一年 浪費時間 添麻煩