大家從事程式開發, 大概很少只有一件工作在手上的.
或常遇到使用者要求我的比較重要, 要先做.
我也遇到過無數次. 也曾和USER鬧得臉紅脖子粗的.
但經過一番寒徹骨, 我漸漸有了心得.
長久來的習慣, 專案或程式排程我通常會如下程序去拿捏:
1.公司賺錢的先做.
2.先進先出.
這個大概沒什麼爭議, 先出現在我桌上的, 我當然先做.
3.需要時間短的先做.
一個需要三天, 一個要三個月.
我通常會先把三天的先完成. 如果一樣都要三天, 那兩件案子就流到下一關PK
4.快結束的先完成.
一件案子這次改完就結案了, 另一件案子這次改完還有要修改的項目.
那我會先把會結案的先完成, 然後結掉.
5. 如此一來, 接到案子心中大概就有譜了, 要排在什麼時間去執行.
這個方法陪我渡過無數個暴風雨.
可以提供給大家做參考.
程式修改分兩種情形:
1.BY CASE: 有BUG及緊急的我會BY CASE. 馬上修改.
2.BY 版次: 程式修改變動很大的. 我通常會多個修改項目一次修改.
程式修改的要領:
我儘量不在USER提出的第一時間修改程式.
我覺得冷靜一下或喝杯咖啡後再想一下會比較好.
我的經驗如果USER馬上說馬上改,
然後馬上通知使用者說改好了.
雖然感覺上效率很好.
到後面再改的機率通常是百分百.
所以我通常會放一下, 再想一下, 再觀察一下. 把每個環節都想通了.
才在關鍵點下手動刀, 通常這樣的結果會動到的程式部份最少.
而且也比較能讓使用者滿意.
沒有留言:
張貼留言