<span id="z5r9v"><video id="z5r9v"><span id="z5r9v"></span></video></span>
<span id="z5r9v"></span><span id="z5r9v"><dl id="z5r9v"><ruby id="z5r9v"></ruby></dl></span>
<strike id="z5r9v"></strike>
<span id="z5r9v"><i id="z5r9v"><ruby id="z5r9v"></ruby></i></span>
<ruby id="z5r9v"><dl id="z5r9v"></dl></ruby>
<strike id="z5r9v"><dl id="z5r9v"><ruby id="z5r9v"></ruby></dl></strike><span id="z5r9v"><dl id="z5r9v"><strike id="z5r9v"></strike></dl></span>
<strike id="z5r9v"></strike>
蘇州峻德信息

軟件外包的坑,他山之石能填否?

轉載: 公眾號“敏捷之美”

時間:2022-09-21

在知乎上看到ID“已退乎”發的帖子——“外包公司的選擇與外包客戶的選擇-甲方乙方的坑”,其中列出了10個軟件外包業務中常見的坑,如下:


大多數情況下甲方都提不出合適的需求,甚至連想要什么都說不明白搞不清楚。

甲方的企業中或者團隊中沒有懂得互聯網或者IT方面的人,甚至整體年齡偏大,互聯網和 app 了解不多。

甲方企業或者團隊普遍不具備運營能力,或者低估了后期運營的難度與投入。

預算不足,以及對持續投入的預估不足,預算難以到位。

對于企業外包項目,很多時候甲方對接人沒有足夠的權限去調用足夠多的資源,甚至很多時候只是個傳話筒。

甲方對于項目重視程度不夠。企業項目表現在把外包開發當成了普通采購,而創業項目甲方過于注重商業模式等商業運作,并沒有好好考慮過外包軟件的各個方面。

項目的實際需求隨著市場改變而變化很快(企業業務軟件也是如此)。

甲方在項目沒有經過調研,經過計劃,連需求都提不出來的情況下,就要求提早報價,而乙方不得已提早報價,甲方后面拿這個報價去卡乙方。

乙方迫于工期壓力與業績壓力,不得以為甲方妥協,報出不現實的開發時間,并在開發中采取拖延戰術來延長開發周期。

在業務軟件外包時,甲方將軟件外包服務當作普通采購,以為是一錘子買賣,考慮不長遠。

帖子作者因為個人原因沒有對所列問題一一作答。但這些問題挺接地氣,是普遍存在的行業問題,絕對是實戰經驗的總結。

逐條歸類,不難看出這些“坑”的根本原因是甲方對自身的需求不清晰,更不清楚用IT手段實現這些需求需要哪些資源和流程,但事情又不得不做,盲目啟動,引發一系列的連鎖“坑”。

術業有專攻,甲方也確實有苦衷,IT技術是有相當門檻的,各行企業自己有IT部門的都不多,更何談有既懂業務又懂IT的人才,不懂又怎能想明白說清楚?

以前(至少十年前)的軟件開發可以提前制定方案,成年累月的實施,前提是系統需求變化不大,不快,相對固定,有規律,模塊化。如今,別說IT實現了,就業務本身,經常三五個月就可能發生根本性的變化,市場風云莫測,不是人力能夠決定的,那么軟件開發怎么能未雨綢繆呢?

那什么樣的軟件開發工作方法能適應當下的市場變化呢?

今天我們用“他山之石”來啟發一下思路。

他山之石

何志森,一位“非主流”建筑設計師,四年前因為在“一席”的一場演講為大眾所知。下面先簡單介紹一下他的故事。

何志森2010年開始讀建筑學博士。第一年主要做參數化,每天用電腦畫各種各樣很漂亮的圖。一次他回福建老家去華僑大學拜訪一位老師的時候,偶然看到了小販用晾衣竿把盒飯傳遞給圍墻后面的學生,當時就被原地震撼了——“這是我們設計師設計的圍墻,他們用一根晾衣竿就把它給捅破了?!?/span>

回到墨爾本之后,他毅然決定不再做參數化了,轉而開始做人文實地考察。他用了四年時間跟蹤了一位在圍墻上賣盒飯的小哥,完成了他的博士論文。這四年里,他目睹了平凡的打工人是怎樣用生存智慧和草根策略,把設計師在電腦上做的各種各樣的圖、在現實中做的各種各樣的空間給顛覆的。

