Re: [請益] 關於制度,給我點建議吧
會問到下面的這些問題，個人猜測原PO的職位，最少也是個Project Leader，
對公司(最少所在部門)的一些政策，有一定的影響力。
現提出一些實務上的細節，看法，供大家討論一下
※ 引述《littlethe (東周小星星)》之銘言：
: 最近要幫公司想一些制度讓程式順利運作,
: 然後我就在想一些軟體業的不好風氣,
: 我希望可以在我公司不要發生,
: 我在過去公司最討厭的就是無薪無補休的加班,
: 很多還很無理的,
: 有的是老闆因為看到其他公司常加班,
: 所以就要員工「為加班而加班」,
: 也遇過「陪加班」的,
: 老鳥事情沒做完,就凹沒事的菜鳥陪他一起加班,
: 還硬說是為了心理平衡...
以上兩種情況，是公司風氣的問題，如果原PO職位資歷足夠，大可從自己做起，建立
部門風氣為先。
: 但更多是因為程式改來改去,造成的加班,
: 我希望這種惡習能在我手中不要發生,
在實際規劃解決方法前，應該先釐清程式改動頻繁的性質與原因。
一般而言，程式的頻繁改動，會有好幾種情況，但並不一定不好。
舉例來說，採用Exterme Programming開發方式，因為每個開發週期均極短，
同時會有各階段的目標不同，因而會出現頻繁的程式改動。
但這類的改動多半是屬於良性的，通常不應造成開發人員的困擾。
程式多次改動造成困擾的情況，通常如下:
1. 設計暨撰寫品質不良，造成後續不得不對原本程式做大幅度的重整。
2. 客戶需求變更頻繁。
根據原PO所想到的兩個方法來看，很可能這兩種情況，在原PO公司，都很常見。
只是，從文件撰寫，檢查程式兩點下手，是否真能解決問題？
: 我想到兩個方法下手,
: 一個是從文件著手,
: 我真覺得一個公司好不好,
: 看文件就知道,
: 文件一開始就寫得很清楚,
: 事情就做得越順利,
: 文件一開始就偷懶,
: 寫得草率,
: 後面就會做得亂七八糟,
: 業界常見的做法是文件別人寫出來,
: 然後丟給程式,
: 但我認為這流程要改變,
: 因為非程式人員幾乎是不會寫系統文件的,
: 寫出來幾乎不能用,
: 所以我想說這文件部份就由程式人員自己寫,
: 寫完再和別人確認是否要這麼做,
: 寫得簡短無所謂,
: 只要寫得具體,
: 看得出功能就好,
: 這樣可以提升文件的水準,
: 由執行者寫,也可以確保文件寫的東西可以做得到,
從上面這整段來看，原PO的文件，應該是指規格書，功能要求表之類的文件；
而且大多是由Sales或PM根據客戶的需求加以撰寫，再交由RD實現。
在這種情形下，如果將撰寫規格書的責任，交予RD，立即可見的問題是：
貴公司的RD，有多少時間，能去瞭解客戶的需求?
說明白一點，這種要求，等於要RD兼任Sales和PM或是FAE的角色，最後的結果，恐怕是原本
每天加班到9:00，變成要加班到凌晨。說不定回到家裡，還得繼續處理客戶打來的電話。
回到原PO的問題，從上面的述敍來看，恐怕貴公司實際上需要的，並不是將文件交由
RD去處理，而是要想辦法增進RD與PM/FAE間溝通的效率。讓客戶的需求，能確實的傳達
給RD，同時，也讓客戶瞭解目前貴公司的技術能處理到什麼地步。
如果，貴公司的PM與RD之間的溝通沒有問題，是因為客戶需求變動頻繁，導致加班，
那麼，請把合約與規格書拿出來，請你們的Sales與對方講明增加的成本，
不要什麼都照單全收才是真的。
: 第二個就是要檢查程式,
: 很多公司的老闆或主管會覺得過程「不重要」,
: 以為只看結果,就可以看得到結果,
: 我看到不管過程,不看程式碼的結果,
: 下場都蠻慘的,
在做code review時，其實結果已經出來了。其實以原PO的要求而言，
個人覺得下列幾項才是對貴部門幫助較大的。
1. Design preview/review。
2. 要求寫Pseudo code，最好能將Pseudo寫成Comment,或是in-code document格式。
3. 部門或公司一致的Coding convention.
第一項的時間成本，通常會比較多，但第二暨第三項，對大多數的公司來說，都不會
花費太多額外的成本。
其中第三項，通常也是做code review時檢視的大宗。
(從過去的經驗來看，1,2兩項有落實的話，程式的結構，寫法，在code review
時是不太有機會去改動的，如果code review後發現需要大幅度的改動，
那可能要回頭檢討一下開始時的設計流程)
: 所以我認為「惡魔藏在細節裡」,尤其程式碼這種東西,
: 一開始寫不好,後面就「連環炮」,
: 所以我希望可以嚴格的規定程式要怎麼寫,
: 因為真的很多人程式是亂寫的,
: 習慣很不好,
: 甚至寫10年程式的老鳥也會亂寫,
: 後面要debug時就很痛苦,
: 對於程式碼我真的不放心任由別人「自由的去寫」,
這裡，得要請原PO舉幾個例子，讓大家瞭解一下"亂寫"的程式，到底是怎樣的亂寫法？
不然很難給予建議。
: 我是希望這兩件事,可以讓我們公司的程式寫出來是很順利很有品質的,
: 這樣就可以減少加班的機會,
: 甚至根本不用加班,
: 也能順利讓案子準時做完,
: 不知道大家對我這樣的想法有沒有指教的,
: 或是有沒有其他制度上的建議可以讓我參考一下呢?
另外提醒一下，改變制度也是要成本的，這成本不能光是以RD的角度來考量，特別是
有能力改變或是提出建議的人，通常層級會比較高，在看事情時，必需要多參考不同
的角度。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 118.168.80.66
※ 編輯: atst2 來自: 118.168.80.66 (07/25 17:53)
討論串 (同標題文章)