“我有一個改變世界的IDEA，就等你來寫代碼了，不談錢，給你股份！”

“我已經談好機構愿意投資我了，就差app跑數據了，你照那誰抄一個就行！”

“在新頁面上加兩個按鈕，很簡單的，今天能搞定吧？”

“我有了個新想法，絕對顛覆傳統商業模式，咱試試唄！”

“剛聽朋友說了，咱的APP用XXXX框架就行，你那套不行了！”

“這五版都不好，還是改回第一版吧！”

……

程序員不易，CTO更苦，那些擺在技術面前的坑，正在變著花樣的洶涌而來，總有一款適合你。

“新需求”相信已經成為技術研發不得不面對的十宗罪之首了。

改完bug新需求來了，新需求做完發現了bug……無限循環，相信這是很多程序員的現狀。沒有準時下班，沒有雙休，如果捎帶手做了運維，那就是7*24小時的命，所以，別總說我們沒有妹子了。

在創業環境下的用戶需求是多變的，尤其是一個全新的產品、服務。需求的驗證和迭代過程，在一個有計劃、頭腦清晰的CEO手中是可以快速推進的，但在一個完全不懂技術、聽風就是雨的CEO面前，那就是一場噩夢了。

他們還總是用代碼提交的數量作為評價工作量的標準，要知道，有時候一個關鍵問題的解決或是一個隱秘bug的篩查，可能會花費大量時間，說不好一天就搭進去。如果真的說“提交多少代碼=做了多少工作”，那研發個自動提交代碼的程序對于技術來說不算難，這么互相騙下去，雙方都有損失，為什么不能多一些理解和溝通呢。

所以，請不要單純拿延期和工作量來評價技術研發工作了。

新需求，可以說是技術的日常，不是不能加，而是要加的合理。

你以為加一個按鈕是UI設計好、改改界面就能搞定的？一個簡單的調整可能牽一發而動全身，影響了前端不說，甚至連后臺邏輯都要改。

舉個栗子，做平臺鏈接供需雙方，想加一個聊天功能，雖然界面看上去是一個按鈕的事兒，而且聊天功能現在很多產品都實現了，開源也有，但是否能直接拿來和現有業務邏輯合并？是一對一聊，還是多人群聊？每換一個或加一個人進來，之前的記錄是否保留？如何避免雙方聊上之后互換聯系方式最終跑單等等，需要非常全面的考慮，不是說拿來copy一下就能直接上的。

最恐怖的是，老板想加一個搜索功能，需求就是“要像百度一樣”……

不懂技術沒關系，不了解背后的邏輯和復雜程度也沒關系，但新需求能否溝通下再做結論？別讓技術總是最后一個知道，連產品經理都蒙逼，連需求文檔都沒有的情況下，就讓技術去實現，這可真不是晚上加會班的事兒。

什么？下禮拜上線？呵呵噠~

用人不疑，相信是很多老板掛在嘴邊的原則，但是否能落實到行為上就另說了。

不怕一無所知，就怕一知半解，自以為懂點技術就指手畫腳，聽風就是雨，看到刷屏級H5就想復制一個，看到外面有人說react混合開發成本低就想試試，看到小程序流行就想追個熱點摻和一下。

這還是外行想要追求新突破提出的建議，一般內部交流、討論下就能說服老板，但就怕遇上一知半解自以為懂代碼恨不得自己下手寫的。

CEO的本職是什么？找錢、找人、搞定公司發展，為未來謀劃，而不是把那些細枝末節都強加在自己身上。

的確，有的技術可能真的不如CEO專業，能力差的可以替換，有潛力的可以培養，否則強的只是CEO一人，于整個團隊無益。

一個人做不完所有事，兼顧不了所有細節，CEO要有包容的胸懷，信任他就交給他去做，可以提出建議、方法，但不要過分介入、干涉。比起直接干預，可以請個外部技術大牛，換一個角度幫助團隊發現問題、解決問題，會令所有人都信服。

