顯示具有 career 標籤的文章。 顯示所有文章
顯示具有 career 標籤的文章。 顯示所有文章

2020年12月19日

軟體人必讀的十大好書之一 Soft Skills :The Software Developer's Life Manual 出第二版了 ( Kindle 版特價中 )

顧及軟體人實際生活與職涯的好書。 現在 Kindle 版本只需要 USD10.49

  
總共有 7 個章節,以下不完全翻譯,因為這一整本是英文書,如果以下的敘述對你有些難度,本書會是你的英文學習本,會花很多時間閱讀,不過作者建議先 Skim(快速瀏覽),從你有興趣的章節來看也是可以的,以下是作者透露的內容,光看內容就可以給我們很多啟發囉 ~ 

Section 1: Take your career to the next level 
 

  • The #1 reason why you need to treat your career like a business. Skip this and you’ll regret it like I did early on    為什麼要對待你的職業等同你的事業


 

  • How to set good career goals. Set the wrong goals and you can set yourself back further than you started    如何訂定職業目標


 

  • Why you need to develop soft skills to get an advantage. Competition has increased greatly and this is your edge          為什麼你需要軟技能以獲得優勢


 

  • Why most software development resumes suck. How to get your foot in the door using the 4 Hour Workweek method     為什麼大多數軟體開發履歷都很糟糕


 

  • How to hack job interviews. You don’t need to enter through the front door. Learn how much easier it is through the backdoor      如何成為工作面試駭客


 

  • The three software development career paths. Which one you choose will dramatically change your life outcome      3 種軟體開發職涯路徑


 

  • Should you specialize or be a generalist? Find out why one path is much harder than the other      應該精通還是成為通才 ? 


 

  • What types of companies should you work for? Even the right person in the wrong place can make no difference       應該為哪類公司工作 ?


 

  • Want to climb the corporate ladder quickly? Follow these steps to avoid a world of pain and the hidden pitfalls        如何在職涯階梯快速升遷 ? 


 

  • Are you a professional or pretending to be one? Learn how to not come across like an amateur           你是真的專業還是假裝的 ?  學習如何不會像個業餘的 


 

  • Should you get married to your tech stack? Let me tell you why you should not get religious with technology      你應該忠於你現有的技術堆棧嗎 ? 


 

  • How to quit your job and work for yourself like I did. I wish I knew this before I set off on my own       如何離開朝九晚五的工作開始如作者一樣完全為自己工作 ?


 

  • How to get started in freelancing. Find out if you're you cut out for the digital nomad life        如何開始你的自由工作生涯 ? 


 

  • Want to become a product entrepreneur? How to find the right audience for your idea           想成為產品企業家,找到對的受眾 ? 


 

  • How to start a Startup. The zero to 100 strategy for avoiding the risky parts.  如何開始你的新創,避免風險的從零到一百的策略


 

  • How to work remotely without working yourself to the bone. The world's shifting to the gig economy and are you prepared?   如何遠端工作仍能游刃有餘 ?

 
Section 2: Time to Market yourself for big returns 
 

  • Why you need to market yourself to stand out from the crowd. The pillars of good marketing in software development     你為什麼需要自我行銷以脫穎而出。在軟體開發的出色行銷支柱


 

  • How to build your personal brand from scratch. Without sounding too salesy or cliche           如何從頭建立你的個人品牌


 

  • Should you create your own blog? How to actually make a successful blog     你應該建立你的個人部落格嗎 ? 


 

  • Should you create your brand on YouTube? Is there a point when so many people already do it?       你應該在 YouTube 上建立你的品牌 ? 


 

  • Do you know how to add value to others? How to get what you want by giving people what they want        你知道如何為別人提升價值 ?  如何藉由給予別人想要的獲得你想要的 ?


 

  • The mystery of social media unveiled. Use social media to grow your brand and become an authority figure     社交媒體揭發的秘密


 

  • Scared of public speaking or presenting? Why this is one of the most effective ways to connect with people          害怕公眾演說嗎 ? 


 

  • Should you write a book or write a bunch of articles? Does it still matter nowadays?        你應該寫一本書或寫一大堆文章 ? 



