職場筆記(NEW)

職場筆記

職f涯地圖發展

https://dotblogs.com.tw/regionbbs/2011/12/15/62133
團體工作注意事項

1.交代事情紀錄不確實,容易忘。

2.你永遠要記得, 不只這裡, 外面也一樣, 一個team有一個team日常的默契與用語,

  就像我們的程式命名規範一樣你只想自己的用自己的說自己的, 永遠沒辦法溝通,

  就像全部人命名規則用,駝峰式命名法,你非要用一個中文命名(創造名詞的,造

  成溝通的誤差)。

3.凡是在討論或是說話的時候必須先思考過,在說出來,減少言語對人的殺傷力。

4.做事情千萬不要急性子,要嘗試沉穩,從沉穩當中去解決問題,千萬別為了急性

  子,擾亂方向。

5.別亂插話,別人在討論的時候,千萬別打斷他人的討論,不管在系統維運或是討

  論時候,用心地去聆聽與感受對方說的話,等對方描述完之後,再與對方交談,

  確保溝通和討論的完整性、完善性。

6.在幫助人的時候,要適當的在時機點,機緣到了再幫助,還要懂得察言觀色,對

  上對下,要懂得揣摩和了解對方彼此,因為太早幫助和尚未了解自己狀況的時候,

  兩人就會走冤枉路,得不償失。

7.表達和溝通要不斷的學習。

8.軟體正式上版的時候,在上版前得必須加入退版流程的考量。

9.對不懂的人,要清楚描述引導;對懂的人,則要簡單扼要講出你想講的重點。

10.注意自己對網管與流程知識欠缺和無知的狀況下,勿把錯怪他人與其他部門
    上,而是要保持溝通與合作把問題解決。

    EX:很多時候硬體或是跑簽核流程問題,或是職責不明的狀況,而是因為自
             己對自己網管和Server與設定上的無知下或是職責模糊和流程問題狀況
             ,性子急的狀況,怪罪他人與相關部門是不對。

11.抽空的時候,記錄今日做哪些事情,以便明日早上review自己的昨天做了哪
    些事情,能夠進入狀況。

12.自己承諾人家開發完成日,EX:PM、SA、SD,如果開發延遲了.........
    請在完成日以前的的前幾天告知,回報SA專案進度與狀況,不然時間到SA才
    發現你延遲了,等於讓SA裡外不是人,你是在補他刀.......
    SA也是要對上交代進度的...在時間前幾天回報,是要確保PM或SA相關的人掌
    握進度的...這牽扯到信任與誠信問題,SA和PM又不是你的蛔蟲,他怎麼知道你
    開發到哪,問題是什麼哩= =?

13.一但系統出現重大需求變更狀況,先了解狀況,不要太著急,先與相關人員與會
    一起合作討論怎麼解決。

14.系統向來都有職責與權責的問題,從物件導向程式的角度切入,單一職責分類清
    楚,是為了明確定義系統範圍與界定。不然通通都變成義大利麵,日後業務擴編
    的時候職責不清楚狀況會延伸出推皮球,推責任之類的問題延伸,該做的分類與
    職責還是要區分,必要的時候,還是要懂得說不和拒絕。

15.程式開發的時候必要時候就要遇到越複雜的程式,越需要職責分離,越要簡化它
    一但上線之後,要改寫或是重構難度變高。

16.查bug異常,要稍微注意看細部業務邏輯運算是否合理,不能只修當下的bug。

17.有時候遇到盤較大系統或是table schema時候、建議拆成小模組或是一部分table
    分批進行來完成任務。

18.在報告或是表達的時候,要補助白板看圖說故事,或是說重點,把從頭到尾的
    事情,濃縮重點,並表述的時候,要能夠聚焦,多用白板,舉例,易懂。

19.遇到系統問題,且不熟的時候,先沉穩,先看,了解,在回應。

20.與主管相處的注意事項:首先要認清誰決定了你這家公司的前途,如果有一個人
    決定你的考績、調薪、升遷、那個人就是你的主管,主管他可以在職涯他是你助
     力或是阻力。

21.多觀察,掌握你主管心中那一把尺,EX:有些底下認定讓工作穩定,達到較高品質
   主管想的是不段改善,求更高機會,如果員工想法跟主管想法不一樣,可以問問那些
   被主管升遷,或是主管認為優秀的人,是了解主管要的是什麼之類。

22.說出口的每一句話,都會影響自己的人際關係發展。

23.很多時候主管不是真正的決策者,必須理解,彈性調整中得到利益的人是你,但為整件事情
   背書,付出風險則是他。

24.與主管保持良好合作關係,績效不差,工作態度積極主動,公司內有一些人脈,對公司政策
    保持樂觀,會接近升遷必要條件之一。

25.不要溝通的時候採用討好和委屈求全方式。

26. 我在聽人家對方描述和需求的時候,沒有搞清楚,嚴格來說,是只聽我自己想要的關鍵之類,其實有遺漏出其他更重要東西。

27.(26,18結合):在聽別人描述與需求,會有可能遺漏需求狀況,透過聆聽的方式,遺漏狀況,可能表達出來的可能文不對題,無法聚焦,可以多記錄、多整理、在說出。

28.表達力與邏輯力問題。

29.要有高超能力,但同時保持低調姿態,通常用來描述一個人有優秀技能和專業知識,但並不張揚自己的成就,而是謙虛態度對待自己工作與貢獻。

30.一個人有很高的能力,它們往往有更多經驗與智慧,能夠了解世事變化,這種對事物的深刻理解會讓它們更加謙虛,不會因為自己成就而驕傲自滿,反之如果一個人如果沒有太多能力和經驗,往往會更加自負,甚至自以為是,以至於不能夠正確看待自己的地位和貢獻,再依定程度上能力越高,姿態就越低調。

 

