前言

知乎上有一個提問：在小公司編程是一種什么樣的體驗？

今天，我們就這個話題，一起來做個討論。

這里有沒有曾經(jīng)待過小公司或者現(xiàn)在正窩在小公司的程序員？如果有，這個問題相信你是最有發(fā)言權(quán)的。

一個軟件產(chǎn)品從前期的調(diào)研到中途的開發(fā)直至最后的發(fā)布環(huán)節(jié)，不知道整個鏈路跟蹤下來，你是否感覺這中間的每一步步驟你們都做的足夠規(guī)范？哪些環(huán)節(jié)是你忍不住想吐槽的？歡迎大家在評論區(qū)，展開討論。

我的回答

我自己曾經(jīng)經(jīng)歷過人數(shù)在0-50的小公司多年，后面也經(jīng)歷過人數(shù)超過10000的大公司，結(jié)合我自己的背景，來嘗試著回答一下這個問題。

我覺得在小公司編程，最大的優(yōu)勢當(dāng)然是靈活了，你要做一件事情，不用受太多條條框框的束縛，想干就干。開發(fā)同學(xué)的技術(shù)選型，也基本都是開發(fā)同學(xué)自己說了算，比較自由。

但缺點也比較明顯：沒有統(tǒng)一規(guī)范作為制約與指引，每個人基本都是按照自己的喜好來做事，本著怎么方便怎么來的原則。所以容易出現(xiàn)信息不對稱、溝通效率低下，最終也及其容易引發(fā)諸多安全事故，給公司造成不可估量的經(jīng)濟(jì)損失。

這里所謂的“規(guī)范”一詞，我認(rèn)為一般涉及如下三個方面：需求階段、設(shè)計階段、發(fā)布階段。

接下來，讓我們一一來拆解一下。

需求階段

正常來說，產(chǎn)品經(jīng)理在調(diào)研完相關(guān)需求后，經(jīng)過自己的整理，最終會形成一份完備的需求文檔。然后他會組織相關(guān)人等(開發(fā)、測試等)進(jìn)行第一輪的需求評審會議，目的也是想和大家對其一下本次需求的內(nèi)容事項。

如果需求內(nèi)容本身比較簡單、清晰明了，一般一輪會議就能敲定。開發(fā)理解了需求后，就可以進(jìn)入下一個階段，比如詳細(xì)設(shè)計。(遇到比較復(fù)雜的業(yè)務(wù)需求，可能需要經(jīng)歷多輪討論，經(jīng)過多次修訂后，這個需求的內(nèi)容才能真正確定下來)。

注意，上述一切都是在比較規(guī)范的前提下展開的。但往往很多小公司，是做不到按部就班按這個流程來走的。

有些小公司或許也有產(chǎn)品經(jīng)理一崗，有的產(chǎn)品經(jīng)理，前期也會簡單的整一份需求文檔。在文檔中，簡單的用純文字描述一下，本次待開發(fā)的需求內(nèi)容。至于拉會評審這一環(huán)節(jié)，是沒有的，他會選擇直接把整理好的文檔，丟給開發(fā)同學(xué)，然后附言一句：如果有問題，可以隨時找他溝通。

開發(fā)同學(xué)，拿到文檔，在還沒看之前，其實是很懵逼的，完全不清楚要干什么，里面有多少內(nèi)容。懷揣著忐忑的心情，只能硬著頭皮打開文檔。(我們固然希望里面的內(nèi)容越少越好，至少看下來，不要讓我們有猜測的成本)

事實證明還是我們一廂情愿了，那一段一段密密麻麻的文案，看的真心想吐，很多時候真的要多看幾遍，才能明白，文案想表達(dá)的意思。

整個文檔，肯定會有幾處地方，是不得電話或當(dāng)面溝通，才能明白它的意圖的。

如果你說這很糟糕啊，那我想跟你說的是，還有比這更甚的。有些需求壓根你就看不到文檔。產(chǎn)品同學(xué)就直接在聊天工具里面，密密麻麻、啰啰嗦嗦的把他想要的需求內(nèi)容，輸出給你，當(dāng)然最后也會附上那句熟悉的話：如果有不明白的地方，隨時可以找他溝通，24小時在線。

