產(chǎn)品業(yè)務(wù)文檔應(yīng)如何整理歸檔?
編輯導(dǎo)語:產(chǎn)品業(yè)務(wù)文檔應(yīng)該如何整理才能讓產(chǎn)品新人快速上手、讓文檔分類清晰從而能夠輕松地繼續(xù)查詢、讓研發(fā)新人了解過去的邏輯,保證迭代的質(zhì)量呢?本文作者為我們總結(jié)了三個(gè)步驟,幫助我們有效避免重復(fù)造輪子,提升文檔撰寫效率和價(jià)值。
在創(chuàng)業(yè)公司中,當(dāng)產(chǎn)品由v1.0版本逐漸穩(wěn)步迭代至2.0、3.0甚至更高版本時(shí),后續(xù)的迭代肯定不再是百分百在創(chuàng)造新的東西,而是在原有的基礎(chǔ)業(yè)務(wù)和數(shù)據(jù)架構(gòu)上進(jìn)行延伸和再創(chuàng)新。
那么在這種背景下,我們就很容易遇到下述3種問題:
問題一:產(chǎn)品新人上手難
剛?cè)肼毜漠a(chǎn)品新人對系統(tǒng)的架構(gòu)和業(yè)務(wù)邏輯不熟悉,這時(shí)往往需要產(chǎn)品leader花大量的時(shí)間去解答其提出的各類問題;同時(shí),新人也難以在零散的問答中快速把握整個(gè)系統(tǒng)全貌,很難快速開展新工作。
問題二:文檔分布零散、難以統(tǒng)一查詢
當(dāng)原來專門負(fù)責(zé)某模塊的同事離職后,產(chǎn)品小黑被派至接替他的迭代。但是此前該同事在很多版本都零散地迭代優(yōu)化過這一模塊的功能,文檔十分分散,難以進(jìn)行統(tǒng)一的查詢和追溯。
這就導(dǎo)致了小黑需要東一塊西一塊地自行拼湊文檔來了解這部分的邏輯,很大程度上耽誤了該模塊的迭代進(jìn)度。
問題三:研發(fā)新人不熟悉老邏輯,影響迭代質(zhì)量
新來的前端小綠在入職后的第一份迭代文檔中,發(fā)現(xiàn)產(chǎn)品文檔里很多處都只寫了個(gè)“遵循原邏輯”,而小綠對原來的老邏輯幾乎完全不清楚。
但是他又想著這一塊可能不需要做改動,在新版本中就直接忽略掉了這一部分,僅關(guān)注了列出需要改動的前端邏輯,結(jié)果導(dǎo)致最終代碼質(zhì)量不佳,從而影響了迭代質(zhì)量。
從上述3個(gè)場景來看,當(dāng)團(tuán)隊(duì)出現(xiàn)了人員變動(流失or擴(kuò)張)時(shí),我們就需要盡快對產(chǎn)品業(yè)務(wù)文檔進(jìn)行歸檔整理,以幫助新人快速上手并保證后續(xù)的迭代質(zhì)量。
解決了為什么要做產(chǎn)品業(yè)務(wù)文檔整理歸檔的問題,下面我們就步入正題:產(chǎn)品業(yè)務(wù)文檔應(yīng)該如何整理歸檔?
首先,我們要明確做這件事的核心思路:即把歸檔整理后的產(chǎn)出——「產(chǎn)品業(yè)務(wù)文檔知識庫」當(dāng)作一個(gè)產(chǎn)品來看。
核心用戶:產(chǎn)品和研發(fā)新人。
核心需求:
- 對系統(tǒng)很陌生,需要快速掌握系統(tǒng)全貌;
- 針對同一模塊的業(yè)務(wù)邏輯,需要支持統(tǒng)一集中查詢。
針對上述需求,我們可以按照下面3個(gè)步驟去逐一實(shí)現(xiàn):
一、梳理業(yè)務(wù)架構(gòu)圖
為了幫助新人快速掌握系統(tǒng)全貌,我們需要給出一個(gè)經(jīng)過產(chǎn)研團(tuán)隊(duì)共同確認(rèn)過后的業(yè)務(wù)架構(gòu)圖,幫助他們從系統(tǒng)地角度去看待產(chǎn)品,更清晰地了解產(chǎn)品各個(gè)模塊的劃分、價(jià)值以及模塊之間的交互關(guān)系。
與此同時(shí),根據(jù)業(yè)務(wù)架構(gòu)圖,我們也能更容易就接下來按模塊對文檔進(jìn)行分類達(dá)成共識。
下圖為一個(gè)脫敏之后的業(yè)務(wù)架構(gòu)圖,僅供大家參考:
二、迭代文檔整理
此前,我們都是以迭代版本號為主,對迭代文檔按時(shí)間順序進(jìn)行了縱向歸檔,但這樣卻不便于按模塊進(jìn)行橫向查詢。因此在第一步完成業(yè)務(wù)架構(gòu)圖梳理之后,我們需要把已有的迭代文檔按模塊進(jìn)行統(tǒng)一匯總。
下圖為筆者的迭代文檔歸類表格,僅供參考:
當(dāng)我們按模塊整理完迭代文檔之后,短期內(nèi)能夠方便產(chǎn)研新人按模塊對業(yè)務(wù)邏輯進(jìn)行熟悉。
但我們?nèi)耘f面臨著一個(gè)不可避免的問題:每一個(gè)迭代都較為零散,只是將文檔簡單匯總在一起,還是難以快速為業(yè)務(wù)有一個(gè)全局的掌握。為了解決這個(gè)問題,因此我們要完成接下來的第三步:模塊核心邏輯撰寫。
三、核心模塊邏輯撰寫
1. 劃分優(yōu)先級
在資源和時(shí)間有限的前提下,我們需要為核心模塊邏輯的撰寫劃分優(yōu)先級,以快速打造一個(gè)mvp知識庫給到產(chǎn)研新人,這里也同樣遵循了二八原則,用20%的時(shí)間完成80%價(jià)值的核心模塊邏輯撰寫,后續(xù)再逐步補(bǔ)全剩余優(yōu)先級略低的模塊文檔。
那么優(yōu)先級應(yīng)該怎么劃分呢?評估優(yōu)先級的角度和方法有很多,但是無論按照何等標(biāo)準(zhǔn)進(jìn)行劃分,我們都應(yīng)該圍繞我們的用戶和產(chǎn)品目標(biāo)來展開。
- 產(chǎn)品研發(fā)新人能夠上手開展工作之前,他們必須要了解的產(chǎn)品業(yè)務(wù)是哪些?
- 不熟悉哪些業(yè)務(wù)會大概率影響到他們的迭代質(zhì)量和進(jìn)度?
下面給出一種廣為認(rèn)知的評估思路:按照緊急/重要四象限來對模塊優(yōu)先級進(jìn)行劃分。這個(gè)方法想必大家已經(jīng)很熟悉了,此處不再贅述。
2. 邏輯撰寫
在確定好優(yōu)先級之后,我們就需要開始著手完成核心模塊的邏輯撰寫工作了。
下面給出筆者的撰寫框架,供大家參考:
1)版本記錄
從使用場景可以判斷得出,此處的文檔肯定后續(xù)會經(jīng)歷持續(xù)的完善和優(yōu)化,因此我們需要在每一篇核心模塊邏輯文檔的第一部分就加入該文檔的版本記錄。
文檔版本記錄需要包含文檔版本號、修改記錄、修改人及修改時(shí)間。
2)文檔正文
接下來就步入文檔的正文撰寫階段,此處給出筆者的正文撰寫結(jié)構(gòu)供大家參考,共包含4部分:需求場景、數(shù)據(jù)字典、業(yè)務(wù)邏輯和相關(guān)迭代文檔鏈接。
- 需求場景:旨在解決用戶在什么場景下的問題;
- 數(shù)據(jù)字典:對于陌生和特定的數(shù)據(jù)名詞進(jìn)行統(tǒng)一的概念講解;
- 業(yè)務(wù)邏輯:該模塊具體的業(yè)務(wù)邏輯;
- 相關(guān)迭代文檔鏈接:該模塊涉及到的迭代版本號及鏈接。
其中,需求場景、數(shù)據(jù)字典和相關(guān)迭代文檔鏈接都是建議盡可能完善的部分,而業(yè)務(wù)邏輯則可以按需優(yōu)先梳理出核心邏輯,剩余細(xì)節(jié)可以及時(shí)告知讀者在具體的迭代文檔中查看。
這樣,能夠有效避免重復(fù)造輪子,提升文檔撰寫效率和價(jià)值。
在完成上述3步之后,我們就上線了產(chǎn)品v1.0版本,交付給了產(chǎn)研新人第一版的產(chǎn)品業(yè)務(wù)文檔知識庫。
當(dāng)然,遵循pdca原則,我們需要通過監(jiān)測和反饋收集,對該知識庫進(jìn)行持續(xù)的優(yōu)化,以保證知識庫的效能最大化,而不是最終淪為一座沉睡的地下圖書館。
作者:冰冰醬;公眾號:setmefree
本文由 @冰冰醬 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)許可,禁止轉(zhuǎn)載
題圖來自Unsplash,基于CC0協(xié)議。
寫競品分析、PRD等產(chǎn)品工作的相關(guān)文檔,看似普通又基礎(chǔ),卻是產(chǎn)品經(jīng)理在追蹤行業(yè)情況、將需求落地為產(chǎn)品的過程中必不可少的步驟,并且將貫穿產(chǎn)品經(jīng)理的整個(gè)職業(yè)生涯。然而,0-2歲的產(chǎn)品新人普遍存在盲目套模板、文檔邏輯混亂等問題。
為了幫助產(chǎn)品新人快速掌握文檔撰寫基本功,這里推薦由起點(diǎn)學(xué)院聯(lián)合惠買集團(tuán)產(chǎn)品總監(jiān)@陳濱淋 老師打造的【15天掌握產(chǎn)品經(jīng)理必備文檔】學(xué)習(xí)計(jì)劃。從實(shí)例出發(fā),帶你高強(qiáng)度系統(tǒng)性學(xué)習(xí)11大類常用的產(chǎn)品工作文檔,快速幫你規(guī)范化日常文檔,提升工作效率>>>http://996.pm/71GE5
很贊!謝謝分享
嘿嘿謝謝????
寫的很棒,能看出作者進(jìn)行了深入的思考和研究,很受用,i了i了。
>。<謝謝大佬