ทักษะความชํานาญ มีอะไรบ้าง

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

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

1. มีความสามารถในการสื่อสารได้อย่างมีประสิทธิภาพ
2. มีความสามารถในการทำงานเป็นทีม
3. มีความสามารถในการแก้ปัญหา
4. มีความสามารถในการคิดริเริ่ม
5. มีความสามารถในการบริหารจัดการ
6. มีความสามารถในการปรับตัว

          ลองมาสำรวจตัวเองกันว่า คุณมีคุณสมบัติทั้ง 6 ข้อนี้แล้วหรือยัง

1. ผู้ที่เป็นนักสื่อสารที่ดี ไม่ใช่แค่พูดเก่งอย่างเดียว ต้องมีทักษะในการฟังด้วย ต้องฟังอย่างตั้งใจเสียก่อน จึงจะโต้ตอบได้อย่างถูกต้อง ถามคำถามได้อย่างเหมาะสม ถ่ายทอดความคิดออกไปสู่ผู้ฟังได้อย่างถูกต้อง ผู้ส่งสารกับผู้รับสารเข้าใจตรงกัน อธิบายสิ่งต่าง ๆ ได้อย่างชัดเจน สามารถคุยกับคนที่ไม่คุ้นเคยได้อย่างไม่เคอะเขิน จูงใจผู้อื่นให้คล้อยตามได้ และสามารถเจรจาหรือต่อรองได้ประสบความสำเร็จ
2. ผู้ที่ทำงานเป็นทีมได้ดี มักจะเป็นคนยืดหยุ่นและประนีประนอม จึงสามารถเข้ากับคนได้ทุกประเภท เปิดกว้างสำหรับความคิดเห็นของผู้อื่น และมีการแลกเปลี่ยนข้อมูลกับผู้อื่นอยู่เสมอ อีกทั้งยังเป็นคนซื่อสัตย์ จริงใจ ไม่เอาเปรียบผู้อื่น ยึดมั่นและทำตามคำสัญญาที่รับปากไว้ ทำให้ผู้อื่นไว้วางใจ ในขณะเดียวกันก็ไว้ใจผู้อื่นด้วย
3. ผู้ที่เป็นนักแก้ปัญหาตัวยง จะมองเห็นปัญหาก่อนที่มันจะกลายเป็นเรื่องใหญ่ ทั้งยังรู้จักมองด้วยมุมมองที่แตกต่าง จึงสามารถเห็นและจัดการกับปัญหาได้ก่อนผู้อื่น คนที่มีคุณสมบัติเช่นนี้ไม่กลัวที่จะเผชิญหน้ากับปัญหา จึงไม่เคยคิดปัดปัญหาไปให้ผู้อื่น เมื่อเกิดความผิดพลาดขึ้นก็เรียนรู้จากความผิดพลาดของตัวเอง และพยายามทางหนทางใหม่ ๆ ในการแก้ปัญหาอย่างไม่ย่อท้อ
4. ผู้ที่มีความคิดริเริ่ม คนที่มีคุณสมบัติเช่นนี้มีแนวโน้มสูงที่จะเป็นผู้นำ เพราะรู้ตัวเองว่าต้องทำอะไรโดยไม่ต้องมีใครบอกให้ทำ ชอบที่จะคิดสร้างสรรค์
   ชอบทดลอง ปรารถนาที่จะเรียนรู้สิ่งใหม่ ๆ ไม่เพียงเฉพาะกับตัวเองเท่านั้น แต่ยังเป็นตัวตั้งตัวตีให้ผู้อื่นทำในสิ่งใหม่ ๆ เช่นกัน
5. 
   ผู้ที่มีทักษะในการบริหารจัดการ สามารถวางแผน งานและจัดลำดับความสำคัญของสิ่งต่าง ๆ ได้ดี รู้ว่าอะไรควรทำก่อน อะไรควรทำทีหลัง มีความสามารถในการทำงานหลายอย่างในเวลาเดียวกัน และสามารถทำงานเสร็จตรงเวลา อีกทั้งยังมีความสามารถในการประสานงานกับผู้อื่นได้ดี
6. ผู้ที่สามารถปรับตัวเข้ากับสถานการณ์และบุคคลได้ดี เป็นคนเรียนรู้เร็ว ไม่ยึดติดกับตัวเอง พร้อมเปิดรับความคิดใหม่ ๆ เสมอ จึงไม่กลัวที่จะลองทำสิ่งที่
   แตกต่าง และสามารถจัดการกับความเปลี่ยนแปลงได้ดี

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

ดาวน์โหลดได้แล้ววันนี้ทั้ง iOS และ Android

เรื่องอื่น ๆ ที่น่าสนใจ

6 วิธีเอาชนะความกลัวในการนำเสนองานหน้าที่ประชุม

6 วิธีเพิ่มทักษะการสื่อสารในการทำงาน

ความชำนาญกับความรับผิดชอบ