Section 3: It’s time to learn how to learn. Learnception. 
 


 

  • My 10 step process to learn anything quickly.    我的快速學習 10 步


 

  • Want to shortcut your success in any field? How to find the right mentor and avoid the bad ones     想知道在任何領域成功的捷徑 ? 


 

  • When should YOU become a mentor and how to find the right apprentice   什麼時候你應該成為輔導師找到對的學徒?


 

  • Why teaching is one of the best ways to grow your skills and make an impact   為什麼教學是讓你的技能成長與發揮影響力最好的途徑?


 

  • Do you need a college degree to be successful in software development?   你需要大學文憑在軟體開發領域成功嗎 ? 

 

  • What you need to do when there are gaps in your knowledge    當有知識落差時你需要做什麼 ? 


Section 4: Let’s get productive in here
 

  • Productivity starts with one key element. Get this wrong and you’ll overwhelm yourself           生產力來自一個關鍵元素,錯了就讓自己難以招架


 

  • My personal productivity plan for you to use and implement right away    我個人生產力計畫供你馬上利用


 

  • How to use the tomato technique to boost your productivity. Proven to work time and time again    如何運用番茄工作法


 

  • How to keep yourself accountable and become a finisher. Why you don’t have to be better than your competition     如何讓你令人信任並總是使命必達


 

  • Why multitasking is the devil to productivity. Avoid this at all cost if you want to succeed       為什麼多工是生產力的魔鬼


 

  • Want to avoid burnout the right way? How to breakthrough and keep going when you don’t feel like it      想避免太快精疲力竭?


 

  • Are you wasting too much time? Here’s what to do to get back on track   你浪費太多時間 ? 


 

  • Do you have a routine or do you rely too much on motivation? Here’s how to create a detailed routine for yourself     你有例行習慣還是需要很多的激勵 ? 


 

  • How to develop effective habits and alter bad habits. 如何發展有效率的習慣並改變壞習慣?


 

  • Why do we avoid hard work when we know it will benefit us? How to avoid procrastination and actually work sharp    如何避免拖延症和真正敏銳工作


 

  • Why is inaction the killer of productivity? What can you do to create momentum again       為什麼不作為是生產力的殺手? 什麼能讓你再創動力 ? 



Section 5: The financial side of software development 

 

  • How to be smart with your paycheck. Why you shouldn’t buy a car with your first paycheck         如何聰明對待你辛苦賺到的錢 ? 


 

  • How to negotiate your salary. Learn the basics of good negotiation to more zeros on your salary      如何做薪資談判 ?


 

  • Why real estate is the best long term investment. Why it’s not that hard to get into    為什麼不動產是最好的長期投資? 


 

  • Do you understand your retirement plan? What to do if you’re stuck in the middle or close to retirement    你對自己的退休計畫做過盤算嗎 ? 


 

  • The dangers of debt. Is all debt bad? Which debt should you avoid or pay off first? Find out in this chapter        債務的危險


   

  • How to build true wealth with triangles. This is my secret to making the well never run dry          如何用三角定律建立真正的財富 - 永不枯竭


 

  • My personal story of how I “retired” at 33.  From a regular job to gumball machines and more       我如何在 33 歲就退休的個人故事


Section 6: The often overlooked Health and fitness 

 

  • The benefits of being fit. From a longer lifespan to being more attractive and others   健康生活型態的益處 


 

  • Setting your fitness goals. How to set effective milestones to reach your goals  設定你健身目標


 

  • How to lose weight or gain it. My simple breakdown for you to use right away   如何減重或增重


 

  • How to get and stay motivated. How to use gamification to stay motivated   如何獲得並持續充滿動力


 

  • Gaining muscle. Go from soft to powerful with my workout fundamentals    獲得肌肉


 

  • Getting those 6 pack abs. When and how to actually get abs. Where it starts and how to get them quickly      如何練出腹肌


 

  • Getting started running. My personal advice on how to get started and make it actually… fun?        作者個人經驗忠告 - 如何開始跑步運動並感到有趣


 

  • My secret to losing fat and gaining muscle at the same time? Is it even possible?      作者減重的同時增加肌肉的秘密  


 

  • My little hacks for gaining muscle and losing weight.   增加肌肉與減重的秘訣


 

  • Using technology to get fit. My favorite apps and devices to help you reach your fitness goals     健身的科技 : APPS 和裝置


