เรา สามารถ ทำอะไรเพื่อให้เรากลับมาสู่เส้นทางเดิมได้
ทวีตล่าสุดเกี่ยวกับสิ่งที่ทีมทำเมื่อตารางงานเลื่อนลอยซึ่งจริงๆ แล้วอาจทำให้สิ่งต่างๆ แย่ลงได้ ดูเหมือนว่าจะโดนใจผู้คนจำนวนมาก
โดยธรรมชาติแล้วมันทำให้เกิดคำถาม: เราจะทำอะไรได้บ้างเพื่อให้เรากลับมาสู่เส้นทางเดิม?
บทเรียนแรกและบทเรียนที่เจ็บปวดที่สุดก็คือการยอมรับว่าบางทีเราอาจไม่สามารถกลับไปสู่เส้นทางเดิมได้ ดังนั้นเราจึงต้องคิดแผนใหม่ มีสองวิธีที่เราสามารถสร้างแผนที่ใหม่ซึ่งเรารู้ว่าใช้ได้ผล:
1. เลื่อนวันจัดส่งกลับให้เหมาะสมกับงานทั้งหมด
2. จัดส่งให้น้อยลงเพื่อให้ตรงตามวันที่จัดส่ง
ไม่ใช่บทสนทนาที่ทีมจำนวนมากชอบพูดคุยกับลูกค้า แต่ก็มีข้อดีอยู่บ้าง Re: #2
เมื่อฉันพูดว่า "ส่งมอบน้อยลง" ฉันหมายถึง "ซอฟต์แวร์น้อยลง" หากเราชัดเจนในใจว่าซอฟต์แวร์และคุณค่าไม่เหมือนกัน ก็จะเป็นไปได้ที่จะส่งมอบคุณค่าส่วนใหญ่ที่ลูกค้าต้องการ — เพื่อแก้ไขปัญหาหลักของพวกเขา — โดยไม่ต้องส่งมอบคุณสมบัติทั้งหมดที่เราวางแผนไว้
นี่คือการพัฒนาซอฟต์แวร์เทียบเท่ากับการพูดว่า “บ้านสร้างไม่เสร็จตรงเวลา แต่เข้าอยู่วันนั้นได้”
หากคุณกำลังทำ Agile Software Development สิ่งนี้อาจเกิดขึ้นแล้ว และถ้าไม่เป็นเช่นนั้น บางทีคุณอาจไม่ได้ทำ Agile Software Development จริงๆ
โซลูชันนี้ต้องการให้เรามีแนวคิดที่ชัดเจนว่าเป้าหมายสุดท้ายที่แท้จริงของซอฟต์แวร์คืออะไร คุณต้องเปลี่ยนการเน้นจากการแสดงรายการคุณลักษณะที่ต้องซื้อไปเป็นการแก้ปัญหาชุดหนึ่ง จากนั้นคุณสามารถซื้อความยืดหยุ่นในการออกแบบได้ ทางเลือกที่มากขึ้นอาจเป็นสิ่งที่ทรงพลังเมื่อคุณต้องการแก้ไขปัญหาภายในระยะเวลาที่กำหนด
เมื่อฉันสืบทอดบทบาทผู้นำทีมในโครงการที่ถูกบุกรุก สิ่งแรกที่ฉันทำคือหยุดทุกอย่างและให้ทีมถอยกลับและถามว่า “เรากำลังพยายามทำอะไรให้สำเร็จที่นี่ มีวิธีที่ง่ายกว่านี้ไหม?” ดังนั้นจงเตรียมพร้อมที่จะทิ้งการออกแบบและทิ้งแผนที่จะไปด้วย จากประสบการณ์ของฉันในการบันทึกโครงการที่ถูกบุกรุก นี่คือกุญแจสำคัญ เตรียมการสนทนาอย่างเต็มที่และตรงไปตรงมากับลูกค้าของคุณ
แต่สามสิ่งที่ฉันทวีตเกี่ยวกับที่เรารู้ว่าสามารถส่งล่าช้าได้ในภายหลังล่ะ
เป็นที่ทราบกันมานานแล้วว่าการจ้างนักพัฒนาเพิ่มจะทำให้สิ่งต่างๆ แย่ลง
สาเหตุที่จ้างนักพัฒนาเพิ่มทำให้ปัญหารุนแรงขึ้น ได้รับการอธิบายอย่างสวยงามในหนังสือชื่อดังของ Fred Brook เรื่อง The Mythical Man-Month ฉันเชื่อว่านักพัฒนาซอฟต์แวร์ทุกคนและผู้จัดการฝ่ายพัฒนาซอฟต์แวร์ทุกคนควรอ่าน
นักพัฒนาที่ยุ่งอยู่กับการทำเรื่องไร้สาระก็กลายเป็นยุ่งกับการหาสมาชิกในทีมใหม่ให้เร็วขึ้น มันเหมือนกับการโปรโมตพนักงานขายที่มีประสิทธิภาพสูงสุดของคุณสู่บทบาทการจัดการ ดูยอดขายดิ่งลง!
นอกจากนี้ ยังมีการเพิ่มจำนวนช่องทางการสื่อสารภายในทีมอย่างทวีคูณเพื่อให้ทุกคนทันสิ่งที่คนอื่นๆ กำลังทำอยู่ ซึ่งน่าเสียดายที่ซอฟต์แวร์มีความจำเป็นเนื่องจากทุกอย่างเชื่อมโยงกัน และเรากำลังต่อสู้กับปัญหาด้านประสิทธิภาพการทำงานที่เพิ่มขึ้นเป็นสองเท่า การสูญเสียนักพัฒนาที่มีประสิทธิผลมากที่สุดไปสู่หน้าที่การให้คำปรึกษาและผลตอบแทนที่ลดลงอย่างรวดเร็วของทีมใหญ่
ดังนั้นคำแนะนำนั้นง่ายมาก อย่าทำ ไม่ว่าคุณจะถูกล่อลวงแค่ไหน ไม่ว่าคุณจะอยู่ภายใต้ความกดดันจากเบื้องบนมากแค่ไหนก็ตาม อย่าทำมัน
แต่จะเกิดอะไรขึ้นถ้าทีมใหญ่เกินไป? จะเกิดอะไรขึ้นถ้าเหตุผลที่คุณไม่ทำเรื่องไร้สาระเพราะทีมโอเวอร์เฮดรั้งคุณไว้ล่ะ? ที่นี่ คุณอาจต้องทำการตัดสินใจที่ยากลำบากมาก ตั้งแต่ระดับร้ายแรงตั้งแต่การย้ายผู้คนไปยังโครงการอื่น (ถ้ามี) หรือคนที่ขวางทางเพื่อให้ผู้คนเป็นทางเลือกสุดท้าย
หากคุณเน้นหนักไปหน่อยหรือมีเด็กฝึกหัดมากเกินไป ก็สามารถดูดซับการโจมตีได้ ในทางกลับกัน หากคุณมีสถาปนิก 3 คน ผู้จัดการโครงการ 2 คน หัวหน้าฝ่ายเทคโนโลยี 6 คน นักวิเคราะห์ธุรกิจ 4 คน นักพัฒนา 30 คน และผู้ทดสอบ 10 คน… เท่าที่ฉันกังวล คนเหล่านั้นจำนวนมากเพลิดเพลินกับสิ่งที่มีประสิทธิผล สวัสดิการในการทำงานประเภทหนึ่ง พวกเขาได้รับเงิน — และอาจจ่ายได้ดีมาก — ไม่ใช่แค่เพิ่มมูลค่า แต่เพื่อดึงคุณค่าออกจากทีมในทางบวก คุณจ่ายเงินให้พวกเขาเพื่อให้คุณช้าลง เราทุกคนรู้ดี แต่มีน้อยคนที่กล้าพูด
ในกรณีที่เห็นได้ชัดว่าทีมมีขนาดใหญ่เกินไป คุณจะมีทางเลือกน้อยมาก แต่ต้องทำให้ง่ายขึ้นหากคุณต้องการส่งมอบสิ่งที่มีคุณค่าในเวลาที่ลูกค้าต้องการ
อนิจจา การตัดสินใจประเภทนี้ - จ้างหรือแจกจ่ายต่อหรือไล่ออก - มักจะอยู่นอกเหนือมือของฉันและคุณ และการจัดการในระดับที่สูงขึ้นในสถานการณ์เหล่านี้ก็มีความเสี่ยงอย่างมาก โดยเฉพาะความเสี่ยงที่คนที่ไปจะเป็นคนเป่านกหวีด พฤติกรรมเริ่มต้นในสถานการณ์เหล่านี้คือการเลือกความล้มเหลวอย่างรู้เท่าทัน ในทางเลวทรามเพื่อประโยชน์ของทีม
การตัดมุมเป็นความผิดพลาดแบบคลาสสิก ตราบใดที่เรารู้ว่าการจ้างนักพัฒนามากขึ้นจะทำให้สิ่งต่างๆ แย่ลง เรายังรู้ด้วยว่าการละเลยคุณภาพจะทำให้เราไปช้าลงจริงๆ
เหตุผลนั้นเรียบง่าย เข้าใจดี และได้รับการสนับสนุนจากเทือกเขาหิมาลัยที่มีหลักฐานชัดเจน จุดบกพร่องต้องเสียทั้งเวลาและเงินเป็นจำนวนมากเพื่อแก้ไขให้ตรวจไม่พบอีกต่อไป การทดสอบน้อยลงแต่ไม่บ่อยนัก ทำให้เกิดคลื่นสึนามิในการแก้ไขข้อบกพร่องที่จำเป็น ซึ่งจะใช้เวลานานในการแก้ไขถึง 10–100 เท่า มากกว่าถ้าเราตรวจพบได้เร็วกว่านั้น
คุณสามารถมองเห็นทีมที่ทำสิ่งที่เราเรียกว่าการพัฒนาแบบ "โค้ดและแก้ไข" ไม่ใช่แค่ขนาดของรายการข้อบกพร่องเท่านั้น แต่ยังรวมถึงเวลาและความพยายามที่แท้จริงที่พวกเขาใช้เพื่อ "ทำให้เสถียร" ซอฟต์แวร์เพื่อสร้าง มันเหมาะที่จะปล่อย ฉันเฝ้าดูทีมต่างๆ วนเวียนกันเป็นวงกลมเป็นเวลาหลายเดือนเพื่อพยายามสร้างโค้ดที่ดีพอที่จะจัดส่ง
นี่คือเหตุผลว่าทำไมทีมที่ทราบ เมื่อกำหนดการเลื่อนลอย ทำการทดสอบมากขึ้น เข้มงวดมากขึ้น และบ่อยขึ้น ใช่ ตอนนี้มีงานมากขึ้นแล้ว แต่งานจะน้อยลง 10–100 เท่าในภายหลัง
แน่นอนว่าไม่มีกระสุนเงินในการพัฒนาซอฟต์แวร์ แต่เมื่อพูดถึงการนำทีมกลับมาสู่เส้นทางเดิม การสร้างการทดสอบอัตโนมัติที่ทำงานอย่างรวดเร็วเป็นสิ่งที่ใกล้เคียงที่สุดที่ฉันเคยเห็น มันสามารถเปลี่ยนทัศนคติได้อย่างสมบูรณ์
ในทำนองเดียวกัน การเปลี่ยนมาใช้ Specification By Example ในการสนทนาเกี่ยวกับข้อกำหนดกับลูกค้าก็อาจส่งผลในการเปลี่ยนแปลงได้ คุณจะประหลาดใจกับความเข้าใจผิดที่คุณพบได้มากเพียงใดเมื่อคุณขอตัวอย่างที่เป็นรูปธรรมเพื่อชี้แจงความหมายของสิ่งเหล่านั้น การใช้เวลาสองสามชั่วโมงในการชี้แจงข้อกำหนดด้วยการทดสอบการยอมรับที่สามารถดำเนินการได้อาจช่วยให้คุณประหยัดเวลาในการทำงานซ้ำโดยไม่จำเป็นได้หลายสัปดาห์
เช่นเดียวกับการบำรุงรักษาโค้ด การคิดและเอาใจใส่น้อยลงในการทำให้โค้ดของเราเข้าใจง่ายและเปลี่ยนแปลงง่าย (โดยไม่ทำลาย) อาจทำให้เราเสียค่าใช้จ่ายมหาศาลและเร็วกว่าที่เราคิด ฉันพบว่าตัวเองถูกขัดขวางในช่วงบ่ายด้วยโค้ดที่ฉันเขียนในตอนเช้า
เช่นเดียวกับกีฬากอล์ฟ วิธีที่จะทำให้ได้คะแนนสูงขึ้นเร็วขึ้นคือการดูแลช็อตของเราให้มากขึ้น
นี่ก็เป็นการขายที่ยากลำบากสำหรับทั้งเพื่อนร่วมทีมและผู้จัดการเช่นกัน ตำนานที่หักล้างกันโดยสิ้นเชิงว่าซอฟต์แวร์ที่มีคุณภาพดีกว่าใช้เวลาในการส่งมอบนานกว่านั้นยังคงมีอยู่ และอาจมีทักษะใหม่ๆ ที่ต้องเรียนรู้เพื่อป้องกันข้อบกพร่องและแนวทาง "โค้ดที่สะอาด" ได้ผล หากทีมยังไม่ทันต่อหลักการและแนวปฏิบัติ คุณคงสับสนนิดหน่อย เพราะคุณต้องใช้เวลาหลายเดือน (อาจเป็นปี) กว่าจะพิชิตช่วงการเรียนรู้นั้น
ถ้าโดยรวมแล้วทีมมีทักษะที่จำเป็น นั่นก็จะทำให้เกิดคำถาม: ทำไมคุณไม่ทำสิ่งเหล่านี้แล้ว? หากคำตอบคือ “เจ้านายไม่ยอมให้เรา” นี่ก็อาจเป็นการสนทนาที่ยากลำบากอีกครั้งหนึ่ง
จากประสบการณ์ส่วนตัวของฉันและเรื่องราวที่ฉันได้ยินจากบุคคลในสถานการณ์ที่คล้ายคลึงกัน ขอแนะนำอย่างยิ่งว่าอย่ามีส่วนร่วมในการสนทนาดังกล่าว หากคุณพบว่าตัวเองอยู่ในตำแหน่งนั้น มีแนวโน้มว่าสิ่งต่างๆ จะแย่ลงไปแล้ว การสนทนานี้ไม่ค่อยคลี่คลายตามที่ต้องการ ในกรณีส่วนใหญ่ เมื่อได้รับตัวเลือกระหว่างคุณภาพและ “คุณสมบัติ” ผู้จัดการและลูกค้ามักจะจัดลำดับความสำคัญอย่างหลัง โดยไม่คำนึงถึงความสำคัญของการรักษาคุณภาพสูง อย่างไรก็ตาม สิ่งสำคัญคือต้องรับทราบว่าท้ายที่สุดแล้วการลดทอนคุณภาพส่งผลให้มีฟีเจอร์จำนวนลดลงในที่สุด น่าเสียดายที่หลายทีมติดกับดักในการนำเสนอตัวเลือกนี้ โดยไม่ทราบถึงความขัดแย้งโดยธรรมชาติระหว่างข้อกังวลทั้งสองนี้
ดังนั้น เมื่อพูดถึงวันส่งมอบงาน ต้องทำให้คุณภาพไม่สามารถต่อรองได้ และวิธีที่ดีที่สุดในการทำเช่นนั้นคืออย่าพูดถึงเรื่องนี้นอกทีม ตัวอย่างเช่น หากคุณทำ TDD นั่นคือวิธีส่งมอบซอฟต์แวร์ที่ใช้งานได้ เช่นเดียวกับการใช้โปรแกรมแก้ไขข้อความ ครั้งสุดท้ายที่คุณเสนอทางเลือกแก่เจ้านายว่าคุณควรใช้โปรแกรมแก้ไขข้อความหรือไม่?
และเมื่อสิ่งต่างๆ ลื่นไถล คุณจะต้องดึงคันโยกคุณภาพเหล่านั้นให้แรงยิ่งขึ้น หากคุณเคยก้าวแบบทารก ให้ทำตามขั้นตอนแบบทารกด้วยซ้ำ หากคุณสร้างและทดสอบทุกวัน ให้สร้างและทดสอบทุกชั่วโมง หากคุณใช้เวลาโดยเฉลี่ย 20 นาทีในการหารือเกี่ยวกับเรื่องราวของผู้ใช้กับลูกค้า ให้สละเวลาหนึ่งชั่วโมงและตกลงเกี่ยวกับการทดสอบปฏิบัติการ รวมถึง Edge Case ทั้งหมดที่คุณนึกออก หากคุณเฉลี่ยการทดสอบหน่วยหนึ่งรายการต่อโค้ด 10 บรรทัด ให้ตั้งเป้าที่จะทำให้การทดสอบหน่วยของคุณมีความเข้มข้นมากยิ่งขึ้น หากคุณกำลังเฉลี่ยการตรวจสอบโค้ดทีมหนึ่งครั้งในการวนซ้ำแต่ละครั้ง ให้ทำการทบทวนโค้ดแบบเพียร์ก่อนทุกครั้ง และอื่นๆ
สุดท้ายนี้ การทำงานเป็นเวลานานหลายชั่วโมง ซึ่งเรารู้จากการศึกษาจำนวนมากที่ทำในช่วงศตวรรษที่ผ่านมานั้นไม่ยั่งยืน ส่งผลเสียต่อทีมและโครงการ และเป็นเศรษฐกิจที่ผิดพลาด ย้อนกลับไปไกลถึงเฮนรี ฟอร์ด ผู้ค้นพบว่าเมื่อเขาลดชั่วโมงคนงานในโรงงานจาก 50 ชั่วโมงเหลือ 40 ชั่วโมงต่อสัปดาห์ พวกเขาทำงานได้มากขึ้น เรารู้ว่าชั่วโมงทำงาน != ผลลัพธ์ที่เป็นประโยชน์
โดยเฉพาะอย่างยิ่งการพัฒนาซอฟต์แวร์มีแนวโน้มที่จะเกิดความเหนื่อยหน่ายเมื่อเราผลักดันทีมเข้าสู่ "โหมดวิกฤต" เป็นกิจกรรมที่ต้องใช้ความเอาใจใส่และความชัดเจน และการมุ่งเน้นและความชัดเจนเป็นสินค้าที่เน่าเสียง่ายซึ่งจำเป็นต้องเติมบ่อยๆ จากการทดลองของฉันเองกับทีมและกับตัวเอง ฉันได้เรียนรู้ว่านักพัฒนาโดยเฉลี่ยจะประสบความสำเร็จได้มากโดยประมาณใน 4 ชั่วโมงต่อวัน เช่นเดียวกับที่เธอทำได้ใน 8 ชั่วโมง และมากกว่าที่เธอจะทำได้ใน 12 ชั่วโมง
ชาวบ้านบางคนพูดว่า “ไม่เป็นไรในระยะสั้น” แต่ฉันไม่พบหลักฐานใดที่ยืนยันว่านี่เป็นเรื่องจริง บางทีพนักงานในสายการผลิตอาจทำงานเป็นกะยาวๆ เพื่อให้ทันกำหนดเวลา แต่นั่นไม่ใช่การพัฒนาซอฟต์แวร์
นอกจากนี้เรายังมีความอ่อนไหวต่อภาพลวงตาของประสิทธิภาพการทำงานอย่างมาก และฉันคิดว่าสิ่งนี้จะอธิบายว่าความเชื่อผิดๆ “ช่วยได้ในระยะสั้น” มาจากไหน แน่นอนว่าเรารู้สึกเหมือนเรากำลังทำเรื่องไร้สาระ แต่นั่นอาจเป็นเพราะเรามองไม่เห็นผลที่ตามมาของความผิดพลาดที่เราทำระหว่างทาง เมื่อสิ้นสุดวันที่มี 8 ชั่วโมง ฉันพบว่าเมื่อฉันวัดผลอย่างเป็นกลาง ว่าฉันกำลังทำผิดพลาดมากขึ้น ดังนั้นฉันจึงเรียนรู้ที่จะลาออกในขณะที่ฉันนำหน้า และพบว่าการมีทีมทำเช่นเดียวกันก็เป็นประโยชน์ เรียนรู้ที่จะรับรู้เมื่อคุณกำลังผ่านจากโซนของ "การไหล" เข้าสู่โซนของ "ความรับผิดชอบ"
ดังนั้น เมื่อฉันเป็นผู้นำทีม ฉันจะมีความอดทนต่อชั่วโมงการทำงานที่ยาวนานต่ำมากเช่นเดียวกับวิธีแก้ปัญหาใดๆ ก็ตาม แม้แต่ในระยะสั้นก็ตาม
และใช่ นี่เป็นการขายให้กับฝ่ายบริหารที่ยากมากเช่นกัน และนักพัฒนาจำนวนมากยังคงรู้สึกซาบซึ้งกับภาพลวงตาของประสิทธิภาพการทำงานของตนเอง ต้องใช้ความกังวลใจอย่างยิ่ง เมื่อใกล้ถึงเส้นตายและทุกคนก็ต่อสู้กันอย่างบ้าคลั่ง ลุกขึ้นจากโต๊ะอย่างใจเย็นเวลา 17.00-18.00 น. และกลับบ้าน แต่เท่าที่ฉันสามารถบอกได้ มันเป็นสิ่งที่ดีที่สุดที่คุณสามารถทำได้สำหรับโครงการนี้
ที่คล้ายกัน — และเกี่ยวข้องอย่างใกล้ชิดกับความจำเป็นในการดูแลมากขึ้น — คือความต้องการที่จะรู้สึกสดชื่นมากยิ่งขึ้น หยุดพักช่วงสั้นๆ มากขึ้น และรับประทานอาหารกลางวันเพื่อผ่อนคลาย (แต่ไม่ใช่คาร์โบไฮเดรตหนัก เพราะจะทำให้คุณง่วงนอน) ขยันเป็นพิเศษในการลาออกในเวลาที่เหมาะสมและมีสมดุลระหว่างชีวิตและการทำงานที่ดียิ่งขึ้น
จากนั้นหันความสนใจไปที่สิ่งที่คุณทำจริงๆ เมื่ออยู่ที่โต๊ะ แทนที่จะสนใจว่าคุณจะใช้เวลาอยู่ที่โต๊ะนานแค่ไหน
สิ่งหนึ่งที่ทำให้ฉันรำคาญจริงๆ ก็คือ มีองค์กรหลายแห่งที่ยืนกรานที่จะใช้เวลานานหลายชั่วโมง แต่กลับเผาชั่วโมงเหล่านั้นไปกับสิ่งรบกวนสมาธิที่ไร้ความหมาย เช่น การประชุมและสภาพแวดล้อมการทำงานที่ผิดปกติ เช่น สำนักงานแบบเปิดโล่ง ฉันมักจะพบความสัมพันธ์ที่แข็งแกร่งระหว่างทั้งสอง อยากทำงานให้เสร็จมากกว่านี้ไหม? จัดการกับสภาพแวดล้อมในการทำงาน ไม่ใช่ชั่วโมง
เอาล่ะคุณมีมันแล้ว เพื่อสรุป; เพื่อเพิ่มโอกาสในการถึงวันจัดส่ง:
1. จัดการความคาดหวังว่าจะส่งมอบอะไรและเมื่อใด ลดความซับซ้อนของผลิตภัณฑ์ ลดความซับซ้อนของแผน มุ่งเน้นไปที่เป้าหมายสุดท้าย ไม่ใช่รายการช้อปปิ้ง
2. ต่อต้านการล่อลวงที่จะจ้างนักพัฒนาเพิ่ม หากทีมของคุณใหญ่เกินไป ให้พูดคุยเรื่องที่ยากลำบากนั้น
3. หมุนปุ่มคุณภาพขึ้น ทำให้คุณภาพไม่สามารถต่อรองได้
4. ทำงานน้อยกว่าชั่วโมง หยุดพักมากขึ้น แทนที่จะมุ่งเน้นไปที่ชั่วโมง ให้มุ่งเน้นไปที่สิ่งที่ทำได้สำเร็จในช่วงเวลานั้น และขจัดอุปสรรคในการทำสิ่งต่างๆ ให้สำเร็จ เช่น สภาพแวดล้อมการทำงาน
แน่นอนว่าฉันพูดทั้งหมดนี้อย่างปลอดภัยโดยรู้ว่าทีมส่วนใหญ่กลัวเกินกว่าจะลองเล่น มันง่ายบนกระดาษ แต่ในทางปฏิบัติ ต้องใช้ทีมประเภทใดประเภทหนึ่งที่มีความเป็นผู้นำแบบใดแบบหนึ่งเพื่อทำให้สิ่งเหล่านี้เกิดขึ้น
ในที่สุด:
5. มีความเป็นผู้นำทางเทคนิคที่แข็งแกร่ง
นี่ไม่ได้หมายความว่ามีคนรั้นเช่นฉันที่ต้องต่อสู้ในทีมเพื่อพวกเขา (แม้ว่าฉันจะทำมาแล้วหลายครั้งก็ตาม) แต่อย่างไรก็ตาม จากที่ใดที่หนึ่งภายในทีม ทีมงานจำเป็นต้องค้นหาจุดแข็งและความเชื่อมั่นในตนเอง และยืนยันตัวเองในประเด็นสำคัญ เช่น ขอบเขต กำหนดเวลา ขนาดทีม ชั่วโมงการทำงาน สภาพแวดล้อมในสำนักงาน และอื่นๆ พวกเขากำหนดให้คุณต้องรับผิดชอบในการส่งมอบ: ตอนนี้ยืนยันอำนาจที่จะต้องมาพร้อมกับความรับผิดชอบนั้นหากมันต้องได้ผล
ขอให้โชคดี!