2015年他博士畢業回國,發起了一個Mapping工作坊,開始了三年在中國各大建筑院校間邊流浪邊教學的游牧式教研生活。

那么Mapping是什么?他用一個具體的例子說明。下圖左邊是紐約曼哈頓地圖,右邊這個地圖,是一個穆斯林在曼哈頓生活了20年之后,把曼哈頓每一個攝像頭都標出來了,最后發現三條沒有攝像頭的路。左邊是地圖,右邊是Mapping——把看不到的東西挖掘出來,就像是偵探一樣。

他的Mapping工作坊給參與的學生提的要求也很明確,有這樣幾個步驟。 

選擇一個目標,可以是人,可以是物體,越小越好。

你要長時間地跟蹤觀察這個目標。

你要把自己變成目標,如果你跟蹤研究一條狗,那么就把自己變成狗。

你要發現這個目標與城市之間的關系,呈現這些關系,然后基于這些關系提出你的設計主張。

他的演講中提到好幾個例子,感興趣的可以自己看。這里只展示一個典型案例。

他在華南理工大學建筑學院做的一個工作坊,有一組學生選擇跟蹤一位賣冰糖葫蘆的阿姨,想通過近距離觀察阿姨的售賣軌跡,去理解小販是如何使用設計師設計的公共空間。

幾天的跟蹤和觀察,讓學生們感同身受地體會到阿姨生存的不易,不僅要時刻逃避城管的驅趕,還不能喝水——為了避免上廁所的麻煩,從凌晨五點以后就不能喝水了,糖葫蘆不賣完,不敢喝水……

學生們先是用電腦建模,為阿姨設計了三條逃跑路線,可以在最短的時間內逃離廣場;之后又專門為阿姨設計了一個變形金剛售賣車——可以變成一個廁所,可以變成一個賣花的、賣衣服的流動攤位,不僅只是賣冰糖葫蘆,在不同的地點有不同的變法。

何志森說:“如果沒有調查跟蹤,沒有把自己的角色變成她,那么學生永遠不可能設計出這樣子的作品?!?/span>

借以攻玉

他的演講很有啟發性,充滿人文關懷和獨立思考,他的Mapping工作坊一直在做,有自己的公眾號,很多有意思的案例故事。這里我們還是回到軟件行業,雖然說建筑設計和軟件開發隔行如隔山,但性質相通——都是專業技術門檻比較高,通過專業技能為人們的生活和生產提供便利。

他提出的Mapping思維就很像敏捷開發,真正的目標導向,以人為本,擁抱變化,不能紙上談兵,閉門造車,一定要近身觀察和了解你要服務的人的生活軌跡、工作流程、商業邏輯,還要通過人與人的溝通和互動,先達成彼此一致的目標和信任,不斷磨合,最終才能做出性價比最好的設計,而且還要與時俱進。

拋開實際操作中可能會遇到的人情事故(甲方、乙方的企業文化、管理風格、企業政治……)和實際困難不談,本質上,好的軟件開發完全可以借鑒何志森Mapping工作坊的原則:

明確一個目標,開發要實現什么功能,越具體越好。

功能實現都涉及哪些環節?底層商業邏輯是什么?誰是這個功能的實際使用者?你要長時間地跟蹤觀察這些使用者,了解他們的需求細節。

你要把自己變成目標,變成實際的使用者。如果你跟蹤研究一條狗,那么就把自己變成狗。

你要發現這個目標與企業整體業務(戰略)之間的關系,呈現這些關系,然后基于這些關系提出你的設計主張。

還是老生常談的那句話,真理是相通的,在不同的行業,做事的方法論、價值觀可能有不同的稱謂,但本質往往相同。

有人可能會說實際情況復雜得多,理論上行得通,現實中寸步難行。是,沒錯,“現實”總是難以撼動的,但并不是撼不動。謀事在人。何志森做Mapping工作坊的真實原因也是想在高校找工作,卻一直沒找到,甚至引來同行的非議和輿論的質疑……但這不影響他兩次走上一席的講壇,用他的故事和案例給千千萬萬人帶來啟發;不影響他的工作坊給參與者的生活、工作甚至價值觀帶去一些轉變,一抹亮色……

盡人事,聽天命。根據二八定律,在樣本中占大多數的,不一定是正確的。無論你處在什么位置,都可以有自己的選擇。軟件行業中也已經有敏捷的踐行者。

