Re: [北美] 軟韌體工程師工作型態(ownership與否)

本身做純軟(full-stack偏後) 所以情境有點不同
但感覺大致上有遇過類似狀況 分享一下想法

----

我的組是做產品端的東西 公司大小中等
所以其實就算組裡面一個產品 其實也是包山包海
有前端後端 有offline pipeline 細分下去有不同產品線
都在同一個不到十個人的組裡面

當沒有ownership的概念的時候
就會遇到一些問題：
- 某個東西壞了 誰去修？誰碰過？誰最懂？
-- 常常變成是bandwidth考量 但也就會遇到完全不熟的狀態很痛苦
- 大家什麼都會一點 但是不夠精 因為東西太廣了
-- 做事情的人變成很短視 反正後續也未必是我接手
monitoring / extendability能吃嗎？

有ownership之後能解決的問題就有：
- 有各個小領域的專家跟DRI(directly responsible individual)
能夠很快地指派任務給特定的人 並有效率的解決該區塊的問題
- 該領域DRI會負責整個小區塊的未來發展跟規劃 變成領域專家
-- 建立長遠的roadmap 並且把那些考量放到眼前的專案中
-- 相對有更完整的方式去替自己包裹整體的影響跟貢獻

----

但這樣DRI的制度 最明顯的通病就是
誒 阿這個做資料庫的姊姊如果突然離職了 那不就整塊垮掉？

所以在我前公司做了幾件事情去避免這個問題：
- DRI要有兩層, primary/secondary類似on-call
去避免離職或者primary無暇時還有人幫忙 需要人討論也有個人聊聊
- 有個領域的DRI更容易規劃該領域的文件規劃 將領域資料建檔也是DRI權責之一

----

可以理解原po說的當大家混再一起的時候的好處
但我覺得那樣的好有幾個但書
1. 需要組裡面的人向心力很足 大家都很強也願意互相幫忙
尤其當權責不清的時候 好的組織可以自然吸收消化
但是壞的組織可能就變成各種推拖拉扯蛋

2. 有點回到公司大小的問題
其實講回頭來看我們公司遇到這樣的狀況
很大一部分是因為組裡面要做的事情太多太廣
那通常就是回推到因為公司規模小
每個人都當一個組用 自然會需要各自很獨立的能解決一個領域的問題
但是當公司大到一個程度 一個組的scope變很小的時候
一來也沒啥好分的
二來東西就是這麼多大家都很熟 也都知道彼此在幹嘛
那可能就是同事間搓搓湯圓就搞定了

我個人還是滿認同ownership制度的
只是就像我剛說的 有他的瑕疵需要其他制度彌補
本身這也不是完美 還是也要看組裡面的氣氛, 公司大小跟產品的廣度而定

※ 引述《GPIO (ioctl())》之銘言：
: 大家好。
: 是這樣的，
: 我從2009開始做embedded software以來經歷過三間公司，
: 每間公司在程式開發或維護上面一直都是沒有ownership的概念。
: 一直到去年換了新公司第一次接觸到ownership的工作型態。
: 個人覺得這種方式蠻沒有效率而且某種方面來看對工作分配有點不公平。
: 做了一年下來，興起了換工作的念頭，
: 但是又想說會不會ownership才是目前的主流。
: 所以好奇做embedded software或純軟的各位，你們公司是用哪種方式呢?
: (以美國為主，但歡迎各地的經驗)
: Ownership:
: 如果寫了個process，
: 所有和這個process相關的ticket都會由author單一來負責。
: 不會有其他的人來支援。
: 如果同時負責多個process又同時被PLL增加需求又壓交期，再外加QA開始測試發bug，就: 會有種非常孤立無援的感覺。
: 休假也變成一件很有壓力的事，
: 因為休假期間沒人會cover，休完假的工作量基本都是加倍。
: Non-ownership:
: 只要是同一個案子裡的ticket，同組的人都可以負責，相對的要負責的範圍就會比較廣(d: river, kernel, userspace…etc)。
: 同組的人會一起分攤互相幫忙，
: 並不會說某人只能做某特定的功能。
: 當然依照經歷的不同，
: 總是有些人特別常接critical/P0的ticket。
: 但好處是，因為沒有ownership，
: 資深的人也可以引導較資淺的人做其他的ticket，在旁輔助他們，讓資深的人可以比較專: 注在P0。(無力感也不會那麼重)
: 我個人目前還沒有感受到ownership的好處。
: 總覺得要產品好，開發上要有效率，
: 還是要多人可以互相討論集思廣益，
: 然後可以互相cover配合交期才是。
: 如果大家有不一樣的想法，我也想要聽聽
: 謝謝大家~~

--