จะอธิบายให้คนที่ไม่ใช่ช่างเทคนิคทราบได้อย่างไรว่าทำไมงานจึงใช้เวลานานกว่าที่คิด [ปิด]

นักพัฒนาซอฟต์แวร์เกือบทุกคนต้องตอบคำถามจากฝ่ายธุรกิจเช่น:
เหตุใดจึงต้องใช้เวลา 2 วันในการเพิ่มแบบฟอร์มติดต่ออย่างง่ายนี้

เมื่อนักพัฒนาประเมินงานนี้พวกเขาอาจแบ่งออกเป็นขั้นตอน:

• ทำการเปลี่ยนแปลงฐานข้อมูล
• เพิ่มประสิทธิภาพการเปลี่ยนแปลงฐานข้อมูลเพื่อความเร็ว
• เพิ่มส่วนหน้า HTML
• เขียนโค้ดฝั่งเซิร์ฟเวอร์
• เพิ่มการตรวจสอบ
• เพิ่มจาวาสคริปต์ฝั่งไคลเอ็นต์
• ใช้การทดสอบหน่วย
• ตรวจสอบให้แน่ใจว่าการตั้งค่า SEO ใช้งานได้
• ใช้การยืนยันทางอีเมล
• refactor และเพิ่มประสิทธิภาพรหัสสำหรับความเร็ว
• ...

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

ดังนั้นจะมีวิธีที่ดีกว่าในการอธิบายว่าทำไมการประมาณการจึงสูงถึงผู้ที่ไม่ใช่นักพัฒนา

คุณเพิ่งทำมันในคำถามของคุณ

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

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

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

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

แต่คุณอาจสูญเสียการจัดการโครงการของคุณในคำว่า "DB" หากไม่ใช่คำว่า "optimization"

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

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

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

ที่สำคัญที่สุดคือสิ่งต่อไปนี้:

• ซื้อการพูดคุยมากที่สุดเกี่ยวกับการรับรู้ของลูกค้าและการใช้งานผลิตภัณฑ์คุณกำลังจะเข้ามามีส่วนร่วมในการพูดภาษาของพวกเขา - ภาษาของ $$ - ประเด็นคือถ้ารหัสถูกแฮ็คเข้าด้วยกันอย่างกระจัดกระจาย ในฟีเจอร์นี้จากนั้นจะมีฟีเจอร์ที่ตามมาเมื่อแนวทางการพัฒนาที่ไม่ดีทำให้ไม่สามารถขยายรหัสได้
• กำหนดลำดับเหตุการณ์ คำถามที่ไม่ใช่ด้านเทคนิคถัดไปจะเป็น "ถ้าเรามีนักพัฒนามากกว่าคุณนี้จะเกิดขึ้นเร็วกว่านี้หรือไม่ถ้าเป็นเช่นนั้นถ้าใช้เวลา 40 ชั่วโมงในการทำสิ่งนี้จะเกิดขึ้น 40 คนในบ่ายวันนี้หรือไม่" แน่นอนคำตอบคือ "ไม่! คุณออกจากจิตใจของคุณหรือไม่" แต่นั่นไม่ใช่สิ่งที่ดีที่สุด สิ่งที่ดีที่สุดคือมีลำดับขั้นตอนแบบลอจิคัลที่นี่ สิ่ง B ไม่สามารถทำได้จนกว่าสิ่ง A จะเกิดขึ้น (ถ้าคุณยังไม่ได้เขียนโค้ดใด ๆ คุณจะไม่สามารถเพิ่มประสิทธิภาพหรือทดสอบได้ ... ) สิ่งที่ A และ A สามารถทำได้ร่วมกันดังนั้นหากพวกเขาสามารถสำรองคนฉลาดนั่นตรงนั้นคุณสามารถโกนเวลาจากหนึ่งสัปดาห์เป็น 4 วันและถ้าพวกเขาสามารถรับประกันการสนับสนุนการทดสอบที่ยอดเยี่ยมคุณก็อาจจะไป 3 วัน. มี'
• มุ่งเน้นไปที่ความเสี่ยงและเตรียมพร้อมที่จะรับทราบว่าความเสี่ยงบางอย่างมีค่าในเวลานี้ นั่นคือสิ่งที่นักธุรกิจได้รับจากการจ่ายเงินจำนวนมากเพื่อค้นหาความเสี่ยงที่คุ้มค่า ตัวอย่างเช่นหากความเร็วในการทำตลาดมีผลการดำเนินงานต่ำเนื่องจาก บริษัท ของคุณมีเงินสดเพียงพอที่จะทำเซิร์ฟเวอร์จำนวนไร้สาระในระยะสั้นคุณอาจถูกบอกให้ข้ามสิ่งต่าง ๆ ในขั้นตอนที่ 4 (การเพิ่มประสิทธิภาพของรหัส / ฐานข้อมูล ) นั่นคือสิ่งที่ถูกต้อง - เป็นเพียงงานของคุณที่จะอธิบายความเสี่ยงที่มีอยู่ในการตัดสินใจ
• อย่างไรก็ตามถ้าคุณไม่เชื่อใจคนเหล่านี้คุณต้องได้รับการยืนยันเป็นลายลักษณ์อักษร - ไม่จำเป็นต้องมีการเผชิญหน้าเพียงแค่อีเมลฉบับย่อว่า "นี่คือสิ่งที่ฉันคิดว่าเราพูดถึงนี่คือสิ่งที่ฉันไม่ได้ทำนี่คือ ความเสี่ยงฉันจะทำตอนนี้ดังนั้นแจ้งให้เราทราบหากคุณไม่เห็นด้วย ... ถ้าฉันไม่ได้ยินคุณจะถือว่านี่เป็นวิธีที่เหมาะสมในการดำเนินการ " เนื่องจากการจัดการผลิตภัณฑ์สามารถเป็นศูนย์กลางสำหรับการสูญเสียความจำระยะสั้นนี่เป็นประโยชน์สำหรับทุกคน

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

