前言
知乎上有一個提問：在小公司程式設計是一種什麼樣的體驗？↓↓↓
今天，我們就這個話題，一起來做個討論。
這裡有沒有曾經待過小公司或者現在正窩在小公司的程式設計師？如果有，這個問題相信你是最有發言權的。
一個軟體產品從前期的調研到中途的開發直至最後的釋出環節，不知道整個鏈路跟蹤下來，你是否感覺這中間的每一步步驟你們都做的足夠規範？哪些環節是你忍不住想吐槽的？歡迎大家在評論區，展開討論。
我的回答
我自己曾經經歷過人數在0-50的小公司多年，後面也經歷過人數超過10000的大公司，結合我自己的背景，來嘗試著回答一下這個問題。我覺得在小公司程式設計，最大的優勢當然是靈活了，你要做一件事情，不用受太多條條框框的束縛，想幹就幹。開發同學的技術選型，也基本都是開發同學自己說了算，比較自由。
但缺點也比較明顯：沒有統一規範作為制約與指引，每個人基本都是按照自己的喜好來做事，本著怎麼方便怎麼來的原則。所以容易出現資訊不對稱、溝通效率低下，最終也及其容易引發諸多安全事故，給公司造成不可估量的經濟損失。
這裡所謂的“規範”一詞，我認為一般涉及如下三個方面：需求階段、設計階段、釋出階段。
接下來，讓我們一一來拆解一下。
需求階段
正常來說，產品經理在調研完相關需求後，經過自己的整理，最終會形成一份完備的需求文件。然後他會組織相關人等(開發、測試等)進行第一輪的需求評審會議，目的也是想和大家對其一下本次需求的內容事項。如果需求內容本身比較簡單、清晰明瞭，一般一輪會議就能敲定。開發理解了需求後，就可以進入下一個階段，比如詳細設計。(遇到比較複雜的業務需求，可能需要經歷多輪討論，經過多次修訂後，這個需求的內容才能真正確定下來)。
注意，上述一切都是在比較規範的前提下展開的。但往往很多小公司，是做不到按部就班按這個流程來走的。
有些小公司或許也有產品經理一崗，有的產品經理，前期也會簡單的整一份需求文件。在文件中，簡單的用純文字描述一下，本次待開發的需求內容。至於拉會評審這一環節，是沒有的，他會選擇直接把整理好的文件，丟給開發同學，然後附言一句：如果有問題，可以隨時找他溝通。
開發同學，拿到文件，在還沒看之前，其實是很懵逼的，完全不清楚要幹什麼，裡面有多少內容。懷揣著忐忑的心情，只能硬著頭皮開啟文件。(我們固然希望裡面的內容越少越好，至少看下來，不要讓我們有猜測的成本)
事實證明還是我們一廂情願了，那一段一段密密麻麻的文案，看的真心想吐，很多時候真的要多看幾遍，才能明白，文案想表達的意思。
整個文件，肯定會有幾處地方，是不得電話或當面溝通，才能明白它的意圖的。
如果你說這很糟糕啊，那我想跟你說的是，還有比這更甚的。有些需求壓根你就看不到文件。產品同學就直接在聊天工具裡面，密密麻麻、囉囉嗦嗦的把他想要的需求內容，輸出給你，當然最後也會附上那句熟悉的話：如果有不明白的地方，隨時可以找他溝通，24小時線上。
還有就是關於需求的迭代或功能變動(最可怕的是，完全推翻重做)，小公司基本都是某些人一兩句話的事情，然後就要開發評估工作量，並要求用最快速度上線。
編碼設計
在座的各位，不知道有沒有在編碼之前，有做詳細設計的習慣。大公司一般團隊內部都有規範，在編碼之前，要求先撰寫詳細設計文件，等你寫完後，需要組織相關人等，進行設計評審。評審過後，你才能進入編碼工作。
當然我相信，很多小公司，其實壓根就不存在這個環節。等整理完要開發的需求內容之後，一般直接就開始擼程式碼了，如果真的遇到問題，他們會停下腳步，做一番思考，實在搞不定，再找人尋求幫助。
這裡有什麼問題？大家不妨先思考一下。我覺得對於一些簡單的功能需求(工作量在3天以內的)，直接擼程式碼，也沒多大問題。為什麼？因為這本身就說明，此次待開發的需求事項，內容比較清楚、明確，產品本身確實只需要用一兩句話，就能描述清楚，開發同學，看了需求後，也胸有成竹，知道自己具體要幹什麼。
但，對於複雜的需求，比如工作量在1周甚至兩週以上的那種，不寫詳細設計文件，我認為可能會是個災難。因為直接編碼，那麼註定前期你根本沒時間經過深思熟慮的思考，很多細節難免會有遺漏，沒考慮進去的情況。一些方案選型，在沒有充分調研、預演的情況下，說用就用，後期做著做著又發現滿足不了，只能返工，推到重來。
而所有的這一切，如果前期，你都能在文件中體現出來，然後在評審會議上一一與大家做介紹。那我相信，一些問題，一定能提前曝光出來，然後團隊內部，就可以提前做一番討論，最終，把相關方案給敲定下來，這樣後期的開發，就會順利很多，不會出現時不時卡頓、返工的情況。
釋出階段
開發同學完成程式碼編寫後，就進入了提測階段。等測試同學按照他們的用例測試、驗證完後，最後專案就進入了釋出階段。大公司一般對於釋出這件事會比較謹慎，比如會有同學，需要撰寫相應的釋出計劃：上面需要詳細羅列清楚此次釋出的內容；釋出的注意事項；同時也要做好回滾計劃，萬一新功能上線，影響了原有的功能，那需要立即程式碼回滾。
釋出也需要提交相關申請單，等相關審批人員審批透過後，然後在具體時間段，正式進行釋出。(根據自己公司的業務情況，避免在高峰期釋出，影響業務穩定性)
但一些小公司，這一塊就比較隨便了，釋出是隨時隨地、一句話的事情。而且開發同學一般都有較大的自主權。
他們可謂超級管理員的存在，資料庫表結構可以自己隨意新增、修改；線上資料也可以自己隨意訂正；想要釋出，一個命令的事情，也完全不管什麼業務高峰、低峰期，想發就發。
有時候，還蹭別人不注意，偷偷的發，當不經意發現自己寫的某個線上bug，做到神不知鬼不覺。
~END
本文內容摘自公眾號：「陶朱公Boy」一文，歡迎關注與轉載，轉載請保留出處。
