working with pro

和專業的人一起工作學到的重要小事

之所以說是小事，是因為這些小事會引發整個團隊或個人在工作上的不便或缺失。於是小事也有記錄下來的必要

  1. 吃飯時間要固定

    • 原因是你一邊寫 code 還得一邊抵抗飢餓的感覺，再加上血糖降低，容易注意力渙散，這時間寫出來的 code 搞不好就是倒站的原兇。
    • 以及方便團隊其它成員找到你，及安排會議 / 討論。

  2. 早上十一點、下午五點 (吃飯前) 禁止 deploy

    • 原因也很簡單，因為你 deploy 不管是新版本或是新 feature 都可能會有炸掉的情況發生，運氣好的 rollback 就沒事，運氣不好的你還得餓著肚子解 bug，這時候又衝到原則一。於是就杯具了，不停在救火。

  3. 溝通需求 / 交代工作 請善用專案管理系統 ex. redmine

    • PM 或 leader 在溝通需求階段有時候必須要參考開發者的意見 (可不可行 / 有沒有更佳解法) 但這時候把開發者從寫 code 的感覺中打斷是很不智的事。所以應當在專案管理系統建立一個 issue 並將開發者加入監看以便開發者在審票的時候一起判斷。
    • 專案管理系統不只是開 bug / issue 的票，還有 雜項及支援 等性質。有需要和人溝通或協助，票開下去就對了。
    • 清楚明白知道目前哪一項工作踢到誰的身上，不會發生追不到人又一問三不知的狀況。 <!-- more -->

  4. 和有sense的開發者溝通，要以目的導向來描述需求。

    • 這邊說的是清楚交代，「因為怎樣的動機」和「你要達到什麼目的」ex.「我們想要知道每天上站使用者數量，因為想測試行銷的效果好不好」而不是「幫我在後台加一個表單，要顯示每天上站人數有多少」這種沒頭沒尾的需求，因為內行人都知道有太多現成的分析工具可以完成上述目的，但如果需求的動機不表達清楚，開發者還得憑空猜測你是不是因為 XXX 或 OOO 的理由所以要這個 feature 結果半猜半問神的結果就是效果不好又浪費時間。

  5. 時程很重要，到一定的 milestone 就要強迫上線

    • 如果沒有明定一個上線日期，沒有強迫推上某個版本，那就會一直想著「我還要加上XX功能」、「我要做到某某程度」才算是完善。結果就是不斷的被需求蓋過去，永遠無法把產品推給使用者。

  6. 開發功能或問題要被整理過且有先後順序

    • 地基沒有打穩，就不要想把大樓蓋的多花俏，所以基礎建設永遠是第一步。提出需求的人可以把後面的願景想的很好，但開發者絕對不會第一時間就幫你把 fancy 的東西堆出來。

  7. 發生問題就要思考如何解決，而不是讓重複的事情不斷發生

    • 檢討生活 / 工作中遇到的問題，諸如睡不飽這樣的狀態也是會影響工作效率，問題的發生自有原因，就必須要被解決。

  8. To Be Continued

Working Rails Project

Comments

comments powered by Disqus