Soft Skills: Business Conversation

เมื่อเราทำงานในบทบาทที่เติบโตมากขึ้น ไม่ว่าจะเป็น Tech Lead/ Development Manager/ Influencer ก็ตาม สิ่งหนึ่งที่เป็นสิ่งสำคัญต่อทีมไม่น้อยไปกว่า Technical Background ที่แข็งแรงก็คือ การสร้าง business conversation ที่จะสนับสนุนการทำงานของทีมเราให้สามารถฝ่าฟันการทำงานไปได้อย่างราบรื่น

อย่างที่รู้กันว่าบริษัทส่วนใหญ่ในโลกไม่ได้มี IT เป็น core value หรือต่อให้มี IT เป็น core value ก็ตาม สิ่งที่จะทำให้บริษัทสามารถเดินต่อไปได้ก็คือ business value ของบริษัท เพราะฉะนั้นต่อให้เราไม่ชอบมันยังไง สักวันหนึ่งเราก็ต้องไปอยู่ในจุดที่จะต้องประสานประโยชน์ของบริษัทด้วยการอยู่ตรงกลางระหว่างสองโลกนี้อยู่ดี ดังนั้นคงจะมีประโยชน์มากถ้าเราได้มาเรียนรู้เกี่ยวกับเรื่องนี้กัน และเข้าใจว่าบริษัทสนใจอะไรจาก Tech Team และเราสามารถสร้างสมดุลให้บริบทของทั้งสองทีมได้ นั่นหมายถึงแนวโน้มที่ดีในการทำงานร่วมกันของ business team และ tech team ได้เกิดขึ้นแล้ว แล้วอะไรบ้างที่เราควรจะต้องเตรียมตัวไปก่อนไปคุยกันนะ

1_2KcMwLSDD5FK5i-mvFA5mQ

Business Focus — เป็นการดีที่เราจะกลับมาทบทวนก่อนว่าในช่วงที่เรากำลังเตรียมนี้ รวมไปถีง periord ต่อๆไป องค์กรได้วางโฟกัสไปที่อะไรบ้าง และสิ่งที่เรากำลังเสนอนั้นมัน align ไปกับโฟกัสขององค์กรหรือไม่ เพื่อที่จะชั่งใจดูว่าเราจะเข้าไปนำเสนอด้วยกลยุทธ์แบบไหน เช่น reinforcement กับ focus ที่มี หรือ จะทำให้เกิดความแตกต่างไปเลย หรือแม้แต่จะสนับสนุนให้เกิดการแข่งขันภายในองค์กรไปเลยก็แล้วแต่ การมอง theme ของธุรกิจให้ออกว่า เรากำลังเดินไปในทิศทางไหน กำลังโฟกัสที่อะไรเป็นจุดที่ดีที่จะให้เรา self-review ก่อนที่เราจะเริ่มบทสนทนา

Benefit /fixed/ measurement— สิ่งที่เรากำลังเสนอนั้น ทำประโยชน์อะไรให้กับองค์กร ในการนำเสนอเรื่อง benefit นี้ขอให้นึกถึง business value ขององค์กรจริงๆ ไม่ใช่ benefit ของเราหรือทีมเท่านั้น หลายครั้งการนำเสนอโครงการทางไอที เราไม่ได้มองให้ถึงแก่นว่าเรากำลังแก้ปัญหาอะไร หรือเรากำลังสร้างคุณค่าอะไรให้กับองค์กร แต่เป็นการฟาดฟันกันด้วย buzz word เพื่อให้องค์กรมีพื้นที่ในสื่อเท่านั้น ยกตัวอย่างเช่น กิ๊กอยากเสนอโครงการแปลงระบบเดิมที่มีอยู่ให้เป็น Microservice ถ้ามองด้วยบริบททางเทคโนโลยีแล้ว เป็นสิ่งที่ sexy มากสำหรับ developer เพราะเขาสามารถไปบอกคนอื่นๆได้ด้วยความภูมิใจว่ากูทำและขึ้น production มาแล้ว แต่คุณค่าที่แท้จริงที่เราได้ deliver ไปนั้นคืออะไร องค์กรได้ประโยชน์จากการทำ microservice หรือไม่ และประเมินได้อย่างไรต่างหาก เช่น ในกรณีนี้ ถ้ากิ๊กได้ทำ benchmark แล้วนำเสนอไปด้วยข้อมูลที่มีว่า