สิ่งเดียวที่คุณขาดไปคือการประมาณเวลา กำหนดเวลาในแต่ละงานและแสดงให้เห็นว่าสิ่งเหล่านี้รวมกันเป็นอย่างไรกับการประมาณการที่คุณให้ไว้ ไม่อนุญาตให้การประมาณการใด ๆ มีขนาดใหญ่กว่า 4 ชั่วโมง หากคุณมีงานใด ๆ ที่คุณพูดว่า "a day" หรือ "10 hours" ให้แยกงานย่อย ๆ ออกเป็นงานย่อย ๆ

2h make some changes to Database
2h add front end HTML
   write server side code
     4h input validation
     4h database inserts
2h add validation
2h add client side javascript
   use unit tests
     2h client-side tests
     3h server-side tests
2h make sure SEO is setup is working
2h implement email confirmation
2h optimize DB changes for speed
2h refactor and optimize the code for speed

ตอนนี้คุณได้รับการเรียกเก็บเงินแยกรายการ ทั้งหมดบอกว่ารวมถึงงาน 27 ชั่วโมง

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

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

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

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

ถามพวกเขา:

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

ฉันบอกให้คุณอธิบายให้พวกเขาฟังว่าซอฟต์แวร์ของพวกเขานั้นเหมือนเครื่อง 100 ตันที่มี 10,000 ส่วนต่าง ๆ ส่วนใหญ่เชื่อมต่อกันด้วยวิธีที่ซับซ้อน การติดตั้งชิ้นส่วนขนาด 1 นิ้วลงในเครื่องนี้ต้องใช้วิศวกรรมเพื่อที่จะไม่ทำให้เครื่องแตก แต่คำตอบที่ดีกว่าคือ:

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

เช่นเดียวกับที่ใช้ในศตวรรษที่ 20 เพื่อรวบรวมสถาปัตยกรรมที่ดีและวิศวกรรมสำหรับการสร้างอาคารขนาดใหญ่เครื่องมือสำหรับวิศวกรรมซอฟต์แวร์เพิ่งมาไม่ถึงกระแสหลัก พวกเขากำลังพัฒนา: ต้องใช้ความคิดใหม่ ดูรหัสเซนที่ wiki.hackerspaces.org/Hacking_with_the_Tao