Ask Questions

發表於： 2023-06-30 分類於：筆記

字數： 1537 閱讀：≈ 4分鐘瀏覽：

如何問問題

問問題模板 1

實際的需求
- 你的原始需求是什麼？
遇到的問題
- 你已經做了什麼？知道了什麼？
- 你查過什麼資訊？
自己的想法
- 根據這些資訊，你還有疑問的部份是什麼？
想法下的關鍵字
查到的結果執行的畫面、指令
- 發生了什麼樣的錯誤
- 錯誤的畫面(有的話)
- 錯誤的 log + stacktrace(有的話)
- Browser F12 的錯誤 (有的話)

問問題模板 2

請提供問題描述
請提供複製問題的步驟
請提供預期結果與當前結果

Debug四重奏

告知他人你原本預期到什麼效果，但目前得出的結果如何，和預期有多少偏差。
請附上主要你認為出錯的code，如果不確定哪一段出錯，就把全部弄上來並標上註解。
附上的圖片請傳高解析度的，且影像方向擺正，不要讓幫忙的人得歪頭歪腦，還要當偵探破解你的低解析圖，以及善用電腦截圖，手機拍電腦螢幕會有摩爾紋加反光，我們不是來辦案的，沒有專業偵蒐工具。
明確告知你已經掌握的基本訊息以及你曾經嘗試過的解決辦法，並且提供方向給幫忙者。

問問題的技巧

問法的重點是，你要先有一個自己理解的版本，拿去跟人說一遍，可以省去對方的時間，你也獲得展現自己理解的機會。請人請你 “debug” 那些想法不太對。通常會被冷處理的是，手一攤什麼都不懂的，想讓人從頭講起一大部分，或對某一個 module 完全不懂，自己猜都不猜，試著提一個版本出來。
如果對整理苦手，推薦先由 sequence diagram 把主要的資料流或 method call 畫出來討論。
在前公司時，有一次做新人 training 就拿現有的 seq diagram，開 debug 跟他對每一個流程，慢慢解說，錄影起來，叫他每天快下班前的一二小時先熟悉流程，能講到跟我差不多的內容，解說的重點有對。大概一週就對整個東西有 80% 的理解了。去掉 syntax 有些不太熟的猶感，大致上可以順利上手
如果他摸半天，又沒有能符合 code reviewer 的期望，那其實是我們沒有告訴他期望的樣子。被火掉又要進去漫長的找人流程我到沒那麼崇高的理想，我缺人，然後只有一個剛畢業的菜鳥，就試看看吧。 (雖然，他抗壓比較低，偶爾要跑去哭哭) 但漸漸有吸收，能消耗任務分配，就及格了
其實到「資深」的話，我覺得要放一點心力在整 team 的輸出有沒有總量上的提昇，不會只專注自己的輸出有沒有繼續變高。所以，增加總體的輸出，讓可以吃下的 story point 變高。短期內速度可能略降，但中長期速度是會提昇的。
劈頭就問這是幹嘛的，有些人會瞬間起防備之心，應該要先稱讚他作為開場，然後再問這個function當時設計的原因，問完再跟他表示感謝

如何練習問問題

先學會怎麼問問題 google【提問的藝術】不然別人就算想幫你也不知道要怎麼幫
問自己現在會什麼東西能做到什麼程度目前可用的資源有哪些(買書、買課程、親友、社群等等)
想學什麼技能? 答案可以透過一次次的面試慢慢得出來，不過要有被洗臉的準備，但跟原本的目標比起來這不是很重要，重要的是這個過程你要自己去歸納自己想做的工作到底需要哪些技能當然，你要自己願意踏出來，不然沒人救得了你
學會安排自己的時間，然後試著用甘特圖畫出來(不會就去google學，沒很難，而且未來在參與專案上你早晚要會用)
用甘特圖把自己預計要會的技能列出來，然後照著自己安排的時間走(既然是自己安排的時間，就要盡量做到，否則你隨便訂一個技能就估2,3個月，這沒什麼意義)
不要拘泥在同一個問題上太久，如果是基礎的問題，就自己去利用資源把基礎打好，比較難的問題可以先記在一個清單上然後先略過，因為重點不是你做了什麼東西出來，而是你從中學到了什麼