ความชำนาญคือการทำอะไรซักอย่างได้เป็นอย่างดี ความรับผิดชอบคือการมีหน้าที่ที่จะต้องจัดการอะไรซักอย่าง แม้ว่า 2 อย่างนี้จะเกี่ยวพันกัน แต่มันอาจจะไม่ใช่ไอเดียที่ดีที่จะเอามันมาผูกกันก็ได้

ความชำนาญด้าน Component กับความรับผิดชอบต่อ Feature

Conway’s law กล่าวไว้ว่า

เวลาองค์กรออกแบบระบบมา ก็จะได้ระบบที่ก็อปปี้โครงสร้างการสื่อสารเหมือนองค์กรนั้นนั่นแหละ

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

วิธีแก้คือให้จัดทีมเป็น feature team แล้วแชร์ ownership ของ code กัน ไม่มีโค้ดของทีมฉัน โค้ดของทีมเธอ แต่โค้ดนี้เป็นของเรา แต่ละทีมรับผิดชอบไปคนละ feature ส่วนความรับผิดชอบของ component จะกระจายไป

แบบนี้แล้ว เราจะยังเหลือความชำนาญในแต่ละ component อยู่ไหม? มีโอกาสสูงมากที่จะมี อย่างน้อยก็ที่ระดับบุคคล สมาชิกบางคนที่มีความรู้ใน component นั้นมากกว่า ก็จะทำงานที่เกี่ยวกับ component นั้นได้ดีกว่า คนที่ชำนาญหลาย ๆ ด้าน เริ่มต้นจากชำนาญซักด้านหนึ่งก่อน แล้วค่อยขยายไปด้านอื่นๆ ยกตัวอย่างเช่น สมมติผมเป็น developer หลักของ component A และผมก็ขยายขอบเขตไปทำ component B แล้วก็พัฒนาความชำนาญจากตรงนั้น

สถานการณ์เดียวกันนี้ก็เกิดขึ้นในระดับทีมเช่นกัน เพราะบาง feature อาจจะแตะบางส่วนของระบบมากกว่า feature อื่น ความชำนาญก็เกิดขึ้นตามธรรมชาติ เนื่องจากความรับผิดชอบมันผูกอยู่กับ feature ความชำนาญด้าน component จะไม่ขัดขวางเราจากการหยิบ feature ที่มีคุณค่าสูงสุดมาทำ

ความชำนาญด้าน feature กับความรับผิดชอบต่อ product

กลไกเดียวกันนี้ก็เกิดขึ้นกับความรับผิดชอบต่อ feature เช่นกัน เมื่อทีมมีความรับผิดชอบต่อ feature หนึ่ง ๆ เช่น ทีม payment ก็จะมีความชำนาญใน domain หนึ่ง ๆ และกลายเป็นข้อจำกัดที่ถ่วงเราเหมือนเดิม เมื่อความชำนาญกลายเป็นเหตุผลที่จะผูกทีมไว้กับ feature นั้น ๆ การพัฒนา product กลายเป็นเรื่องยากขึ้นเมื่อมันผูกกันกับโครงสร้างขององค์กร

วิธีแก้คือ จัด feature team หลาย ๆ ทีมที่แชร์ product backlog เดียวกัน ทีมเหล่านั้นจะ รับผิดชอบต่อทั้ง product และไม่แบ่งความรับผิดชอบเป็นกลุ่มของ feature กลุ่มใดกลุ่มหนึ่ง อย่าง payment เป็นต้น

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

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

สรุปแล้ว ให้ทุกทีมมีความรับผิดชอบต่อทั้ง product และให้ product เป็นตัวนำทางไปว่าเราจะชำนาญใน feature ใด

Requirement area

ถ้าคุณทำงานในการพัฒนาขนาดใหญ่และใช้ LeSS คุณน่าจะเคยได้ยินเรื่อง Requirement area มาก่อน มีคำถามว่า เราอยากจะตั้ง Requirement area ขึ้นมา แล้วแบ่งแยกความรับผิดชอบใน product แต่ละ domain อย่างชัดเจน หรือ เราอยากจะให้ area ทั้งหลายเป็นแค่กลุ่มของทีม แล้วความชำนาญในแต่ละ domain ใน product มันเกิดขึ้นเองตามธรรมชาติกันนะ? ผมคิดว่ามันไม่มีคำตอบตายตัว แต่ประเด็นสำคัญคือ Requirement area นั้น dynamic เมื่อเราตั้ง Requirement area ให้มีความรับผิดชอบชัดเจนและผูกทันเข้ากับชื่อที่มีความหมาย เช่น Security มันอาจจะช่วยสร้าง identity ให้กับทีมและช่วยเร่งความชำนาญ แต่ในทางกลับกัน มันอาจจะทำให้ Requirement area นั้นอยู่ยั่งยืนยงตลอดไปก็ได้

บทสรุป

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

Credits:

Lv Yi สำหรับต้นฉบับบทความที่ผมแปลมา

Nuttawoot Singhathom สำหรับคำแปลของ Conway’s law แบบง่าย ๆ