本記事的寫作契機

前不久，我從工作了三年半的巨型企業轉職到一直憧憬的全球科技公司。在這三年半的時間裡，我在前公司（巨型企業）學到了許多，因此我想將這些學習整理成本文，讓自己「不忘這些學習」和「在今後能夠有效利用這些學習」。

這是為了在新環境中迷失時能夠回頭的自我備忘錄。

思考與姿態

🔸 具高視座的工程師是什麼

在我接觸的工程師當中，有許多人顯然比我能看到不同的景象。
我認為，這些工程師共同的特點就是高視座。

他們不僅思考眼前的任務，還考慮如何達成業務和公司的目標以及路線圖，並在思考「現在該如何做」和「應該如何製作」的同時付諸實踐。

他們持有整體最優化的視角，不僅考量短期的效率，還能思考技術選擇和設計判斷對未來的可維護性、擴展性等長期影響，並能夠進行決策和說明。

🔸 不輕易接受他人的How

當Why和What都已決定的一定階段，卻很少看到有人來詢問或計畫開始時，這是相當罕見的。

在這種情況下，再次討論「這個How是否最合適」以及「有考慮過哪些其他的How，還應該考慮什麼」的問題與相關人員是非常重要的。

此外，與上述的討論一起，想要明確那些可讓步和不可讓步的前提條件。

🔸 現在這麼做真的是最好的選擇嗎？

如果不深思熟慮時，僅僅是在處理眼前的任務，會變得只是機械地完成。

在理解「為什麼在這個時間點要做這個任務」的基礎上來進行，會產生認同感，也能對任務擁有更強的主導權。

此外，這個提問也有助於防止目的與手段的顛倒。

透過詢問「現在這個任務真的就是最好的選擇嗎？」，意識會不斷回到目的（為什麼要做，完成後的理想狀態）。
這樣可以使得為了達成目標能夠進行「放棄某些任務」、「調整任務的順序」、「更改任務本身」等戰略性判斷。

🔸 有意識地留出思考時間

在一天或一週中，有意識地留出思考時間，不把自己的日程封鎖住，否則每天都會只專注於眼前的任務而結束。

無論一天中留出15分鐘，回顧團隊、業務和路線圖，預測未來可能發生什麼，可以提前思考可採取的行動，這樣會讓你能夠更好地掌控日常工作。

此外，在單獨思考的時候，明確團隊、業務和產品的理想狀態，並思考與理想狀態的差距，以及能做些什麼來填補這些差距，這樣也能讓自己作為商業人士的成長和評價提升。

🔸 從as-is / to-be明確化

在遇到專案或問題時，首先明確「as-is（現狀）」和「to-be（目標狀態）」是非常重要的。

如果兩者都不明確，就無法定義as-is和to-be的差距，無法選擇適當的解決方案，還可能朝向錯誤的方向前進。

此外，在實施了解決方案後，衡量「問題真的解決了嗎？」和「成果是否出現？」的標準也會變得不明確。

相反地，如果能在事前定義as-is和to-be，就能共用目標，進度和成果的評估就會變得容易，也能減少相關人員之間的認知偏差。

這不會有什麼壞處。

🔸 解決方案與ROI同步考量

檢討課題時，考慮解決方案時，始終要將ROI（投資回報率）同步考量是非常重要的。

即使How再優秀，如若無法與投資的回報對等，即使真的用那個How解決了問題，收益也會減少。

需要考量開發工時、運營成本、未來的可維護性等，以儘可能定量的方式判斷預期的成果和投資的平衡。

通過意識到ROI，將更容易進行優先排序及決策，讓在有限資源下也能創造出最大的價值。

🔸 考量QCD，邏輯上說「不」

在專案中，對所有要求都回應「好的」是非常困難的。

在有限資源中最大化價值，以QCD的觀點來邏輯性地判斷和解釋可實現性和優先級的判斷至關重要。

透過量化「為什麼困難」、「對品質、成本、交期的影響為何」，並在解釋權衡的基礎上傳達「不」，就會更容易獲得對方的認同。

