กฎแปดประการสำหรับการผลิตซอฟต์แวร์อย่างมีประสิทธิภาพ

ตลอดระยะเวลาการทำงาน ฉันได้เข้าร่วมในโครงการซอฟต์แวร์ในชีวิตจริงหลายโครงการและได้สังเกตวิธีการทำสิ่งต่างๆ ในทุกระดับ: การตัดสินใจ การนำแนวทางปฏิบัติไปใช้ การสร้างทีม การสรรหา การกระจายทักษะ ฯลฯ เห็นได้ชัดว่าวิธีการต่างๆ ให้ผลลัพธ์ที่แตกต่างกัน . ในฐานะที่เป็นคนประเภทที่มุ่งเน้นการปรับปรุง ฉันสังเกตเห็นและรวบรวมแนวทางปฏิบัติที่มีประสิทธิภาพที่สุดและลูกเล่นที่ใช้ได้จริงที่ดีที่สุดเพื่อช่วยฉันในการทำงาน

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

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

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

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

นี่สำหรับใคร?

ให้ฉันทำข้อจำกัดความรับผิดชอบที่สำคัญที่สำคัญที่นี่

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

เทคนิคเหล่านี้จะเป็นประโยชน์มากที่สุดสำหรับหัวหน้าทีม สถาปนิก และผู้จัดการโครงการ แม้ว่านักพัฒนาซอฟต์แวร์อาวุโสจะได้รับประโยชน์จากเทคนิคเหล่านี้เช่นกัน

กฎข้อที่ 1: เข้าใจความคิดของไอที

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

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

สรุปทั้งหมดข้างต้น เราสามารถพูดได้ว่าความสำเร็จในด้านไอทีไม่ได้ขึ้นอยู่กับทักษะหรือความรู้สึกโดยกำเนิด แต่ขึ้นอยู่กับตัวอย่างจริงในทางปฏิบัติ ไม่เคย "ทำตามอุทร" หรือเชื่อโดยอาศัยความรู้สึกเพียงอย่างเดียวรวมทั้งของคุณ

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

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

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

กฎข้อที่ 2: อย่าผสมผสานการผลิตซอฟต์แวร์และวิธีการพัฒนาซอฟต์แวร์

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

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

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

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

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

กฎข้อที่ 3: ใช้การจัดเก็บข้อมูลแบบถาวรเป็นส่วนเสริมของหน่วยความจำของมนุษย์

ความจำของมนุษย์ถึงแม้จะมีความสามารถที่น่าทึ่ง แต่ก็มีขีดจำกัด คุณจดจำสิ่งต่าง ๆ ด้วยความแม่นยำและระยะเวลาที่คาดเดาไม่ได้ และเมื่อคุณลืม ไม่มีทางที่จะจำมันได้ตามต้องการ

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

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

ในการประชุม ให้พูดว่า “เดี๋ยวก่อน ฉันวางสิ่งนี้ลงไป” และใช้เวลา 10-30 วินาทีเพื่อเขียนเป็นลายลักษณ์อักษร การเขียนไม่ควรกว้างขวาง แต่ควรมีความสมบูรณ์และสอดคล้องกัน เช่น คุณกำลังถ่ายทอดแนวคิดทั้งหมดลงในกระดาษ ในภายหลัง คุณหรือใครก็ตามที่อ่านข้อความของคุณควรเข้าใจอย่างชัดเจนพอๆ กับที่คุณเข้าใจในตอนนี้ เคล็ดลับดังกล่าวช่วยประหยัดเวลาได้มาก แต่ยังช่วยให้คุณบันทึกได้ทันที

เทคนิคนี้มีวัตถุประสงค์สองประการ

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

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

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

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

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

กฎข้อที่ 4: หยุดเสียเวลากับการประมาณเวลาอย่างเป็นทางการ

