Post #61

前幾年轉換跑道來寫程式的高中同學，經常會來問我一些技術上問題，最近因為想要跳槽所以正在準備面試時想要呈現的作品。 他給自己訂下了一個簡單的目標，想要在兩週內完成一個簡單的專案，卻沒想到進度比他預想的延後了許多。 之前其實就有觀察到這個現象，他經常會在平日的晚上還在焦頭爛額地去處理工作上遇到的困難，然後很抱歉地再與我約時間求助，後來閒聊了一下發現他與 PM 押定時程的方式很有問題，主要是： • 由於轉職的緣故加上學歷不算太差，不想被人看扁想要好好表現，而給出了緊繃的時程，沒有將 research 與 debug 的時間算入 • 有些 PM 並不具備開發經驗，對於估算時程上面也沒有經驗，會想要儘可能地縮短開發時程來推進專案進度 ___ 後續與他分享了這幾年的一些小小個人心得，也順便寫在這裡，集思廣益一下： [1] 對於之前實作過的功能，我的估算方式通常是 x2 倍時間 [2] 對於之前沒有ˊ實作過的功能，可以與 PM 討論是否先將「驗證可行」與「實作需求」分開，後者通常是習慣的保守時間 x4 倍 [3] 如果押出過長的時程，對方會再限縮，不用一開始就給出太短的時程，倘若對方就真的接受那麼長的時程呢？ [4] 提前完成有許多益處，比如得到信任與讚賞、有餘裕的時間讓自己做其他事或承攬下一個任務，更重要的是也能給予自己正面回饋 [5] 反之；時程押得太過緊湊，延宕不僅造成對方觀感不佳，自己也容易被逼得手忙腳亂，為了滿足期待而更多地壓迫非上班時間 賣的瓜不必保熟呀！ #Thought