Section 7: Cultivate your mindset for success 
 

  • How the mind influences the body. Why everything you do starts with the mind first  心智如何影響身體


 

  • It starts with a positive mindset. How to reboot your attitude for greater benefits in every area of life   如何重新啟動你的心態以在生活每個領域都變得更好


 

  • How to change your self image. How to reprogram your brain and change your reality    如何改變你的自我形象 ( 你對自己實相的認知 )  


 

  • Why software developers have a hard time finding love and relationships. What you can do to remedy this    為什麼軟體開發者在尋找愛和關係會遇到困難?


 

  • My personal success book list. Read these to radically change your perception and mindset    我個人的成功書籍列表


 

  • How to stop fearing failure. What failure is a good thing and you should open your mind to more    如何停止害怕失敗,你應該開放迎接失敗


 

  • Getting out of your comfort zone. Why it's actually OK to feel like an idiot   走出你的舒適圈


 

  • Stoic philosophy and how it can change your life. How to become a stoic and become invincible when tackling life’s hardships    斯多葛哲學以及它能如何改變你的人生


 

  • And much more...






2009年11月18日

Lean Software Development的七個原則與管理觀念

在agilesoftwaredevelopment.com看到一篇Seven Principles of Lean Software Development才知道原來Agile Software Development和日本製造的JIT有這樣的淵源關係. 依據作者的說法:日本最賺錢的汽車製造商Toyota運用JIT(Just-in-Time)在生產製造上大幅領先同業. Taiichi Ohuno(大野耐一)-JIT創始人,寫了多本相關JIT的書, 最有名的Toyota Proudction System,成為美國Lean Manufacturing的基礎. 在軟體產業上, 則啟發了Lean Software Development(精簡軟體開發)的觀念, 而Lean Software Development醞釀了Agile Software Development Method的兩個分支ScrumCrystal Clear.
















在Lean Software Development中以
Mary and Tom Poppendieck著的書最有名.
在他們著的書中 "Implementing Lean Software Development - from Concept to Cash"(Mary and Tom Poppendieck著作)提出7個實作Lean的原則, 呼應JIT的觀念, 且反應軟體開發的特質. Lean Software Development背後的想法是: 讓客戶在還沒有清楚資訊以供做正確的決定前, 儘量延後"定型". 不過只要客戶一提出要求, 開發團隊可迅速做出客戶所要的, 在客戶來不及改變主意前出貨給他. 這個作法, 就如我們線上一下單購物, 隔天東西就寄來了, 大多收貨者都不會說要退貨或做任何變更.

這七個Lean的原則是:


1. 避免浪費


JIT的「徹底的なムダの排除」(徹底排除浪費), 只要在客戶看來沒有任何附加價值的過程或產出都被視為浪費. 軟體開發的七浪費:
  • Particaly Done Work (開發過程中的預先完成品)
  • Extra Processes(以文件中心來管理的開發最容易有這種現象)
  • Extra Features(應該只開發客戶要的功能)
  • Task Switching(每人應一次只專心完成一件事)
  • Waiting(等待指示或簽核, 等待資訊..)
  • Handoffs(換手的過程一些默認的知識很有可能跟著遺失)
  • Defects(無法馬上測到的問題)
實行重點:
  • 結合市場與技術領導 -整合市場與技術的專家才有可能激發出先進創新的產品. 你必須了解什麼是對你的客戶有價值, 以及你擁有或可以採用什麼技術來實現.
  • 僅聚焦於價值鏈- 小心過分的流程改造, 確定這些流程是你必須的, 你應該聚焦在可以創造價值的流程. (想到軟體專案界常講的CMMI嗎? "裁適"應該比"完美"來得重要)
  • 精簡程式碼 - 越多程式碼相對需要越多的測試,如此增加工作量. 所以如果有的功能沒必要, 就不要浪費時間在上面.
