7 ปัจจัยสำหรับความล้มเหลวในการรับประกัน

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

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

ด้านล่างนี้คือ 7 ปัจจัยทั่วไปที่รับประกันความล้มเหลว

ปัจจัยที่ 1: ไม่สนใจปัจจัยมนุษย์

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

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

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

ปัจจัยที่ 2: คิดใหญ่เกินไปหรือทำให้เล็กเกินไป

บางบริษัทรับช่วงต่อโครงการ พวกเขาประเมินความซับซ้อน ความเสี่ยง และบุคลากรจำนวนมหาศาลและความพยายามด้านวัสดุต่ำเกินไป องค์กรของฉันสามารถจัดการโครงการที่มีพนักงาน 100 คนโดยไม่คำนึงถึงค่าใช้จ่ายได้หรือไม่ เรามีงานเพียงพอ, ห้องประชุม, ความจุของเครือข่าย, เซิร์ฟเวอร์สำหรับการพัฒนา ฯลฯ หรือไม่?

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

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

ปัจจัยที่ 3: พึ่งพาการประมาณการและการวางแผน 100%

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

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

ปัจจัยที่ 4: สามเหลี่ยม PM ที่มีมนต์ขลังถูกละเลยอย่างต่อเนื่อง

เรียนวิทยาการคอมพิวเตอร์ ภาคเรียนที่ 1 การจัดการโครงการ บรรยายครั้งแรก “สามเหลี่ยม PM มหัศจรรย์” . บุคคลที่สนใจในงานด้านการจัดการจะได้รับการแนะนำให้รู้จักกับกฎของรูปสามเหลี่ยมนี้ตั้งแต่เนิ่นๆ สิ่งเหล่านี้บอกว่าการเปลี่ยนแปลงหนึ่งในสามพารามิเตอร์ย่อมนำไปสู่ผลที่ตามมาของพารามิเตอร์อื่นอย่างน้อยหนึ่งตัว

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

ปัจจัยที่ 5: เอกสารทุกอย่าง

ฟรีหลังจาก Franz Beckenbauer: "เราเรียกมันว่าคลาสสิค!" แม้ว่าบริษัทจำนวนมากขึ้นเรื่อย ๆ จะอาศัยขั้นตอนที่คล่องตัว (ส่วนใหญ่เป็นการต่อสู้) แต่ก็ยังคงพบองค์กรและโครงการต่าง ๆ ซึ่งให้ความสำคัญกับเอกสารมากมายมากกว่าซอฟต์แวร์ที่จะสร้างขึ้น นี่เป็นความเสี่ยงสูงโดยเฉพาะในโครงการขนาดใหญ่ บ่อยครั้งที่การตามล่าจากที่ปรึกษาและผู้เชี่ยวชาญของแผนกในหน้าเว็บหลายพันหน้ามักใช้เวลาหลายเดือนหรือหลายปี ซึ่งจะมีการแปลโดยทีมอื่นใน SW ในภายหลัง

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

ปัจจัยที่ 6: ไม่มีการจัดโครงการที่สมดุล

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

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

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

ปัจจัยที่ 7: อุ่นกบอย่างช้าๆ

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

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

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

จึงจะเป็นไปได้

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

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