Re: [閒聊] 大家公司會有喜歡分享知識的人嗎
我覺得軟體服務業並不在意技術的分享與交流，
我的同事也很熱於分享『技術』
因為有時候為了搶快做出來的10萬行程式，
也只是免洗工程師們趕工出來的卡位工具，
裡面可能只是1000組的SQL存寫副程式
對軟體服務業來講，服務模式才是不能分享的知識，
工程師要做coding的交流...更好，
甚至不要搞什麼分享了，趕快找人幫忙寫一寫，
趕快讓公司做系統整合、上線最好
那同事之間的分享呢？
由於我待的是軟體組合...整合業，
也沒有什麼高端的技術秘密需要、可以分享
因此平常除了會偷藏別間公司正妹美工、PM、助理的資料外，
『技術』資料的分享可以說是非常熱烈
所謂的技術資料分享，
就是我copy我的code給你paste、你讓我copy你的code...
整個專案就在人工耦合工程下完成了
今天早上剛好寫了一篇感想文，
講的是公司和公司之間在專案需求的分享
裡面沒什麼重點，可以按 ← 或是 end 跳過
【為什麼我的軟體模組供應商總是要重新討論需求？】
你拿著完工的規格書給軟體模組的供應商、外包商，然而你的供應商卻不厭其煩、
積極的想反過來瞭解功能需求，他們放著規格書裡面現成的、清清楚楚的API規格、
介面定義不看(有API規格和系統限制，基本上就可以開工了)，反而願意花時間陪
你閒聊、想要拿到你手中的story card，為什麼呢？
因為規格書只是技術性的資料而已，而且大部分的動作、資料、參數規格在釋出
之前，都經過一定的變更程序，來掩飾這份規格和前後系統、專案的關聯性。
也就是說供應商如果只有一份開發的規格書，對他們來說就是把暨有的技術、
零件組裝而已，無法從專案學到東西、或是從你的身上撈到經驗。
對軟體模組供應商而言，產業經驗、領域知識(domain knowledge/ know-how)才
是真正重要的資產、與能力累積的關鍵，否則單純地照規格開發一個軟體模組，
就只是拼積木的勞力工作而已。
但是藉由反向(透過你)去瞭解需求規格，不但可以還原API介面、參數的真實意
義，更重要的是可以瞭解，這個模組究竟是寫給什麼系統使用的，系統的商業應
用、產業位置又是什麼，以及要推展到哪塊市場、要怎麼賣/賣多少，也就是透
過反向建立小小軟體模組的功能需求，來看到商業模式。
所以當你的供應商想要再搞一次需求分析/訪談、需要什麼應用情境/應用案例的
時候，也許對方並不是真的看不懂你的規格書、系統設計文件...。或是他們熱
心地要幫你將前後端、上下層模組也完成的時候，也並不單純只是想要多賺點小
錢，而是要藉由專案開發，找到滲透產業鍊的位置。
(如果你的供應商是高中生、大學生、上班族兼差團隊，
也許他們真的只是想多賺點錢)
但是不要忘了，在這個需要打團體戰的資本主義商會社會下
(其實我不太瞭解這是什麼)
學會如何利用人與被人利用是很重要的，因此身為一個PM或是偷偷對外發包的工
程師，在將公司的產品(部份)委外的時候，如何衡量、取捨公司利益與委外夥伴
的關係，我覺得是用智慧型計算求區域最佳解的有趣題目。
(正常的八股結論應該是「實在是PM與營運主管需要深切研究學習的課題」...吧)
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 180.217.30.234
推
11/20 23:37, , 1F
11/20 23:37, 1F
推
11/21 01:43, , 2F
11/21 01:43, 2F
→
11/21 10:45, , 3F
11/21 10:45, 3F
討論串 (同標題文章)
完整討論串 (本文為第 8 之 17 篇)：