做爲開發人員,不免會須要直接接觸客戶,那麼這就致使了須要能理解客戶說的需求,能挖掘出客戶描述中,真正須要的功能,在這麼多年與客戶的溝通中,有些客戶會整理出需求的簡單文檔給你,有些就只能是口頭說明,並且若是通過產品經理的轉述以後,若是產品經理沒辦法整理明白,就會發覺了一個很奇妙的事情,那就是:
你看到需求≠產品經理內心理解的需求≠客戶口頭說的需求≠客戶內心實際的需求,固然我這裏沒有任何貶低產品經理的意思。
(案例會不定時補充)
案例一:
某客戶說要作一個ERP,說了特高大上,聽着就以爲大型系統, 後來按進銷存等系統的功能規劃參考用戶給過來的文字整理了一份需求給到客戶,客戶說太複雜,,後來我跟客戶實際微信在線語音了一次以後,發覺,客戶只是想要一個相似於項目進度管理的功能+一點點的庫存管理就行,連個進貨單跟銷售單都省了。。與一開始看到的功能差了不是一星半點
大部分客戶只能是有一個朦朧的概念說要一個XX東西,當實際到開發階段的時候,朦朧的需求就會使得開發週期徹底沒辦法肯定,並且客戶也會邊想邊改,這就痛苦了,所以,整理出了幾條經驗:
一、首先要問客戶三個問題:是否客戶有正在用的系統?這套系統主要想解決什麼樣的問題?是否有心目中能夠參考的第三方系統?數據庫
問這三個問題,第一若是客戶已有系統了,那麼重點就在於客戶對現有系統哪裏不滿意,還須要增長什麼東西,這樣一來,能夠節省不少力氣,第二,客戶有時候只是一個朦朧的需求,可是他們爲何須要一套系統,以及想用這套系統解決目前哪一種問題,這個大部分客戶是能夠說出來的,好比:想規範審批流程啊、想讓財務報表和庫存能準一點啊、想對目前公司的流程進行電子化省的員工隨意走流程啊、又或者是想搭建本身的商城對外銷售啊等等,有了這個前提,那麼後面才能夠聊的下去了,而且功能的大致範圍能夠肯定下來。後端
二、無論完整的系統功能有多複雜,,必定要跟客戶談分期上線,不然就跟本身搬石頭砸本身的腳同樣,第一期儘可能外部功能少,由於第一期還須要預留時間作系統的一些基礎架構的設計啊,數據庫表單的設計啊,還有初期上線的調整期,這些都是須要時間的。
三、
別總是以爲客戶甲方是傻X,,換個思路想一想,人家都能搞清楚了,還要你幹嗎?你的價值不就是替客戶解決問題。
四、若是是作的商業系統的,通常能夠有兩條線能夠串起整套系統的流程:
一條錢流,一條物流。
錢流是指整套系統中有多少個流程口是進錢的,好比:商城的客戶訂單、進銷存系統的銷售單等等;
物流是指整套系統中,商品的庫存是怎麼流動的,哪一個節點扣,哪一個節點增長,好比商城的客戶訂單或發貨單,進銷存系統的進貨入庫單或銷售出庫單等等。
通常來講絕大部分商業系統都是要解決錢跟庫存的管理,通常來講,這兩條線,若是跟客戶確認,,客戶是能夠明確告訴你的,由於客戶本來就是按着這樣去運行的,把確認的流程畫出來或者整理成UE圖,,基本上就成功了20%
五、要客戶提供目前現有在有的全部表單(紙質的或者電子版的)的給你,而且單據上須要有模擬的數據,從客戶給出來的單據上,大致能夠看出這套系統中,須要爲客戶開發哪些單據,這部分也是客戶能夠明確提供出來的
六、經過上述幾個階段以後,大致上就能夠整理出一份客戶的工做流,而且這套系統的大框架的功能就能夠肯定下來了,再來就是一些細節的地方須要不斷地跟客戶覈對,好比:商品信息是否有什麼特殊的字段,不一樣的表單上的字段會不會有什麼特別的字段須要注意的,權限要怎麼管理(不是全部客戶都須要權限功能,客戶不須要就不要硬塞,沒加錢的),在不斷地與客戶交流中,修正你手中的思惟導圖或者文檔
七、通常若是客戶公司比較正規的話,除了跟對接人確認需求的同時,還須要注意去跟財務部確認他們的真實需求,由於經驗下來,財務部是最難搞定的,財務搞定了,其餘部門就相對好解決一點,由於做爲老闆,通常最終就關心錢的事情而已,只要錢對了,其餘都好說,而財務部一般是一分都不能差。
八、若是出現需求常常變更的話,通常有兩種可能:微信
一是客戶本身的經營模式常常變更(這個比較少,畢竟系統這東西不像設計圖,是肯定的,能夠逆推的,跟各人審美無關),這個親身經歷一個剛創業期的客戶,模式三天兩天變一次。;架構
二是初期整理出來的需求不是客戶心理真正的需求(這個可能性比較大),通常文檔是給公司內部人員本身看的,其實不要期望客戶能看得懂UE或者思惟導圖實際要表達的事情。框架
所以,若是邊開發,客戶常常要求修改功能的話,頻率比較高的狀況下,最好中止開發,把需求從頭開始跟客戶再過一遍,不然就是越努力越淒涼,產品經理累,客戶也累,開發更累優化
九、若是客戶有打算經過系統管理生產流程的話,必須跟客戶建議,初期先對倉庫的生產出入庫數量進行管理,等倉庫人員對系統更熟悉了以後,再開始討論怎麼樣管理或優化生成環節,由於:大部分生產環境的工人也好,操做人員也好,對IT是不熟悉的,而且最致命的一個問題是,國內的狀況是,幾乎沒有多少家工廠的生產流程是特別標準的,大部分都是本身玩本身一套,所以,若是要作生產方便管理的話,優先確保倉庫對生產的收發兩端數量的準確,只有出入的數量準確了,當開始推動到生產環節的時候,至少先後兩端的數量是準確的,那麼出了問題,就查中間的操做流程,相對而言會比較容易查出問題。spa
若是一開始就整套上線,會出現的問題就是,生產環節的操做員,因爲習慣問題,要麼作錯單,要麼先記錄紙質後錄入系統,最終致使數量永遠對不齊。 設計
最後的最後,以上只是針對中小型客戶,大型客戶未接觸過,不必定可用。而後對新入行作後端開發的同窗一個建議就是,最好能多接觸一點好比說ERP系統,進銷存系統,由於這類系統,屬於長流程,而且流程之間的銜接比較縝密,能夠培養一些邏輯的思惟以及跟客戶的溝通能力,大部分互聯網的系統都不會有太長的流程。後端開發