Developing Life Cycle ตีแผ่ความจริงของวงการ Developer
แต่นแต๊น…..วันนี้เป็นฤกษ์งามยามดีที่จะขอนำเสนอความจริงที่ถูกปิดบังมานานในวงการ Software ฮิฮิ แต่คิดว่าน่าจะมีบางคนพอรู้ความจริงเรื่องนี้ อยู่บ้างแล้ว พอดีเข้าไปเจอกระทู้ใน web ที่มีชื่อเสียงแห่งหนึ่ง ซึ่งอ่านแล้วรู้สึกว่าเป็นการตีแผ่ที่กระจาย กระจ่างแจ้ง ดีจริงๆ เลยอยากเอามาเผยแผ่ได้อ่านกันขำ ๆ แต่ก็มิได้นำพา….
ที่มา : http://www.thaimacdev.com
ขอชี้ชัดๆ กันเป็นข้อๆเลยน่ะค่ะ….
รูปที่1: ลูกค้าอยากจะได้โปรแกรมอะไรซักอย่าง ก็เลยอธิบายให้กับ Project Leader ฟัง (ชิงช้าสามที่นั่ง)
รูปที่2 : อีตา Project Leader ดันไปเข้าใจว่าลูกค้าอยากได้อย่างงี้ (แกว่งไม่ได้ ทำได้แค่นั่งพิงต้นไม้)
รูปที่3 : อีตา System Analyst ฟังจาก Project Leader มาดันดีไซน์ออกมาเป็นแบบนี้ (แก้ปัญหาชิงช้าแกว่งไม่ได้ ด้วยการดัดแปลงแบบขอไปที)
รูปที่4 : ไอ้โปรแกรมเมอร์ดันเขียนชุ่ยๆออกมาเป็นแบบนี้ (แล้วตูจะแกว่งยังไงฟระ)
รูปที่5 : อีตา Business Consult ก็ดันโม้กะลูกค้าซะเต็มที่เลย ว่าโปรแกรมที่ท่านสั่ง มันจะทำได้ขนาดนี้ครับท่าน (ล่อเก้าอี้โซฟาพระราชทานกันเลย)
รูปที่6 : และนี่คือร่างเอกสารของโปรแกรมที่ทำมา (โล่งโจ้ง เพราะไม่มีใครอ่าน)
รูปที่7 : แต่จริงๆไอ้ที่ติดตั้งไป มันทำได้แค่นี้เอง (เหลือเชือกแค่เส้นเดียวเนี่ยนะ)
รูปที่8 : แต่ลูกค้าโดนคิดตังค์ไปขนาดนี้ (สั่งชิงช้า โดนคิดเงินเท่าสร้างสวนสนุก)
รูปที่9 : แถม Support ยังเหลือแค่นี้ (มีแต่ตอ)
รูปที่10 : ซึ่งจริงๆแล้ว ลูกค้าต้องการแค่เท่านี้เอง (ฮ่าๆๆๆๆๆๆ)
“ฝากไปถึงทีมนักพัฒนาโปรแกรมทุกท่านนะครับ ว่า แทนที่จะยัดความอลังการแต่เพิ่มความเข้าใจต่อความต้องการที่แท้จริง ของลูกค้าท่านจะดีกว่านะครับ ผมไม่อยากเห็นใครเสียเงินสร้างสวนสนุกกันบ่อยๆครับ อิอิ” คำกล่าวของเจ้าของกระทู้…. แต่ก็มิได้นำพาน่ะจ๊ะ
ที่มา: แบไต๋ ไฮเทค!! 2.0
อาจารย์หนูเอาแต่รูปมาให้ดูแล้วตีความจากรูป
งงกันเลยทีเดียว หุหุ เดาไปกันไปเรื่อยเปื่อย แต่อาจารย์ก็เฉลยประมาณนี้แหละค่ะ อิอิ
คุณ Oho,
ยินดีครับที่บทความต่างๆ บน WeLoveBug เป็นประโยชน์กับคุณ Oho ครับ
ชอบมากเลยครับ ผมคิดว่าน่าจะได้เจอกันบ่อย ๆ กับเหตุการณ์อย่างนี้ ดูแล้วตลกดี
ขอบคุณนะครับที่ หาอะไรมาให้อ่าน เรื่อย ๆ
ผมเป็น Tester มือใหม่นะครับ ได้ความรู้จากเว็บนี้ไปเยอะมากเลย ยังไงสู้ ๆ ต่้อไปนะ ชอบมาก ๆ
เคยเห็นมานานมาก แต่ตีความกันไปคนละอย่างเลย พอมาอ่านคำอธิบายภาษาชาวบ้านแล้ว Get เลย อิอิ
55 โดนใจครับ ส่วนใหญ่คนอาจจะลืมนึกถึงหลัก V&V ที่เคยเรียนกันมาตั้งแต่สมัยมหาลัย (เพราะอาจจะนานโข อิๆ)
V แรก Verification -> Do we build the software right? ประมาณว่า ทำโปรแกรมออกมาได้ดีเยี่ยม ตรงตาม standard ประมาณว่าโปรแกรมได้ certificate ได้ รางวัลกันเลยทีเดียว
แต่เรามักจะลืมนึกถึง V อีกตัวซึ่งก้อคือ Validation -> Do we build the right software? ซึ่งน่าจะเป็นสิ่งที่สำคัญกว่า Verification อีก เพราะถ้าลูกค้าสั่งทำรถตู้ แต่เราดันไปทำรถมอเตอร์ไซด์ที่ดีเยี่ยม จนแทบจะได้รางวัลออกมาจะมีประโยชน์มั๊ยเนี่ยยย
โดนใจมากๆ ยิ่งเวลาที่ลูกค้าเปลี่ยน requirement แล้วไม่ยอมรับว่าเปลี่ยน เพิ่มงานนะ แต่ไม่เพิ่มเวลา เวง..กำ..
โดนจริงๆ
เหมือนเจอที่ Office ไงก็ไม่รู้
ยกเครดิตให้จารย์เดฟอีกทีครับ เหอๆ
วันนี้พี่เค้าส่งบทความมาให้อ่าน เลยได้มีเวลาเข้ามา ปกติงานยุ่งอยู่ช่วงที่ผ่านมาเลยไม่มีเวลาได้เข้ามาเลยค่ะ หวัดดี เพื่อนๆ พี่ทุกๆ คนของ welovebug นะค่ะ
ขํามั๊กๆ เลยค่ะ 555 เคยเจอบ้างเหมือนกานค่ะ แบบว่าไป get requirement vs project manager ก็แบบได้มากว้างๆ แล้วก็มาพยายาม breif แบบให้ได้ตรงตาม requirement มากที่สุด ของที่สุด 555 แล้วก็มาขําตอนใกล้ๆ จะ UAT แล้วก็มาขําที่สุด ตอน UAT ซึ่งมันหูชาดี ดีจนบางที timeline ยื่น เก็บเงินไม่ได้ 555 แต่ตอนนี้เปลี่ยน field มาเป็น Test engineer โดยตรงแล้วค่ะ แล้วไม่ต้องไปฝ่าด่านกะลูกค้า ให้ Project Co and Project Manager ไปเป็นด่านหน้าแทน
ขอบคุณน้องอ้อ สำหรับบทความเรื่องนี้ พี่ว่ามันโดนใจหลายๆ คนเลยทีเดียว ที่อยู่ในสายงายของการพัฒนา Software นะ
ไงก็ดูกันขำขำ อย่าไปคิดอะไรมากนะครับ