Monolith ที่มีอยู่เดิมนั้น มีส่วนที่สามารถแยกออกมาเป็น microservice แล้วสามารถทำให้ลดความซับซ้อนของการบำรุงรักษาได้ โดยสามารถ ลด code conflict ลงได้ 5–10%
สามารถทำให้ code review ได้เร็วขึ้นโดยส่งผลให้สามารถลดเวลา lead time ลงได้ถึง 10 นาที
ทำให้ feature ที่จำเป็นต่อธุรกิจเร็วขึ้น 50 ms ซึ่งทำให้มี bandwith ของผู้ใช้งานเพิ่มขึ้น 100 คน/วินาที และสุดท้ายทำให้สามารถเพิ่มความสามารถในการแข่งขัน หรือสามารถนำไปลด cost ของ cloud ในการ scale ที่ peak time ได้
เหมือนที่เคยเล่าใน blog ก่อนๆ หลายครั้งว่า เราไม่สามารถบอกได้ว่าเราได้ปรับปรุงให้อะไรดีขึ้นถ้าเราไม่เคยวัดเลย เพราะฉะนั้นแล้ว ก่อนจะนำเสนอถ้าเราสามารถ benchmark แล้วนำเสนอให้เห็นว่า “การปรับปรุงด้านเทคนิคสามารถช่วยสร้างคุณค่าให้ธุรกิจได้อย่างไร” และ “สามารถวัดผลความสำเร็จของโครงการได้อย่างไร” การสนทนาครั้งนี้จะทำให้คุณสามารถได้สิ่งที่ทีมอยากทำ (technical แบบคูลๆ) และ business ต้องการ

Cost — ต้นทุนในการทำโครงการนี้ อันนี้ค่อนข้างตรงมาตรงไป อย่าลืมว่าต้นทุนสำคัญของโครงการด้านไอทีมีอยู่หลายอย่างด้วยกัน และจะเป็นการดีที่เราได้ทำรายการของต้นทุนที่เราต้องการเพื่อให้โครงการสามารถสำเร็จไปได้ ใน PMI มักจะพูดเป็น category เช่น direct cost/indirect cost/variable cost และ fixed cost แต่ผมอยากจะให้ลองแบ่งง่ายๆแบบนี้ดูก่อน

ต้นทุนเวลา — อันนี้มองได้สองมุมคือ ถ้าเราทำเราเสียไปเท่าไหร่ และถ้าเราไม่ทำเราเสียไปเท่าไหร่ บางครั้งการเลือกไม่ทำมีผลเสียมากกว่าการเลือกที่จะทำ เพราะมีต้นทุนที่เรียกว่า Cost of opportunity เสมอ

ต้นทุนค่า License — ค่า License นี่เป็นเรื่องที่น่าปวดหัวมาก เพราะแต่ละบริษัทมักจะมีวิธีการกำหนด license ให้ซับซ้อนจนเราปวดหัวต้องไปพึ่งพาให้บริษัทช่วยเท่านั้น แต่หลังๆนี้มักจะใช้ Free/Opensource software ที่มีโมเดลที่ชัดเจนมากกว่า จึงสบายใจไปได้ แต่ก็จะไปหนักที่ต้นทุนของ Operation และ Hardware ที่ต้อง maintainace มากกว่า

ต้นทุนค่า Hardware — อันนี้เอาที่สะดวกครับ หลายที่นิยมใช้ cloud แต่หลายๆที่ก็ยัง classic กันไป เพราะ license ของ enterprise หลายเจ้าไม่มี model สำหรับ cloud หรือ virtual machine/container

ต้นทุนค่า Operation —ค่า Operation คือต้นทุนในการที่จะให้โครงการนี้เกิด ไปจนทำให้มันมีชีวิตอยู่ได้ ซึ่งมักจะรวมทุกอย่าง โดยเฉพาะ“คน” หลายๆครั้งเราไม่ได้คิดไปถึงส่วนนี้ เพราะเมื่อเรา hand over โครงการไปแล้วมันไม่ได้อยู่ในมือเราไง เราต้องคิดไปถึงว่าโครงการนี้จะต้องอยู่ไปอีกกี่ปี โดยแต่ละปีนั้นมีส่วนของ Operation Expense ที่ต้องจ่ายอีกเท่าไหร่ รวมถึงการปรับปรุงมันอย่างต่อเนื่องจนกว่าจะ decommission โครงการออกไปนั้นจะต้องคิดถึงอะไรอีกบ้าง เช่น ถ้าเราจะ break monolith ออกเป็น microservice เราจะทำให้มี role คนที่ต้องทำงาน operation ใน development team เพิ่มตามจำนวน service ไหม เราต้องมี NOC เพิ่มขึ้นมาสำหรับ monitor ระบบใหม่อีกหรือเปล่า ลองคิดแบบ end-to-end เลยจะได้เห็นภาพเยอะๆ
ก่อนการเริ่มบทสนทนานั้น อย่าลืม Recheck ว่าเรามองเห็นภาพต่างๆ ครบถ้วนหรือยังนะครับ

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

BeyondCoding