【項目實施前】
1、需求分析：和客戶及需求方充分溝通以真正的明確客戶的需求。
2、根據確定的需求制定可實施性方案文檔、標書及實施設計、架構圖、邏輯圖等。
3、同等層次，儘量實施方案設計的前瞻一些（例如滿足1-2年內的需求。）
4、確定物理設備需求及人員等資源的配合。
5、根據實施方案文檔進行人員分工，並明確責任和義務方，以免實施中、實施後扯皮，特別是多家公司合作的時候。
6、確定實施週期。這裏的弓不要拉的太滿，否則，物極必反。特別是內部運維項目，我們自己可以制定項目週期的時候，就不要急於立功表現自己，而最後反而做不好。
例如：老男孩的上一期架構師培訓班有兩個學生，給公司部署ldap（多種業務ftp,http（cacti,bug sys）,samba,***,postfix）主從加高可用等的統一認證的方案，還有drbd+mysql/nfs/mfs+ha雙主多從高可用及負載均衡的業務。竟然和老大說半天就搞定，雖然真的可以搞定，但是也儘量別這樣說，這麼複雜的技術你1-2個小時就說搞定，以後總有你花一天還搞不定的簡單的問題（可能是老男孩沒講過的新技術，但是老大覺得你10分鐘就能），因爲之前老大對你的能力預期上去了，你做的達到基本標準也可能會被認爲，能力不行了，讓別人預期不是太高，最後提交成績時，可以給老大驚喜，這兩種效果對領導的感覺是完全不同的。。
關鍵：
a.準備完成後，要給大佬及客戶需求方講解或彙報文檔實施的方案策略，讓客戶及大佬心裏有數，不要跑偏了，一致通過後再開工。
b.還有，方案中的內容自己也要有數，不要設計超出你本人及你身邊可用資源或用資金都無法獲取的方案，只爲一時的滿足客戶。
c.如果可以，請需求方在實施方案文檔上簽字，或者有郵件明確回覆爲好，以免按照實施文檔實施的結果不符合需求方的預期，造成糾紛。人的經歷職業不同，對同樣的文字理解也不同。
【項目實施中】
1）一定要根據實施準備的方案進行施工。
2）實施中，不可避免的要遇到棘手問題，此時，不要私自輕易變換方案，如果需要變換要徵得客戶和大佬同意。
3）讓所有實施過程都有記錄可查。儘量不趕工，如果客戶逼得急，最好增加人手和工作時間。
4）如果確實人手、時間、資源都不夠用，那隻能先滿足客戶利益，犧牲一些對客戶看來無關緊要的，例如：實施的規範和操作記錄等。
5）儘可能在關鍵節點請需求方確認，以免最終結果不是需求方想要的，做好每一步就不怕結果不符合要求了。
6）及時總結項目中的問題，亡羊補牢。可以每天，每兩天做一次總結，坐一起開會討論下大家遇到的問題及解決經驗，後續問題的解決計劃。
關鍵：項目組領導，要安排核心人員親歷督促並驗收每項（查看總結報告及現場查看），領導切記不能春種後，就等着秋收的想法，否則結果一定會走板，項目實施中也要有人澆水施肥的，認真呵護項目的成長的。
【項目實施後】
1）項目組內部自我驗收，例如測試人員，也包括各種壓力測試，黑白盒測試。
2）請客戶及大佬驗收，現場或通過開會及總結書（驗收報告）的形式，小項目可以發郵件。
如果是內部項目，可以寫一些實施中的心得體會，經驗型的技巧等。分享經驗很重要。
除了讓人驗收外，更重要的是有了成果要讓大佬知道，否則，一切的工作都是徒勞的。
以前就有老男孩的羣裏網友問我，工作很努力，但是，薪水就是不給加，我該怎麼辦？
這就是會做也要會表現，好鋼用刀刃上。有關表現的話題以後有機會在和大家分享。
3）實施的結果和實施文檔圖紙有偏差很正常，需求方對實施文檔的理解也可能有偏差，所以，無論多麼努力
都未必能完全滿足需求方，認識到這個事實後，就好辦了。
4）在各種條件允許的情況下，可以根據客戶的提出的新老問題修正實施結果，前面的實施前、實施中的簽字或郵件確認就很重要了。
如果有需求方的一步步確認，結果出來了，不是他心裏想要的，我們也有證據。不至於太被動。有些項目經理這方面就做的不太好。
關鍵：老男孩常和學生講，戰爭的勝負不在戰場上的瞬間，而是戰爭前的充分準備階段就決定了！所以，項目前期準備不充分時，再項目驗收時就被動多了，功勞變成了苦勞或徒勞，這就是爲什麼老大不給你加薪的原因，甚至表揚都是很簡單表面化的敷衍而過。
【小結】
今天老男孩說的這些項目管理的經驗了。。。是一個非常大的門類。。。，我僅盡我所能分享一些老男孩在做運維時做項目，以及現在開辦的外包公司對外服務外包的一點經驗，供兄弟們參考。
老男孩的其他想法：如果是練技術，儘量還是找網站類的運維工作好一些，如果是做項目實施類工作，那麼我們的定位就不能僅僅是技術了。整個項目週期中的客戶溝通、實施人員協調、設備供應、實施中的多方溝通，確認、回報、跟蹤進度等等都是比技術還重要的知識和經驗，希望兄弟們把眼光放遠一些，畢竟，我們不能總做底層的運維屌絲吧！