這學期因為修課的關係，很巧的有兩個team project需要團隊去執行，整個過程雖然不算風風雨雨，但也總是有些不順遂，本想說在社群網站設計的期末展覽結束之後就整理心得，也比較不會忘記當下的想法，不過因為要準備去杭州的比賽以及搬家就先被擱置了，不過在思考沈澱以後，寫下一些筆記也是不錯的。
隊友：
首先，你不得不承認找隊友是件很重要的事情，因為如果找到很強大的隊友他就能將整個專案一手包辦，如此，你就可以很輕鬆的完成這個專案，當然，如果你想要也一起參與這個專案，我想事實的拿出積極度與參與討論都是很重要的，而對於一個專案的需求，會需要不同領域不同能力的隊友也是可以預見的，不過我有幾點覺得應該注意：- 不因為人情選擇你的隊友
- 因為人情選擇你的隊友，往往使得你們在以後會變得更加難堪，在專案討論的時候，從概念的討論到最後的成品，中間的過程中會有無數次討論甚至爭執，如果因為人情選擇了一個不太好合作的朋友，反而會因為這次的合作使得兩個人因概念上的差異直接產生衝突，所以與其一開始因為人員配置的考量而拒絕對方，也不要因為人情壓力而選擇同組，這對兩個人都不會是件好事情。
- 不嘗試去改變對方的想法，認為好的領導就是不管什麼樣的人都可以領導
- Mr. Jamie網誌中曾提過，「其實沒有一個人是壞掉的，你也往往無法改變他人。與其浪費時間在你無法改變的人身上，還不如去找那些願意接受你的想法的人。」，這點我很認同，千萬不要自己為自己可以改變別人，否則當對方依照他的思維模式在做的時候，吃虧的往往是自己。
- 不過份重視過去，但也別小看前科
- 過去的經驗雖然輝煌，但每次的合作有很大的部份還是全新的一個過程，過去的經驗與戰績未必在這次合作中會起作用；但是，也別小看過去對方是否有不良的經驗，或是不好的態度，如果有，還是在找伙伴時就把他檔在門外吧！！！
溝通：
團隊溝通也是很重要的，如果可以還是建議使用專案管理的協助工具（git、wiki）來協助開發，並且定期討論，而每次進度回報最好能夠完成下面幾點的答案：- 甘特圖
- 進度達成度
- 下次預定進度
而除此之外，團隊也要養成將遇到的問題筆記的習慣，可以讓在開發類似性質的專案時，減少自行解決問題的成本。
合作：
這次的合作過程中，很榮幸的能夠和設計的朋友一起合作，而當然也有碰到些問題，其實這次合作的過程中設計師是比較隨和的，也許是考量期末展快近了，很多設計被完成出來時其實不完全能夠達到當初設計的概念，例如距離的誤差、按鈕被碰觸時的互動，但若是設計師跟切版者不能是同一人的話，設計師在出圖的時候最好能夠一起附上：- 原始設計圖：最好是可以模擬瀏覽緝獲者手機上瀏覽時的真實情況，並且考慮不同解析度相容性問題，如果今天解析度過小或者過大要怎麼處理。
- 框架圖：每個元件跟元件間的位置，如果有顏色，也需要將色碼寫在旁邊，越詳細越可以減少切版時的微調成本。
- 動態元件分鏡圖
如果這些東西都齊全了，就只要附上元件圖，如此可以將切版的成本降到最低。
而和程式設計師合作，則是門大學問，市面上有許多書籍在討論，小弟也不夠清楚，不過有幾點我覺得在簡單的專案中可以減少許多溝通成本，以及將討論的時間大幅下降：
- 高內聚低耦合的架構設計，如此除了方便切割每個元件的責任歸屬，如果有想要作測試，這種方式也是比較好測試的一種程式設計技巧。
- 寫文件，沒錯，就是幫自己設計的元件寫文件，每次要趕著作業的deadline時，常常會聚在一起趕作業，但是其實一個程式設計師在自己熟悉、舒適的環境中寫程式的效率是比較好的，大家聚在一起其實是降低了個別的生產力，但是之所以聚在一起是因為「我不知道你寫了些什麼」、「我不懂你程式的流程應該要怎樣串街」等等的問題，而除了真的因為架構比較旁大的元件需要當面討論外，很多時候其實只要將文件寫好供其他開發者查找，就可以解決這個問題了，而在每個元件最基本應該要有的資料最好也獨立處理，例如每個參數是用來做什麼的、回傳什麼東西、回傳的物件是實例還是參考等等的資訊，都可以透過團隊討論制定好統一文件規格來撰寫，如此就可以降低溝通成本了。
以上是我一點心得的筆記，如果有什麼更好的建議或者不一樣的想法歡迎交流。
