我這個人對分享特別感興趣，總是愛給人叨叨講東西。我也一直認為對於每乙個搞技術的同學 ，技術分享是應該始終伴隨在工作中的，就像吃飯上廁所一樣。然而最近我們團隊的分享卻各種難產，一種「沒有分享，地球也照樣轉」的感覺，這不禁讓我開始懷疑人生。
遙想起剛來北京，看到帝都有這麼好的分享氛圍而激動萬分，不辭辛勞不遠萬里去參加w3ctech組織的各種分享會，那份渴望至今還記憶猶新。第一次見到傳說中的周愛民老師，近在咫尺卻也不敢上前對話，只能投以深情的目光，那種感覺至今也還縈繞心間。
多年來我從被分享和主動分享中獲益良多。這裡並不打算闡述分享的種種好處，我相信讀者朋友是心知肚明的。例如老王自從愛上分享，變得能言善辯，多年的口吃都治好了。今天想要講的是我們團隊在組織分享中遇到的一些問題，以及我的一些思考。組織分享遠不是想象中的那麼簡單，這中間會面臨很多決策，思考的過程像是在做一道道選擇題。（我們有20個前端，在創業公司中應該算很多的了）
創業公司要不要搞技術分享
首先，問題的根節點，創業公司要不要搞技術分享。
如果答案是否，那本文就到此結束了...提出這個問題是因為我對此也有點猶豫。創業公司相對更忙一些，做專案是頭等大事，能留給做技術分享的時間並不多。而且我們的前端分散在各專案組，時間步調不一致。每次分享都零零散散來不到十個人，這對分享者來說有點潑涼水，畢竟人家吭哧吭哧準備了幾個晚上的內容。
以上是負面的因素。既然我們要打造公司的技術氛圍，那麼分享是一定要搞的。搞技術的人應該都有這樣的初心，要保持技術上的持續成長，而不是做了一年專案下來發現什麼都沒學到，我覺得新手尤其有這樣的訴求。如果公司沒有提供這樣成長的環境，那麼優秀的員工遲早會離開。所以分享還是要搞滴，我們需要做的是克服一下負面因素。
分享的時間該如何安排
人到不齊，那肯定是時間安排不合理嘍。所以，下乙個問題，分享的時間該如何安排。
首先糾結的乙個就是：分享是定期搞還是不定期隨機搞。如果定期搞，差不多就是一周或兩周一次。上面也提到了創業公司的時間充滿不穩定性，很難保證每次定期分享都到齊，而且分享者的壓力也比較大。我們目前技術比較高能做分享的也就四五個。就算輪著來，每人每月進行一次分享壓力還是蠻大，更何況這還是理想情況。
如果是不定期組織呢？我覺得會更不靠譜。人對於學習總是有惰性的，這是本性，憑興趣能堅持的是少數。如果不定期組織，很可能就會一推再推，最後分享就變成一件可有可無的事情。
綜合考慮還是覺得定期分享比較靠譜，至於分享壓力的問題，想辦法再權衡。
關於分享的時間，還有另一道選擇題：上班時間搞還是下班時間搞？之前我們是在上班時間，周五的下午來分享。考慮到盡量不占用大家的下班時間。這樣的弊端是，手頭有工作的同學可能就不能參加了。
其實我是傾向於下班時間來搞的，之前在奇舞團也是每週一下班開始分享會，每次參加的人都很多。我覺得稍微向上一點的程式設計師，在占用下班時間和學習知識之間，都會偏向後者。人的本性是貪圖舒適，但不能因此就把分享和聽講者的關係本末倒置，不能有「不好意思占用一下大家的時間，請大家參加一下分享會」這樣的想法出現，分享不是求人，分享者在無私付出，其他人要想學到東西就必須犧牲一些享樂時間。而且下班時間也更加自由寬鬆，大家能夠安心聽講不被工作打擾。
總的來說，我覺得定期、下班時間分享是比較好的選擇。
分享人的選定
接下來就是分享人的選定，小公司不像bat那樣有那麼多講師資源，一人一遍能輪一年。所以分享人的選定我們也面臨兩個選擇：自由申報、強制指定。
之前我們是本著自由申報的原則的，畢竟分享是乙個自由開放的事情。
最大的阻力還是人的惰性以及付出回報的不對等。做ppt、準備分享需要耗費一定的精力，這是時間成本。每次來聽的就零星幾個人，分享者成就感太低，寫篇部落格還幾千pv呢，扯著嗓子講半天就這點影響範圍，太不划算。再有就是程式設計師的主動性往往很低，性格使然吧。
自由申報的結果就是無人申報。要想定期分享，講師接不上肯定是很大的問題。
所以我也有考慮是否每次都提前指定好分享人。這種指定當然是大家在會上商量一下，誰好久沒分享了，下次該輪誰了，大家的意見達成一致就行，算半強制吧。我覺得有乙個共識是所有人需要達成的，分享人是付出勞動的，聽講者是佔了便宜的，所以自己也不能老佔便宜，也付出一點勞動回饋一下團隊。達成這一的共識後，就算是強制到你頭上了，你也應該沒有怨言。
這麼分析下來，我傾向於輪流分享，每次提前商議決定分享人。這樣就解決了講師資源不足的問題，講師足了，定期分享也就好搞了。
分享內容怎麼挑
團隊的技術水平參差不齊，分享內容的選擇也是需要考慮的乙個方面。由分享者自己把控應該是市面上的常規套路吧。這樣的缺點是太依賴分享者的個人品味，萬一他看走眼了選了乙個偏門主題，讓聽眾感覺浪費時間也是不好的。
常見的做法就是提前預告，讓大家先對分享內容有個了解，然後再決定參加與否，我覺得這是很好的。另外我還想到的乙個辦法是，可以成立類似「分享管理委員會」這樣乙個小組，事先對分享人的主題進行評審，對ppt以及內容進行先驗，這樣萬一發現主題不合適可以進行調整。這樣更好地提高了分享質量，保證了上座率。
關於分享內容，我們團隊還有這樣的嘗試，將分享內容進行分類，根據分類將分享會定為不同的級別：
由講師編寫「教材」，分享前端的基礎知識、公司的技術棧，要求新員工必須參加，類似培訓會。
常規的分享，但是要求內容必須是自己實踐的原創，能google到的內容不允許講。
技術邊緣的廣泛討論，內容形式不限。大概就是聊聊工作近況，聊聊行業話題之類，類似茶話會。
看上去好像挺規整，但是這個方案一直沒能落實。我覺得可能是以下原因吧：
編寫「教材」進行培訓，對講師的要求太高，而且是長期的。我們平時手上都有專案，根本騰不出這麼多時間寫教材、做培訓。而且對於新人，我覺得知道公司的技術棧自己去學就可以了，也沒有必要進行手把手的教學，都喂到嘴裡了，對丫太好了。
「不允許講」這4個字是很傷感情的，分享本來是自由開放的事情，有些內容即便網上可以搜到，再分享一下也沒什麼的，畢竟前端的知識太雜，沒有誰能面面俱到。本來講師就不積極，再加這個限制的結果就是沒人肯分享了。
茶話會倒是挺好，我覺得合併到分享會，作為末尾環節就可以了，也沒有單獨搞的必要。
所以，對於分享內容，我覺得還是簡單化，沒必要這麼多限制，還是交給分享者吧。（以前奇舞團的分享搞的那麼好，不知他們是否有委員會）
小公司的無奈
身在小公司，處處能感受到小公司的無奈。缺乏健全的管理，很多的不規範讓人著實頭疼。如果再因為弱智的管理嚴重影響開發效率的話，那將是更加的無法忍受！面對這些，弱小的我們又能怎麼樣呢，唯無奈爾。還值得慶幸的是小公司也有不少牛人，從他們身上能不斷提高自己。在貧瘠的草地上也會有強壯的牛羊，我想能在貧瘠的草地上...
大公司與小公司的區別（技術篇）
大公司 人才很多，有很多可用，做事比較靠譜，做每一件事都是盡量選擇乙個有充分能力和自信來完成這個任務的人來完成 因此一些菜鳥的鍛鍊機會有被剝奪了。簡單說 大公司選擇人做事，要符合充分必要條件。而小公司，則恰恰相反，它做事的原則可以或者說只能是 非充分必要條件。那麼如果在大公司，怎麼爭取機會呢？就得一...
小公司的專案交付
工控行業 物聯網行業 機械人行業軟體開發可聯絡我 從畢業起在一家小公司不知不覺已經工作了兩年，從開始的懵懵懂懂逐漸的對產品交付過程有了一些了解，最近負責了乙個專案的開發讓我感到在小公司要做好乙個專案真的很難，也深知是自己目前的水平還不夠，以下僅僅是根據自己目前的知識背景所提出的見解，可能有很多是錯的...