三五個人十來條槍 如何走出軟體作坊成為開發正規軍

來源:互聯網
上載者:User

標籤:blog   http   ar   使用   sp   資料   art   問題   log   

三五個人十來條槍 如何走出軟體作坊成為開發正規軍(轉載)

 

自從發了上一篇博文,這幾天收到很多朋友的來信。

大家從各個開發語言的優缺點和適用領域,一直討論到設計模式、架構、重構、單元測試,乃至敏捷編程,最後都討論到了軟體開發過程管理,甚至都談到了盈利模式和中國軟體

的悲哀。

最後不了了之,都覺得改善中國內地現在的軟體生產狀況不可能。

為什麼呢?

我重新把這幾天大家的討論留言翻了一遍,發現大家的軟體團隊都存在著這樣一種普遍現象

1大部分人所在的公司,開發人員僅3-5人,多的在10人。別看就這幾條槍,還從售前支援,軟體開發,測試、打包發布、文檔編寫、實施安裝、培訓、支援人員都做。
這還不算什麼,而且幾乎是一個人負責一個產品或一個項目,一個人從頭跟到尾,而且負責多個客戶的維護工作。
這還不算什麼,而且隨時老闆會找來八竿子打不著的新活,要的還挺緊,突然要開發,打亂了所有的計劃,最後都懶的按計划行事,每天撞鐘,老闆有事就吩咐,沒事就上網,還不讓聽歌,當然更不讓打遊戲。甚至還不讓看技術書籍,呵斥不幹工作。只能上網裝作在工作。

2老闆和員工互相鬥智鬥勇,在年終獎、報銷、出差、平時福利上啊,都明爭暗鬥。老闆卡的緊,員工就在項目和產品上下藥,還不知道是誰佔了誰便宜,誰給誰打了工。

3員工一邊在刻苦鑽研各種開發工具,閱讀原始碼,學習做DEMO例子,閱讀UML、設計模式、單元測試、敏捷編程等等,一邊卻懶的修改現在公司的產品,有問題就打補丁,客戶不嚷嚷就懶的修改,代碼不最佳化,介面不友好,架構沒架構,代碼不封裝

但是,在討論中,我時時都強烈感覺到,大家是想把產品開發好,把開發過程管理的井井有條,但是都心有餘而力不足。閱讀了N多軟體工程的書籍,從重型方法到輕型方法都閱讀了,但都無法把現在的開發狀態一點點扭轉好。

許多人想鬧革命,把現在這些產品和團隊都砸塌,然後重新來過,但這隻是夢想,說說而已。只能希冀下一次跳槽,能找到一個好的公司,把自己平生所學全部發揮出來,但這好像也只是夢想,因為交流了一下,大家彼此的境況基本相同。

一些極端主義者自己開了公司,才發現不持家不知道油鹽貴,現在自己和手下變成了老闆和員工的關係,走了過去的老路。

更有一些極端主義者辭職,自己做軟體,最後由於生活拮据或做做發現這個軟體沒什麼意義,就丟棄了自己的夢想,隨便找一家公司開始沉默撞鐘。

一些聰明的傢伙,有的入了外企,有的進了大的網遊公司,有的進了外包公司,有的進了大網站公司,都是講究大規模開發的公司,希望能找到一條中國式團隊開發產品保證之路


作為小軟體公司,我們真的無能為力了嗎?我們真的成為炮灰了嗎?

但是,中國軟體行業大部分都是這樣的公司。從每年的CSDN的程式員調查都可以看到,中國軟體公司大部分都保持在這種Team Dev規模,開發人員大部分都在畢業1-3年。

我們是在等待時間讓人變得成熟嗎?我們是在等待時間讓人變得技術綜合實力增強嗎?

依筆者看,作為中國軟體群體最大的小軟體公司,需要的不是UML/RUP/CMM這些重型方法,不是前幾年大家關注的小組開發方法,也不是敏捷編程這樣的結對方法,我們都無法有這樣的資源實現這樣的方法。

但是,想想,星星之火可以燎原。紅軍能從爬雪山過草地起家,最後解放全中國。我們就沒有方法?

那我們就需要想,就我們目前能擁有的權力和資源,我們如何一點點改進。我們需要的是從遊擊隊到兄弟連,從兄弟連到正規軍的方法。我們現在還處於遊擊隊,一個隊長領了一幫遊兵散勇,有的人甚至沒有槍還背著大刀,有的人還沒殺過鬼子。

首先,要把我們自己變成兄弟連。

我常常觀看國際著名的CS戰隊的比賽錄影,他們配合的多好啊。如果他們都單兵作戰,那麼早就死翹翹了。這和咱們的軟體開發多麼相像。我們多麼神往這種默契的配合,打的多麼流暢。我們要的就是這個。他們也不幾個人麼。

那讓我們來分析分析吧。

