บ่อยครั้งที่ผู้ปฏิบัติงานด้านวิทยาศาสตร์ข้อมูลจะกลายเป็นผู้จัดการโครงการโดยไม่ได้ตั้งใจ บางทีทีมงานโครงการของพวกเขาอาจมีขนาดเล็กเกินไปที่จะมีผู้จัดการโครงการเต็มเวลา หรือบางที นักวิทยาศาสตร์ด้านข้อมูลก็ยังจำเป็นต้องกำหนดและรับผิดชอบงานละเอียดที่เกี่ยวข้องกับโครงการระดับสูงถึงแม้จะอยู่ต่อหน้าผู้จัดการก็ตาม เหตุการณ์สำคัญ ตัวอย่างเช่น ในทีมโปรเจ็กต์ขนาดใหญ่ นักวิทยาศาสตร์ด้านข้อมูลอาจรับผิดชอบงาน "การพัฒนาแบบจำลองการกำหนดราคาเชิงคาดการณ์" ซึ่งประกอบด้วยงานเล็กๆ การทดลอง ความแตกต่าง และการพึ่งพาที่ละเอียดเกินกว่าจะพอดีกับโครงสร้างการจัดการโครงการแบบเดิม
เมื่อถึงเวลาต้องทำหน้าที่เป็น "ผู้จัดการโครงการอย่างไม่เป็นทางการ" มักจะเกี่ยวข้องกับการนำทางในส่วนต่างๆ ที่เคลื่อนไหว เช่น การมีส่วนร่วมของผู้มีส่วนได้ส่วนเสีย การตั้งค่าความคาดหวัง การทำความเข้าใจมูลค่าทางธุรกิจของโครงการหรืองาน และการสร้างตัวชี้วัดความสำเร็จ จากประสบการณ์ของผม นักวิทยาศาสตร์ข้อมูลที่มีทักษะทางอารมณ์ที่ดีมักจะประสบความสำเร็จในเรื่องที่กล่าวมาข้างต้น ในทางตรงกันข้าม ปัจจัยหนึ่งที่ฉันเห็นว่านักวิทยาศาสตร์ข้อมูลประเมินต่ำเกินไปหลายครั้งคือระยะเวลาของงาน
มันจะเกิดขึ้นกับเราทุกคน เราจะรู้สึกตื่นเต้นกับโปรเจ็กต์นี้ เมื่อผู้มีส่วนได้ส่วนเสียหลักจะไล่ออก: “คุณคิดว่าจะใช้เวลานานแค่ไหนจึงจะเสร็จสมบูรณ์?” และเกือบจะคงเส้นคงวาที่เราจะดูแคลนเวลาในการทำให้เสร็จ
ด้านล่างนี้คือตัวละครสองตัวที่สร้างจากเรื่องจริงที่เป็นตัวอย่างข้อผิดพลาดทั่วไปในการประมาณเวลา
คริส เดอะโค้ดเดอร์
ผู้มีส่วนได้ส่วนเสียอาวุโสต้องการให้เพื่อนร่วมงานด้านวิทยาศาสตร์ข้อมูล (ขอเรียกเขาว่า Chris the Coder) เพื่อฝึกอบรมแบบจำลองเพื่อแยกประเภทบทความข่าวที่เกี่ยวข้องและไม่เกี่ยวข้องจากฐานข้อมูลที่บริษัทของพวกเขาซื้อมา
“เฮ้ คริส ต้องใช้เวลานานแค่ไหนในการฝึกโมเดลเพื่อระบุข่าวที่เกี่ยวข้องและไม่เกี่ยวข้อง”
“ขึ้นอยู่กับขนาดของข้อมูล ฉันต้องใช้เวลาหนึ่งถึงสองวันในการประมวลผล จากนั้นอีกสองสามวันเพื่อปรับแต่งโมเดลอย่างละเอียด (ฉันจะเริ่มต้นด้วยเส้นฐาน) จากนั้น ฉันสามารถสร้างการคาดการณ์ได้ เพื่อให้ผู้มีส่วนได้ส่วนเสียหลักสามารถตรวจสอบอีกครั้ง และขึ้นอยู่กับการทำซ้ำนั้น การปรับแต่งเพิ่มเติมอีกสองสามวันและ 1 วันในการจัดทำเอกสารและรวมไว้ในโค้ดที่นำมาใช้ซ้ำได้”
ตามการประมาณการของ Chris จะใช้เวลาประมาณ 7 วันในการฝึกแบบจำลอง หรืออาจใช้เวลาประมาณ 10 วันสำหรับตัวประกอบการคูณ อย่างไรก็ตาม โครงการเฉพาะนี้ใช้เวลาห้าเดือนในการดำเนินการให้เสร็จสิ้นและส่งมอบผลลัพธ์สุดท้าย ซึ่งทำให้ผู้มีส่วนได้ส่วนเสียอาวุโสผิดหวังอย่างมาก
คริสประมาณการเวลาในการทำให้โปรเจ็กต์นี้เสร็จผิดพลาดไปได้อย่างไร เมื่อมันเกิดขึ้น Chris ละเลยหลักการบริหารโครงการแบบเก่าที่บอกเราว่า งานแตกต่างจากระยะเวลา คริสประมาณว่า งานของเขา จะใช้เวลาเท่าไร เขาไม่ได้ประมาณความจริงที่ว่าหากต้องการรับข้อมูลข่าว เขาจะต้องมีสิทธิ์เข้าถึงโต๊ะที่มีคนเพียงสองคนเท่านั้นที่สามารถอนุญาตได้ หลังจากได้รับการอนุมัติในการประชุมทางวิศวกรรมซึ่งจัดขึ้นทุกไตรมาส เขาไม่ได้ประมาณความจริงที่ว่าเมื่อได้รับชุดข้อมูลแล้ว ตารางต่างๆ ก็ไม่เป็นระเบียบจนเขาต้องจัดการประชุมกับเจ้าของสินทรัพย์เพื่อขอคำอธิบาย เขาไม่ได้ประมาณความจริงที่ว่าชุดข้อมูลมีขนาดใหญ่มากจนแม้แต่การแสดงภาพข้อมูลก็ใช้เวลาทั้งวัน ดังนั้นเขาจึงต้องหันไปพึ่ง "พันธมิตร" ซึ่งเป็นวิศวกรข้อมูลที่มีงานยุ่งคนหนึ่งของเขาเพื่อประมวลผลข้อมูลล่วงหน้าให้เขา ท้ายที่สุด เขาไม่ได้ประมาณ ระยะเวลา ของการพึ่งพา ซึ่งเพิ่มเวลารวมในการทำให้โครงการเสร็จสมบูรณ์ตามลำดับความสำคัญ!
เอลลี่ นักประมาณค่า
อีกตัวอย่างทั่วไปของการประเมินระยะเวลาที่ไม่ถูกต้องคือเมื่อมีคนถูกพาเข้ามาในโปรเจ็กต์ระหว่างทางเพื่อ "ช่วยเหลือ" เพื่อนร่วมงานที่อาจลางานเป็นเวลานาน หรืออาจจะเป็นโปรเจ็กต์เก่าที่ต้องรื้อฟื้นและทีมงานที่ทำก็สาบสูญไปนานแล้ว สถานการณ์นี้เกิดขึ้นกับเพื่อนของฉัน Ellie ซึ่งเป็นที่รู้กันว่าเชี่ยวชาญด้านการบริหารโครงการ นี่คือการสนทนากับผู้จัดการของเธอ
“ปีที่แล้วเราได้ทำโครงการเกี่ยวกับการคาดการณ์การแสดงผลแบบอนุกรมเวลา บุคคลที่ฝึกอบรมแบบจำลองได้เดินหน้าต่อไป แต่ตอนนี้ผู้มีส่วนได้ส่วนเสียอาวุโสคนหนึ่งต้องการอัปเดตโครงการเพื่อรวมข้อมูลใหม่ ฉันรู้สึกว่าควรใช้เวลาเพียงหนึ่งหรือสองวันคุณคิดว่าอย่างไร”
“ฉันต้องดูโครงการเป็นเวลาอย่างน้อยสองวันเพื่อพยายามทำความเข้าใจขั้นตอนในการอัปเดตข้อมูล จากนั้นฉันจะกลับมาหาคุณพร้อมประมาณการได้”
คำตอบของ Ellie ทำให้ผู้จัดการของเธอผิดหวังเล็กน้อย แต่ก็ช่วยประหยัดเวลาของเธอได้ในระยะยาว สิ่งที่อาจมองว่าเป็นการ “เสียเวลาสองวัน” เพียงพยายามทำความเข้าใจโครงการ ทำให้มีภาพที่ดีของงาน หากเธอไม่ “เสียเวลาไปสองวัน” เธอคงไม่สังเกตเห็นว่า:
- รหัสขาดเอกสารที่ชัดเจน เธอไม่คุ้นเคยกับแบบจำลองนี้มากนัก และการนำเสนอด้วยพาวเวอร์พอยต์ที่ให้มาก็ไม่ได้ช่วยชี้แจงวิธีการสร้างผลลัพธ์ขึ้นมาใหม่
- ฟีเจอร์บางอย่างดูเหมือนจะได้รับการฮาร์ดโค้ด โดยมีคำอธิบายเพียงเล็กน้อยว่าทำไมจึงต้องเป็นเช่นนั้น
- โมเดลที่ผ่านการฝึกอบรม ดูเหมือน จะมีความเฉพาะเจาะจงสำหรับปีนั้น และจำเป็นต้องได้รับการฝึกอบรมใหม่หากต้องการให้มีความแม่นยำ
- ส่วนหนึ่งของรหัสระบุว่า "ตรวจสอบโดย Carlos ด้วยตนเอง" ซึ่งบอกเป็นนัยว่าผู้มีส่วนได้ส่วนเสียรายอื่นต้องตรวจสอบข้อมูลเมื่ออัปเดตแล้ว
แต่ละขั้นตอนเหล่านี้เป็นความเสี่ยงที่คาดการณ์ไว้และเพิ่มระยะเวลารวมของโครงการ (รวมถึงความน่าจะเป็นของความสำเร็จทั้งหมด) ไม่มีสิ่งใดที่จะเป็นตัวบล็อกได้อย่างสมบูรณ์ อย่างไรก็ตาม พวกมันจะต้องถูกดำเนินการ ในการสื่อสารอย่างชัดเจน เธอสามารถให้กำหนดเวลาที่ชัดเจนมากขึ้นแก่ผู้จัดการของเธอ และลดความคาดหวังที่เพิ่มขึ้น
ตัวอย่างทั้งสองนี้แสดงให้เราเห็นว่าการประมาณค่างานของคุณเองมักเป็นเพียงองค์ประกอบหนึ่งในการประเมินระยะเวลายกเว้นของโครงการของคุณ เรารู้ว่าเราใช้เวลานานเท่าใดในการฝึกโมเดลแมชชีนเลิร์นนิง สร้างกราฟ หรือพัฒนาแอปพลิเคชันเบราว์เซอร์พื้นฐาน อย่างไรก็ตาม ในการประมาณ ระยะเวลา ของงาน เราต้องพิจารณาปัจจัยต่างๆ ที่มักจะอยู่นอกเหนือการควบคุมของเรา ต่อไปนี้เป็นรายการธีมทั่วไป โดยไม่ครอบคลุมทั้งหมด:
- การเข้าถึงข้อมูลจะใช้เวลานานเท่าใด?
- ฉันมีสิทธิ์ที่จำเป็นหรือไม่? ใครคือผู้ที่สามารถอนุญาตให้ฉันเข้าถึงได้ และพวกเขาจะทำได้เร็วแค่ไหน?
- ข้อมูลมีการจัดระเบียบอย่างไร? มีพจนานุกรมไหม? ฉันสามารถเข้าถึงเจ้าของสินทรัพย์ที่เข้าใจได้หรือไม่?
- เมื่อถึงโครงการกลางทางแล้วเอกสารจะดีแค่ไหน?
- หากมีคนอื่นในทีมของคุณต้องให้ข้อมูลแก่กระบวนการนี้ พวกเขางานยุ่งแค่ไหนและกำหนดเวลาส่งเชื่อถือได้แค่ไหน
- หากคุณต้องการข้อมูลจากผู้มีส่วนได้ส่วนเสียก็เช่นกัน
มักจะมีประโยชน์ในการเขียนงานลงในตาราง โดยระบุว่างานใดมีความสำคัญ ซึ่งเป็นเครื่องมือที่ผู้จัดการโครงการชอบเรียกว่า การแมปการพึ่งพา ซอฟต์แวร์เฉพาะที่คุณใช้ไม่เกี่ยวข้อง — ทีมต่างๆ จะใช้ซอฟต์แวร์ที่แตกต่างกันในการบันทึกงาน (หรือหากคุณเป็นคนโพสต์อิท ก็ลงมือเลย!) ด้านล่างนี้เป็นตัวอย่างระดับสูงของวิธีการพิจารณาการขึ้นต่อกัน:
การมีแผนผังการพึ่งพาที่แม่นยำนั้นเป็นงานที่ยาก และคุณอาจต้องอัปเดตเป็นระยะๆ เพื่อปรับเปลี่ยนในสถานการณ์ที่ไม่คาดฝัน ในทางกลับกัน การไม่มีแผนที่เป็นความแน่นอนในการประเมินระยะเวลาของโครงการต่ำไป แผนที่จะต้องปรากฏแก่ผู้มีส่วนได้ส่วนเสียหลักและสะท้อนถึงการคาดเดาที่ดีที่สุดของคุณในแต่ละงาน มั่นใจได้ว่าเวลาเริ่มแรกที่ลงทุนโดยคิดถึงงานของคุณคือเวลาที่ใช้ไปอย่างคุ้มค่า!
คุณสามารถเป็นนักวิทยาศาสตร์ข้อมูลที่เร็วที่สุดในโลกในแง่ของการเขียนโค้ด แต่ยังไม่ตรงตามกำหนดเวลา หากคุณไม่คำนึงถึงระยะเวลาของการพึ่งพาของคุณ
หากคุณมีเครื่องมืออื่นใดที่จะช่วยคุณประมาณระยะเวลาของโครงงานวิทยาศาสตร์ข้อมูล โปรดแสดงความคิดเห็นด้านล่าง
หมายเหตุ: คำว่า “โดยบังเอิญ” หรือ “ไม่เป็นทางการ” ผู้จัดการโครงการมาจากหนังสือสองเล่มที่ฉันแนะนำเป็นอย่างยิ่ง: การจัดการโครงการสำหรับผู้จัดการโครงการที่ไม่เป็นทางการ โดย Kary Kagon, Suzette Blakemore และ James Wood และ Accidental Agile ผู้จัดการโครงการ: Zero to Hero in 7 Iterations โดย Ray Frohnhoefer และผู้แต่งคนอื่นๆ
