不成文的期望

2021-08-30 03:45:36 字數 2872 閱讀 7260

原文:

1,no surprises

不要有意外。公司裡的一切都是可check的,有特定的人在特定的時間陪你review,這些都在計畫中。乙個比較可怕的事情是火上房頂了才呼救,作為乙個開發者,對於老闆給你安排的工作,你要合理地估計工作量和工作難度(當然在這之前他也會為你估計),搞得定才說ok,搞不定的地方要提出來,老闆好想辦法,比如減少你的任務量,安排其他人支援等,千萬不要等到快「交貨」了才大呼「好難哦,搞不定哦…」,你的解釋是無濟於事的,因為我們相信沒有人會偷懶。而這樣造成的後果很難彌補,因為沒時間去彌補。

2,objective

每個人都有目標,無論是年度計畫、月度計畫還是手頭的工作。要去找老闆談這些計畫,這是你的責任,你要讓他了解同意並支援你的這些計畫而不是他根本不知道,否則最後沒人知道你今年都幹了些什麼,雖然貌似你的task都close掉了。另外,老闆知道了你的計畫他會有一些支援的工作會為你做,比如培訓。

3,refuse

學會合情合理地拒絕。同事之前相互幫忙是很經常的事情,但你得估計自己的時間安排,的確沒問題的時候才說沒問題,並且要在短時間內給你回應。如果暫時不能幫忙時得告訴對方你大概在什麼時間能幫他,以免其無限期地等待,雖然你的卻很忙。實在安排不過來的要委婉的拒絕,以免耽誤人家的工作和讓自己成為不為陳諾負責的人。

4,performs & values

業績與價值觀。公司喜歡那些在這兩方面都表現優秀的人,具體地說就是能有很出色的業績同時要和公司的價值觀很匹配,這樣的人工作起來很快樂,也很容易被提公升。事實上hr要招到乙個價值觀很合適的人比招到乙個業績很強的人要難,所以招人時才有那馬拉松似的面試。打個小廣告:ge的價值觀是:curious, passionate, resourceful,accountable,teamwork,committed,open,energizing。當然任何一家公司都能寫出一長串的標語,但在team內部能感受到這些才是最重要的,ge是這樣。所以如果你發現你與公司value格格不入的話,這可能是工作中沒有激情的主要原因,調整自己或離開公司。這很重要,我覺得這就像戀人之間的性格是否相合。

5,means & ends

方法與目標。同等重要的兩個東西。如果leader們僅僅希望自己的員工們能很出色的完成任務,那可能眼光就有些狹窄了。達成目標之外,我們要考察方法中的各個細節,好的東西要形成流程和規範,以便讓更多的同事按照這套方法能輕鬆達成目標。另外,要整頓流程和規範,可能有的同事會存在工作完成得很好卻挨了一頓批的抱怨,因為你的方法有問題。

6,communicate 「left, right, up, down」

全面溝通。幹得好也要宣傳得好。溝通不僅僅是遇到問題要像對方解釋清楚,也不僅僅是談戀愛似的讓對方給了解你的想法。它同樣是一種反饋,多數情況下人家的看法才是事實。它同樣是一種績效考核,幹了相同多工作的兩個人,人們往往覺得善於溝通的那個做得更多,在團隊中更活躍,更讓人敬佩。別做忙碌的「傻瓜」。

7,hi,how are you today?

今天怎麼樣?一不小心碰到老闆時(在電梯、食堂…),他常常會問這樣的話,很多同事包括以前的我,常常會說「很好」「還不錯」之類的話。那是因為我們不知道什麼是「電梯演講」。老闆平時很忙或是由於我們或多或少有點畏懼老闆,所以沒什麼重要的事情不會去找老闆面談,但電梯演講給了我乙個機會,我們可以用一兩句話簡單概述一下目前的工作進展,遇到了什麼難題,如果有什麼需要老闆協助的也可以能輕鬆地提出來。或者談談很出色地完成了某個工作而讓你很興奮之類的事情。這既可以給老闆不錯的印象也能讓老闆知道他需要在什麼地方協助你或找其他人協助你,而且整個過程很輕鬆。

