從事程式設計工程師也好幾年了，合作過的程式工程師也很多人，那就再來發一篇我對於團隊合作的心得吧。 一個研發團隊最理想的狀態就是可以互相支援對方對方60%~80%的工作，舉例說，有工程師A與工程師B，不論年資，只單純看能力，若是A對於B負責的功能或專案有80%的熟悉度，反之B對A也有80%，那好處就是當A突然有事請假，那專案進度並不會delay到，又或者業務臨時急件要拿B的專案去demo，那A可以馬上處理解決，這樣可以讓整個team給其他部門有好的印象，不會讓人有這部門怎麼什麼都不行的感覺，當你自己有自覺寫的程式不是代表自己，而是代表整個團隊時，那自己就要主動去跟團隊裡每個同事學一下技術，或了解相關進度，這絕對對自己有好處的(若是你想在短時間內有急速成長，並在多年後成為神(註1)，就一定要這樣做)。 雖然是理想，但在現實上要達成是有很大的難度的，我目前待的研發團隊正面臨這個難題，整個團隊也為了這件事開會討論過，當一個團隊出現了有人能力跟不上，甚至會造成對個團隊進度負成長(註2)，團隊裡就會開始有不好的氣氛，會有人開始抱怨，每個人對於這種負成長根源解決方式不同，我是把android team的人都找出來，之後用引導對方式向那位上班不集中的工程師問他原因，問他為什麼一個功能只要1小時可以寫完，他需要花上1天，並且我也直接跟他表明目前這個團隊需要的是可以跟上進度，有能力學習、不拖累別人的強者，之後他也承認他上班時都在玩，沒有認真寫程式，當然最後也有請主管與他談，後來他向主管承諾會改善，但這問題並發只有一人，別的小組也有這情形，但那位工程師被主管約談之後，他自己也覺得拖累大家，當天就決定離職了。 對於團隊合作，我目前所在的團隊討論了一個方式，大家之後會互相把專案功能切開，並把架構、UI、功能都分離，有人專負責架構，有人UI、有人功能，最終由1人整合，每個人都要有UI的基礎，這是基本的，剛進來不會的人就會先被分配去學做UI+流程，再由強的人去打主架構，然後大家都可以實作功能，功能有相同的可以集中成utility(註3)，整合的人則是要對全部都很熟，要會寫架構、UI、功能、元件，才有能力進行整合並分配各工作，這樣的做法目標就是要讓每個人的能力都可以拉上來跟上團隊，讓團隊可以對專案的研發速度提升。 最後下個結論吧，我目前負