誤區
之前我沒有項目經驗，在上一家公司的項目管理上，我只是照葫蘆畫瓢。
-
產品發起，整個項目沒有項目經理這一說。或者說有，但卻真的感受不到，一丁點也感受不到。
-
產品發起會議，或者開發發起會議。無論誰來發起會議，一般都會針對於某一具體需求或者某一具體實現方式。
-
沒有具體的任務規劃，任務拆得不夠細緻。這個和開發自身有關係。當然那時的公司確實沒有一些指導性質的模板和導師。
-
任務分得不夠細緻，就會導致工期評估差距比較大。
-
各種O們的臨時緊急需求，很多O沒有技術背景和項目管理背景。很多時候提出的需求都是發生在項目開始過程中。
都是很急的需求，不得不重新估算時間和排期。開發為了避免延期風險，就是讓產品排優先級，然後我們根據優先級估時。
直到有必要的需求都在這個迭代中計劃上。
-
沒人全局把控，產品從產品角度，開發從開發角度，業務從業務角度。始終沒有一個最終的協調人。
產品在對各種O的對話中，氣場和身份不足，導致需求基本是提出就會安排。即便是請出青島總負責人出面溝通，最終的結果一般就是接受。
-
之前我們是青島為開發，北京為產品、UI、前端、測試。異地溝通。電話會議是常有的事情，私下的臨時溝通電話更是家常便飯。
信息同步、開會、理解程度 都會造成溝通上的成本增加。
-
緊急需求上線后，三個月沒人反饋。問了才知道，財務提的需求他們沒用過。
-
開會一般都會臨時決定，發起人會準備資料，但是其他人提前看資料準備問題的情況極少。導致會議冗長效率低。
解決
現在來看，無論如何，我們在知道這些問題，但是為什麼不去處理呢？應該還是習慣了，即便是整個項目非常掙扎，依然是按老規矩走。大家都是困在了這個圍牆中。
我現在也有了一年的項目管理經驗，初入門道。只是對自己的過往進行一下分析解決。
以上的誤區和問題，我覺得需要一個有經驗並且有點能力的人來帶領這個項目團隊。
1. 確認項目經理
但是按照我上家公司的情況，一般會立經驗豐富的主管直接管理這個項目。
當時的情況是，項目主管在項目上的精力完全不夠，甚至說項目管理在項目主管心中的優先級比較低。
根本原因，青島作為研發中心，技術基因強大。很多技術管理人員，沒有意識到項目管理的重要性。
組織架構主要是垂直單線架構，技術-主管-經理-總監-CTO。無非是自己下面的人多，按照業務或者大項目分了組而已。
如果讓開發作為項目經理，
首先這個開發是否願意承擔項目經理職責？
是否真的能夠賦給項目經理一些實權？
是否有鼓勵機制，比如晉陞優先或者獎金等？
建議：
加強項目管理意識；
加強項目管理能力；
必要的話可以作為量化指標來看；
加入一些激勵機制；
2. 培養主動性
因為技術基因影響。主管或者經理出於“好心”考慮。
他可能會考慮到，如果把項目管理中的某些事情分配給組員，會不會引起反感？會不會影響在組員中的美好形象？
也算是確實分下來一些，比如項目規劃和估時以及排期。但是我沒經驗的，是不是可以稍微引導一下？
領導總想為老好人，但是這樣自己手頭的任務分不下去。
下面的人也得不到成長。
建議
對組員有一定的規劃和成長要求，而不是放任其隨意生長（有一定風險）
領導應該提高自身的管理能力，管理技巧。而不是憑經驗論。
定時關切Review分下去的任務，從結果或者過程提出建議和優化。
3. 確認好需求邊界
產品經理和負責人，確認好需求邊界。飄忽不定的需求給項目的打擊是很大的。
開發在搖搖墜墜中估時，此時的估時肯定會有大量的冗餘，因為之前需求的變動，上線時間一改再改。
在加上，主管、經理偶爾砍幾刀。所以開發在估工時都會冗餘很多。為了被砍，為了需求不定。
建議：
確認好需求，可將項目周期縮短，小版本迭代。
強化項目上線時間約定，鍥約精神。不僅僅是開發要遵守。其他人員最好也能嚴格遵守。（當初這個做起來真的比較困難）
信心是做出來的，幾次項目的延期和需求的變更會嚴重打擊大家的信心和士氣。所以按時上線很重要。
規劃得有，但是是不是可以考刪掉遠在4個月以後的需求。
4. 緊急需求
比如財務的一些緊急需求，其實確實緊急，但是使用頻率很低。
是不是可以有另一種解決方案？不一定非要按照財務提出的那種設想。
我們達到並滿足了他們的目標，後期再去做頁面更加直觀。
比如要一個訂單查看頁面。那我使用程序定時拉取新訂單推送到企業微信或者釘釘。結果也是非常滿意的。
不一定非要做一個頁面，很多時候做成一個頁面，大家會發揮自己的產品意識，增加一些不必要的按鈕、功能和邏輯。
建議
深入了解需求，而不僅僅是一句話，也不是根據用戶提出的需求來做，用戶到底想要什麼？--他就想要有訂單能及時知道。
緊急需求是否真緊急，也得看使用頻率。使用頻率低，是否有其他方式實現。
能擱置的暫且擱置一下，之前就我一個人開發，很多原本緊急的需求因為開發不夠，擱置了也就擱置了。然後甚至有的都自己消失了。
5. 高效開會
會議開始前，大家幾乎么有預習的習慣，會上很多時候沒有主持人，大家就問題會討論很深，導致時間不可控。
有的會能一個電話解決的就沒必要拉這個拉那個來開會。這種儀式感不重要，開會也不是拉家常。
為了讓領導知道這次會議的重要性，這個項目的重要性。拉着領導一起開：
但是領導的事情多，很多時候在會上他們是一直回複信息，其實當時是比較尷尬的，領導不能專心處理問題。我們看着領導沒用心聽，不了解的同事還以為領導漠不關心呢。
建議：
發起人拉群，提前@人提醒大家關注和看會議內容。
發起人做會議：主題、流程、最終結論
確認會議主持人，隨時控制會議進度。有些細節會後溝通。
領導可以不必參加需求討論會，把會上討論的疑難問題，會後單獨和領導會報，再拉一個小會議電話溝通確認即可。
重要項目啟動會、項目上線等會議盡量簡短，領導全身心參加。保證大家的鬥志，統一思想達成一致。有些形式必須要有的。
6. 相關方
開發與客戶溝通少，因為兩地溝通，基本是產品作為翻譯官將業務轉成需求轉達給開發。
開發沒有感知用戶的存在。
建議
多聽聽用戶怎麼說。
大家達成一致，每月電話會議或者視頻會議溝通一次。會議可以控制在1小時以內，氛圍可以輕鬆，主要是收集需求以及反饋問題。
如果有多個業務部門都是相關方，那麼主要思想就是設置定期溝通（規律的定期溝通）
7. 轉變
優勝劣汰的企業付薪給我們，我們就要服務於這個企業用戶。甚至說服務好用戶。
我們開發也要主動從自身求變。好好說話，真心替我們的用戶思考過問題。
從產品和業務角度認可業務優先級，而不是緊緊盯着開發重構、新技術的應用。
建議
轉變意識：我想為你們服務；
我能力不行，但是我能主動學習項目管理知識和經驗，並在項目中實踐，反思，再實踐。
我要為我開發的產品負責，它的迭代，扔給它的需求，和它相關方，它的應變能力。
主動一點，也許事情看起來並沒有那麼難。
現在的我，我們
新的公司，給了我很多的機會，糾正了我很多認知，我也從實踐中反思了很多，收穫了很多。
公司的組織架構是矩形架構：橫向職能，垂直項目
項目首先會有項目經理，項目經理有一定的項目經理獎金。當然項目經理要履行項目經理的職責。都會有績效。
項目經理，開發，產品，測試，DBA，運維，PMO 這些會組成一個項目組。
整個項目組會在項目經理的引導下，開發項目直到上線。然後迭代下一版本。
現在項目中，有使用瀑布開發，有使用敏捷開發。
我所認知的一點是，各個職能團隊人員雖然屬於職能。但是基本會長期泡在各個項目中。
項目中學習到的東西，在項目中的成長也是很重要的。所以項目經理有一定的敏捷角色中PM的角色：引導大家，賦能給大家。
我們正在嘗試的敏捷（嘗試）
其他團隊物理面板：
我們團隊的面板：非常簡單
項目并行和項目特殊性，我們採用周交付，不確定哪一天交付什麼（特殊需求除外）。
因為項目為運維性質的項目，有開發，緊急需求，客戶答疑問題較多。時間不太可控。
並且大家积極性都很高，沒必要要求必須排滿周開發任務。
自己開發完直接到需求池，領取最優先級的需求，或者幫助其他組員分解開發任務。
業務需求 + 技術需求 雙向需求驅動，佔比5：1。
周最高優先級佔比 1：4
這樣大家不會因為具體時間的衝突導致交付的壓力。周交付的任務為必須交付的最小單元（本周必須交付）。
沒必要的會議去掉，我們基本都坐在一起，不去會議室。工位周邊就可以開會。電腦操作隨時記錄，會後發出來。
周五：計劃會（15：00 ~ 15：30）
10分鐘，材料都是平時積累，會前整理完
地點：工位
目的：回顧上版本迭代精進結果。分析過程問題原因，總結問題。認知好與不足，下版本迭代重點要解決的問題。；討論新需求優先級；達成一致周最小目標。
周五會後 + 周一開會前
這段時間，是大家緩一緩，總結自己規劃下周的時間。
磨刀不誤砍柴工，想好怎麼做，才能預知困難和風險。
對新需求進行任務拆分，需求理解，任務具體估時。
周一：迭代會（10:00 ~ 10:15）
15~30分鐘，微調任務；統一思想；確認周迭代目標；
地點：工位
周三：如果需要可以開一個簡短溝通會
我們自己維護的計劃和交付，簡單高效。團隊協作，互相可看。
我們的產品是剛畢業的新人，我們互相指導學習。
他最近也在研究用戶故事如何寫好。他打算下周先打印出來，大家看看自己感受一下。
最近我看完了一本敏捷開發相關的書籍，同時推薦給了他。我們想單獨摘出好的或者值得討論的地方，大家圍在一起拿出半小時討論一下也未嘗不可。
還有一本我正在看，可能我實踐經驗不足。總是感覺一般般的感覺。思路不是很清晰。
有讀過的朋友可以發表一下看法。
總結
敏捷我們在路上。不為敏捷而敏捷。
我們互相提高，互相幫助，能力提升，升職加薪。生活質量更好。
大街上敏捷一大堆，根據實際情況摸索敏捷之道。發揮大家的能力，提升大家的能力。為大家帶來點實際的東西。為企業帶來點實際的東西。
項目管理根本目標是把項目管好，項目管好，大家更加自信，互相也都信任。所以項目管好是項目組良性循環的根本。項目經理要多花大力氣去關注，去學習。
謝謝關注公眾號
本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理【其他文章推薦】
※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!!
※網頁設計一頭霧水??該從何著手呢? 找到專業技術的網頁設計公司，幫您輕鬆架站!
※想知道最厲害的台北網頁設計公司推薦、台中網頁設計公司推薦專業設計師”嚨底家”!!
南都電源表示，孔輝汽車主營汽車電子控制系統研製與銷售、汽車整車及部件的試驗測試等業務。此次增資會增強公司在新能源汽車系統集成領域的能力，從而為公司向新能源汽車產業鏈的發展奠定相關的基礎。 文章來源：全景網
今年3月底，斑馬快跑互聯網+新能源綠色通行大巴項目從武漢啟動，切入了巴士出行的蛋糕。李佳說，斑馬巴士免費運營3個月以後，斑馬紋已經給當地社會帶來了品牌效應，並且上座率也實現了98%，新的盈利點破局。據悉，本月斑馬快跑即將上線第一批七座乘用車並將在年底鋪開。 關於以後發展方向，斑馬快跑希望能做最大的新能源車輛運營商，打造車、樁、網的“斑馬雲”，做成武漢這座城市的互聯網名片。日前，定制物流車型“東風斑馬”已由工信部《道路機動車輛生產企業及產品公告》車輛新產品公示發佈，斑馬快跑迎來又一個里程碑，讓車輛從一出廠即將帶有斑馬紋。 文章來源：CNEV-H
據工信部資料統計，自2009以來，中國新能源汽車安全事故共31例，其中2015年以來發生17起，在這17起事故中有4起是電池系統的事故、有6起是相關部件的事故、有2起是充電系統缺陷引起的，當然還有5起是違規改裝或者不當使用引起的。截至2015年底，事故率達到0.17‰，高出世界平均水準。 工業和資訊化部裝備工業司司長李東表示：「國家已經組織制定了電動汽車遠端監控標準，並且電動客車安全條件即將發佈實施。電池管理系統技術條件、動力電池的編碼、規格尺寸等標準正在編制、修訂，並且也要儘快出臺。與此同時，正在組織修訂新能源汽車生產企業和產品准入規則，擬大幅度提高企業的研發能力和生產條件要求，提高性能和安全的要求。」 文章來源：證券時報
