4月1日，輪子科技項目主管孫衝在dbaplus社群帶來了《從技術轉管理後，我在敏捷轉型上的試錯與收穫》線上直播分享，並在線回答了觀眾提問，本文精選出8個問題和解答與大家分享。
文末還有本期直播PPT獲取路徑，不要錯過~
>>>>
Q&A
Q1：領導對技術的干涉太多了，比如提需求，改需求，親自設計方案等，遇到這種情況應該怎麼處理？
A：我們先來自問，為什麼領導會干涉這麼多？我們再來拍腦袋分析一下。
因為是創業公司？容不得半點馬虎？
因為客戶是老闆談的？老闆比較瞭解？
因為老闆不放心其他人做？底下人做出的東西他不滿意？
因為老闆的職業習慣？
以上問題，我們可以分為兩個方向，分別是老闆的問題和我們的問題。
1）老闆的問題
自己沒有意識到適當的放權可以讓下面的人成長，自己也可以有精力去做其他重要的事情；這個不放權也有可能有其他的考慮和苦衷。
2）我們的問題
是不是老闆給了機會，沒有把握住，沒有精進？每次都犯一樣的錯誤，造成了很大的損失？
即便是老闆沒有放權，我們可以學著做，將來老闆把事情安排到我們身上，我們能夠快速接住。這個需要機會也需要自己的自律能力，學習能力。
Q2：項目經理怎麼處理和技術經理之間的關係？
A：我們實際中確實遇到了這個問題，只是說遇到的是 【產品專員】VS 【項目經理】 VS【產品專員的職能領導】之間的關係。
從【項目經理】角度來看：
對於產品專員，對於其職能發展沒有其太多權力干涉。
但是產品專員的能力有反向影響著項目。項目迫切希望產品專員的能力能夠成長。
從【產品專員的職能經理】角度來看：
產品專員的職能領導對產品專員在項目中的表現和需求知道的並不多。
但是職能領導有希望參與或者得到項目中更多產品專員的信息進行能力補充。
從【產品專員】角度來看：
他希望職能經理能夠指導他，能力進行更多的提升。來滿足自身職業技能的需要。
同時他也希望這些技能正是項目中需要的技能。能做更多專業的事情得到大家的認可。
好了，我理清楚了上面的需求後會和職能經理溝通，希望在項目中提出對於產品專員能力的提升要求。然後我們線下會對產品專員進行雙面的指導。比如產品專員畫PRD，我會先讓他的職能經理看，然後我再從項目的角度來看PRD。
如果我和職能經理的想法本質上就有很大的出入，那麼我們就三方進行線下溝通。我說出我的標準和為什麼是這個標準，其他人也像這樣來溝通以達到我們共同的目的。
我們共同的目的是：項目做好，人員也得到發展和精進。如果都奔著這個目的去，事情應該都會得到解決。思路就是：先職能經理過，然後我再過，最終對大的衝突點進行討論。
當然前期的過程是需要各自磨合的，開始時候大家都端著，慢慢放下了我們的思想包袱後。漸漸理解了這個做法的真正目的，後面大家話也說開了也都理解了，溝通很重要。
Q3：如何處理團隊中散漫的組員？
A：疑問1：他是否一直這樣？其他人是否也這樣？
分析：是不是你的的管理出現了問題。
方案：可以組內單獨談話跟進了解。
瞭解對項目對內其他人的期望，對你的期望。
如果你自身出現問題，是不是可以你自己先調整？
收集大家對你自己的期望對項目的期望。自己做出調整，給出方案和改進計劃。
不能口空答應沒有反饋沒有監督，樹立大家對你對項目的自信。
疑問2：他的懶散通過消極工作表現出來？他的懶散通過話語表達表現出來？他的懶散是持續表現還是偶爾發生？
分析：
他的不滿有可能想引起你的注意，想通過情緒和你訴說著什麼。
這種訴說可能是一種主動‘表白’訴說。
也可能是自己一種無奈的表達。
方案：此時需要單獨溝通，深入瞭解他的訴求。
可能最近一段時間他的狀態不好，有點自暴自棄，有點鑽牛角尖。那你就組織解決他的困惑，多關心一下舒緩他的狀態，或者敲打敲打他。
也有可能遇到了瓶頸或者說遇到了職業倦怠期。推薦幾本書，或者有更多經驗的領導單獨給排解一下這個倦怠期。推薦幾本書也行。
-
也有可能他就是覺得自己的價值在項目中沒有發揮出來，那你就可以分配挑戰性任務
也有可能他想讓你認可他，讓你關注他而已，那你就多關注他。
總結：以上了解完成後，可以讓他自己調整，也可以介入調整。
都有利弊，需要從長遠發展的角度來解決問題。
Q4：我們現在處於疫情期間，敏捷開發是否會煥發出不一樣的魅力？
A：我覺得這次後大家會對敏捷開發有一定的認識，因為在家辦公也算是團隊自制力的整體體現。敏捷價值體現的理想狀態是，大家能夠主動溝通，主動發起跟進事件。
我們疫情期間仍然進行我們的多溝通，及時溝通，及時反饋的思想，所以大家沒有什麼思想波動，舉幾個例子：
疫情期間的小目標先出來，讓大家有目標可循。
我們疫情期間堅持視頻早會，大家會很快進入狀態。
評審會議依然繼續，只是從線下搬到線上。大家沒有什麼不適應。
我們每天發每個人的待辦事項到群裡。
任務狀態每天更新，目標里程碑的跟進。
如果之前沒有習慣開早會的團隊疫情期間突然開早會，大家會很突兀。或者不開早會，通過填表格或者其他手段進行工作狀態跟進，大家反而會覺得突然加了緊箍咒，心裡感受到了組織對自己的不信任。
但是人性是懶惰的，需要有一定的工具和制度的介入，甚至說流程吧。習慣成自然。但是這種工具和制度甚至說流程的本質是為了強迫而出發？還是為了喚起大家的主動性，促進大家的認知上的精進？這是完全兩種不同的表現。
Q5：敏捷開發對於需求，任務劃分粒度有什麼標準？
A：首先從需求上看：需求可以分為史詩級、主題級、任務級。如果從任務來看，任務我覺得劃分的粒度是更加獨立最好。
比如一個查詢列表需求，首先這個需求對應著各個工種的任務：
【後端】任務1：接口協議設計
【後端】任務2：參數組裝，格式化
【後端】任務3：主頁業務邏輯
【前端】任務1：頁面設計
【後端】任務2：條件搭建
【後端】任務3：查詢對接
以上是例子，這個看團隊的開發習慣，我一般是讓組員自己根據需求拆任務。因為我們前提是在需求評審和理解會議上，已經將重點、難點、影響面積和核心邏輯粗略盤點了一遍。
所以任務都是組員自己估算自己理解，然後我進行Review，很粗的任務儘量打回重新分，裡面的對接過程和信息儘量的詳細。最後的編碼只是很小的一部分，準備是關鍵。
Q6：敏捷開發對於產品經理有特別的要求嗎？
A：推薦《Scrum精髓：敏捷轉型指南》，裡面有對敏捷開發中三個角色的具體定義。
Q7：實踐敏捷，如何提高team共同認知度，在你以往經驗中，有過什麼樣痛點和好的應對方案？
A：這也是我最近在思考的問題，這個主要是你自己認同了也感受到某種方式可能效果會很好。
但是小組內很難推進，如何推進呢？部門公司內部如何推進呢？我想以學習引導為主，就是找到幾個人進行組團學習。
比如估點，我們就學習估點的章節，大家分享，然後討論，討論出都理解並認可的方案。然後團內內再統一宣講後執行。這個需要給大家一個足夠的鋪墊。讓大家的認知至少保持較小的差距。這樣實行起來的阻力和抗拒感較小，遇到問題也能夠接受。
所以普及並統一戰線很重要。還有一點是不要急於求成，一點一點滲入，一點一點的嘗試，勤總結。
Q8：比較好的開源電子面板工具有哪些呢?
A：這一塊關注的不是非常多，只是工作中遇到了就用，工具而已。
GitLab支持企業自己搭建環境。
Github上有很多的開源面板，可以下載安裝，但是也僅僅是面板。
我們經常使用的是項目管理工具，面板是其中的一個功能。
獲取本期PPT
請添加右側二維碼微信
制定技術戰略規劃是技術管理者的重要職責之一，但不少技術管理者對此往往無所適從。什麼是技術戰略？如何規劃？怎麼找到技術體系建設中的主要矛盾？來
Gdevops全球敏捷運維峰會北京站聽聽快狗打車CTO沈劍的經驗之談：· 《技術戰略到底要規劃些什麼？》58集團/快狗打車 技術VP/CTO 沈劍
9月11日在北京，一起打造技術管理者的核心能力！