何志森說:“我覺得設計這門教育不是教那些圍墻里面的學生如何畫圖,如何被規范,而是教他們如何思考和創造生活。我們的學生離生活太遠了,學生離開學校時帶走的應該是一個富有人性的價值觀,而不是滿腦冰冷的規范。只有這樣子回到工作的時候,他的設計才會考慮到不同人群的感受,才會真正地接地氣?!?/span>

對軟件開發,亦如是。
上一篇:長痛與短痛,國內軟件開發究竟該如何選擇? 下一篇:一文了解什么是軟件開發ODC(離岸研發中心)

軟件外包的坑,他山之石能填否?

軟件外包的坑,他山之石能填否?

在知乎上看到ID“已退乎”發的帖子——“外包公司的選擇與外包客戶的選擇-甲方乙方的坑”,其中列出了10個軟件外包業務中常見的坑,如下:


大多數情況下甲方都提不出合適的需求,甚至連想要什么都說不明白搞不清楚。

甲方的企業中或者團隊中沒有懂得互聯網或者IT方面的人,甚至整體年齡偏大,互聯網和 app 了解不多。

甲方企業或者團隊普遍不具備運營能力,或者低估了后期運營的難度與投入。

預算不足,以及對持續投入的預估不足,預算難以到位。

對于企業外包項目,很多時候甲方對接人沒有足夠的權限去調用足夠多的資源,甚至很多時候只是個傳話筒。

甲方對于項目重視程度不夠。企業項目表現在把外包開發當成了普通采購,而創業項目甲方過于注重商業模式等商業運作,并沒有好好考慮過外包軟件的各個方面。

項目的實際需求隨著市場改變而變化很快(企業業務軟件也是如此)。

甲方在項目沒有經過調研,經過計劃,連需求都提不出來的情況下,就要求提早報價,而乙方不得已提早報價,甲方后面拿這個報價去卡乙方。

乙方迫于工期壓力與業績壓力,不得以為甲方妥協,報出不現實的開發時間,并在開發中采取拖延戰術來延長開發周期。

在業務軟件外包時,甲方將軟件外包服務當作普通采購,以為是一錘子買賣,考慮不長遠。

帖子作者因為個人原因沒有對所列問題一一作答。但這些問題挺接地氣,是普遍存在的行業問題,絕對是實戰經驗的總結。

逐條歸類,不難看出這些“坑”的根本原因是甲方對自身的需求不清晰,更不清楚用IT手段實現這些需求需要哪些資源和流程,但事情又不得不做,盲目啟動,引發一系列的連鎖“坑”。

術業有專攻,甲方也確實有苦衷,IT技術是有相當門檻的,各行企業自己有IT部門的都不多,更何談有既懂業務又懂IT的人才,不懂又怎能想明白說清楚?

以前(至少十年前)的軟件開發可以提前制定方案,成年累月的實施,前提是系統需求變化不大,不快,相對固定,有規律,模塊化。如今,別說IT實現了,就業務本身,經常三五個月就可能發生根本性的變化,市場風云莫測,不是人力能夠決定的,那么軟件開發怎么能未雨綢繆呢?

那什么樣的軟件開發工作方法能適應當下的市場變化呢?

今天我們用“他山之石”來啟發一下思路。

他山之石

何志森,一位“非主流”建筑設計師,四年前因為在“一席”的一場演講為大眾所知。下面先簡單介紹一下他的故事。

何志森2010年開始讀建筑學博士。第一年主要做參數化,每天用電腦畫各種各樣很漂亮的圖。一次他回福建老家去華僑大學拜訪一位老師的時候,偶然看到了小販用晾衣竿把盒飯傳遞給圍墻后面的學生,當時就被原地震撼了——“這是我們設計師設計的圍墻,他們用一根晾衣竿就把它給捅破了?!?/span>

回到墨爾本之后,他毅然決定不再做參數化了,轉而開始做人文實地考察。他用了四年時間跟蹤了一位在圍墻上賣盒飯的小哥,完成了他的博士論文。這四年里,他目睹了平凡的打工人是怎樣用生存智慧和草根策略,把設計師在電腦上做的各種各樣的圖、在現實中做的各種各樣的空間給顛覆的。

2015年他博士畢業回國,發起了一個Mapping工作坊,開始了三年在中國各大建筑院校間邊流浪邊教學的游牧式教研生活。

