สองสัปดาห์ที่ผ่านมาประชุมเยอะขึ้นมากๆ แต่รู้สึกว่าได้ทำงานเป็นชิ้นเป็นอันจากการประชุม ไม่ได้รู้สึกว่ามัวแต่ประชุมไม่ได้งาน
ทำให้เข้าใจอย่างนึง เวลาประชุมแล้วไม่มีประสิทธิภาพมันไม่ได้เกิดจาก Format ในงานประชุมเสมอไป แต่เรื่องนึงที่ทำให้ไม่มีประสิทธิภาพ รู้สึกว่าไม่ได้งาน คือ เวลาประชุมเพื่อ "สร้างความมั่นใจให้ผู้เกี่ยวข้อง"
ผมเริ่มเห็นว่าการประชุมแบบนี้ Effective ต่ำและกินพลังงานเยอะ ไม่ได้แปลว่าควรเลิก แต่แปลว่ามีช่องให้พัฒนาได้เยอะ
ในโดเมนการพัฒนาซอฟต์แวร์ เครื่องมือที่สร้างความมั่นใจที่ดีที่สุดคือ Working software รองลงมาคือ Demo ส่วนการทำสไลด์หรือการพูดคุยย้ำๆ ว่า โปรเจ๊กต์ยังไปได้ งานยังดี อันนี้สร้างความมั่นใจได้น้อยกว่าอย่างมาก แถมยังต้องพูดย้ำบ่อยๆ แล้วเปลืองเวลา
จะพบว่าเวลาคุณรัน Agile, Scrum, etc. แล้วคุณต้องสร้างความมั่นใจทุกๆ สองอาทิตย์ มันจะบังคับให้คุณต้องมี Demonstratable Progress ในเลเวลนั้น
และมันจะกระทบไปถึงวิธีเขียนโค้ด Process การทำงาน การวางโครงสร้าง
พอมาถึงหัวข้อนี้ ผมไม่ Buy เลยว่าพอทำ Scrum แล้วจะทำให้ Architecture ห่วย แต่มันต้องใช้ Architecture style และ Mindset ที่ต่างกัน
เช่น หลายคนเชื่อว่าคุณสมบัติของ Fundamental Architecture ที่ดีคือสิ่งที่ทำครั้งเดียวแล้วทนทานใช้ได้ตลอดกาล ซึ่งพอเปลี่ยนวิธีทำงาน คุณสมบัติที่สำคัญกว่าในการทำงานแบบ Agile (ที่มี Feedback loop สั้น) ถ้าต้องแก้ แก้ง่าย ทุกคนแก้ได้หมด เป็นคุณสมบัติที่มี Priority สูงกว่าความทนทานใช้ได้ไม่มีวันพังไม่ต้องแตะ ในโลกแบบ Agile
เขียนไปเขียนมาแตกหัวข้อไปหลายเรื่องแฮะ ขอสรุปหน่อยว่า Reflect อะไรได้บ้าง
- การประชุมเป็นเครื่องมือที่คนนิยมใช้เมื่อต้องการ "สร้างความมั่นใจให้ผู้เกี่ยวข้อง" แต่ มันเป็นเครื่องมือที่ Effective ต่ำมาก ถ้าประชุมอันไหนมีหน้าที่แค่ "รายงานให้คนเกี่ยวข้องสบายใจ" แปลว่ามี Room for improvement เยอะมาก อย่างเลเวลแรก จากสไลด์ 30 นาที คุณเปลี่ยนเป็นทำเป็นเดโม 5 นาที ได้ความมั่นใจมากกว่าโดยใช้เวลาน้อยกว่าเยอะ ถ้าเปลี่ยนเป็นแค่ Deploy working software แล้วบอกให้คนเกี่ยวข้องมาลองเล่นเองได้ ยิ่ง Effective เลยใช่มั้ย และสิ่งที่ Effective ที่สุดคือ ทำให้เขาเชื่อมั่นจนเขาบอกเองว่า "ไม่ต้องอัพเดทพี่แล้ว พี่ไว้ใจทีม มีอะไรให้พี่ช่วยมั้ย ถ้าไม่มี พี่เอาเวลาไปทำอย่างอื่นดีกว่าว่ะ" อันนี้คือ End game และตราบใดที่ยังไม่ถึงตรงนี้ เรายังสามารถหาทางดิ้นเพื่อพัฒนาได้เรื่อยๆ
- พอพัฒนาข้อแรกมันจะมากระทบ Process การทำงาน ไปจนถึงโค้ดที่เขียนแต่ละบรรทัดเลยนะ ซึ่งไม่เป็นไร กระทบก็กระทบ ผมไม่เห็นว่าเสียหายอะไร แต่ต้องเข้าใจว่ามันกระทบ ซึ่งบางครั้งกระทบไปลึกซึ้ง ถึงนิยามว่า Practice ที่ดีไม่ดีคืออะไร Architecture ที่ดีไม่ดีคืออะไร นิยามและความเข้าใจมันจะเปลี่ยนได้
เอาจริงๆ ผมขอบคุณประสบการณ์ตัวเองและอาจารย์ที่สอนสั่งมาหลายท่านว่าธุรกิจเขาคิดอะไรกัน คือผมมีประสบการณ์ในวงการ Startup ที่มี Exposure โดยตรงกับผู้เกี่ยวข้องมาตลอด ทำให้เวลาผมเรียงลำดับความเสี่ยงที่ทำให้โปรเจ๊กต์ล้มเหลวได้ ผมเรียงว่า
1. ทำไม่ได้ทรัพยากรไม่พอ อันนั้นลำดับหนึ่ง
2. ทำไปทำมา ระหว่างทางคนลงทุนขาดความมั่นใจจนถอนทุนแคนเซิลโปรเจ๊กต์ อยู่ลำดับสอง
แล้วปัญหาที่แบบวางโครงสร้างไม่ดี วางโค้ดไม่ดี ใช้ Tech stack ผิดแล้วล้มเหลวต้องแก้ไข ผมมองว่าเป็นความเสี่ยงลำดับล่างๆ อาจจะเกิน 10 ด้วยซ้ำไปมั้งถ้าแตกหัวข้อจริงๆ
ผมเลยไม่มีปัญหากับการ Bend ตัวโค้ด สถาปัตยกรรม โครงสร้าง เพื่อแก้ความเสี่ยงข้อ 2 ทำไงก็ได้ให้ทำให้คนเกี่ยวข้องมั่นใจไม่ถอนทุน ถ้าต้องมี Automated test ก็ต้องมี ถ้าต้องมี Evolutionary architecture ก็ต้องมี ถ้าวางอะไรลงไปแล้วต้องแก้ทีหลัง ก็ต้องทำ (ตรงนี้มันเถียงกับความเข้าใจผิดของหลายๆ คนได้อีกว่า การทำ Engineering practice ห่วยๆ จะทำให้ปั่นงานเร็วกว่า มีอะไรไปอัพเดทสร้างความมั่นใจบ่อยกว่า ซึ่ง ผมว่าไม่ใช่)
ซึ่งผมมองว่ามันเสี่ยงกว่าเรื่องที่ว่าเลือก Tech stack ผิด เลือกภาษาผิด แบบคนละเรื่องเลยนะ พวกนั้นไม่ทำให้โปรเจ๊กต์พัง แค่ทำให้เหนื่อยเฉยๆ อ่ะครับ