最近回顧了這段時間的專案管理工作，想把學到的東西整理成文字。以下寫出我認為很重要的 3 件事。
這篇文章沒有使用 AI（如果有用 AI，標題應該會更像那種風格）。
1. 為了防止大問題，持續提出小問題
在專案裡，某一天問題會突然發生，而且往往是相當大的問題。
這時候會讓人抱頭苦思：怎麼會變成這樣呢？但其實，問題並不是突然發生的，而是一直都存在，只是到了那個時間點才被顯現出來而已。也可以說，是因為它大到不得不被看見，所以才浮現出來。
當然，如果能把大問題解決掉就好了，但那所需的成本並不小（因為問題很大）。有時還需要與相關單位協調，甚至可能影響到自己與周遭人的狀態。當然，工作本來就是每天都在解決問題，但如果可以，還是盡量不想去處理那種大問題。
仔細想想，那個問題是「變得」很大，也就是說，它原本應該是小的。大概吧。那麼，如果能在它變大之前就先發現，不就好了嗎？因為那時候它還不大。
我覺得，這正是專案經理的工作所在。簡單來說，就是找出問題，尤其是那些特別容易被忽略的問題。
專案經理每天都要觀察團隊狀況，找出問題。
這有時是很難說出口的事，也有可能會掀起波瀾。很多時候，自己如果只是成員時能說出口的話，換成專案經理反而會覺得不太好開口。這大概是因為「專案是穩定的」（至少自己是這麼以為）會讓人比較安心。
然而，如果能主動把問題撿起來，在它變大之前就先發現，就能提高在小問題階段處理掉的可能性。
從這個角度來看，或許反而應該更主動地去犯錯。就算只是很小的一句話，比起沉默不說、一路拖到變成大問題，早點丟出來、早點出糗失敗，長遠來看反而比較好。
對專案經理來說，甚至可以說，與其一直都沒發生任何問題，反而會讓人感到不安比較好（當然，若同事都很優秀，實際上也可能真的一段時間都不太有問題）。
2. 將專案視為一個系統，持續進行調整
我們可以把專案看成一個系統。裡面有一些構成要素，而這些構成要素彼此之間有著某種關係。它們會相互影響、彼此依存。專案經理則是在自己也是這個系統中的一個構成要素的前提下，仔細觀察這些關係，並對其他構成要素施加某些正向影響。
例如，在做某個任務時，通常會有事前資訊，而這些資訊也有適合提供的時機。專案經理要做的，就是在各個成員都各自行動的過程中，選在合適的時機提供那些資訊，讓整個系統運作得更順利（如果缺少必要資訊，就在那個時間點前先取得）。
思考如何把自己的任務做好、並確實完成，當然也很重要；但有時候，比起「自己要做什麼」，更重要的是思考「自己現在介入在哪裡，能讓整個專案更順地往前推」。如果能做到這一點，專案管理往往會更順利。
要能做到這些，我認為需要：
- 有時間軸、空間軸的意識
- 自己保有一定的餘裕
而最重要的，是要「好好觀察」專案本身。
※ 反過來說，平常也要注意自己的言行，讓別人也願意對你產生正向影響，或許也很重要。
3. 線程表，是為了想像「已經達成的狀態」而寫的
作為專案經理的基本工作之一，就是畫線程表。這不就是專案經理的工作嗎！以前我也曾經想過：這東西畫了到底有什麼意義？與其花時間畫這個，不如直接動手做吧。
線程表的意義，當然包括：
- 對關係人共享、展示
- 進行進度管理
這些都是很重要的功能；但我也開始覺得，它還有另一個用途：
- 想像「已經達成的狀態」
當你畫出未來的線程表時，就能具體想像：到了這一天會變成什麼樣子、到這裡應該就差不多能發布了、這裡因為有國定假日或公司內部活動，所以能做的事情不多等等。然後再從這些想像往回推，思考現在該做什麼。
線程表畫出來，也不代表一定會照著走（我自己也是每天都在反覆重畫）。即使如此，畫線程表的時候，尚未存在的未來會先變得具體。如此一來，就能開始思考：「那麼，為了讓狀態變成那樣，今天我應該做什麼呢？」
我認為，這就是在消除不確定性。
以前我曾寫過一篇〈估算失誤差點死掉了（所以分享 3 個重點）〉的文章，提到估算的重要性；我也認為，就上述這層意義來看，估算同樣非常有用。（估算並不只是為了猜對發布日而存在。）
後記
這樣寫著寫著，總覺得這些事不只是專案經理，對任何人來說都應該多少能意識到吧。
原文出處：https://qiita.com/shirakurak/items/ee7565d212fd3ae1adcb
1) --- 會變成分隔線（上一行必須是空白）
2) # 會變成一級標題
3) ## 會變成二級標題
4) ### 會變成三級標題
5) **粗體文字**會顯示粗體文字
6) ```當第一行與最後一行會顯示程式碼
7) 請搜尋 Markdown 語法，了解各種格式
