台灣最大程式設計社群網站
線上人數
1203
 
會員總數:244980
討論主題:188951
歡迎您免費加入會員
討論區列表 >> 心情甘苦談 >> 有感而發,認知不同,有所不同。
[]  
[我要回覆]
1
回應主題 加入我的關注話題 檢舉此篇討論 將提問者加入個人黑名單
有感而發,認知不同,有所不同。
價值 : 0 QP  點閱數:2054 回應數:7

樓主

~水瓶寶寶~
中級專家
4327 1
1642 82
發送站內信

捐贈 VP 給 ~水瓶寶寶~
最近,內部的決定。感覺都是亂亂來,有新的就想學人。從頭到尾都沒個樣!像有人就去了微軟的開發者大會後,有某位講師說一定要單元測試後,再開發程式。
  但是,個人認為。單元測試是好。但還是要依環境和產業別為主,並且是要自行開發出一套完整的開發流程。由於我一開始接觸程式時,是開發客製化系統的。
所以當初也都只有以開發完成,並且達到目標,讓客戶驗收通過為主!不乏有:鋼鐵業的進銷存系統、某大影音出租的門市出租系統、某縣市的果菜進銷存系統、某KTV點歌系統、某港務局的PORTAL系統、房屋租賃系統、還有宜蘭縣某活動已被停辦的其中一年網站。
全部都是客製化。不是說完全沒有顧慮到安全性的考量,只是至少要先把功能性、需求性、使用性完成後,才會有其他的精神和時間做安全性的補強!有人會說SA和SD啊!
但說真的,接案子的時候都是火燒屁股,SA、SD。真的有RUN的話,那一定都是違約賠款。因為會DELAY。
  目前的工作是在遊戲業,但不是開發遊戲。也是專職於網站的的相關性開發!單位名也是掛RD。@@有人又會說:嘩!RD也!我咧!是沒錯,也是做研發一些需求單位的需求。但沒有像人家研發DRIVER或是基底的介接溝通或通訊的程式那樣硬!有時候都會遇到非需求單位的困難點!這個個人倒是覺得影響很大!因為客觀性不同,主觀性不同,認知性不同。那做好的東西,也都會有所不認同!舉個例:明明需求寫著只是移植原本的功能至另一個開發的後台,但需求完全沒有描述清楚,在測試的時候,卻又因為自己覺得那樣不好,或覺得那樣不OK,要加什麼。或是要如何做。而因這個因素說測試不通過,是沒錯,不能拒絕需求單位的需求,但如果需求不明確也會讓我們的開發耗費許多不必要的時間和測試上的時間。
  我記得我的某位上司說過一段話:你們後台不就像開關一樣,接一家廠商的後台查詢。不就很簡單不用耗費工時嗎?根本不算工作量!
  但重點是「寫好後,往往都是卡在測試的流程,因為測試時,會因對方未介接完成,或傳回來的資料不正確。或是對方忘了開IP、或是對方變換原本申請的IP、測試者往往都擺了好幾天,要測的時候因為其他人的因素造成測試失敗、或是主觀意識覺得要加其他東西或建議。而造成逾期!很多東西,可以建議。但要事後做。不然這樣從頭到尾都違反了流程,因為是建議,應該是要另外再另案處理,而不是在測試時,要上線了。才又在改需求。測試主要的目的是測有沒有BUG或是功能是否達到需求。這才是最重要的。
  我自己承認,因為之前開發客製化軟體,都是以達到功能和目的為主要。沒有考量其他的細節。但並不代表那就是真的我
。或是我就是那樣的人,因為真的有許多東西不是我所一人能想到的或測到的。我往往在之前也有做測試,但在測試時,往往
給我的都不是理性的或合理的建議。
如:
1、原本功能就沒有匯出EXCEL檔的功能,需求單內容也隻字未提。卻又在測試時以此因素而測試不通過。
2、原本的錯誤訊息,即是顯示日期區間不正確,所以無資料顯示,但測試者,卻說:應該要秀無資料。而測試不通過。
3、原本的彙總或明細為下拉選項。但測試者卻說:為何要做為下拉式的選項。而測試不通過。
建議是很好,但不是做為測試不通過的理由和藉口。或許有個人因素,但我也是本著,對事不對人。所以一直忍受著!但並不代表我認同。只是我覺得測試者如果自己也是程式開發人員,反過來想。感受為何?況且是一個自己也有經歷過程式開發的主管。這更讓人無法心服口服。就像常言道:帶人要帶心。或許今日因為幸運的一直狂升而變成了我的主管。但如果是想以高高在上的態度,來把我們踩在腳下。那總有一天,你會發現!每個人都不會心服口服的,只有做表面!那代表已失去民心了。那這樣的團隊,很難帶出有效率的。
  但我這陣子也想通了。因為他的不成熟,我覺得不必跟小朋友計較。因為他只是運氣好,祖上積德。所以會升到現在的位
