เส้นตายที่ไม่ได้รับทั่วไปในงานเขียนโปรแกรมหรือไม่ [ปิด]


18

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

คำถามของฉันคือ: นี่เป็นความกังวลใหญ่หรือพลาดกำหนดเวลาทั่วไปในการเขียนโปรแกรมงานดังนั้นฉันไม่ควรกังวลเกี่ยวกับเรื่องนี้มากเกินไป?


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


3
วันครบกำหนดที่ไม่ได้รับเป็นเรื่องธรรมดาในงานทั้งหมด
Steven A. Lowe

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

6
ทำเร็วทำถูกทำดี: เลือกสองข้อ
ซ้ำ

คำตอบ:


45

ใช่. กำหนดส่งที่ไม่ได้รับเป็นเรื่องปกติในการพัฒนาซอฟต์แวร์

นักแปลอิสระหลายคนทำตามกำหนดเวลาโดยการก่อหนี้หนี้สินทางเทคนิคหรือซ่อนสิ่งสกปรกไว้ใต้พรม

การถอดความเดือนเฟรเดอริคบรูค ' The Mythical Man :

Frederick Brooks ผู้แต่ง The Mythical Man Month

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

  • การพัฒนาซอฟต์แวร์มีความซับซ้อนโดยธรรมชาติซึ่งสาขาอื่นขาด โปรแกรมขนาดใหญ่สามารถมีส่วนประกอบได้มากกว่ารถยนต์และส่วนประกอบเหล่านี้สามารถโต้ตอบได้หลากหลายวิธี

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

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

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

  • ส่วนใหญ่vaporwareคืออะไร แต่ซอฟต์แวร์โครงการที่ถูกตัดเพราะชนิดของปัญหาเหล่านี้

สรุปแล้ว:

การประเมินที่ไม่ถูกต้องและการประเมินความซับซ้อนต่ำเกินไปเนื่องจากลักษณะงานฝีมือของกระบวนการพัฒนาซอฟต์แวร์หมายความว่ามันยังคงมีระเบียบวินัยที่ไม่สมบูรณ์


11
+ คำตอบที่ดี แต่เมื่อมีการสัมผัสกับวิศวกรรมเครื่องกลและวิศวกรรมโยธามันเป็นเรื่องน่าขบขันที่โปรแกรมเมอร์ทำการเปรียบเทียบได้ง่ายกับการสร้างสะพานและสิ่งอื่น ๆ เมื่อพวกเขาไม่ได้คิดอย่างถ่องแท้
Mike Dunlavey

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

2
@ user61852: คุณเข้าใจฉันผิด 'แผน' สู่วิศวกรรมเป็น 'แหล่งที่มา' ของวิทยาการคอมพิวเตอร์ - คือคำอธิบายโดยละเอียดของทุกองค์ประกอบ - แต่เมื่อเรามีมันแล้วเราสามารถสร้างมันขึ้นมาได้ (ใส่makeหรืออะไรก็ได้) อะไรคือ 'แผน' ในวิทยาการคอมพิวเตอร์จะเป็นแผน ของแผน 'ใน engeneering ความแตกต่างคือmakeในวิทยาการคอมพิวเตอร์ใช้เวลาไม่กี่ชั่วโมงในขณะที่เขียนซอร์สโค้ด (รวมถึงการทดสอบและการรวม) ใช้เวลาเป็นเดือนในขณะที่ในด้านวิศวกรรมการวางแผนอาจใช้เวลาเป็นเดือน (รวมถึงการคำนวณเชิงโครงสร้าง) ในขณะที่การก่อสร้างใช้เวลาเป็นปี ในภายหลัง
Maciej Piechotka

1
@ user61852: เกี่ยวกับความซ้ำซ้อน - คอมพิวเตอร์สิ่งหนึ่งที่ยอดเยี่ยมคือระบบอัตโนมัติ สมมติว่าคุณต้องสร้างบล็อกง่าย ๆ - เมื่อถึงตอนที่คุณมี 'การประมาณ' ที่ถูกต้องคุณจะได้รับ wordpress (หรือระบบบล็อกอื่น ๆ ) ในสถานที่ดังนั้นคุณไม่จำเป็นต้องทำอะไรเลย (ในกรณีของสะพาน คุณยังคงมีสภาพแวดล้อมที่แตกต่างกันดังนั้นคุณจำเป็นต้องปรับตัวให้ดีขึ้นเนื่องจากหินอาจจะแตกต่างกันหรืออาจมีที่อยู่อาศัยของนกหรืออาจทำลายมุมมอง) - โปรแกรมเมอร์อาจมีความรับผิดชอบในการสร้างเครื่องมือมากขึ้น (รุ่นสะพานมาตรฐาน)
Maciej Piechotka

