管理感悟：軟體的特性
栁鯤鵬2017-12-18
關鍵字：管理 軟體 特性
簡介：本文嘗試討論軟體的特性。目錄
硬體與軟體的差異... 2
產品的三個階段... 2
研發期... 2
產品成熟期... 2
維護公升級期... 2
怎樣正確認識使用者需求... 3
使用者需求三原則... 3
使用者不知道什麼... 3
關於使用者需求的錯誤觀念... 3
產品決定需求... 3
怎麼看待軟體產品... 4
產品的觀念... 4
更換軟體的可能性... 4
功能與執行... 4
簽字了不一定執行... 4
不簽字的也能緊急加入... 5
各方及時通報情況... 5
如何有效避免... 5
軟體與加班... 5
不懂技術怎麼管理... 6
兩個關鍵... 6
如何安排研發... 6
專案與工期... 6
分階段推進，及時互動... 6
硬體軟體
半成品出門不能能
有問題退貨
完善經常維護公升級
退貨受歡迎
功能無法按時完成
只能延期
遮蔽功能，按計畫出
生產有成本
完全無成本
開展市場
容易困難
丟失市場
容易困難
技術原型階段。
演示階段。完善、測試的迴圈，直到能對外演示，緊急情況下可以賣給使用者湊合使用。到了這裡，才可以暫停。
產品階段。完善、測試的迴圈，直到能湊合用。注意，這裡的產品，能滿足基本使用，無嚴重問題。
不存在意見、討論、修改、公升級的迴圈。
產品效能更好。
產品**更便宜。
產品讓自己更省事。
不知道技術細節。
不知道產品細節。
不知道功能細節。
以為使用者知道自己想要什麼東西，東西的各種細節。
把使用者言論當作聖旨，不會分析是否合理、真實意圖。
以為使用者看了東西，能一次性把問題說全（所有問題，每個問題細節）。
以為使用者的想法一成不變，發生了變化就惱羞成怒。
動輒打著使用者的名義。
迷信文件。等著使用者列出詳細文件；以為有了文件，什麼都清楚確定了。
開發產品，真實原因在於，我們認為使用者想要什麼，而不是使用者告訴我們。這是因為使用者需求三原則在指導我們。
需求實際上是由產品確定的。沒有產品時信口開河，有了產品實際上是被產品引導、限制。
歸根結底，先讓對方使用產品。之後關於需求的主動權就轉移到軟體方。
這聽起來很不可思議，實際上想想，軟體維護公升級是誰決定的？使用者反映的問題，要不要解決、哪個版本解決，都是軟體方決定的。
大多數人是沒有產品觀念的，問題的關鍵在於，都以為自己有產品觀念。
產品有什麼問題，視而不見，就是典型的例子。有產品觀念的人，看產品處處是問題；無此觀念的人，一旦沒告知，就不知道要幹什麼。
作為乙個普通員工，有沒有關係不大。作為乙個決策者，必須具有產品觀念。
產品在我心中：
產品大體上什麼樣子，具備哪些功能。
什麼條件下能將就出門。
產品有什麼問題，下一步要做什麼。
對於個人很容易？也不好說。一旦用一段時間，就會形成信賴。
對於大集團使用者：
求穩。換人不換衣，表面上看起來要差不多。普通使用者感覺不到變化。
所以對於大集團，除非萬不得已，不會更換。也就是說，大集團使用者一旦拿下，只要不犯大錯誤，市場就是穩定的。
一般來講，簽字（簽訂合同）了就必須嚴格執行。
而在軟體業，延遲是很常見的事情。於是問題就產生了。
簽字了是不是就一定要執行？
不一定。根據時間、技術難度、臨時情況等等，可以只做一部分就算完成。
不簽字的功能，是不是就一定不能加？
不一定。要看具體情況。
首先，即使軟體經常延期，導致功能完成不了，我們工作中依然要想方設法的保證進度、功能。而不是心安理得的延期。
對方提出新功能，如果涉及到新的技術，一定不能明確答應。一定要等技術原型出來之後，再做答覆。也許乙個很小的功能，要耗費大量的人力時間。
比如哪個功能無法按時完成，要及時通報，看看如何補救。
同樣的，新的功能要求緊急加入，也是越早越好。
對於新功能，都不要當場答覆。因為有可能涉及到新的技術或方案。一定要等技術原型出來之後，才能給予答覆。
如何有效的安排研發工作。
如何有效的管理研發工作。
做軟體，沒有不加班趕工的情形。
如果不是長期，那也是呈現波浪形的加班週期。
如果沒有加班，那說明了領導層存在嚴重失誤。
為什麼軟體要加班？
功能的變化性。
軟體的複雜性。發現的bug最好解決，麻煩的是偶現，而且是很難復現的那種。不過大多數程式設計師發現的都解決不完。為什麼呢？
能力的不足。雖然技術人員覺得自己很厲害，實際上並不是這樣。而天才級別是請不到的，所以必須加班趕工。
首先，一定不要被技術嚇住，也不要被需求、文件、方案嚇住。這些東西跟領導無關。
其次，一定要抓住重點工作，重點專案、重點功能。
在軟體行業，目標無法按時完成，實際上是常態。延期了如何不影響商務？
工作安排上，要採取「先重後輕」的原則：
前期做關鍵的工作，即重點、難點。
把關鍵人力（技術能手）投入到關鍵的工作。特別是要避免雜事分散其精力。
前期工作要多安排，突擊趕工。
以專案為條理，採取專案負責制。
要求研發列出詳細的功能點列表及計畫。當然這個是參考，不可能是全部。
研發、測試、試用、完善要同步進行。注意是並行，不是序列。
嚴格控制工期。一旦超出計畫，立即著手縮減功能。
每次前進一步，及時與買方互動。
盡可能每次會談都有進展。
軟體外包專案管理的經驗感悟
自2003年參加工作至今,一直在參與軟體外包專案。從程式開發人員到設計人員,再從設計人員到專案組長 專案經理,風風雨雨走了將近8個年頭。這期間經歷了大大小小數十個專案,對專案和專案管理的認識也從無到有經歷了下面幾個階段 對專案 專案管理所知不多階段 這個階段是剛進入公司的頭一年,對專案完全沒有概念,...
專案管理感悟
專案進行到設計階段時，持續時間偏差已經達到80 而整體進度不允許時間偏差，這就意味著需要在後面的階段中追趕進度，把 前面耽誤的時間給追回來。人力沒有補充，工作量在那裡明擺著，開會時所有的開發人員都怨聲載道 量那麼打，時間那麼短，肯定完成不了，如果實在要在指定的時間內完成，那只有湊合，不能保證質量 我...
感悟管理 一
親愛的fx 有一件事情我不得不連夜寫信向你表示感謝，你在請我吃肯德基的同時幫我想明白了一件困擾我很多年的事情。就是作為乙個老師如何給他的學生指導。我的結論現在是這樣的，我舉例說明 1 老師要告訴學生怎麼樣使電腦啟動。你不會說 給電腦說英語open，不能使電腦啟動 你不會說 用棍子敲電腦，不能使電腦啟...