ทำไมการประเมินแบบ man-hour จึงใช้กับซอฟแวร์ไม่ได้

ในทัศนคติของผม ผมคิดว่าปัญหาหลักของการประเมินแบบ traditional คือ การใช้ man-hour หรือหน่วย คน-ชั่วโมงในการประเมินขนาดของงาน

man-hour นั้นเป็นหน่วยของงานที่บอกว่า งานชิ้นนี้ถ้าหากใช้ 1 คนทำ จะเสร็จในเวลา 1 ชั่วโมง เพราะฉะนั้น ถ้าใช้สองคนทำก็จะเสร็จในเวลา ครี่งชั่วโมง ซึ่ง man-hour นี้เป็นหน่วยวัดทาง engineering ตั้งแต่ยุคบุกเบิกตั้งแต่หลังการปฏิวัติอุตสาหกรรม ปัญหาของมันคือ มันถูกคิดขึ้นมาเพื่อวัดขนาดของงานในยุคที่งานต่างๆ ถูกแยกย่อยจนกระทั่งไม่มีความแตกต่างของงานชิ้นเดียวกันไม่ว่าจะกระทำโดยคนงานที่มีทักษะระดับใด พูดง่ายๆ คือคนเก่งและคนไม่เก่งจะใช้เวลาเท่ากัน ใครอยากเห็นภาพชัดเจน ก็ดูหนังเรื่อง Modern times ที่นำแสดงโดย Charlie Chaplin นะครับ

แนวคิดเรื่องการแตกงานจนใครทำก็ไม่แตกต่างกันนี้ ถูกนำมาใช้กับการพัฒนาซอฟแวร์ด้วย ลองดูวิธีการ WBS (Work Breakdown Structure) นั่นคือผลพวงของแนวความคิดนี้ ทีนี้ใครก็ตามที่เคยเขียนซอฟแวร์จริงๆ คงจะพอเห็นภาพแล้วว่า การเขียนซอฟแวร์มันไม่ได้เป็นเช่นนั้น ต่างคนเขียนก็ใช้เวลาต่างกัน แม้แต่ตัวเราเอง แค่เขียนคนละครั้งโค้ดยังไม่เหมือนกันเลย เพราะฉะนั้นการแตกงานย่อย ไม่ได้ช่วยให้งานเกิดเป็นลักษณะที่ไม่มีความแตกต่างจากทักษะได้เลย

เมื่อทักษะและความสามารถมีผลต่อเวลาที่ใช้ทำงาน สมมติฐานเดิมที่ว่าไม่มีความแตกต่างจึงใช้ไม่ได้ และทำให้ man-hour ใช้ไม่ได้จริงในการพัฒนาซอฟวแร์ ทีนี้ถ้าหากเราดันทุกรังใช้มันล่ะก็จะเกิดอะไรขึ้นบ้าง ลองคิดถึงคนสองคน งานชิ้นเดียวกัน คนแรกใช้เวลา 1 ชั่วโมง ส่วนคนที่สอง ใช้เวลาเพียง ครึ่งชั่วโมงเสร็จ แปลว่าอะไร แปลว่า คนแรกทำงาน ทำงานมากกว่า คนที่สองอย่างไรล่ะ เพราะคนแรกทำงาน ไป 1 man-hour ส่วนคนที่สอง ทำไปได้เพียง 0.5 man-hour เท่านั้น ในบริษัทที่ใช้ man-hour ในการประเมินงาน สิ่งที่จะพบเห็นเป็นประจำคือ หาคนมีฝีมือมาทำงานด้วยได้ยาก และยิ่งทำงาน ไป ทำงานไป คนทำงานมีแต่ลาออก และคนที่เข้ามาแทนก็มีทักษะลดลงไปเรื่อยๆ เพราะ คนที่ทำงานได้ช้าจะดูเหมือนทำงานได้มากกว่าคนทำงานเก่งนั่นเอง

เหตุเพราะ man-hour ถูกใช้ในการประเมินขนาดของงาน จึงมักจะใช้ในการคิดคำนวณต้นทุนไปด้วย เช่น โครงการนี้มีขนาด 500 man-hour เมื่อรู้ต้นทุนค่าแรงต่อชั่วโมง (เงินเดือน / จำนวนวันทำงาน / ชั่วโมงทำงานต่อวัน) ก็จะทำให้คิดคำนวณเป็นตัวเงินได้ ทีนี้เมื่อคำนวณต้นทุนได้ ราคานี้ก็จะถูกนำไปบวกกับกำไรที่ต้องการ แล้วคิดเป็นราคาขายไปด้วย ตามสมการ

ราคาขาย = ต้นทุน + กำไร

