又一次簡歷受挫
每每看著招聘網上上"需求,分析,諮詢,it"關鍵字下的一摞摞的搜尋結果,都讓人提不起精神
幹了四年了,業務經理也幹了一年,帶領著小20的團隊,不敢說一點問題沒有,但總還是有條不穩的引領這乙個需求團隊混殺在紛爭複雜的各種鬥爭之間
想想之前來公司,文分需求,理分編碼,傻乎乎的跟著大家一起幹起了需求.
公司給培訓,師傅給教方法,自己不斷實踐,總算是對需求是什麼,怎麼做有個小想法,懵懵懂懂的過了四年
平日裡也會有些困惑,比如,同學/朋友問起你幹啥的,我說做需求的,然後人家就困惑了,需求?需求是個啥?銷售麼?市場麼?諮詢麼?然後再我費盡巴拉的說了一堆,我的工作內容之後,大家恍然大悟的說"哦,是跟軟體開發有關是吧",於是索性,我以後就說"我是做it的",然後大家也就不問了
平日裡還有這樣的困惑,每每看著編碼,架構,qa的紛紛跳槽,各各飛出雞窩進鸞廟,我也蠢蠢心動的,搜尋職位,然後就出現,要不就是沒有行業背景,要不就是不是計算機專業,除了auto-reply的,還有幾秒迅速被pass給回執的,總之,乙個結論,您這樣的,我們不需要
於是動起了寫點東西的慾望.以我的理解,什麼是需求,為什麼做需求,怎麼做需求
什麼是需求?
我們團隊很有意思,有來自業務部門的人,有做過需求的人,有做過設計的人,有做過編碼的人,有做過測試的人.在乙個需求團隊中,你會發現這樣那樣有意思的衝突.
場景一: "這個使用者不關心!"
每每有技術組/測試組的跟我抱怨,"xx脾氣不好,總是不說清楚,一問到細節問題就總是說'這個使用者不關心!'"
通常情況下,總是來自業務部門的人會出現這種問題,前台點個鈕,後面批處理,裡面怎麼做,跟我沒關係.最後結果對了就ok拉,想怎麼設計怎麼設計,你們想去吧
有意思,因為通常跟操作層使用者調研時,你會聽到相同的話. 我們不把這種沒有分析過的東西叫需求,我們叫業務操作
場景二:"if...else..."
每次拿起業務規則文件,長篇累牘的if...else...,我就把需求人員叫來問,這個想要實現什麼目的牙...然後需求人員就把這個邏輯給我複述了一遍...於是我隨便指出乙個步驟,挪挪順序行不行牙,拆這麼多步要幹嘛牙,然後逐漸逐漸,才明白想要實現的業務規則是什麼
通常情況下,總是做過設計的人,比較容易犯這樣的問題,我都設計好了,您技術別改了,就我這個來吧
有意思,詳細設計全省了,直接上來編碼吧
場景三:"這個用例不是我的,你去問xx!"
又是每每有技術組/測試組的跟我抱怨,"問乙個業務流程弄不清楚,功能之間不知道怎麼互相影響的"
通常情況下,出現問題最多的是做過編碼的人,我這攤是我這攤,別人攤的你問別人去
有意思,技術測試給弄的團團轉,問了幾個人還是不知道這流程要幹嘛
場景四:"客戶需求就這麼寫的"
也見過幾個專案的客戶需求,有的寫的很籠統,有的寫得很詳細.現在這個專案的客戶很成熟,把客戶需求全寫成了用例,規則寫得很清楚. 於是,會發現,需求裡面的句子,從客戶需求copy到了系統需求中,完全的忠於原著
於是開發測試腦仁兒疼了就找我抱怨,這個邏輯怎麼回事
呀呀呀,我趕緊開啟客戶需求和系統需求一看,人家客戶需求說簡潔了,給理解偏了...
做需求的嘛,還是要動點腦子去調研的
任何乙個事物的發生都不是偶然的,不是沒有原因的,對需求的理解是在做需求之前就必須明確的
需求為何物? 個人感覺,客戶需求是沿用pmp的概念,發起人,客戶,(使用者),其他干係人已量化並且記錄下來的需要和期望,是開發團隊與使用者/客戶訂立的契約,;而系統需求是已被精化梳理後的客戶需要和期望的二次確認,也同時是指導開發的可被分解實施的單個業務目標的集合.
舉個簡單的例子,什麼是業務?就是口渴了要去解渴.什麼是客戶需求?就是當嘴唇發乾,那麼就需要找水,什麼是系統需求?就是,口渴了一定嘴唇幹麼?還有沒有其他的症狀呢?有更好的衡量標準麼?一定要喝水麼?別的飲料可以喝麼?找不到水呢?等等,等等.都是系統需求需要分析清楚的.
經過一系列的分析,我們會突然發現,客戶需求也許只是在描述一種客戶/使用者體驗到的場景,真正的需求隱藏在這個現象背後
為什麼做需求?
很多小專案或者小scrum,需求感覺瞬間就做完了,通常專案經理又當爹又當媽,管著專案進度,同時了解分析需求.
需求的時間可短可長,不過以為需求工作可以被弱化,我覺得就大錯特錯了
前段時間跟架構組一起開會, 上來按照自己的理解了解了業務模組,就開始紮進解決方案了.結果,轉一圈,這個需要先對需求了解了,那個需要先明確系統需要什麼功能,又繞回到了需求
需求就像是路邊燈,只有按著燈的亮才不會栽到水井裡. 不然就摸著黑走夜路,不知道走到**去了
也有的說,很多小專案,直接拿到客戶的要求就編碼,做完了給客戶瞅瞅,不行再改
我也非常同意,需求工作的開展從來不是跟專案割裂開的,既然如是,那麼是把需求文件寫全了,再開發,還是需求開發一起做,最終不過是要經濟有效率的完成專案. 但是我一直以為,拿開發出的產品找客戶確認的過程和把原型拿出來給客戶確認的過程,都一樣是需求工作的一部分,誰來做,怎麼做,可以根據專案的情況具體來分析
為啥要整理需求？
這幾天一直在處理各方面收集到的需求，目前整理的進度應該在80 左右，通過整理和分析得到如下一些資料 需求數目 353 預估的開發量 2536人天 也就是說，如果我乙個人來實現這些需求，一年做250天的話，需要做10.14年，如果365天鬥來做的話，需要6.95年，目前預估的開發量還沒完成，因此需要的...
需求是個什麼雞兒
都說需求分析是產品設計的第一步，也是產品經理的基本技能。但是需求到底是個什麼東西？這裡我們把需求用問題這個詞進行替代，就比較好理解了。存在問題，有就有一群產品經理等待著跟進優化。那麼如何發現和設計這些需求呢？1 發現需求 總所周知現在多數網際網路吃產品主打某種功能區解決或者服務一部分人。那麼這些產品...
需求 開發 售後 需求是一條財富資訊鏈
時隔半年，總想提筆寫一寫，我們作為第三方軟體提供商，如何去跟進系統維護？作為軟體開發人員，如何更加高效的進行軟體測試，增加系統互動性，提高使用者使用感受呢？這是乙個大話題，今天先簡單說一下我是如何看待開發人員做售後支援的。可能大家都做過開發，但說到售後系統維護，提供技術支援，解決日常問題，和使用者打...