由上看來, 也許我們可以想想自己的團隊是否有以下的問題:
  • 是否有例行的報表, 會議, 或文件但無濟於價值創造呢?
  • 每個人寫的codes在專案範疇內嗎?
  • 需求分析有切中要領, 規劃出真正對客戶有價值的東西嗎?
  • 是否能將工作儘量獨立切分, 平行運作, 避免相依?
  • 如何從coding的品質要求, 即早發現瑕疵?
  • 團隊溝通是否要跑很冗長的流程, 有辦法達到如神經組織般的溝通效能?

2. 增強學習能力

軟體開發這途需要不斷精進技術, 也面臨團隊和專案的scale挑戰, 客戶需求變更的不確定性, 和是否熟悉domain know-how的問題. 所以
  • "增強學習能力"是改善軟體開發競爭力的最佳法門.
  • 避免累積瑕疵, 最好是控管coding的品質或一寫好馬上測試
  • 與其寫很多文件或做詳細的計畫, 不如儘快寫code跟做個build來測試一下想法是否行得通
  • 客戶需求的收集與整理應簡單明瞭,建議以screens的方式與終端使用者討論需求
  • 運用短的開發循環週期(short, full-cycle)來加速學習過程--短週期指的是一個星期到一個月的週期, 每個週期都應做出working software, 週期應包含重構(refactoring)和整合測試(integration testing)
  • 簡短且多次地和客戶溝通, 讓開發者與客戶雙方頻繁的對話, 可清楚釐清現階段應投入的功夫(efforts), 以及未來改進的方向. 客戶可以就每次開發團隊完成的結果更明確給與意見, 開發者也可在多次客戶回饋中更釐清domain know-how以及如何做才能滿足客戶.
實行重點:
  • 建立有設計能力的建築團隊 - 開發團隊的領導者必須能傾聽團隊成員的聲音並聰明提問讓所有成員有辦法很快地自己找答案或解決問題, 或醞釀更新更好的解決方法- 創造一個可以讓人們在工作中持續改善的環境, 他們應該被知會沒有最完美的, 永遠有更好的方法, 且一定要不斷改善別無他途.
  • 培訓問題解決技巧 -開發團隊應該像小的研究單位, 其應該有辦法建立假設, 然後快速執行實驗求證.
由上看來, 也許我們應考慮一下:
  • 團隊是否做daily build?
  • 如何控管coding的品質? 個人能力和自我把關? 有coding style的check或輔助工具?
  • 如何才能即時方便地有記錄地和客戶討論需求, 報告進度, 或做需求變更, 瑕疵回報,文件分享並讓所有參與者知悉呢?
  • 如何才能切出可掌控的工作大小, 排出有效的開發循環週期, 而其中的refactory和integration testing的準則和方法又是什麼?
  • 如何建立持續改善的機制和環境?

3. 儘量延遲決策

軟體開發不確定的變數很多, 在剛開始時很難預測後面的變化, 所以建議儘量多留活口, 採用options-based approach. 應該根據事實而非根據假設來做決策. 不到清楚明朗, 最後關頭, 都要留多個選項. 另一方法是運用iterative approach(如上述的short, full-cycle), 來應變軟體不可避免的需求變更和機動修正錯誤.

實行重點:
  • 到最後關頭才做無法逆轉的決定 - 你應該要知道往哪裡去但你有可能不知道應走哪條路, 但有可能越走越清楚. 最重要的是要往正確的方向走.
  • 打散依賴度 - 元件的關聯應該越鬆越好, 如此才可以任意的次序來開發.
  • 保持彈性 -所有關鍵決策開發多種解決方案以便能從中挑出最好的. 運用Set Based Development的方法:儘可能拆解"產品生產"為可平行運作的"零件生產", 並清楚定義各零件間的整合介面. 如此您可以多頭同時進行, 每個零件也可有多種生產進行的方法. 到要整合的時候, 您將更清楚如何定義這些零件間的整合介面, 且有多種選擇以做出最佳的產品.
