หัดเขียนโปรแกรมยังไงให้เก่ง?

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

ก่อนอื่น ต้องทำความเข้าใจพื้นฐานก่อน ว่า

“การเขียนโปรแกรม”​ มันเป็นเรื่อง “Skill การสื่อสาร”

ครับ ซึ่งหลายคนอาจจะงงว่ามันเป็นแบบนี้ได้ยังไง ทำไมมันเป็นแบบนี้ ซึ่งผมขออธิบายสั้นๆ ว่า เพราะว่าเราจะต้องสื่อสารสิ่งที่เราคิด อย่างเป็นระบบเบียบเป็นขั้นเป็นตอน ให้คนที่โง่ที่สุด ที่บังเอิญขยันและคำนวนเร็ว อย่าง “คอมพิวเตอร์” สามารถนำไปปฏิบัติได้

ปัญหาอันดับแรกๆ ที่ผมพบก็คือ “คิดเป็นขั้นตอนไม่เป็น”

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

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

ดังนั้นในการสื่อสาร เราจะมีปัจจัยตั้งต้นคือ “ชีท” และ “กลุ่มคน”​ และปลายทางที่เราต้องการคือ “ทุกคนในกลุ่ม ได้รับชีทที่ถ่ายเอกสารแล้ว” ถ้าจะสื่อสารเป็นกระบวนการแบบโปรแกรม หรือฟังก์ชั่นทางคณิตศาสตร์ ก็จะได้ลักษณะนี้

จำนวน = นับ(คนในกลุ่ม)
ชีทที่ถ่ายเอกสารแล้ว = ถ่ายเอกสาร(ชีท, จำนวน)
คนที่ได้รับชีท = แจกจ่าย(ชีทที่ถ่ายเอกสารแล้ว, คนในกลุ่ม)

เป็นต้น

ปัญหาอันดับต่อไปที่ผมพบก็คือ การให้ความสำคัญกับตัวภาษาโปรแกรมมากไปในตอนแรก (แต่น้อยไปในระยะหลังจากนั้น)

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

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

ทีนี้เมื่อเริ่มสื่อสารเบื้องต้นได้แล้ว ความเข้าใจในภาษาที่ดีขึ้น ก็จะมีประโยชน์ที่ทำให้เราสื่อสารได้ดีขึ้น กระชับขึ้น สวยขึ้น กินใจขึ้น ฯลฯ หลายคำที่เคยใช้อย่างเวิ่นเว้อ ก็อาจจะใช้คำเฉพาะไปเลย อย่างเช่น ลองพยายามสื่อสารคำว่า “หึง” โดยที่เราไม่รู้จักคำนี้สิ จะพบว่ามันยากมาก แต่พอรู้แล้วการสื่อสารจะกระชับขึ้น ง่ายขึ้น และผิดพลาดน้อยลง

ซึ่งก็เหมือนกับการเขียนโปรแกรมน่ะแหละ ที่ตอนแรกไม่จำเป็นต้องรู้ตื้นลึกหนาบางอะไรของภาษาโปรแกรมที่ใช้มากมายนัก รู้แค่งูๆ ปลาๆ ก็เพียงพอแล้ว แต่จะต้อง “หัดสื่อสาร” ให้เร็วที่สุดและเยอะที่สุดเท่าที่จะเยอะได้

ตัวอย่างง่ายๆ ผมเชื่อว่าแทบทุกคนรู้จัก

printf("Hello, world\n");

(หรืออะไรก็ได้ที่เทียบเท่ากัน ซึ่งแตกต่างกันไปตามภาษา) ซึ่งมักจะได้เรียนกันในคลาสแรก ไม่ก็หนังสือบทแรก แต่จะมีกี่คนเชียวที่ “เล่น” กับมันต่อ เอาไปหัดสื่อสารมันต่อ ลองหาดูว่าจะประยุกต์หรือพลิกแพลงมันอย่างไรได้บ้าง เช่น จะลองให้แสดง

Name            Lastname        Sword
Byakuya         Kuchiki         Senbonsakura
Sousuke         Aizen           Kyokazuigetsu

โดยช่องว่างให้เว้นว่างทั้งหมด 2 Tab และให้ได้โดยใช้ printf เพียงตัวเดียว ทำได้หรือไม่ อย่างไร อะไรทำนองนี้