工作政治心態調整

1.很多時候都是在等待、浪費、慢半拍的狀況下,要懂得順勢得讓它走下去,捨棄自己的
  所期望與實際期望的期待,這樣得失心不會這麼重

2.做案子如果遇到大軍兵團狀況下,這是很正常,因為過程必須會提出一些意見和未經過
  整理的需求和資訊,所以很難做有價值和做對的系統,必須要先過整理過和篩選過,在
  朝向正確的道路方向去進行(這部分有解法是腦力激盪),如同做Paper的過程是一樣的

28.系統操作手冊,要寫得很白話,要一步一步的寫,步驟方式寫非IT的人看得懂
 

29.專注自己工作,態度應該要等別人來求助和請益才回答!

重構問題

1. 你不應該去動別人開發中的 code, 除非 pair 或你是有被授權的人.

2. 你可以使用他的 code , 建 common, 但你不應該改回他的部分(理由1).

3. 假設改完會有衝突, 那表示你做的不是重構.

4. 如果完成再重構會花更多時間, 那表示你做的不是重構.

5. 你要用他的 code , 跟你要整理重構, 是兩回事.

所以你要先搞清楚你要做的事情, 是解決你的事情,
還是幫別人改(你未必有取得授權的) code.


你拿別人的東西, 改成自己能用的 common lib,
用自己的 common lib, 這樣基本上應該不至於被靠北.

但去動別人正在開發的東西, 說穿了, 你知道人家在幹嘛嗎?
你權責上能對人家時程負責嗎?

或說穿了, 你可以負起 fix conflict 的責任嗎?


另外有個版友說重構是農閒的事情,
其實重構是越忙的地方越需要, 因為會忙通常就是沒在重構,

但是這篇原文講得並不是重構,
而是在僭越職責的前提底下自作聰明改別人的程式碼.


厲害的人應該是會抽出正確的 common,
當A 跟B都做完的時候, 拿 common 套回去不會很久的.

會被開發拖著走的 common, 表示需求根本就還沒穩定到可以共同重構啊.

 

 

需求問題

1.不要讓使用者自己想,當使用者提出構想的時候,我們要整理出一條路和方案出來
  避免使用者無限擴大,無限擴想和想法。

2.先等使用者提出構想,然後幫他整理出需求,避免擴大需求變更和增加,有時候
  開發者過多考量,增加多於功能,只會增加BUG...。

3.熟悉系統操作面的東西,有時候透過系統操作面的東西和搭配程式開發就能完成問題

  例如:切換活動樣板需求,透過後台的頁面設定,時間不同進行切換的頁面。

4.必須要以系統完整性的輪廓去切入需求分析。

5.從整體的需求分析,分析出使用者操作的系統流程,把流程和需求確認必須釐清。

6.細節的問題,先以解決問題為主、當問題解決,再去思考其他問題。

7.系統釐清需求的時候,必須要先請使用者提出流程,怎麼做,在依
  照怎麼做的方式,提供可行性的做法,和可不可行。

8.當需求提出來的時候,要明確說出,解決方案出來,制定規則出來。

9.當看到文件的時候或是email的時候,需經過整理出來,在撰寫邏輯。

 

        (例如:刮刮樂的每日交叉折價券的邏輯)

10. 誰給你需求,要保留EMAIL的通知與紀錄,口頭的話,請他寄送EMAIL
     或是會議開完會之後,寄送EMAIL給我。

11. 網頁上的(正常運行)https://  發現按下搜尋沒有,在撈的資料有可能有http:// 才導致沒有 https://
 

 

 

 

系統的維運問題

先診斷系統有沒有問題
註記:先看資料正確性(再由使用者單位資料修正和調整)     例如:地址當中  基隆市中山區調和街(隔壁工地)    地址錯誤請由客服人員修正資料。
.從系統的log當中看是否有人工介入。
假設  1.說明SOP   2.人工判斷   3.廠商判斷   取決於流程know how了解。
多觀察Email,其他IT的人是怎麼回應訂單處理流程,從中去學習know how。

(註記:需求的時候,一定要求email往來確認)

 

 

 

程式修改注意事項:

1.當要異動舊有程式,舊有欄位變更時候,要注意是否有影響到其他程式和其他模組,
  以及是否有影響到其他人的程式,並確實告知,並進行同步修改和協同作業開發。

2.程式能盡量動態就盡量動態運作,不要寫死程式,程式寫死是非必要才會用。

 

科學實驗的基本三步驟
一、遇到問題產生疑問
二、大膽假設
三、小心求證

 

大膽假設不是問題,最重要的是小心求證
結果錯了,前面都是錯的
慣性是不確定答案或是方向時,就不要猜了,直接問

 

 

測試重點說明

1.程式的格式驗證測試
  例如:數量輸入0.5,跳出異常,長度測試
  日期格式驗證:例如日期輸入數字

2.規則測試

3.業務邏輯的測試,例如:申請日期大於截止日期

4.如果網站是要加入XSS和SQL過濾函數問題

5.先符合user最簡單的輸入跟輸出

 

 

 

 

 


未來職涯問題

1.如果要考慮主管部分:得找一家夠大夠穩的公司,歷練者五年以上,才能發展到決策層核心,
  若走顧問路線,得找一個專業顧問,跟他摩個兩、三年,才慢慢轉型顧問

2.切記:若到財富自由階段想退休,千萬不能辭職,因為一旦辭職退休,就會跟外面脫節,技
  術脫節,人脈脫節

老E隨手寫