建議增加彈性的一些可行方法:
  • 將部分完成的設計資訊分享(不只是團隊內, 也可以權限分級的分享給客戶)
  • 建立團隊每位成員能直接溝通的協同作業機制
  • 建立何時應該做決策的共識
  • 建立如何吸收變更的共識(避免重複, 分散關連, 打包變數, 延遲使用未來開發資源)
  • 致力於重構(refactoring)
  • 採用自動化測試工具

4.
儘快出版

儘快出版的目的是讓您的客戶能在最佳的資訊了解狀態下做最好的決策. 一旦客戶一決策, 您的團隊就能很快提供一個可用的版本. 以市場觀點來看, 越快將沒啥大問題的產品上市讓客戶使用, 可以越早獲得客戶的回饋, 併入下一輪開發排程中. 越短的開發週期, 能越快讓開發團隊從市場獲得即時的資訊, 也讓團隊有辦法快速應變市場的變化. 採取可快速應變後續變動的短週期開發法, 才能降低貿然決策後所遇到客戶或市場需求轉向所造成的衝擊.

實行重點:
  • 以小批生產方式 - 切割專案成多個release cycles,讓每次release間隔不要太長, 保持開發的速度與穩定的開發環境, 如發現窒礙的原因和作法, 請儘量移除.
  • 就資源安排適量工作 - 儘量減少排隊等待的工作(在一兩個iteration後來做還可以), 建議如果要排很久才會輪到的工作, 可以考慮直接排到下一輪, 且如果自己的list裡還有等待自己完成的工作, 就應該拒絕接新的工作.
  • 聚焦 cycle time而非利用人力到最大限度 - 在排程中應該將工作切割成小量, 儘量減少因需時太長而看不到工作完成日的問題. 請降低每一iteration的需時, 將每個工作範圍切少一些, 減少排隊等待完成的工作.

5. 授權與尊重

相較傳統的命令式管理, Work-out技巧已被很多有經驗的經理人證實, 反過來做的成功率比較大, 讓你的組員深入參與並決定怎麼做比較好, 自己給commitment, 經理人僅提供如何加強或改進的建議. 如果回顧管理的歷史(請參考
Mary Poppendieck走過歷史的演說 The role of leadership in software development), 團隊成員不應只被當reources(資源)看待, 並不是給成員工作的list, 然後就可以完成. 激勵(Motivation), 知道為什麼而做, 以及時常的溝通, 讓成員知道所有相關工作者正在發生什麼事, 對於整體的工作士氣會有很大的幫助. 另外, Lean Software Development很鼓勵讓開發者直接面對客戶,如此開發者對於domain kow-how, 以及自己到底為什麼而做, 會有更深的感觸. 而團隊領導者應提供所有團隊成員應有的支援和幫助, 以克服困難, 維持團隊的合作默契和士氣. 至於所有的團隊成員, 應該給與他們在什麼情況下如何應付的經驗分享和培訓, 已幫助他們做正確的決定.

實行重點:
  • 訓練團隊領導者和專家- 訓練你的團隊領導者和專家, 讓他們有能力分享他們的專業, 訓練組員, 建立可實行Lean的環境.
  • 將責任與決策權轉移到有可能的最底層- 讓你的人自己思考和決定, 他們應該知道如何運用複雜的演算法或運用完美的軟體架構來寫程式與運用完美的軟體架構.
  • 加強工藝的自豪感 - 鼓勵團隊成員熱情的參與他們所有的執行工作與方法

6. 整體經驗

客戶對於軟體的感覺不是只有產品本身, 而是整體產品經驗(integrity), 一種是perceived integrity, 包含產品如何行銷, 出貨, 上線, 接觸, 直覺反應, 價格, 和問題解決經驗. 這是客戶不會告訴你的需求, 需要團隊本身細膩的市場觀察. 另外一種是conceptual integrity, 指系統每一零件的運作和合起來運作的在彈性度, 維護度, 效能, 回應效率等整體狀況是否協調,達到某一定的水準. 要達到令顧客滿意的程度一方面要靠對於問題領域有深度了解的基礎, 一方面要能同時快速解決, 而非要按順序一個一個解決. 所需的資料與其要等全部完整寫成一大篇文件或開冗長的會議,不如持續不斷的雙向溝通, 每次溝通的資訊可以是短短的,不浪費太多時間的. 儘量避免長久隔離後才一次給與大量資訊的方式, 這會讓雙方的溝通充滿挫折感, 也較難給客戶好的整體經驗.

