工做走的累了,不妨停下來,思考一下這一路走來的艱辛。 算一算,我也是工做時間不短的人了。 可是老是感受工做中思路、方法或多或少有問題。 前幾日和朋友幾杯酒下肚,卻是聊出了一些故事,說說本身的感覺,也就成了此文。web
目標&手段——引子面試
先來講個場景,關於電商的秒殺。sql
「大秒活動基本都是在整點進行的,整點活動的詳情頁流量會很是高,爲了保證這麼大的流量不沖垮機器,業內大體的作法以下:後端
從詳情頁開始就作了多層過濾。首先是垃圾請求,普通的電商商品是能夠經過拼http/https下單請求參數直接下單的,然而對大秒來講,若是選擇了答題,題目參數用戶是沒法推斷的,detail會作一層簡單的過濾,將這部分垃圾請求直接攔截掉;接着,因爲人的操做速度限制,一秒幾十次的請求會被系統直接關進小黑屋,進行若干時間的屏蔽;若是流量依然很大,採起了柵欄方式進行限流(此限流方式有運氣成分,平時不會開啓,只有在大促限流時偶爾開啓),在系統約定的容許請求經過時間點起,會進行一個隨機的時間偏移,每一個請求的偏移時間不一樣,若是請求在偏移時間以內,很差意思,運氣很差,須要再重試一次」。服務器
在這個故事中,合適的作法,應該先關注「如何從技術角度保證秒殺能夠進行」,而不是「怎麼讓後端服務器同時頂住巨大的流量」。二者的區別,是目標和手段的區別。若是一開始就考慮怎麼頂住流量,頗有可能就會由於選擇了錯誤的方案,走進死衚衕(好比有可能加數倍的機器以及讓開發同窗被迫去壓榨已經接近極限的性能)。架構
在工做中也同樣,首先須要圍繞目標思考「 要拿到什麼結果 」,再考慮「 如何拿到這個結果 」。這個概念極爲重要,再怎麼重視都不爲過。性能
方向&方案學習
方向是肯定的目標,方案是自由的手段 。測試
城市環衛,目標是保持乾淨的市容市貌,而不是僱傭和管理成千上萬的清潔工,後者只是一種實現目標的方案。3d
日本採起了另外一種方案,就是作好垃圾分類,作好衛生教育,結果卻比絕大部分國內城市作得好。對於清潔工個體,也同樣:能夠選擇早出晚歸勤掃不輟,也能夠選擇多搞幾個垃圾桶,放 在垃圾源邊上。
「無論黑貓白貓,能抓老鼠的貓就是好貓」,是關於「方向&方案」的最好辯證。在這裏,「抓老鼠」是目標,是好貓的標準,而不是長得萌或其餘;在這個標準下,黑貓白貓均可以是好貓。
不管是公司CEO,仍是清潔工,在目標肯定的狀況下,手段的選擇是自由的。清楚這個概念,工做思路能夠開闊不少。能夠問老闆要方向,不要問老闆要方案。方案是本身弄出來的,能想到leader想不到的方案並作出來,就是咱們牛逼,才能體現本身的價值。更進一步,理解目標更能幫你站在leader的角度看問題,才能及時補位,超出預期。
結果&過程
結果是衡量工做好壞的惟一標準,而過程不能徹底拿來衡量工做好壞 。
在業務上,說「用戶是上帝」,說「用戶永遠是對的」,由於「用戶感知是檢驗工做好壞的惟一標準」。一個事情作得好很差,不是由你的出發點、動機和付出多少努力所決定的,而是你的用戶的感知所決定的。以前在前一家公司負責過公司內部系統流程的移動審批接入。上線以後接到很多同事的反饋說體驗很差, 手機打開審批流程慢。老闆找我聊,我也解釋了很多,說做爲審批網關性能實際上和內外任務中心以及下游業務方數據實時獲取都有關,但老闆的意思很明確, 「對於用戶而言,主觀即客觀」,用戶主觀以爲這個產品很差,那就是很差,沒什麼可說的。去想辦法改進纔是正道。另外一個角度來看,只有用戶可感知的,纔是有意義的。這個話我說的稍微有些極端,可是並不是沒有依據。咱們不少人平時都是很忙。早上PRD, 下午技術方案評審,明天kickoff。可是這些只會產生結論,並無產生結果。這些「結論」,用戶都是沒有感知的,並不能讓咱們的產品和服務讓更多人知道,讓更多人喜歡。在這些「結論」產生結果以前,全部的開會、討論、分析,都是無用功。極端一點講,都是成本,而不是成果。
沒有藉口,說到作到
**說到作到,是最大的靠譜 **。
我遇到過不少這樣的場景。身邊的不少同事,包括我本身。老是喜歡爲本身找藉口。咱們老是會說,項目晚上線, 是由於臨時出了bug,是由於臨時有新項目插進來了,是由於對方聯調的同事請假了,而後會把話題轉移到本身有多麼多麼辛苦。
岔開說個小事。我本身不少時候對於時間很偏執。有朋友說過,「全部關於遲到的理由都是不成立的」。因此我老是很在乎時間的規劃。好比我去每次去機場都會詳細的規劃好時間。好比晚上九點半的飛機。那我估計多長時間候機?以往在路上大概多久(好比一路暢通從武林門機場大巴站到蕭山機場須要27分鐘)? 若是晚高峯預留多少時間合適?我須要多長時間能打到車?等等。
總有人說,哎呀,路上太堵,運氣很差連續碰到紅燈,因此遲到了——你老是掐點出門,固然會遲到,不是今天遲到就是明天遲到。你怎麼不提早半小時出門呢?你不能默認一路通暢啊,你應該默認路上會堵啊——作項目,你應該默認有困難啊,怎麼可能預設沒意外呢?怎麼不預備好解決突發問題的資源呢?
困難及不肯定性,是須要咱們克服的東西,不是在開始以前,就預設爲過後「完不成的理由」。一旦有這種預設,就完了,就從一個「行動者」變成「解釋者」了,精氣神就沒了。的確,是有所謂的不可抗力,但99%被稱爲不可抗力的東西,都不是不可抗力。以前有句流行的話,「以大多數人努力的程度,根本還沒到拼智商的地步」。同樣的,大多數人面對的困難和不肯定性,還遠不到不可抗力的程度——還沒「盡人事」呢,就「聽天命」了。
在上一節說過, 「 **只有用戶可感知的,纔是有意義的 **」 。所作的努力和投入,若是沒有最終實現並傳遞到用戶身上,就是成本。沒有完成目標,就是沒有完成目標,沒什麼可多說的。結果導向的意識形態,就是「 **沒有藉口 **」。
從終點出發
小孩子剛學寫文章,老是想到哪裏寫到哪裏;高手寫文章,都是先列提綱再動筆的。
咱們在用手機地圖導航的時候,第一步都是先輸入目的地。而後地圖會給你幾條路線的選擇,再看是打車仍是公交車。這裏面隱藏着一個道理,就是「倒着作事情」。所謂「倒着作事情」,就是在設置行動路徑的時候,從你想要達到的結果進行倒推,而不是根據眼下的狀況決定行動方案。上一節說到,爲了不遲到,就要從上班的時間倒算,來定出門的時間、起牀的時間;而不是先看幾點鐘起牀,再看何時能到公司。
拿咱們程序猿來講,咱們常常犯的錯誤,就是接到一個需求,內心感嘆一句臥槽這很簡單。一個早上的時間便已經寫完調試而後發佈了。結果發生需求變動說要加一個信息本身就懵了, 告訴PD說這個改動很難可能要改動總體的架構。或是當生產環境發生了異常咱們沒有作好足夠的容災結果眼睜睜的看着一個小問題變成了一個故障。這裏實際上是一個基於問題的假設。分析能力的提高,不是學會多少分析的方法,而是掌握正確的分析思路。
跨團隊合做中,結果倒推尤爲重要。主導一次合做,不是等對方完成一個項目,再看下一步,而是應該直接約定好項目節點,推動事情。不是「等你作好這個,咱們再約個會討論那個」,而應該是「下週三咱們一塊兒開會討論結果吧」。這裏有一個好處,就是利用好「 來自目的地的張力 」,以此倒逼本身和團隊,提高效率。
以對方爲準
"溝通最大的問題,在於覺得溝通已經發生" 。這是我現階段遇到的一個很大的問題。
經常聽到團隊關於溝通的抱怨,「我跟A說過這個事情的,可是A太不靠譜了,到如今都沒有作好」。出現這種狀況,一般不是A不靠譜,而是在跟A的溝通中出現了問題。溝通容易犯的錯誤,就是從本身(溝通的發起方)的動做出發,而不是從對方(溝通的結果方)的接收以及接受出發。
舉個栗子。
有次項目, 我在發佈前給項目組發了郵件。郵件中指明瞭某同窗在發佈前須要將本次涉及到的sql初始化腳本在準備預發時提供給我。結果當天我去要的時候獲得的回覆是:「我不知道啊?你跟我講過了?」,我頓時火了:"你特麼不看郵件的?"
相似的還有。打車的時候,司機電話說「我在馬路右邊」,我就會很是惱火,你說東南西北還能夠,我又不知道你的朝向,鬼知道你說的右邊是哪邊啊?發一個通知,說「這個我已經發過羣裏講過了」,這只是「講過了」,卻沒有保證對方已經瞭解狀況,萬一對方電腦壞了呢?「這個模塊的接入咱們已經討論過了,可是無法統一結論」,討論是討論了,可是雙方數據口徑的定義是一致麼?
另外須要注意的是,要資源、要信息,不一樣的目的須要不一樣的溝通方式。對誰講、講什麼、怎麼講?對方瞭解背景知識嗎?對方有什麼樣的立場?對方可能會有怎樣的質疑?我說的對方聽得懂嗎?是直接了當講,仍是旁敲側擊講?是用郵件正式溝通,仍是電話溝通?是羣會溝通,仍是1對1溝通?這些都是溝通以前須要本身問本身的問題,並從對方的角度來得到答案,而不是無差異 的 從本身已經習慣的溝通方式和風格來推動。
溝通最大的美妙之處,在於達成共識;而咱們經常得到的,是已經達成共識的幻覺。正確的溝通,是拓展影響力的最佳方法。溝通中,要確保信息對方已經接收了,在達成共識的過程當中,要確保對方已經接受了——而不能止步於,「反正我已經說過了啊」。
擱置&反饋黑洞
最後來講說我認爲工做中兩件最忌諱的事情。
擱置
遇到問題就擱置,職場第一大忌諱。 某件事情被分配到了你的頭上,你就要把它解決,躲是沒有用的,想方法!哪怕你再討厭,再反感。
反饋黑洞
積極溝通是第一要務。
這件事情我有深入的感知。程序猿相對來講是一個比較沉默孤僻的羣體。咱們大部分人其實不善於溝通。可是我認爲溝通偏偏是工做中的第一要素。不溝通,不主動坦露本身的信息,無論自己實力有多強,在團隊中老是會遇到各類問題。說的狠一點,溝通能力就像木桶原理中那塊最短的板子,嚴重製約着咱們的發展。
結語
結果導向思惟,實際上是「反人性」的。人條件反射的就會從「臨近的」、「熟悉的」、「具體的」起點的角度來思考和作事,而不會從「遙遠的」、「對立的」、「抽象的」結果來進行規劃和執行。
在平常工做中,更好的落實以結果爲導向,就必須事前清晰到極致的明確結果定義,將責任落實到一對一,這樣在過程當中纔不會倦怠和推諉,同時也就能更清晰的對目標和責任的實踐狀況進行準確斷定。作出結果,作出事前定義的結果才能不懼質詢,才能作出成就、實現價值。
作軟件測試的小夥伴們能夠加入313782132,羣內有關於測試的學習資料、面試技巧、內推機會。
嘗試改變,發現不同的本身。