以農業行業為例：談談ToG資訊化產品建設分享
本文將從筆者認為的ToG資訊化產品建設的七個步驟，進行ToG資訊化專案分享。同時，部分內容以農業為例進行闡述。
首先我將產品進行如下的劃分：2C、2B、2G、2GB。
2G指政府；2GB指國企和央企；2GB按照統一維度劃分是應該包含在2B中的。
只要不是2C的產品，一般設計的過程中都需要考慮到我們的使用者，並將我們的使用者稱之為甲方，簽訂合同以“養活”大夥，這個時候我們的使用者都會被冠以“客戶”的稱號。
而對於在專案中提煉出IT企業自身的產品的企業而言，當他們基於PaaS和SaaS對外提供服務，或者幫客戶構建起PaaS和SaaS對外提供服務時，還會引入租戶及客戶的租戶角色，也是做此類產品需要新增審視的產品角色。並且這種場景在2B專案中較多，2G和2GB專案中也存在。
2G、2GB中很多產品只能稱之為系統，基本上是沒有產品的迭代更新階段的。專案結束，即是這個系統的終止，除非有二期專案的更新，否則培訓和維保期一過就很少會被使用，這也使得很多專案做著做著就消失了，或者系統用著用著就不用了。
這個觀點對於ERP、雲端計算平臺、大資料平臺等底層技術平臺產品不適用。
正是這個觀點的現實存在，凸顯出做農業2G專案中農業資訊化產品建設的重要性——將農業資訊化產品真正賦能於農民，為農民創造出切實價值，以縮短我國農業工業化與發達國家的差距。農業資訊化決不能變成若干個巨頭企業和資本市場洗錢賺錢之地，要不然對不起那7億農民。
夢想遠大，但現實還是靠專案賺錢，只能說我分享後能夠在賺錢之餘為農民留下可持續使用的產品，這一點必須向直接面向農民的2C的農業網際網路產品們致敬。
接下來，會對如何做好2G的農業資訊化產品建設做些分享：
第一環節：把握客戶的資金出處
2G專案首先一定要把握客戶的資金出處，這是最根本的，再好的專案也需要有資金的支援。
要把握客戶資金的出處就是第一需要找到專案的主體受益者。
而專案的受益者往往又可以按照顯性受益者和隱性受益者劃分，比如：
在農業，任何2G的政府專案的顯性受益者是農民、農企和當地的農業；隱性受益者則可能是該專案立項的政府部門、當地的涉農產業鏈及整個農業產業鏈等，甚至是中國整個農業都是可能的。
資金出處需要把握顯性受益者。
假如顯性受益者主要是農民，那麼資金出處就是農業局或者縣委；假如顯性受益者是農企，那麼資金出處就是農業局、縣委、商務局、工商局、扶貧辦等，部門會多很多，需要明確一個主抓部門一堆協助部門，還需要明確協調部門（別的部門的資金憑什麼要給這個部門使用）；假如顯性受益者是當地農業，那麼出資部門可以是農委、農業局、縣委、商務局、工商局、招商辦、產業辦、市場監督管理局、質監局等（政府和黨委部門的融合）。
至於隱性受益者是不能成為資金出處的，只能作為解決方案吹噓的方向。
第二環節：尋找專案大方向的切入點
在找到客戶資金的出處後，就是需要尋找專案大方向上的切入點。說直白點，就是告訴政府使用我們的資訊化產品之後可以實現哪些遠大的目標——這個目標是跟行業、公司主營產品、公司最佳實踐案例和合作夥伴產品都密切相關，是一項體系層面的介紹。
當然要是沒有最佳實踐案例怎麼辦？
很多公司的做法是和他人公司合作，逐步構建自己的最佳實踐案例體系。
在農業領域，這個目標可以切合的大方向有農業三產融合、鄉村振興、扶貧攻堅、精準扶貧、科技興村等。在交談過程中，一些思維迸發的領導會在你提供的目標下，跟我們逐步互動。如果想要的產品會超出我們和合作廠商的範圍，就需要減縮客戶的範圍；或者在下次交流前擴大我們自身的能力集範圍。
最終就是要將大方向上的切入點在我們的掌控之中，並能為客戶帶去喜感。
第三環節：暴露切入點下的需求
在大方向確定後，就是要將客戶的需求進行明確，確認需求的過程中就需要訪談上一個環節的領導，以及他們的下屬。主要是下屬，就是那群幹活的科員，只有這樣才能實現資訊化產品“既與實際業務相配合，又與領導的想法相吻合”，最終才能找到落地的解決方案。
訪談過程中，一定要注意適時引導訪談客戶在我們現有產品和解決方案能夠解決的需求中，以便增強專案的可操作性和交付的穩定性。再者，要適時為客戶站在業務的基礎上，交流使用我方軟體帶來的業務的創新點和變革。
需求需要明辨公司能否實現，需求的優先順序，是否為偽需求；並面向客戶角度，形成客戶通俗易懂的需求文件（分為售前需求文件和產品需求文件，這個環節建議用PPT做個售前需求文件即可，並反映在後續彙報的解決方案中）。不同級別的客戶給予不同的需求文件，對領導就需要拔高需求文件——可新增產品價值的闡述，即實現XXX需求後能夠帶來哪些價值和變化。
第四環節：針對需求提供解決方案
明確使用者需求後，是需要提供詳細解決上述需求的解決方案，而不是直接進行產品開發階段或者是專案簽訂。
在解決方案中，需要將上一環節的需求文件包含在內，並利用公司現有的產品和合作夥伴的產品有條不紊地解決上述的需求。
解決方案也分為兩種：
一種是銷售拜訪時的通用性解決方案——這種解決方案一般是初期沒有進行溝通前的拜訪階段使用；
一種是隻要溝通過一次就需要提供針對性的解決方案——提高與專案的鍥合度（當然很多公司只有一個通用方案，針對性解決方案也只是將通用性解決方案修改了部分內容）；針對性的解決方案還需要迭代，與客戶的不同見面次數及交流次數下，需要提供不同版本的針對性解決方案。
在編寫針對性解決方案的時候，工程師需要與產品經理詳細溝通，以便撰寫的解決方案最終能夠落地；儘量使用公司自己的產品落地，實在無法滿足客戶需求才會考慮合作伙伴的產品，做整合商。
第五環節：落地解決方案的資訊化產品
有了解決方案，並達成專案意向，完成招投標環節之後，就是軟體交付階段。在這個環節，有成型軟體產品的公司在這個階段的交付壓力會小一些。
這個階段裡，工作就落在專案經理和產品經理身上，需要按時按量完成交付。產品經理需要面向客戶進行再次溝通確認，確認產品設計階段的產品需求文件。
這個工作，有條件的公司會在第三環節中與解決方案一起前往使用者處進行溝通，會讓產品做專案前期的工作；還有的公司直接拿解決方案需求當產品需求，差別的戰略也嚴重影響這個專案組在使用者中的形象，影響下一環節的持續性專案發現。
產品做完需求分析後，一般會做略帶互動的產品原型，以便和客戶進行原型確認/原型評審，複用成型的產品的部分，可直接演示成型的產品。演示成型產品的環節也可以安排在第二個環節與使用者溝通後，給予使用者直觀的產品價值體現。
緊接著就是軟體研發、測試和驗收。建議在軟體研發過程中也需要與業務部門的業務人員溝通，讓他們試用開發完成的模組，而不是等到驗收的時候一股腦兒地拿出來。
第六環節：持續專案發現及產品優化
一般來說到第五環節就專案就結束，不含維保期，但是ToG專案很多是可以持續性投入產出的。
這個時候就需要儘量構建起一系列的產品圈，這個產品圈還需要與解決方案相結合，為客戶不斷解決新的需求（有些時候還需要主要創造需求，比如帶領導去先進地區逛逛看看其他政府是如何做的）。說白了就是持續拱專案，還讓現場辦公的專案組持續在現在辦公，持續賺錢。
第七環節：幫領導解決隱藏需求
這個環節的需求，並不是用資訊化解決的，很多時候也不需要這個環節的；主要是專案經理、解決方案和銷售參與，並需要調動公司的高層資源。
領導的隱藏需求有政績視覺化、學歷、產業化、引資、招商、名人效益、縣域名牌等。以政績視覺化為例，就需要解決方案在設計時將硬體裝置加入其中，使得整個專案可演示可展示，有實體的載體，大屏就是再合適不過的武器。
作者：清河落河清，一個農業產業產品經理，公眾號：農業一二事
本文由 @清河落河清 原創釋出於人人都是產品經理。未經許可，禁止轉載