那么Mapping是什么?他用一個具體的例子說明。下圖左邊是紐約曼哈頓地圖,右邊這個地圖,是一個穆斯林在曼哈頓生活了20年之后,把曼哈頓每一個攝像頭都標出來了,最后發現三條沒有攝像頭的路。左邊是地圖,右邊是Mapping——把看不到的東西挖掘出來,就像是偵探一樣。

他的Mapping工作坊給參與的學生提的要求也很明確,有這樣幾個步驟。 

選擇一個目標,可以是人,可以是物體,越小越好。

你要長時間地跟蹤觀察這個目標。

你要把自己變成目標,如果你跟蹤研究一條狗,那么就把自己變成狗。

你要發現這個目標與城市之間的關系,呈現這些關系,然后基于這些關系提出你的設計主張。

他的演講中提到好幾個例子,感興趣的可以自己看。這里只展示一個典型案例。

他在華南理工大學建筑學院做的一個工作坊,有一組學生選擇跟蹤一位賣冰糖葫蘆的阿姨,想通過近距離觀察阿姨的售賣軌跡,去理解小販是如何使用設計師設計的公共空間。

幾天的跟蹤和觀察,讓學生們感同身受地體會到阿姨生存的不易,不僅要時刻逃避城管的驅趕,還不能喝水——為了避免上廁所的麻煩,從凌晨五點以后就不能喝水了,糖葫蘆不賣完,不敢喝水……

學生們先是用電腦建模,為阿姨設計了三條逃跑路線,可以在最短的時間內逃離廣場;之后又專門為阿姨設計了一個變形金剛售賣車——可以變成一個廁所,可以變成一個賣花的、賣衣服的流動攤位,不僅只是賣冰糖葫蘆,在不同的地點有不同的變法。

何志森說:“如果沒有調查跟蹤,沒有把自己的角色變成她,那么學生永遠不可能設計出這樣子的作品?!?/span>

借以攻玉

他的演講很有啟發性,充滿人文關懷和獨立思考,他的Mapping工作坊一直在做,有自己的公眾號,很多有意思的案例故事。這里我們還是回到軟件行業,雖然說建筑設計和軟件開發隔行如隔山,但性質相通——都是專業技術門檻比較高,通過專業技能為人們的生活和生產提供便利。

他提出的Mapping思維就很像敏捷開發,真正的目標導向,以人為本,擁抱變化,不能紙上談兵,閉門造車,一定要近身觀察和了解你要服務的人的生活軌跡、工作流程、商業邏輯,還要通過人與人的溝通和互動,先達成彼此一致的目標和信任,不斷磨合,最終才能做出性價比最好的設計,而且還要與時俱進。

拋開實際操作中可能會遇到的人情事故(甲方、乙方的企業文化、管理風格、企業政治……)和實際困難不談,本質上,好的軟件開發完全可以借鑒何志森Mapping工作坊的原則:

明確一個目標,開發要實現什么功能,越具體越好。

功能實現都涉及哪些環節?底層商業邏輯是什么?誰是這個功能的實際使用者?你要長時間地跟蹤觀察這些使用者,了解他們的需求細節。

你要把自己變成目標,變成實際的使用者。如果你跟蹤研究一條狗,那么就把自己變成狗。

你要發現這個目標與企業整體業務(戰略)之間的關系,呈現這些關系,然后基于這些關系提出你的設計主張。

還是老生常談的那句話,真理是相通的,在不同的行業,做事的方法論、價值觀可能有不同的稱謂,但本質往往相同。

有人可能會說實際情況復雜得多,理論上行得通,現實中寸步難行。是,沒錯,“現實”總是難以撼動的,但并不是撼不動。謀事在人。何志森做Mapping工作坊的真實原因也是想在高校找工作,卻一直沒找到,甚至引來同行的非議和輿論的質疑……但這不影響他兩次走上一席的講壇,用他的故事和案例給千千萬萬人帶來啟發;不影響他的工作坊給參與者的生活、工作甚至價值觀帶去一些轉變,一抹亮色……

盡人事,聽天命。根據二八定律,在樣本中占大多數的,不一定是正確的。無論你處在什么位置,都可以有自己的選擇。軟件行業中也已經有敏捷的踐行者。

何志森說:“我覺得設計這門教育不是教那些圍墻里面的學生如何畫圖,如何被規范,而是教他們如何思考和創造生活。我們的學生離生活太遠了,學生離開學校時帶走的應該是一個富有人性的價值觀,而不是滿腦冰冷的規范。只有這樣子回到工作的時候,他的設計才會考慮到不同人群的感受,才會真正地接地氣?!?/span>