還有就是關(guān)于需求的迭代或功能變動(最可怕的是，完全推翻重做)，小公司基本都是某些人一兩句話的事情，然后就要開發(fā)評估工作量，并要求用最快速度上線。

編碼設(shè)計

在座的各位，不知道有沒有在編碼之前，有做詳細(xì)設(shè)計的習(xí)慣。大公司一般團(tuán)隊內(nèi)部都有規(guī)范，在編碼之前，要求先撰寫詳細(xì)設(shè)計文檔，等你寫完后，需要組織相關(guān)人等，進(jìn)行設(shè)計評審。評審過后，你才能進(jìn)入編碼工作。

當(dāng)然我相信，很多小公司，其實壓根就不存在這個環(huán)節(jié)。等整理完要開發(fā)的需求內(nèi)容之后，一般直接就開始擼代碼了，如果真的遇到問題，他們會停下腳步，做一番思考，實在搞不定，再找人尋求幫助。

這里有什么問題？大家不妨先思考一下。我覺得對于一些簡單的功能需求(工作量在3天以內(nèi)的)，直接擼代碼，也沒多大問題。為什么？因為這本身就說明，此次待開發(fā)的需求事項，內(nèi)容比較清楚、明確，產(chǎn)品本身確實只需要用一兩句話，就能描述清楚，開發(fā)同學(xué)，看了需求后，也胸有成竹，知道自己具體要干什么。

但，對于復(fù)雜的需求，比如工作量在1周甚至兩周以上的那種，不寫詳細(xì)設(shè)計文檔，我認(rèn)為可能會是個災(zāi)難。因為直接編碼，那么注定前期你根本沒時間經(jīng)過深思熟慮的思考，很多細(xì)節(jié)難免會有遺漏，沒考慮進(jìn)去的情況。一些方案選型，在沒有充分調(diào)研、預(yù)演的情況下，說用就用，后期做著做著又發(fā)現(xiàn)滿足不了，只能返工，推到重來。

而所有的這一切，如果前期，你都能在文檔中體現(xiàn)出來，然后在評審會議上一一與大家做介紹。那我相信，一些問題，一定能提前曝光出來，然后團(tuán)隊內(nèi)部，就可以提前做一番討論，最終，把相關(guān)方案給敲定下來，這樣后期的開發(fā)，就會順利很多，不會出現(xiàn)時不時卡頓、返工的情況。

發(fā)布階段

開發(fā)同學(xué)完成代碼編寫后，就進(jìn)入了提測階段。等測試同學(xué)按照他們的用例測試、驗證完后，最后項目就進(jìn)入了發(fā)布階段。

大公司一般對于發(fā)布這件事會比較謹(jǐn)慎，比如會有同學(xué)，需要撰寫相應(yīng)的發(fā)布計劃：上面需要詳細(xì)羅列清楚此次發(fā)布的內(nèi)容；發(fā)布的注意事項；同時也要做好回滾計劃，萬一新功能上線，影響了原有的功能，那需要立即代碼回滾。

發(fā)布也需要提交相關(guān)申請單，等相關(guān)審批人員審批通過后，然后在具體時間段，正式進(jìn)行發(fā)布。(根據(jù)自己公司的業(yè)務(wù)情況，避免在高峰期發(fā)布，影響業(yè)務(wù)穩(wěn)定性)
但一些小公司，這一塊就比較隨便了，發(fā)布是隨時隨地、一句話的事情。而且開發(fā)同學(xué)一般都有較大的自主權(quán)。

他們可謂超級管理員的存在，數(shù)據(jù)庫表結(jié)構(gòu)可以自己隨意新增、修改；線上數(shù)據(jù)也可以自己隨意訂正；想要發(fā)布，一個命令的事情，也完全不管什么業(yè)務(wù)高峰、低峰期，想發(fā)就發(fā)。
有時候，還蹭別人不注意，偷偷的發(fā)，當(dāng)不經(jīng)意發(fā)現(xiàn)自己寫的某個線上bug，做到神不知鬼不覺。

~END

本文內(nèi)容摘自公眾號：「陶朱公Boy」一文，歡迎關(guān)注與轉(zhuǎn)載，轉(zhuǎn)載請保留出處。