กลายเป็นลูกค้าก็จ่ายเงินตามจำนวนชั่วโมงที่ใช้ทำงาน และในเมื่อเป็นเช่นนั้น ผลกำไรก็สามารถคำนวนกลับมาเป็นชั่วโมงได้ด้วย เหตุนี้เอง เงินรางวัลก็จะแปรผันตามจำนวนชั่วโมงการทำงานไปด้วย ทุกอย่างจึงจบลงที่ คนจะทำงานหนักขึ้นเพื่อให้จำนวนชั่วโมงทำงานมากขึ้น กลายเป็นการทำงานล่วงเวลา และ ไม่มีใครหาทางที่จะพัฒนาการทำงานให้ใช้เวลาน้อยลง เพราะนั่นย่อมทำให้ผลตอบแทนน้อยลงไปด้วย นี่เองที่ทำให้ พนักงานมีแรงผลักดันที่จะพยามประเมิน(estimate) ขนาดงานให้มีขนาดเพิ่มขึ้นอยู่เสมอ

สำหรับลูกค้าและนายจ้างนั้นไม่ได้โง่ พวกเขาระแวดระวังเรื่องต้นทุนอยู่เสมอ และรู้ดีถึงช่องโหว่นี้ พวกเขาพยายามต่อรอง เพื่อให้ ค่าประเมิน(estimate) จำนวน man-hour ลดลงอยุ่เสมอ เพราะนั่นหมายถึงต้นทุนที่ลดลงเสมอ ซึ่งคือสิ่งสมเหตุสมผลในสายตาของพวกเขานั่นเอง

ความขัดแย้งนี้เองที่นำมาสู่การขาดความไว้เนื้อเชื่อใจระหว่างนายจ้างและลูกจ้างในการบวนการพัฒนาซอฟแวร์ เพราะฝ่ายหนึ่งก็จ้องที่จะประเมินให้โตขึ้น ส่วนอีฝ่ายก็พยายามต่อรองให้เล็กลง สุดท้ายฝ่ายนายจ้างมักจะชนะเพราะอำนาจที่เหนือกว่า และตามมาด้วย ปัญหาคุณภาพจากการพัฒนาซอฟแวร์ที่ไม่ได้มาตรฐาน ทั้งจากระยะเวลาที่น้อยเกินไป และทักษะของคนทำงานที่อยู่ในระดับต่ำกว่าที่ควรจะเป็น

ทั้งหมดคือปฐมบทของอไจล์ ว่าเกิดขึ้นมาได้อย่างไร และทำไมอไจล์จึงไม่ใช้ man-hour ในการประเมินขนาดงาน

Advertisements