對軟件開發,亦如是。

軟件外包的坑,他山之石能填否?

轉載: 公眾號“敏捷之美”

時間:2022-09-21

在知乎上看到ID“已退乎”發的帖子——“外包公司的選擇與外包客戶的選擇-甲方乙方的坑”,其中列出了10個軟件外包業務中常見的坑,如下:


大多數情況下甲方都提不出合適的需求,甚至連想要什么都說不明白搞不清楚。

甲方的企業中或者團隊中沒有懂得互聯網或者IT方面的人,甚至整體年齡偏大,互聯網和 app 了解不多。

甲方企業或者團隊普遍不具備運營能力,或者低估了后期運營的難度與投入。

預算不足,以及對持續投入的預估不足,預算難以到位。

對于企業外包項目,很多時候甲方對接人沒有足夠的權限去調用足夠多的資源,甚至很多時候只是個傳話筒。

甲方對于項目重視程度不夠。企業項目表現在把外包開發當成了普通采購,而創業項目甲方過于注重商業模式等商業運作,并沒有好好考慮過外包軟件的各個方面。

項目的實際需求隨著市場改變而變化很快(企業業務軟件也是如此)。

甲方在項目沒有經過調研,經過計劃,連需求都提不出來的情況下,就要求提早報價,而乙方不得已提早報價,甲方后面拿這個報價去卡乙方。

乙方迫于工期壓力與業績壓力,不得以為甲方妥協,報出不現實的開發時間,并在開發中采取拖延戰術來延長開發周期。

在業務軟件外包時,甲方將軟件外包服務當作普通采購,以為是一錘子買賣,考慮不長遠。

帖子作者因為個人原因沒有對所列問題一一作答。但這些問題挺接地氣,是普遍存在的行業問題,絕對是實戰經驗的總結。

逐條歸類,不難看出這些“坑”的根本原因是甲方對自身的需求不清晰,更不清楚用IT手段實現這些需求需要哪些資源和流程,但事情又不得不做,盲目啟動,引發一系列的連鎖“坑”。

術業有專攻,甲方也確實有苦衷,IT技術是有相當門檻的,各行企業自己有IT部門的都不多,更何談有既懂業務又懂IT的人才,不懂又怎能想明白說清楚?

以前(至少十年前)的軟件開發可以提前制定方案,成年累月的實施,前提是系統需求變化不大,不快,相對固定,有規律,模塊化。如今,別說IT實現了,就業務本身,經常三五個月就可能發生根本性的變化,市場風云莫測,不是人力能夠決定的,那么軟件開發怎么能未雨綢繆呢?

那什么樣的軟件開發工作方法能適應當下的市場變化呢?

今天我們用“他山之石”來啟發一下思路。

他山之石

何志森,一位“非主流”建筑設計師,四年前因為在“一席”的一場演講為大眾所知。下面先簡單介紹一下他的故事。

何志森2010年開始讀建筑學博士。第一年主要做參數化,每天用電腦畫各種各樣很漂亮的圖。一次他回福建老家去華僑大學拜訪一位老師的時候,偶然看到了小販用晾衣竿把盒飯傳遞給圍墻后面的學生,當時就被原地震撼了——“這是我們設計師設計的圍墻,他們用一根晾衣竿就把它給捅破了?!?/span>

回到墨爾本之后,他毅然決定不再做參數化了,轉而開始做人文實地考察。他用了四年時間跟蹤了一位在圍墻上賣盒飯的小哥,完成了他的博士論文。這四年里,他目睹了平凡的打工人是怎樣用生存智慧和草根策略,把設計師在電腦上做的各種各樣的圖、在現實中做的各種各樣的空間給顛覆的。

2015年他博士畢業回國,發起了一個Mapping工作坊,開始了三年在中國各大建筑院校間邊流浪邊教學的游牧式教研生活。

那么Mapping是什么?他用一個具體的例子說明。下圖左邊是紐約曼哈頓地圖,右邊這個地圖,是一個穆斯林在曼哈頓生活了20年之后,把曼哈頓每一個攝像頭都標出來了,最后發現三條沒有攝像頭的路。左邊是地圖,右邊是Mapping——把看不到的東西挖掘出來,就像是偵探一樣。

他的Mapping工作坊給參與的學生提的要求也很明確,有這樣幾個步驟。 

