Tim Lister - ผู้ร่วมเขียนหนังสือ

• “ปัจจัยของมนุษย์ โครงการและทีมงานที่ประสบความสำเร็จ" (หนังสือต้นฉบับชื่อ "พีเพิลแวร์")
• "Waltzing with the Bears: การจัดการความเสี่ยงในโครงการซอฟต์แวร์"
• “อะดรีนาลีนบ้าคลั่งและซอมบี้ในรูปแบบต่างๆ รูปแบบพฤติกรรมของทีมงานโครงการ”

หนังสือทั้งหมดนี้เป็นหนังสือคลาสสิกในสาขาของตนและเขียนร่วมกับเพื่อนร่วมงานใน สมาคมระบบแอตแลนติก. ในรัสเซีย เพื่อนร่วมงานของเขามีชื่อเสียงมากที่สุด - ทอม เดอมาร์โก и ปีเตอร์ ฮรุชกาผู้ซึ่งเขียนผลงานชื่อดังมากมาย

Tim มีประสบการณ์ 40 ปีในการพัฒนาซอฟต์แวร์ ในปี 1975 (ไม่มีผู้เขียน Habrapost นี้เกิดในปีนี้) Tim ดำรงตำแหน่งรองประธานบริหารของ Yourdon Inc. อยู่แล้ว ปัจจุบันเขาใช้เวลาให้คำปรึกษา สอน และเขียน โดยแวะเยี่ยมชมเป็นครั้งคราว พร้อมรายงาน การประชุมทั่วโลก

เราได้สัมภาษณ์กับ Tim Lister โดยเฉพาะสำหรับ Habr เขาจะเปิดการประชุม DevOops 2019 และเรามีคำถามมากมายเกี่ยวกับหนังสือและอื่นๆ อีกมากมาย การสัมภาษณ์ดำเนินการโดย Mikhail Druzhinin และ Oleg Chirukhin จากคณะกรรมการโครงการการประชุม

ไมเคิล: คุณช่วยพูดสักสองสามคำเกี่ยวกับสิ่งที่คุณกำลังทำอยู่ตอนนี้ได้ไหม?

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

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

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

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

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

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

19 ปีแห่งความคล่องตัว

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

ทิม: ฉันคิดว่าวิธีการแบบคล่องตัวเริ่มต้นจาก ประกาศเปรียว ในปี 2001 ได้เปิดหูเปิดตาของอุตสาหกรรม แต่ในทางกลับกัน ไม่มีอะไรสมบูรณ์แบบ ฉันทั้งหมดเพื่อการพัฒนาซ้ำ การวนซ้ำมีประโยชน์มากในโครงการส่วนใหญ่ แต่คำถามที่คุณต้องคำนึงถึงก็คือ เมื่อผลิตภัณฑ์หมดและใช้งานแล้ว จะอยู่ได้นานแค่ไหน? นี่เป็นผลิตภัณฑ์ที่จะใช้งานได้หกเดือนก่อนที่จะถูกแทนที่ด้วยสิ่งอื่นหรือไม่ หรือนี่เป็นผลิตภัณฑ์ที่จะใช้งานได้นานหลายปี? แน่นอนว่าฉันจะไม่เอ่ยชื่อ แต่... ในนิวยอร์กและชุมชนการเงิน ระบบพื้นฐานที่สุดนั้นเก่ามาก นี่มันอัศจรรย์มาก. คุณมองดูพวกเขาแล้วคิดว่า ถ้าคุณสามารถย้อนเวลากลับไปในปี 1994 และบอกนักพัฒนาว่า “ฉันมาจากอนาคต ตั้งแต่ปี 2019” เพียงพัฒนาระบบนี้ให้นานเท่าที่คุณต้องการ ทำให้สามารถขยายได้ คิดถึงสถาปัตยกรรม และจะปรับปรุงต่อไปอีกกว่ายี่สิบห้าปี หากคุณชะลอการพัฒนาอีกสักหน่อย ในรูปแบบอันยิ่งใหญ่ของสิ่งที่จะไม่มีใครสังเกตเห็น!” เมื่อคุณจะประมาณสิ่งต่างๆ ในระยะยาว คุณต้องพิจารณาว่าจะมีค่าใช้จ่ายทั้งหมดเท่าใด บางครั้งสถาปัตยกรรมที่ได้รับการออกแบบมาอย่างดีก็คุ้มค่าจริงๆ และบางครั้งก็ไม่คุ้มเลย เราต้องมองไปรอบ ๆ และถามตัวเองว่าเราอยู่ในสถานการณ์ที่เหมาะสมสำหรับการตัดสินใจเช่นนี้หรือไม่?

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

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

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