置。並不是靠他自己的實力爭取而來的!而我,只要一有機會,我就一定會再去進修!充實自己的專業能力,並且提昇自己的
競爭能力。總有一天,努力會有收穫,付出會有回饋!與大家共勉之!^^

搜尋相關Tags的文章: [ 有感而發,認知不同,有所不同。 ] ,
本篇文章發表於2008-11-21 10:39
別忘捐VP感謝幫助你的人 新手會員瞧一瞧
1樓
回應

桂正和
捐贈 VP 給 桂正和 檢舉此回應
做SA的意義就在於減少那些浪費的事情
所以說有利有弊
就看每份專案開發的時候有沒有一開始就把這段工作也算進去

想想
如果一開始SA的文件就做好了
規格跟流程都寫得清清楚楚
一開始就給客戶過目的話
這樣有什麼問題或者要修改
就可以在動工之前或者是測試之前就先反應出來
至少不會有那些修小東西修到抓狂的事情
真的有客戶最後面才來反應
至少我們也有底氣∼

畢竟文件規格跟流程的寫的清清楚楚了
到最後面才在反應這不對那不對的話Delay到時間那是客戶自己也要吸收的成本

就好比為什麼合約都要仔細的寫
盡量把有可能發生的狀況都考慮進去
例如客戶跳票、工作Delay、功能大幅度的增加修改等等
就是為了避免雙方的爭議

所以力求在一開始跟客戶溝通的時候~~
工作所需時間加上這個吧
或者是在簽約開始動工之前就把SA的部分先做好

如果公司硬要省掉這段功夫
那也只好每當因為修改會Delay到工作時間的時候反應給公司
再三的強調問題點

說真的
現在很多公司都沒有在管SA這東西
與其是事先就提交出來的文件
還不如說是最後面才付上的使用說明書
用途差了很多

所以也要看是否能調適心態了
一昧的抱怨也不是個辦法
畢竟前面提到SA沒時間做
後面也提到因為功能沒一開始說明所以如何如何
這有點矛盾∼
本篇文章回覆於2008-11-21 11:54
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
2樓
很多都是靠關係的~~~國營企業也一樣

關關難過 關關過


本篇文章回覆於2008-11-21 11:56
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
3樓
作者回應

~水瓶寶寶~
捐贈 VP 給 ~水瓶寶寶~ 檢舉此回應
很多都是關係企業。這倒是真的!因為有朋友的朋友!有的是學長會找學弟。或是同校的或是同屆的,甚至是當兵的還有同梯或當兵的學長學弟。多囉!
本篇文章回覆於2010-04-06 09:40
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
4樓
回應

SUN
檢舉此回應
是有感而發,SA有需要嘛!?
當Programmer完成程式給客戶"測試"之後!!
SA還有用嘛!?
哪個客戶會再去找SA再由SA指導Programmer修改程式呢?
都是直接找Programmer~
但是Programmer通常身上要揹個3-30個CASE!!

結論SA=業務吧!!
本篇文章回覆於2010-04-15 18:03
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
5樓
最有價值解答

小羊窒息
捐贈 VP 給 缺氧的羊:窒息 檢舉此回應
我最近的感想...

SA/SD 給客戶看的雛型畫面, 如果就是未來完成時的畫面,
那麼 PG 做出來的東西, 基本上都不會做出跟客戶所想的有落差

但如果 一開始的是[參考畫面], 那後來的成品就很容易出現落差
本篇文章回覆於2010-04-22 18:23
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
6樓
作者回應

~水瓶寶寶~
捐贈 VP 給 ~水瓶寶寶~ 檢舉此回應
小羊大大說的沒錯!因為參考畫面,就代表會有空間。就無法有確定的標準。就會有很多說不明講不清的界限了!
好一點的可以讓你過,壞一點的讓你超難過。所以還是要確定需求為首要!
本篇文章回覆於2010-09-16 10:52
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
7樓
回應

浩瀚星空
捐贈 VP 給 浩瀚星空 檢舉此回應
其實樓主的論點有些是對,有些是不對的。

如:
1、原本功能就沒有匯出EXCEL檔的功能,需求單內容也隻字未提。卻又在測試時以此因素而測試不通過。
這一點是ok的。匯出功能是需要事先說明。這點你抱怨是對的。

2、原本的錯誤訊息,即是顯示日期區間不正確,所以無資料顯示,但測試者,卻說:應該要秀無資料。而測試不通過。
這點我認為客戶這樣要求是對的。原本沒資料就盡量出現「無此資料」或是相關的訊息。你不能因為客戶手賤。故意選個不可能有資料的區間日期產生不了資料。
就去怪客手賤。

3、原本的彙總或明細為下拉選項。但測試者卻說:為何要做為下拉式的選項。而測試不通過。
這點是需要兩邊互相溝通決定方案的。畢竟得要依客戶的要求去做。

本篇文章回覆於2010-09-21 15:04
== 簽名檔 ==
--未登入的會員無法查看對方簽名檔--
   
1

回覆
如要回應,請先登入.