作爲一個低調的程序員，平時除了要學學技術外，還要多多關心除開發以外其它職能的作用以及運作，方便站在一個比較高的層次看待問題。特別是當你的工作越長時間成爲老鳥時，你要遇到的人的"品種"將越複雜，瞭解這些將能更好地利用資源。
就開發而言，經常接觸到的有項目經理、技術經理、一起開發的同事，偶爾技術遇到問題時找技術經理解決，如果是超出項目組能力範圍的技術經理通常會調動項目組之外的其它資源，比如美工、SL、其它項目組等，也可能是你直接跟資源溝通，因爲遇到的問題你最清楚。需求有問題時一般都會找項目經理，不會讓你直接找需求人員。就我的經驗，通常都是前期需求人員與項目經理一同做需求調研的，所以項目經理也是很熟悉需求，之後需求規格說明書出來後，基本上就見不到需求人員，中間的橋樑其實就是項目經理了。許多公司爲了節省開支，通常在項目的前期會分配有一個項目經理和一個技術經理，或者只有項目經理或技術經理。技術經理根據需求設計詳細設計之後經常會閃人，他們經常會同時有幾個項目併發，分身乏術。
所以需求方面和開發人員沒有啥關係嗎？錯！對於剛入職場的菜鳥而言，老大分配的往往只有開發任務，但是對於團隊內部的精英、核心骨幹，經常也會充當前期的需求調研角色，除非是需求人員開發出身，熟悉技術，能在技術可行性上引導客戶，否則還是需要開發人員去提供技術支持的，所以開發人員也會和需求人員和客戶打交道，包括前期需求範圍的確定。開發人員不是機器人，接到什麼任務就做什麼，對於不能實現的技術或開銷比較大的開發他們也要提出自己的意見。還有，有些公司沒有專門的部署人員，通常部署的角色都是由開發人員承擔，這個時候你需要和客戶那邊的運維打交道。部署後你又要做客戶培訓等等工作。然後你求神拜佛，希望部署後不要出現太多問題，然後催客戶趕緊驗收，然後有項目獎金可以拿
。部署之後沒有問題是不可能的，客戶在使用之後會提出更多的需求，這是好事，說明你做的系統有人使用了。
漏了一個環節：測試。其實規範的項目應該分配有測試人員的，而且在需求文檔出現之後，開發項目之前就應該做需求測試了，然後做白盒測試，阿爾法測試、單元測試、迴歸測試、集成測試等。測試在正規公司其實佔有很大比重，對於做企業應用的公司，這部分往往做得比較薄弱，一些遊戲公司比較重視。在微軟，測試人員其實就佔了一半，可見測試的重要性。
剛纔說了那麼多，其實也還只是站在一個開發人員的角度去想問題而已，前後經歷了需求、設計、開發、測試、部署、驗收、維護等環節。現在以做ERP系統的公司爲例，講講我對售前、售後、產品、市場、銷售幾個部門職能的理解，通過對這幾個部門的理解我不再是站在開發人員的角度去想問題。（這裏要多謝榮哥的指點）
市場：做市場調查，然後做宣傳吸引客戶（榮哥公司的市場是靠兩種方式吸引客戶的：一種是與行業內知名IT公司（如：Oracle）合作，然後搞產品宣傳；第二種是請行業內的專家來做講座或培訓，培訓完後順水推舟做產品宣傳）。總而言之，做市場的就是儘可能地挖掘好潛在客戶，然後挖空心思給客戶灌輸公司的產品、宣傳產品。
產品：做產品的對各方面要求都比較高，就榮哥說的，在他公司要進產品部起碼要在這個行業內混上個四五年。產品要求對業務要達到精通的程度，並且能很熟悉產品的使用、產品的細節，業務上是這個領域的專家了，能在一定程度上引導客戶。技術方面也要求比較高，因爲要和開發人員交流。
銷售：銷售要做的就是“拿下單”，做銷售的一定要懂業務和產品，可以不懂技術。，但最主要就是憑自己的三寸不爛之舌說服客戶買你的產品，客戶簽下單之後銷售就拍拍屁股閃人了。
售後：可以理解爲實施吧。其實售後也是蠻考驗人的，這一部分榮哥深有體會，說得也很具體生動。首先，公司雖然有產品了，但是畢竟人家原先就使用了一些系統，積累了很多數據，那麼如何去將老數據整合到新產品中呢？而且產品最終能否比原先系統好用或更加規範，要經得起考驗，經常會聽到一些客戶大罵：“怎麼新系統比老系統還麻煩啊！要點好幾個按鈕才能出來？原先只要輸入以下就行啊！”這個時候實施可能會成爲出氣包，導致這種問題有很多原因，有可能是爲了數據更加規範統一，也有可能是爲了某個報表的更好統計，能否說服或說安撫好用戶，就要靠實施人員的經驗和技巧了。而且客戶提出的需求通常會反饋給實施，然後再由實施反饋回項目經理或開發人員，這當中有涉及到溝通問題，能否正確的傳達客戶要什麼，也是一個考驗。綜上所述，實施中最難的就是需求變更以及新需求的把握、解決方案的溝通等。