一咐鹤、現(xiàn)場需求調(diào)研人員對研發(fā)的開場白：

1.這個需求很緊急，麻煩抓緊安排圣絮。

2.局方領(lǐng)導(dǎo)檢查祈惶，這個功能需要演示。

3.這個功能很簡單扮匠，一天就做完了捧请。

4.功能是項(xiàng)目驗(yàn)收用的。

5.這個功能需要再增加（修改）某某邏輯

二餐禁、功能開發(fā)完畢幾個月后現(xiàn)場反饋的問題：

1.某功能（n個月前開發(fā)的）客戶要用血久，升級怎么失敗了？

2.某功能怎么查不出數(shù)據(jù)帮非？

3.某功能客戶要增加字段氧吐，請盡快調(diào)整。

4.某功能點(diǎn)擊報錯末盔，麻煩定位下問題筑舅。

三、針對以上問題的分析

很多時候現(xiàn)場和客戶對需求都不明確陨舱，根本不知道自己想要的是什么翠拣。都抱著先做出來看看樣子，不行再改的態(tài)度去做需求游盲。

如果現(xiàn)場在做需求分析的時候能多和用戶溝通需求的實(shí)用性误墓。例如使用場景蛮粮、應(yīng)用效果以及對功能最本質(zhì)的需求。這樣一來應(yīng)該可以了解用戶的本質(zhì)想法以及期望效果谜慌，這種溝通后得到的需求單才算是一個負(fù)責(zé)的產(chǎn)物然想。需求本身就需要反復(fù)確認(rèn)的環(huán)節(jié)，而不僅僅是將客戶的語言簡單轉(zhuǎn)化后填寫到需求單中欣范。很多時候我們自己在心里都一種思想变泄，將局方當(dāng)做不可忤逆的角色。其實(shí)無論是局方還是需求調(diào)研都應(yīng)該是平等的恼琼，我們是幫助局方更好的管理他們的資源提供便利妨蛹，而不是被局方指揮的碼農(nóng)。局方的接口人也都不是隨隨便便找出來的晴竞，建設(shè)性的意見和建議也應(yīng)該會合理的接受蛙卤，出現(xiàn)不合理需求的時候我個人認(rèn)為就是需求調(diào)研時我們的調(diào)研人員根本就沒有真真正正的思考功能合理性，同樣也提不出任何讓接口人認(rèn)可的建設(shè)性意見噩死。

客戶不催現(xiàn)場不問表窘，需求做完了就放著等哪天客戶想起來的時候才急著要升級。

這種功能做完不升級的情況舉不勝舉甜滨。等到某天局方的人想到這個功能了，現(xiàn)場才急急忙忙自己升級或者聯(lián)系家里研發(fā)協(xié)助升級瘤袖。很多時候功能已經(jīng)拖了幾個月衣摩，當(dāng)時的升級文檔現(xiàn)場找不到了，家里研發(fā)因?yàn)闀r間過久忘記了甚至有相關(guān)研發(fā)離職導(dǎo)致升級困難耽誤時間捂敌。這種問題不單單是現(xiàn)場的責(zé)任艾扮，應(yīng)該是流程管控的缺失導(dǎo)致的。

功能升級后幾乎沒用過占婉，等檢查的時候點(diǎn)了才發(fā)現(xiàn)存在問題泡嘴。

現(xiàn)場功能升級后一直沒有使用，等到集團(tuán)或者領(lǐng)導(dǎo)檢查時候才突擊點(diǎn)下每個功能逆济，發(fā)現(xiàn)了一些功能根本就無法使用或者報錯酌予。功能點(diǎn)不完善這個完全是研發(fā)的責(zé)任，如果有一個完善的測試流程這個問題是可以避免的奖慌。但很多項(xiàng)目組的開發(fā)模式都是研發(fā)開發(fā)功能抛虫、自測、提交文檔升級包給現(xiàn)場简僧。自測個人認(rèn)為是一個沒有任何約束性的測試建椰，就和自己考試自己打分一個道理。

基礎(chǔ)數(shù)據(jù)源問題導(dǎo)致查詢無結(jié)果（統(tǒng)計程序沒運(yùn)行岛马、相關(guān)原始數(shù)據(jù)表不存在）