實行重點:
  • 順暢詳細的資訊流 - 建立客戶, 使用者, 開發者間快速同步溝通的聯絡網. 正如Agile強調: Customer collaboration over contract negotiation.
  • 與人同步前的品質保證 - 為了讓你的軟體達到高品質, 你應該在一行程式都還沒寫之前就開始操心, 如果你是等到要與別人同步時才開始操心, 會很慘的.
  • 自動化 - 強調及早, 經常, 全面性的測試. 所以如果能夠自動化test, build, deploy,只要是例行作業都能自動化, 將有助於提昇 integrity.
  • 重構(Refactor) - 將程式碼複製降到"零"-每次運用程式重構, 測試, 或文件來降低複雜度

7.系統思考

如果我們去觀察大多數的管理理論, 多強調工作拆解後被分析出來的個個元素的最佳化. 但Lean thinking認為如果你從局部來做最佳化, 常常導致整體的次等化. 為何會這樣? 作者舉例, 如果你想要最佳化測試資源的運用, 那麼你將降低一定時間內整體產生測試過且可用code的數量. 此外, 就算你傾全力來降低個人的瑕疵, 還是避免不了一個有名的事實-80%的瑕疵來自系統工作方式, 也就是管理上的問題. 欲避免這樣的問題, 建議應該去鼓勵人與人之間的溝通協調, 著重"我能影響什麼"而非"我能控制什麼". 由高於"個人"一層來觀察, 如去看整個團隊的瑕疵數量, 而非去探討個人的瑕疵數量. 改善的方式與結果評量也以整體表現來考量. 要求系統思考的原因是: 作者發現加強個人並不會真的提高整體表現, 但發覺如果是整個團隊一起探討改進, 修改系統工作方式, 整體表現可以很顯著的提昇.

實行重點:
  • 聚焦於整體的價值鏈 - 專注於贏得整體的比賽, 不要只看到每個局部的改善, 要從整個組織產品整體來考量最佳化.
  • 完整的出貨 - 整個團隊需要好的領導也需要好的工程師, 業務, 市場專家, 助理秘書...全部合起來以最好產品和服務呈獻給客戶.

總而言之, Lean的基本想法是如果開發者能被尊重且互相有效的溝通協調, 這群開發者就比其他團隊更有可能做出好的產品來滿足客戶---- 聚焦人本與溝通協調.


如果你看上面那7個原則感覺還不夠的話, 建議看看Mary Poppendieck走過歷史的演說 The role of leadership in software development 應該可以更清楚了解整個Lean概念的啟蒙, 以下擷取幾張片段, 看過後應該有更深的感觸.


1. 對於傳統的MRP模式, 作者認為這不是working hard就能100%達到規劃好的進度.
沒有所謂的SOP, 只有how to constantly improve the way to get work done.




















2.第一個提出Perl管理專案概念的Polaris專案成功的原因並不歸功於Perl, 而是以下幾點:















3. 發現Mission Critical Job能夠成功做到不危及生命的Mind Set是:









<





4. US Army 發覺戰勝的Leadership應該是給mission command而不是detailed command. 重點在delegate(委派), 如果你要讓人發揮他的價值, 就要授權讓他思考判斷. 主要讓他知道What need to be achieved, 而不是What to do.

















5. 整個組織要訓練expert能分享他的經驗, 教育其他人, 在產品Concept到Cash的階段, 是個不斷Technology與Marketing marriage的collaboration和創造, 與知識的創造和分享.
















6. 你要找的是認知自己在建教堂的工人, 而不是認為他在切石頭或填飽肚子的工人.