10 thoughts on “ทำไมการประเมินแบบ man-hour จึงใช้กับซอฟแวร์ไม่ได้

  1. ถ้าอย่างนั้นแล้วฝั่งบริษัทที่ถูกจ้าง ที่จะใช้ agile หรือ scrum ทำงานให้ลูกค้า จะประเมินขนาดของโครงการสำหรับลูกค้าตั้งแต่เริ่มแรกอย่างไรดีครับ?

    ลูกค้าส่วนใหญ่โดยเฉพาะผู้นำฝั่งการเงิน (CFO) ก็มักจะอยากรู้ว่าถ้าเราจะให้บริษัทนี้ทำโครงการ จะใช้เงินเท่าไหร่ เสร็จใช้ได้จริงเมื่อไหร่ หรือหลายๆ ลูกค้าก็จะเปิดประมูลให้หลายๆ บริษัทเอาราคามาประชันกัน

    • แล้วจากประสบการณ์ที่ผ่านมา(ในการทำงานแบบ traditional) การประเมินล่วงหน้าแบบนั้น ถูกต้องตรงกับความเป็นจริงแค่ไหนล่ะครับ ถ้าหากมันทำได้ถูกต้องจริง อไจล์คงไม่เกิดขึ้นหรอกครับ แต่เพราะในตอนเริ่มต้นโปรเจ็คไม่มีใครล่วงรู้ได้เลยว่า โปรเจ็คนี้ความจริงมี scope อย่างไร และจะต้องใช้เวลานานเท่าไหร่จึงจะสำเร็จ อไจล์จึงสร้าง feedback loop เล็กๆ ขึ้นอย่างต่อเนื่องเพื่อ ให้เราสามารถ learn and adapt ต่อความรู้ที่ค่อยๆ เพิ่มขึ้นตลอดโครงการได้

      ส่วน CFO สามารถ กำหนด วงเงินไว้ก่อนได้ แล้วกำหนดเวลาตายตัว แต่ปล่อยให้ขอบเขตของงานปรับเปลี่ยนได้ (fixed cost, fixed time, vary scope) หรือไม่ก็ กำหนด วงเงิน และขอบเขต ปล่อย ให้เวลาขยายได้ (fixed cost, fixed scope, vary time) การ fix ทั้ง 3 ตัวพร้อมกันคือความล่มจมของ quality ครับ

      ถ้าไม่เข้าใจบอกได้นะครับ จะได้บล็อกให้อ่านเพิ่มเพราะค่อนข้างซ้บซ้อนครับ

      • ขอบคุณครับ ผมเข้าใจครับว่า agile มีขึ้นมาเพื่ออะไรและมีผลดีช่วยแก้ปัญหาโครงการแบบดั้งเดิมยังไง

        จากประสบการณ์แล้วผมรู้สึกว่าลูกค้าที่ค่อนข้างจะหัวโบราณนิดนึง (ตัวอย่างเช่นองค์กรที่ธุรกิจหลักไม่ใช่ IT หรือพวกรัฐบาล)​ จะตั้งใจอยากจะปกป้องผลประโยชน์ตัวเอง ก็เลยเขียน requirement ออกมาหนาปึ้ก เวลาผลโปรเจคท์ออกมาสุดท้ายแล้วเป็นยังไง จะสามารถมานั่งเช็คกับบริษัทผู้ถูกจ้างว่าระบบมัน “ผ่าน” requirement พวกนั้นรึเปล่า ง่ายๆ ก็คือใช้ requirement พวกนี้เป็น “สัญญาของขอบเขต”​ ที่ลูกค้ากับบริษัทตกลงกันแต่แรก

        ผมก็เข้าใจครับว่าหลักการของ agile จะขัดแย้งรุนแรงกับความตั้งใจอันนั้น แต่มีอีกคำถามครับ เอาเป็นว่าสมมติเราสามารถโน้มน้าวลูกค้าพวกนี้ให้ทำโปรเจคท์แบบ fixed cost, fixed time, vary scope อย่างที่คุณบอก และสมมติว่าลูกค้ายอมที่จะจ่ายเงินเราแบบ time & material เราจะทำยังไงที่จะปกป้องทั้งฝั่งลูกค้า และฝั่งเราให้ว่าตอนสุดท้ายแล้วต่างฝ่ายพูดไม่ได้นะว่าอีกฝ่ายนึงเอาเปรียบโดยที่เราไม่ได้มี “สัญญา”​ เอาไว้แต่แรก ตอนจบลูกค้าอ้างได้ง่ายๆ ว่า เราไม่รู้สึกว่าบริษัทคุณทำงานให้กับเราคุ้มค่าเต็มที่ เราเคยใช้อีกบริษัทนึงใช้เงินน้อยกว่าแต่ให้ผลงานได้มากกว่า (ได้หน้าเว็บเยอะกว่า ระบบซับซ้อนกว่า) โปรแกรมเมอร์เอาแต่อู้ไม่ทำงาน 40 ชั่วโมงต่อวัน หรือ พวกโปรแกรมเมอร์ของคุณมาทำงาน 8 ชั่วโมงก็จริง แต่แต่ละคนเป็นเด็กจบใหม่ ไม่ได้มีประสบการณ์ที่จะทำโครงการให้กับเราอย่างมีประสิทธิภาพเต็มร้อย ฯลฯ

  2. ในโลกปัจจุบัน ปัญหาที่คุณเจอได้ถูกแก้ไขไปแล้วครับ เราไม่จำเป็นต้องอธิบายสิ่งใดเลย เพราะลูกค้าก็มีคู่แข่งขัน ในขณะที่คู่แข่งก้าวเร็วกว่าเดิมอย่างไม่เห็นฝุ่น พวกเขาก็ต้องก้าวตามให้ทัน อไจล์โด่งดังมาไม่ใช่เพราะสมัยนิยม แต่เป็นเพราะ ทุนนิยม องค์กรธุรกิจใดไม่ปรับตัวให้เร็วพวกเขาก็จะถูกทิ้งห่างและตายในที่สุด ใครจะเคยคิดว่า บริษัทอย่าง Koduk SUN หรือ Nokia จะเกือบล่มสลายในชั่วชีวิตเรา บริษัทที่ทำธุรกิจแบบเดิมไม่ยอมเปลี่ยนจะไม่สามารถแข่งขันได้อีกต่อไป ซึ่งหมายความง่ายๆ ว่า เขาจะไม่มีเงินมาจ่ายคุณหรอก ไม่ใช่เร็วๆ นี้ ก็คงไม่ช้าเกินไป สิ่งที่คุณต้องตัดสินใจคือ จะจมอยู่กับรูปแบบเดิมๆ หรือปรับตัวให้เข้ากับความเปลี่ยนแปลงที่เกิดขึ้น ซึ่งผมเชื่อว่าคุณคงไม่ได้ทำธุรกิจของคุณอยู่คนเดียว คุณคงต้องมีคู่แข่งอยู่แน่ ถ้าหากพวกเขาก้าวได้เร็วกว่าคุณเพราะ เขามีลูกค้าที่พร้อมจะก้าวเร็ว แล้วขย้ำลูกค้าของคุณ ถามว่า คุณจะทำอย่างไร

    คงพอเห็นภาพนะครับ

    edited:
    อ้อลืมตอบข้อหลังไป

    ถ้าคุณจ้องจะเอาเปรียบลูกค้าแบบนั้น คุณก็ไม่สมควรเรียกตัวเองว่า มืออาชีพ ถ้าคุณไม่ได้ทำแบบนั้น แล้วลูกค้ามัวแต่จ้องว่า คุณจะเอาเปรียบ เขาก็ไม่เป็นมืออาชีพเหมือนกัน คุณต้องถามตัวเองว่า ทำไมเขาถึงไม่ไว้ใจคุณและคิดแต่ว่าคุณจะเอาเปรียบอย่างนั้น

  3. ขอบคุณครับ คุณคงคิดว่าผมหัวโบราณน่าดู :-)

    ช่วยชี้แนะทีว่าปัญหาอย่างที่ผมกล่าวมา ถูกแก้ไปยังไงครับ? จุดที่ผมต้องการพูดไม่ได้บอกว่า waterfall เป็นทางเดียวที่จะปกป้องผลประโยชน์สองฝ่าย แต่คำถามหลักๆ ผมคือเราจะวัดยังไงว่าโครงการ agile ประสบผลสำเร็จตรงตามที่ลูกค้าตั้งใจไว้ และตกลงกับบริษัทถูกจ้างแต่แรก

    • เปล่าเลยครับ ผมรู้สึกว่าคุณเป็นคนธรรมดาคนหนึ่ง สิ่งที่ผมพูดแม้จะ เรียบง่าย แต่ก็ยากนักที่คนที่ไม่เคยสัมผัสจะเชื่อได้ว่ามันมีอยู่จริง

      การสร้างความไว้เนื้อเชื่อใจไม่ใช่ของง่ายครับ ต้องใช้เวลาสร้างสม ผมไม่ได้บอกว่า จู่ๆ คนเราจะเชื่อใจกันได้เลยหรอกครับ ต้องสร้างด้วยความยากลำบาก แต่ก็ไม่ใช่ว่าเป็นไปไม่ได้ มันเป็นไปได้ และมีคนทำได้มากมาย

      คนเราไม่ได้จะชั่วไปหมดทุกคนหรอกครับ คนเราเหมือนเหรียญสองด้าน เราต้องทำให้เขาหันด้านดีๆ มาหาเรา ด้วยการหันด้าน ดีๆ ของเราเข้าหาเขาเช่นเดียวกัน

      ผมตอบง่ายๆ ว่า เขาจ้างเราต่อ นั่นแหละครับตัวชี้วัดที่ดีที่สุด ผมไม่ได้พูดเล่นนะ งานที่ทำอยู่ปัจจุบันผมทำงานโดยไม่มีการทำสัญญายาวๆ รอบการทำงานคือ 2 สัปดาห์ ถ้าลูกค้าไม่พอใจ สามารถยกเลิกได้ตลอดเวลา แต่ก็มีการวางแผนล่วงหน้า เช่น phase แรก ราว หกสัปดาห์ ก็มีการวางแผนคร่าวๆ อย่างชัดเจน และก็ไม่ใช่ว่า ต้องรอ จนจบแล้วค่อยมาวัดผลให้ feedback ทุกอย่างเกิดขึ้นอย่างต่อเนื่อง realtime

  4. ขอบคุณครับ ในที่สุด ย่อหน้าสุดท้ายของคุณตอบคำถามผมซักที

    อยากถามต่อว่าตอนเริ่มโครงการที่คุณทำอยู่มี documentation อะไรบ้างที่ลูกค้ากับฝั่งคุณใช้ ต้องมีรายละเอียดขนาดไหนครับ

ใส่ความเห็น

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / เปลี่ยนแปลง )

Twitter picture

You are commenting using your Twitter account. Log Out / เปลี่ยนแปลง )

Facebook photo

You are commenting using your Facebook account. Log Out / เปลี่ยนแปลง )

Google+ photo

You are commenting using your Google+ account. Log Out / เปลี่ยนแปลง )

Connecting to %s