top of page
  • 作家相片馬在飛科技

成功的專案管理方法(上):目標導向與報價清楚


目標導向與報價清楚
目標導向與報價清楚

大家好,我是馬在飛的馬。


之前我們說到,報價的不明確、需求的誤解、Bug的惡性循環以及延遲交付等因素都可能導致專案的失敗,對企業來說,外包的團隊畢竟是組織外的團隊,各種變數難以掌控,雖然轉移了自己組建團隊的風險,但卻提高專案失敗的風險。所以當企業在尋找合作的外包團隊時,外包團隊僅只是一句「我們保證會如期如質的完成專案」就能確保專案順利是遠遠不足的。

馬在飛依據過往管理外包專案的經驗,提煉出的一些管理方法,有助於在外包軟體的領域,提高專案成功的機會,依序為:目標導向管理、報價清楚明確、持續增量交付、開發進程透明


以目標為導向的管理核心思維


「您好!我有一個開發APP的需求,你們可以開發APP嗎?」

「可以喔,請問您想開發的是什麼樣子的APP呢?」

「我想要開發一個像Facebook一樣的社群APP,可以直播,然後用戶也可以用著個APP點外送,像Food Panda一樣!想要2個月後上架,你們可以嗎?」

「……」


好,我或許有一點點誇張,但在接案的過程中 - 套句產品大神梁寧的話 - 遇到想做「一整個互聯網」的客戶實在不在少數,雖說有夢最美,難保你的構想不會是下一個爆紅的產品,但當你有時間與預算限制時,如果不懂的適當的取捨,用產品迭代的思維去前進,只會蠻幹,最後預算花光了,卻只得到一個跛腳的產品。

梁寧,著名產品人
梁寧,著名產品人

梁寧是著名產品人,與數個中國知名企業都有長期的合作。

以她的資料庫加上我的個人經驗,相信我,想要做「整個互聯網」的人真的很多


原本的幻想很美好,但在看開使頭入開發產品前,我們要先確認一個核心點,你的產品想要帶給用戶什麼?想要解決用戶的什麼痛點?想要帶給用戶什麼樣的爽點?回歸的產品的中心理念,由此發展產品的核心功能,確保在專案初期將有限預算的投入了最需要的功能,並也依循這個概念去規劃產品的每一次的進步與迭代。


在管理專案時,也應持續保持這個思維,了解自己的目標與目的,做出最好、最有效的選擇。因為在現實中,我們可能遇到很多情況,會有預算/時間不足、外在環境變化等,不如預期的變數,若固執於原本的規劃,反而可能讓專案或產品失敗,但若你清楚目標是什麼,就可以優先剔除對目標沒有幫助的事情,確保資源的集中,再來想辦法先使用更簡便的替代方案來達成目的,而不會因為一些挫折或困難導致專案窒礙難行。

理想很豐滿,現實很骨感
理想很豐滿,現實很骨感

圖片來自:weibo

理想很豐滿,現實很骨感。如果不懂變通,恐怕永遠只是活在虛無的妄想中。


馬在飛科技在進行專案管理時,秉持著這個中心思維,不像傳統的外包,只是去做客戶提出功能,我們會進一步的去思考理解這個產品的核心功能,並依據客戶的預算與時間,和客戶討論調整專案內容,當專案遇到預期外的問題時,我們也會秉持達成目標的精神,去建議不同的解決方案,在馬在飛,我們要的不只是專案做完,而是把專案做好。



報價初期就清楚明確,後續也好管理


之前我們提到過,一般外包公司,在粗淺的理解專案後,都是憑經驗值用時間去報價,這樣報價其實是相當不可靠的。第一,外包公司想像的功能可能和客戶要的有很大的落差,造成後面專案在執行上有很多爭議,第二,不同經驗值得工程師估價結果可能不一樣,若外包公司都找沒有經驗的小菜菜去估價,客戶起不虧大了!

沒有經驗的工程師去估價
沒有經驗的工程師去估價

恩...這個QRcode掃瞄功能,我大約要做1天到3週吧!


馬在飛我們改用另一種形式的報價,叫做「複雜度點數」報價,當我們初步了解客戶的需求後,我們會將客戶的需求拆解成「User Story」,敘述這個產品可以讓使用者做些什麼事,這對沒有軟體開發背景的客戶來說,會比直接的功能列表好理解。再來列出要達成每一個User Story要完成的工作或功能,最後去排序出項目的複雜度,依據複雜的程度由低排到高,再去賦予每個不同複雜區間的功能一個複雜度的點數,以此完成估價的基本,再依據整體的複雜度點數去做報價以及時程的預估。


這種評估的方式的好處,在於複雜度排序的的公信力遠高於直接估算一個功能需要的時間,試想一下,你問工程師「做一個Facebook和計算機,各要花費多少時間?」和「做一個Facebook和計算機,哪一個比較簡單?」工程師哪一個問題的答案會比較快、比較精準?再者,在這個工程中,我們也將整個產品的功能進行了一次梳理,讓客戶可以確認,我們想像中的產品功能和他們的期待是否有落差?有沒有哪個項目,我們可能高估或低估了,都可以在報價期就先發現認知上的落差,避免後續爭議,之後再開發的過程中,若有功能的變動,也可以更快的比對出差距的內容,來決定是否有需要加價,或可以用什麼次要功能進行替換。

馬在飛科技的估價單
馬在飛科技的估價單

一目瞭然的估價單,讓客戶清楚了解花的錢都去了哪裡

結尾

馬在飛科技不用空口無憑的方式來保證專案的成功,我們採用的是實際的方法,來改善並避免軟體外包專案可能會遇到的問題。下一篇文章,我將繼續和你分析,為什麼「持續增量交付」、「開發進程透明」可以有效的降低專案風險,提升專案的效率喔!


如果你有任何管理專案的經驗可以分享,歡迎留言並分享我們的文章,我們也很希望和更多人討論的專案管理的經驗和想法喔!讓我們一起為了更好的未來努力!

------------

若你有軟體開發或專案管理的需求,請點擊此並留下你的需求,我們會盡快與你聯繫

你也可以在Medium上看到馬在飛的文章喔!前往Medium

【馬在飛科技】不是軟體專業,如何建立開發功能規格? User Story(下)

上集傳送門 Hi!大家好,我是馬在飛的Nat。 上篇最後有提到了 User Story 是刻意模稜兩可(ambiguity),其原因在於透過模糊而促使你去和團隊的溝通。為什麼要刻意促進溝通呢?因為在 User Story 的方法出現之前,大家建立規格方式,就是儘可能的收集資訊,最常見的方式叫使用案例(Use Case ),Use Case 指的是使用者與產品之間的各種交互行為,以下是以售票系統為例

【馬在飛科技】不是軟體專業,如何建立開發功能規格? User Story(上)

大家好,我是馬在飛的 Nat。 這篇文章我們來聊聊:不懂軟體要如何建立開發功能規格? 在軟體開發上有很多專業的名詞如: Landing page、Tab bar、CSS、HTML、API、Database 等,這些都是建構APP或網頁的必要項目,在不了解這些專有名詞的情況下,真的有辧法去建立功能規格嗎?為什麼不能由委託給的軟體外包團隊建立呢? 產品的功能最好由「你」建立。因為產品的成敗最後一定是你

bottom of page