8,changes

變化是正常的,別抱怨。學過軟體工程的人往往有乙個趨向:做早期工作以應對變化。相反地,當頻繁變化時會引起一些開發人員的抱怨,他們會認為是早期工作做得不好,現在事情才變得這麼麻煩。事情不完全是這樣的,作為開發人員的我們要合理的部署自己的工作以應對變化的來臨(站在coder的角度,沒有變化就沒必要用設計模式了哈),另一方面,變化來臨時,我們應該理解這種變化的合理性並積極主動地迎接變化,而不要心生抱怨。計畫趕不上變化嘛:)另外,抱怨也是極不成熟的表現哦,即便我們貌似很有道理。

9,it』s not my job

相信大家有時(或經常)或聽到這樣的話。但願不是出自你之口。我想說這的確是你的責任。一位顧客想打**給公司客服,不小心撥錯號到我的**上了。當然,我不是客服,這當然不是我的工作。那麼當我拿起**,有幾個選擇:1. 不好意思,您打錯了,然後掛掉。2,告訴他打錯了,幫他轉接,或者在我也不知道正確號碼的同時幫他轉接到前台,或告訴他前台**,讓前台幫他查。選擇二雖然要麻煩些,但如果我選擇一,可能人家就會罵ge員工什麼狗屁素質了。工作中千萬別說「不該我幹,我也不知道該誰幹」。

10,speak out

大膽發言。前兩天一位同事說他以前在一家日本企業工作時,他們開會時基本只有leader在台上講,下面聽評書或是睡著了。太不可思議了,千萬別這樣。ge healthcare是乙個不錯的榜樣,我的會議都需要乙個不錯的facilitator,否則會議很可能成為一場頭腦風暴而偏離主題。積極發言不僅僅能為討論的問題出更多的好點子,也能更好的暴露問題,以及讓人家知道你的想法你在做什麼,如何配合你。乙個反面例子是:開會時不說,到後來發現問題或造成不一致時,人家會反問「開會時怎麼不說!」

上面的僅僅是我的一些個人想法(很不成熟)以及公司前輩的指導,希望大家積極討論與補充:)

11,to be flexible (由anytao兄補充)

不管是對人、對事,在複雜的人際關係和複雜的**關係中,都要適應變通,沒有什麼是一成不變的。變通不代表察言觀色,技術人從來不喜歡委曲求全,我指的是能夠在規則與規矩中尋找更好的解決思路。

不成文的期望

原文 1,no surprises 不要有意外。公司裡的一切都是可check的,有特定的人在特定的時間陪你review,這些都在計畫中。乙個比較可怕的事情是火上房頂了才呼救,作為乙個開發者,對於老闆給你安排的工作,你要合理地估計工作量和工作難度 當然在這之前他也會為你估計 搞得定才說ok,搞不定的地...

初入職場 不成文的期望

初入職場 不成文的期望 周銀輝 很幸運小弟剛畢業就來到了ge healthcare,這裡很多很多大師,所以我無時無刻不在像他們學習著。公司也很多 頭 當然我不是,當我知道在那之前應該做乙個好員工。老闆對你很多期望,有明文的也有不成文的,閒暇起來的時候我也思考過,在這裡和園子裡的大哥大姐們分享一下,如...

軟體程式設計不成文21法則 你認可幾條?

任何乙個有經驗的程式設計師都知道,軟體開發遵循著一些不成文的法則。然而,如果你不遵循這些法則也並不意味著會受到懲罰 相反,有時你還會獲得意外的好處。下面的就是軟體程式設計中的21條法則 1.任何程式一旦部署即顯陳舊。2.修改需求規範來適應程式比反過來做更容易。3.乙個程式如果很有用,那它注定要被改掉...