有邏輯的解釋，能夠引導出建立在相互建設性上的討論，而不僅僅是拒絕，結果會有助於建立整個團隊的信任關係，能夠不費力地持續推動產品成長。

🔸 做事要有感悟

這裡似乎不斷地在重複類似的言論，但「思考與姿態」的最後一部分是要「帶著理解去工作」。

對專案或方針，如果對「為什麼這麼做？」「為什麼要這樣的方針？」「想要改變誰的什麼行為？」等未能理解而去進行，就會導致判斷變得被動，最終只會成為執行指示的人。

首先對專案和方針能持有疑問，正確認識現狀。
不會出現任何疑問的狀況可能意味著「自己未能正確認知內容」或「無法擁有主導權」。

首先要有疑問，然後解消疑問，目標是能用自己的話語表達目標，這是擁有工作主導權的第一步。

若每個成員都能這樣帶著意識投入工作，就能避免出現「製作並發布了，但沒有一個人使用」的情況。

既然要做，就要製作出用戶真正喜歡的、有價值的東西。

專案管理

🔸 專案的啟動會議是重要的

若僅在自己的開發團隊中，或許啟動會議是不必要的，但若需要牽涉到其他團隊，則即使是短時間的啟動會議也會使後續變得更輕鬆。

如果在目標、範圍、角色分配和進行方式都模糊的情況下啟動專案，後來認知與責任範圍的模糊會浮現，並導致返工和溝通成本增加。

在啟動會議中，與所有相關人員分享目的與背景，明確to-be的狀態和進行方針是非常重要的。
此外，通過問答解決早期的不安和前提不一致，建立專案持續推進的「共同基礎」。啟動的細緻性將支撐後續的速度和成功。

🔸 從風險出發而非任務考量

在推進專案的過程中，許多人往往會從「應該做的任務」開始規劃。
然而，實際上引發計劃崩潰或降低品質的，恰恰是那些未被注意的風險。

因此，最初應著手的應該是為了識別風險而進行的必要工作，而不是任務。
在前公司，我們會進行被稱為「前期風險評估」或「風險分析」的活動。

早期明確潛在的麻煩、可能成為瓶頸的地方、不確定因素、依賴關係、延遲和返工的可能性等，並優先解決這些風險是至關重要的。

不是在任務基礎上加入風險視角，而是要以風險為起點來建立計劃，這樣才是減少不確定性的專案管理之道。

🔸 以MVP和用戶可提供的價值為基礎規劃

在以風險為起點規劃之後，透過MVP（最小可行產品）或用戶可提供的價值為出發點來考量是非常重要的。
（※ 風險和價值哪一個作為起點應根據不同情況而定，或許有不同的說法。）

以功能需求或組織內的情況為基礎來制定計劃，可能會使原本想傳遞的價值延遲，或優先度較低的功能使計劃變得膨脹。

首先明確「對用戶而言，什麼是最有價值的」，然後倒推定義MVP並確立優先順序，這樣在有限的資源中也能迅速向用戶傳遞價值。

與其追求完美，倒不如從價值的核心部分逐步堆疊，這樣便能形成精簡的計劃並快速進行驗證循環。

🔸 不要在不明確的定義和認知下推進專案

在推進專案時，若不將用詞或前提的模糊性拋諸腦後，後面將大大增加誤解或返工的可能性。

特別是「應對」「完成」「暫時的」以及「服務或業務領域特有的術語」，它們的含義可能因人而異，使用時需謹慎。
若不將其明確定義而進行，將會導致每個成員憑自己的理解去行動，最終易導致成果物及時間表出現偏差。

在初期階段，「似乎有某種程度的共識」的狀況是最危險的。需早期將模糊的部分進行明文化和統一語言，以做好術語和完成條件的定義，藉此避免認知的偏差，使專案管理減少不確定性。

🔸 確認前提知識和目的是否一致

在專案推進過程中，如果相關人員之間的前提知識和目的認知出現偏差，將導致討論和決策交加，最終造成重大返工的原因。

