-
1 # 傑傑職場
-
2 # 網際網路臨時工
1.產品經理啥都不懂,估計就是剛學的或者就是沒有做過產品的(我們公司之前就來了一個,後來暴露了)。
2.技術負責人?哈哈,這我很開心了。現在想想就覺得好笑,我畢業之後去了一家創業公司,公司開發人員共2人(IOS 程式設計師+Android本人),公司資料、後臺等外包。我去了一個星期發現公司的技術總監居然只是一個僅會PS的殺馬特(扎頭髮/裝設計師)。不僅如此,沒有產品資料、文件、原型,也沒有UI。我直接辭職了。還有一個案例我朋友公司一個iOS的普通程式設計師因為是公司第一批員工升職為開發部負責人。由於急於表現,多次在公司專案需求變動中都承諾下來,以至於開發跟需求脫節(沒法跟上需求變動)體現在改了刪,刪了改,改了加。導致公司在拉投資開招商會的時候專案演示掉鏈子,以至公司基本快倒閉了。
3.至於外包?!一定要有完整的需求,不然專案大都有問題。之前參與的外包至少%50的都有問題,雖然都交付。
總之,技術/專案負責人一定要專業,專案需求一定要完整清晰!
-
3 # 誰若傾城
前期沒有做好系統的架構,目前解決問題最重要。招一個架構師和全棧工程師(資金有限了就讓全棧把架構的活也幹了),根據業務需求先做好架構,然後前端和後臺先暫時獨立開發修改匹配,提前統一標準。標準統一後,開發完成後再前後臺對接測試等。PS:那個資料庫出身的,開了是損失,畢竟從頭到尾ta都參與了,後面對接各個環節也方便。就當培養新員工了,不過一年半的時間,說實話,學費有些貴。得讓ta加班出產品賺回來學費。
-
4 # 流浪劍客26
首先找外包只是做專案的第一期(功能沒問題就ok),開發出來看投放市場的情況,情況樂觀就可以考慮招人維護更新迭代一些功能上去,再過一階段,流量和併發上來就必須招一個專業的團隊來了,系統重構、叢集、高可用。創業一步一步走向成功,產品技術也一步一步走向成熟,每一步都需要共同的努力、信任和理解。一個好的團隊絕不是死加班,也不是鬆散的管理制度,用人很重要!最後補充一點,不管處於創業階段還是成熟階段,技術人員最好能相對穩定,不要頻繁換cto和小組長。
-
5 # 鋼鐵茶几
您這技術負責人有問題,這種後臺對接不能對接應該很早就知道,前期業務需求理解沒?介面定義沒?里程碑計劃每個節點的成果呢?時間節點控制沒?都做大半年才告知,前面時間都在滑水啊!
-
6 # 喝酸奶還要舔蓋兒
主要是沒找對人,找人做App最好是熟人推薦的,或者比較瞭解的外包公司,無論什麼樣的方式都要定期追蹤進度,一來把關進度有沒有走偏並及時發現問題,二來也可以督促對方,本人獨立完成過從後端介面到IOS和Android整個專案並已上線運營,如有更多疑問可留言。
-
7 # 一刻科技
首先要反思的是:公司的產品需求是否明確?中途需求變更有多少?個人覺得無論自己開發還是外包各自都有大半年時間,如果需求明確,需求變更可控的話,不應該出現自己做的系統需要推倒重來,外包的達不到上線要求,還有就是您可能需要一個專案經理或者產品經理來進行專案管控了,放過那個可憐的技術負責人讓他迴歸到他熟悉的領域去做事情…
-
8 # 為民做主與權利什麼區別
規劃儘量半年至少上線一個部分功能版本。app可以先開發一個android的,比如ios可以外包。
後臺不能外包,招2個人。都要迭代開發,就是先做加法設計出來,然後做減法,做最小可用功能,先上線逐步可用,合入功能。
不過後臺架構要有後期一定可擴充套件性,把這個技術負責人開了,去你外包的公司,挖個有水平的後臺開發人品可信的來整體負責。
-
9 # 偶為英音狂v
技術負責人問題很大,外包和自己做都不行那要他幹什麼用的?自己做能不能做,需要什麼人和資源,這個技術負責人要確定的。外包要評估方案,參與架構把握進度。最後我覺得這個負責人也是背鍋的,因為沒有個專案經理,最好懂技術和規劃,當然再配個產品就更好了。
說外包不靠譜的,其實很大還是自己的原因,需求老是變,然後不具備篩選供應商的能力,進度把控不行等。外包管理是門學問。我以前外包專案給印度和俄羅斯,自己跟都可以上線。當然外包的程式碼質量什麼的,自己懂一點去把控。
-
10 # 王冬791
問題出在沒有找對人,開發流程也不對,一個專案必須有一個能夠把控全域性的人,他對業務,系統架構,前端後端都有比較深入的瞭解,還有就是這種創業型專案,應該採用快速迭代的方式,分成很多小的功能模組進行進度管理和交付,前端做完了後端合不上,說明技術部負責的完全是外行,在蒙你不懂
-
11 # jdk2020
很想幫你,但不知道怎麼幫你。你的技術人員和外包公司都是坑貨,你太容易相信他們了。至少說,如果技術不行或者舊程式碼不行,應該一開始就能評估出來。建議你找真正懂技術的人好好聊聊。
-
12 # myNameIsBug
專案開發就像蓋樓一樣,如果一開始地基打不好,後面怎麼蓋都是有問題的。如果一開始架構設計不規範,後面很有可能越做坑會越大。外包公司厲不厲害並不重要,歸根到底,你專案的質量還是取決於直接參與開發的那幾個人,如果專案不大,每個端的開發人員都是獨立開發,技術不行的話,搞砸一個專案那是分分鐘的事
-
13 # 全球奇趣
我本人是搞java 的,我覺得會出現在後期前後端無法接通等等問題的原因在你所說的負責人,前後端根本就沒有把握好,缺少了溝通和產品,技術上我不相信不管你們公司還是外包都做不出來的東西,還是你們的負責人問題很大,估計都不知道自己在幹什麼。
-
14 # 特斯拉中國區總監
埠無法接入.......不可能是那個負責人說出來的,如果他是DBA的話,有可能說出這樣的話,我姑且算是你聽錯了,你們的問題應該是介面沒調通,從你這段描述來說,你是公司的中高層負責人,而且你的公司規模不大,更重要的是你不懂技術,如果一個公司沒有一整套的配備:Java後臺(/.net等),前端,DBA,運維,測試,產品.....這個是最少的一個團隊配置,如果你是Android的WAP端的,後臺的那位也能做,如果有架構師,CTO 這種也會給專案的程式碼作出指明燈的效果,這些人每個崗位都必須有一位是專業的,這個專案基本問題不大。
-
15 # 交易沒有銀彈
你這玩蛇皮,首先,公司投入財力物力做東西一定要選擇靠譜的人去搞,尤其是領導的位置非常重要,你對技術負責人都不瞭解,玩啥子?很多有些簡歷都可能有問題,叫你熟悉的人推薦啥的,如果自己不會技術,就考別人瞎忽悠,最後肯定把自己坑慘,另外,外包公司為什麼叫外包,因為人家技術有限,尤其小外包公司,找到一個技術和專案管理都到位的負責人不是一件容易的事情,但是正如你看到的那樣,你選個搞資料庫的人來搞也是沒誰了
-
16 # 十維思考
不知道哪來的技術負責人。一般來講兩種情況,一個你們這東西太先進或者太不靠譜,一般的公司搞不出來,甚至要這個東西的人都說不清楚。
還有一種情況,這個技術負責人就是個坑,什麼都不懂。
-
17 # 實體觀察
我感覺是模式沒有理清楚,首先你要寫出系統功能需求,要非常細,細到每個環節的具體項;其次,要與產品經理討論可行性,歸納出核心功能需求,這樣才能交給外包方,還要與外包方一一溝通實現的可能性,我感覺你是不停修改需求,造成前後矛盾無法實現,我也是吃過虧才懂得,好在辛苦了三個月,系統終於可以上線了,祝你好運。
再補充下,最好能把UI做出來,它就好比你的思維圖,也能讓系統清晰起來,我不懂技術,但我真實一路摸爬滾打過來的
-
18 # Coder雨龍
聽你的描述,技術負責人責任很大,專案前期就應該發現問題所在,拖拖拉拉一年還沒上線。技術負責人需要對技術,需求,時間節點全面掌控,及時發現風險點!
-
19 # 找順風車返空車51快配
我也是傳統行業進入網際網路行業的。沒進入之前也和大部分人認為的一樣,這個東西簡單嘛!五萬十萬三個月就做出來了,現在全社會沒有做過app的人都是這麼認為的,甚至包括有的風投公司都是這麼認為的。
真正我做的時候才知道根本沒那麼簡單,你找人承包他給你承諾得很簡單,三個月上線,實際呢?我從去年十月開始開發,承諾17年元旦上線,結果17年四月還沒有上線,招商加盟定金都收了上百萬了導致幾乎全部退款,後來組建技術團隊自己開發,預計兩個月,因為該出的問題前七個月基本上都找到了,設計方案又進行了最佳化,結果還是花了7個月,不過在大家的努力下我的app已近順利運行了。
經驗就是,設計規劃一定的周到詳盡,千萬不要改動太多,所以產品經理和規劃人員就相當重要了,多討論後在開始,其次一定的按科學的步驟來,理念先出來,再設計頁面,出現的問題一定要有一套科學的溝通解決模式。尤其是初期問題很多,怎麼一個個解決。初期感覺還是找比較優秀的外包團隊可以節省時間,但是一定要深入溝通,也不要期望太快,功能複雜的app一般得半年以上時間。越級越容易出錯,一錯就很麻煩。
-
20 # 老拱
這個本人經歷的太多了。
一句話你所謂的技術負責人不靠譜,資料庫工程師,我能理解為不夠全面嗎!他可能是資料庫方面的專家,但不夠支撐整個專案。
做網際網路產品專案,創始人不懂技術是比較糟糕的,難以把自己的想法和專案很好的吻合,並且死於N個坑。
不懂也可以,那麼你要有一個靠譜的技術合夥人,必須有股份。靠譜和股份是重點圈起來。靠譜是人品與技術,人品第一,技術其次。最理想的還要是個有想法的人,他自己也想成就一番事業。那麼雙劍合璧,必有作為。
否則不要入坑了,多少錢都白扔。
回覆列表
說是jave後臺不懂而造成的責任
我還沒聽說過過jave是什麼,我做過網際網路外包專案,負責與外包公司溝通。
你這個應該是沒選對公司,也沒選對技術負責人。
這個所謂的懂技術的人,應該是對此事的直接負責人,如果外包公司完成不了,應該第一時間就能知道並且重新選擇外包公司合作。小半年了才發現到不了上線標準,不管是後臺還是前端的問題,多是這個人的問題。正常最多半月就該告訴你行不行了。
所謂資料庫工程師出身,可能只懂他後臺資料庫管理的一些東西,對於這個專案管理,能力不夠。屬於趕鴨子上架,硬著頭皮在做專案。
另外,技術外包是最不靠譜的!
我曾經接受的專案就是屬於前一個外包公司做的,接手以後花費最多的時間是看他們程式碼,反而不是去實現新功能。程式碼的維護,更新,功能版本的更迭,需要的是瞭解專案的人,一點點的去完善。
接手專案,一期開發完成,拍拍屁股走人。基本上意味著這專案快涼了。
因為你想繼續把這個專案執行下去,得找比上家外包更牛一級的人接手,不然沒人願意看你的祖傳程式碼,還不如直接重新做一個新的省事!
以後還不知道會有多少坑,祖傳程式碼,能跑起來就不錯了。