======================================

สรุปสั้นๆ การเขียนโปรแกรมก็เหมือนกับการสื่อสาร คิดว่าทำอย่างไรให้สื่อสารเก่ง ก็ทำแบบนั้นกับการเขียนโปรแกรม หลายคนอยากจะพูดภาษาอังกฤษเก่ง แต่เจอฝรั่งทีไรวิ่งหนีทุกที ให้พูดก็ไม่ยอมพูด แล้วมันจะเก่งได้อย่างไร ต่อให้วันๆ นั่งท่องไวยากรณ์ นั่งท่องศัพท์ ก็ไม่เคยมีประโยชน์ … พูดในฐานะคนที่พูดได้ 3 ภาษา ฟังออก 4 อ่านออก 6 ภาษา (แต่เป็นงูๆ ปลาๆ ไม่ค่อยแข็งแรงเท่าไหร่ซะ 3) นะครับ

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

สุดท้ายคือ ให้ “ลงมือทำ” เพราะความ “อยากได้” มันไม่เคยมีประโยชน์เลย ถ้าไม่ “ลงมือทำ”

======================================

เรื่องสุดท้าย … แต่ก่อนอื่นต้องขอเล่าเรื่องตัวเองให้ฟังสักหน่อย ผมมีวิธีการเรียนเขียนโปรแกรมอยู่อย่างหนึ่ง ซึ่งโดยส่วนตัวแล้วมันเวิร์กสำหรับผม คือ

หัดให้ “มือ” เขียนโค้ด อย่า copy & paste เด็ดขาด และอย่าใช้สมองคิดโค้ดโดยไม่จำเป็น

เวลาผมจะหัดเขียนโปรแกรมในภาษาใหม่ และหัดจากหนังสือ ไม่ว่าจะเป็นหนังสือใครเขียน (และแน่นอน ว่าผมลองทำแบบนี้กับหนังสือตัวเองด้วย) ผมจะ “อ่านเนื้อหาผ่านๆ” ก่อน 1 เที่ยว จากนั้น “พิมพ์” โค้ดเหล่านั้นเองด้วย “มือตัวเอง” ผมจะไม่เคย copy & paste โค้ดในช่วงของการเรียนรู้เลย เพราะว่าสิ่งที่สำคัญที่สุดคือ มือผมต้องโค้ดเป็น

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

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

ซึ่งนี่คืออีกปัญหาที่ผมพบ ซึ่งเป็นปัญหา “ใหญ่ที่สุด” คือ ผู้ฝึกเขียนโปรแกรม ต้องการได้ผลลัพธ์สำเร็จรูปเร็วเกินไป ฉาบฉวยเกินไป ต้องการโค้ดที่เอาไป copy & paste ได้ กด compile & run เห็นผลลัพธ์ แล้วคนขยันหน่อย ก็อาจจะกลับมานั่งอ่านโค้ดบ้าง นอกนั้นก็ปล่อยๆ มันไป เพราะได้ผลแล้ว

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

ผมมีข้อสังเกต ว่าถึงระบบการศึกษาบ้านเรามันจะไม่ได้แย่ลงกว่าเดิมเท่าไหร่ แต่ทำไมคนเดี๋ยวนี้เขียนโปรแกรมแย่ลงกว่าเมื่อก่อนมาก ก็เพราะมันเริ่มต้น “ง่ายเกินไป” และ “ฉาบฉวยเกินไป” มีโค้ดอยู่แล้ว copy & paste ง่าย แค่ Ctrl+C, Ctrl+V ก็จบแล้ว หรือไม่ก็ download งานที่เสร็จแล้วมา unzip แล้วใช้งานได้เลย ดังนั้นโค้ดจะไม่ผ่านมือเลย ซึ่งนี่คือเรื่องที่หลายคนอาจมองว่ามัน “เล็กน้อย” แต่จริงๆ แล้วนี่คือเรื่องที่ “ใหญ่ที่สุด” เรื่องหนึ่ง