不要認為「這應該是共享的、大家都知道的」，而是重要的是要暫停一步確認背景、目的和前提條件。

特別是當與其他團隊進行溝通或轉換階段時，知識水準和目的理解程度往往會出現差異。

透過統一基礎，減少討論中的認知偏差，提升判斷和計劃的精度。
不依靠模糊進行，而是仔細進行認知對齊，最終將更接近成功。

🔸 切勿失去Scrum的目的與支柱

Scrum不僅僅是儀式或運用規則的集合，它是一個幫助團隊持續交付價值的框架。

然而在實務中，日常Scrum會議或衝刺等活動的「實行本身」有時會成為目的，使得原本的意圖無形化的情況並不少見。

Scrum的三個支柱是「透明性」「檢查」「適應」。
適當發揮這些支柱，團隊能夠早期發現和改善問題，並提高在變化中的成果。

活動僅僅是支撐這三個支柱的手段，單憑形式的遵循無法使Scrum發揮效用。
不斷回歸目標和支柱的認識非常重要。

🔸 對任何事進行效果測量和回顧

在推進施策、專案或改進時，執行不應是結束，而必須將效果測量和回顧結合進行。

若不衡量實施後的效果，就無法判斷施策的好壞或後續的改進點，最終可能導致惰性行動。

不僅僅是收集量化數據，也需要包含定性的反饋來驗證成果，基於事實進行多次改進，這樣團隊的學習循環就會啟動。

不應該只執行而不思考，將回顧納入流程，可以提高決策的精確性和可重複性，並加速團隊的成長。

🔸 不要偷懶於文檔編寫

文檔編寫越是拖延，內容越模糊，最終會自掘墳墓，對自己和團隊造成傷害。

當記憶猶新時寫下來，可以準確記錄背景、意圖和決策的過程，並減少後續的認知偏差和交接成本。

越是繁忙的時期，越要「現在這個時候就算是臨時的也要留下「決定的事項」、「背景」和「經過」的備忘」的心態是至關重要的。

文檔是對未來的自己和團隊的投資。
不偷懶，當下執行才是最有效率的做法。

🔸 積極主動去撿起掉落的球

在推進專案的過程中，會必然出現「誰來做並不明確的工作」或「可能被疏漏的問題」。

若忽視這些「掉落的球」，後來會導致麻煩或延遲出現。
即便尚未確定責任，也要第一時間提醒，並根據需要進行周知和分配，這一心態是重要的。

如果因為「這不是我的範疇」而置之不理，最終可能會影響整個團隊的成果。

若大家都意識到「撿起掉落的球」，便會產生團隊的凝聚力，推進專案的穩定性。

🔸 確保自我與團隊的狀況對外可見

為了順利推進專案和任務，保持自己與團隊的工作情況向他人可見非常重要。

無論是哪項任務，都要創建待辦清單或票據，讓團隊隨時掌握進度、剩餘工作和問題，從而減少為了解狀況而造成的無謂確認成本，並可能及早進行跟進或發現風險。

若只有特定人的腦海中掌握信息，則會成為依賴化和疏漏的溫床。
公開的信息共享提高了透明性和信任，形成了整個團隊推進專案的基礎。

「可視化」不僅是成本，而是支撐團隊生產力的投資。

🔸 須考量定期會議的用法和頻率

在專案中，定期會議往往容易被設置，但若不考慮目的和頻率，惰性延續將降低生產力。

會議的重要性在於要明確「為什麼要舉行」、「這是決策的場合是什麼」、「真的有必要定期舉行嗎」。
例如，若進度共享是目的，則文檔或任務管理工具可以替代會議。

需關注必要的成員、適當的頻率和時間上限，若議題不明確則可考慮中止會議。
會議不是習慣，而是一種工具。
以正確的用法和頻率考量，可以提高團隊的集中力和推進力。

🔸 非功能性需求容易被忽視，需記得任務化

在專案中，往往將焦點放在功能性需求上。
相對而言，非功能性需求往往會被後延，最糟糕的情況是連任務都不被認作。