ไม่มีสองโครงการเหมือนกัน ครั้งต่อไปที่คุณทำโครงการที่คล้ายคลึงกัน คุณจะมีลูกค้าที่แตกต่างกัน เป้าหมายที่แตกต่างกัน ทีมงานที่แตกต่างกัน อาจจะเป็นเทคโนโลยีที่แตกต่างกัน แม้จะใช้เครื่องมือและส่วนประกอบมาตรฐาน คุณยังต้องปรับแต่งการกำหนดค่าและสถาปัตยกรรม เมื่อคุณจัดการโครงการซอฟต์แวร์ พึงระลึกไว้เสมอว่าโครงการเหล่านี้เกี่ยวข้องกับงานที่กำหนดเองระหว่าง 50% ถึง 100% พวกเขาต้องการการวิจัย การอภิปราย การคิด การทดลอง และกิจกรรมอื่นๆ ที่คาดเดาไม่ได้ ในทางปฏิบัติ คุณอาจพบความแตกต่างอย่างมากในสิ่งที่ปรากฏบนพื้นผิวว่าเป็นโครงการแบบเดียวกันและสิ่งที่คุณเคยทำมาก่อน โครงการประเภทใหม่โดยการขยาย แทบจะเป็นไปไม่ได้เลยที่จะประมาณการได้อย่างแม่นยำ

ถ้ามันเป็นสิ่งที่คาดเดาไม่ได้ ผู้จัดการโครงการควรจะนำเสนอกำหนดการของโครงการและยึดติดกับมันอย่างไร?

มีวิธีการหนึ่งที่เป็นทางการในการทำเช่นนี้ที่อธิบายไว้ในวรรณกรรม กล่าวคือ แบ่งโครงการทั้งหมดออกเป็นขั้นตอนย่อยๆ ให้ประมาณการว่าแต่ละขั้นตอนใช้เวลานานเท่าใด จากนั้นจึงคำนวณความยาวรวมของโครงการโดยรวมความยาวงานของแต่ละชิ้น มีทฤษฎีมากมายที่อยู่เบื้องหลังวิธีนี้ซึ่งสอนในหลักสูตร MBA

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

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

ฉันต้องการเน้นผลลัพธ์ที่สำคัญสองประการของวิธีการที่อธิบายไว้ข้างต้น

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

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

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

กฎข้อที่ 5: ทำความเข้าใจต้นทุนของการเปลี่ยนงานและลำดับความสำคัญของการเล่นกล

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

จิตใจของนักพัฒนาคือสินทรัพย์ที่ยอดเยี่ยมในการพัฒนาซอฟต์แวร์อย่างแน่นอน ในฐานะผู้จัดการโครงการ คุณสนใจที่จะทำความเข้าใจให้ดีขึ้นและนำไปใช้ในตำแหน่งที่ทำงานได้ดีที่สุดหรือไม่?

พูดง่ายๆ คือ หลีกเลี่ยงทฤษฎีที่มากเกินไป จำไว้ว่าทฤษฎีจะพาคุณไปไกลได้ก่อนที่คุณจะต้องเรียนรู้จากประสบการณ์ ไม่ว่าของคุณเองหรือจากผู้อื่น

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

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

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

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

ตกลง. ตอนนี้เราได้สรุปแนวคิดในการเปลี่ยนงานแล้ว เรามาดูกันว่ามันทำงานอย่างไรในการทดลองทางความคิดในชีวิตจริง (อย่างที่จะพูด)

ลองนึกภาพว่าคุณมีนักพัฒนาประจำสิบคนทำงานประจำสิบงาน—หนึ่งงานต่อคน สมมติว่าเราสามารถรวมพวกเขาไว้ในสภาพแวดล้อมที่ปราศจากสิ่งรบกวนได้อย่างสมบูรณ์ งานแต่ละงานสามารถแก้ไขได้ในระยะเวลาหนึ่งด้วยจิตใจเพียงคนเดียว สิ่งทั้งหมดจะใช้เวลานานเท่าที่จำเป็นในการทำภารกิจเดียวที่ยาวที่สุดให้เสร็จ

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