參考資料:

Youtube: The role of leadership in software development

agilesoftwaredevelopment.com Seven Principles of Lean Software Development

Lean Software Development

Wikipedia: JIT生産システム

Wikipedia: Lean software development




2009年8月6日

Tom DeMarco的Software Engineering: An Idea Whose Time Has Come and Gone? 摘要與感想

在Google搜尋時, 剛好在網路上看到Tom Demarco於2009 IEEE 七八月刊的作品: Software Engineering: An Idea Whose Time Has Come and Gone? 很欣賞他連之前的自己都可以否定的勇氣. 我相信越有名, 要說自己以前是錯的越困難.

他在此文對於自己1982年寫的Controlling Software Projects: Management, Measurement, and Estimation(Prentice Hall, Yourdon Press出版),這本啟蒙軟工專案計畫與度量發展的重要作品, 重新評價:
"Do I still believe that metrics are a must for any successful software devleopment effort? My answers are no, no, and no."

還自己說這本書所傳達的message有誤:
"The book's deep message seems to be, metrics are good, more would be better, and most would be best. Today we all understand that software metrics cost money and time and must be used with careful moderation."
"The book's most quoted line is its first sentence: You can't control what you can't measure. This line contains a real truth, but I've become increasingly uncomfortable with my use of it. Implicit in the quote(and indeed in the book's title) is that control is an important aspect, maybe the most important, of any software project. But it isn't. "

他從專案的本質:一個投百萬可賺1.1百萬的案, 和一個投百萬可賺50百萬的案相比, 獲利能力低的案子相對需要較高的control才能成功, 來說明並非每個案子都要一樣的control程度. 那是否獲利低的案子反而要花更多錢跟時間去做measurement, 那利潤不就更低了. 這是做低獲利案的惡性循環. 也回歸到business model的問題, 為什麼要接這樣低利潤的案子?

另一方面, 他也提出人的品質是無法度量的, 你可以度量honor, dignity, discipline, personality, grace under pressure, values, ethics, resourcefulness, loyty, humor, kindness這些嗎? 但事實上這些都深深影響到專案的performance. 所以DeMarco建議要做好專案就回歸人,時間和資源的管理. 在管理的方法上,雖然他很謙虛的說他沒什麼資格來建議軟體開發要用什麼方法, 不過他提倡agile的概念.

雖然他一再說度量, 可預測不是最重要的, 但仍相信軟體開發仍需要工程化, 但不要把on time和on budget當成最高準則. 那什麼是最重要的呢?
"The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business."

我相信這是DeMarco殷切想讓大家不斷去回歸本質想"為什麼我要做這個專案?", "怎樣才能把事情做好?" 而不要因為要達到某專家說的最高境界, 而投入大量資源只為生出很多度量報告, 但忘了去評估做這些報告之於"原始目標" 幫助有多大? 哪些是必要的? 又哪些沒有必要?

如果Google當初是選擇運用搜尋引擎的技術接專案的方式, 今天大概沒有人知道Google是什麼吧. 這應該就是DeMarco在這篇文章一直強調的what is important.

最後, 不相關話題, 但相關Mr. Tom DeMarco
推薦DeMarco "最後期限"的專案管理的小說 有深度又很有趣!

2008年8月8日

”會議革命”讀後感

書名:會議革命 作者: 齋藤孝 譯者: 劉瑩慧 出版社:商周出版 讀後感: 最近讀完會議革命, 覺得台灣人跟日本人的開會文化很類似, 在我的職業生涯中不知開過多少忘了”為什麼我們要開這個會的會議”. 以下幾個我觀察到的現象,在看這本書後,發覺我們都犯了這本書說的開會弊病:
  1. 許多公司多固定說好星期幾是部門會議 , 星期幾是產品檢討會議. 開會那天, 所有開會成員就是讓自己到場進去報告, 也不清楚這次開會要解決什麼問題, 開了大半天或一天,原本要做的事不是加班cover, 要不就延後再做囉.
  2. 我看過一種會,大家帶自己的notebook進去開會,別人在說時, 自己在下面看自己的東西.
  3. 還有一種文化, 因為前面的座位多半是大頭的位置,大家一進會議室搶著坐後面一點的位置. 開會的多數時間是大頭在說話, 大家多是在需要自己報告時才發言, 報告有時就像是報流水帳, 把這週做的說一遍, 通常會議多輪為大頭對大家的宣教時間.
  4. 還有一種會議, 是公司內有些人政治考量, 動不動就把一堆人叫進會議室, 但實際上也沒達成任何決議, 只是提出現在所有產品的問題與客戶的不滿, 找出肇事部門要其負責.
  5. 開會要討論的事情太多, 不重要的事也討論蠻久的, 到最後最重要的反而沒有怎麼討論到, 草草結束.