สมัยผมหัดเขียน C++ 98 (ที่เป็น Standard แรกที่มี STL) ผมซื้อหนังสือ The C++ Standard Template Library ของ Nicolai Josuttis มานั่งอ่านผ่านๆ ทั้งเล่มก่อน 1 เที่ยว และ “นั่งลอก” โค้ดทุกบรรทัดด้วยมือตัวเอง ทั้งเล่ม จากนั้นค่อยพยายามศึกษารายละเอียดอีกครั้งในเบื้องลึก

ซึ่งนี่เป็นวิธีเดียวกับที่ผมศึกษา Perl, Ruby, Objective-C, Mathametica, Haskell, OCaml, Scheme และภาษาอื่นๆ ที่ผมเขียนเป็น และเขียนพอเป็น

และนี่แหละ เป็นสาเหตุที่ผม “ไม่อยากให้โค้ด” สำหรับโปรแกรมจากหนังสือคู่มือเขียน iPhone App ของผม ซึ่งพิมพ์โดยสำนักพิมพ์ Provision

สรุปสั้นๆ: อยากเขียนโปรแกรมเก่ง ต้องหัด “เขียน” โปรแกรมครับ อย่าหัดแต่รันโปรแกรมที่คนอื่นเขียนแล้ว

======================================

หวังว่าคงจะเป็นประโยชน์บ้าง …​ จริงๆ แล้วเนื้อหาบทความนี้ คัดมาจาก “บทแรก” ของหนังสือเล่มใหม่ที่ผมกำลังเขียนอยู่ (ยังไม่มีชื่ออย่างเป็นทางการ แต่ประมาณ “คิดและโค้ด ผ่านภาษา Objective-C”) โดยดัดแปลงให้เหมาะกับการเป็นบทความบนเว็บ

รออ่านนะครับ ผมหวังว่าจะเป็นหนังสือที่ดี(นะ)

ทวนเข็มนาฬิกา

หมายเหตุ: บทความในตอนนี้เป็นส่วนหนึ่งของการบรรยายหลายต่อหลายครั้งของผม

เมื่อนานมาแล้ว ผมได้มีโอกาสอ่านหนังสือเรื่อง The Information Master ของ John McKean ซึ่งมีผลการสำรวจถึงเรื่องการลงทุนในด้านต่างๆ ทั้งตัวเลขที่ลงทุนจริง และตัวเลขที่ทาง McKean แนะนำว่าควรจะเป็น ดังนี้


mckean.006.jpg

ซึ่งแสดงให้เห็นว่า องค์กรทั้งหลายมีการลงทุนด้านเทคโนโลยีที่สูงเกินไป และมีการลงทุนด้านอื่นๆ ที่ต่ำเกินจากความเป็นจริงมาก

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

ผลที่ได้ทำให้ผมขนลุกทันที เพราะนี่คือสิ่งที่ผมแสวงหามานาน

ลองดู “สิ่งที่ควรเป็น” ดูก่อนนะครับ


mckean.005.jpg

อย่างที่บอกว่าผมไม่ได้สนใจอะไรมากมายนักกับตัวเลข แต่สนใจมากกว่าจะมีอะไรที่สะท้อนภาพสิ่งที่ผมคิดว่า “เป็นจริง” กับบ้านเราได้บ้าง และนี่ก็คือสิ่งนั้นครับ และภาพที่สิ่งนี้สะท้อนให้เราได้เห็นกันก็คือ “การพัฒนา” อะไรก็แล้วแต่ที่เราจะนึกออก ไม่ว่าจะเป็นระบบฐานข้อมูล ระบบสื่อสิ่งพิมพ์ดิจิทัล ระบบการศึกษา ระบบ ฯลฯ

