老闆專案，就是指老闆突然跟你說，我們要做個什麼什麼，然後你只有執行的份兒……的專案。什麼，你們公司所有專案都是老闆專案？很正常，那我們更應該聊聊這個話題了。
先來一點科普，做專案的目標無非是多快好省：範圍多、時間短、品質高、資源省。但又要馬兒跑又想馬兒不吃草的事情是沒有的，有理智的老闆也都明白這一點，所以我們通常是在上述4 個要求中做平衡。對比經典的專案trq ：專案時間（time ）、專案資源（resource ）、專案質量（quality ），幾乎一樣。一點區別就是q ，我覺得q = quality+quantity 更準確，質量這個詞其實包含了「品質」和「數量」兩個含義，而我所經歷的專案，q 更多的是表達quantity ，一般來說，品質高這點是不會捨棄的（不排除有特殊場景），所以可變的是專案範圍。
綜合一下，我們做專案就是在時間要求、人財物花費、專案範圍三點上做平衡，不妨就繼續叫做trq 吧。
來乙個真實場景回放：「你突然被老闆叫到辦公室，他和藹可親，又情緒激動的對你說，小某啊，組織上有個重要專案要交給你，blablabla ，省去半小時，這都不關鍵，最後一句：某月某日之前一定要發布！」似曾相識？嗯。首先恭喜你，通常這樣的「老闆專案」都是重要的專案，說明老闆信得過你。然後你要反駁了，恭喜什麼啊，我牙還沒刷呢，連做什麼都不知道，居然trq 的t 已經定了？！
是的，當時就是這樣。
傳統專案管理中的那一套，先需求，知道要做什麼以後，再組織協調資源，最後推算出時間計畫，在這裡跑不起來啦。我腦中突然浮現一句話，改編如下：做專案，特別是老闆專案就像被，與其無畏的反抗，不如好好享受。
於是，阿q 的我們找到了理論支撐：agile，敏捷！
不是麼，更多的時候我們都是被動敏捷，或是被老闆逼的，或是被使用者逼的，或是被對手逼的……人類的本性應該還是恐懼變化和不可知的吧，不知有多少人看到這裡內心在吶喊——我愛瀑布模型！
所以有公司在價值觀裡宣揚「擁抱變化」真是很積極的一種人生態度。那我們來擁抱敏捷吧，看看在trq 三方面應該如何享受：
t是給死的， 可以試著商量一下，但一般很難改變，如果是老闆的老闆給老闆定的，那就更甭想改了。通常，每一級任務的下放，老闆都會給自己留一小段時間做緩衝，但是我們 可千萬不要在定專案計畫的時候算上老闆留給自己的這段時間，反過來，我們訂計畫的時候應該再給自己留一段，這些都是最後救命用的。
q是可變的，先說q ，一般越大的老闆給出的指示越戰略性，越不具體，所以具化出來的q 就可大可小了，所以開始的時候，盡量發揮自己的聰明才智，先天馬行空的爽一把，把q 搞大搞大搞大，並合理的算出乙個巨大的r ，然後，你就可以欣賞到老闆因為無法付給你這麼多r 而自己砍q 的表演了……當然，我們應該盡職的幫老闆排出各種功能的建議優先順序和所耗資源，好讓老闆知道刀該往**揮。
r是豐富的，老闆專案麼，第一優先順序，r 就是大大的有，其他專案統統讓路，讓多少路，這個問題應該拋回給老闆決定，我們只提供專家意見，獅子大開口：讓的越多越好！記住，千萬不用在這個時候就幫老闆著想，應該怎麼節省r ，那樣反而不討好，老闆會覺得你思路不開闊，沒勁，我有過一次做了個專案方案，十幾個人就搞定，沾沾自喜，結果老闆說：你先給我照著100 個人做這麼久來規劃。
真的這麼爽？
當然不是，有時候你發現，老闆比較猛，q 都幫你想好了，那只能說沒勁，也別廢話了，甩開膀子幹活唄。更悲劇的是，r 也是不足的，就那麼幾棵人，又要在固定的t 下做這麼多q ，絕望？不至於，我們還有最後一招it 民工必殺技——加班，天天加班，天天加班還不要加班費……我們期望的是老闆看得到，公司有前途，明天會更好……
如果這樣還做不完，那只能說——老闆喪失理智了！兄弟，撤吧……
最後談談，老闆專案到底好不好？從個人角度，如果是純專案經理，這就是本質工作，無所謂好壞，而對於我們這樣做產品的同學，老闆專案沒有成就感（有成就感的專案是自己去做使用者/ 市場研究，然後發現問題，發起專案），而好處就是接近老闆，無需多說；從老闆/ 公司角度，效率高，決策風險大，其實，這和民主與**的區別是很像的。
ua:f [1.2.0_562]
如何做好產品設計
今年早些時候，我曾經問過幾位作家是怎麼寫書的，比如 流血的仕途 作者曹公升 科幻作家劉慈欣，發現他們寫書的方式，居然和我想的不一樣。據他們說，基本上是順序寫下來的，甚至寫的過程中自己也不知道後面會發生什麼情節，也許和他們寫的是 有關係。對比起來我的寫作就很特別了，簡直是把書當軟體來做了，有點瀑布模型...
如何做好「老闆專案」
老闆專案，就是指老闆突然跟你說，我們要做個什麼什麼，然後你只有執行的份兒 的專案。什麼，你們公司所有專案都是老闆專案？很正常，那我們更應該聊聊這個話題了。先來一點科普，做專案的目標無非是多快好省 範圍多 時間短 品質高 資源省。但又要馬兒跑又想馬兒不吃草的事情是沒有的，有理智的老闆也都明白這一點，所...
產品設計體會（十六） Feature List
看不清吧，那就對了，暫時不能讓你們看清 p 乙個feature，這次我給了它如下屬性 模組 一般來說，每個模組下分3 10個子模組是合理的，否則要考慮重新劃分 由於這個癖好，自己電腦裡的檔案目錄結構也是遵循這個原則的 子模組 稍大一點的產品至少要給功能模組做二級分類了，這部分其實又涉及另外乙個很大的...