安全性、性能、日誌設計、監控、備份、運行設計等若在後期來處理，可能會導致高成本或返工的因素。

非功能性需求的重要性不在於「等到注意時去考慮」，而是在一開始就要明確列出並做任務管理。

若能盡早將其任務化，便能與設計或開發同時進行考量與實施，有助於順利推進專案。

溝通

🔸 在會議前先確定目標與議程

為了有效率地進行會議，會議前確定目標和議程是不可或缺的。

如果在目的不明的情況下開始，會使得討論發散，時間只會空過，而無法得出決定。
預先定義「想決定什麼」、「要達到什麼狀態會結束會議」，整理好必要的成員、資料和議題，讓每個人都能以共同的目的參加會議。

另外，參加者也因此可以進行事前準備，討論的質量會大幅提升。
準備議程和目標二者，將有助於提升會議的時間效益。

🔸 從要求出發，調整認知，卷入其他團隊

在需要卷入其他團隊的專案中，認知的錯位與依賴關係的疏漏往往會發生。

因此，首先要從需求（想實現什麼，為什麼需要）調整認知是非常重要的。
在共享背景與目的的基礎上進行討論，能使其他團隊更容易將其視為自身的事情，建立建設性的合作關係。

不僅僅是單純的請求，透過「為什麼這一改變必要」「會帶來什麼價值」的細緻說明，能夠在線共通的目標推進力。

🔸 落實早期的溝通，並適時表達意見

專案出現問題加大時，大多數是因為「延誤了溝通」的緣故。
在感到迷惑或有異議的時候，若能夠及早共享，可能小問題就能解決，但若放置下去則會成為更大的麻煩。

「再觀察一下」和「因為看起來很忙，所以不太好意思說」的心理，最終可能會加重整個團隊的負擔。
困惑、不明之處或疑慮，即使尚未整理完善也是可以的。

及早地表達意見是最好的風險對沖，能夠幫助團隊及保護自己。
溝通方面，重於「快速」而非「顧慮」將更容易建立信任。

🔸 深入挖掘問題時，明確自己困擾的是什麼

在深入問題時，明確「自己困擾的是什麼」是非常重要的。
若僅僅追逐表面現象討論，則會誤判原因和優先度，浪費於虛無縹緲的解決方案。

首先要通過具體言語阐述出困擾的事實，整理「是誰」「在何種場合」「為何困擾」的情況，問題的本質將會愈加明晰。

放任不明確的討論，將導致意見相左，轉眼間可能就進入「另一個話題」。
問題的深掘是從「明確困擾」開始，而非探索原因。這是問題解決的第一步。

🔸 否定意見與替代方案應並行

在討論或評審的場合中，僅僅傳達「這是錯的」「最好停止」的否定意見無法引導至建設性的討論。

更重要的是，要同時提出「那麼該怎麼辦」的替代方案。
有了替代方案後，能夠更容易地展開後續行動，整個團隊將更積極地產生行動。

唯有否定意見止步於問題意識的共享，然後再提供替代方案，才會轉化成改善的建議。

提出替代方案會是具有挑戰性的，但總是能超越單純的批評，這樣的姿態將建立信任，並提升討論的質量。

🔸 教會他人釣魚，而不是直接給魚

在培育成員方面，關鍵是要讓他們學會解決問題的過程，而非直接解決問題。

如果只是提供答案（魚），會使得問題的解決變成權宜之計，當下一次出現相同問題時便無法自如契機。
首先要教會「釣魚的方法」，共享思維方式與判斷基準，這樣才能促進成長。

理想情形是，讓對方能夠自己思考釣魚的方法。
也就是說，培養可重複的問題解決能力。
關注於支持思考而非指令的方式，能使整個團隊變得自律而活躍的組織。

總結

雖然還學到了很多東西，但以上就是我「將來依然想要牢記並實踐」的學習了！

在前公司三年半，能與許多優秀的人們共事真的非常幸運。
為了不輸給那些優秀的人，我也會持續成長，創造出能改善社會的產品！

原文出處：https://qiita.com/Toshi-Shumi/items/e71ee26d16f0b288981c