ผู้จัดการโครงการในสถานการณ์แรกสามารถดำเนินโครงการได้อย่างมีประสิทธิภาพ คนที่สองจัดการเพื่อ "ดำเนินการ" ได้ แน่นอนว่า...ในแง่ที่พวกเขาช่วยให้การตายของมันง่ายขึ้น ยินดีด้วย. เทคนิคการฆ่าโปรเจ็กต์นี้มีประสิทธิภาพเป็นพิเศษ เพราะนอกจากจะเสียเวลาเปล่าแล้ว ยังทำให้ขวัญกำลังใจของพนักงานลดลงเหลือศูนย์อีกด้วย

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

นั่นเป็นสถานการณ์ในชีวิตจริงที่เกิดขึ้นค่อนข้างบ่อยอย่างน่าเสียดาย

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

กฎข้อที่ 6: ใช้การทบทวนสถาปัตยกรรมเป็นวิธีปรับปรุงการออกแบบระบบ

อุตสาหกรรมไอทีดำเนินงานด้วยแนวคิดเกี่ยว กับ วิศวกรรมที่สูงและ ต่ำ เมื่อพูดถึงการสัมภาษณ์ ทุกคนบอกว่า Over-engineering ไม่ดี คำตอบนั้นง่ายเพราะตัวคำถามเองสื่อความหมายเชิงลบของคำว่า "เกิน" ซึ่งแปลว่า "มากเกินไป" ความรู้เชิงปฏิบัติที่แท้จริงจะต้องรับรู้ได้อย่างไรเมื่อสถาปัตยกรรมของคุณมีการออกแบบทางวิศวกรรมมากเกินไป และควรหลีกเลี่ยงในช่วงแรกๆ

ให้ฉันให้คำแนะนำบางส่วนที่พยายามและเป็นจริงของฉันเกี่ยวกับเรื่องนั้น

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

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

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

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

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

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

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

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

กฎข้อที่ 7: Value Team Players

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

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

การสื่อสาร

แน่นอนคุณภาพแรกและสำคัญที่สุดคือความสามารถในการสื่อสาร

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

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

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

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

มาดูกรณีการใช้งานจริงในการตรวจจับและวัดความสามารถในการสื่อสารกัน

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

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

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

อีกส่วนหนึ่งของทักษะการสื่อสารคือความสามารถในการปรับให้เข้ากับผู้ฟัง

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

เข้าใจจุดแข็งและจุดอ่อน

มามุ่งเน้นที่คุณสมบัติส่วนบุคคลที่จำเป็นสำหรับผู้เล่นในทีม

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

นี่คือที่มาของบรรยากาศที่เป็นมิตรของทีม

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

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

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

กฎข้อที่ 8: Focus on Teamwork Organization

มีข้อมูลเพียงเล็กน้อยเกี่ยวกับองค์กรการทำงานเป็นทีมเช่นเดียวกับหัวข้อก่อนหน้าข้างต้น ทุกคนรู้ดีว่าการทำงานเป็นทีมนั้นดีกว่า แต่วิธีการสร้างและดูแลทีมยังคงเป็นปริศนา อย่างไรก็ตาม แม้ว่าจะเป็นไปไม่ได้ที่จะครอบคลุมทุกด้านของการสร้างทีม แต่อย่างน้อย เราสามารถสำรวจเทคนิคการสร้างทีมที่สำคัญบางประการได้ที่นี่

ความเชี่ยวชาญในการสร้าง

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

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

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

เรามาดูกันว่ามีวิธีรับมือกับข้อเสียโดยไม่ขัดขวางผลงานของทีมมากน้อยเพียงใด

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

ป้องกันสิ่งนี้โดยเปิดโอกาสในการเรียนรู้ที่อื่นสำหรับพวกเขา แจ้งให้พวกเขาทราบเกี่ยวกับโครงการและกลุ่มเทคโนโลยีของบริษัท และเปิดรับความท้าทายใหม่ๆ หากความสนใจของพวกเขาอยู่ในขอบเขตของโครงการ คุณจะได้รับรางวัลสองเท่าในการทำให้ทีมของคุณท้าทายและขยายชุดทักษะของทีมที่มีประโยชน์ไปพร้อมกัน However, any self development is good to avoid boredom, even if it doesn't intersect with immediate project needs. As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!