[心得] SCRUM:用一半的時間,做兩倍的事
書名: SCRUM:用一半的時間,做兩倍的事
推薦指數:★★★★☆
購買連結: https://bit.ly/3vun2Tp
今天介紹的這本書是要介紹一個近年很流行的工作方法
過去我們會把一個專案拆成好幾個所需完成的工作
並詳細的說明每個工作會需要花費多少時間
但是大家或許會注意到
以往的方法所預估的時間差異往往過大
你可能預估這件事情完成只需兩小時
但實際完成卻花了二十小時或是二十分鐘
而過去的方法之所以失敗的原因就是
事情發展往往超乎想像
而書中的這套方法:Scrum
則把不確定性和創造性都納入考量
並不斷地滾動式修正
讓專案執行的速度越來越快且達成需求
那怎麼做呢?
首先,必須規劃出「衝刺」的期間
在書中一開始的例子
是以兩個禮拜作為一個循環
每個循環就是一次衝刺
在循環一開始的時候
團隊要開會決定在未來兩個星期中
他們能完成多少事情
每次衝刺結束後
團隊還要再開一次會
展現出大家在這一次循環當中完成甚麼工作
檢視有多少個項目已經被完成?
是否有列出太多工作沒有完成或是相反的狀況?
在這部分最重要的事情是「對自己的速度有基本的認知」
同時也需要提出問題給成員
「昨天你做了甚麼事情協助團隊完成本階段衝刺」
「今天你準備做甚麼事情來協助團隊完成本階段衝刺」
「有甚麼阻礙團隊前進的因素」
在專案管理中,有三個因素會造成時間的浪費
第一個是多工環境的切換
常常大家可能手上不只一件案子
然而本書建議大家一次只做一件事情
千萬不要A做一點就做B
B做一點就做C
人腦在切換環境的過程中需要一點時間適應
在過去的研究當中
假設你有五個專案在同時執行
那實際上會有75%的時間被浪費掉
第二個是事情做一半等於沒有完成
如果沒辦法做出一個已完成的產品
讓使用者可以使用的產品
那這件事情等於沒有價值
也相當於花費了時間與心力卻沒有任何成果
那這輪衝刺就浪費掉了
第三個是第一次就把事情做對
有間軟體公司曾經做過一個紀錄
紀錄軟體開發人員發現錯誤的當下就把程式更正和事後再回來修改程式
兩者所花費的時間的差異
後來發現如果在當下就花一秒把錯誤修正
可以預防事後花24秒修改程式
這樣的浪費是非常巨大的
而這也是由於人體的生理結構所限制
當你在做某一個專案的時候
腦中會有該專案的詳細架構與流程
但是當你轉換了幾個專案
事後再來回想
大腦需要花費更長的時間來重新組織進入狀況
最後本書有個概念我認為很值得一提
百分之八十的價值其實是來自於百分之二十的產品
但作者建議最好在有一點小功能就趕快拿給使用者試用得到回饋
這個概念稱為「最小可行產品」
如果是一台相機,可以設計一個能照相但還不能對焦的相機
你可能會聽到
「相機的機身很難拿」「快門鍵設計在詭異的地方」
這些評論都可以讓你在繼續設計以前先修改方向
得到更多的使用者滿意度
這本書在工作上也啟發了我很多
其實也如同先前介紹過的許多書一般
提醒你專注在適合的任務,提升工作效率
以免白白浪費了許多時間,卻十分低生產力
--
部門導入Scrum以來,每天早上站著開會30分鐘,週一開會討論t
ask 4小時,週五檢討task 4小時…有夠蠢!
是用一半時間做兩倍事沒錯 變相壓榨員工QQ
一半的時間拿來開會了 另外一半的時間你們要交出
全部的成果 非常棒的敏捷思維
看你覺得敏捷是正面的或者是負面的就知道你在團隊的
腳色是甚麼了
真的是寫的比唱的好聽
敏捷不是萬靈丹 可是你們部門把敏捷完成那樣是你們的
問題吧XD
我是小碼農 所以不用質疑我在團隊的角色
敏捷的精神是早決定早檢討早修正 開會開成這樣已經
走偏了吧
只有學到皮 沒有學到骨XD
事情做越快越做不完xd
敏捷方法對抗的是公司文化,公司文化不改變,敏捷的優勢出
不來
19
Re: [討論] 大家公司產品的Release週期都多長阿先快速回答這題的答案, 我待過的不同團隊有兩週上線一次、每天上版的, 也有一天上很多次(每個人都可以 deploy)的團隊。 原文下面的推文也滿多人提到跟工作方法或產品型態有關, 我寫了一篇文章來分享自己過去在團隊做 Release Management 的經驗,19
[心得] 數據分析_多家面試心得(二)繼上一篇: — 離2/14 正式離職剛好滿一個月,從離職隔天我就開始狂投海投履歷(真的是字面上的意 思,狂投、海投),大概在三天前開始收到Offer,趁還有一點微弱記憶記錄一下這個月 的面試。15
[心得] 產品上線規劃:分階段Release網站的流程之前有在板上分享我們每天上版、一些 deployment, release 流程介紹, 最近又寫了一篇文章則來從 PM 做產品管理的角度分享, 該如何針對一個新功能、流程改動來做產品上線規劃, 以及前篇文章提到的階段性釋出的工具、方法與工作細節。 文章內容包含:15
[心得] 最有生產力的一年 真正可行的建議這本書的名聲已經響亮很久了,最近終於買來讀完 我覺得非常有啟發,而且書中的做法是真實可行的 搭配另一本神書《原子習慣》,我自己開始執行裡面的內容,感覺還滿好的 這邊推薦給大家~ 這邊有無廣告網誌版,看完也可以看看別篇文章:11
[心得] 讀書心得:你會問問題嗎?(文長慎入)大家好! 之前在本版分享心得的時候,有個網友推薦了我這本書。 我認為這本書非常值得推薦,也為了回饋本版,因此寫了一些心得來分享。 本來只想些一點,沒想到越寫越多,也懶得縮了,就這樣吧。 也希望有人可以分享自己的實務經驗讓我學習一下,感謝了。10
[心得] 產品經理、專案經理學習資源分享哈囉,我是《產品三眼怪》的 Anne,我們是幾位在網路產業工作的 PM,從去年開始定期在 Medium 上寫文章分享知識和職涯經驗。 自從開始分享文章後,常會有朋友請我推薦相關的書籍、線上課程、自我學習教材。這其實是個非常難回答的問題,一來是每個人的基礎不同,會需要的學習資源當然會不同;再來就是每間公司、每個產品團隊對產品經理的能力需求不同,因此真的不可能有一本書、一個課程讓人上完就可以克服所有的困難。尤其大家工作忙,也不可能所有資源都看過一次。 這篇文章,我會嘗試從「沒經驗、想轉職」和「有經驗」這兩種不同角度切入,分享我自己在不同階段的工作外學習與自我提升歷程。當然我自己最推薦的學習方式還是從工作中學習,畢竟無論學了多少東西,最終都是要運用在實務工作上的。 有圖有延伸閱讀的版本請到 Medium 閱讀:10
[心得] 產品經理、專案經理學習資源分享作者: annedoo (安安) 看板: Soft_Job 標題: [心得] 產品經理、專案經理學習資源分享 時間: Sun Oct 11 18:59:42 2020 哈囉,我是《產品三眼怪》的 Anne,我們是幾位在網路產業工作的 PM,從去年開始定期在 Medium 上寫文章分享知識和職涯經驗。 自從開始分享文章後,常會有朋友請我推薦相關的書籍、線上課程、自我學習教材。這其實是個非常難回答的問題,一來是每個人的基礎不同,會需要的學習資源當然會不同;再來就是每間公司、每個產品團隊對產品經理的能力需求不同,因此真的不可能有一本書、一個課程讓人上完就可以克服所有的困難。尤其大家工作忙,也不可能所有資源都看過一次。6
[討論] 如何改善產品團隊的工作流程?(PM角度)板友大家好,我跟朋友一起在網路上分享產品管理、專案管理相關知識與經驗, 最新一篇文章是分享新加入的 PM 如何幫助團隊改善工作流程。 Medium 好讀版(我會複製幾乎全文過來,想看一些參考資料/延伸閱讀再點吧!) 上篇文章《身為團隊第一個 PM 好難!我的辛酸血淚史與生存之道》中提到擔任團隊內第一個 PM 除了要肩負起做產品的責任外,優化團隊的工作流程也是很重要的一環。一來是團隊中多了 PM 這個角色加入後,大家的工作方法一定會有所不同;二來是要建立好的產品文化,一套好的工作流程絕對是不可或缺的。3
[心得] 《努力,但不費力》聰明做事的三種方法《努力,但不費力》讀後心得:聰明做事的三種方法 只做最重要的事,其實沒有你想的那麼難 圖文好讀 你覺得一個人要獲得成功,只有努力、努力再努力這條路嗎?你覺得重要的事情,一定都 很困難嗎?你覺得不重要的事情,一定都很簡單嗎?或許我們還有另外一種選擇,讓原本1
[心得] 產品 Beta Release、Feature Flags 分享之前有在板上分享上分享過每天上版的部署流程、單一功能釋出從功能拆解到分階段釋出的概念,這篇文章則會著重分享之前文中提到的 Beta Release、Feature Flags 的使用方法。 主要也是寫給 PM 看的,文章內容包含: - 適用 Feature Flags 的時機 - Beta Release 的流程規劃 - Beta Release 的受眾選擇、移除功能的做法、測後訪談方向