作為一個低調的程式設計師，平時除了要學學技術外，還要多多關心除開發以外其它職能的作用以及運作，方便站在一個比較高的層次看待問題。特別是當你的工作越長時間成為老鳥時，你要遇到的人的"品種"將越複雜，瞭解這些將能更好地利用資源。

 就開發而言，經常接觸到的有專案經理、技術經理、一起開發的同事，偶爾技術遇到問題時找技術經理解決，如果是超出專案組能力範圍的技術經理通常會調動專案組之外的其它資源，比如美工、SL、其它專案組等，也可能是你直接跟資源溝通，因為遇到的問題你最清楚。需求有問題時一般都會找專案經理，不會讓你直接找需求人員。就我的經驗，通常都是前期需求人員與專案經理一同做需求調研的，所以專案經理也是很熟悉需求，之後需求規格說明書出來後，基本上就見不到需求人員，中間的橋樑其實就是專案經理了。許多公司為了節省開支，通常在專案的前期會分配有一個專案經理和一個技術經理，或者只有專案經理或技術經理。技術經理根據需求設計詳細設計之後經常會閃人，他們經常會同時有幾個專案併發，分身乏術。

所以需求方面和開發人員沒有啥關係嗎？錯！對於剛入職場的菜鳥而言，老大分配的往往只有開發任務，但是對於團隊內部的精英、核心骨幹，經常也會充當前期的需求調研角色，除非是需求人員開發出身，熟悉技術，能在技術可行性上引導客戶，否則還是需要開發人員去提供技術支援的，所以開發人員也會和需求人員和客戶打交道，包括前期需求範圍的確定。開發人員不是機器人，接到什麼任務就做什麼，對於不能實現的技術或開銷比較大的開發他們也要提出自己的意見。還有，有些公司沒有專門的部署人員，通常部署的角色都是由開發人員承擔，這個時候你需要和客戶那邊的運維打交道。部署後你又要做客戶培訓等等工作。然後你求神拜佛，希望部署後不要出現太多問題，然後催客戶趕緊驗收，然後有專案獎金可以拿

 漏了一個環節：測試。其實規範的專案應該分配有測試人員的，而且在需求文件出現之後，開發專案之前就應該做需求測試了，然後做白盒測試，阿爾法測試、單元測試、迴歸測試、整合測試等。測試在正規公司其實佔有很大比重，對於做企業應用的公司，這部分往往做得比較薄弱，一些遊戲公司比較重視。在微軟，測試人員其實就佔了一半，可見測試的重要性。

剛才說了那麼多，其實也還只是站在一個開發人員的角度去想問題而已，前後經歷了需求、設計、開發、測試、部署、驗收、維護等環節。現在以做ERP系統的公司為例，講講我對售前、售後、產品、市場、銷售幾個部門職能的理解，通過對這幾個部門的理解我不再是站在開發人員的角度去想問題。（這裡要多謝榮哥的指點）

市場：做市場調查，然後做宣傳吸引客戶（榮哥公司的市場是靠兩種方式吸引客戶的：一種是與行業內知名IT公司（如：Oracle）合作，然後搞產品宣傳；第二種是請行業內的專家來做講座或培訓，培訓完後順水推舟做產品宣傳）。總而言之，做市場的就是儘可能地挖掘好潛在客戶，然後挖空心思給客戶灌輸公司的產品、宣傳產品。

產品：做產品的對各方面要求都比較高，就榮哥說的，在他公司要進產品部起碼要在這個行業內混上個四五年。產品要求對業務要達到精通的程度，並且能很熟悉產品的使用、產品的細節，業務上是這個領域的專家了，能在一定程度上引導客戶。技術方面也要求比較高，因為要和開發人員交流。

銷售：銷售要做的就是“拿下單”，做銷售的一定要懂業務和產品，可以不懂技術。，但最主要就是憑自己的三寸不爛之舌說服客戶買你的產品，客戶簽下單之後銷售就拍拍屁股閃人了。

售後：可以理解為實施吧。其實售後也是蠻考驗人的，這一部分榮哥深有體會，說得也很具體生動。首先，公司雖然有產品了，但是畢竟人家原先就使用了一些系統，積累了很多資料，那麼如何去將老資料整合到新產品中呢？而且產品最終能否比原先系統好用或更加規範，要經得起考驗，經常會聽到一些客戶大罵：“怎麼新系統比老系統還麻煩啊！要點好幾個按鈕才能出來？原先只要輸入以下就行啊！”這個時候實施可能會成為出氣包，導致這種問題有很多原因，有可能是為了資料更加規範統一，也有可能是為了某個報表的更好統計，能否說服或說安撫好使用者，就要靠實施人員的經驗和技巧了。而且客戶提出的需求通常會反饋給實施，然後再由實施反饋回專案經理或開發人員，這當中有涉及到溝通問題，能否正確的傳達客戶要什麼，也是一個考驗。綜上所述，實施中最難的就是需求變更以及新需求的把握、解決方案的溝通等。