很多情況功能查詢無數(shù)據(jù)棉姐，都是后臺的統(tǒng)計程序沒有啟動或者相關(guān)動態(tài)表沒有創(chuàng)建導(dǎo)致的⊥懒校現(xiàn)場維護(hù)人員如果看下日志應(yīng)該是可以分析出原因而不需要聯(lián)系研發(fā)定位問題。但目前來說愿意看日志的現(xiàn)場維護(hù)人員不多伞矩，其根本原因是部門沒有統(tǒng)一日志格式的規(guī)范笛洛，每個人的功能里日志滿天飛。這種日志除非自己寫的扭吁，其他研發(fā)看起來都很費(fèi)力更不用說現(xiàn)場維護(hù)的人員了撞蜂。

功能健壯性幾乎為零

人天生都是具有破壞意識的，就針對功能來說侥袜，如果可以把這個功能搞掛很多人的心理都有一種成就感蝌诡。功能的健壯性和完整的測試體系有關(guān)。功能給客戶使用的過程中不可避免會出現(xiàn)客戶惡意的輸入一些非法參數(shù)導(dǎo)致功能報錯枫吧。如果有著頁面標(biāo)簽參數(shù)校驗(yàn)組件的存在浦旱，應(yīng)該也可以阻止絕大部分的問題。

一句話功能（客戶需要xx日報表）導(dǎo)致垃圾代碼堆積

這種功能姑且不論是否應(yīng)該存在九杂，就代碼而言此類功能的重復(fù)度是最高的颁湖。此類功能應(yīng)該是以動態(tài)參數(shù)配置共用一套代碼來處理，而不應(yīng)該每次拿到需求后就重新建包寫重復(fù)的代碼例隆。

四甥捺、個人建議

1.需求管控

現(xiàn)場維護(hù)的每位員工都希望自己的需求都被排到優(yōu)先級最高，導(dǎo)致了插隊(duì)的現(xiàn)象產(chǎn)生镀层，插隊(duì)的理由也多種多樣镰禾。

針對這種情況我希望大家能協(xié)商版本發(fā)布周期，以自然月內(nèi)的所有需求為一個版本唱逢。等到下個月升級的時候?qū)⑸蟼€月版本內(nèi)的功能一起上線吴侦，而不是針對單個功能點(diǎn)來進(jìn)行開發(fā)上線。

2.升級工具

很多項(xiàng)目組的升級步驟是kill進(jìn)程坞古、替換class文件备韧，jsp文件執(zhí)行啟動腳本。這種方式是最原始痪枫、最直白的升級方式同樣也是最靠不住的方式织堂，因?yàn)槭止?zhí)行命令替換、修改每個文件的時候不能保證不會遺漏缺失听怕。當(dāng)重啟現(xiàn)網(wǎng)系統(tǒng)發(fā)現(xiàn)各種報錯后浪費(fèi)的都是大家的時間捧挺。每次升級至少去1-2個研發(fā)支撐，原因就是在升級過程中有著各種各樣的問題需要去解決尿瞭，而這些問題恰恰都不是代碼層面的功能性問題闽烙。

以以前在華為升級的經(jīng)驗(yàn)，應(yīng)該是研發(fā)提供升級包給測試、測試按照升級文檔升級后測試功能黑竞。然后將測試過的升級包交給現(xiàn)場捕发。整個升級過程有自動化工具執(zhí)行，操作步驟就是簡單的導(dǎo)入很魂、提交扎酷。研發(fā)保障功能的實(shí)用性、測試保障功能的可靠性遏匆、升級工具來確保升級步驟的完整性法挨。

3.日志規(guī)范

統(tǒng)一規(guī)范的日志方便閱讀糾錯，后續(xù)也可以寫一些分析工具用來解析日志文件按照不同的功能過濾日志方便研發(fā)和現(xiàn)場定位問題幅聘。

4.簡單報表抽象

簡單的報表查詢功能大概占總需求的15%凡纳，以我個人為例從開發(fā)到上線至少需要3人/天時間。大部分的報表類功能是可以做到抽象的帝蒿，將模塊骨架抽出以動態(tài)參數(shù)的形式組裝實(shí)現(xiàn)配置即可用荐糜。

五、后記

以上的文字是我在行業(yè)工作以來的感受和建議葛超、有理想化的意見也有實(shí)際擺在面前的問題暴氏。如果可以解決所有甚至只是一部分目前存在的不合理問題，我想這對整個流程都會是一個很大的進(jìn)步绣张。