โอเล็ก: คุณกล่าวถึง Agile Manifesto เราจำเป็นต้องอัปเดตหรือแก้ไขโดยคำนึงถึงความเข้าใจที่ทันสมัยของปัญหานี้หรือไม่?

ทิม: ฉันจะไม่แตะต้องเขา ฉันคิดว่ามันเป็นเอกสารประวัติศาสตร์ที่ยิ่งใหญ่ ฉันหมายความว่าเขาเป็นสิ่งที่เขาเป็น เขาอายุ 19 ปี เขาแก่แล้ว แต่ในสมัยของเขา เขาได้ทำการปฏิวัติ สิ่งที่เขาทำได้ดีคือเขากระตุ้นปฏิกิริยาและผู้คนก็เริ่มกระซิบเกี่ยวกับเขา เป็นไปได้มากว่าคุณยังไม่ได้ทำงานในอุตสาหกรรมนี้ในปี 2001 แต่แล้วทุกคนก็ทำงานตามกระบวนการ สถาบันวิศวกรรมซอฟต์แวร์ XNUMX ระดับของแบบจำลองความสมบูรณ์ของซอฟต์แวร์ (CMMI) ฉันไม่รู้ว่าตำนานโบราณวัตถุอันล้ำลึกดังกล่าวบอกอะไรบางอย่างกับคุณได้ไหม แต่แล้วมันก็เป็นความก้าวหน้า ในตอนแรกผู้คนเชื่อว่าหากตั้งค่ากระบวนการอย่างถูกต้อง ปัญหาต่างๆ ก็จะหายไปเอง จากนั้นแถลงการณ์ก็มาพร้อมและพูดว่า: "ไม่ ไม่ ไม่ เราจะอยู่บนพื้นฐานของผู้คน ไม่ใช่กระบวนการ" เราเป็นผู้เชี่ยวชาญด้านการพัฒนาซอฟต์แวร์ เราเข้าใจดีว่ากระบวนการในอุดมคตินั้นเป็นภาพลวงตา แต่มันไม่เกิดขึ้น โปรเจ็กต์มีความแปลกประหลาดมากเกินไป แนวคิดของกระบวนการที่สมบูรณ์แบบเพียงกระบวนการเดียวสำหรับทุกโปรเจ็กต์นั้นไม่สมเหตุสมผลเลย ปัญหาซับซ้อนเกินกว่าจะอ้างว่าทุกสิ่งมีทางแก้ทางเดียวเท่านั้น (สวัสดี นิพพาน)

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

พีเพิลแวร์: 30 ปีต่อมา

โอเล็ก: Peopleware เป็นการปฏิวัติเช่นเดียวกับ Manifesto หรือไม่?

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

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

ไมเคิล: มีอะไรเปลี่ยนแปลงไปในช่วง 30 ปีที่ผ่านมานับตั้งแต่หนังสือเล่มนี้ตีพิมพ์หรือไม่?

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

เราทุกคนอาศัยอยู่ใน DevOps

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

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

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

ไมเคิล: แนวคิดทั้งหมดของ devops คือการส่งมอบการพัฒนาที่มีความหมายให้เร็วที่สุด ฉันเห็นว่าโลกเริ่มเร็วขึ้นเรื่อยๆ จะปรับตัวเข้ากับความเร่งดังกล่าวได้อย่างไร? เมื่อสิบปีก่อนสิ่งนี้ไม่มีอยู่จริง!

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

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

รูปแบบและการต่อต้านรูปแบบ

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

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

เราแค่คุยกับสหายของเราว่าปีนี้เป็นปีที่ครบรอบ 1969 ปีนับตั้งแต่ผู้คนเหยียบดวงจันทร์ นี่คือในปี 1969 เทคโนโลยีที่ช่วยให้ผู้คนไปถึงที่นั่นนั้นไม่ใช่แม้แต่เทคโนโลยีปี 1960 แต่เป็นปี 62 หรือ XNUMX เพราะ NASA ต้องการใช้เฉพาะสิ่งที่มีหลักฐานที่ดีว่าเชื่อถือได้เท่านั้น ดังนั้นคุณจึงดูและเข้าใจ - ใช่แล้วและมันก็เป็นเรื่องจริง! ทีนี้ ไม่ ไม่ แต่คุณประสบปัญหากับเทคโนโลยีเพียงเพราะว่าทุกอย่างถูกกดดันมากเกินไป และถูกขายหมดสิ้นไป ผู้คนต่างตะโกนจากทุกที่: "ดูสิ นี่มันของใหม่ล่าสุด สวยที่สุดในโลก เหมาะสำหรับทุกคนจริงๆ!" แค่นั้นแหละ... โดยปกติแล้วทั้งหมดนี้จะกลายเป็นเพียงตัวล่อแล้วทุกอย่างก็ต้องถูกโยนทิ้งไป บางทีทั้งหมดอาจเป็นเพราะฉันแก่แล้วและมองสิ่งเหล่านี้ด้วยความสงสัยอย่างมาก เมื่อผู้คนหมดความสนใจและบอกว่าพวกเขาพบวิธีเดียวที่ถูกต้องที่สุดในการสร้างเทคโนโลยีที่ดีที่สุด ในขณะนี้ มีเสียงปลุกขึ้นมาในตัวฉันว่า “นี่มันยุ่งจริงๆ!”