เมื่อเราลองมอง “ภาพที่ควรเป็น” นี้ ภาพวงกลมที่เราเห็น ก็เหมือนกับ “หน้าปัดนาฬิกา” ที่เริ่มต้นเดิน ณ เวลา 0 คือเริ่มจากสีฟ้าอ่อน ซึ่งก็คือ “คน” ซึ่งจะเห็นว่า ต้องใช้ “ทรัพยากร” (เงิน เวลา ความพยายาม ฯลฯ) ประมาณ 20% และต้องเริ่มต้นจากจุดนี้ จากนี้เมื่อมี “คน” แล้ว ก็ต้องมีพัฒนา “กระบวนการ” เพื่อให้คนเหล่านี้ทำงานด้วยกัน สิ่งนี้จะต้องใช้ทรัพยากรอีกประมาณ 15% และเมื่อมี “คนที่ทำงานเป็นขั้นตอนกระบวนการ” เป็นแล้ว ก็ต้องจัดระบบระเบียบการทำงาน การประสานงานอื่นๆ หรือ “ระบบการทำงาน” (Organization) อีก 10% ต่อด้วยการพัฒนาวัฒนธรรมการทำงานของระบบการทำงานอีก 20% และเมื่อได้สิ่งเหล่านี้แล้ว ความรับผิดชอบเฉพาะทางที่เกิดจากความเชี่ยวชาญที่ได้ทำงานมา ซึ่งก็จะเกิดขึ้น และจะต้องพัฒนาจนกลายเป็น Leadership ในด้านนั้นๆ อีก 10% และเมื่อได้ถึงจุดนี้แล้ว กระบวนการทั้งหมดก็จะเริ่มสร้าง (Create/Generate) องค์ความรู้ ข้อมูล ฯลฯ ต่างๆ ขึ้นมา ไม่ว่าจะเป็นรูปของกระดาษ หรือรูปแบบอื่นๆ ซึ่งจะต้องพัฒนาเพิ่มขึ้นอีก 15% สุดท้ายของวัฏจักรก็คือ การพัฒนาเทคโนโลยีหรือเครื่องมือขึ้นมาเพื่อรองรับกระบวนการทั้งหมด อีกเพียง 10%

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

แล้วมันเกิดอะไรขึ้น? สิ่งที่ผมต้องการจะสื่อถึงกรณี “บ้านเรา” คืออะไร?

บ่อยครั้งมาก ที่เราต้องการการพัฒนาอย่างเร่งด่วนฉาบฉวย ซึ่งมักจะหมายถึงการ “เร่งมีอย่างที่คนอื่นมี” ไม่ว่าจะเป็นการเร่งมีระบบฐานข้อมูลเหมือนที่คนอื่นมี การเร่งมีสิ่งพิมพ์ดิจิทัลบน iPad เหมือนกับที่คนอื่นมี การเร่งจะมีเว็บขายของเหมือนที่คนอ่ืนมี ใช่ไหมล่ะครับ?

ความต้อง “มีอย่างที่คนอื่นมี” แสดงให้เห็นว่า เราจะต้องเคยเห็นมาก่อนว่าคนอื่นมีอะไร นั่นคือ เราจะต้องเห็น “ผล” ที่​ “ปลายเหตุ” ซึ่งก่อให้เกิดความอยากได้เหมือนเขาบ้าง เราอาจจะศึกษากระบวนการของเขาทั้งหมด ย้อนกลับไปว่ามาได้อย่างไร ส่งคนไปศึกษาดูงาน อ่านหนังสือ ฯลฯ ก็แล้วแต่

ลองดูกราฟของ “สิ่งที่เกิดขึ้น” บ้างครับ


mckean.006.jpg

ความน่ากลัวที่น่าสนใจก็คือ “การเดินย้อนทวนเข็มนาฬิกา” ซึ่งจะมุ่งเน้นไปที่ “การมีเครื่องมือสุดท้ายเหมือนกับเขา” โดยที่ไม่ได้สร้างคน กระบวนการทำงาน ระบบงาน วัฒนธรรมการทำงาน ฯลฯ อะไรไว้รองรับเลย และเมื่อมีเครื่องมือตามที่ต้องการแล้ว ก็ค่อยหาข้อมูลมาใส่ระบบอย่างลวกๆ จากนั้นก็กำหนดหน้าที่การทำงานในระบบอย่างลวกๆ (อาจจะตามตำรา หรือตามที่ได้ดูงานมา) ในวัฒนธรรมการทำงานที่ถือได้ว่า Non-Existing จากนั้นอาจจะตั้งระบบ แผนก หรือองค์กรขึ้นมาทำงานหน้าที่นั้นอยากลวกๆ และสุดท้ายก็คือ หาคนมาใส่ให้เต็มงาน โดยที่คนเหล่านี้ไม่ได้ถูกสร้างมาสำหรับอะไรแบบนี้เลย

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

==================

