ความสำคัญของการรู้หน้าที่ก่อนการเข้ารหัสคืออะไร?

ฉันทำงานให้กับ บริษัท พัฒนาซอฟต์แวร์ที่มีการพัฒนางานให้กับเรา ทีมฝั่งสนับสนุนการสนับสนุนและพูดคุยกับลูกค้าโดยตรง เราไม่เคยพูดคุยกับลูกค้าโดยตรงเราเพียงแค่พูดคุยกับผู้คนจากทีมฝั่งที่พูดคุยกับลูกค้าโดยตรง

เมื่อความต้องการมาทีมฝั่งพูดคุยกับลูกค้าและทำเอกสารความต้องการและแจ้งให้เราทราบ เราทำเอกสารการออกแบบหลังจากศึกษาข้อกำหนด (เราทำตามโมเดลน้ำตกดั้งเดิม)

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

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

คำถามของฉันคือคุณจะพัฒนาอย่างไรหากคุณไม่รู้จักการทำงานของแอพอย่างสมบูรณ์

UPDATE

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

เวอร์ชั่นสั้น:

รู้ว่าต้องทำอย่างไร≠รู้จักลูกค้าของคุณ

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

รุ่นยาว:

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

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

บนมืออื่น ๆ , ผลิตภัณฑ์ซอฟต์แวร์ที่ทำด้วยความเข้าใจของโดเมนที่ระบุไม่มีจะเป็นที่ที่ดีที่สุด, ดี, บิตใช้ไม่ได้

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

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

2. ผู้ที่มีความเชี่ยวชาญในการจัดการโครงการ

3. ผู้ที่มีความเชี่ยวชาญในโดเมนของลูกค้าที่มีความเข้าใจอย่างถ่องแท้เกี่ยวกับโดเมนนี้และความต้องการที่แม่นยำของลูกค้า แน่นอนว่านี่อาจเป็นลูกค้าของตัวเอง

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

สำหรับกรณีเฉพาะของคุณคุณอธิบายสาเหตุของปัญหาด้วยตนเอง:

เราต่อสู้กับเอกสารการออกแบบเนื่องจากข้อกำหนดจะไม่ชัดเจน

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

เมื่อรู้ว่าคุณต้องทำสิ่งที่แตกต่าง:

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

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

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

คุณกำลังใช้วิธีการพัฒนาที่ไม่ถูกต้องสำหรับปัญหาที่คุณเผชิญอยู่

โดยการใช้ Waterfall คุณยอมรับว่า:

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

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

การเปรียบเทียบที่ดีของWaterfall vs Agileถูกเขียนขึ้นมาได้สักพักลองใช้เครื่องหมายคำพูดสองสามคำจากนั้นเพื่อเน้นปัญหาของคุณ:

ไม่มีเครื่องหมาย:

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

ผูก ...

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

... และไม่สามารถย้ายได้

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

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

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

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

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

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

นี่คือบางสิ่งที่จะช่วยแก้ปัญหา:

1. ปรับปรุงการสื่อสารระหว่างสองทีม ขอให้อีกทีมบีบอัดความต้องการเป็น 3 คำจากนั้นโปรแกรมเมอร์จะใช้คำเหล่านั้นให้ถูกต้อง คำเพียงแค่ต้องถูกต้อง ไม่มีสิ่งใดที่จะดำเนินการได้หากปราศจากคำพูดเหล่านั้น ทุกคำให้รหัส 2,000 บรรทัด การดำเนินการเริ่มต้นเมื่อรู้คำใหม่
2. ถ้าเป็นคำไม่ได้ทันทีที่ชัดเจนในการเขียนโปรแกรมของพวกเขาได้รับอนุญาตให้ถามคำถามเดียว คำถามจะต้องถูกต้องอีกครั้ง มันต้องการคำตอบทันที - คำตอบนั้นไม่สามารถรอรถไปกลับจากอีกด้านหนึ่งของโลกได้ แต่ต้องรู้ล่วงหน้า การดำเนินการเริ่มต้นทันทีหลังจากได้รับคำตอบและคำตอบจะถูกตามด้วยจดหมาย
3. หากในระหว่างการดำเนินการมีข้อกำหนดที่ไม่ชัดเจนหรือคลุมเครือวิธีการแก้ไขพวกเขาคือการดูที่ 3 คำแรก (ปัจจุบัน) หากยังคงไม่มีความชัดเจนแล้วโปรแกรมเมอร์ทำให้ดีที่สุดคาดเดาไปได้ ความล่าช้าใด ๆ ในกระบวนการนี้เป็นสิ่งต้องห้ามอย่างแน่นอน; และการขอความช่วยเหลือจากทีมอื่นไม่ใช่วิธีที่ถูกต้องในการแก้ปัญหา - พวกเขามีโอกาสเปลี่ยนข้อกำหนดโดยการตัดสินใจ 3 คำที่ถูกต้อง
4. หากหลังจากทั้งหมดนี้ความต้องการยังไม่ชัดเจนหรือเป็นไปไม่ได้ที่จะใช้วิธีที่ถูกต้องในการจัดการคือการปฏิเสธ 3 คำที่ทำให้เกิดปัญหาและย้ายไปยังคำถัดไป คำที่ถูกปฏิเสธใด ๆ จะถูกรวบรวมและส่งต่อไปยังทีมอื่นและพวกเขาจะต้องแก้ไขคำศัพท์ก่อนที่จะป้อนคำเหล่านั้นเข้าสู่ระบบอีกครั้ง การปฏิเสธคำพูดจะเลื่อนกำหนดเวลาและการดำเนินการจะต้องมีการวางแผนอีกครั้ง
5. ทีมจะต้องได้รับการประเมินตามจำนวนคำที่พวกเขาปฏิเสธ หลังจากความต้องการได้รับการดำเนินการก็จะคงที่ตลอดไปและไม่สามารถเปลี่ยนแปลงได้ ความพยายามใด ๆ ที่จะเปลี่ยนคุณสมบัติที่ใช้งานไปแล้วจะถูกปฏิเสธ
6. ปัญหาที่แท้จริงของคำถามคือสมมติว่าข้อมูลเพิ่มเติมทำให้การใช้งานง่ายขึ้น นี่ไม่เป็นความจริง. อิสระมากขึ้นในการเขียนโปรแกรมของคุณมีที่ง่ายขึ้นการดำเนินการ การบีบอัดข้อกำหนดทำให้สามารถสื่อสารข้อมูลจำนวนมากได้โดยไม่ จำกัด จำนวนที่โปรแกรมเมอร์อนุญาตให้ทำมากเกินไป