ไมเคิล: อันที่จริง เราได้ยินเกี่ยวกับกระสุนเงินครั้งต่อไปบ่อยแค่ไหน?

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

ไมเคิล: ใช่ “คำถามหลักเกี่ยวกับชีวิต จักรวาล และทุกสิ่ง” เทคโนโลยีหรือแนวทางนี้เหมาะสมกับสถานการณ์ของคุณหรือไม่?

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

ตำนาน “วิศวกร Devops”

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

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

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

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

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

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

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

“ผู้เชี่ยวชาญทุกเรื่อง”

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

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

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

ความเสี่ยงและความไม่แน่นอน

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

โอเล็ก: เคลื่อนที่อย่างรวดเร็วและทำลายสิ่งของ!

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

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

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

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

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

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

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

การคิดทางวิศวกรรมสำหรับผู้ใหญ่

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

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

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

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

โอเล็ก: ชีวิตของคุณคือโครงการของคุณซึ่งคุณจัดการ

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

จะเข้าสู่การบริหารความเสี่ยงได้อย่างไร

โอเล็ก: มีโครงสร้างความรู้ที่เป็นทางการในด้านนี้หรือไม่? ตัวอย่างเช่น ฉันเป็นนักพัฒนา Java และต้องการเข้าใจการบริหารความเสี่ยงโดยไม่ต้องเป็นผู้จัดการโครงการจริงๆ ด้วยการศึกษา ฉันอาจจะอ่าน "โครงการซอฟต์แวร์ราคาเท่าไหร่" ของ McConnell ก่อนแล้วจึงจะเป็นอย่างไร ขั้นตอนแรกคืออะไร?

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

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

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

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

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

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

ราคาของการสื่อสาร

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

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

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

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

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

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

ไมเคิล: ไปเขียนโค้ดกัน!

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

โอเล็ก: มิชา คุณกำลังคิดอะไรบางอย่าง

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

ชีวิตที่ไม่มีเงินเดือน

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

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

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

คำแนะนำที่ดีที่สุด

ไมเคิล: กลับมาที่ “คำแนะนำที่ดีที่สุด” มีอะไรที่คุณบอกลูกค้าของคุณซ้ำแล้วซ้ำอีกหรือไม่? มีแนวคิดประมาณ 80/20 และคำแนะนำบางอย่างอาจทำซ้ำบ่อยกว่านั้น

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

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

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

ฝึกฝนการบริหารความเสี่ยง!

ไมเคิล: ในความเห็นของคุณ มีองค์กรกี่แห่งที่มีส่วนร่วมในการบริหารความเสี่ยง?

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

ไมเคิล: แล้วมีกี่บริษัทที่เกี่ยวข้องกับการบริหารความเสี่ยง ห้าเปอร์เซ็นต์?

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

ใช่ ฉันมักจะได้ยินว่า “เราจะแก้ไขปัญหาที่เกิดขึ้น” แน่นอนเราจะ? เราจะตัดสินใจได้จริงหรือ?

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

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

ทิม: มากดปุ่มรีเซ็ตกันเถอะ! ไม่ มันไม่ทำงานอย่างนั้น

คำปราศรัยที่ DevOops 2019

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

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

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

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

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

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

Tim Lister จะมาถึงพร้อมกับปาฐกถาสำคัญ “ลักษณะ ชุมชน และวัฒนธรรม: ปัจจัยสำคัญเพื่อความเจริญรุ่งเรือง”สู่การประชุม DevOops 2019 ซึ่งจะจัดขึ้นในวันที่ 29-30 ตุลาคม 2019 ที่เมืองเซนต์ปีเตอร์สเบิร์ก คุณสามารถซื้อตั๋วได้ บนเว็บไซต์อย่างเป็นทางการ. เรากำลังรอคุณอยู่ที่ DevOops!

ที่มา: will.com