如果依"會議革命"這本書的觀念,以上狀況是有辦法改善的,以下依順序說明:
  1. 例行會議會讓大家有”時間到了就去開會”的想法 ,建議應該是有問題需要集合大家在一起面對面討論問題徵結與腦力激盪提案解決時才開會. 有些事可以用打電話, e-mail, 或其他方式讓狀況透明清楚, 獲得解決的話,可採用這些非會議的手段. 所有參與會議者於會前一定要知道開會目的, 要解決哪些事, 要討論的事況最好在開會前先搞清楚, 以免開會時淪為報告會議. 然後,要請大家遵守開會時間,且要在預計時間內完成決議. 開會要從最重要與最容易獲得結論的事討論起,且主席要控制發言避免偏離主題的發言將時間吃掉.
  2. 開會時有人可以玩自己的notebook真的不如讓這些玩notebook的人回去做他崗位的工作. 建議應設計大家都可以參與的會議,而非報告型的會議. 書中提議很多讓大家投入開會的方法, 如插入異性成員,重排桌椅讓開會氣氛輕鬆, 兩兩討論再各組發表,拿掉發言權重不均的要素,白板記錄開會內容等等.
  3. 公司會議桌如果太固定,很容易形成大家按職等來坐的文化, 尤其在禮儀學中也有所謂的座位學. 除非主席有刻意安排將職等意識去除的開會方法(如:改變位置), 不然以注重禮儀的社會來說, 以職等來坐是很難避免的事.如果再加上公司的發言重量, 高職等的發言重量是較低職等的數倍,那更會造成大家消極對待開會這事, 大多數人都儘量不發言了. 上面對2狀況的建議,其中的重排桌椅,兩兩討論再各組發表,拿掉發言權重不均的要素等, 也是對3狀況的建議解決方式,此外,書中也提出開會的人要有運動精神,在別人發言時, 用關鍵字做圖像化的記錄, 吸收別人的想法,可以激發更好的解決方案.
  4. 讓大家知道所有的問題,其實沒有必要一定到開會時間才開始整理. 平常一有問題就可放在公開的問題表中要求問題核心主管指定負責解決者,提出解決方案,並回報解決狀態. 有時可以針對需要討論或一次多方了解的問題開個10分鐘會議, 而不是把一堆人叫來聽訓話,當場要他們馬上在會中將剛聽到的問題提出解決方案.
  5. 大家開會的態度要抱著不決議不散會且決議後不改變的決心. 且要有何時應結束會議的準備. 在開會前即需針對要討論的事情設定”易獲結論"的主題,且可善用小組討論讓大家的意見都可在短時間內表達. 將討論議題標三色,標出最重要, 普通重要,和有趣的話題. 開會時要從最重要的開始, 如果有些嚴肅過頭了, 插入易獲結論和有趣話題進來,再回到重要性話題來討論,則有機會讓大家開場很充實的會議.
這本書很值得所有想要將事情做好的人參考. 相信有效率的會議, 一方面可以大符降低會議成本(人數x時間x個人工時經濟成本),也有機會找出最佳的解決方案. 不過, 別忘了, 所有決議事項也要繼續追蹤, 一一完成, 不然就枉費一群人,共聚一堂苦費心思的心血與時間.

你可能會有興趣的課程

🎬  開個更好的虛擬會議:如何主持有效的會議