《軟體工程之美》打卡第三周
- 2020 年 2 月 18 日
- 筆記
這是筆者參加極客時間21天打卡行動第三周，三周的時間無間斷剛好21天，這21天里我強迫自己每天都要學習半個小時並寫100個字的分享，正是這樣的自律讓我找回以前的那種感覺，真的好久沒這樣認認真真做一件事情了。話不多說，下面是本周每日學習總結記錄：
第十五天
今天學習了寶玉老師的《軟體工程之美》中的「13 | 白天開會，加班寫程式碼的節奏怎麼破？」，以下是我的總結：
這節課的內容我感受不是很深，如果是正常的需求迭代，目標還是比較明確，所以不會存在太多無意義的開會。不過這個主題有一點我是比較認同的，就是開會是有成本的，而這個成本就是每個人員的單位時間成本。所以這個給我們提了個醒就是，開會必須是有價值的，而這個價值必須大於我們的成本，不然就造成浪費了。
那麼怎樣的會議是高效的？有以下幾點：
- 參會人員少
- 時間短
- 議題和目標明確
例如每日站會就比較符合這樣的標準。
既然開會有成本，怎麼降低開會的成本？
- 沒價值的會議不開 無目標、無法形成決策和行動指導的，跟你無關的基本可以砍掉。
- 減少參與會議的人數 只有相關人參加，容易達成一致目標。
- 縮短開會時間 限定討論的範圍，不做無意義的發散，事先有準備，把握節奏。
- 提升會議創造的價值 明確目標和主題，圍繞會議目的展開。如果會議內容跟自己無關緊要又必須參加，可以尋找其他能在會議做的事情來減少時間的損耗。
第十六天
今天學習了寶玉老師的《軟體工程之美》中的「14 | 項目管理工具：一切管理問題，都應思考能否通過工具解決」，以下是我的總結：
這節課說的管理問題主要是軟體項目中困擾項目經理和開發人員的一些問題，比如任務進度量化的問題，項目進展不夠直觀，項目經理需要耗費很大的精力去做任務管理等。
項目管理工具軟體發展史
階段一：沒有工具的年代
去管理項目確實是非常耗費精力，比如阿波羅項目，需要專業人士花大量時間和精力去制定計劃和調整計劃。
階段二：項目計劃工具
在瀑布模型為主軟體項目，才出現了相對容易制定計劃的項目計劃工具，比如微軟的MS Project，但存在不方便跟蹤任務進度，進度不直觀的缺點。
階段三：基於Ticket的任務跟蹤系統
傳統項目計劃工具不能解決具體的任務跟蹤狀態，後面才有了基於Ticket的任務跟蹤系統，從用來跟蹤bug逐步衍出跟蹤需求和開發任務等功能。但缺點是不能直觀看到哪些任務的狀態。
階段四：基於看板的可視化任務管理
可以很直觀的看到不同的任務處於什麼狀態，項目經理和項目成員都可以很直觀看到進展。
第十七天
今天學習了寶玉老師的《軟體工程之美》中的「15 | 風險管理：不能盲目樂觀，凡事都應該有B計劃」，以下是我的總結：
風險管理的重要性不容忽視，如果軟體項目沒有做風險管理，造成的後果輕則項目不能按時完成，重則造成無法挽回的經濟損失，拼多多被「薅羊毛」事件就是風險管理不到位的典型案例。
應對風險的幾個層次：
- 被動應對：風險已經發生，造成了問題才被動應對；
- 有備無患：事先制定好風險發生後的補救方案，但沒有任何防範措施；
- 防患於未然：對可能發生的風險作出防範，並把風險防範作為項目任務的一部分。
做好風險管理需要做好以下幾點：
- 培養風險意識 不能盲目樂觀，思考最壞的情形，提前做好Plan B。
- 管理風險 管理風險有四步： 2.1 風險識別 軟體項目的風險有以下幾類：
- 項目風險：項目預算、進度、用戶和需求等方面問題；
- 人員風險：人員離職、人手不足等問題；
- 技術風險：採用技術所可能帶來的風險；
- 商業風險：與市場、產品策略等有關商業風險。
可以按照上面的分類整理出自己的風險檢查表。
2.2 風險量化
風險發生的概率和發生後後果的嚴重程度，概率大和後果嚴重的應該以優先順序去重點考慮。
2.3 應對計劃
一張圖解釋如何應對風險，我們可以根據實際情況來選擇應對策略，減少可能的損失。
2.4 風險監控
要做好監控，有以下三點：
- 第一要能對監控內容良好
- 第二要設置閾值
- 第三要有後續的報警和處理機制
這就就比如我們會監控線上版本的Crash率，設定告警的閾值，比如2%，超過這個閾值我們就告警，相關開發人員要及時處理線上的Crash，通過熱更新解決Bug來將Crash率維持閾值以下。
這個主題其實開發人員感受可能不會很深，我們日常更多是基於需求去評估單個需求完成可能存在的風險，比如技術選型和人力成本這些方面去考量，但對項目整體來看，要把需求都變得可控，所以風險管理就很重要，如果前期評估出了風險，可以通過砍需求或者延長時間來降低風險。但對於開發人員如果能全局去培養自己的風險意識，這樣能很大程度幫助團隊一起規避不必要的風險，防患於未然。
第十八天
今天學習了寶玉老師的《軟體工程之美》中的「16 | 怎樣才能寫好項目文檔？」，以下是我的總結：
我個人是比較偏向寫文檔的，很多程式設計師不願意寫文檔，無非就以下幾個原因：
- 不知道怎麼寫
- 太忙沒時間寫或者懶得寫
- 覺得文檔無用，價值不高
從這篇文章學習的內容，更加堅定了我對寫文檔的重要性的態度：
- 文檔能夠幫助自己理清思路
- 方便未來的維護和交接，最明顯的是新人可能更快的融入團隊，減少口口相傳
- 團隊更好的協作溝通
如何寫好文檔？
- 從模仿開始，參考別人是怎麼寫的
- 從簡單開始，不要求一下子寫大而全的文檔
- 從粗到細，迭代更新
- 一圖勝千言，能用圖說明清楚的就不用文字，常用的有線框圖、流程圖、時序圖、各種格式的截圖等。
這一節我感受比較深，因為最近我也在幫助團隊整理項目文檔，因為我作為新人加入項目基本知道我缺什麼東西，需要了解什麼東西，如果之前有文檔估計我可以更快融入團隊和發揮自己的價值。
第十九天
今天學習了寶玉老師的《軟體工程之美》中的「17 | 需求分析到底要分析什麼？怎麼分析？」，以下是我的總結：
這節課的資訊量很大，需求分析說實話工程師參與的並不多，更多是產品經理將需求分析過後的翻譯成我們能夠理解的需求單。需求的重要性不用多說，只有真正理解用戶的需求，我們才能做出觸及用戶內心訴求的產品。寶玉老師這節課提到了很多讓我很受益的知識和觀點，比如做需求分析的一些步驟：
- 收集需求
- 頭腦風暴
- 用戶調研
- 競品分析
- 快速原型
- 分析需求
- 表層需求：用戶對解決問題的期望
- 深層需求：用戶的深層動機，訴求產生的原因
- 底層需求：人性本能的需求
- 需求評估
- 可行性：技術能否實現
- 成本：人工成本、時間成本
- 商業風險和收益：有沒有商業的風險，收益是否合理
- 緊急性與重要性：是不是用戶迫切的需求
- 評估其優先順序：緊急重要四象限
- 需求設計
- 驗證需求
在日常工作中，其實產品最終效果不明顯很大程度就是沒有做好需求分析，沒有深入理解真實的用戶需求，一種好的基於數據驗證需求實踐——AB Test，通過數據驅動來分析需求。
第二十天
今天學習了寶玉老師的《軟體工程之美》中的「18 | 原型設計：如何用最小的代價完成產品特性？」，以下是我的總結：
原型設計經歷了三個階段：
- 低保真原型設計
- 中等保真原型設計
- 高保真原型設計
目前原型設計已經從一種快速開發模式演進成了設計工具，產品經理可以低成本、高效率的做出軟體原型，便於更好的確認產品需求。
如何做好原型設計？分為以下四個部分：
- 分析：原型設計的目標是什麼，搞清楚用戶的需求
- 設計：從資訊架構和使用流程兩個維度去考量
- 實施：在設計的基礎上通過原型工具進行介面搭建
- 驗證：產品經理反覆驗證流程，調整存在走不通或者使用不方便的地方進行調整。
選擇合適的原型設計工具的幾個考慮維度
- 面向的平台：Web、桌面、手機；
- 保真度：
- 中等保真度還是高保真度；
- 功能：是否滿足你的要求；
- 成本：價錢是否可以接受。
寶玉老師推薦了幾款原型設計工具，可以結合自身的需求來選擇：
- Axure RP
- 墨刀
- Adobe XD
- ProtoPie
- Framer X
這節課內容更偏向產品設計，開發人員可能日常比較少參與原型設計，不過作為一個有追求的程式設計師，提升自己的產品設計能力也有助於我們用產品的視角來看待用戶需求，也能更好的跟產品經理進行溝通協作。
第二十一天
今天學習了寶玉老師的《軟體工程之美》中的「19 | 作為程式設計師，你應該有產品意識」，以下是我的總結：
https://time.geekbang.org/column/article/89480
這節課很值得所有程式設計師都學習一下，裡面的理念跟我一直貫徹的不謀而合。程式設計師的價值體現在兩個方面：
- 體現在產品之上
- 團隊中的稀缺性
程式設計師的價值不在於技術水平，而是通過技術給產品進行賦能。
產品意識是很多程式設計師都欠缺的，因為他是一種思維方式，需要站在產品角度去思考問題。產品意識包含：
- 商業意識（ 產品需要有商業價值，簡單來說是能賺錢）
- 用戶意識（良好的用戶體驗，有同理心）
- 數據意識（數據驅動去發現問題和驗證結果）
培養產品意識寶玉老師提到：
- 首先要解放思想，從產品角度分析產品，關注用戶體驗，關注功能所創造的價值
- 然後改變習慣，從關注技術細節轉變成關注用戶體驗，關注產品創造的價值、使用場景等
- 最後要多實踐，業餘實踐做些原型，收集用戶的使用意見，感受產品視角帶來的感悟
最後
21天的打卡行動，就在春節的大年初二完成了，打卡雖然結束，但學習行動並未結束。軟體工程之美這個專欄是今年的第一個學習專欄，很有價值，裡面是寶玉老師的經驗之道，也提供了很多術和器。學習真的貴在堅持，打卡雖然看起來是個很傻的事情，但我們總是高估了自己自律性，而低估了自己的惰性。下周我們繼續不間斷打卡，直到完成今年的Flag。
