1樓：大熊圓滾滾
很多人都說這個問題難，那是因為如果你要站在問題裡面看問題。不能跳出來，那當然是難題，乙個本來就不關心專案進度，或者是在這個專案裡，關心進度對與這個員工沒有真正的正向反饋的時候，他為什麼來跟你主動報告呢？
當然很難沒有可能了！
那我們現在該做的是什麼？
先把工作激勵，專案激烈，員工生涯規劃做好！
不要畫餅，而是實實在在的。
能力成長了，
近期收益可以是漲工資，學到了技術和經驗
遠期收益看加薪，晉公升，管理層。
如果這些公司都沒有，那整個公司成長性都不高了還談什麼團結協作，共同奮鬥呢。
把上面的激勵做好。願意成為主人公的員工，自然會站出來。
因為他會獲得更多的薪資，更高的職位，也能學地更多的技術。
很多時候說我招來的人野心不夠，都是老油條。
我想說其實，只不過是激勵還沒到位罷了。
2樓：Andy
最重要的就是統計專案規模，快速IFPUG快速功能點對專案規模進行估算。
前端，客戶端程式都是可以進行規模的估算的。
估算專案規模已經是國家標準了。以後在大學課堂上會教的越來越多。
3樓：忽悠忽悠大忽悠
兄弟，我叫你一聲大哥
說句真的，這要求，難
你不能指望員工都能這麼自覺的關心整體進度，能操心別的成員和自己相關業務就已經很不錯了
員工都是餬口養家的，高效幹完自己的活賺了這份錢就完了
4樓：李小沫
1.由將進度的展現由"拉模式" 改為"推模式"。 2.增加整體進度展現頻率，不斷在日常工作中重複出現。自然但不要刻意。 3.讓進度與個人利益掛鉤 4.激勵
5樓：黃勇
人總是趨利避害的，任何的管理方式想要扭曲人的自然屬性都會受到無數的反抗而無法持續。他們為什麼不關心整體的進度？因為他們沒有作為乙個團隊和整體的進度繫結在一起，並進行考評。
他們被作為個人進行責任劃分。他們只需要對自己的工作而非全域性負責。任務劃分的顆粒度是不是太高，以致形成了任務之間的壁壘；是不是沒有打造全功能的團員，團員有了明顯的title，資料庫王，介面陳，測試李……；有沒有充分實施結對與交換，讓人員在團隊內充分工作；團隊的整體進度有沒有透明化？
敏捷專案管理，最佳團隊人數是多少人？
敏捷開發 但是人數並不是乙個死規定。具體可以按照自己的團隊實際情況來進行調整。像LeSS框架，就是將Scrum框架放大，並應用於多團隊管理層級中。LeSS保留了很多Scrum 中的基本要素，例如 每日站會 產品待辦列表 Sprint計畫會議 Sprint評審會議 回顧會議等。但在Scrum框架的基礎...
在敏捷開發中，如何預估團隊的開發速度？
金三 其他答案中介紹的撲克發啊估算法啊，都是在衝刺初期對任務工時的估算，進而和time box做匹配的過程。這不是估算速度，這叫迭代排期。估算速度的目標在於評估團隊的交付能力，並提高交付能力。估算的權威資料是在單位時間內，如乙個迭代可以交付的增量的規模，這個資料才是有意義的開發速度。難點也在這裡，增...
如何管理團隊中的「老油條」？
許多歌兒 老油條之所以是老油條，是因為經歷的比較多，經驗足。但有長處，必有不足。他的不足是你能幫他的地方。團隊中的老油條也需要你的幫助。 教育家大學 但凡是成熟的培訓機構，都會存在一批 老油條 的員工，校長們對於這些老教師的管理非常頭疼，既說不得 罰不得，又不能直接開除。全文共計，建議閱讀時間5分鐘...