คนที่ไม่ใช่ด้านเทคนิคสามารถเรียนรู้การเขียนข้อมูลจำเพาะสำหรับโครงการขนาดเล็กได้อย่างไร

คนที่ไม่ใช่ด้านเทคนิคสามารถเรียนรู้การเขียนรายละเอียดสำหรับโครงการขนาดเล็กได้อย่างไร

เพื่อนของฉันกำลังพยายามที่จะ outsource การพัฒนาบางอย่างในโครงการสถิติ

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

อย่างไรก็ตามเพื่อนของฉันเป็นคนที่ไม่ใช่ด้านเทคนิค เขาเป็นคนยากจนที่เขียนรายละเอียดทางเทคนิค

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

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

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

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

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

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

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

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

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

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

เมื่อฉันต้องการรายละเอียดจากลูกค้าที่ไม่ใช้เทคนิคฉันมักจะขอให้พวกเขาเขียนในภาษาธรรมดาว่าพวกเขาต้องการทำอะไร เช่นเดียวกับใน "แอพควรทำ A ถึง B เมื่อฉันกด C แต่ถ้าเป็น D" เท่านั้น โบนัสพิเศษสำหรับ "เพราะ D หมายความว่า ... "

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

กล่าวอีกนัยหนึ่งอธิบายความคิดไม่ใช่การนำไปปฏิบัติ

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

หากไม่มีใครที่ใส่ใจและเข้าใจกระบวนการโครงการจะล้มเหลวไม่ว่าในกรณีใด ๆ

เขาสามารถลองใช้วิธีสตอรี่บอร์ด

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

เขาสามารถใช้เครื่องมือเช่นอาสนะเพื่อกำหนดขอบเขตของโครงการและฟังก์ชั่นการใช้งานและแม้แต่โต้ตอบกับผู้พัฒนาของเขา

การแปลเป็นความต้องการที่ชัดเจนนั้นมีการทำงานมากกว่าการใช้ข้อมูลจำเพาะที่เขียนอย่างชัดเจนถึง 10 เท่า

สาธุ นั่นยังอธิบายได้ว่าทำไม:

โคเดอร์ที่เขาจ้างไม่ได้คิดผ่านมุมและถามคำถามที่เหมาะสม

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

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

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

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

รหัสที่เขาจ้างไม่ได้ ... ถามคำถามที่เหมาะสม

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

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

• สำหรับการแนะนำจัดหาภาพรวมที่มีน้ำหนักเบาเกี่ยวกับวิธีการพัฒนาซ้ำและ Agile (บทความวิกิพีเดียจะทำ) เพื่อให้พวกเขารู้สึกว่าควรจะเป็นอย่างไร
   
• เพื่อช่วยให้พวกเขาเข้าใจถึงความล้มเหลวในอดีตให้จัดหาภาพรวมที่มีน้ำหนักเบาของ Waterfall / Big Design Up Front (ที่มีการวิจารณ์ - อีกครั้งบทความ Wikipedia จะต้องทำ) - โดยทั่วไปแล้วสิ่งเหล่านี้ทำได้ค่อนข้างดี ด้านหน้า

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

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

มันแตกต่าง - ดูเหมือนง่ายกว่าการระบุแอปพลิเคชันบนเว็บ มันเป็นกระบวนการทางตรรกะ นี่คือสิ่งที่ง่าย

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

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

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

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

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

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

กระบวนการทั้งหมดนี้เรียกว่า "การจับความต้องการ" และเป็นขั้นตอนแรกในกระบวนการวิศวกรรมซอฟต์แวร์ จริงๆแล้วการเขียนซอฟต์แวร์เป็นเพียงส่วนเล็ก ๆ ของวิศวกรรมซอฟต์แวร์ซึ่งความจริงที่น่าเศร้าที่นักพัฒนาซอฟต์แวร์จำนวนมากลืม อีกสิ่งหนึ่งที่พวกเขาดูเหมือนจะลืมคือมีความต้องการที่แข็งแกร่งในการสื่อสารกับลูกค้าและให้การสนทนากับพวกเขาในระหว่างกระบวนการทั้งหมดเพื่อให้แน่ใจว่าสิ่งที่อยู่ในการติดตาม

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

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

แต่ในระยะสั้นประเด็นหลักคือไม่ใช่งานของลูกค้าของคุณในการเรียนรู้ภาษาของคุณมันเป็นของคุณเพื่อเรียนรู้ภาษาของพวกเขา