我們想好好專職的開發軟體,但我們的時間都被實施安裝、培訓、支援人員佔去了。為什麼我們要做這些?是因為我們軟體沒有操作說明,其他部門人都不會用。而且我們也沒有培訓機制,其他部門人更不會用。而且我們的軟體不穩定,其他部門人都拒絕實施。由於我們軟體不穩定,老出問題,出了問題其他部門人也幫不上忙,只能我們自己去做支援人員。

從以上來看,主要矛盾就是在:操作說明、培訓機制、穩定性。如何保證這三點。而且從以上來分析,穩定性是最重要的。不穩定,你即使有操作說明和培訓機制,其他部門人都躲著實施,誰想去客戶那裡尷尬丟臉挨罵呀。所以,其他部門人會找各種理由向老闆告開發部的狀,以躲避實施,說軟體太爛,根本無法拿出去。這也就是開發部往往和其他部門關係都不好,開發人員老抱怨自己就悶頭辛苦開發解決問題,沒有人說好,卻被奸人陷害。天長日久,積怨頗深。其實說起來,根源還在開發部自己這裡。

如何保證穩定性?

大家第一想到的就是招測試人員。當然,一些公司的老闆是拒絕養測試人員的。另外,如果你只想到招測試人員,其他方法不配合測試人員,即使有了測試人員,軟體穩定性仍然不會有提高。所以,有一些工作,是不管有沒有測試人員,都必須是我們開發人員要做的:

每個人的技術水平都參次不齊的,每個人對自己代碼的負責認真性也都是不一樣的,所以要想提高穩定性,必須專門從隊伍中找一個人,他作為公用代碼開發員。每個產品或項目的修改需求,必須首先經過他的思考,能做成公用代碼,能封裝成函數,就他來做。其他的程式員只管調用函數,實現客戶UI操作和協助工具功能。這個公用代碼開發員必須具備以下能力:
A參與過幾個主要項目的開發、實施、支援。這樣,他對客戶需求有綜合的把握。如果隊伍中沒有這樣的人,只有開發經理一個人有這樣的經理,那麼接到客戶需求,分析客戶需求,分解析辨是公用代碼員來做還是其他開發人員來做。
B公用代碼開發員具有負責認真的工作態度,代碼細心嚴謹考慮周詳異常保護做的到位記憶體建立釋放有頭有尾,代碼優美,代碼可閱讀,代碼重構,代碼效能和穩定都高
C公用代碼開發人員的技術能力高,知道封裝成什麼樣的函數介面,在靈活性,以後的修改變化性上最好

應該說,找一個技術能力好的,工作認真負責的人,應該是不難找到的。而且專門做這件事,不讓他參與各種雜事,他是應該能幹好這件事的,而且會越做越好,這就是術有專攻。

剛才還講到一件事,那就是開發經理要熟悉客戶需求,而且是深刻理解客戶需求。

客戶需求,客戶需求。這個讓開發部最頭疼的字眼。每當想起客戶需求,就想起了以下這些話:
1 程式員說:這是你們家個性的需求,太邪門,我們不做。客戶說:不做我們找你們老闆去,我們是花錢買了你們的產品的。
2 客戶說:我不會用滑鼠,你給我做一個語音輸入吧。我們還想要一個類似QQ的東西供我們內部溝通,你們給我們做一個吧。程式員:我暈。
3 程式員說:等你們內部鬥爭完,你們協調完了,我再調研需求。

似乎,我們在需求上無能為力,我們永遠在追趕客戶的需求,滿足他們的現狀,把N多家的客戶需求都加進軟體中,只要能實現的,我們盡量咬牙實現了。

最後,我們發現,我們的軟體無比複雜,誰也不會用了,連開發部門都不會用了,誰也不知道這個需求當時為什麼是這樣的。因為無比複雜,所以實施、培訓、支援人員都成了問題,穩定性更成了問題。代碼互相交叉,根本無法理清有多少交叉影響點。維護的程式員都快崩潰了,天天在祈求,千萬別接到客戶電話,千萬別接到客戶電話。

這個問題終歸是問題,而且是軟體開發最大的問題。雖然我們也動用了這樣的技巧:
1 客戶業務部門不能隨便提需求。必須集中匯總到客戶IT部門,由客戶IT部門匯總過濾完,再集中報給軟體公司
2 客戶IT部門的需求,必須客戶方負責IT項目的老闆簽字才會生效,才能報給軟體公司
3 不能隨時報,每3個月集中報一次
4 不能口頭報(即使在現場實施支援也不行),不能電話報,只能MAIL或傳真來報
5 必須按我們規定的格式報,要嚴格寫清楚需要實現的功能的介面,輸入資料或輸出資料,輸入輸出資料的格式要求,誰操作,多長時間操作一次。
6 軟體上線後只能免費修改3次。以後再有需求,就必須另簽合約另收費,否則不予修改。

