最近團(tuán)隊(duì)在產(chǎn)品開發(fā)過程中溝通出現(xiàn)了很嚴(yán)重的問題，團(tuán)隊(duì)的小伙伴說(shuō)：“無(wú)法想象產(chǎn)品是什么樣子的?！?同時(shí)產(chǎn)品開發(fā)過程中也一直沒有可靠的發(fā)布日期。
蜂窩現(xiàn)在的產(chǎn)品開發(fā)方法，傳送門：
敏捷開發(fā)Scrum，一個(gè)教育創(chuàng)業(yè)團(tuán)隊(duì)的嘗試
團(tuán)隊(duì)不清楚自己的生產(chǎn)率，這是一件非?？膳碌氖?/h3>
1. 沒有可靠的發(fā)布日期
為什么？因?yàn)槿绻麍F(tuán)隊(duì)不清楚自己的生產(chǎn)率，那么產(chǎn)品負(fù)責(zé)人(Product Owner)就無(wú)法用可靠的發(fā)布日期來(lái)創(chuàng)建產(chǎn)品路線圖，也就沒有可靠的發(fā)布日期，產(chǎn)品無(wú)法到達(dá)用戶，所有的一切都是未經(jīng)驗(yàn)證的假設(shè)，那么產(chǎn)品就會(huì)失敗。
2. ScrumMaster無(wú)法確定大產(chǎn)品的發(fā)布日期
ScrumMatser會(huì)和每個(gè)產(chǎn)品負(fù)責(zé)人一起制定每次的sprint計(jì)劃，如果因?yàn)槟硞€(gè)產(chǎn)品總是沒有可靠的發(fā)布日期的話，那么在其他產(chǎn)品開始新的sprint計(jì)劃時(shí)，在遍歷產(chǎn)品backlog的時(shí)候，在需要多產(chǎn)品協(xié)作完成某個(gè)故事的時(shí)候，就無(wú)法指定故事的優(yōu)先級(jí)，因?yàn)樾枰獏f(xié)作的產(chǎn)品組還在沖刺上輪沒有完成的sprint計(jì)劃。
3. 無(wú)法跨產(chǎn)品協(xié)作完成某個(gè)故事
比如直播課有一個(gè)故事：“作為小孩，我需要在微信內(nèi)能進(jìn)入個(gè)人中心提交課前、課后作業(yè)，并且微信公眾賬號(hào)在特定時(shí)段會(huì)推送消息提醒孩子提交作業(yè)”的故事，這個(gè)故事就需要更新護(hù)照的用戶界面，增加數(shù)據(jù)庫(kù)中的表，添加產(chǎn)品邏輯。
而作為護(hù)照的產(chǎn)品負(fù)責(zé)人如果無(wú)法給出可靠的發(fā)布日期，就會(huì)給直播課的產(chǎn)品負(fù)責(zé)任人帶來(lái)了很大的困擾，沒有可靠的發(fā)布日期，就會(huì)造成ta們無(wú)法完成這個(gè)故事。因?yàn)閠a們?cè)诘葂xxx那邊完成他們的工作，那么另外一個(gè)產(chǎn)品也就會(huì)陷入產(chǎn)品發(fā)布延期的情況，這也會(huì)直接導(dǎo)致小伙伴的信心直線下降。每次發(fā)布，直播課的產(chǎn)品負(fù)責(zé)人都會(huì)問：“真的嗎？”
為什么會(huì)出現(xiàn)這樣的問題？
1. 第一個(gè)問題就是“完成”
我和團(tuán)隊(duì)的小伙伴沒有對(duì)“完成”有一致的定義。代碼被check in以后，故事就算完成？還是部署到服務(wù)器等待測(cè)試算完成？又或者是發(fā)布到達(dá)用戶？
1.1. 在跨產(chǎn)品協(xié)作完成某個(gè)故事卡片的時(shí)候由于對(duì)完成的定義不清晰，會(huì)直接拖慢產(chǎn)品發(fā)布日期。
比如護(hù)照有一個(gè)故事：“我們希望獲取用戶的微信用戶信息，頭像、昵稱..”的故事。這個(gè)故事卡片，我的理解是調(diào)用公眾平臺(tái)開發(fā)接口獲取用戶信息，我只需要封裝好API類庫(kù)，在需要用的時(shí)候調(diào)用數(shù)據(jù)即可。而對(duì)于直播課的小伙伴，在我告訴ta們開發(fā)完成的時(shí)候，ta們會(huì)直接進(jìn)入護(hù)照體驗(yàn)，問我為什么沒有用戶的信息呢？其實(shí)我也是n階懵逼。
而造成這樣的問題，其實(shí)是沒有站在用戶視角的角度去看待問題。那么到底怎么算完成？而Scrum的要求又是什么呢？
Scrum的要求（實(shí)際上也是敏捷軟件開發(fā)和精益制造的要求）: 把事情完全做完！達(dá)到可以交付的狀態(tài)！事情只做了一半，它的價(jià)值就是0（也許還會(huì)是負(fù)數(shù)）。
所以，基于護(hù)照和直播課來(lái)說(shuō)完成不是代碼被check in，不是完成測(cè)試，這樣的完成再來(lái)對(duì)比Scrum的要求，其實(shí)沒有產(chǎn)生任何價(jià)值。為什么做這個(gè)功能？難道不是為了解決用戶的某個(gè)問題嗎？如果不是，那么又為什么做這些沒意義的事情呢？
2. 第二個(gè)問題就是我對(duì)生產(chǎn)力的錯(cuò)誤預(yù)估
我總是按照理想的狀態(tài)下估算生產(chǎn)力?，F(xiàn)在想想，影響生產(chǎn)力的事情多了去了，而我又經(jīng)常能遇到很多事情。每次的預(yù)估都以為能完成這么多，而實(shí)際完成的工作與當(dāng)初預(yù)計(jì)的還是有區(qū)別。
因?yàn)槔硐氲墓ぷ鳡顟B(tài)是不受打擾、高效的一天。而現(xiàn)實(shí)是總是有突發(fā)情況，或者產(chǎn)品討論，又或者是產(chǎn)品出現(xiàn)了bug，又或者是一個(gè)電話的打擾。
所以跟小伙伴探討過后，我以后在評(píng)估生產(chǎn)力的時(shí)候會(huì)看過去的幾個(gè)sprint里面的生產(chǎn)力是多少，然后假定在下一個(gè)sprint里面生產(chǎn)力差不多不變的情況下然后在乘以一個(gè)意外系數(shù)(初步商定1.2)。
最后總結(jié)一下。更頻繁的使產(chǎn)品到達(dá)用戶，建立更短的產(chǎn)品反饋周期意味著更頻繁的用戶反饋，更意味著團(tuán)隊(duì)可以在錯(cuò)誤方向上花的時(shí)間更少，學(xué)習(xí)和改進(jìn)的速度更快?！睙o(wú)論遇到什么問題，我和小伙伴們都需要快速解決，加快這個(gè)循環(huán)快速迭代。
