這是
《程式設計師》
的約稿，已經發在7 月那期的第80 頁，職場相關話題「如何撥打工作**」，4 個小豆腐塊中的第一塊（選題佔了個小便宜），命題作文總覺得寫的乾巴巴，而且還要考慮字數限制，真的很像小學生作文唉，貼出來大家看看吧，格式上稍作了調整方便閱讀：
按照做產品的思路，要不咱先不談「 怎麼做」 ，而談談「 做不做」吧，即什麼時候適合打**。想想這種「 一對一」 的溝通場景，常用解決方案無非4 種：**、email 、im （即時通訊軟體）、面談。
**********====
小結一下，緊急、短暫、簡單的溝通，適合打**，並且和email 、im 、面談可以靈活組合應用，而具體如何打，請看另幾位的文章，：）
豆腐塊結束，發現這篇也可看作「 **」 這一產品在工作中的應用場景分析，順手畫了個圖，參考了時間管理的思路，從「緊急」、「重要」、「成本」的角度比較一下上述幾種溝通方式，另外之前也寫過有關一對一溝通話題，可以看這裡
。 如果看不到，請參考這裡
本期同名話題的4 個豆腐塊，還有李笑來老師的一篇，
原文在此
，當然，這篇是加強版了。其他兩位豆腐塊作者的文章，在網上沒有搜到。
李笑來老師的部落格
讓我收穫很大，向大家推薦一下，而他的新書
《把時間當作朋友——
運用心智獲得解放》
，也是絕對值得一讀。
產品設計體會（十六） Feature List
看不清吧，那就對了，暫時不能讓你們看清 p 乙個feature，這次我給了它如下屬性 模組 一般來說，每個模組下分3 10個子模組是合理的，否則要考慮重新劃分 由於這個癖好，自己電腦裡的檔案目錄結構也是遵循這個原則的 子模組 稍大一點的產品至少要給功能模組做二級分類了，這部分其實又涉及另外乙個很大的...
產品設計體會（十二） 少而精
長假回來，這兩天基本在全力做 批量定時上架 的需求，n多的pk 評審 確認會搞得頭昏腦脹，不過終於算是把需求確認掉了。其中有些關於功能做多做少的爭論，這個話題在體會 三 中有所設計，但說的不深，這裡再寫點。一 個功能的多次需求會議中，必然有這樣乙個過程。開始對乙個功能想的不完整，說著說著大家都想把這...
產品設計體會（十六） Feature List
看不清吧，那就對了，暫時不能讓你們看清 p 乙個feature，這次我給了它如下屬性 模組 一般來說，每個模組下分3 10個子模組是合理的，否則要考慮重新劃分 由於這個癖好，自己電腦裡的檔案目錄結構也是遵循這個原則的 子模組 稍大一點的產品至少要給功能模組做二級分類了，這部分其實又涉及另外乙個很大的...