Re: [閒聊] 最後一根稻草... 嗎?
最近常在思考一個問題:
如果 programmer 寫出來的東西是可以輕易找人接手替換
還有需要進入如此繁複的軟工流程嗎?
如果專案本身需要相當高的門檻
一般制式化文件能帶來多少幫助?
其付出的代價和得到的效益是否划算?
當然, 管理者總是希望手下的人沒有一個是無可取代的
但是若專案本身是一堆隨時可替換的人可完成的
是否因為沒有利用更有效的工具, 或更有效的開發方式來減少人事開銷?
--
看不懂愛因思坦的相對論
到底是我程度差還是他寫的不好?
※ 引述《Lapha (lapha)》之銘言：
: 分享一些個人看法:
: 建立一個這種團隊, 並不應該仰賴各成員的工作互相overlap來達成, 因為這是
: 十分不經濟的作法(不只就人力運用而言, 抑或是溝通協調而言)
: 要達成這個目標, 個人認為關鍵在將各成員的輸入、產出進行標準化、規格化,
: 這樣子要抽換任一個成員的成本將會相對降低, 一旦完成這個工作, 溝通協調的
: 問題自然也不會產生, 因為不管是誰來接, 都能很快上手。簡單地說, 就是將各
: 成員當成一個模組來使用。
: 當然這麼做還需要別的條件:
: 首先是成員能力的鑑定和培養, 我們不能把釘子塞進螺絲孔, 然後還希望他能正常工作,
: 找來接手的人, 必須能勝任這個工作, 這樣這些規格化的輸入、輸出對他才有意義。
: 另外, 誠如原po所言, "..把人壓在電腦前, 寫的東西能不能用是另一個故事.." 就實際
: 執行而言, 面臨的另一個問題是: 我們可以訂出一堆表格、一堆文件, 要求大家去填寫,
: 但是, 如何保證大家確實填寫?
: 這是知識產業和製造業在管理上一個很大的不同點, 對知識產業而言, 要去驗證另一個人
: 的成果, 某些時候, 幾乎得把他的工作拿來重作一次。當然不是每一次, 但偶爾會遇到
: 沒有快速驗證法的case時, 你總得先有答案, 才能去評斷手下成員做對還是做錯
: (比如說, 你想知道手下RD的註解有沒有亂寫, 你除了乖乖去看code, 逐一檢視外, 好像也
: 沒什麼好方法了 :p)
: 就這方面而言, 似乎又回到了工作必需overlap的老路上, 但不同的是, 這是屬於稽核性質
: 的overlap, 就管理者來說, 他可以隨機抽樣去驗證, 而不是要求各成員每天必須互相去
: sync. overlap的工作範圍。
: 建置這種團隊, 是很不容易的, 因為這大大加重了管理階層的工作量: 從各成員工作項目的
: 輸出、入介面定義到各成員的能力判定、培養, 到最後的稽核驗證，以上還不包括管理者
: 自己原有的日常工作內容。
: 所以, 我們不常看到這種團隊, 相反的, 倒是常看到 "RD挾程式碼以令老闆"的戲碼上演 XD
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 61.224.48.155
討論串 (同標題文章)
以下文章回應了本文：
完整討論串 (本文為第 5 之 15 篇)：
Soft_Job 近期熱門文章
PTT職涯區 即時熱門文章