時間管理與項目計划 -开发者知识库

時間管理與項目計划 -开发者知识库,第1张

正文

隱藏風險的識別

大多數情況下,后期的各種問題的主要來源就在於前期對於隱藏風險識別度不夠。導致很多原本可以早期就進行方案修正或者是實現改變的問題,到后期才發現導致大換血或者是問題頻發。

Task 前置

如果遇到第三方(不可抗力)的影響,可以先將后期的 Task 能夠現在完成的前置,而不是等待不可抗力的自我修復(此時無所事事),這樣會導致一旦第三方修復,我們的 Task 會突然暴增,這樣神都救不了。

問題拋出講技巧

對於問題要及時拋出,並且進行問題處理的過程跟蹤,結果跟蹤,在拋出問題的時候千萬不要只拋出問題,要附帶自己認為可行的解決方案,讓接受問題的人來選擇。
這樣做事一種雙贏,
一,問題的接受者不需要去思考問題的解決方案,只是簡單的做個選擇(這樣可以大大的增加問題拋出后得到及時反饋以及解決的幾率)
二,我們自己來決定的解決方案會對我們的實現更加有利,畢竟是我們考慮了實現方面所想出來的解決方案。

溝通的集中性,文檔性

對於溝通,是個老生常談的問題了,除非我們都是獨立開發,否則項目中不可避免的就會出現溝通這個詞,我們不需要做那種零散的溝通,你告訴我,我再轉告他,他又轉告他。信息在傳遞的過程中,是很難保證不變的,很多時候到了最后的接收者那里問題早就被改變意思了,而且這中的溝通過程太過於冗長,所以先把問題整理起來,然后直接團隊一起一個 call ,或者是一次小型會議就解決掉所有的問題。然后溝通的結果一定要體現到文檔上,白紙黑字的記錄下來,以后大家就根據文檔辦事情,不要憑借着自己的記憶來辦事情(好記性不如爛筆頭)。

多 Task 並行處理

一般來說到了項目后期,Task 是比較重的,經常是多 Task 並行的狀態,解決這個問題,就需要從四象限原則出發,對當天的 Task 做一個分類,先輕重,后緩急,然后再根據這個分出來的四象限來開始今天的工作,如果你是管理人員那么你在這里還可以進行任務的再分配,確定哪些是你做的,哪些是你可以分給團隊其他人員完成的,還有那些是屬於兄弟團隊的事情,並且進行相對應的轉移以及 Task 的跟蹤。

需求挖掘

很多問題后期才會體現有很多也來自於需求挖掘不夠,導致后面的工作,諸如測試用例,開發方向,實現方向,測試方向可能出現重大的偏差,所以對於需求我們必須要抱有一個懷疑態度,對需求必須要復雜化,越復雜越詳細的需求,才能夠給后期的工作提供更多的幫助(這里的復雜化不是文字描述上的復雜化,而是整個需求的詳細化),越是粗略的需求分析,我們就越容易在項目后期來還這筆欠債(這個時候就沒有那么好還了,高利貸日子越久越難還上)

遇到問題不能驚慌

驚慌解決不了任何問題,反而會讓我們的智商下降,人在煩躁的狀態下是很難進入狀態的,就會導致項目進度十分緩慢,然后問題影響就會更加明顯,然后就會更加驚慌,然后項目就會繼續進度緩慢,如此的惡性循環對於項目還是自己來說都是百害而無一利的事情。所以在項目前期,就需要盡量的去發現這些潛在的問題(比如 Service 掛掉,比如第三方不能提供穩定的 Support,比如第三方的系統會有一些使用限制以及隱藏 bug。。。。。),然后大概根據這些最壞的情況想出一些應對的方案,使得真的發生的時候不至於感覺一下子天就塌了。

Buffer Time

做軟件開發,重要的一點就是一個延時性,我讓你今天完成這個功能,那么多半來說,你是完不成的,你會多需要一定的時間(雖然在計划的時候是認定確實能夠完成,但是在這個過程中,多半都會延期),因此我們給自己(或者給團隊)就應該要留下一些 Buffer Time 來應對這種情況的發生以及突發情況的發生。

精簡的郵件

沒有人願意經常看長篇大論的郵件,通過郵件溝通的時候盡量讓郵件內容變得精煉簡潔,需要解決什么問題,不需要圍繞問題的一大堆的詳細描述,就只要問題的精華部分,讀了就懂,這樣會大大的增加郵件回復的及時性。
總之,懷疑的心態在 IT 行業是不要丟掉的,我們不能相信任何人,包括我們自己。
如有問題,希望不吝賜教!

最佳答案:

本文经用户投稿或网站收集转载,如有侵权请联系本站。

发表评论

0条回复