中國一句古話，麻雀雖小，五臟俱全。
但是小項目也能有大娛樂，google、37sigal，都是以"精小而美"著稱。雖然還要面對軟件時間，但是不用去面對布魯克斯法則、不用煩心長長的bug list，不用強打精神奮戰在動則幾小時的溝通協調會議等等，小項目無疑更幸福^_^。
若讓我描述項目管理，我會以站在地獄想天堂來總結之。
一次不開心的敏捷體驗。
2年前開始帶項目，嚴格來說是開發leader，如果武功是以毫無雜念爲最佳天資，對項目管理卻是天生殘缺。與其說敏捷讓我吃盡苦頭，事實最多隻是我作繭自縛。像所有人一樣，我期望找到銀彈解決所有的問題。失敗以後，我信奉帶人要帶心的信條，完全站在開發人員一邊。至此，你應該猜到，項目被我推向了失敗的邊緣。項目關係人對項目團隊失去了信心，要求更多特性，更快的交付時期，開發人員越加痛苦。
辛苦卻看不到結果，這是程序員最大的痛，也是項目最大的痛。
軟件時間
程序員不擅長估算時間，估算剩餘時間卻是例外。
估算會議上所有人估算出軟件的完成時間，但是這個時間不是精確的，這點我知道，一開始其他人也知道。前提是項目關係人沒有失去耐心。現在的我會將任務的剩餘時間即時更新，並且定出優先級，與客戶溝通下次發佈的任務。但是那時的我昏了頭，一味替團隊開脫，可笑卻說不出什麼時候可以交付新的版本。因爲我也是開發人員。
不知道什麼時候完成任務？即使完成了也不一定是用戶可用的。 --這是項目管理最難的部分。
出現這個問題的時候，你或許正讓幾個人來完成一個功能。看起來7人的團隊，卻交付不出兩個人的成果。即使存在優秀的程序員勝於10個爛程序員的事實，壹加壹難以等於二卻是不爭的事實。如果我有兩個優秀的程序員，現在我更願讓他們各自完成的自己的工作。因爲我再也不想聽他們抱怨會議佔用太多的時間，我沒有時間編寫代碼了。
布魯克斯法則
“只有一個月了，還有兩個月的任務，你讓我如何幫助你。”
“給我加一倍的人。”
如果你這樣做了，你一定會失信於人。這個有悖常理的法則把我從最後一根稻草上拉下來。
我不是答覆機，現在我寧願頂着頭皮讓客戶選擇最高優先級的任務，然後讓程序員更早的demo產品，安撫程序員”脆肉”的心靈。
提防磨刀時間
“手動導數據太麻煩了，我準備些個腳本來完成”
“腳本還有點小問題如果別人希望把關聯的其他數據也要導入呢？我要修改一下”
“。。。”
研究新技術，或者編寫新工具確實能改善生產率，但不是現在，而是未來，如果未來你還會遇到相同的問題。將來最大的問題是，問題總是以面目出現在你的眼前，即使拋卻這個不計，它也是犧牲現在的時間，在將來獲得回報。如果項目本來很緊，我寧願用最笨的方法，也不情願將另一個軟件時間引進我的項目。
總結
人多力量大，對於項目管理而言是藝術，對於現在的我或者其他人都是很難的。如果一個人可以完成的事情，10個人未必會更好、更快。