ประสบการณ์ตอนทำงาน ตอน การให้และขอ Requirement Path 2

ความคาดหวัง

อีกหนึ่งเรื่องที่ Dev อยากให้คนที่รับ Requirement หรือคนที่จะให้ Requirement คุยกันก่อนคือเรื่องความคาดหวัง ความคาดหวังมันคืออะไรผมก็ให้นิยามมันแบบตรงๆไม่ได้แต่พออธิบายเป็นภาษาบ้านๆได้ก็คือ ตกลงกันว่ามันจะทำงานได้ในระดับไหน ดีแค่ไหน ตัวอย่างความคาดหวังง่ายๆที่เห็นบ่อยๆคือ ถ้าคุณซื้อของแพงกว่าราคาตลาดทั่วไป เช่น ซื้อ IPhone คุณก็จะเริ่มมีความคาดหวังว่ามันจะต้องดีกว่าของที่ราคาตลาดอย่าง SAMSUNG, Nokia , อาม่า อันนี้ไม่ได้บอกของใครดีกว่าใครแต่มันเป็นค่านิยมที่ถูกตลาดปลูกฝังว่ายี่ห้อนี้ดีกว่าอีกยี่ห้อนึงซึ่งในความเป็นจริงอาจไม่ใช่เลย (ลองหาอ่านเรื่องการเปรียบเทียบถ่านไฟฉาย ไปๆมาๆไฟฉายยี่ห้อที่เราคิดว่ากากกลับมีประสิทธิภาพดีกว่าถ่านไฟฉายมียี่ห้อ https://pantip.com/topic/31504294 )

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

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

หรืออีกเคสสำหรับใครดู EndGame แล้วคาดหวังกับ Captain Marvel ผมบอกเลยว่าเฮ้อออออ จริงๆมันเกิดจากที่เราคาดหวังมันมากไปว่าจะต้องแบบนั้นแบบนี้พอออกมาน้อยกว่าคาดก็จะอารมณ์นี้

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

ส่วนสิ่งที่ทีม Dev คาดหวังเวลาคนไปรับ Requirment ไปคุยกับลูกค้า ทาง Dev ก็อยากจะให้คุณตั้งค่าความคาดหวังกับลูกค้าประมาณว่า

• อาจจะได้ภายในวันนี้นะครับแต่อาจจะมีปรับเปลี่ยนนบางเรื่องที่ทางเราเห็นว่าอาจจะกระทบต่อระบบ ซึ่งถ้ามีอาจจะเลื่อนนะครับ
• ถ้าจะเอาให้ทันภายในวันนั้น อาจจะต้องลด Scope เหลือเท่านี้
• ถ้าเอาแบบนี้ไม่น่าจะได้ครับ แต่ถ้าเป็นแบบนี้ได้ไหมครับ ให้ผลลัพธ์เหมือนกัน

Requirment ของ Report

สำหรับงานที่ผมเจอบ่อยๆและหงุดหงิดบ่อยๆคือ Report คือ Requirment ที่เคยได้มาคือ ทำ Report นี้ให้ที คำถามของทาง Dev ก็คือ Report เ-ี้ย อะไร บอกให้ทำแต่ไม่รู้ว่า Report ที่ออกมาหน้าตาเป็นยังไง Format ที่ออกเป็นแบบไหน แล้วจะออกด้วยเงื่อนไขอะไร โอเคเราจะมาลองสรุปคร่าวๆว่า Dev อยากได้อะไรเวลาจะทำ Report จริงๆผมอยากจะบอกว่าพวกเราทีม Dev ควรจะพึงระลึกเสมอว่าเมื่อโดนสั่งทำ Report ควรถามห่าอะไรพวกนี้เสมอ

หน้าตา

หน้าตาของ Report ที่อยากให้ออกมาเป็นแบบไหน Excel , csv , PDF แล้วจะดีหน่อยคือไปเอาตัวอย่างที่เขาเคยมีในระบบเก่าหรือมีอยู่แล้วมาเป็นตัวอย่างประกอบด้วย ทางทีม Dev ดูแล้วจะได้รู้ว่ามันทำได้ ทำไม่ได้ คุ้มค่าไหมที่จะทำ

Field

Field ที่จะเอาไปใส่ใน Report คืออะไร ไปเอามาจากไหน ถ้าคนที่ทำงานเป็นหรือทำงานมานานก็จะ capture ว่าเอามาจากฟิลล์นี้ในหน้าจอ หรือระบุรายละเอียดต่างๆนาๆให้

ชื่อไฟล์

อันนี้ก็เป็นประเด็นเหมือนกัน คือตอนมาสั่งบอกเอาแต่ Report แต่ไม่บอกว่าออกมาจะมีชื่อไฟล์อะไร อันนี้ก็เป็นปัญหาเหมือนกัน เคยมีงานนึงผมให้ออกเป็น Format : ReportName_20191231_110231.xlsx แต่พอขึ้น PROD ไปแล้วกลับไม่พอใจ อ้าวไอสาดไม่บอกมานี่

เงื่อนไขการออก Report

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

Report มันต้อง Realtime แค่ไหน

นี่เป็นอีกคำถาม Classic เกี่ยวกับ Report ที่คนที่ไปคุยกับลูกค้า หรือ ลูกค้าที่ให้ความต้องการรู้ คือ Report ของคุณอะ Realtime แค่ไหน Realtime คือกดตอนนี้ต้องได้ตอนนี้เลย ข้อมูลต้องเป็น ณ ป้จจุบัน หรือจริงๆคุณอยากได้ Report สรุปผลรายเดือน ทั้ง 2 อย่างต่างกันมากเลยนะ ถ้าคุณอยากได้ Realtime มันต้องใช้เทคนิคและทรัพยากรมหาศาลในการทำ (ซึ่งยากมากแต่คนไปรับบอกสบายมาก แล้วไปตั้งค่าความคาดหวังกับลูกค้าไปแล้ว) แต่ถ้าเป็น Report สรุปรายเดือนมันจะเป็นคนละแบบ ระบบสามารถค่อยๆทำผลสรุปเรื่อยๆรายวันแล้วมารวมเป็น Report ตอนปลายเดือน ข้อมูลที่ได้จะเป็นแบบ T + 1, T +2 คือถ้าจะเอาข้อมูลวันนี้มันจะได้วันพรุ่งนี้ หรือ มะรินนี้ อันนี้สามารถทำได้โดยไม่ต้องมีเทคนิคอะไรมาก ไม่ต้องใช้ทรัพยากรเยอะเท่าแบบ Realtime แบบแรก

กดแล้วได้เลย หรือ กดแล้วค่อยมาดูทีหลังได้

อันนี้เป็นอีก Requirement และความคาดหวังที่ควรตกลงให้ กดแล้วได้เลยคือ กดแล้วลูกค้าต้องนั่งแช่รอสัก x วินาทีแล้วได้ Report กลับมา การทำแบบนี้บอกเลยว่ากินทรัพยากรมาก เพราะคุณต้องทำการสร้าง Report ให้ทัน x วินาทีที่กำหนด ส่วน กดแล้วค่อยมาเอาจะประมาณว่า กดสั่งสร้างแล้วระบบรู้ว่าอยากให้สร้าง Report เดี๋ยวระบบเอาไปทำให้นะ รอไปเดี๋ยวได้ Report แน่ แบบนี้จะดีกว่าแบบแรกเพราะคุณสามารถเอางานไปรอไว้ก่อนรอ Server ทำงานไม่หนัก หรือ ช่วงเวลาที่มีไว้สำหรับการออก Report หรือ ส่งไปให้ระบบทีทำการออก Report โดยเฉพาะ ทำการออก Report ซึ่งอาจจะนานกว่าเวลาที่ผู้ใช้มากดแล้วต้องนั่งรอ ลองคิดว่านั่งรอ 5 นาทีกว่า Report จะออกมา กับ การตั้งค่าความคาดหวังว่า ระบบรับเรื่องการออก Report แล้วกำลังนำไปออก Report คุณว่ามันดีกว่าการที่เขามานั่งรอหน้าจอทำงานอื่นไม่ได้ 20 นาทีไหม

ข้อพึงระวังกับ Report

พวกนี้เป็นเรื่องที่พึงระวังกับ Report เป็นเรื่องที่คนสั่งคนทำหรือทุกคนที่เกี่ยวข้องควรจะทราบเกี่ยวกับ Report

Report ที่กดข้อมูลอาจไม่เท่ากันถ้ากดคนละเวลา

อันนี้เป็นอีกเรื่องที่ชอบมาโวยวายกันคือกด Report ตอนนี้ได้ผลแบบนึง กด Report อีกเวลาได้ผลอีกแบบ คุณควรเข้าใจนิดนึงว่าข้อมูลที่เอามาจาก Database ถ้าคุณอยากได้ Realtime แล้วมันมีการเปลี่ยนสถานะของข้อมูลจาก A ไป B ซึ่งถ้าเงื่อนไขในการออก Repot มันมีสถานะพวกนี้อยู่ในเงื่อนไข ผลลัพธ์ที่ออกมาก็ย่อมเปลี่ยน

ระบบมันไม่ได้มีไว้ออก Report

ระบบ Application ส่วนใหญ่เขาออกแบบมาเพื่อรับงานที่เป็นงานหลักของ Application เช่น เว็บนำเข้าส่งออกเขาก็มีระบบไว้รองรับการแจ้งนำเข้าส่งออก หรือ Shopee เขาก็ออกแบบระบบมารองรับการสั่งซื้อสินค้า หรือ Agoda เขาก็ออกแบบระบบมาให้คนจองโรงแรม เปรียบเทียบราคาโรงแรม เขาไม่ได้ทำระบบมาเพื่อออก Report ดังนั้นบริษัทใหญ่ๆพวกนี้เขาก็จะมีกระบวนการนำข้อมูลไปออก Report ที่ระบบอื่น หรือถ้าอินเทรนหน่อยเขาจะเอาข้อมูลไปเทรน AI แต่คงไม่มีระบบไหนเขาเทรน AI บนระบบหลักครับ ดังนั้นพึงระลึกเสมอว่าระบบมันไม่ได้มีไว้ออก Report ถ้าเป็นระบบเล็กๆ Report กระจอกงอกง่อยนิดๆหน่อยๆมันออกได้ครับ แต่ถ้ามันเริ่มเป็น Report ที่ complex มากๆแบบ ผลรวมของสาขานี้นั่นโน่นนี่รายเดือนรายปี หรือ สรุปการทำงานของแต่ละคนในช่วงเวลาต่างๆโดยเงื่อนไขหลากหลาย หรือ เมื่อใดที่ Dev บอกว่าเห้ยมันเกินระบบรับไหว ก็พึงระลึกเถอะครับว่าเขาพูดจริง คือเวลามีปัญหาใครจะเป็นคนปวดหัวมากกว่ากันระหว่างคนที่ไปบอกลูกค้าว่าระบบมีปัญหา กับคนที่ต้องมาแก้ปัญหาหน้างานโดยมีเวลาจำกัด แบกรับความเครียด และงานต้องออกมาถูกต้อง ไม่มีใครอยากอยู่ในสถานะนั้นดังนั้นเมื่อเขาพูดแปลว่ามันจะเกิดปัญหาแล้ว

เพลงประกอบการเขียน Blog

จงให้ความสำคัญกับทุกการพบเจอเพราะมันอาจเป็นครั้งสุดท้ายแล้วที่เราจะได้พบกัน