請問一下
軟體工程似乎有些觀念適合拿來管理團隊或公司
例如高內聚: 個人只要專注在本業就好，例如寫web就專注寫web，不要再去碰DevOps
低耦合: 工作上與其他部門的合作越少越好，避免相依太重導致專案延宕
不知道這樣的想法是否正確?

你先定義什麼叫正確

照這種思維，國內的公司都是相反來過的多。wwwwwwwwwwww

大公司就是這樣啊, 不到十人的新創還走這套就沒意義

三四十年前 (我老人味也飄出來了?:p) 那個的日本企業強勢到不行的年代，美國也出了超多在研究日本企業管理方法的管理學相關書籍和研究，像是變形蟲式管理那種，簡單的說就是所有人都跟變形蟲一樣能做所有事 ("所有" 是誇大的行容法啦) 像是總經理看到地板髒了也會順手拿掃把清一下之

上面就多能工，輪調超頻繁，還沒熟練就換下一位，導致所以東西都跟大便一樣

類的奇怪例子，那時認為員工的多工與可替代性是日本企業成功的秘訣，是歐美學不來的，跟你說的完全相法呢 XDDD

不知道是不是台灣受過日本統治的關係，大多都是變

依我鍵盤管理學大師的看法，管理學這東西是官大學問大，你當壓榨員工成功了就變軍事化管理，你靠運氣搭上風潮成功了叫扁平式管理，反正成功了都有話說，失敗了就沒了:p

形蟲式管理，得一人身兼多職，老人越多的公司似乎

要先改掉個人績效評斷方式

只要有邏輯思考前後順序的概念，都很自由適合拿來管理企業

meowyih說的才是真的.成功了就屁也是香的.

你這樣是在建立 silos

Issue tracker:專案管理系統Code review: 電子公文系統Toyota 8d , Google OKR 其他樓下補充

孫子兵法都能拿來把妹了 你說呢

首先，你高內聚的用法就錯了，適不適合還是要看誰來搞

低耦合要看你的層級拉高到哪邊

隕石開發法

台灣很多公司一個人等於IT部門

你已經違反了違反直覺守則軟工中看似直覺無誤的東西 就驗證根本和直覺對幹下一篇 CMMI PMP似乎適合管理公司 然後違反專案定義

我覺得excel更貼近一點

一堆理論要人數夠才適用 有個環節人不夠就破功了

高內聚低耦合 就是以team為單位 而個人就是其中的threead罷了 pool中的其中一個小零件開發法中講的本來就沒有限定在軟體 團隊的運行也包含

高內聚應該是要team內部要有能夠完成專案的所有元素吧

人才是關鍵，不然再好的管理方式都一樣

最好是企管那麼容易一語概括 XDD

Devops 思維拿來執政很適合

台灣軟體業有軟工?從業人員真的體會到hc.lc根本不到兩成

一群好的人不管怎麼管理都可以有很好的產出一個爛的人就能讓團隊天翻地覆

agile是從toyota的方法演進來的吧

新創流行的lean startup也是從Toyota演化來的。

你可以用依賴注入呀，事情都包給派遣公司，反正人他們會搞定

事情有這麼簡單就好了

上面提到與人數有關 實際的確如此 一個project配給的人數過少 scrum那些根本沒屁用 OKR拿來用一用就好

人數少直接幹,人數多,某種程度上我覺得有用...

豐田式管理JIT 是即時消除庫存 agile和這沒關係吧不過看板管理倒是在各行各業都有就是了

底層人是這樣想 不用焦頭爛額 然而老闆不一定是這樣想現代而言生活品質也很重要 除非是好待遇的公司...

人跟軟體比 當然軟體好管多了管理團隊 溝通方式才是重點 技能其次

軟體專案管理