為什么你的項目推不動(一)
編輯導讀:在和其他部門同事合作的過程中,總會遇到這樣的問題:交代給別人的事情做出來的效果不盡如人意或者進度緩慢,你在旁邊焦急如焚。這時候應該怎么辦呢?本文作者根據自身工作經驗,告訴你解決方法分三步走,與你分享。
不知道你有沒有遇到這樣的問題,你交給同事小a一件事,要么進度很慢,要么是收到的結果差強人意,無論你和小a是上下級關系還是合作關系,都會發生這樣的問題。
工作中80%的人都和小a差不多,那么這個時候除了換掉80%的小a,有沒有什么辦法保證事情順利進行呢?按照涉及多人的互聯網軟件項目,牛奶總結了三個步驟,如果是兩人合作,參考前兩個步驟即可。
01 確認目標
確認目標這件事兒幾乎是所有事情的第一步,明確的目標能夠保證相關人員在方向上是一致的一方面確認目標后,可以具有更靈活的解決方案,不會專注在單一的執行方案上,而是共同的結果。比如你們想要的是提升用戶活躍,那么提升的方法有很多,大家不會專注于爭辯是否是當前的方案,對新的解決方案的接納程度也會更高。
另一方面,當合作雙方是不同的利益體時,達成統一的目標有助于提高大家共同的工作積極性。畢竟解決自己想要解決的問題比幫別人做自己不想做的事情,心態上積極很多。
02 確認可執行標準
為什么確認可執行標準很重要?
對于相對復雜的事情,我們經常會用經驗來判斷一個人是否能做一個事情。而執行標準是經驗的提煉結果。因而確認可執行標準是保證結果相對可控的必要方法。
什么算是可執行的標準呢?
拿一個相對簡單的工作舉例:b端業務調研。
如果我們對調研的要求是:產品經理希望調研結果盡量還原業務場景,這句話顯然很難保證結果符合預期。
但如果我們提出如下要求:
調研的具體內容包括以下幾個問題:
- XX部門的工作流程是什么?
- 他們的組織結構是什么?
- 他們在工作遇到了什么問題?
- 為什么會產生這樣的問題?
- 解決這個問題能夠給你們帶來怎樣的好處?
上述的問題就是調研可執行的標準,通過這樣方式的調研就能從實際的業務場景和開發該功能產生的價值了解業務。
調研報告請盡量還原用戶的話術,并保留好調研錄音。
如果沒有提供這樣的標準,調研人員可能會問:
我們是負責給你們優化流程的,請問您需要我們做什么?
得到的回復大概率是用戶根據問題自己思考的解決方案。
這樣的問題不利于根據業務分析本質的解決方案,最終只能照貓畫虎的復刻別人的想法,成為了一個原型產品經理。但如果我們提供了調研的問題模板,負責調研的同事按照問題做好記錄,結果大概率不會太差。
我們平時在工作用到的周報模板、交互走查表、原型文檔模板都是可執行的標準。因而確認可執行的標準會大大保證我們的工作符合預期。
03 確認執行流程
有了前兩步,可以解決兩人合作時結果差強人意的問題。涉及到多人時,確認執行流程很有必要。
我們拿需求變更來舉例。
- 場景1:業務同學a和產品經理反饋了需求變更a,過了一段時間,發現軟件系統并沒有變化。
- 場景2:業務同學a和產品經理反饋了需求變更a,產品經理落實了解決方案,不久后業務同學b和產品經理反饋了需求變更b,產品經理發現變更b和變更a有沖突啊,這該怎么辦?
- 場景3:業務同學a和開發反饋了需求變更a,開發解決了問題。過了一段時間,產品經理問:“誒,咱們產品怎么變了?”
以上3個場景的發生,主要是因為沒有明確的執行流程,對應場景的解決方案是制定需求變更的流程。
針對需求變更,我們可以制定如下流程:
- 業務方匯總需求變更,并確認變更
- 由統一的業務出口人負責和產品經理對接變更
- 產品經理根據變更繪制原型
- 產品經理將繪制的原型和業務方再次確認,是否滿足需求
- 產品經理將具體變更原型進行記錄
- ui落實變更設計圖
- 技術落實需求變更的開發
看完流程,不知道你有沒有發現,所有環節看似連著,但又好像斷開了,為什么會出現這種情況呢?
因為我們希望業務做完事情告訴產品,產品做完事情告訴ui,ui做完事情告訴開發,開發最好還能告訴業務,也就是任何一個環節斷了,這個事都有可能推不下去,就出現了場景1的問題。
那怎么解決這種情況呢,這時候我們就需要一個負責需求變更的人,可以起到整體進度的跟蹤和流轉的鏈接,畢竟工作之后,我們都清楚讓一個人做完事情主動推進下一個環節并不現實。
有了統一的需求變更人,連接人時間節點和對應負責人分階段跟進,項目推動就容易多啦~
#專欄作家#
牛奶,可可愛愛單身產品狗一枚,工業互聯網產品經理,微信號:1528120885,微信公眾號:產品經理的小紅書,人人都是產品經理專欄作家。分享對產品的思考和總結,一起快樂成長。
本文原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Unsplash,基于 CC0 協議
- 目前還沒評論,等你發揮!