推 littlethe:說到我的難處了,有時候我還在想是不是乾脆就不寫文件 07/27 01:40
→ littlethe:因為人力實在不夠,但不寫文件的下場就很慘 07/27 01:40
→ littlethe:想多徵人,但那要和老闆「好好商量」才行... 07/27 01:41
※ 引述《littlethe (東周小星星)》之銘言：
: 我再講一下狀況好了,
: 我並沒有改變原有制度,
: 因為我的團隊才剛「誕生」,
: 所以要建立制度,一切都剛開始,
: 至於很多人提到的文件...
: 其實我這點很無奈,
: 因為公司其他部門的人不會這一塊,
: 懂的就只有我部門的程式人員,
: 到底文件要誰來寫我很煩惱,
: 硬要其他的外行人去寫系統文件好像更糟糕,
: 所以才覺得是不是要由程式人員兼著寫,
: 我公司裡沒有SA,SE,PM這些職位的人員,
: 頂多有業務人員和企劃人員,
: 但他們都不會寫系統文件
我的做法是乾脆拉一個會coding且會寫文件的人來專職當sa
就負責寫文件 若量太大 頂多請個工讀生幫忙 若者再拉個人上來
但這樣的結果勢必會增加人力成本(多徵coding人材)
如同原po第一篇我就有推文說到
真的要改變效率的話 落實分工制度是最好的辦法
當然 給的薪資也不能低於水準
只是問題是 台灣老闆大多都很摳的
所以一人兼多角在台灣是正常的事.......
自然而然 這樣的狀況就會導致加班加不停
效率太差
: ※ 引述《ericinttu (腿力爆增 XD)》之銘言：
: : 關於加班，可以分析一下是loading不平均或是人手不足。
: : 關於程式改來改去的加班，可以分析為什麼程式需要變動。
: : (Ex: 新的需求、改變的需求、或是Refine codes而造成的結果。)
: : 關於文件，有文件說明當然是好事，但是基於人性考量，必須兼顧到要寫文件的那些人，
: : loading是高或低。試想一位八、九點才能下班的RD，又要再花一些時間去補文件補到上頭所要求的程度，應
: : 該會有反感吧。
: : 關於檢查程式，輸入一般資料看看結果是否正確，再進行bounding test(輸入特殊值看看
: : 是否有異常)，極限/耐力測試，memory leak，再由熟手skim這些程式是否有邏輯上的問題。
: : 這是小弟的粗略見解，還請高手們補充指正。
: : 另外，假如可以有效率地與這些要Coding/寫文件的人進行溝通與討論，讓半數的人理解
: : 這樣的改變對他們是好的的話，原PO的理想會比較順利且持久。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.62.148.44