<output id="dbzbb"><cite id="dbzbb"><progress id="dbzbb"></progress></cite></output>

<output id="dbzbb"></output>

              關愛程序員,人人有責!

              2017-08-08 13:49:31      訪問:

              【內容導讀】 我有一個改變世界的IDEA,就等你來寫代碼了,不談錢,給你股份!我已經談好機構愿意投資我了,就差app跑數據了,你照那誰抄一個就行!在新

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

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

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

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

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

              “這五版都不好,還是改回第一版吧!”

              ……

               

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

              1.

              延期?你以為我想!

               
               
               

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

               

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

               

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

               

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

               

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

               

              2.

              需求不是你想加,想加就能加!

               
               

              ——“新加個導航功能,就百度地圖那樣的,下禮拜能上線么?”

              ——“sorry,不太可能~”

               

              ——“這么簡單都不行,抄你都不會?”

              ——“簡單你來?”

               

              ——“我要會還用你!”

              ——“……”

               

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

               

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

               

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

               

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

               

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

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

              3.

              用人不疑,略懂代碼,

              不意味著可以指手畫腳

               
               
               

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

               

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

               

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

               

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

               

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

               

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

              4. 

              論CEO要不要懂點技術

               
               

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

               

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

               

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

               

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

               

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

              5. 

              程序員不是修打印機的,謝謝!

               
               
               

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

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

               

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

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

               

              但事實上呢?

               

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

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

               

              幾點建議,供大家參考:

               

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

               

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

               

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

               

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

               

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

               

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

               

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

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

               

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

              關鍵詞:關愛程序員,人人有責!_定制開發知識_森普信息集團程序員 人人
              上一篇:濟南軟件開發:軟件開發經驗到底是什么?
              下一篇:最后一頁
              先锋影音资源站

              <output id="dbzbb"><cite id="dbzbb"><progress id="dbzbb"></progress></cite></output>

              <output id="dbzbb"></output>

                          黄色视频免费|x3x537 菠萝蜜视频在线观看|zxv788 狼色精品人妻在线视频网站|3xv144 99热99|vx4346 天天干夜夜操|zvx206 老司机带带我精彩免费|x2v175 久久久无码精品亚洲日韩麻豆|zvz592 黄色视频免费|2zv617 免费AV在线|xz236 山外人精品影院|vv254 天天射综合网|zvx941 久草av|v2z417 山外人精品影院|xzv469 h视频在线观看|3zx318 激情五月网|zx3799 黄网站免费|zzx492 三级片免费看|v3z980 97人妻一区二区精品免费|xvv664 黄色视频免费|1vz317 亚洲老熟女|xz1248 精品国产伦一区二区三区在线观看|zvz300 国产精品一区成人精品|v1x788 免费的黄色网站|z22311 97人妻精品全国免费视频|zxv786 一本久道久久丁香狠狠躁|x2v269 天天干天天日|vxx227 青草视频在线观看|2xz935 中文字幕av|xx2290 亚洲男人天堂|zvv452 欧美日韩国产|x0x827 山外人精品影院|xvx733 五月天色婷婷|1zz122