การจัดการกับประมาณการเป็นโปรแกรมเมอร์จูเนียร์


16

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

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

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

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


2
ฉันมีประสบการณ์คล้ายกันมากเมื่อฉันเริ่มงานแรกด้วย ไม่ต้องกังวลมันเป็นเรื่องธรรมดามาก
Rocklan

1
@ ratchetfreak นี่เป็นสิ่งที่โปรแกรมเมอร์แน่นอน ฉันมีประสบการณ์คล้ายกันในการฝึกงานแม้ว่าฉันจะเคยมีประสบการณ์การเขียนโปรแกรมมาก่อนมากมายเนื่องจากระบบที่เราทำงานนั้นใหญ่มาก
JSideris

1
การคาดคะเนเป็น Guesstimates สิ่งที่ทำเมื่อพวกเขาทำ บางครั้งคุณสามารถตัดมุม แต่คุณทำเช่นนี้สำหรับวันที่ยาก (รุ่น / ตัวอย่างลูกค้า / ... ) เพื่อไม่ให้ตรงกับการประมาณการที่คุณทำเมื่อ 3 วันที่ผ่านมา! 002
Martin Ba

คำตอบ:


12
  • นักพัฒนาหลายคนที่มีประสบการณ์ด้านการจัดการเพียงเล็กน้อยประเมินงานโดยใช้ความเร็วหรือความเร็วของนักพัฒนาที่ "ดีที่สุด" ในทีม

  • ความเร็วแตกต่างกันไปตามประสบการณ์ นักพัฒนาอาวุโสสามารถใช้เวลา 3 ชั่วโมงในการแก้ปัญหาบางอย่างเมื่อคุณใช้เวลา 2 วันทำการในการแก้ปัญหาเดียวกัน

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

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

จากประสบการณ์ของฉัน:

  • ฉันคิดว่านักพัฒนาอาวุโสหรือผู้จัดการควรจะสามารถประเมินเรื่องราวของผู้ใช้ (ความต้องการทางธุรกิจ) ในแง่ของขนาดเสื้อยืด (XL, L, M, S, XS)

  • มันเป็นงานของนักพัฒนาที่จะแบ่งเรื่องราวของผู้ใช้ออกเป็นงานที่เล็กลงและประเมินสิ่งเหล่านั้น งานที่มีขนาดใหญ่อาจต้องใช้นักพัฒนาอาวุโสต่อวันเพื่อแก้ปัญหาซึ่งอาจใช้เวลาตลอดทั้งสัปดาห์

  • มันสำคัญมากที่จะต้องบันทึกว่าคุณใช้เวลานานแค่ไหนในการทำภารกิจให้สำเร็จ

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

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


11

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

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


7

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

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

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

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


2

นี่เป็นเรื่องปกติ

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

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

หลังจากนั้นเพิ่มเวลาที่คุณคิดว่าจะใช้เวลาในการทดสอบการสื่อสารการวิเคราะห์และอื่น ๆ


1

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

ฉันขอแนะนำว่านี่คือความล้มเหลวของผู้จัดการของคุณ แต่มันเป็นและจะเป็นหน้าที่ของคุณในการจัดการความคาดหวัง

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

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

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

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

นักพัฒนาจะปรับปรุงเมื่อเวลาผ่านไปผู้อาวุโสเร็วกว่ารุ่นน้องและ "ความเร็ว" ของทีม - เดือนที่คาดการณ์ในเดือนนั้นจะดีขึ้นตามไปด้วย


1

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

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

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

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


0

ฉันขอแนะนำคุณให้รู้จักกับเพื่อนทั้งสองของฉัน WAG และ SWAG

เช่น 'Guess Wild Assed Guess' และ 'Guess Wild Assed Guess'

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

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

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

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

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

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

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


-1

นั่นเป็นสถานที่ที่ยากลำบาก ดูเหมือนว่าคุณกำลังติดอยู่ในขั้นตอน "เพียงแค่ต้องส่ง" ของท่อนั้น

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

  • ใครเป็นคนออกแบบ?
  • ใครเป็นคนประเมิน
  • ใครกำลังใช้งานอยู่

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.