經過這麼幾招,客戶也疲了。需求是不提了,開發部歡呼雀躍。但我們真的做好了嗎?難道客戶真的滿意了嗎?客戶為什麼要用我們的軟體?難道僅僅是為了把他們現在手工做的,然後轉到電腦去做。讓電腦的查詢統計計算速度代替人工?

客戶為什麼要提這樣的需求?客戶要根本解決什麼問題?這些問題誰來想,誰來想解決辦法?

OH,My God!我們無能為力,因為我們是技術人員,我們不懂業務。

那這個問題誰來解決?

程式員苦笑了:沒有人解決,也沒有人能解決。客戶就要,你不做他就要給老闆打電話。

噢,那就讓程式員的噩夢繼續吧。誰也救不了你,能救你的只有你自己。

要救我們自己,必須我們自己走出我們自己。誰讓我們就處在這樣的處境呢?我們都想過的好,只能我們自己救我們自己。

那我們就鼓足勇氣,走出來,從我們的設計模式、OO、軟體工程、虛擬介面、反射、持久化、架構中走出來。開發經理來承擔起客戶行業研究來:
1 客戶行業這個群體有多大?大中小規模各有多少家,各分布在什麼省?我們面對的最佳客戶是什麼規模什麼資訊化程度的?我們的次佳客戶是什麼規模什麼資訊化程度的?
2 我們的上層競爭者、本層的競爭者、下層競爭者目前的產品怎麼樣?他們各自的優點是什嗎?他們各自的缺點是什嗎?我們應該突出的優點是什嗎?我們的缺點是什嗎?
3 客戶行業的過去5年,現在2年,未來3年的發展曆史和趨勢是什嗎?他們面臨哪些挑戰和機遇?
4 我們現在所做的典型客戶,他們的組織圖,人員規模,每個崗位每日商務程序、每個崗位每日每周每月每季每年的異常處理商務程序,每個崗位每日每周每月季每年的輸入表格,每個崗位每日每周每月季每年的常用資料查詢,每個崗位每日每周每月季每年的統計報表
5 針對以上的瞭解,客戶面對未來挑戰和機遇,未來應該如何變更他們的崗位和職責和流程,盡量流程少,效率高,運轉快?

其實,開發經理就相當於業務架構師(因為我們還是遊擊隊,不可能有專職的業務架構師),公用代碼開發員就相當於技術架構師。

柳傳志說的非常好:搭班子,定戰略,帶隊伍。你班子不行,上什麼需求管理軟體、版本管理軟體、項目進度管理軟體、自動化的測試、自動整合軟體,都是無法落地執行的。

有了夯實的業務+技術,功能實用、功能符合客戶操作、功能穩定。這是軟體最基本的要求,就都能滿足了。這時候再招測試人員,就能把品質再夯實了。

而且,測試人員由於熟知產品,他們還能做支援人員呢,這樣可以有更多的開發人員來專職開發,開發的專業性就能越來越提高了。

好的產品,還需要有好的文檔和培訓,否則其他部門還是不會接開發部的產品的。

那就招一個文案人員,寫協助說明,製作操作視頻,製作學習版資料庫,參與輔助測試(這個很重要,否則文案人員不熟知產品,無法寫出有品質的文案)。有了這些文案的基礎,最熟悉產品的非開發人員就有了兩個崗位:測試兼支援人員,那麼文案就兼起培訓工作(由於他自己寫文案自己用自己的文案做培訓,在培訓中會有各種提問,會更加增進他對文案和產品的理解,能寫出更好的文案。而且他不是開發人員,他能站在使用者的角度上來寫來講,而且他屬於開發部門,他會給產品開發帶來更多更好的產品易用性建議)。

好了,開發部的四套馬車終於起來了,這就是我要講的開發模式:從遊擊隊轉變為兄弟連,從軟體作坊走向

記住:業務架構、技術架構、測試兼支援人員、文案兼培訓,四套馬車。

我們一直用它,效果很好,搭建團隊容易,循序漸進不革命。

有了這麼好的團隊,就能比過去產出更好的軟體,軟體的品質,軟體的進度,軟體的競爭力就都上來了,再上各種管理軟體:如專案管理軟體、版本管理軟體、BUG管理軟體、自動化的測試軟體,就水到渠成了。

其他部門也願意接軟體了,軟體的實施和培訓和支援人員都被其他部門接過去了。開發部門也終於專職專業起來了,整個公司都很協調了,部門間也不互相陷害抱怨了。公司發展速度蹭蹭的。

老闆看著形式這麼好,也不摳門了。獎金福利隨之而來。老闆看著公司產品銷售這麼好,也不用再為公司生存發愁了,不用隨處找單子養活了,給開發部門更帶來了專業理順的計

劃發展。老闆也開始重視研發部門了,研發部門在公司的地位高多了,給與研發部門的資源和支援也更多了。

OH,My God!

 

三五個人十來條槍 如何走出軟體作坊成為開發正規軍

相關文章

Alibaba Cloud 10 Year Anniversary

With You, We are Shaping a Digital World, 2009-2019

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。