團隊管理中的每日站立會思考

題外話：

咱們爲何要作這件事(Why)？如何才能把這件事作好(How)？堅持高效的執行這件事(What)？是否審視評估這件事的成效(Review)？

Why:它能給咱們帶來什麼益處？它有 帶來哪些壞處？它要達到的目標效果是什麼？
How:怎樣作才能達到預期的目標？如何規避 存在的風險？
Waht:咱們具體作的事項，堅持、高效、成效的執行，確保目標的達成。
Review:是否是達到預期的目標？哪些沒有作到位？哪些須要添加？哪些須要刪除？(下一個迭代啓動)

Why讓咱們思考這件事的意義和目標以及標準；How讓咱們思考這件事如何更高效且有成效的達成；
What讓咱們具體執行的事項，堅持、高效、有成效的達成；Review讓咱們思考是否偏離方向，持續的改進優化提升。

來自西蒙-斯涅克《偉大的領袖如何激勵行爲》的思考。
[短時間利益，讓你吃上飯；長遠利益，讓你吃好飯。]
[人們買的不是你的產品，而是你的信仰；人們合做不是你的人，而是你的信仰。]
[相信你所相信的並帶領你們相信你所相信的，並讓你們看到階段性可預見的成果，小步快跑。]

 

有段時間沒寫博客了，在深圳參加一些很棒的線下活動，認識了不少大牛，有時間一一整理，分享一下。
四月份寫的博客《團隊管理中的每日站立會》，是基於對站立會的最初認識，執行一段時間週期，最近又有對站立會的新思考：
每日站會，來自敏捷最佳實踐，真的作好作到位，把站會的真正價值發揮出來還真的須要不少地方可改進的。

簡單敏捷認識
不知道你們是怎麼接觸敏捷，說到本身最初的話，應該是博客園關注大牛周金根老師，而後就是第一家公司廣聯達的敏捷實踐。
每一個人接觸敏捷的形態不同，有的是進入公司的第一天就有接觸，由於公司已把站會做爲一種研發規範肯定下來，你必須接受；
有的是接觸身邊朋友你們都在搞每日站會，彷佛效果也不錯，咱們也搞一下試試，你嘗試接受；
有的是公司學習大公司好的研發體系，發現廣泛的大公司都在搞這個，咱們不能丟咱們必須同步，咱們應該有，你強制本身接受。。。。
每一個人的接受程度不同，對最初的事物的認知度不一樣，以及接受嘗試後，反思對事物的認識又是不一樣， 推翻最初的認知， 提升最初的認知。
一項新事物、新概念，不一樣的應用場景，不一樣人的執行，達到的預期的效果不同。以致於咱們對該事物的認知有所改變，而沒有思考其根本。
咱們公司推行了敏捷，敏捷中提倡的最佳實踐，咱們都有執行，但是預期的效果並非如此的好，並且沒有獲得提升改進反而形成阻力，對團隊、對項目無益處；
那就須要分析思考是否是哪裏作的不到位，是否是哪些方式方法不當，是否是哪裏不適合咱們企業能夠變通、調整下，不一樣的人執行達到的效果是不同的。
敏捷不只僅是提升效率的，並且仍是下降成本的，固然項目管理不能僅依靠敏捷的一套思路去作，能夠吸取百家所長，相輔相成，服務於項目。

每日站立會新思考，對這篇《團隊管理中的每日站立會》博客的補充：
每日站會是否主持高效？
可能不少團隊也一樣糾結站立會如何主持，才更高效？在寫的這篇《團隊管理中的每日站立會》博客中，提到建議的一種方式就是團隊成員的輪值主持，有利有弊。
對於不是太成熟的團隊或是專業度很高的團隊， 更多的選擇的是由PM\SM\PO主持(控制沒必要要的風險或團隊成員能力欠佳不能很好組織帶來低效)；
對於通常性的團隊， 更多選擇有團隊成員輪值主持比較好，利弊分析過，再也不冗餘，不過這個仍是極力推薦和推崇的。
其實敏捷指望達到的一種團隊狀態就是敏捷的自組織、團隊成員的自組織，每一個人都有很強的責任感和使命感，每一個人都對團隊賦有承諾，
每一個人都對產品的成敗負責，每一個人都覺着天天的工做都是有意義的，你們在共同打造一款超級棒的產品。更多的強調團隊成員的參與感、團隊的主人翁精神，
團隊的凝聚力，而每日站會就是一個很好的促成方式。當咱們在爲公司作事情的同時，也期待我的也有所成長和提升。
你不是在給老闆打工，你是在給本身打工；你不是在打造一款公司的產品，你是打造一款你鍾愛的產品。

