讀《團隊之美》
此書從2010-11-4日開始讀,到今天兩個多月了還尚未讀完。效率低下的讓人慚愧。當然,我可以藉口說太忙了,精力都被一些不該程式設計師關心操勞的事情吸引了,但啥是浮雲,程式設計師心裡是很清楚的。
書中主要是以訪談錄的形式講述了“團隊”這個非技術的技術性話題。總結和提煉的程度上不如《人件》那麼精闢,但書中所舉均為近現代的軟體專案例項,新鮮;語言平易近人,像一位經驗豐富的老前輩在滔滔,親切;正視技術團隊建設複雜度的客觀性,實在。
正文之前
- 資深團隊領導講述發人深省和引以為戒的故事
- 團隊構建軟體,但是如果你們的團隊不能在一起有效的工作,那麼在軟體開發這個遊戲中,成功的機會將微乎其微
- 卓越的團隊不僅產出成果,而且鍛鍊人,並能開出美麗的團隊之花
- 任何一個稍具規模的專案都不是一個人能夠完成的
- 毫無疑問,人員和團隊是使專案成功的最重要因素
- 一個在公司解散前夕仍舊勁頭十足、照常工作的團隊;在面臨人類的災難時互相幫助、同舟共濟的團隊;為了同事的利益而表現出正義感和不懈努力的團隊;一個為一千萬人民提供潔淨飲用水的團隊。這些團隊告訴了我們什麼是團隊之美。
- 團隊中包含哪些成員更為重要:他們的技能如何,他們在一起工作的融洽程度如何
- “最佳”實踐是不存在的——至少沒有那種已知的實踐方法能夠保證每次都取得成功
- 你對不同的人運作專案的方式瞭解越多,對自己運作的專案幫助就越大
- 在正確的時機做出正確的決定,這對專案的成功非常重要
第1章 領導力
- 管理的技巧就是透過其他人的工作實現你的目標。而更重要的:寫作的技巧就是創造一個能夠激發其他人進行思考的環境
- 系統必須具有這樣一個基本特徵:每個任務都很小,人們能夠獨立完成
- 我們需要有一個可以激發人們創造力的體系,還要有一整套原則
- 狹縫令創造力如噴泉般湧出
- 騎過馬的人都知道,要想騎好馬,秘訣在於讓馬認為它做的是自己想做的事情
- 最好的領導就是能夠讓人們自覺自願的去做事
- 完成的方法不止一種
- 領導一個團隊,如何能讓一群人發揮他們的潛力?關鍵是瞭解他們,瞭解他們能夠做些什麼
- 對自己做的工作要保守,接受別人的意見時要心胸開闊
- 如果你的系統結構良好,團隊取得成功的機會就會大一些
- 沒有最佳方案,只是做出的選擇不同而已
- 也許上帝是為了讓人們信仰而虛構出來的
- 建立一個令人信服的願景並讓別人接受
- 我們是一個小群體,在一起緊密的工作
- 你應當讓人們自由的做他們的事情,然後看看他們的情況
- 我必須讓事物動起來,然後再趕上它們
- 作為一個好領導,就是要知道人們什麼時候有能力去做那些事情
- 你需要能和你爭執的人,你需要人們有他自己的想法
- 美即是真,真即是美,這就包括你們所知道和該知道的一切
- 為了讓人們能夠一起工作,最重要的是給他們一個願意接受的美學願景。在你為自己構造的真理構建一個大家都能接受的願景時,你也是在表達一種理想。因為只有這樣才能讓人們獨立的、自由自在的追求那種理想
第一部分 人員
- 優秀的團隊必須把重點放在團隊成員的技術能力上
- 獲得適當的團隊成員並不是終極目標,它僅僅是完成了組建團隊的第一步
- 人們需要能夠一起融洽的工作,否則技能再好也沒有用
- 最成功的團隊實際上並不總是由最好的程式設計師組成,他們是由一些能夠一起融洽工作的人組成的
- 團隊中最有影響力的人並不總是最優秀的程式設計師。實際上,他們也不是經理或領導
第2章 醜陋團隊的獲勝之道
- 那些未能毀滅我的力量,反而使我更加堅強
- 我們中的大多數人受困於一種變形的、做作的、過於簡化的美學認知,總覺得漂亮的就一定好,而醜陋的就必然糟;我們甚至都不願去探究其他的可能性
- 完美的得分通常意味著能夠亦步亦趨的遵循某些規則,這並不能表明此人富有激情、思想自由,而且願意承擔風險
- 沒有風險、錯誤,不能同甘共苦,就難以形成人與人之間深厚的感情聯絡
- 漂亮的人們害怕傷疤,他們根本無法認識到傷疤的美麗之處
- 這些人會一起經歷失敗,然後互相舔舐傷疤,再共同重新振作,並仍像一個團隊一樣戰鬥。只有共同經歷這些,團隊才能發展處一種接近於美的特性
- 泰坦尼克號在下水當天身上鉚著幾千顆有毛病的鉚釘
第3章 構建影片遊戲
- 人們把他們的時間和技能都投入到團隊工作中,他們也需要從團隊中得到回報
- 說到什麼是最好的領導,這要看你領導的是什麼人了
- 領導者最優秀的能力是在開始的時候選擇合適的團隊,然後儘可能讓團隊成員實現自我領導
- 讓合適的人待在一起非常重要,讓兩個彼此感到心煩的天才一起工作是很糟糕的事情
- 如果你不去嘗試,那麼永遠都不會成功。如果真想去做,就要有所行動,動手做一做,看看會發生什麼事情。需要行動起來,即使遇到困難也不放棄
第4章 打造完美團隊
- 如果擠佔培訓時間,甚至不用等到專案結束就要付出代價
- 我們每個人都帶來一些東西,我們每個人都做出了貢獻,有一個對人們保持敏感的領導,這個領導知道人們的長處並接受他們的不足
第5章 激發開發人員的因素
- 社會關係交往是開源世界不可分割的一部分,不然,你不過是在自娛自樂罷了
- 你必須要對團隊成員的工作狀態保持敏感,併為他們提供一種工作環境,讓他們覺得這是你能給出的最有趣、最好玩的社交環境
- 尊重他人是有益的
- 禮儀就是人際交往的潤滑劑
- 關於禮儀,要記住三件事——尊重他人,傾聽他人,每天洗澡。如果能做到這些,那就解決80%了。原因在於:如果你做不到,人們是不會願意與你一起工作或跟你接觸的
- 除了伺服器著火之外,最影響工作效率的事情就是人們彼此憎惡,或無法共同工作。如果人與人之間存在任何發生衝突的可能,都應該馬上進行處理
- 經理的職責是讓人們順暢工作,不受其他事情的阻礙
- 正在干擾團隊的人們必須馬上改變自己的行為
- 智者領導:工作做得最多、最好的人就應該受到獎勵。如果獎勵就是此人被視作社群一位值得尊敬的成員,那他成為領導也是順氣自然的
第6章 激勵成員
- 如果人們不相信你會關心他們,那他們也不會在意你所說的話
- 我要做的就是給他一個有挑戰性的環境,讓他有動力去實現那個目標
- 在我們的團隊中,每個人都處於職業生涯的某個階段,將會到達某個目標,每個人都是不同的
- 人們渴望被關注
- 我們都討厭別人批評自己,但又都擅長批評別人
- 如果是零風險,那麼回報率也是零。沒有風險是不可能獲得成功的。風險就是不好的事情發生的可能性
第7章 將音樂帶向21世紀
- 花時間設計簡潔的架構,如果有已經公佈的標準就按照標準進行設計
第8章 內部開源
- “為重用進行設計”太僵化了,效果不一定好,而且適應性很差。這也許是努力的方向,但是在可預計按的未來中不具有可行性。“使用-使用-重用”方法要更合適
- 無論設計的目的是什麼,它總是在不斷變化的,所以永遠無法做到特別合適
第二部分 目標
- 在於團隊一起工作時,團隊目標不一致是可能出現的最糟糕的錯誤
- 團隊要確保目標寫在白板上,透過會議的方式,確保團隊對任何變化都一清二楚
- 客戶,也就是我們為之構建軟體的人,並不善於告訴我們他們需要什麼
- 作為開發人員,我們很容易認為自己已經完全瞭解了將要構建的軟體
- 如果你從一開始就讓每個人都與目標保持一致,在目標變化時讓每個人都知道(目標總是在不停變化的),那麼專案取得成功的可能性就會大得多
第9章 建立團隊文化
- 如果你所在的地方做的是一些極富創新的產品,而你們缺乏相互信任的文化,哪麼創新肯定會受到很大影響
- 軟體開發是一種關於人的體驗。如果能夠儘可能的考慮人的體驗,那麼信任自然也就產生了
- 既要尊重個人的工作風格,又要滿足業務的需求
- 作為優秀的專案經理,必須成為開發人員和組織的政治中間的一道屏障
- 最好的領導都非常善於表達,他們能夠編寫非常好的程式碼,他們也能夠和外面的人進行交談——他們能夠超越程式碼本身
- 優秀的領導都非常在意人際關係,能夠明白並尊重人們的感受
- 優秀的領導能夠同時在多個抽象級別工作
- 你面對的往往都是一些技術能力很強的人,他們都有一定的自尊,傲慢與缺少尊重是讓他們感到最惱火的事情。所以,請心態平和的進入角色。同時還要勇敢,不怕失敗
- 要向權力部門講真話,雖然這樣做在拿自己的生計冒險,因為有些人難以邁出第一步,但是這個職位確實需要如此。你必須尊重事實,否則,整個過程就會變成一個又一個謊言。要對權力部門說真話,這點非常重要。這是把你的團隊與令人不習慣的政治隔離開的另外一個方面
- 就算失敗,你也總是能找到另外一份工作:生命短暫,不必浪費在拙劣的組織中
- 健康組織的標誌之一是他們對失敗不會過分渲染。
- 極度刻板、根本不想失敗的組織一般來說也都是缺少創新的組織,那些人非常害怕失敗,總是採取最保守的行為方式,所以他們也沒有什麼樂趣
- 在失敗方面有一定自由度的組織是生產率更高的團隊
- 持久的組織一般都會不斷的重構,不僅僅是程式級別的重構,還包括架構級別的重構
- 把重點放在可執行的程式碼上,將沒有加工過的程式碼作為初始產品推出,這是最重要的事情,是一個敏捷過程
- 以增量、迭代的方式完成事情,節奏有一定規律,可以引入重構,在某個時刻可以做的稍微差一點,並且有並行的路徑讓你嘗試一些東西
- 把重點放在架構上,把架構作為管控手段之一
第10章 讓“我”為失敗負責
- 軟體專案的總體失敗率高達80%
- 實踐方法並不能確保成功
- 盡力為人們爭取一些更為合理的目標,儘管有些時候你的願望無法實現
第11章 制定計劃
- 優秀團隊都能從清晰明確、引人向上的目標中受益
- 想賺很多錢並沒有錯,但那並不能讓團隊團結一心,達成非同一般的目標
- 做的越好的團隊走的越快。如果你能寫出高質量的程式碼,你就可以加快步伐,因為沒有那麼多程式碼拖你的後腿
- 相對劣質程式碼而言,好程式碼能夠提升開發速度
- 清晰、催人向上的目標
- 一個應用中所有的程式碼不一定都要處於同樣質量水平
- 不是每件事情都要做到一流。在大多數情況下,我們根本沒有機會做到一流
- 不管工作流程的其他部分有多麼好,如果它不能提供某種程度上的可預測性,就無法使用
第12章 公眾利益鬥士攻佔邪惡之城
- 有時候,一定的成本消耗是不可避免的
- 身處社會之中,我們只能做這樣的事,它們產出的價值一定要比廢話多。專案越大,變為廢話的成本就越多
第13章 保衛自由世界
- 要有向更高目標前進的感覺
- 讓我們的技術人員從客戶那裡獲取深入的領域知識
第三部分 實踐
- 所有的團隊(即使每個團隊成員都表現出色而且配合默契)都存在不好的習慣
- 要找到更好的做事方法,這樣團隊就不會一再受困於同樣的老問題了
- 改變團隊的文化特別危險,這一點不必懷疑。實際上,不僅僅是文化會受到影響,改變甚至會威脅到團隊自身的存在。
- 在嘗試使用新實踐的時候,團隊會面臨兩個主要風險:一個風險是實踐本身可能沒有價值,而推動這個實踐的人對此一無所知;實踐本身確實很不錯,團隊成員卻無法深入體會其妙處。
- 對於團隊文化來說,最危險的事情莫過於在他們身上強加不適合他們的改變
第15章 構建協作性和學習型的團隊
- 團隊要保持活力,以高效開發軟體。過多加班會降低產品質量,讓人員疲憊不堪,得到難以預測的產出。每個人都會努力工作,但是要保持可持續的速度
- 構成偉大團隊的一個要件:一位眼光長遠、敢作敢當、願意支援團隊的管理者
- 唯一具備所有細節的需求形式就是程式碼
- 一粒老鼠屎真的會壞一鍋湯。某人的情緒不對頭,真的會毒害整個協作團隊
- 要改變現狀還是有可能的
- 只要人們想協作,他們就會去協作。如何提升想協作的氣氛?
- 提升他人:認可他人
- 提升安全感:支援其他人,可以挑戰別人的想法,但是要予以實踐
- 取得進度:成功孕育成功
- 增加活力:挑戰和奉獻
第16章 更好的實踐
- 質量就是要滿足需求
- 如果人們很自私,只願意做他們喜歡做的事情,就很難建立一個高績效的團隊了
- 作為團隊領導,大量的思想應當投入到團隊的目標上
- 做一些工作來培養團隊,這對工作本身是有幫助的
- 士氣與激勵通常都是相關的,但並不總是這樣
- 我們學習的課程告訴我們你是一名個體程式設計師,你的目標是成為程式設計大師,但是在參加工作以後,面臨的環境無一例外都是基於團隊的
- 如果某個程式設計師是不可或缺的,那麼應當解僱他
- 團隊中的問題程式設計師代表了對專案的超高風險;他們可能並沒有那麼出色;他們耗盡了團隊其他成員的精力。作為經歷,可以想辦法培訓他們,讓他們變得更好;作為老闆,應該儘早擺脫他們以降低成本
- 組織規模越大,層次越多,就越難維持開放與責任制,因為會存在一些小區域
第17章 TRW軟體生產率專案回憶錄
- 文化變革是困難的,而在大型組織中跟上技術的快速步伐就更加難了
- 在開發上每投入一元錢,就需要在軟體生命週期中花費兩元錢來保證產品是可用的
- 打造完美團隊的關鍵之處
- 識別所有對成功至關重要的利益相關者,並將他們全部包括進來
- 事先做大量的傾聽、探索和團隊構建工作
- 指定一個產品及其結構的願景,並讓大家都知道
- 支援以為思想開放、善於傾聽、善於打造團隊的經理
- 鼓勵來自外部和內部的思維創新
- 關注並處理團隊的需求
- 以尊重個人的方式調配相處不融洽的團隊成員
- 與有衝突的利益相關者協商一個雙贏的解決方案
- 仔細的監控進度並主動的處理決定成功的威脅
第18章 建造宇宙飛船
- 團隊是很難管理的,有時候讓不同技能的和不同個性的人恰當的組合在一起是一件很有挑戰的事情
- 如果太多的人都有很強的個性,就很容易產生分歧了;如果太多的人都很溫順,你可能就無法得到最優秀的想法了。需要在二者之間找到平衡點。需要有一個讓人感到安全的環境,讓他們表達出他們關注的問題以及他們的想法
- 影響團隊日常運作的因素有兩個:個人性格和責任
- 最佳團隊都有一個共同目標。在為同一個目標而努力,彼此欣賞。尊重每個人。每個人都明白,團隊中的每一個人都做出了自己的貢獻
- 最讓人滿意的專案做的不一定是偉大的事情,而是那些團結一致、每個人都因為自己的貢獻而受到尊敬的專案
第19章 成功的需求
- 常常的,團隊在開始一個專案時並沒有討論如何進行協作。在專案支出就應當花些時間討論團隊如何運作,這段時間的投入是值得的
- “你們需要什麼?”在挖掘需求的時候這是一個最沒用的問題了。“你們打算利用系統做些什麼?”是更好的提問方式
- 馬拉松式的會議是沒有用處的,因為在幾個小時後,疲勞的眼睛就很難再貢獻更多有價值的意見了
第20章 在Google的開發工作
- 團隊經理的成功就是團隊的成功
- 有了敏捷方法的高可視性,就能夠早早的面對痛苦的現實了。你面對現實越早,痛苦就越少。雖然仍舊是痛苦,但那是修復問題所帶來的痛苦。
- 敏捷方法的缺點是無法隱瞞,這對很多開發人員和經理來說都非常恐怖
- 完成的意思就是完成了。完成的意思就是明天可以交付了
- 任何被檢入、審批、接受的主幹程式碼,任何一個呼叫功能部件的詳細過程在完成之後,都應當可以在今天交付
- 確定下來需要做些什麼,這是專案工作量的最主要的一部分,在專案過程中還需要做出調整,以便和利益相關者的需要做出相應
- 燃燒圖回答的問題完全是投入的工作量以及完成的工作
- 在截至日期之前沒有經過測試、承諾和接受的東西都不在這個迭代中
- 迭代中間的需求改變不是讓你的團隊成員大吃一驚的、出乎意料的隨機改變。這是有計劃的,它是可以預測的
- 工程師們,特別是年輕、聰明但是做過的專案不多、也沒有留下傷痕的工程師們,一般都喜歡多做一些東西。
- 開發團隊可以歸結為兩個主要目的:開發正確的軟體,以正確的方式開發軟體
- 更重要的是開發合適的軟體:軟體的功能集要讓公司能夠成功
第21章 團隊與工具
- 優秀的工具對團隊協作能力有變革效應
- 在專案中引入一個新標準並不是一件容易的事情
- 完美不可與優秀為敵
- 即使一小步自動化工作也可能給團隊的協作能力帶來顯著差異
- 對一個普通任務增加幾秒鐘的額外開銷足以讓這個任務變得不再普通
- 你的團隊不是懶人,只是普通人
- 對程式碼的提交進行評審保持了代價計程車氣,提高了人們的技能(因為他們都能相互學習),增強了團隊一起工作的能力(因為每個人都習慣於接受他人有建設性的批評),並且對參與專案形成了激勵(因為評審是公開的,所以鼓勵其他人做同樣的事情)
- 如果一開始就面對一條陡峭的學習曲線,真是再糟糕不過了
- 部分自動化常常已經足以產生差別
- 好工具的關鍵並不是說不再需要人們,而是讓人們更快樂
第22章 研究團隊
- 如果不知道一件事情對不對,就必須透過試驗來證明
第23 章 HADS團隊
- 一個高階語言編譯器,能夠跟蹤利用的知識比程式設計師腦海中保留的知識要全面的多
- 如果使用者找不到其他原因,就要責怪工具了
第四部分 障礙
- 在構建軟體的時候,一些最難處理的問題是那些你無法控制的事情
- 如果不處理那些阻擋團隊道路的障礙,軟體將很難構建。一個最大障礙就是糟糕的經理
- 人的本性都傾向於談論自己的失敗
- 在每一種情況中,都有一個重要的經驗需要學習,人們由於經驗而變得強大,即使他們所在的團隊本身已經不存在了
第24章 糟糕的上司
- 有些時候,在明天道歉比今天獲得批准更好
第26章 跨越障礙
- 在軟體團隊中,人是成功最主要的因素。你和其他人的交流方式比你今天使用的任何一種很酷的新技術所產生的影響都要大
- 需要關注的不僅僅是技術
- 不是每個人都一樣,有些人就是不願意在團隊中工作。有些工作是可以單槍匹馬完成的。
- 敏捷開發:有紀律的敏捷軟體開發是一種迭代和增量(演進)的軟體開發方法,由自我組織的團隊透過高度協作的方式,在一個繁文縟節“剛好足夠”的有效的監管體系下,以節省成本和及時的方式生產高質量的軟體,從而滿足利益相關者不斷變化的需求
- 需要有人密切注意整個團隊,確保整個團隊停留在正軌上,確保他們所作的任何事情對整個組織來說都是有意義的
- 糟糕的監管會削弱領導能力,讓我們試著提高監管的有效性,因為監管的價值在於幫我們做出好的決策,走向正確的方向
- 把洗澡水倒掉,但把孩子留下
- 一 個組織總會有很多要做的事情,但是資金只有這麼多,所以他們必須選擇做些什麼,希望能夠有效的完成。因為你要確保實現那些目標,所以專案決定了工作量。如 果目標發生了變化,要確保自己立刻跟著變,你需要監管這種發展。你需要常常對照現實情況做出檢查,應當經常進行檢查,但實際上並沒有做到。
- 專案遇到困難時,必須有人做出決策,看看如何把團隊帶出困境。如果沒有人知道如何把團隊帶出困境,現在就需要切斷供給,不要再把錢扔到沒有用的地方
- 讓專案與公司保持一致,確保專案構建的是它應該構建的東西
- 如果一組人在一起工作的時間足夠長,他們就開始以同樣的方式思考了,對於同樣的問題產生盲點
- 監管應當與授權和激勵有關,不應當成為命令和控制的方式,不應當成為負擔
- 做監管的人最常犯的一個錯誤是試圖把同樣的過程和同樣的監管體系強加給不同的團隊,因為不同的團隊需要不同的方法來監管,所以這種方法是行不通的。目標可能是一樣的,但是實現這些目標的方式是不同的。你應當實現可重複的結果,不是可重複的過程
- 願意尋求幫助是至關重要的,但是願意給予幫助也是至關重要的。武術的一個原則是透過幫助與教導別人,比你自己學習能夠學到的東西要多
- 不僅要幫助他們完成工作,還要幫助他們以專業的方式開發
- 對於結對程式設計,你需要做的就是堅持到底做下去
第27章 速度與質量
- 團隊有一個“紳士般”的文化,在出現糟糕的事情時也不會說髒話
- 抓緊那些小任務,如果遇到困難,請告訴我
第28章 層層障礙鋪墊之路
- 如今的豬圈都有格子間的兩倍大
- 擺脫掉這些拖後腿的傢伙後,如果你要是做的事情太少,那麼自己都會覺得內疚。因為你環顧四周會發現所有人都忙的不亦樂乎,於是你也只能努力工作了
- 質量問題的開銷在產品時間線上呈非線性
- 質量是一家企業成敗與否的最根本因素
- 質量問題就像地雷,可以潛藏很長時間。恰恰在最不合時宜的時候,它們會給我們造成嚴重的損害
- 沒有了樂趣,這就只是一份工作而已,甚至還算不上什麼好工作
第29章 辦公室內外
- 孩子們不喜歡向父母表露自己的感情,需要仔細的觀察
第30章 彙集團隊的聲音
- 企業的建立和消亡是已經很平常的事情。它們留下的永久財產是那些僱員們
- 專案對員工成長的影響與專案的既定目標同樣重要
- 負責理性行為的自我退回到本我,導致本能衝動的爆發
- 讓每個人的意見都能得以表達
- 每一次成功和失敗都可以用來幫助改進團隊建設
- 每一個專案決策都應該考慮它對團隊成員和專案資源有何影響
- 消除那些沒用的會議
- 專案的加速前進只能讓時間變得更快
- 歷史上,公司在作出重要的工程決策時都會重視工程師的意見
- 尊重工程師,容忍他們固執己見的表達方式
- 公司應該徹底開發並利用僱員(或客戶以及其他利益相關者)的潛力,使他們成為有發言權的組織政策制定者
- 我們沒有必要去努力維持一個正在消亡的商業模式
第五部分 音樂
- 隨波逐流、全憑感覺是不夠的。美學願景驅動著過程
- 如果人員足夠優秀,受到激勵、產生興趣並且具備技能,是可以奏出曲目的,讓他們有所領悟並即興發揮
第31章 製作音樂
- 要成為專案經理,應當對將管理的所有工作都非常熟悉。你不需要是最好的,只要掌握了每項工作的知識就可以了
- 某些人如果尊重你的能力,就會按照你的指導去做,或聽從你的建議,至少認為你的知識足以給他們指導
- 學習如何跟人們說話實際上是一門非常重要的課程
- 你的誠實和承認錯誤的勇氣能夠讓團隊保持對你的尊重。如果你想掩飾自己的無知或讓自己看上去總是很清高,你就越來越像個贗品,團隊會離你而去
- 好的專案經理一個最正面的目標是激發出專案成員最好的一面,而不是抑制他們,不能妨礙他們前進,不要把他們擠在兩堵牆中間
- 你要做的是在團隊中培養英雄,讓你團隊中的人(如果可能,是團隊的所有人)都能發光,讓你們的團隊看上去像是一個頂尖的團隊
- 你必須讓他們的意見得到傾聽,你必須這樣做,一定要這樣做
- 當你拒絕某人的想法時不要針對個人
- 交流的方式可以有多種,當你發現他們走錯路的時候,你要激發出人們最好的一面而不是抑制他們
- 要麼好,要麼不好,總要有個人出來說一下
- 你一定不能有這種想法,認為付錢給你製作這一切的人是敵人
- 如果早期讓出資人介入,那麼他們會因為感到自己介入了中間過程而對最後的結果更容易接受
- 你必須具備技術能力,你必須理解程式設計師的問題,你也必須理解公司的利潤問題
- 挑選團隊成員時要非常小心
- 你必須根據人們以後是否能夠融洽相處來建立自己的團隊。一旦出現問題,你有終極武器:解僱某個團隊成員。這不是壞事。這可能成為很好的事情,因為如果能夠擺脫麻煩製造者,團隊的力量會得到增強。
- 解僱人是不可避免的
- 如果你衝著他們叫嚷,他們聽到的不是你說的話,而是你的怒氣。你必須控制怒氣
- 當你講出事實的時候可能會很生氣,但是不要顯露出來,它會讓你付出代價的
- 公開的進度圖讓每個人都能參與進來
- 任何一個涉及大量資金的事情都需要有組織
- 在做專案的時候,必須誠實的考慮預算所帶來的約束
- 互動的事情能夠讓團隊真正的融合到一起。如果你在做決策的時候能夠讓他們參與,他們會非常熱心
- 人類的思考方式很奇怪,有高度創造力的人社交技能一般都不好,因為他們大部分的腦力都用到了高度創造力的事情上
- 如果沒有“明星”,將無法成為一個團隊
- 真正聰明的“明星”知道如果沒有一個優秀的團隊,他們將很難成功
- 你必須是團隊中最清醒的人
- 在這個充滿天才的世界上,任何一個團隊都可能被替換掉。每個人都有責任學習如何與其他人一起相處,就算是“明星”也不例外
- 你們是在與其他頂尖團隊競爭,你不能讓內部有爭吵,你不能讓團隊的明爭暗鬥破壞士氣和團隊生產率。
- 一個態度好的人會替換掉你。誰都可以被替換
- 現在有太多讓人分心的東西,讓我們很難把精力集中在所從事的事情上
- 計算機技能並不難獲得
- 我們的危險是失去了集中注意力去掌握一樣東西的能力
- 你知道的越多、學習的越多,你人生中成功的機會就越大
- 把你的閒暇時間拿出來,多學點東西
原文網址:http://dearymz.blog.163.com/blog/static/205657420110884838587/
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/16502878/viewspace-696835/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 《團隊之美》的那些作者們
- PDD介紹美菜前端團隊(上)前端
- 讀大道至簡之我見3——團隊建設
- 團隊動力之團隊發展階段理論
- DevOps 團隊之殤dev
- 《GIT團隊協作》讀書筆記Git筆記
- SkyReach 團隊團隊展示
- 如何讓IT團隊和安全團隊之間更好地進行協作
- 小團隊管理與大團隊管理
- 團隊溝通利器之UML——類圖
- 6、Git之團隊協作機制Git
- 豆瓣閱讀:10 人小團隊的“慢工細活”
- 讀後有感,專案團隊協作感悟薦
- 《瞬間之美》讀書筆記筆記
- 《架構之美》閱讀筆記架構筆記
- 團隊作業1——團隊選題&展示
- 團隊作業1——團隊展示&選題
- 團隊競技遊戲要限制團隊配合遊戲
- 團隊管理
- Zero團隊
- 團隊分工
- 團隊活動
- 前端團隊前端
- 團隊8
- 團隊如何組織?前後端團隊與業務功能團隊的比較後端
- Jenkins 使用指南 之 團隊部署篇Jenkins
- 專案成功之團隊精誠合作(轉)
- 團隊動力之社會認同理論
- 網路時代的團隊:虛擬團隊(轉)
- 團隊作業1——團隊展示與選題
- 讀《進化:從孤膽極客到高效團隊》
- 《數學之美》讀書筆記&思考筆記
- 花花隊——團隊貢獻分
- 鹹魚翻身隊——團隊展示
- CSS團隊精神:CSS最佳實踐團隊開發CSS
- 技術團隊
- 團隊建設
- 團隊專案