ลองดูกรณีศึกษากันหลายๆ กรณีนะครับ

  • หลายบริษัท/องค์กรเร่งไปที่การมีมาตรฐาน ISO, CMMI ตามกระบวนการประกันคุณภาพ (Quality Assurance; QA)​ โดยไม่ได้สนใจที่มาที่ไป รากฐานของมันเลย และยังทุ่มทรัพยากรไปกับการทำสิ่งเหล่านี้โดยใช่เหตุ และถือว่าเมื่อมีการใช้เครื่องมือเหล่านี้เหมือนชาวบ้านเค้า ก็ถือว่าเรามีคุณภาพแล้ว
  • หลายองคก์กรที่พัฒนาโปรแกรม เร่งไปที่การมี “เครื่องมือ” ต่างๆ ในการพัฒนาองค์กร เช่นสารพัดวิธีในการทำ Agile หรือสารพัดวิธีในการจัดการซอฟต์แวร์ เช่น Personal Software Process โดยที่เมื่อมีการทำพวกนี้แต่เปลือก ก็ถือว่ามีแล้ว โดยทั้งที่จริงๆ แล้ว “คน” ยังเขียนโปรแกรมกันแทบไม่เป็นเอาซะเลยด้วยซ้ำ กระบวนการทำงานของแต่ละคนเองก็ยังไม่เป็นรูปเป็นร่างอะไรเลย ยังทำงานร่วมกันไม่ได้เลย ฯลฯ
  • ผมพบบ่อยๆ ว่าเวลาเราไปดูงานที่ประสบความสำเร็จ เราจะเห็นภาพสุดท้าย โครงสร้างองค์กร หน้าที่ความรับผิดชอบต่างๆ ว่ามีแผนกอะไร ใครต้องทำอะไร ดังนั้นสิ่งที่เกิดขึ้นบ่อยในบ้านเรา คือ การลอกแบบจากปลายเหตุ ตั้งองค์กรตาม แบ่งแผนกตาม หาคนมาทำงานตาม โดยไม่ได้เริ่มจากการสร้างอะไรเองเลย ดังนั้นก็จะมีอะไรหลายอย่างที่มันไม่ function ตามที่มันควรจะเป็น
  • ระบบฐานข้อมูล เป็นอะไรที่ว่ากันยาวมาก หลายคนต้องการ “ระบบ” ขึ้นอย่างรวดเร็ว และเวลาที่เราบอกว่า มันต้องเริ่มจาก “คนใช้ข้อมูลอะไรในการทำงานอยู่ในปัจจุบันบ้าง” และข้อมูลอะไรจะต้องเชื่อมโยงกับอะไรที่มีอยู่แล้วบ้าง คนมักไม่ค่อยสนใจ คิดว่าจะต้องเริ่มด้วยการพัฒนาระบบเลย หรือดีกว่านั้น ซื้อระบบสำเร็จรูปมาใช้เลย ทั้งๆ ที่ระบบที่มันใช้งานได้ดี ส่วนมากจะใช้เวลานับปี วางรากฐานเรื่องข้อมูล และระบบข้อมูล ว่าใครใช้อะไรอยู่แล้วบ้างในการทำอะไร และข้อมูลนั้นเอามาจากไหน จากนั้นวางความเชื่อมโยงกับสิ่งที่มีอยู่แล้ว และค่อยพัฒนาระบบ ซึ่งจะใช้เวลาอีกหลายปี เป็นต้น
  • เว็บไซต์หรือเว็บแอพพลิเคชั่นก็เช่นเดียวกัน ที่เริ่มจากการ “อยากมีเว็บเหมือนคนนั้นคนนี้” โดยที่ไม่ได้สนใจ “การเริ่ม” ที่เหมือนกับเขาเลยแม้แต่น้อย จะเอาแต่ปลายเหตุอย่างเดียว
  • เรื่องเดียวกันก็เกิดขึ้นกับการพัฒนาแอพพลิเคชั่นทั่วไป การพัฒนา Digital Publishing ก็ไม่ใช่ข้อยกเว้น ที่จะเริ่มจากการเห็นคนอื่นมีกัน แล้วจะเร่งรัดไปที่ปลายเหตุอย่างฉาบฉวย ไม่ได้สร้าง “คนที่เข้าใจกระบวนการ มีความสามารถในการทำงานจริงจัง” ขึ้นมาเลย
  • เรื่องที่เห็นชัดเจนมากที่สุดเรื่องหนึ่งคือ Knowledge Management หรือ KM ที่ผมเห็นหลายที่บ้ากันจังเลย กับเครื่องมือสารพัด ไม่ว่าจะเป็นแผนภูมิก้างปลา กับการมี Blog ภายในองค์กร ที่แต่ละคนสามารถมาแชร์ความรู้กันได้ แล้วก็มีคนเขียนแค่ไม่กี่คน เขียนเรื่องอะไรก็ไม่รู้ พอมี Blog และมีคนเขียนคนสองคน ก็ถือว่า “องค์กรได้ทำ KM แล้ว” ซึ่งเป็นเรื่องโง่บัดซบ องค์กรในฐานะ “สิ่งมีชีวิต” จะดำรงอยู่ได้ด้วยอะไรในฐานะ “สภาพแวดล้อมและอาหาร” ยังไม่รู้เลย ดังนั้นตัวองค์กรเอง ต้องเรียนรู้อะไรเพื่อให้มันอยู่รอดได้ พัฒนาได้ อันนี้ก็ตอบไม่ได้ ในเมื่อไม่เป็น Learning Organization แล้วจะทำ Knowledge Management ไปเพื่ออะไร … ที่น่าเศร้า คือคนมันโดนล้างสมองไปแล้วว่า การทำ KM คือการมี Blog
  • เรื่องการศึกษาที่เน้นไปที่ผลลัพธ์ก็ไม่ใช่ยกเว้น เพราะสิ่งที่อยู่ในขั้นตอนสุดท้ายก็คือ “เครื่องมือ” ไม่ว่าจะเป็นสูตรคำนวน หรืออะไรก็แล้วแต่ ดังนั้นหลายครั้งเราจะเริ่มที่ปลายเหตุ คือ สอนการใช้เครื่องมือให้ได้ผลลัพธ์ โดยไม่สนใจสิ่งต่างๆ ก่อนหน้านั้นทั้งหมด และหลายคนก็สับสนไปว่า การใช้เครื่องมือเป็น คือการเข้าใจ ด้วยซ้ำ
  • ฯลฯ ฯลฯ และ ฯลฯ
  • (อัพเดท 2021): เรื่อง Agile, DevOps และสารพัดก็เช่นกัน

