摘要: 互聯(lián)網(wǎng),從今年5月~7月的準(zhǔn)備,再到8月入職至今的半年以來,感受和經(jīng)歷有很多。年末歲尾、空閑之余,來梳理那些日子里還記憶尤新的片段。
畢業(yè)后開始做程序員、工作第3年轉(zhuǎn)做了系統(tǒng)分析師,第5年轉(zhuǎn)做項目經(jīng)理,1年之后投入互聯(lián)網(wǎng)產(chǎn)品至今。7.5年的職業(yè)生涯里,在收獲各階段經(jīng)歷的同時也在感受著互聯(lián)網(wǎng)行業(yè)帶來的各種變化。而對于轉(zhuǎn)互聯(lián)網(wǎng)的初衷及時機(jī),概括來說有如下幾點:
1.互聯(lián)網(wǎng)產(chǎn)品更加貼近生活、更有趣、更喜歡
2.積累了軟件開發(fā)、產(chǎn)品及項目管理工作經(jīng)驗
3.積累了互聯(lián)網(wǎng)產(chǎn)品規(guī)劃、設(shè)計、管理及運(yùn)營等書籍閱讀和筆記
4.積累了對一些互聯(lián)網(wǎng)產(chǎn)品的看法和見解
從開始關(guān)注互聯(lián)網(wǎng)產(chǎn)品,到感興趣和不間斷關(guān)注,到最后加入這個圈子,那些過往的情景還歷歷在目:
閱讀全文
posted @
2014-11-03 13:05 cheng 閱讀(396) |
評論 (0) |
編輯 收藏
摘要: 高速發(fā)展的世界,需要我們迭代地開發(fā)和改進(jìn)業(yè)務(wù)問題的解決方案,我們需要一些方法來持續(xù)探索業(yè)務(wù)及其問題,將這些要求告訴技術(shù)專家,他們?yōu)闃I(yè)務(wù)提供技術(shù)解決方案。
許多組織機(jī)構(gòu)不是等待需求的所有細(xì)節(jié)都得到定義,而是更喜歡迭代完成這些業(yè)務(wù)活動,定義一些需求,開發(fā)一部分解決方案,定義更多的需求,這樣增量式交付發(fā)行版本,直到解決方案被判定完成。這種迭代的方式意味著,業(yè)務(wù)環(huán)境和開發(fā)環(huán)境中的關(guān)注點、想法和變化更加同步。使開發(fā)者更了解今天的業(yè)務(wù)問題,工作的產(chǎn)品適合今天的業(yè)務(wù)環(huán)境。
這種持續(xù)的工作探索意味著,業(yè)務(wù)分析師持續(xù)地將新故事或需求加入分析列表,這個列表又持續(xù)地按價值進(jìn)行分析,最重要的是按業(yè)務(wù)價值來分析。列表根據(jù)價值和緊急性來排列優(yōu)先級,最高優(yōu)先級的需求交給開發(fā)者開發(fā)。
閱讀全文
posted @
2014-06-02 23:59 cheng 閱讀(1951) |
評論 (1) |
編輯 收藏
摘要: 今天的大多數(shù)軟件都不是擁有它的組織機(jī)構(gòu)開發(fā)的,而是購買的。考慮到這些開發(fā)和解決方案選項,今天的業(yè)務(wù)分析師有一項額外任務(wù):即決定最佳的策略來發(fā)現(xiàn)和溝通需求,不論組織機(jī)構(gòu)決定采用哪種方式實現(xiàn)自動化。
以需求策略作為指導(dǎo),決定從哪里開始,是否有足夠的細(xì)節(jié),你需要哪個迭代循環(huán),記錄知識時采用哪種形式,何時復(fù)查,何時讓哪些利益相關(guān)者參與,何時構(gòu)建原型,何時以及如何做大量的事情,讓你的工作更接近為業(yè)務(wù)產(chǎn)生最優(yōu)價值,每個項目的情況不同,有必要采用不同的做事順序、做事細(xì)節(jié)、溝通形式。
閱讀全文
posted @
2014-06-02 23:58 cheng 閱讀(1219) |
評論 (1) |
編輯 收藏
摘要: 需求評審環(huán)節(jié)檢查了單項需求,確保它表述正確、無二義性、在范圍內(nèi)、可測試、可追蹤、不是鍍金需求,從而確定制有正確的原子需求才包含在需求規(guī)格說明中。
接下來,必須考慮需求規(guī)格說明是否完整,這意味著將規(guī)格說明作為一個整體來復(fù)查,確保應(yīng)該有的部分都有。
這種復(fù)查可以在任何時候進(jìn)行,而不只是在發(fā)布之前,它可以是一項持續(xù)的活動。
閱讀全文
posted @
2014-05-16 22:16 cheng 閱讀(1479) |
評論 (0) |
編輯 收藏
摘要: 需求來自于人,人們并非總能確定他們需要什么,并非總能解釋他們想要什么,需求也并非總是編寫地很小心,完整無二義。
需求工作的要點是要確保交給開發(fā)者的東西是準(zhǔn)確的、完整的、無二義的,陳述了真正的需求。任何不足都有違需求工作的初衷。開發(fā)者可以構(gòu)建任何東西,但他們首先必須知道他們必須構(gòu)建什么。
閱讀全文
posted @
2014-05-16 22:10 cheng 閱讀(1235) |
評論 (0) |
編輯 收藏
摘要: 如果產(chǎn)品有一項需求,要執(zhí)行某個功能或具備某種屬性,那么測試活動必須展示產(chǎn)品確實執(zhí)行了該項功能,或具備了該項期望的屬性。為了進(jìn)行這樣的測試,需求必須有一個測試基準(zhǔn),這樣測試者才能比較提交的產(chǎn)品和最初的需求。要注意的是,這里的驗收標(biāo)準(zhǔn)既不是測試,也不是對測試的設(shè)計,而是測試提交的產(chǎn)品必須采用的測試基準(zhǔn),是構(gòu)建測試用例的輸入信息。
閱讀全文
posted @
2014-05-10 11:54 cheng 閱讀(1156) |
評論 (1) |
編輯 收藏
摘要: 為什么所謂的‘非功能需求’也很重要?請考慮一個真實發(fā)生的故事:客戶拒絕了交付的服務(wù)臺軟件。功能是正確的,但客戶不想要它。為什么?因為客戶拒絕使用它,更愿意采用原來的人工過程。這就是需求團(tuán)隊幾乎沒有注意非功能性需求。
只所以需要這些非功能需求,不是因為它們是產(chǎn)品的功能活動(諸如計算、操作數(shù)據(jù)活動),而是因為用戶希望這些活動以特定的方式執(zhí)行,并達(dá)到特定的品質(zhì)。
例如,亞馬遜網(wǎng)站很容易導(dǎo)航,這讓客戶容易找到對象,它也很友好,讓你覺得自己是尊貴的顧客,你可以寫評論,通過購物伙伴和亞馬遜推薦得到指引,很容易查看和安排送貨,等等。
閱讀全文
posted @
2014-05-10 11:25 cheng 閱讀(1006) |
評論 (0) |
編輯 收藏
摘要: 通過產(chǎn)品用例(PUC)場景展示和確定了解決方案后,下面就需要PUC場景轉(zhuǎn)換到功能需求。
功能需求指明了產(chǎn)品必須做的事情,即產(chǎn)品為了滿足它存在的根本理由而必須執(zhí)行的一些動作。需求分析師理解了產(chǎn)品必需的功能后,他要用功能需求告訴開發(fā)者要構(gòu)建什么。
閱讀全文
posted @
2014-05-10 11:06 cheng 閱讀(1187) |
評論 (0) |
編輯 收藏
摘要: 當(dāng)需求人員和客戶之間針對需求溝通中的業(yè)務(wù)本質(zhì)問題達(dá)成一致時,接下來就是溝通和確定多少業(yè)務(wù)將通過產(chǎn)品來實現(xiàn)自動化。作為需求分析人員,需要在業(yè)務(wù)需求、包含的功能、用戶體驗、非功能需求、開發(fā)成本、技術(shù)可行性、限制條件這些因素之間取得平衡和折中來完成解決方案的確定和發(fā)布。
沒有公式化的方法能得到最佳的解決方案,需要實際過程中考慮和權(quán)衡。
閱讀全文
posted @
2014-05-06 22:26 cheng 閱讀(1068) |
評論 (0) |
編輯 收藏
摘要: "我知道這是我提出的,但這不是我想要的。”你不必在IT這行待很長時間就能聽到這句話,看著期待的笑容從開發(fā)者臉上消失,因為這事經(jīng)常發(fā)生。開發(fā)者交付了客戶提出的需求,但結(jié)果卻不能解決他們的業(yè)務(wù)問題。為什么?因為真正的問題從未闡明,所以從未正確理解。
在做需求調(diào)研和收集時如果聽到的都是客戶關(guān)于解決方案的想法,而不是描述背后要解決的問題,這可能是個好的解決方案,但更有可能的是,它受限于客戶的經(jīng)驗和想象力。而且,你不清楚它是否解決了正確的問題。所以,作為需求分析人員,你的任務(wù)就是解釋客戶所說的內(nèi)容,揭示它的本質(zhì)。
閱讀全文
posted @
2014-05-06 22:05 cheng 閱讀(1269) |
評論 (0) |
編輯 收藏
摘要: 不論哪種工作,試圖改變之前先對它有充分的理解,如果一頭沖進(jìn)去,對你要改變的東西幾乎沒有理解,就進(jìn)行‘改進(jìn)’,那么結(jié)果不如意也不奇怪。當(dāng)你開始理解原有的工作時,肯定會產(chǎn)生一些想法,知道如何改進(jìn)它。
這里探討的比較常用的Brow Cow模型和一些用于發(fā)現(xiàn)業(yè)務(wù)過程的調(diào)研方法,而實際過程中不可避免地需要多種調(diào)研技巧組合使用,具體情況需要具體應(yīng)對。
閱讀全文
posted @
2014-05-05 22:05 cheng 閱讀(2082) |
評論 (1) |
編輯 收藏
摘要: 項目啟動過程建立了工作的范圍,即要研究的業(yè)務(wù)領(lǐng)域,業(yè)務(wù)領(lǐng)域其中的一部分將通過預(yù)期的產(chǎn)品實現(xiàn)自動化。而實際上,這個工作范圍可能太大,難以作為一個單元進(jìn)行研究,正如吃東西之前先要將它切成小塊一樣,需要將工作范圍分解為一些可管理的部分,然后再來研究它以發(fā)現(xiàn)產(chǎn)品的需求。這里將需求過程中涉及到主要對象以及它們的分工界面通過一張關(guān)系圖來展示:
閱讀全文
posted @
2014-05-05 21:03 cheng 閱讀(1093) |
評論 (0) |
編輯 收藏
摘要: 從通信行業(yè)的產(chǎn)品工作到政府行業(yè)的項目工作,一直在和‘需求’打交道,不同的行業(yè)特點和項目環(huán)境需要針對性的需求發(fā)現(xiàn)和實現(xiàn)方法,但圍繞需求調(diào)研、分析、編寫、評審、驗證到需求交付這幾個過程基本是相通的。經(jīng)歷從瀑布型項目需求策略到迭代型需求策略的轉(zhuǎn)變和實踐過程,回過頭來看《軟件開發(fā)方法學(xué)-掌握需求過程》,進(jìn)行摘錄和梳理的同時,也加深和沉淀一些對需求的理解和認(rèn)識。以此片文章開始,分享一些讀書筆記:
閱讀全文
posted @
2014-05-05 20:49 cheng 閱讀(1297) |
評論 (0) |
編輯 收藏
摘要: 剛給大輝發(fā)完郵件準(zhǔn)備去上班,微信群里熱鬧不已,原來是pmp成績出來了,盡管考試完后心里基本有底,但聽老師說這次考試偏難,等在待結(jié)果出來的前夕,還是不免忐忑。
2013年年初報名直到2014年3月份才考試,倒也是好事,實際工作中的那些事和那些人,總能在復(fù)習(xí)的過程中讓自己反復(fù)思考和碰撞。而4m1p的成績單,算是給自己交了一份滿意的答卷,在這里簡單回顧一下,有興趣的同學(xué)可參考:
【復(fù)習(xí)歷程】:
1、 關(guān)于教材劃分(含:1本教材(2012版)、3套模擬題、1本輔導(dǎo)書),自己是按下面四部分來分批閱讀:
第1章 項目引論、第2章 組織影響和項目生命周期、第3章 項目管理過程
第4章 項目整合管理
第5章 項目范圍管理、第6章 項目時間管理、第7章 項目成本管理、第8章 項目質(zhì)量管理
第9章 項目人力資源管理、第10章 項目溝通管理、第11章 項目風(fēng)險管理、第12章 項目采購管理、
閱讀全文
posted @
2014-04-19 09:35 cheng 閱讀(1137) |
評論 (2) |
編輯 收藏
摘要: 這段時間以來的產(chǎn)品使用過程,界面性能和易用性成為關(guān)注的重點。相比運(yùn)營商項目不同,政企項目驗收過程相對簡單,沒有嚴(yán)格的測試用例,以是客戶組織的項目評審會,公司匯報階段進(jìn)展、客戶做業(yè)務(wù)測試的方式開展。
簡單回顧上線期間一些工作:
1)公司側(cè)提供《需求規(guī)格說明書》、《產(chǎn)品使用手冊》、《角色權(quán)限清單》
2)業(yè)務(wù)部門整理《用戶申請表》、《業(yè)務(wù)制度管理辦法》
3)業(yè)務(wù)部門組織上線前項目例會
3)業(yè)務(wù)部門發(fā)布系統(tǒng)上線公告
4)業(yè)務(wù)部門組織用戶培訓(xùn)
5)公司和業(yè)務(wù)部門提供產(chǎn)品使用支持,解答最終用戶的操作疑問、收集產(chǎn)品反饋。
閱讀全文
posted @
2014-03-26 22:05 cheng 閱讀(1362) |
評論 (3) |
編輯 收藏
摘要: 項目進(jìn)入試用階段,版本節(jié)奏也相對平緩,對于需求&開發(fā)&測試過程中的一些管理,分享一些個人體會,歡迎指正。開始正文之前,存在下面前置條件:
1.本輪版本要交付的功能及時間已已評估并與客戶達(dá)成一致,是以交付時間倒推來管理《需求規(guī)劃》和《研發(fā)計劃表》的方式。
2.團(tuán)隊資源:有測試組長,開發(fā)組長是臨時支持(同時兼顧其他項目)。
3.開發(fā)4人、測試2人、需求1人,迭代周期1~2周。
4.需求、開發(fā)和測試在一起辦公。
閱讀全文
posted @
2014-01-19 22:40 cheng 閱讀(1928) |
評論 (5) |
編輯 收藏
摘要: 項目接近尾聲,需求也逐漸收斂。面對需求變化頻繁、迭代版本周期較短的客觀情況,傳統(tǒng)模式已不能在此生搬硬套。雖現(xiàn)有的開發(fā)過程談不上正規(guī)敏捷,也算接近小步快跑的節(jié)奏。下面分‘需求開發(fā)&代碼開發(fā)、版本控制、版本發(fā)布、增量升級’幾個部分,記錄一些體會,歡迎指正:
(1)需求溝通&代碼開發(fā):
1、針對有可以復(fù)用的現(xiàn)有模塊時,和開發(fā)人員溝通主體思路,由開發(fā)人員著手開發(fā),開發(fā)人員在開發(fā)期間與需求人員充分溝通,碰到疑問及時澄清、解決。
2、針對沒有可復(fù)用的模塊且涉及較復(fù)雜的業(yè)務(wù)流程時,需求人員畫原型圖(緊急情況手繪草畫),開發(fā)人員按原型圖或草圖著手開發(fā)。
3、需求人員記錄開發(fā)過程中和開發(fā)人員、客戶溝通的需求變化點。
4、功能開發(fā)完成、客戶驗收后,及時補(bǔ)充到《需求規(guī)格說明書》。
(2)版本控制:
1、代碼提交前做比較再合入版本庫(嚴(yán)禁合入非自己修改的文件)。
2、合入代碼需填寫修改信息,新版本開發(fā)只填寫修改信息,優(yōu)化修改還需在BU
閱讀全文
posted @
2013-12-27 20:47 cheng 閱讀(1322) |
評論 (0) |
編輯 收藏
摘要: 5W1H原則:
what:用戶需求是什么,要做什么功能。
why:產(chǎn)生這個需求的背景是什么,原因是什么,能幫助用戶解決什么問題。
who:功能需求做出來了,哪些角色會參與使用。
where:功能需求的使用環(huán)境是什么(如:操作系統(tǒng)、瀏覽器環(huán)境,分辨率環(huán)境)。
when:功能需求何時交付(基于交付時間,考慮實現(xiàn)方案的選擇)。
閱讀全文
posted @
2013-12-01 16:30 cheng 閱讀(1822) |
評論 (0) |
編輯 收藏
摘要: 8、9、10三月,需求依舊爆棚,相比純業(yè)務(wù)功能的開發(fā),數(shù)據(jù)的匯聚、整理、分析、統(tǒng)計成為重點,具體細(xì)節(jié)不一一展開,按如下關(guān)鍵詞:任務(wù)計劃、項目溝通、項目流程、客戶匯報、業(yè)務(wù)關(guān)注、時間評估、管理筆記做一些筆錄,持續(xù)更新:
1、任務(wù)計劃:
1.決策前考慮充分,決策后不再懷疑。
2.任務(wù)精細(xì)、描述清晰,對內(nèi)分解針對到負(fù)責(zé)人、給外匯報針對產(chǎn)品功能。
3.計劃制定時,請成員預(yù)審任務(wù)量,再和開發(fā)、測試確認(rèn)時間,由成員承諾時間。
4.安排任務(wù)多人完成時,指定一個牽頭人。
5.大的需求,組織討論,小的需求,點對點溝通,最后要全部閘口到文檔。
閱讀全文
posted @
2013-11-09 22:48 cheng 閱讀(2183) |
評論 (3) |
編輯 收藏
摘要: 6、7兩月,時間很快,周末的時間來做些梳理、小結(jié),好的要繼承,不好的去改進(jìn)。下面,分日報管理、計劃管理、客戶管理、需求管理、客戶匯報、團(tuán)隊建設(shè)幾個方向,梳理一些記錄,歡迎指正。
1、日報管理
1.項目啟動會召開,介紹項目背景,時間計劃和項目目標(biāo),使團(tuán)隊成員有共同的認(rèn)識。讓團(tuán)隊成員之間互相介紹,以彼此熟悉。
2.根據(jù)收集和掌握的需求任務(wù),編寫項目計劃、安排日報(體現(xiàn)當(dāng)天任務(wù)在項目計劃中的完成百分比、當(dāng)天任務(wù)完成百分比)。首次發(fā)日報前,與日報匯總?cè)藛T點對點溝通編寫格式,注意事項,重在量化指標(biāo)。
3.根據(jù)日報匯總?cè)藛T匯總的內(nèi)容,了解各開發(fā)、測試成員的工作飽和度及工作質(zhì)量,以針對性安排后續(xù)新任務(wù)。
閱讀全文
posted @
2013-08-04 10:38 cheng 閱讀(1884) |
評論 (2) |
編輯 收藏