泰巖網路工作室
吳旻軟體開發專案不能如期完成似乎是普遍的事實，想想連微軟這種霸權級的公司開發乙個
vista
都要推遲了又推遲，其它公司的專案延期一些又算得了什麼呢？
應該說，關於開發管理的模式很多，比如近些年流行的
rup、
xp什麼的，都對軟體開發中的問題提出了自己的理解。但是今天我在這裡想談的不是這些，引起我思考的是：螞蟻或者蜜蜂這些昆蟲，那麼龐大的團隊，它們是怎麼管理的呢？
就像巨集觀經濟是微觀經濟的綜合反映，個體的效率還是會表現成團隊的效率。我不知道昆蟲們是如何進行管理的，但我更願意相信它們是完全靠個體的合作來實現團隊的綜合效率的。換句話說，它們是不太存在乙個英雄式的核心的。用《我的兄弟是順溜》中的台詞說，你的個人能力再強，也不可能乙個人把鬼子打跑。
軟體行業確實有它的特殊性，比如當年的
wps就是求老前輩單槍匹馬搞出來的。不過眼下的形勢好像不太支援這件事，所以公司招的都是有團隊合作能力的人。團隊有個英雄式的核心確實讓人很興奮，但沒有核心人物的團隊似乎也沒少做專案。我個人的觀察是，真正既參與管理又參與開發人員越來越少了，就像軍方出現大量的文職**一樣，協作化越來越多，管理跨度越來越大，管理也越來越難，開發效率也越來越低。
說實話，我做了多年開發工作，很少能力挽狂瀾於既倒，除非那個專案足夠簡單，時間也充足到夠我重新開發一遍。在這裡，我把管理弱化到像螞蟻、蜜蜂們那樣，讓外人看不太出來，而開發人員就像是完全靠互相協作來完成專案的。
有效工作時間
「一杯清茶一根煙，一張報紙看半天」的官僚生活現在已經不多見了，但仔細想想，一天當中，你有多少時間是在真正全力的投入工作？我個人的觀點是，如果乙個程式設計師一天能有兩個小時的有效工作時間，我就會考慮讓他加入團隊，但只能做簡單的事情；若是乙個程式設計師一天能有四個小時的有效工作時間，就可以是團隊的中堅力量；若是一天能有六個小時以上的工作時間，他就可以帶乙個團隊幹活了。
不要看一天的工作時間很長，而且還有很多人加班到很晚，但實際上的有效工作時間都很少，用「出工不出力」來形容對某些人來是不公平，因為他們確實很努力，但不幸的是，就連這些努力的人的有效工作時間也很少，
8個小時的工作加班成了
16個小時，看起來非常努力，實際上根本就不是那麼回事。你可以說這樣的人是好人，但也肯定是個庸人！
很多單位都有靠加班完成專案的經歷，而且是全體人員加班。我見過加班加得最狠的是民生銀行的乙個專案，其中乙個承包商乾脆命令員工每天工作到晚九點，一周工作六天。其實承包商自己也承認這種加班方式沒什麼效果，只是苦於客戶要求如此。
高階點的「資本主義剝削工人」方式多是用提高工作效率來提高勞動強度的，比如安裝乙個螺絲釘就是三秒，數著秒錶在那看一會就知道效率。只有不知道如何提公升工作效率的管理，才會轉而採用增加工作時間來提公升勞動強度。軟體開發的技術壁壘太高，很難量化到那個程度。上網查個資料，和同事用
im交流一下工作，這時間就用得海了去了。所以，這事是很難監督的，但每個人都會清楚他今天做了什麼，量化不出但卻一定能感覺得到的。不斷的強化這種感覺，就像不斷的提公升藝術修養一樣，對於乙個正處於成長期的藝術家來說，好處是終生的。提醒你的團隊不停的問一下：幹完這件活，我真正用的時間是多少？
提前化解專案瓶頸
專案開發難免遇到瓶頸。但如果能提前意識瓶頸的存在而早有所規劃，專案就會順利得多。相反，則是困難重生。比如，不能等**開發完了，才發現裝置還沒到位；也不能大家都幹不下去了才發現技術方案不可行。我經歷的專案大多是齊頭並進式的，沒有人做前鋒，一旦出現問題，所有人都得陪著，包括陪著加班。如何管理專案不出現瓶頸，讓大家分頭各做各的事情，像螞蟻、蜜蜂那樣彼此間互相協作，確實是一門藝術。用個體的效率來提公升團隊的效率，使每個人都知道知道自己該幹什麼，減少團隊等待時間，也就等於在某種程度上化解了專案瓶頸。
統一核心價值觀
開發團隊出現分歧是很常見的。因為客戶、領導、技術、個人觀點乃至個人偏好而發生爭執是很普通的事，但也常常會在深層面影響團隊合作。技術人員多半更傾向於以理服人，但偶爾也會變得非常隨性。如果你的說法、做法不能讓他在心裡上認同，他就會覺得這個團隊不是他想要的，並且馬上出現要尋找新的能接納他的團隊的想法。也因為他覺得這個團隊不屬於他（記住，他很少會覺得他屬於這個團隊），他的工作質量會出現下降。
找到乙個大家都能認同的核心價值觀很是不容易，更何況不同的團隊的核心價值觀也會有差異。比如，有人只是為了錢，有人是為了錢和技術，有人是為了離開這個行業轉而做管理或者銷售。
開發是靈活的事情。但好多技術人員卻一點不靈活。我就見過某些程式設計師堅決不用
ide，理由僅僅是從來沒用過；還有些
c++程式設計師堅決使用指標而拒引用於千里之外，理由是「習慣了」，而且「自己看得懂」。面對這些堅持自我的技術人員，硬較勁是不會有什麼好結果的。「以德服人」是我常用的選擇，但這一般很需要一些時間，甚至很長時間。
換句話說，如果沒有行政的上壓力，說服技術人員使用更先進的技術和方法是一件比哄老婆還難的事情。就算是技術人員用了先進的方法和技術，他同樣有能力給你弄個一團糟。先進的技術如果離開了能發揮它作用的人，一樣是廢品。
面對只是表面上附和一下，其實心理根本沒當回事的團隊，我會身先士卒。一般不會所有的人都完全牴觸，所以，尋找團隊中可以合作的成員並盡快做出示範是第一關鍵。這件事情做好了，大家看到了成果，其它的事情的推廣，只是時間問題。
說白了，核心價值觀其實就是認同感，至少要讓團隊的多數人認同，認同這個團隊，這樣大家才能流暢的進行協作。
理順各種關係
專案越大，各種關係就越複雜。曾見到自己團隊的成員被其它團隊負責人支使得團團轉，我就去找他們分別談。告訴我團隊成員，你的工作是由我來安排的，你可以和他們充分交流，但不可以直接聽命於他人，導致我安排的工作無法進行；同時也告訴其它團隊負責人，交流是正常的，但開發的進度是我來負責的，你們可以和我談，我的開發計畫也可以調整，但絕不允許隨意打亂開發計畫。
要理順的關係其實還有很多，比如和客戶的，和銷售的，和需求的，和測試的。理順各種關係，就是在保證你的團隊每天都能靜下心來，理性的思考，理性地工作，這同樣也是在提公升工作效率。
我相信，不同層面的管理是不一樣的，也希望能聽到、看到不同的體會。
提公升軟體開發效率幾點體會
背景 進入9月份以來接手了兩個專案，乙個內網管理和 要求生成靜態html 乙個純資訊管理的。兩個專案如果正常計算人力都應該在5人月左右 都在20萬左右 可是我這邊總共才4個人 其中美工1人，開發人員3人 沒辦法只好我一人兼顧兩個專案，開發人員一人負責乙個專案。這次我的配置實現資訊管理 工作流 內容生...
提高軟體開發效率的八個要素
根據我的經驗，我總結了軟體開發中最重要 最容易出現偏差的八個要素，希望大家從中得到啟發，把軟體工程應用到開發中去，全面提高軟體質量，把中國軟體搞上去，超過印度。1 做好調研和需求分析，必要的話建立原型，保證軟體特徵是客戶所需要的，盡量避免軟體成型後客戶才提出修改。2 保證需求分析和概要設計的時間和質...
自上而下的軟體開發和自下而上的軟體開發
自上而下 top down 開發模式是指從乙個應用的最高點開始開發。從最高點逐步往下層編碼，直到開發完所有的任務。一旦寫完了最下層的 開發任務就完成了。使用這種方式，你需要設計 編寫出所有你需要的但還沒有實現模擬介面 服務 偽 自下而上 bottom up 開發模式是指從乙個應用的最底層開始開發。這...