2
โบนัสสำหรับการเสนอข่าวเดือนคนในตำนาน; หลังจากหลายปีที่ผ่านมาเฟรดเดอริกบรูคส์ได้มุ่งเน้นไปที่คนที่ไม่ใช่เทคโนโลยี
Michael Shopsin

3

วันครบกำหนดที่ไม่ได้รับไม่ควรกลายเป็นเรื่องธรรมดาหากคุณต้องการทำงานต่อ

ด้วยที่กล่าวไว้โดยทั่วไปคุณต้องการปล่อยให้ตัวเองมีห้อง "กระดิก" เพิ่มเติมในการประมาณการของคุณในกรณีที่มีสิ่งต่าง ๆ เกิดขึ้น (และมันก็ทำเสมอ) คุณไม่จำเป็นต้องเปิดเผยว่าคุณได้เพิ่มในเวลาพิเศษเพียงแค่ไม่ทำให้มันไม่มีเหตุผล อาจจะอยู่ระหว่าง 5 - 10% ของเวลาทั้งหมด วิธีเดียวที่คุณจะพบคือทำสองสามครั้ง

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


2
ฉันให้ห้อง 20% เสมอเมื่อทำการประมาณ 5-10% น้อยเกินไป ฉันคิดว่ามันขึ้นอยู่กับว่าคุณเป็นคนฟุ้งซ่าน พัฒนาเดี่ยวอาจไม่ฟุ้งซ่านที่ทุกคน
BЈовић

ฉันเป็นนักพัฒนาเดี่ยวและฉันมักจะรับกำไร 10% สำหรับโครงการของฉัน
Konsole

อืม ... ดูHofstadter's_law
Philip

1
เมื่อเทียบกับ 5-20% ฉันคิดว่าอัตรากำไร 100% จะดีกว่า อย่างจริงจัง. ช่วยให้คุณสำรวจตัวเลือกของคุณได้ดียิ่งขึ้น และตอบคำถามเพิ่มเติมใน Stack Exchange
คิวเมนตัส

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

3

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

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


2

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

สิ่งที่น่าอัศจรรย์เกี่ยวกับความเร็วคือมันครอบคลุมทุกสิ่งที่จับต้องไม่ได้เช่นการขัดจังหวะและความซับซ้อนที่ไม่คาดคิดซึ่งนักพัฒนามีการบันทึกเวลาที่ยากลำบากในการประมาณของพวกเขา ความน่าจะเป็นทั้งหมดเฉลี่ยเมื่อเวลาผ่านไป โดยเฉลี่ยนานกว่า 10 สัปดาห์การประมาณความเร็วของเรานั้นแม่นยำภายใน 5% แต่เมื่อเราประเมินงานเดียวกันในไม่กี่ชั่วโมงทีมงานเดียวกันจะประเมินค่าต่ำกว่า 30-50% อย่างสม่ำเสมอ


1

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

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

ถ้าใครออกแบบห้องครัวใหม่พวกเขามักคิดว่า 'ฉันจะทำเสร็จภายในสองสัปดาห์' พวกมันเสร็จประมาณหกสัปดาห์ต่อมา


1
นาซ่าเกี่ยวข้องกับคำถามของฉันอย่างไร

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

ในขณะที่ฉันยอมรับว่าการคาดการณ์ของคนส่วนใหญ่ถูกปิดอย่างน้อยสองเท่า แต่หน่วยเวลาต่อไป ... hmmmm อย่างไรก็ตามนาซ่าเก่งมากในการประเมินงานที่พวกเขารู้อยู่แล้วว่าจะทำอย่างไร ปัญหาคือคนไม่เก่งในการประเมินงานเมื่อพวกเขาไม่รู้ว่าพวกเขาไม่รู้อะไร การที่นาซ่าทำงานเป็นผู้บุกเบิกอย่างแท้จริงจึงไม่น่าแปลกใจที่ไม่รู้ว่าพวกเขากำลังทำอะไรอยู่จนกระทั่งพวกเขาเริ่มทำมัน ดังนั้นเหตุผลของการประเมินต่ำเริ่มต้น นอกจากนี้บางคนก็มักจะมองโลกในแง่ดีและคนอื่น ๆ ในแง่ร้าย ไม่แน่ใจว่าเกี่ยวข้องกับวิวัฒนาการ
Dunk
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.