agustin villena在說服管理層接受看板限制（kanban limit）時，遇到了乙個問題。他寫道:
\
我是一名諮詢師，遇到了這樣的管理者們，犯難了——儘管看板上清楚地顯示著他們的員工們已經在超負荷工作了這一事實，但他們卻意識不到這對產能和工作壓力的負面影響……\
他還寫道:
\
現在的問題是要去限制分配給團隊的專案總量。但是我們沒法說服他們的經理減緩接專案。\\他們的信條是鬆弛等於浪費……
\
為什麼我們不認為鬆弛是浪費呢？按tom demarco的說法，鬆弛是「實現改變所必需的自由度」。這麼理解的話，那麼鬆弛就可以被看作是在乙個組織中預防運動磨損所需的潤滑劑。
\ mary和tom poppendieck所著的《敏捷軟體開發工具——精益開發方法》一書中提到，從排隊理論的角度看，鬆弛還能達到乙個更為基本的目的：「如果沒有某種程度的能力鬆弛，高速公路就無法提供可接受的服務。同樣，如果在組織內沒有鬆弛的機會，你也許就無法為客戶提供最高水準的服務。」
\ amir kolsky對「鬆弛就是浪費」提出了精闢的反駁:
\
鬆弛不意味著大家在放羊。\\鬆弛是指大家做事不要苛求極致，直至遇到瓶頸狀態。
\ 鬆弛的時候可以做點別的事情，他們也可以很忙。
\
那麼，什麼造成了對看板限制的抵制呢？nader talai認為管理者們對看板限制這一做法產生牴觸，在一定程度上可能是出於對他們團隊績效評估的考慮:
\
你知道管理者們看重的或者被考核的是什麼嗎？看板能顯示他們所看重的東西嗎？\\[...]
\ 比如，衡量乙個管理者績效的是專案開發完成情況，而不是零缺陷交付。我就曾在那樣的乙個公司工作過，他們考核it團隊能不能根據12個月前估算的完成日期按時交付專案。在這樣的公司裡，重點是按時交付，不管交付的是什麼或者質量怎樣。
\
tomo lennox認為，可能還需要給管理人員多多**:
\
如果管理者們單純的認為，分配給你的工作越多，你產出的就越多，那麼除非你能給他們洗**，否則他們不會改變的。\
不過有時也別小覷笑話的力量，它同樣能幫你傳達思想。「人們更能聽得進笑話。」 lennox寫道:
\
乙個警察看見乙個男孩推著自行車在跑，於是他跟上去想幫忙。「你爆胎了嗎？」警察問。「沒。」男孩回答並繼續推著車跑。警察又追上男孩並試著問。「那麼你的自行車怎麼了？」「沒事。」男孩說完就跑開了。警察再次追上男孩又問了一次：「那麼你為什麼不騎車呢？」「我上學要遲到了，我沒時間上車。」……他繼續往前跑。\
\檢視英文原文：get back to work!
\ 感謝金毅對本文的翻譯。
幹活兒去，別閒著！
agustin villena在說服管理層接受看板限制 kanban limit 時，遇到了乙個問題。他寫道 我是一名諮詢師，遇到了這樣的管理者們，犯難了 儘管看板上清楚地顯示著他們的員工們已經在超負荷工作了這一事實，但他們卻意識不到這對產能和工作壓力的負面影響 他還寫道 現在的問題是要去限制分配給...
跑外業的也能協同幹活兒了 向量雲端分享
協同作業中，經常需要在各個地方使用向量資料，也需要把向量資料分享給需要的同事。那怎麼操作呢？lsv最近收到不少老使用者的反饋，說我們這麼多人幹一件活兒，跑這裡跑那裡，標記的東西怎麼能協調統一管理呢？要是乙個人想接手另乙個人的活兒又怎麼弄呢？用郵箱，又不直觀又容易出錯啊。這不是乙個現成的雲端使用場景嗎...
第20課 設計高效能網路伺服器，能幹活就別閒著
在軟體開發行業中，一提到高效能，就會立即給人一種高大上的感覺。那麼在同樣的硬體平台上，為什麼有的伺服器可以稱為高效能，而有的就不行呢？在本節課中，我們就拿乙個網路伺服器作為例子，看看它是如何從最簡單的模型一步步演化而來，並且討論每一步演化過程的改進之處，主要內容包含 要討論高效能伺服器，首先要對它做...