每日站會是不是工做彙報？
可能不少團隊一樣也糾結站立會怎麼變成工做彙報了？在寫的這篇《團隊管理中的每日站立會》博客中，提到每日站立會中的三段論，在作工做狀況陳述。
纔開始的執行確實是這樣切入比較好，可是執行一段時間後，你會發現你們都只管本身的那一塊任務的陳述，或是任務陳述過於浮於形式。
其實，採用什麼形式或許並非最重要的，肯定工做陳述主要目的是什麼：
<1>.項目進度反饋。對項目經理、對團隊成員反饋你任務執行的進度，確保咱們的項目在一個可控的安全時間內運轉；
<2>.項目風險把控。對項目中 存在進度的偏離，技術風險，需求風險，溝通風險，都能及時的暴露，風險前置；
<3>.團隊監督承諾。每次工做陳述都是對本身已作工做和將作工做的一個承諾，你們一塊兒監督，你也迫使本身去達成本身設定的目標。
<4>.團隊溝通透明化。你們彼此溝通無障礙，誰的任務，有須要誰來協助，各個環節溝通順暢，工做事項透明化。
只要能夠達到這個四個或許採用三段論也不妨，可是若是團隊出現疲態或是背離咱們的初衷，那就須要及時的調整，採用一些有趣好玩的形式，讓咱們的工做陳述更有意義。

每日站會是否要作會議記錄？
可能不少團隊一樣也糾結站立會要不要作會議記錄？ 你們認識中敏捷是無文檔、無加班，提倡更可能是必要重要的文檔和天天高效工做的保持。
在《團隊管理中的每日站立會》博客中，提到會議的產出。其實，更多須要一些重要的紀要性的文檔產出，例如：
針對今天站立會，忽然發現團隊某種不良現象，要加以約束和調整，團隊成員達成共識的一個團隊執行標準，這個是須要記錄的，爲咱們更大的團隊執行制度添枝加葉；
針對今天站立會，可能引起的溝通上的不協調問題，團隊達成共識的一個決議，這個須要記錄的，讓你們之後都採用這種方式來溝通；
針對今天站立會，一些須要的重大的調整、決議、設計、改進等等，也須要簡單記錄，方便查找和過後的跟蹤。
會議記錄做爲會議的一個產出，既是對之後工做的一個監督跟蹤也是造成了一份組織資產，可能不少公司都不關注公司組織資產的建設，認爲是費時費力有沒成效的事情。
近期看組織資產確實不能給你帶來當前的利益，長遠看組織資產將是一大筆財富，不須要太花費大量的人力、物力投入去作，只需平時工做中多作那麼一點點就能夠了，水滴積河流。

每日站會是否滋長懶人歪風？可能你的團隊來自一個矩陣組織，業務分析員、測試工程師、不一樣部門的開發工程師、UI設計師組織在一塊兒，同時爲了項目組織在一塊兒。可能在工做會出現項目責任的推諉，每日站會的時候，告知PM和你們這個模塊作不了，交給其餘人來作。你們來自不一樣的職能部門，有各自的職能經理，對於成立的項目組的歸屬感不大，也不認爲是你們的項目，只管把本身那一塊的工做作好就行了。其實有時候不是跨職能組織的團隊，本身一個部門也會有相似的問題。可能就想到敏捷執行確實須要必定的基礎建設，團隊、公司是否適合推行敏捷。做爲PM臨時的處理辦法就是命令指派的領導，但這不是長久的方法，這明顯的是一個團隊的不成熟，須要多花心思去讓團隊更加成熟些，增長你們的歸屬感，一塊兒短暫的奮鬥合做的事業更有意義。在發現這種不良情況時，PM就要反思了，要讓你們看到咱們的前面路很美好，讓你們看到彼此的付出，讓你們彼此信任，他作了那麼多，我也不能拖團隊的後腿，我要要作點什麼。讓團隊正向能量運轉，首先PM要相信，而後讓你們去相信。相信你所相信的，帶領你們相信咱們所相信的，並看到可預見的成果。