คุณต้องการฮีโร่: ผู้จัดการโครงการ

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

ทำไมคุณถึงต้องการผู้จัดการโครงการตั้งแต่แรก

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

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

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

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

ใครบางคน ฮีโร่คนนี้ เป็นผู้จัดการโครงการ

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

ทำไมโปรแกรมเมอร์ถึงไม่เป็นผู้จัดการโครงการที่ดี

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

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

อย่างแรกเลย คุณต้องจ่ายเงินให้เราเป็นโค้ด

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

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

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

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

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

อย่างไรก็ตาม คุณยังมีหลายอย่างในจานของคุณ

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

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

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

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

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

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

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

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

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

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

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

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

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

สำหรับข้อมูลสั้นๆ เกี่ยวกับเรื่องราวของผู้ใช้ ฉันพบว่าบทช่วยสอนเหล่านี้ของ Mountain Goat Software และ Roman Pichler มีคุณภาพสูงและกระชับ สำหรับข้อมูลเพิ่มเติมเกี่ยวกับปรัชญาการจัดการโครงการแบบ Agile ทั้งหมด ให้ลองใช้บล็อกโพสต์ Toptal The Ultimate Introduction to Agile Project Management โดย Paul Barnes

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

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

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

การประชุมแบบยืนขึ้น

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

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

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

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

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

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

การควบคุมแหล่งที่มา

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

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

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

การควบคุมแหล่งที่มานั้นยิ่งใหญ่ที่สุด

การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ

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

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

สรุป

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