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

เหตุผลที่คุณต้องการผู้จัดการโครงการ

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

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

• โครงการมีความกดดันของเวลา
• งบประมาณน้อยกว่าที่ฉันต้องการ
• ค่าธรรมเนียมของฉันแพงกว่าที่ลูกค้าต้องการ
• ฉันฟังไม่สมบูรณ์เท่าที่ลูกค้าต้องการ
• ลูกค้าไม่ได้อธิบายสิ่งต่าง ๆ อย่างสมบูรณ์แบบเท่าที่ฉันต้องการ

เห็นได้ชัดว่าเราต้องการคนเลี้ยง ต้องมีคนเข้ามาตั้งกฎของเกมให้ทุกคนซื่อสัตย์และอย่าลืมบางสิ่งที่สำคัญ มีคนคอยอำนวยความสะดวกในการสื่อสารระหว่างทุกฝ่าย

คนนี้พระเอกคนนี้เป็น Project Manager

ทำไมผู้จัดการผลิตภัณฑ์จึงอยู่ในกล่อง? เขาเป็นแมว แมวรักกล่อง

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

สาเหตุที่โปรแกรมเมอร์ไม่ใช่ผู้จัดการโครงการที่ดี

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

คอร์ปอเรชั่น กับ ค คอร์ปอเรชั่น คืออะไร

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

สำหรับผู้เริ่มต้นคุณจ่ายเงินให้เราเพื่อเขียนโค้ด

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

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

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

เมื่อเราหลุดพ้นจากอาการมึนงงในการเขียนโปรแกรมในการตัดสินใจโค้ดจะหยุดเขียน

สาเหตุที่ลูกค้าไม่ใช่ผู้จัดการโครงการที่ดี

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

อย่างไรก็ตามคุณยังมีอีกหลายอย่างที่ต้องทำ

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

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

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

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

รายการเทคนิคที่ไม่สมบูรณ์สำหรับการจัดการโครงการทางเทคนิค

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

เหตุการณ์สำคัญ

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

การประมาณเวลา

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

การจัดทำงบประมาณทุนเป็นกระบวนการของการวิเคราะห์:

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

เรื่องราวของผู้ใช้

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

สำหรับข้อมูลสั้น ๆ เกี่ยวกับเรื่องราวของผู้ใช้ฉันพบบทช่วยสอนเหล่านี้จาก ซอฟต์แวร์ Mountain Goat ย โรมันพิชเลอร์ มีคุณภาพสูงและรัดกุม หากต้องการข้อมูลเพิ่มเติมเกี่ยวกับปรัชญาทั้งหมดของ 'การจัดการโครงการแบบ Agile' ลองดูบล็อกโพสต์ของ ApeeScape ความรู้เบื้องต้นเกี่ยวกับการจัดการโครงการแบบ Agile โดย Paul Barnes

องค์ประกอบ (จำลอง)

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

นักออกแบบส่วนใหญ่จัดหา comps หรือที่เรียกว่า 'comps' ใน Adobe Photoshop, Adobe Illustrator หรือ Sketch หากคุณกำลังทำด้วยตัวเองคุณสามารถใช้หนึ่งในเครื่องมือออนไลน์มากมายเช่น Balsamiq หรือ InVision . คอมพ์ไม่จำเป็นต้องมีสีและสไตล์เดียวกันกับผลิตภัณฑ์สำเร็จรูป (เนื่องจากสามารถเปลี่ยนแปลงได้ง่ายในภายหลัง) แต่โปรดใช้เวลาเพิ่มเติมเพื่อให้แน่ใจว่าองค์ประกอบ UI ทั้งหมดมีอยู่และได้รับการยืนยัน

การประชุมแบบสแตนด์อโลน

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

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

ระบบจำหน่ายตั๋ว

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

• สร้างงาน
• กำหนดลำดับความสำคัญและวันที่จัดส่ง
• เชื่อมโยงงานและงานย่อย
• กำหนดความละเอียดที่แตกต่างกันเช่น 'เสร็จสมบูรณ์' หรือ 'การทดสอบล้มเหลว'
• แสดงงานทั้งหมดที่มอบหมายให้กับผู้ใช้บางราย

เมื่อผู้จัดการโครงการแสดงตั๋วลำดับความสำคัญสูงสุดสีแดงสด 40 ใบที่ครบกำหนดในวันเดียวกันคุณจะเข้าใจคุณค่าของวิสัยทัศน์โครงการนี้อย่างแท้จริง

คุณไม่จำเป็นต้องใช้กระดาษโน้ตเพื่อติดตามจุดบกพร่อง

การควบคุมเวอร์ชัน

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

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

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

ผู้สร้างภาษาซี

การควบคุมเวอร์ชันเป็นสิ่งที่ดีที่สุด

การพัฒนาตามการทดสอบ

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

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

ใกล้

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