Generalists are rare…and, therefore, precious. — Chad Fowler, “The Passionate Programmer”, p. 48
Multi-disciplinary หรือ Interdisciplinary คือคุณสมบัติที่คนๆหนึ่งสามารถทำได้หลายๆอย่าง ข้าม academic disciplines ครับ
Software engineer เป็นตัวอย่างที่ดีครับ software engineer มีรากฐานมาจาก computer scientist มีความเป็นนักวิทยาศาสตร์ มองปัญหาผ่านสายตานักวิทยาศาสตร์ ใช้ชีวิตไล่ตามความสวยงามของ code และเพื่อตอบสนองความต้องการ application ที่มีขนาดใหญ่ขึ้นเรื่อยๆ เริ่มต้องทำงานเป็นทีม ก็เริ่มดึง production process ใน engineering disciplines มาใช้ กลายเป็น software process ต่างๆที่เราใช้ในปัจจุบัน การผลิตของใหญ่ๆ ลงทุนสูงๆ ก็เริ่มให้ความสำคัญกับการ design ซึ่งอยู่ใน academic discipline ด้านสถาปัตยกรรม เกิดเป็น design patterns และ concept การทำ model และเพื่อเพิ่มศักยภาพในการเก็บ requirement จึงจำเป็นต้องศึกษา business เพื่อให้เข้าใจกลไกการตลาดของธุรกิจและสามารถ lead benefits ได้
ถึงภายนอกจะเปลี่ยนไปจนแทบไม่เหลือเค้าของ scientist แล้ว แต่ข้างในไม่เคยเปลี่ยนครับ เรารัก software ที่เราเขียนขึ้นมา และอยากให้มันมีชีวิตอยู่สร้างประโยชน์ให้กับ user ได้นานๆ ไม่มีใครอยากเขียน software ไป deploy ทิ้งไว้ ให้มันกินไฟไปวันๆไม่มีคนใช้ จริงไหมครับ?
Q: ทำไม Multi-disciplinary นี้ถึงเข้ากันกับ Agile ได้อย่างกับเค้กกับกาแฟ? A: นั่นเป็นเพราะการแบ่งงานใน agile process นั้น เราแบ่งเค้กกันเป็นชิ้นๆตามแนวตั้งครับ ไม่ได้แบ่งกันเป็น layerๆ ตามแนวนอนเหมือนพวก iterative process (ดูภาพประกอบ)
Q: แล้วแบ่งตามแนวนอนมันไม่ Agile ยังไง? A: ลองทบทวน input และ output ของ software development process กันซักนิดครับ สมมติว่าเรามี process ที่อภิมหาagile ชนิดว่าทันทีที่ธุรกิจมีเค้าความเปลี่ยนแปลงแล้ว CEO คิดอยากได้ application อะไรปุ๊บ ดีดนิ้วแล้วออกมาเป็น system ปั๊บ input ของ process คือไอเดีย แล้ว output ของ system ก็คือ software ถูกไหมครับ? ลองมาดู assembly line (สายการผลิต) เดิมๆที่เราใช้กัน SA เก็บ requirement, โยนให้ developer implement, แล้วโยนให้ QA test พอเราแบ่งแบบนี้ เครื่องมืออะไรที่เราใช้ในการการันตีไอเดียจากหัวหนึ่งไปอีกหัวหนึ่งครับ?… documents! ใช่ครับ documents (มี s ด้วย) จดกันเข้าไป เขียนกันเข้าไป เขียนน้อยก็คลุมเครือ เขียนมากก็กำกวมอีก ลองมาดูว่าแบ่งตามแนวตั้งให้คนเก็บ requirement, test, code เป็นคนเดียวกันแล้วเราใช้อะไรเป็นเครื่องมือขั้นระหว่างหัวสองหัว?… testcase กับ interface ครับ เราใช้ testcase ยืนยันว่า logic ถูก เราใช้ interface ยืนยันว่า structure ถูก ประกอบกับเพื่อนๆได้ ฟังดู agile ไหมครับ? idea จากลูกค้าจะถูกถ่ายมายัง developer ผ่านการคุยกัน แล้ว idea ก็จะไหลจากหัวลง keyboard แล้วออกมาเป็น software ไม่ต้องไปจดใส่เอกสารที่ไหน การทำ test case จะช่วย confirm ความเข้าใจของเรากับลูกค้าได้ (แน่นอนว่า testcase จะต้องใช้ภาษา business เพื่อให้ลูกค้าอ่านรู้เรื่อง ให้อารมณ์ Domain Specific Language (DSL) นิดๆ) เมื่อ document หายไปจาก development process เวลาเขียน doc. ก็หายไป เวลาอ่าน spec. ก็หายไป เหลือแต่เวลา implement เพียวๆ จะไม่เร็วกว่าเดิมได้อย่างไร?
Q: อืม.. ฟังดูดี แต่ไอ้ interdisciplinarity นี่มันซื้อที่ไหน? A: ซื้อที่ร้านหนังสือครับ ^ ^” อ้างอิง: อยากเก่ง, ทำอย่างไรดี? ที่ผมเคยเขียนไว้ อยากเก่งขึ้นก็ต้องฝึกฝนครับ ข่าวดีคือ การจะมี interdisciplinary ได้นั้น ไม่จำเป็นต้องเทพทุกด้านครับ แค่ไม่อ่อนจนเกินไปก็พอแล้ว (เก็บเลเวลจาก 1-> 50 แปปเดียวครับ ใช้พลังน้อยกว่าเก็บจาก 50->100 เยอะ) แต่ละคนก็มีจุดแข็งของตัวเอง เราไม่จำเป็นต้องโยนจุดแข็งเราทิ้ง แต่เราศึกษา discipline อื่นๆเข้ามาเพื่อให้เราสามารถทำอะไรที่เราไม่เคยทำได้มาก่อน แล้วปาฏิหารย์จะเกิดครับ ที่เคยต้องทะเลาะกับ SA ทุกวันจะหายไป ที่เคยต้องเปิดศึกกับ พวก QA ขอ waive นั่น waive นี่จะไม่ต้องมี เดินไปฟังโจทย์เอง, ทำ test เอง, code เอง, train user เอง แล้วชีวิตการทำงานจะมีความสุขขึ้นมากๆเลยครับ
ปล.
- post นี้ไม่ได้เป็นส่วนหนึ่งของ series กับดัก Agile นะครับ สำหรับ level 2 นั้น ขอเวลาบ่มความคิดให้มันตกตะกอนอีกซักพักครับ
- credit PetitPlat by sk_ สำหรับรูปเค้กต้นฉบับครับ
- หากมีข้อแนะนำ ติ ชมประการใดจะเป็นความกรุณามากๆเลยครับ
May Agileness smiles upon you! สวัสดีครับ!
อย่างนี้ BA,SA ตกงานกันเป็นแถบ
นี่ก็อาจเป็นเหตุผลที่บ.ส่วนมากปรับมาใช้ agile ไม่ได้
เพราะจะให้ลุงๆป้าๆมาหัดโค๊ดดิ่งใหม่ก็เห็นจะลำบาก
เพราะลืมหมดแล้ว แถมบางคนก็อาจไม่เคยโค๊ดมาก่อนเลยด้วยซ้ำ
แล้วก็ไม่ต้องมาเถียงกันแล้วว่า SA ต้องโค๊ดเป็นหรือปล่าว เพราะไม่มี SA แล้ว
มีแต่ developer หุหุ
ปัญหาลุงป้านี้น่าจะเห็นบ่อยกับคนไทยนะคะ เพราะเท่าที่ทำงานกับฝรั่งมา คนอายุมากๆ แล้วก็ยังเขียนโปรแกรมเก่งกว่าเราเลย เป็นเพราะเค้าไม่ได้คิดว่าจะต้องเติบโตในสายบริหาร และจับเทคนิคอลตลอด ยิ่งฝึกยิ่งเก่งค่ะ
และที่บริษัทปรับมาใช้ agile ไม่ได้ ส่วนหนึ่งมาจาก concept ของ agile ยังไม่เข้ากับการทำงานขององค์กรใหญ่ค่ะๆ หากปรับต้องปรับหลายส่วนและกระทบหลายส่วน โดยส่วนใหญ่เหมาะกับองค์กรณ์พวก software company หรือ software house แนวนี้มากกว่า
นั่นเป็นแค่ความเชื่อว่า BA,SA ไม่มีงานให้ทำ Agile ไม่ได้บอกว่าห้ามมี Document
เราจะทำ Document เท่าที่จำเป็นต้องใช้เท่านั้น เช่น User Story, Story Board, UI guideline, Wireframe หรือจะแม้แต่ Knowledge Management ต่างๆที่ใช้ในการพัฒนา Software พวกนี้ต้องมี Documents ทั้งนั้น
BA,SA งานจะกลายเป็น Product Owner แทน
ของพวกนี้ adapt กันได้เพียงแต่ศึกษาให้เข้าใจและรู้จักปรับใช้ตามความเหมาะสมกับวัฒนธรรมและสังคม
How to Rate a Software Developer (http://www.realsoftwaredevelopment.com/how-to-rate-a-software-developer/) ได้อ่าน article นี้วันนี้แล้วรู้สึกว่ามั่นใจใน post ตัวเองมากขึ้นครับ
เห็นด้วยครับว่าถ้า developer well around มากขึ้น BA, SA จะไม่ต้องทำสิ่งที่ทำอยู่ทุกวันนี้ครับ (ซึ่งผมเรียกว่าจับปูใส่กระด้ง) จะตกงานหรือไม่ อยู่ที่สิ่งที่เค้าทำอยู่ทุกวันนี้เป็นทุกอย่างที่เค้าทำได้ หรือว่าจริงๆเค้าทำอย่างอื่นที่เป็นประโยชน์มากกว่านี้ได้ แต่ไม่มีโอกาสได้ทำเพราะต้องมานั่งทำสิ่งที่ทำอยู่ทุกวันนี้?
wireframe เพิ่งจะได้ยินเป็นครั้งแรก ไปอ่านดูก็เห็นว่าน่าสนใจ ยังไม่เคยเห็น practical example เลยยังไม่เห็นภาพเท่าไหร่ ไม่แน่ใจว่าสิ่งที่ wired คือ GUI หรือว่า knowledge ที่เกิดจากงาน? ถ้าเป็น GUI คิดว่าพวก page navigation น่าจะตอบโจทย์ได้ ถ้าเป็น knowledge คิดว่า การจดลง wiki เป็นแนวทางหนึ่งที่จะทำให้ได้สิ่งที่คล้ายๆกันกับ wireframe?
การทำ KM ในองค์กรเป็นอีกอย่างที่ผมสนับสนุนอย่างแรงกล้า ทุกวันนี้ผม work around โดยการ post ลง Narisa.com (cost เยอะขึ้นเล็กน้อย เพราะต้อง generalize content ก่อน แต่ข้อดีคือเปิดช่องทางให้ผมได้แบ่งปันประสบการณ์กับท่านอื่นๆ และบ่อยครั้งได้ต่อยอดความคิด) สำหรับ project-specific knowledge ผมอาศัย Google doc เสียส่วนใหญ่
ทดสอบ post ครับ
[...] [...]
สนับสนุน Multi-disciplinary อย่างแรงครับ อยากจะเสริมว่าในโปรเจคที่มีขนาดใหญ่และมีความซ้ำซ้อนสูง ผมว่าการมีคนที่ดูภาพรวมด้วยไม่ว่าจะเป็น SA/BA หรือ architect ก็มีความสำคัญนะครับ ไม่เช่นนั้นอาจเกิดอาการทำได้กันหมดทุกคนแต่ไปคนละิทิศคนละทาง หรือ requirement ซ้ำซ้อนหรือขัดกันเอง
อีกตัวอย่างหนึ่ง SA/BA ยังมีความสำคัญอยู่ คือในทีมที่ผมทำงานอยู่ เหตุผลหลักๆคือ requirement วิ่งเข้ามาจากหลายทาง มีทั้งส่วนที่มาจากทีมในประเทศกับส่วนที่มาจากทีมที่อยู่ต่างประเทศ หลายครั้ง requirement ก็ขัดแย้งกันเอง หนำซ้ำถ้าจะให้ dev แต่ละคนซึ่งภาษาอังกฤษไม่ได้ชำนาญเท่าไหร่ไปคุยทางโทรศัพท์หรือแม้แต่ Video Conference ก็อาจจะไปกันใหญ่ จริงอยู่การมี proxy อย่างนี้อาจทำให้ความสามารถในการบรรลุ multi-disciplinary ลดลง แต่สำหรับผมชั่งน้ำหนักดูแล้วได้มากกว่าเสียครับ งาน document ภาพรวมหรือ knowledge ที่ใช้บ่อยก็เป็นสิ่งที่ SA/BA จะมีบทบาทได้เป็นอย่างดี
Most Effective Team Structure (http://www.infoq.com/news/2010/03/most-effective-team-structure)
เห็นเกี่ยวกัน เลยเอามาแปะไว้ครับ
ปล.
- ขอบคุณพี่ @somkiat ที่ share ผ่าน twitter ครับ (-/\-)
อาจบทความ แล้วผมนึกถึงภาพนี้อ่ะครับ หาตั้งนานกว่าจะเจอ
http://www.agiledeveloper.com/blog/content/binary/3260585819-project_management.jpg
เยี่ยมครับ! classic มาก ^ ^