在家辦公的我，砍需求砍得更狠了
最近全民開(kāi)始了在家辦公模式，目前看來(lái)這種模式還要持續(xù)很長(zhǎng)的一段時(shí)間，至少要到3月份才能有可能回到公司辦公了。
其實(shí)，在哪辦公對(duì)于程序員來(lái)說(shuō)其實(shí)差別并不是很大，無(wú)非就是在哪敲代碼而已。
時(shí)間很快，從在家辦公開(kāi)始，一直想說(shuō)點(diǎn)什么，但是一直都沒(méi)落筆，現(xiàn)在已經(jīng)兩周多了，是時(shí)候?qū)扅c(diǎn)什么了，這兩周給我最大的感受有兩點(diǎn)。
一、會(huì)議比以前多了
在家辦公之后，每天都是各種電話會(huì)議、視頻會(huì)議、語(yǔ)音會(huì)議等等。
在公司辦公的時(shí)候，只有有一些大事，如需求評(píng)審、設(shè)計(jì)評(píng)審之類的才需要開(kāi)會(huì)，還有就是項(xiàng)目晨會(huì)或者團(tuán)隊(duì)周會(huì)之類的。
但是在家辦公之后，每天會(huì)被拉著參加各種會(huì)議，以下是我某一天的會(huì)議日程：
從早上9點(diǎn)，到晚上8點(diǎn)，一直都有會(huì)議，甚至有時(shí)候還有很多會(huì)議時(shí)間是重合的。
這時(shí)候就體現(xiàn)出在家辦公的好處了，我就可以同時(shí)參加多個(gè)會(huì)議。釘釘視頻會(huì)議開(kāi)一個(gè)，手機(jī)電話會(huì)議開(kāi)一個(gè)。不需要我的時(shí)候我就把我的麥禁掉。
比如有些會(huì)議，我只是負(fù)責(zé)把相關(guān)人員拉在一起，大家討論下，最終得到一個(gè)結(jié)果，我發(fā)個(gè)郵件出來(lái)就好了。這種我就不需要發(fā)言，只需要聽(tīng)著就行了。
還有的一些會(huì)議，如技術(shù)方案評(píng)審之類的，可能會(huì)議中只有一小部分是和我相關(guān)的，那么我只需要再討論這部分的時(shí)候開(kāi)麥發(fā)言就好了。
如果是在公司開(kāi)會(huì)，是不可能同時(shí)進(jìn)行的，這反而大大提升了開(kāi)會(huì)的效率。
二、砍需求砍得更狠了
我萬(wàn)萬(wàn)沒(méi)想到在家辦公帶來(lái)的一個(gè)變化，也不知道是好是壞，那就是：我砍需求砍得更狠了!
相信很多一線開(kāi)發(fā)人員都和我一樣，每天都會(huì)接到各種各樣的需求，而給我們提需求的人也是形形色色。
而各種奇葩需求更是讓我們哭笑不得，但是大多數(shù)程序員在做過(guò)一些心理斗爭(zhēng)之后都會(huì)想辦法解決這個(gè)需求。
其實(shí)，所有需求都需要解決的，這沒(méi)錯(cuò)，但是我還是給大家提一個(gè)建議：先用嘴解決需求，不行的話再用代碼解決。
在家辦公之后的這兩周，我負(fù)責(zé)的一個(gè)項(xiàng)目目前正處于聯(lián)調(diào)階段，但是這個(gè)階段還是會(huì)接到一些需求，這其中有些是產(chǎn)品經(jīng)理提出來(lái)的需求變更、新增需求等，還有些是合作方技術(shù)提出來(lái)的有些技術(shù)需求，如要求接口同步、要求多一次系統(tǒng)交互、甚至要求ERROR_CODE的格式等等。
因?yàn)槲邑?fù)責(zé)的這個(gè)項(xiàng)目是個(gè)新產(chǎn)品上線，完全初期，要盡快上線接收用戶檢驗(yàn)，沒(méi)必要一開(kāi)始就搞的特別復(fù)雜。所以對(duì)于這些需求，目前的狀態(tài)是能砍則砍，不能砍的先用最簡(jiǎn)單的方式先上去。
所以這兩周來(lái)，我越發(fā)的發(fā)現(xiàn)我砍需求砍的原來(lái)越狠了，甚至有一次，我團(tuán)隊(duì)的另外一個(gè)同學(xué)問(wèn)我一個(gè)單據(jù)的狀態(tài)問(wèn)題，我隨口問(wèn)了下問(wèn)這個(gè)干什么，他說(shuō)產(chǎn)品經(jīng)理讓他實(shí)現(xiàn)個(gè)小需求。
我了解下來(lái)之后，就拉他和產(chǎn)品經(jīng)理一起開(kāi)了個(gè)電話會(huì)議，然后動(dòng)之以情，曉之以理，把"不合理"的地方都砍了，把"能優(yōu)化"的也都優(yōu)化了。
本來(lái)需要2-3個(gè)系統(tǒng)合作才能實(shí)現(xiàn)的一個(gè)查詢功能，經(jīng)過(guò)調(diào)整之后，變成只需要查詢一個(gè)系統(tǒng)就可以實(shí)現(xiàn)。這既減少了系統(tǒng)交互、降低了風(fēng)險(xiǎn)，又減少了用戶的理解成本。何樂(lè)而不為呢?
我始終認(rèn)為，啥需求都接的程序員，一定不是個(gè)好程序員!但有些需求，總要有人先站出來(lái)砍!就算最后沒(méi)砍掉，我認(rèn)為也是有好處的：
1、可以讓我們理解這個(gè)需求背后的東西。之所以最終沒(méi)砍掉，肯定是有很多原因在的，只有在討論的過(guò)程中我們才能更多的理解這些背后的原因。否則最后可能只是你毫不情愿的實(shí)現(xiàn)了一個(gè)你認(rèn)為"垃圾"的功能，但是實(shí)際上可能這個(gè)需求背后有一些你不理解的原因。如合規(guī)風(fēng)險(xiǎn)、法務(wù)風(fēng)險(xiǎn)等等。
2、表達(dá)一個(gè)我們的態(tài)度。我覺(jué)得，作為一個(gè)程序員，態(tài)度還是很重要的。比如有些惡心的或者需求，我們可以"迫于壓力"去實(shí)現(xiàn)，但是我們還是有權(quán)利表達(dá)我們"不認(rèn)可"的態(tài)度。而且這個(gè)表達(dá)的過(guò)程，也是你樹(shù)立話語(yǔ)權(quán)的一個(gè)過(guò)程。
我砍需求有很多考慮，但是減少工作量絕對(duì)不是最重要的。最近幾天砍需求，我大概總結(jié)了一下，用到的很簡(jiǎn)單的幾個(gè)架構(gòu)設(shè)計(jì)原則：
- 1、Keep It Simple ， Stupid
- 2、Open/Closed Principle
- 3、Single Responsibility Principle
- 4、Minimize Coupling
- 5、Avoid Premature Optimization
簡(jiǎn)單點(diǎn)，無(wú)論是系統(tǒng)功能，還是系統(tǒng)代碼，最怕的就是復(fù)雜。越復(fù)雜的功能用戶越不喜歡，所以，如果一個(gè)功能很復(fù)雜，那大概率是個(gè)垃圾功能。
系統(tǒng)實(shí)現(xiàn)上面也是，如果一個(gè)功能，實(shí)現(xiàn)起來(lái)很復(fù)雜，那大概率會(huì)存在很多問(wèn)題。而解決這些問(wèn)題最好的辦法就是提前減少?gòu)?fù)雜度。
除此之外，要明確知道系統(tǒng)邊界以及系統(tǒng)關(guān)系，實(shí)現(xiàn)一個(gè)功能可能有100種方式，但是到底由誰(shuí)來(lái)實(shí)現(xiàn)比較合適?如何才能降低系統(tǒng)間的耦合度?如何實(shí)現(xiàn)才有更強(qiáng)的可擴(kuò)展性和可維護(hù)性?這些都是要考量的。
還有比較重要的一點(diǎn)，在初期，不要過(guò)早的做所謂的優(yōu)化。記住：Done is Better than Perfect，
我們?nèi)粘Ｒ拥男枨笾校幸恍┦菢I(yè)務(wù)需求，還有一些是技術(shù)需求。那么，有什么好的原則或者辦法可以參考呢?到底哪些能砍，哪些不能砍?到底應(yīng)該怎么砍呢?
關(guān)于這些問(wèn)題，我后面會(huì)寫(xiě)一篇詳細(xì)的方法論，結(jié)合我工作中的例子，論如何砍需求。大家如果有更好的建議，或者對(duì)這個(gè)話題感興趣，可以給我留言，歡迎探討!
愿這個(gè)世界沒(méi)有需求變更!~
