Mashable的Scott Gerber Young Entrepreneur Council
credits: Kengo HAMASAKI
1. 搜尋引擎最佳化專家（SEO）
再好的產品也需要曝光才能獲得更多使用者。
2. 資訊分析專家
網路上充斥著各種資訊，要從這些資訊中找岀有意義的內容需要經過分析。
3. 溝通專家
雖然對科技人才的需求很高，但是更需要的是同時具備科技專業知識以及與客戶溝通能力的人才，這樣就不需要再一個中間人去協調客戶和IT部門。
4. DevOps專家（協調開發及運營部門的部署專才）
隨著敏捷軟體開發、迭代式開發、SaaS以及雲端運算的普及化，以及未來即將需要擴大規模營運的公司來說，客戶的需求越來越大且多變，也意味著開發及營運部門的溝通變得更頻繁及複雜，因此需要一些DevOps專家來加強發佈協調，並且部署協調以彌合開發與運營的鴻溝，迎合越來越快速及多變的軟體開發流程。
5. 手機/平板電腦軟體開發者
手機以及平板電腦越來越普遍，因此對於行動軟體開發工程師的需求也變多。
6. 產業IT專家
工程師除了需要具備程式及科技領域知識外，各個產業也希望他們可以加值對於各個專業領域的知識，例如醫療、商務、法律、會計及餐飲的知識，而不是單只有技術能力。
7.使用者經驗（UX）專家
好的設計不一定是中看不中用，產品開發除了視覺設計、程式設計及行銷外，更值得注意的是使用者經驗。一個產品的價值在於它給使用者的經驗，但是很矛盾的，“經驗”是不能被設計的，使用者經驗專家的目的不是設計經驗，而是盡量提供使用者一個最良好的軟體使用流程。
8.雲端運算專家
AWS、Rackspace和Gogrid等雲端平台時代的來臨，無論是Startups還是大型企業都需要更多熟悉雲端平台的專家來維護及整合雲端服務。
綜觀以上八種類型的專業能力是美國新創業家協會所認為是今年最熱門的職缺以及專業能力，其中對內及對外的“溝通”能力也是網路界最為強調的主要能力，溝通專家，DevOps專家及使用者經驗專家都強調了一種溝通的能力，其中DevOps最受爭議，有些人認為它是 Sys Admin的新職稱 。有很多人認為DevOps是一個職位，但是它其實比較像是一種運動，一種思維，提醒開發和運營團隊需要多合作，根據wiki的解釋：
DevOps（Development＋Operations） 是一組過程、方法與系統的統稱，用於促進開發（應用程序/軟體工程）、技術運營和質量保障（QA）部門之間的溝通、協作與整合。需要頻繁交付（continuous delivery）的企業可能更需要對DevOps有一個大致的了解。Flickr發展了自己的DevOps能力，使之能夠支撐業務部門 「每天部署10次」的要求 ──如果一個組織要生產面向多種用戶、具備多樣功能的應用程序，其部署周期必然會很短。這種能力也被稱為 持續部署 ，並且經常與精實創業方法聯繫起來。
以下有一個有趣又能夠解釋DevOps來龍去脈的影片：
影片是2010年DevOpsDay的開場短，影片中，查理·卓別林的角色是運營人員，但一連串的事件讓他覺悟到DevOps的能力，影片中影射的 問題 是：
- 開發人員經常不考慮自己寫的代碼會對運營造成什麼影響。他們在交付代碼之前，並不邀請運營人員參與架構決策或代碼評審。
開發人員對配置或環境進行修改之後，經常沒有及時與運營人員溝通 * ，導致新的代碼不能運行。
開發人員可能對運行時環境缺乏了解 * ，從而難以正確地對代碼進行調整。
運營人員可能對應用程序內部缺乏了解 * ，從而難以正確地選擇運行時環境和發布流程。
運營人員嘗試避免變更，新功能流入生產環境的速度因此被延緩，從而延緩了開發人員將特性交付給用戶使用的速度。 *
>
DevOps 聽起來跟敏捷開發（agile）的一些方式很像，的確Devops是由敏捷運動啓發而來的，而最先提出DevOps概念的原因也是因為為了應付敏捷開發過程中需要 加快產品交付的速率 而衍生的問題，當軟體敏捷開發持續追求優越的技術與優良的設計時，DevOps則是持續改良整個流程的順暢度。整體來說，DevOps有幾個重點，簡稱“CAMS”：
Culture 文化 * 至少先要有精實（lean）跟敏捷（agile）的文化，團隊裡每個人都懂得共同分擔和承擔責任。
Automation 自動化 * 善用自動工具來驅動或管理如：共享版本控制（shared version control）, builds, deployments, testing, monitoring等工作，優化發佈流程。
Measurement 量 測 * 從紀錄中學習並且改進，如果沒有任何測量紀錄就不會知道錯在哪裡，自動化的流程，人的表現，這些通通都需要數據化。
Sharing 共享 * 開發中需要加強發佈協調，確保相關團隊人員都瞭解每次變更的內容，開發後需要事後檢討，將開發團隊以及維護團隊的問題全部搬到檯面上來討論，更進一步的發掘問題以及雙方的困難。
在敏捷開發中會常常需要持續部署，也因此需要更緊密的團隊溝通以減少出錯，而一開始沒有將溝通納入考量的公司會隨著敏捷開發的團隊擴大規模而發現不少問題。
為使「開發團隊與運營團隊之間更具協作性、更高效的關係」，對DevOps有興趣的人可以參考John Allspaw (Flickr/Yahoo!) 和 Paul Hammond (Flickr)的 演講：”10+ Deploys Per Day: Dev and Ops Cooperation at Flickr” （ 投影片 、 Liveblog ），這個關於DevOps合作的演講後來還 啓發了日本的Cookpad 呢，後來Cookpad也做了一個叫”10+Deploys Per Day: Dev and Ops Coopeartion at Cookpad.”的投影片。
出自Inside部落格
@@ACTIVITYID:402@@