選擇一個目標,可以是人,可以是物體,越小越好。

你要長時間地跟蹤觀察這個目標。

你要把自己變成目標,如果你跟蹤研究一條狗,那么就把自己變成狗。

你要發現這個目標與城市之間的關系,呈現這些關系,然后基于這些關系提出你的設計主張。

他的演講中提到好幾個例子,感興趣的可以自己看。這里只展示一個典型案例。

他在華南理工大學建筑學院做的一個工作坊,有一組學生選擇跟蹤一位賣冰糖葫蘆的阿姨,想通過近距離觀察阿姨的售賣軌跡,去理解小販是如何使用設計師設計的公共空間。

幾天的跟蹤和觀察,讓學生們感同身受地體會到阿姨生存的不易,不僅要時刻逃避城管的驅趕,還不能喝水——為了避免上廁所的麻煩,從凌晨五點以后就不能喝水了,糖葫蘆不賣完,不敢喝水……

學生們先是用電腦建模,為阿姨設計了三條逃跑路線,可以在最短的時間內逃離廣場;之后又專門為阿姨設計了一個變形金剛售賣車——可以變成一個廁所,可以變成一個賣花的、賣衣服的流動攤位,不僅只是賣冰糖葫蘆,在不同的地點有不同的變法。

何志森說:“如果沒有調查跟蹤,沒有把自己的角色變成她,那么學生永遠不可能設計出這樣子的作品?!?/span>

借以攻玉

他的演講很有啟發性,充滿人文關懷和獨立思考,他的Mapping工作坊一直在做,有自己的公眾號,很多有意思的案例故事。這里我們還是回到軟件行業,雖然說建筑設計和軟件開發隔行如隔山,但性質相通——都是專業技術門檻比較高,通過專業技能為人們的生活和生產提供便利。

他提出的Mapping思維就很像敏捷開發,真正的目標導向,以人為本,擁抱變化,不能紙上談兵,閉門造車,一定要近身觀察和了解你要服務的人的生活軌跡、工作流程、商業邏輯,還要通過人與人的溝通和互動,先達成彼此一致的目標和信任,不斷磨合,最終才能做出性價比最好的設計,而且還要與時俱進。

拋開實際操作中可能會遇到的人情事故(甲方、乙方的企業文化、管理風格、企業政治……)和實際困難不談,本質上,好的軟件開發完全可以借鑒何志森Mapping工作坊的原則:

明確一個目標,開發要實現什么功能,越具體越好。

功能實現都涉及哪些環節?底層商業邏輯是什么?誰是這個功能的實際使用者?你要長時間地跟蹤觀察這些使用者,了解他們的需求細節。

你要把自己變成目標,變成實際的使用者。如果你跟蹤研究一條狗,那么就把自己變成狗。

你要發現這個目標與企業整體業務(戰略)之間的關系,呈現這些關系,然后基于這些關系提出你的設計主張。

還是老生常談的那句話,真理是相通的,在不同的行業,做事的方法論、價值觀可能有不同的稱謂,但本質往往相同。

有人可能會說實際情況復雜得多,理論上行得通,現實中寸步難行。是,沒錯,“現實”總是難以撼動的,但并不是撼不動。謀事在人。何志森做Mapping工作坊的真實原因也是想在高校找工作,卻一直沒找到,甚至引來同行的非議和輿論的質疑……但這不影響他兩次走上一席的講壇,用他的故事和案例給千千萬萬人帶來啟發;不影響他的工作坊給參與者的生活、工作甚至價值觀帶去一些轉變,一抹亮色……

盡人事,聽天命。根據二八定律,在樣本中占大多數的,不一定是正確的。無論你處在什么位置,都可以有自己的選擇。軟件行業中也已經有敏捷的踐行者。

何志森說:“我覺得設計這門教育不是教那些圍墻里面的學生如何畫圖,如何被規范,而是教他們如何思考和創造生活。我們的學生離生活太遠了,學生離開學校時帶走的應該是一個富有人性的價值觀,而不是滿腦冰冷的規范。只有這樣子回到工作的時候,他的設計才會考慮到不同人群的感受,才會真正地接地氣?!?/span>

對軟件開發,亦如是。
上一篇:長痛與短痛,國內軟件開發究竟該如何選擇? 下一篇:一文了解什么是軟件開發ODC(離岸研發中心)
国产又黄又大又网站视频