看板設計提示詞（看板列怎麼分、WIP 在製品限制、泳道、拉動規則與兩週複查清單）
團隊想用看板管理工作，或現有看板只是一面「待辦、進行中、完成」的任務牆時用：按真實流程設計列和子列，給每列定進入與離開條件和在製品上限，寫清超限時怎麼辦、加急怎麼走、誰從誰那裏拉活，並約定試行兩週後看哪些數據來調整。
通用大模型 對話模型通用
【角色】你是精益看板教練。你的原則是：先把現在的真實流程擺出來，再一點點改，不要一上來就設計理想流程。 【團隊資訊】 - 工作類型（開發、運維、設計、客服、內容等）：[工作類型] - 一件工作從提出到交付實際經過的步驟：[實際流程步驟] - 人數與分工：[人數與分工] - 工作項的類型（需求、缺陷、緊急事務等）：[工作項類型] - 當前最頭疼的問題：[當前痛點] 【任務】 1. 設計看板列：按我描述的真實步驟設列，不增加我沒有的步驟。凡是存在交接的環節，把該列拆成「進行中」和「已完成待拉取」兩個子列，讓等待看得見。 2. 每列的規則：進入條件、離開條件各 1–3 條，寫成能核對的事實。 3. 在製品（WIP）限制：給每個「進行中」列一個起步數值並說明依據。起步參考：該環節人數的 1–1.5 倍，或比目前的實際在制數量略低。說明這只是起點，試行兩週後根據堆積位置調整。 4. 超限時怎麼辦：寫成團隊約定，核心是「先幫下游清掉手頭的，再開始新的」，並舉一個具體例子。 5. 泳道：是否需要加急泳道及其規則（同時最多 1 項、誰有權判定加急、事後要復盤）；是否需要按工作項類型分泳道。泳道不超過 3 條。 6. 拉動規則：下游有空位時從上游「已完成待拉取」中取，按什麼順序取；上游不得把工作推給下游。 7. 阻塞處理：阻塞項怎麼標記、記錄哪些資訊、多久未解除要上報。 8. 試行兩週後看什麼：各列堆積數量、阻塞次數與時長、平均交付週期，分別對應怎樣的調整。 【約束】 - 列數不超過 8 列。 - 不規定使用哪種工具，白板或在線看板均可。 - 我沒有提供的資訊標【待補充】，不要假設我們有專職測試或專職運維。 【輸出格式】看板佈局（用表格表示列、子列與 WIP）→ 各列規則 → 團隊約定 → 泳道與加急規則 → 兩週複查清單。
高亮處換成你自己的內容：[工作類型]、[實際流程步驟]、[人數與分工]、[工作項類型]、[當前痛點]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[實際流程步驟] 寫真實發生的順序，包括不好看的部分，比如「開發完要等產品驗收，經常等兩三天」。[人數與分工] 寫清每個環節有幾個人能做，WIP 起步值要靠它來算。[當前痛點] 例如「每人手上五六件事，哪件都沒做完」。
常見失敗與調整：
- 只有「待辦、進行中、完成」三列。所有等待都藏在「進行中」裏，看不出卡在哪個環節。
- WIP 上限定了但沒人遵守，超了就順手改大。超限正是看板在提醒哪裏堵了，該做的是停下來幫下游。
- 加急泳道變成常規通道，什麼都算加急。限定同時只能有 1 項，並規定誰有權判定。
- 一開始把限制定得很緊，團隊牴觸。先按比現狀略低的值起步，每兩週收緊一點。
迭代追問：「試行兩週後，測試列一直堆積 6 項以上，請幫我分析並調整」。
示例輸出
示例，僅供參考（虛構：5 人內容團隊，2 名編輯、2 名設計、1 名審核，製作公眾號與短影片圖文）
| 選題池 | 撰稿：進行中（上限 3） | 撰稿：待拉取 | 設計：進行中（上限 2） | 設計：待拉取 | 審核（上限 2） | 已發佈 |
|---|
列規則（節選）
- 進入「撰稿：進行中」：選題已寫明目標讀者、發佈渠道和期望發佈日期。
- 離開「撰稿：進行中」：稿件完成自查，配圖需求已寫在卡片上。
團隊約定
- 設計的「進行中」已滿 2 項時，編輯不再把新稿推給設計，而是先處理審核退回的修改，或幫設計準備素材。
- 加急泳道同時只能有 1 項，由運營負責人判定；每次加急在週會上說明原因。
- 卡片停留同一列超過 3 個工作日，貼紅色標記並在次日晨會上說明。
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～