筆者這次彙整了這幾年協作常見的問題，也算是做一個記錄。
協作工作常見問題，問與答
Q1：遇到事情忘記該怎麼做?
A：當遇到交代事情紀錄不確實，容易忘，就要做筆記和反覆跟對方確認，確保訊息可以傳達到。
Q2：自己自幹命名衝突的問題，該怎麼做?
A：一個team有一個team日常的默契與用語，就像我們的程式命名規範一樣你只想自己的用自己的說自己的，永遠沒辦法溝通，就像全部人命名規則用，駝峰式命名法，你非要用一個中文命名(創造名詞的，造成溝通的誤差)。
Q3：日常溝通上會有不愉快或是很難傳達訊息，該怎麼做?
A：做法如下…
- 開會前可以先寫在筆記本或是google行事曆列出報告事項與重點，在會中整體描述出來。
- 對不懂的人，要清楚描述引導；對懂的人，則要簡單扼要講出你想講的重點。
- 在討論或是說話的時候必須先思考過，在說出來，減少言語對人的殺傷力。
- 在報告或是表達的時候，要補助白板看圖說故事，或是說重點，把從頭到尾的事情，濃縮重點，並表述的時候，要能夠【聚焦，多用白板，舉例，易懂】。
補充：說出口的每一句話，都會影響自己的人際關係發展。
Q4：常常急性子，導致你溝通困難或是累死自己，該如何改善?
A：從底下開始進行改善，便可以慢慢解決你這些問題
- 做事情千萬不要急性子，要嘗試沉穩，從沉穩當中去解決問題，千萬別為了急性子，擾亂方向。
- 別亂插話，別人在討論的時候，千萬別打斷他人的討論，不管在系統維運或是討論時候，用心地去聆聽與感受對方說的話，等對方描述完之後，再與對方交談，確保溝通和討論的完整性、完善性。
Q5：幫助人也是要看狀況，該怎麼做?
A：在幫助人的時候，要適當的在時機點，機緣到了再幫助，還要懂得察言觀色，對上對下，要懂得揣摩和了解對方彼此，因為太早幫助和尚未了解自己狀況的時候，兩人就會走冤枉路，得不償失。
Q6：軟體上版注意的部分?
A：軟體正式上版的時候，在上版前得必須加入退版流程的考量。
Q7：常常都會怪罪他人的心態，該如何改善，該怎麼做?
A：注意自己對網管與流程知識欠缺和無知的狀況下，勿把錯怪他人與其他部門上，而是要保持溝通與合作把問題解決。
**舉例：很多時候硬體或是跑簽核流程問題，或是職責不明的狀況，而是因為自己對自己網管和Server與設定上的無知下或是職責模糊和流程問題狀況，性子急的狀況，怪罪他人與相關部門是不對。**
Q8：如何知道自己今天做什麼事情，昨天完成什麼，今日目標又是什麼?
A：抽空的時候，記錄今日做哪些事情，以便明日早上review自己的昨天做了哪些事情，能夠進入狀況。
舉例：在EXCEL中列出日期、完成事項、昨日遇到困難、今日目標、工作時數或是用追蹤管理系統管理。
Q9：對上管理與PM或SA關於進度問題，該怎麼做?
A：自己承諾人家開發完成日，EX：PM、SA、SD，如果開發延遲了………請在完成日以前的的前幾天告知，回報SA專案進度與狀況，不然時間到SA才發現你延遲了，等於讓SA裡外不是人，你是在補他刀…….SA也是要對上交代進度的…在時間前幾天回報，是要確保PM或SA相關的人掌握進度的…這牽扯到信任與誠信問題，SA和PM又不是你的蛔蟲，他怎麼知道你開發到哪，問題是什麼哩= =?
Q10：系統一旦遇到重大問題的時候，該怎麼應對?
- 一但系統出現重大需求變更狀況，先了解狀況，不要太著急，先與相關人員與會一起合作討論怎麼解決。
- 遇到系統問題，且不熟的時候，先沉穩，先看，了解，在回應。
Q11：遇到一個程式一堆組在負責和修改的時候該怎麼做?
A：系統向來都有職責與權責的問題，從物件導向程式的角度切入，單一職責分類清楚，是為了明確定義系統範圍與界定。不然通通都變成義大利麵，日後業務擴編的時候職責不清楚狀況會延伸出推皮球，推責任之類的問題延伸，該做的分類與職責還是要區分，必要的時候，還是要懂得說不和拒絕。
Q12：日常開發遇到複雜的部份該怎麼做與應對?
A：程式開發的時候必要時候就要遇到越複雜的程式，越需要職責分離，越要簡化它一但上線之後，要改寫或是重構難度變高。
Q13：查bug異常要留意的部分?
A：查bug異常，要稍微注意看細部業務邏輯運算是否合理，不能只修當下的bug。
Q14：當遇到table盤點或是混合式欄位該怎麼做?
A：有時候遇到盤較大系統或是table schema時候、建議拆成小模組或是一部分table分批進行來完成任務。
Q15：與主管相觸要注意的有那些事情?
- 與主管相處的注意事項：首先要認清誰決定了你這家公司的前途，如果有一個人決定你的考績、調薪、升遷、那個人就是你的主管，主管他可以在職涯他是你助力或是阻力。
- 多觀察，掌握你主管心中那一把尺，EX：有些底下認定讓工作穩定，達到較高品質，主管想的是持續改善，求更高機會，如果員工想法跟主管想法不一樣，可以問問那些被主管升遷，或是主管認為優秀的人，是了解主管要的是什麼之類。
- 很多時候主管不是真正的決策者，必須理解，彈性調整中得到利益的人是你，但為整件事情背書，付出風險則是他。
- 與主管保持良好合作關係，績效不差，工作態度積極主動，公司內有一些人脈，對公司政策保持樂觀，會接近升遷必要條件之一。
工作政治心態調整
在公司常遇到討論時間拉長或是等待和浪費，該怎麼做?
A：調整自己心態如下…
- 很多時候都是在等待、浪費、慢半拍的狀況下，要懂得順勢得讓它走下去，捨棄自己的所期望與實際期望的期待，這樣得失心不會這麼重。
- 做案子如果遇到大軍兵團狀況下，這是很正常，因為過程必須會提出一些意見和未經過整理的需求和資訊，所以很難做有價值和做對的系統，必須要先過整理過和篩選過，在朝向正確的道路方向去進行(這部分有解法是腦力激盪)，如同做Paper的過程是一樣的。
需求問題
常見的需求問題與困難，該如何下手?
A：方法如下…
- 不要讓使用者自己想，當使用者提出構想的時候，我們要整理出一條路和方案出來避免使用者無限擴大，無限擴想和想法。
- 先等使用者提出構想，然後幫他整理出需求，避免擴大需求變更和增加，有時候開發者過多考量，增加多於功能，只會增加BUG。
- 熟悉系統操作面的東西，有時候透過系統操作面的東西和搭配程式開發就能完成問題，例如：切換活動樣板需求，透過後台的頁面設定，時間不同進行切換的頁面。
- 必須要以系統完整性的輪廓去切入需求分析。
- 從整體的需求分析，分析出使用者操作的系統流程，把流程和需求確認必須釐清。
- 細節的問題，先以解決問題為主、當問題解決，再去思考其他問題。
- 系統釐清需求的時候，必須要先請使用者提出流程，怎麼做，在依照怎麼做的方式，提供可行性的做法，和可不可行。
- 當需求提出來的時候，要明確說出，解決方案出來，制定規則出來。
- 當看到文件的時候或是email的時候，需經過整理出來，在撰寫邏輯。
- 誰給你需求，要保留EMAIL的通知與紀錄，口頭的話，請他寄送EMAIL或是會議開完會之後，寄送EMAIL給我。
系統的維運問題
- 先診斷系統有沒有問題。
- 註記：先看資料正確性(再由使用者單位資料修正和調整) 例如：地址當中基隆市中山區調和街(隔壁工地)，地址錯誤請由客服人員修正資料。
- 從系統的log當中看是否有人工介入。
- 多觀察Email，其他IT的人是怎麼回應訂單處理流程，從中去學習know how。
(註記：需求的時候，一定要求email往來確認。)
程式修改注意事項
- 當要異動舊有程式，舊有欄位變更時候，要注意是否有影響到其他程式和其他模組，以及是否有影響到其他人的程式，並確實告知，並進行同步修改和協同作業開發。
- 程式能盡量動態就盡量動態運作，不要寫死程式，程式寫死是非必要才會用。
科學實驗的基本三步驟
- 遇到問題產生疑問。
- 大膽假設。
- 小心求證。
大膽假設不是問題，最重要的是小心求證，結果錯了，前面都是錯的，部分人的慣性是不確定答案或是方向時，就不要猜了，直接問。
測試重點說明
- 程式的格式驗證測試，例如：數量輸入0.5，跳出異常，長度測試、日期格式驗證：例如日期輸入數字。
- 規則測試。
- 業務邏輯的測試，例如：申請日期大於截止日期。
- 如果網站是要加入XSS和SQL過濾函數問題。
- 符合需求的輸入輸出，例如API的參數和輸出是否符合需求。
未來職涯問題
1.如果要考慮主管部分：得找一家夠大夠穩的公司，歷練者五年以上，才能發展到決策層核心，若走顧問路線，得找一個專業顧問，跟他摩個兩、三年，才慢慢轉型顧問。
2.切記：若到財富自由階段想退休，千萬不能辭職，因為一旦辭職退休，就會跟外面脫節，技術脫節，人脈脫節。
補充：財富自由與退休不代表不用工作，而是可以做自己最想做的事情。
