管理感悟：軟體的特性

管理感悟：軟體的特性

栁鯤鵬

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

硬體與軟體的差異

硬體	軟體
半成品出門	不能	能
有問題	退貨	完善
經常維護更新		受歡迎
功能無法按時完成	隻能延期	屏蔽功能，按計劃出
生産	有成本	完全無成本
開展市場	容易	困難
丢失市場

産品的三個階段

研發期

　技術原型階段。

　　示範階段。完善、測試的循環，直到能對外示範，緊急情況下可以賣給使用者湊合使用。到了這裡，才可以暫停。

　　産品階段。完善、測試的循環，直到能湊合用。注意，這裡的産品，能滿足基本使用，無嚴重問題。

産品成熟期

　　不存在

維護更新期

意見、讨論、修改、更新的循環。

怎樣正确認識使用者需求

使用者需求三原則

1. 産品性能更好。
2. 産品價格更便宜。
3. 産品讓自己更省事。

使用者不知道什麼

1. 不知道技術細節。
2. 不知道産品細節。
3. 不知道功能細節。

關于使用者需求的錯誤觀念

1. 以為使用者知道自己想要什麼東西，東西的各種細節。
2. 把使用者言論當作聖旨，不會分析是否合理、真實意圖。
3. 以為使用者看了東西，能一次性把問題說全（所有問題，每個問題細節）。
4. 以為使用者的想法一成不變，發生了變化就惱羞成怒。
5. 動辄打着使用者的名義。
6. 迷信文檔。等着使用者列出詳細文檔；以為有了文檔，什麼都清楚确定了。

産品決定需求

1. 開發産品，真實原因在于，我們認為使用者想要什麼，而不是使用者告訴我們。這是因為使用者需求三原則在指導我們。
2. 需求實際上是由産品确定的。沒有産品時信口開河，有了産品實際上是被産品引導、限制。

歸根結底，先讓對方使用産品。之後關于需求的主動權就轉移到軟體方。

　　這聽起來很不可思議，實際上想想，軟體維護更新是誰決定的？使用者反映的問題，要不要解決、哪個版本解決，都是軟體方決定的。

怎麼看待軟體産品

産品的觀念

大多數人是沒有産品觀念的，問題的關鍵在于，都以為自己有産品觀念。

 産品有什麼問題，視而不見，就是典型的例子。有産品觀念的人，看産品處處是問題；無此觀念的人，一旦沒告知，就不知道要幹什麼。

 作為一個普通員工，有沒有關系不大。作為一個決策者，必須具有産品觀念。

 産品在我心中：

 産品大體上什麼樣子，具備哪些功能。

 什麼條件下能将就出門。

 産品有什麼問題，下一步要做什麼。

更換軟體的可能性

　　對于個人很容易？也不好說。一旦用一段時間，就會形成信賴。

　　對于大集團使用者：

1. 求穩。
2. 換人不換衣，表面上看起來要差不多。普通使用者感覺不到變化。

　是以對于大集團，除非萬不得已，不會更換。也就是說，大集團使用者一旦拿下，隻要不犯大錯誤，市場就是穩定的。

功能與執行

一般來講，簽字（簽訂合同）了就必須嚴格執行。

而在軟體業，延遲是很常見的事情。于是問題就産生了。

簽字了不一定執行

　　簽字了是不是就一定要執行？

　　不一定。根據時間、技術難度、臨時情況等等，可以隻做一部分就算完成。

不簽字的也能緊急加入

　　不簽字的功能，是不是就一定不能加？

　　不一定。要看具體情況。

各方及時通報情況

 首先，即使軟體經常延期，導緻功能完成不了，我們工作中依然要想方設法的保證進度、功能。而不是心安理得的延期。

 對方提出新功能，如果涉及到新的技術，一定不能明确答應。一定要等技術原型出來之後，再做答複。也許一個很小的功能，要耗費大量的人力時間。

比如哪個功能無法按時完成，要及時通報，看看如何補救。

 同樣的，新的功能要求緊急加入，也是越早越好。

如何有效避免

　　對于新功能，都不要當場答複。因為有可能涉及到新的技術或方案。一定要等技術原型出來之後，才能給予答複。

　　如何有效的安排研發工作。

　　如何有效的管理研發工作。

軟體與加班

　　做軟體，沒有不加班趕工的情形。

　　如果不是長期，那也是呈現波浪形的加班周期。

　　如果沒有加班，那說明了上司層存在嚴重失誤。

為什麼軟體要加班？

　　功能的變化性。

　　軟體的複雜性。發現的BUG最好解決，麻煩的是偶現，而且是很難複現的那種。不過 大多數程式員發現的都解決不完。為什麼呢？

　　能力的不足。雖然技術人員覺得自己很厲害，實際上并不是這樣。而天才級别是請不到的，是以必須加班趕工。

不懂技術怎麼管理

兩個關鍵

　　首先，一定不要被技術吓住，也不要被需求、文檔、方案吓住。這些東西跟上司無關。

　　其次，一定要抓住重點工作，重點項目、重點功能。

如何安排研發

　　在軟體行業，目标無法按時完成，實際上是常态。延期了如何不影響商務？

　　工作安排上，要采取“先重後輕”的原則：

1. 前期做關鍵的工作，即重點、難點。
2. 把關鍵人力（技術能手）投入到關鍵的工作。特别是要避免雜事分散其精力。
3. 前期工作要多安排，突擊趕工。

項目與工期

以項目為條理，采取項目負責制。

　　要求研發列出詳細的功能點清單及計劃。當然這個是參考，不可能是全部。

　　研發、測試、試用、完善要同步進行。注意是并行，不是串行。

　　嚴格控制工期。一旦超出計劃，立即着手縮減功能。

分階段推進，及時互動

　　每次前進一步，及時與買方互動。

　　盡可能每次會談都有進展。