軟體工程之淺見

標籤：問題   工作   表   管理   時間   一個   

一個軟體的開發，最初是靠個人能力的。開發人員的能力與軟體的功能息息相關。可是隨著軟體行業的發展，個人能力的佔比在不斷下降，這也是符合客觀規律的。

軟體的規模在不斷變大、軟體的複雜程度在直線上升。這都是單靠個人能力所無法保證的。假設一個開發人員的能力很高，他在一個系統中的表現很好，可是不一定在其他系統中的開發表現良好。人都是有其擅長和不擅長的趨向問題。另一個原因是，如果一個軟體對單個開發人員的依賴度過於高，那麼帶來的重大風險也會隨之升高。離職、個人能力的欠缺、個人的職業素養等等都會直接影響軟體的品質。因此，現在的軟體行業，已經脫離了靠個人能力單打獨鬥的時代了。

現在的電腦專業都有一門課《軟體工程》，是的但從名字上，我們也能理解現在軟體的方向，軟體必須向工程化方向靠攏。什麼是工程化，按自己的理解就是有一個根據行業特點制定的一個適合當前形勢的軟體生命週期的管理步驟、規範、甚至是標準。

在這個體系中，按照自己的理解，應該務求這麼幾個方面：

1.流程務必簡單。不能像國企那樣申請一隻筆，竟然要幾個人審批，審批好幾天。如果其中某一個人請假不在公司或者出差，那麼還申請不到。另一種就是，其實只需要一個人審批的事情，根本沒有必要再加上其餘的審批，因為即使加上他人審批，問題是出了問題，他們誰會為此負責呢？我想沒有任何一個審批人願意承擔責任的。所以與其一堆人審批，不如按誰審批誰負責的原則，減少不必要的，形式化的審批次程序。

2.盡量一個蘿蔔一個坑。兩個人一起去做一件單一的事情，最終往往是把事情搞得很複雜，事情也沒被辦好。這樣的例子幾乎處處都是。如果一件事涉及到不同的工種協同工作，那麼也要明確職責及期限，那個環節的問題和責任更是要明確下來（當然要獎勵也要與之對應才行），如果出現一堆人在扯皮的事情，不是其中一個人的問題，而應該思考思考哪裡的問題了。

3.環節中的人員選擇。在整個軟體工程的鏈條中，每一個環節都需要有合適的人去做，並且監督。一個環節不一定要那種聰明絕頂的人，但是也堅決不能要那種問題永遠沒玩沒了的人，那種老油條和習慣性推卸責任的人也堅決不能選擇，我們需要的是能打仗的戰士，能幹活的工友，而不需要那些賣油條的人。人員配備，其實應該是軟體工程的一個基礎性的保障。

4.就像一些很著名的言辭一樣。金錢是成功的附屬品，當你成功時，你一定會擁有金錢、地位等等附屬品。可是你單一追求金錢時，即使你追到也未必算得上成功。軟體工程管理者角色也一樣，你天天追求財務報表的好看，向基層幹部和員工下達苛刻的財務指標。其餘的什麼公司文化建設、員工歸屬感、人員招聘一律不管，恨不得在所有花錢的地方都把一分錢掰成八瓣花，而在所有應該發放福利的環節偷偷摸摸。我想這個做法或許在某一時刻非常管用，但是時間一長，輕重顛倒的利害不用重複了吧。相反，如果能夠花更多心思研究當前的行業形勢、公司的發展方向，研究在當前形勢下，公司的制度應該怎樣更好的適應這一潮流。研究怎麼樣招聘到更合適的人才，怎樣讓員工在公司開心的工作......等等，我想如果這樣做下去，勤於打理的肥沃土地上，長出豐碩的果實，是早晚的。