序
- 沒完沒了的各種項目會議，到底有沒有用？
- 本來6個人的項目群，幹着幹着擴成了30人，這是什麼情況？
- 都進入開發了，産品說要補下規則，該不該接？
- 項目結束了，産品說自己工作到位了，開發說自己沒問題，但軟體就是沒法用，這是誰的鍋？
- ……
大家好，我是TF男孩，一名常年卧底在程式員中的程式設計表演藝術家。
今天開始呢，我将給大家白話項目那些事。
今兒個先談一個現象，那就是：不懂開發可以帶項目——嗎？
第一集：來了一位美女項目經理
不懂開發可以帶項目嗎？肯定是可以，因為必定是有人這麼幹了，是以才産生了現象。
但是，現象不一定都是好現象。
如何實施軟體項目，被納入了管理學的範疇，管理學有一個特點，那就是和行業無關。
不管你是哪個行業的，從文化到醫學，從餐飲到建築，我這一套方法你都可以用。
學術派屬于學術界，它并不屬于IT界。
見過一些漂亮小姑娘，二十來歲，知名大學畢業，輾轉幹過文員、行政等工作，皆不如意，後來考了個項目管理證書，于是去機關機關帶起了軟體項目。
- 小姑娘問我：下一步該幹什麼了？
- 我說：你是項目經理，你安排啊！
- 小姑娘說：那我安排你列一下項目計劃吧。
小姑娘就是理論派的代表，她們強調你不用懂開發細節，項目管理的本質是管理，把握好各個流程就可以。軟體開發不就是分析、設計、編碼、測試、傳遞這些流程嗎？你隻要控好流程，流程不缺失，效果就不差。
你是個司機，沒有必要了解汽車的詳細構造，這絲毫不耽誤你成為一名優秀的司機。
當然了，你了解更好，不了解也沒事，可以去問别人嘛！
劉邦不懂打仗，但是有蕭何、韓信。劉備不懂打仗，但是有關羽、諸葛亮。你看，反而不懂的人成就了霸業。
是以，項目管理就是要充分調動大家的積極性，嚴把時間節點，嚴控項目品質，這才是關鍵。
說的很有道理，就像你剛從總經理辦公室出來，感覺進門前的疑難問題都不是問題了，原來是自己格局小了。
第二集：成功學的副作用
但是，你一旦行動起來，馬上就發現不對了：
- 诶？不懂車的構造好像是不耽誤我開車，但現在是TM讓我去造車呀！
- 控流程是沒錯，但是程式員幹沒幹完我都沒法判斷，我怎麼控？！
管理學大師頭上閃着金光從天空45度角的方向出現了，說話帶着回音……着回音……回音：
- 關于專業的問題，你可以去咨詢專業的人，不懂開發你可以去問開發經理！
- 不懂産品你可以去問産品經理！
- 不懂測試你可以去問測試主管！
- 不懂啥就問啥。
- 就像你不懂管理，來問我一樣，我必定會告訴你答案。
啾啾啾啾……大師說完就消失了。
小姑娘如同醍醐灌頂，頓開茅廁……茅塞，恍然大悟，虔誠地向着餘光拜了很久，直至太陽落下了山，秋蟲兒鬧聲喧。
她躊躇滿志地走進辦公室，面對衆人，決定重整河山，結果又遇到了很多問題：
- 開發經理和程式員同穿一條褲子，他說開發品質隻能等投産後才知道，請問是否合理？
- 産品經理和開發經理就“清單接口是否傳回資料詳情”而争論不止，請問如何定奪？
- 程式員在發射火箭接口直接return了“成功”，直到上線才被發現，請問責任在誰？
- ……
此時，小姑娘虔誠地點上香，口念咒語。不一會兒，金光閃現，管理學大師再次出現。
“大師！”，小姑娘連忙喊道：“大師，清單接口能否傳回資料詳情呢？請大師指點迷津”。
大師很生氣：“你不要問我具體的問題，你要記得時刻充滿正能量，并把這份正能量傳遞給每一個人。隻要做到這些，一切的問題就迎刃而解了”。
說罷，大師再次“啾啾啾啾”，消失了。留下小姑娘一個人撕着頭發陷入了沉思之中。
第三集：老闆的力量
小姑娘很消沉，把員工抱團偷懶的情況告訴了老闆，老闆很生氣，召集各個部門開會：項目上不了線，大家一起扣工資，保安也一樣！
各個部門立馬緊張了起來，放下成見，各司其職，主動推進，互相妥協，很快項目勉強上線了。
第四集：問題出在哪兒（上）
上線後，項目運作不是很穩定。
小姑娘經常接到回報：上傳功能出問題了！
作為項目的頭兒，小姑娘對有什麼功能絕對是了解的，但是為什麼出問題，她卻不知道。
她首先質問測試：你們怎麼測的？這麼嚴重的問題居然沒有測出來！
測試吓了一跳，先是看了看上線的checklist，然後又自己親自驗證了一遍，然後很有底氣地說：不是我們的問題的，上線那天是好的。
小姑娘碰了一頭灰：那為什麼現在不行了？！
測試說：那你問開發啊，是不是他們偷偷改什麼東西了。
小姑娘找到開發：你們怎麼開發的？這個功能出問題了！
開發的内心一點波瀾都沒有：聯網了沒有？浏覽器開相容模式了沒有？上傳格式對不對？
小姑娘驗證過好多次了：一切操作都沒有問題。
開發依然很淡定：雖然這個按鈕是我寫的，但我是調用的後端接口，他給啥我顯示啥，你找後端去吧。
小姑娘找到後端開發人員，又把剛才的話重複了一遍。
後端先是一愣，呆在那裡好久，表情凝重，然後豁然開朗：你這個不對吧，産品需求裡沒有這種場景的，我們不支援這種場景。
第五集：問題出在哪兒（下）
- 小姑娘說：但是使用者都是這麼用的呀！
- 後端說：那你找産品吧，讓他們改規則。
- 小姑娘找到産品，把問題又重複了一遍。
- 産品說：客戶給的需求就是這樣的，評審的時候，你也在場。
- 小姑娘說：但是現在有這種場景了，得加上！
- 産品說：那讓開發加上吧。
- 開發說：你得給個規則。
- 産品說：規則就是加上這種場景。
- 小姑娘說：要多長時間？
- 開發說：有了需求才能評估。
- 産品說：不用需求。
- 開發說：你原型不加一個說明嗎？
- 小姑娘：是呀，得說明一下吧!
- 産品說：你已經知道怎麼做了，改了不就行。
- 小姑娘說：是呀，趕緊改了吧。
開發和産品一起憤怒地看向小姑娘。
小姑娘一言不發：你們到底想怎樣，有沒有大局觀？！我要報告老闆！
第六集：老闆再次出山
老闆：趕緊修複，否則扣工資。
頃刻之間，問題就修複好了。
小姑娘内心暗想：你看，他們是可以做到的，就是故意刁難我。
總結
不知各位掘友看到上面的故事作何感想。
反正我有一點是可以确定啊，就上面的情況，就算再來幾十個項目，都是可以開發的，也可以上線，公司也可以運轉多年，這也是多數中小企業的現狀，并沒有你預想的那樣恐怖。
同時，還有幾個觀點我想說明一下：
1、為什麼老闆一出面就可以解決問題，小姑娘卻不行？
上面的故事中，因為小姑娘的專業性不強，協調不動各方，導緻老闆兩次出面解決了問題。
但是，老闆并沒有針對問題進行剖析，而是我不管你們怎麼樣處理，我隻要結果，不然大家都扣工資。
協調本是小姑娘的工作，是因為她做不好，導緻大家工作不流暢，沖突點在她身上，大家心裡不平衡，各自堅持不妥協，想倒逼她改善方式。但是，老闆直接放出狠話，各方出于求生欲，放下堅持，自主協調完成了工作。
從這裡看出，一方面小姑娘的作用不大，因為有她沒她效率都沒有顯著變化。另一方面，小姑娘的權利也不是很大，如果有老闆那樣的權利，就不用老闆出面了。但是，如果處理一件小事就動用老闆權利，那麼這種權利慢慢地就會泛濫，讓大家不再重視。
是以，還得是小姑娘能處理好工作，保證大家工作有序開展，這樣才能對于公司的業務發展、同僚工作的舒适度、老闆作為原子彈出場的次數，以及小姑娘在團隊中的威信等，都是有利的。
2、誰更貼近一線，誰更接近真理！
小姑娘從管理學大師那裡不斷擷取管理秘訣，應用于項目管理，認為這樣是可以成功。
管理學或者成功學，都是一門學科。并非說這些學科無用，隻是它隻限于應用于某一個層面。
比如從提高人們的積極性上來說，成功學就很有效，隻需要聽3分鐘演講，咔咔咔，精神振奮，無腿青年都想去爬珠峰。從精神層面，可以使用成功學來催人奮進。
但是，到具體的操作層面，因為成功學大師他沒有帶過IT項目，但他又想發言，是以就開始忽悠了：“我告訴你，如何解決你的困惑。首先分析問題，然後解決問題，最後總結問題”。他說的有錯嗎？沒有錯，而且極其對，就像人要呼吸一樣。有用嗎？沒有用。
真正能帶好項目的人，肯定是親身經曆過項目的人，絕不是紙上談兵的人。就跟蓋房子一樣，建造師、瓦匠、水電工、采購等各種崗位多少都接觸過，了解起碼的工作流程和标準。最好能了解各自對接的痛點，比如由于UI提供的設計稿沒有考慮适配，導緻上線後不同裝置出現效果錯位的現象，這是提高效率的地方，也是你起作用的地方。這在哪個行業都一樣，隻是在軟體行業這個情況更加明顯。
不是産研出身的同學，并非沒有優勢。隻要願意傾聽，願意思考，可能比業内人更容易從特殊角度獲得靈感。條件是貼近一線，并不是非得從事一線。
從來都是解決問題才能促進發展，掩蓋問題隻會限制發展。而貼近一線，是發現和分析問題的基礎。
3、都會遇到哪些問題，該怎麼解決？
我們先看小姑娘遇到了哪些問題。
- “程式員幹沒幹完我都沒法判斷”，這是進度的問題。
- “開發品質隻能等投産後才知道”，這是品質的問題。
- “開發經理和産品經理因為接口傳回格式引起争論”，這是産品設計與技術實作的問題。
- “新增一個場景，要不要寫到原型說明上”，這是項目流程的問題。
有人說，開發的事情由開發經理來幹就行，你去壓他，讓他去控進度抓品質。
當然這是理想的情況，我們都願意這樣。但是，實際上尤其在中小企業有些角色本身就配置不全，就沒有開發經理，隻有幾個後端和前端。有的雖然存在角色，但是無法勝任。你要等換了人再開展項目嗎？不可能的。
另外，軟體項目是一個需要多方精心設計和配合的工程，就算都按照标準出産物，你是5毫米的螺絲釘，我是5毫米的螺絲帽，最後可能也無法收獲滿意的結果，因為客戶是3毫米的孔。是以，想靠自驅力，靠意識，靠玄學來完成項目，本身就很懸。
最後，最重要的就是責任了。
前面說了一個小例子：“有個程式員在發射火箭接口直接return了成功，直到上線才被發現”。這件事就相當于客戶讓你建一個發射場，你做了一個按鈕，一按放出段語音：發射成功。但是火箭根本沒動，這純屬糊弄。
那麼，這是誰的責任？
是那個程式員糊弄事情的責任嗎？他的上司是怎麼跟他安排任務的，是說做個demo還是要真的發射，後續有沒有跟進，測試是怎麼測試的，相關人有沒有做過抽查？
這是誰的責任？企業肯定不會把程式員推出來的，說是這個臨時工的鍋，你們都去譴責他吧。從企業和客戶之間，這肯定是項目管理者的責任。降幾個層面，到自己家裡關上門，才談産品、開發和測試怎麼分鍋。
是以，出于這個目的，項目管理者對于所有的事情就都要了解，而且要管理。