既然專業事交給專業人去做，那CEO還有必要懂點技術么？

叨叨曾遇到過為了與程序員交流更順暢而去學習技術的CEO，精神可嘉，但更重要的，還是看心態。

很多被技術坑過的CEO都會想懂些代碼，但一方面做個全面的創業者，另一方面學習技術并實踐，對于非技術背景的CEO是不現實的。但基礎的了解還是有些必要，最起碼的要知道PHP和JAVA是不同語言，分析師、架構師、IOS/Android/PC端、運維、前端、后臺、測試分屬不同專業領域、有著不同崗位職責，不要一股腦以為有個CTO就夠了。

另外，了解一些技術并不是為了干涉程序員的具體工作，而是能夠從更全面的角度分析產品，避免提出那些不合理的需求，提高團隊工作效率。其實對于“懂點技術”，更多的可以是對產品經理的要求。

比如騰訊，非常提倡技術出身的產品經理，一方面善于發現、篩選用戶需求，另一方面懂得在技術實現與用戶需求之間找到平衡點，比如騰訊創始人，他就是這樣一位技術出身的產品經理，還做了CEO。

聊完專業的，再聊聊日常。

程序員的日常和電腦有著不可分割的密切關系，但這并不意味著技術就會修電腦。有多少技術沒幫助運營妹子修過電腦、裝過軟件？開始可能會樂此不疲，但時間久了也是會煩的，更不用說在梳理邏輯的時候被打擾，真的是@#￥！&*#￥&@*

不只是程序員，被誤解最深的恐怕就是CTO了。

很多不懂技術的老板對CTO的定位就是“萬能魔術師”，仿佛一個好的IDEA只要有了CTO的加入就能改變世界、改變全人類。

但事實上呢？

知乎上“程序員pilot”的回答很有意思，“頂著CTO的名頭干著技術組長兼打雜的事情，包括但不限于招聘，裁員，拉網線，查機房，裝系統，重裝系統，討論方案，推翻方案，談合同，簽合同，哄手下，罵手下，被老板哄，挨老板罵，確定進度，拖延進度，重新定進度，取悅老板，揣摩老板，寫畫餅郵件，寫辭職郵件等工作，工作內容一般不包括編碼。”

所以，對老板而言，只要他們認為目前技術團隊不夠好，不夠給力，不夠預期，就認為自己缺CTO。

幾點建議，供大家參考：

1.一紙協議永遠比承諾更靠譜。不要覺得股權無所謂，該爭取的不要礙于情分、面子而覺得不好開口，要知道，只有明確了利益歸屬，才好綁在一起加油干。

協議中要明確約定公司協議主體和性質、股權比例、出資方式和期限、回購條款等等，這類注意事項搜一下都能找到，不再贅述。

2. 警惕公司改革。那位被坑了7年的技術合伙人就是在不知不覺中被CEO將股份轉移至自己名下，所以，和誰簽的協議一定要明確，并且信息可以在工商備案中查到具體信息。

3.明確退出條件。無論項目上市、被并購，還是中途離開、被離開，都要明確你會得到什么、如何得到、各自的前提是什么。

4.明確工作成果的所屬權。相信沒人愿意最終對簿公堂，但萬一出現這種情況怎么辦？當對方一口否認工作成果屬于你，將你貶得對公司毫無價值怎么辦？所以，必須留有“證明工作成果屬于你”的證據，比如在你開發的代碼、軟件里面埋幾個彩蛋，只有你自己知道彩蛋的出現方法，前提一定是不影響業務正常發展、不惡意留后門。友情提示：翻墻證據無效。

至于其他的坑，比如重構別人代碼、鉆到N年前別人寫的代碼里修bug、和蘋果審核撕逼、舊系統沒有源代碼等等，篇幅有限，下次再聊。

程序員的坑雖多，但遠沒到絕望的程度。

更絕望的是，明明知道是坑，卻還是要努力完成它……

向每一位戰斗在代碼一線的程序員致敬，祝早日找到妹子！