一年來很少寫日誌，更多地是項目開發和研究他人的經驗和知識。
做開發4年來，給我一個總體的感覺是痛苦並且快樂着。相信很多朋友和我一樣，解決了一個棘手的問題，更有甚者這個問題他人不能解決時，成就感油然而生。至於痛苦的方面，這可能和他人不同，我很少會爲不能解決的問題而困惑，更多的是來自於團隊合作和團隊工作質量。有時候，會對隊友很失望，無論是經驗程度，還是處理人事的方法。
對於軟件開發，筆者一點體會，簡單地說，爲了一個共同的目標，一個或多個團隊相互合作，產生一定“結果”的社會過程。個人偏好地認爲是一種過程，通常來說，由項目立項、可行性分析、需求分析、架構設計和技術選型等等。在不同的場合，這些過程增加或者減少。無論怎麼樣的變化，其決定性因素的還是人，處理好人事等於成功了一半。在軟件工程，沒有最好，只有更好，永遠牢記着只做正確和適合自身的開發方法，儘量不要教條主義和理想主義。筆者曾經就犯過錯誤，嚴格地按照敏捷那套執行，開始就遇到了同事的反對，理由是他不能理解，執行起來困難重重，照搬是不行的。
萬事開頭難，尤其是軟件項目，把握需求是困難的，一般而言，很難做到所有的需求細節一一列出，只可能在一個相對抽象的需求上不斷地“演化”，甚至發生變化。開發人員最苦惱的地方莫過於需求變遷所帶來的反覆開發或者修改，所謂的“Change is welcome"，那是“Communism”。若要把項目致力於靈活多變，無疑是困難的。從事多年開發的同仁會感覺，如果有一個不需要編碼，只需要簡單配置，能夠完成需求，那該多好。不過，據我所知，不管模型化建模，還是代碼自動產生器都不能很好完成需要，畢竟需求是各異的。
找不到理想中的“烏托邦”，最終還是回到現實。重擔還是落在開發人員身上，開發人員面對“脆弱的”需求，尤其是架構師團，更需要抽象業務邏輯，構建需求的藍圖和界限。筆者認爲成功的架構師是務實的，我見過不少“理想主義“的架構師，寫出來的方案有點像“八股文”，甚至一些方案在實際情況中是“死衚衕”。
架構設計並不是越抽象越好，更不是越技術先進越好，成熟大於高新，務實大於花哨。
說句題外話，我看到過很多同學，尤其是初出茅廬的，在簡歷上面寫了不少的“高新”技術，動不動就是“精通”的字樣，有經驗的HR看都不會看這樣的簡歷。反思一下，爲什麼不少公司招聘信息註明，行業經驗優先考慮。不難看出業務理解優先於技術實力。技術是要落到實處來解決實現的問題的。好比鈔票，如果不流通，它就是廢紙。
架構設計和技術選型之後，詳細設計，一個和客戶或者和開發人員內部討論過程，無論你的角色是什麼，溝通的素質是必須的。作爲開發人員，要了解自己的輸入和輸出。作爲項目經理，需要合理安排人力資源和協調團隊，同時和客戶互通。
人力資源安排是一門大學問，首先需要了解團隊人員的素質，主要是技術實力和需求理解能力，其中需求理解至關重要。
項目經理好比軍隊中的“帥”，架構師好比“參謀”，開發人員則是前線將士。團隊的執行力，往往決定項目的成敗。首先，需要了解部下，一個穩定的團隊是相當重要的。衆所周知，IT行業是一個流通性相對比較大的行業，尤其在時間拮据的情況下，大多數通過面試手段來招募賢士，少數則是通過推薦。無論哪種方法，在短期內，知人善任是困難的，項目經理很難全面的瞭解開發員的才能。筆者就遇到了這個問題，開始覺得挺不錯，感覺後來越來越差，人才真是鳳毛麟角。當項目進行到一定階段的時候，臨時“易將”是不明智，重新招募和培訓新的員工，無論是時間成本還是人事處理都是不合適的。一個權宜的方法就是培訓員工，因爲技術和素養是可造的。一些上了年紀或者有家庭的員工很難進行“培訓”，其興趣和精力不在於此，處理這樣的問題比較棘手，至今效果不理想。
事情不能改變的時候，只能適應其規律。
接下來，溝通和協調團隊。它是雙向的，逐漸地瞭解隊友的習慣和素質，合理地安排任務的分配。筆者舉一個二期開發項目的例子，見到的一個常景就是，各個隊員開發個自己的小模塊並且保留接口，接口之間可用性和風格各異。由於筆者偏好開發，因此有“Code review”的習慣。出於尊重前輩（筆者的年紀最小，平均小了10歲），時常在代碼上面添加註釋，建議修改或者改進。由於項目前期，測試用例極少，導致了目前修改後的bug不斷，項目中出現了相互職責的問題。經過一段時間的調整，最終統一了意見。過程可以說是步履維艱，其消耗了大量的開發時間。在一個團隊中，很少的人對軟件的思考，過多的是實現功能性。軟件作爲一門藝術，開發是苦難的。如果僅僅停留在功能性實現的層面上，可以說沒有什麼價值。若把它定位到哲學高度，則是力於美的結合。雖然軟件是虛擬的，但是它能夠體現一個團隊背後的智慧，從學術的角度，就是軟件的製造工藝。工藝水平直接或間接地體現了軟件的架構能力。提升團隊的素質，應該從這個方面入手，有限地提高。
顧客就是上帝。
有時候這些上帝也比較“瘋狂”，提出來很多不合理的需求。相信大家喜歡技術型出身的客戶，那樣會更有“人情味”。推掉不合理的需求也是一門學問，如果能夠化“被動”爲“主動”，那更是“藝術”。處理顧客關係，使用軟件技術手段是行不通的。有意思的是，軟件工程裏面很少有“人文關懷”，而是過多的“工程實踐”。筆者認爲“人文”方面是不可少的。事實上，項目經理多不是“技術”官，而是“行政”官，不少人誤解了其作用。
由於時間和經驗的關係，只能寫到這裏。針對一些問題，我會做“專題”，從行政管理到軟件架構，甚至到開發實踐方面，相當地歡迎朋友們一起討論或者指點迷津。