==================

ผมขอปิดบทความนี้ด้วยภาพนี้ภาพเดียวครับ ซึ่งคือสิ่งที่สำคัญที่เราจะต้องช่วยกันทำ


transforming.jpg

เปลี่ยนจากวงกลมซ้าย ที่เดินย้อนทิศทางเข็มนาฬิกา ที่ทำให้เรามีอะไรหลายอย่างที่มันฉาบฉวย ไม่ยั่งยืน ไม่มีประโยชน์จริง แต่เป็นภาพลวงตาที่หลอกเราไปวันๆ ว่า “เรามีแล้ว” ไปเป็นวงกลมขวา ที่เดินตามเข็มนาฬิกา ที่จะทำให้เรามีอะไรเป็นของตัวเอง ไม่จำเป็นต้องเหมือนกับใคร ใช้งานได้จริง มีประโยชน์กับตัวเราเอง องค์กรเราเอง และไม่ใช่ภาพลวงตา

สิ่งที่เราเห็นว่าคนนั้นคนนี้มี และหลายต่อหลายครั้งที่เราเห็นแล้วเผลอคิดไปว่า “เพราะเค้ามีสิ่งนั้น เค้าเลยดีกว่าเรา” มันเป็นเพียงแค่ “ยอดภูเขาน้ำแข็ง” เท่านั้นเอง


iceberg.018.jpg

ซึ่ง “ยอดภูเขาน้ำแข็ง” ที่ว่านี้ หมายถึงสิ่งที่เราเห็นลอยพ้นจากน้ำ ซึ่งจะมีเพียงแค่ 10-20% ของภูเขาน้ำแข็งทั้งก้อนเท่านั้น และการที่เราเข้าใจรูปร่างมันผิด และไปประมาทมัน เรือที่ไม่มีวันจมอย่างไทเทนิค ยังอับปางมาแล้วเลย …​. แต่นี่คือสิ่งที่หลายต่อหลายคนอาจจะมองเห็น แต่เพียงเท่านี้ ….