工作被夾在中間，項目不能儘快推動，怎麼辦？

01-21

背景：畢業近一年，目前就職某互聯網公司，產品運營。最近有個項目，要儘快上線，由於人手不夠，我需要扮演類似項目經理的角色，要和開發團隊溝通、催進度。
困擾：我的直接領導很強勢，希望這個項目儘快上線。而開發團隊也在做，但是就目前的進度不可能儘快完成。而boss催得又緊，我又不能每天都去開發那邊催催催，感覺被夾在中間，我也很著急也希望儘快項目上線，可是我自己的項目管理經驗很少很少，感覺非常有挫敗感。請教此方面有經驗的前輩，如果您遇到類似情況怎麼處理才最好？

找出開發團隊的leader（如果沒有需要找開發團隊部門負責人指定leader），告訴他項目的上線目標，請他制定執行計劃，並每周更新進度，把執行計劃和進度反饋發送給你領導，抄送給你。

你只是一個溝通人員，無管轄權；你直接去管理（崔進度）人家鳥你是出於禮貌。

我的直接領導很強勢，希望這個項目儘快上線。而開發團隊也在做，但是就目前的進度不可能儘快完成。而boss催得又緊，我又不能每天都去開發那邊催催催，感覺被夾在中間，我也很著急也希望儘快項目上線，可是我自己的項目管理經驗很少很少，感覺非常有挫敗感。

常見現象，不用著急。

首先，光催沒用的，你要找到團隊真正的問題和瓶頸所在，然後再施以正確的辦法應對。團隊開發之所以慢、趕不上進度，有許多方面的原因，如開發流程不合理，管理不到位，員工開發技能、技術不行，工具不好用等等。所以，第一步是現狀分析。

第二步是爭取獲得足夠的許可權和影響力。領導委任你做PM，要實現領導的目標，首先要看你是否拿到了足夠的許可權，在開發團隊中是否有足夠的影響力（威信），大家是否願意聽你的？如果沒有或缺少影響力，那麼你應該更多做一個觀察者、建議者、促進者的角色。開發團隊中的核心角色通常是一位主架構師，你應該多與他溝通，建立起良好的關係，協助他、通過他來帶領、影響乃至改變整個團隊的行為。

關於進度，應該首先分析為什麼在指定的時間內完成不了，日常開發中存在哪些管理和工程技術的上的問題，低效、浪費的地方，能否改進？

如果現有的需求實在完成不了，那麼應該研究如何調整這次發布的需求任務集，對工作量、任務做一些刪減和變通，看看如何在規定時間（fixed time）內滿足領導的要求？這是一項技術活，需要進行細緻的需求分析與發布計劃，需要產品經理、需求分析師、架構師、技術骨幹等人的配合。

你現在的這種狀態其實很難解決。主要是項目管理流程，團隊協作方面的問題。但估計你的權力和資源又無法改變現狀。

參考下我之前的回答

如何有效的在一個研發團隊中推行Scrum？ - 王春生的回答

謝邀。

題主沒有什麼項目管理經驗也沒有什麼關係，我來告訴你一個最佳項目管理方法-讓項目各節點可視化，推薦使用看板方法來管理你的項目。

詳情請見infoq這篇文章：

解析精益產品開發（一）—— 看板開發方法

看板方法，起源於日本，曾經是豐田生產方式的重要工具，後來被david anderson引入軟體行業。

目前國內互聯網行業很多採用scrum方法管理項目，但題主不是專業人員（可能也不需要成為項目管理專業人員，特別苦真的），實施scrum方法略有些難度，建議從敏捷方法里最好入手的看板開始。

看板方法的最簡單實施步驟：

定義每一個流程狀態，比如需求，待開發，開發中，開發完成，測試中，測試完成，等待上線等狀態。
每一個任務作為一個卡片貼到看板上；
限制每個主要狀態的同時並行數量（比如開發中，限制5張卡片同時進行）；
每天同步看板，召集團隊回顧昨天的工作狀態（開發中，已完成，遇見的問題），15分鐘以內；
持續更新卡片和看板。

如果有條件，可以使用實體看板。如果不方便，可以使用工具，比如trello, worktile, teambition,tower等。

「加人or砍需求」，但談判是需要理由的，所以首先要探索領導的需求，上線時間是否真的無法調整，其次明確開發實際情況，是能力不足效率低還是挑戰大任務量重；最後如果時間無法調整，開發也無法按時交付，那就向上級申請資源加人；如果不加人那就只能砍需求。

我不相信你們不做甘特圖，不進行項目開發估期。如果都有，那麼開發時間不夠，要麼是開發的問題，要麼是方案修改。那麼問題源頭都是能找到的。

如果還是想要保證最後發布時間穩定，直接從甘特圖裡找一些功能直接砍。

上面也有朋友從很宏觀到方面去講解了。

個人覺得你做的做好兩樣就好了：

1、理清楚需求

2、壓力傳導

這兩點再總結為一點為共識

第一個：理清楚需求：

a、要達成目標，需要完成哪些功能模塊，這些功能模塊之間的依賴關係。

b、這些模塊依賴的資源。

這個過程不是你來劃定，應該是與對應研發同事一塊梳理，有了結論就可以了。

這樣就目標方面達成共識。

第二個：壓力傳導

boss要求能夠儘快上線，你再單獨催促研發，研發直接頂回來你又頂不回去，當然成了受氣筒。

約上成員或模塊負責人，和領導一塊溝通（你們三方必須坐到一塊）

領導提出整體的時間，研發應答到底能夠什麼時候完成，要包含近測試時間。

這個過程是博弈的過程，你可以對功能或需求進行切分，砍掉一些，以滿足時間。或者讓領導決定加人或減需求。

切記一點，會上必須由研發承諾時間，領導承諾需求範圍。最後你梳理一下決議。

三方達成共識。

後續你就按照時間去跟蹤，如果時間較長，中期再拉著三方討論進度。

領導如果有實際進度有異議，他也參會了，他就會記得研發的承諾。你就不是夾板了。

其實從正規的項目管理角度去分析：

1、理清楚項目範圍

2、做好時間管理（活動定義，排序，時間估算，資源估算）

3、溝通管理

先把項目情況理一下，項目原計劃是怎樣的，現在執行情況怎樣，哪些任務沒有按期達成，原因在哪兒，給出幾個解決方案讓領導拍板。方案也簡單

1如果任務沒人對應，就加人。

2對應人的能力不夠就換人。

3變更太多太頻繁，就加強需求評審，沒評審過的變更一律不改。

4時間不夠就延期，不能延期就砍功能。

5項目干係人沒有配合到位，就請領導協調。

現在這種情況，再學什麼項目管理方法都幫不到你了。

像碰到這種情況，唯一能做的就是砍需求，砍砍砍，特別是那些耗時長的非核心功能，第一版本只做那些只要完成了就可以發布alpha版本的功能，這樣對上可以有交代，對開發團隊也會更加明確目標和工作量。