เรื่องมันเศร้าขอเหล้าเข้ม ๆ ตอนที่ 3 อไจล์ใน Non-IT ไม่มีอยู่จริง
ใน 2 ตอนก่อนหน้านี้ ทั้งตอนของ นนท์ (NON) และอิฐ (IT) ทั้งคู่ใช้ชีวิตกับเส้นแบ่งระหว่าง IT กับ Non-IT
ส่วนตัวผมเอง นอกจากผมจะคิดว่าอไจล์ใน Non-IT ไม่มีอยู่จริงแล้วนั้น ทั้งเส้นแบ่งระหว่าง IT และ Non-IT ก็ไม่มีอยู่จริงเช่นกัน
เส้นแบ่งนี้มันอาจจะเคยมีประโยชน์ในสมัยก่อน สมัยที่ไอทียังเป็นส่วนเล็ก ๆ ในองค์กร แต่ในธุรกิจวันนี้ มีบริษัทไหนที่ยังสามารถขับเคลื่อนโดยไม่ใช้ไอทีได้อยู่บ้าง? ความคล่องตัวในธุรกิจมันผูกพันธ์กับความยืดหยุ่นในระบบไอทีอย่างแน่นหนา ทุกองค์กรต่างปรับตัว เรียนรู้ ทุก business unit ต่างต้องการมีไอทีเป็นของตัวเอง ต้องการให้ซอฟต์แวร์มันปรับเปลี่ยนได้รวดเร็วยิ่งขึ้น เพื่อที่จะได้แข่งขันในธุรกิจได้ทันการ
คำถามที่ผมไม่เข้าใจคือ ในบริบทของทุกวันนี้ การขีดเส้นแบ่งระหว่างไอทีกับ business ยังมีประโยชน์อีกหรือ?
เดิมเราแบ่ง จะได้เห็นชัด ๆ ว่า cost ของไอทีมันสูงขนาดไหนแล้ว เราจะได้จำกัด cost ของมันได้ เพราะเราคิดว่าซอฟต์แวร์ไม่ใช่ core business หลักของธุรกิจเรา แต่วันนี้การมองไม่เห็น cost ไอทียังเป็นปัญหาที่สำคัญที่สุดอยู่อีกไหม?
อไจล์ใน Non-IT
บ่อยครั้งเวลาผมเห็นคำว่าอไจล์ใน Non-IT ถูกอ้างถึง มักจะเป็นบริบทที่ยังมีเส้นแบ่งระหว่างไอทีกับ Non-IT อย่างชัดเจน (ดูชื่อสิ) และเป็นการเอา practice ของอไจล์ไปปรับใช้ในบริบทที่ไม่ใช่ไอที
อย่างไรก็ดี อไจล์ไม่ใช่สิ่งใหม่ ถ้าเราไปดูประวัติศาสตร์ของอไจล์ จะพบว่าจริง ๆ แล้ว อไจล์เอาไอเดียดี ๆ ในบริบทอื่น ๆ มาปรับใช้ในการพัฒนาซอตฟ์แวร์ หลักของ queuing theory, หลักของ Lean manufactoring หรือหลักของ Toyota Production System มันมีมาตั้งแต่ก่อน Agile Manifesto จะเกิดเสียอีก ถ้าแบบนั้นแล้ว อไจล์ก็เป็นเหมือนอุปมาอุปมัยเอาของนอกการทำซอฟต์แวร์มาปรับใช้ในการทำซอฟต์แวร์ ดังนั้นการเอาของในอไจล์กลับไปปรับใช้นอกการทำซอฟต์แวร์ก็เลยเป็นเรื่องทั้งตลกและอันตราย
อันตรายยังไง?
เพราะทุกครั้งที่เรา “ปรับ” ใช้ เราก็บิดสิ่งนั้นออกไปจากบริบทดั้งเดิมของมันไปนิดนึง จะดีกว่าไหมถ้าเราจะกลับไปหารากของไอเดียดี ๆ เหล่านี้ แล้วเอาแก่นของหลักการนั้นมาปรับใช้ในบริบทของเรา ดีไม่ดี ไอเดียดี ๆ ที่เราเห็นในอไจล์ อาจจะมีรากมาจาก domain ที่เราอยู่อยู่แล้วก็ได้
และถ้าเรายังยืนยันที่จะใช้อไจล์จริง ๆ เราควรกลับไปที่ Manifesto 4 ข้อและ principle 12 ข้อ เพราะถ้าเราไม่ทำตามสิ่งนั้น ผมก็ไม่รู้ว่าเราจะเรียกสิ่งที่เราหยิบยืมไปว่าอไจล์ได้อย่างไร ทำให้ผมนึกถึงคำแซวว่า
they’ve got the move, not the point (เค้าลอกไปแต่กระบวนท่า ไม่ได้แก่นของมันไป)
และถ้าเราเห็นพ้องต้องกันว่าการ follow principle ทั้ง 12 ข้อเป็นเรื่องสำคัญในการปรับใช้อไจล์ บอกผมทีว่าคุณทำตาม principle ข้อโปรดของนนท์ที่ว่า
Business people and developers must work together daily throughout the project.
ในบริบทที่มีเส้นแบ่งระหว่างไอทีและ Non-IT ชัดขนาดนั้นได้อย่างไร?
จะดีกว่าไหม ถ้าเราจะเลิกให้ความสำคัญกับเส้นแบ่งนั้น เลิกรุม CTO หรือ CIO บนบอร์ดบริหาร แล้วกลับมานั่งหาคำตอบว่าพวกเรามารวมตัวกันในองค์กรนี้ เพื่อส่งมอบคุณค่าอะไรให้โลกใบนี้ แล้วลองหาทางแบ่งเส้นใหม่ วางโครงสร้างใหม่ โครงสร้างที่ไม่ได้ไปลอกใครมา โครงสร้างที่พวกเราคิดขึ้นมาเองจากบริบทการทำงานของเราเอง เพื่อจะได้ส่งมอบรอยยิ้มให้กับผู้คนได้มากขึ้น โครงสร้างที่จะเปิดโอกาสให้วัฒนธรรมที่เราอยากให้เบ่งบานมันเติบโต โครงสร้างที่ปัญหาเรื้อรังเดิม ๆ ที่ติดอยู่กับโครงสร้างเก่านี้ไม่มีทางเกิดขึ้นได้อีก
อย่างในชุมชน ODDS เราก็มี department เดียว เรียกว่า software development department เป็นวง ๆ เดียวที่คนสองร้อยกว่าคนอยู่ในนั้น แล้วในนี้ไม่มีเส้นแบ่งว่าใครต้องทำอะไร เราไม่รู้หรอกว่าโครงสร้างนี้มันถูกไหม แต่ที่แน่ ๆ ในนี้ไม่มีใครชี้นิ้วโทษหน่วยงานอื่น เพราะมันทำแบบนั้นไม่ได้ เวลาที่ทั้งองค์กรมีแค่หน่วยงานเดียว :D
เราชอบเวลาที่มีคนนึงบอกว่า หน่วยงานเธออ่ะทำงานช้า ก็จะมีคนตอบว่า เออ หน่วยงานเดียวกับเธออ่ะแหละ
ถึงตรงนี้ ผม, นนท์ กับ อิฐ ก็ชนแก้วกัน
