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

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

ฉันควรทำอย่างไรในกรณีนี้? ฉันควรจะใช้ความพยายามพิเศษหรือควรใช้ง่ายไหม? และฉันควรพูดกับผู้จัดการอย่างไร

เหตุผลที่โครงการนี้มุ่งหน้าไปสู่ความล้มเหลว:

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

ในความเป็นจริงเราเพิ่งได้รับโครงการนี้ (พร้อมกับระเบียบ) ประมาณ 1-2 เดือนที่ผ่านมาจากทีมพัฒนาอื่นภายใต้ผู้จัดการเดียวกันซึ่งทำงานในโครงการนี้มาสองสามเดือน

สื่อสารข้อกังวลของคุณด้วยวิธีที่รัดกุมและไม่หวือหวาเท่าที่จะเป็นไปได้ สรุปความเสี่ยง แต่อย่ากำหนดข้อสรุปของคุณ

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

เมื่อทำอย่างนั้นแล้วให้ทำงานต่อในโครงการโดยสุจริต

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

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

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

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

ฉันจะแนะนำให้คุณใช้เวลาอ่านหนังสือ 2 เล่มเล็กน้อย

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

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

3 กลยุทธ์ที่ง่ายและเหยียดหยามเพื่อรักษาอาชีพ / สติปัญญา

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

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

3. วางแผนสำหรับทางออกฉุกเฉินบน T + 1: ให้ทางเลือกแก่คุณและทำพื้นฐานสำหรับการถ่ายโอนภายในหรือภายนอกที่อาจเกิดขึ้นในขณะนี้ พูดคุยกับผู้คน; ไม่มีเหตุผลที่จะต้องรอให้คนอื่นตัดสินใจว่าจะทำอย่างไรกับคุณเมื่อเงินทุนของโครงการถูกตัดหรือถูกล้นใน 'การแตกตื่น' ที่หลีกเลี่ยงไม่ได้ของผู้คนที่อพยพออกไปในอีกสองสามเดือน

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

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

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

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

บ่อยครั้งความโกลาหลและความระส่ำระสายเดียวกันที่มาพร้อมกับโครงการที่ล้มเหลวทำให้คุณมีโอกาสส่องแสง

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

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

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

1) มุ่งเน้นไปที่ความเป็นเลิศส่วนบุคคล - มุ่งมั่นที่จะเขียนรหัสที่ดีกว่าเคยได้มาตรฐานที่สูงขึ้นของคุณภาพและฟังก์ชั่น

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

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

ในสถานการณ์เช่นนี้เนื่องจากขั้นต่ำสุดของบันไดมีเพียงสิ่งเดียวที่คุณสามารถทำได้เพื่อช่วยโครงการ

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

นอกจากนั้นคุณต้องดูแลหมายเลข 1 ด้วย

• บันทึกเอกสารทุกอย่าง
• เก็บอีเมลทั้งหมดการสนทนา IM
• ลองหาทางออกจากโครงการถ้าเป็นไปได้

ความล้มเหลวของโครงการอาจเป็นพิษต่อจิตวิญญาณทำให้เกิดภาวะซึมเศร้าทำงานมากกว่าและเคารพตนเองต่ำ

ทุกอย่างเกี่ยวข้องกับมุมมอง

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

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

ในขณะที่คุณกำลังทำงานบางอย่างที่คุณชอบ มีองค์ประกอบอย่างชัดเจนในโครงการปัจจุบันที่คุณไม่ชอบ

คุณต้องระบุว่าองค์ประกอบปัญหาเหล่านั้นคืออะไรและจัดการปัญหาเหล่านั้น

• ความดันกำหนดเวลา
• ควบคุมคุณภาพ
• ความเป็นมืออาชีพ
• คำแนะนำโดยผู้บริหาร

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

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

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

คุณจะมีความสุขมากขึ้น

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

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

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

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

1) ทำงานของคุณ ไม่ต้องกังวลมากเกี่ยวกับโครงการโดยรวมตราบใดที่คุณทำหน้าที่ของคุณให้เสร็จ

2) CYA หากโครงการล้มเหลวและคุณสงสัยว่าผู้จัดการจะเริ่มตำหนิทุกคนยกเว้นตัวเขาเองตรวจสอบให้แน่ใจว่าคุณมีหลักฐานเพียงพอที่คุณทำทุกอย่างตามที่คุณต้องการ (ดูรายการที่ 1)

3) ให้คำแนะนำที่สุภาพเล็กน้อยเพื่อการปรับปรุง อย่าส่งเสียงเตือน, อย่ามอมแมม, หม่นหมองแค่สุภาพและบอบบาง

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

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

นอกจากนี้:

4) การปรับโครงสร้างตามโอกาสคือเพื่อนของคุณ

1. ทำงานหนัก; แต่ไม่ใช่ค่าใช้จ่ายของครอบครัวหรือสุขภาพของคุณ
2. เก็บบันทึกการตัดสินใจออกแบบที่สำคัญทั้งหมด โดยเฉพาะอย่างยิ่งที่เกี่ยวข้องกับการทำงานของคุณ
3. รักษาการเชื่อมต่อเครือข่ายและเปิดทางเลือกของคุณหากสถานการณ์นั้นยากเกินไปหรือคุณตกเป็นเหยื่อของการเลิกจ้างจำนวนมาก
4. พยายามอย่าคิดว่าโครงการของคุณเป็น "โครงการที่ล้มเหลว" ทุกคนชอบคนที่คิดบวกและต่อสู้อย่างหนักเมื่อเผชิญกับความทุกข์ยาก ดังนั้นให้นานที่สุดเท่าที่เป็นไปได้พยายามที่จะว่าคน บวกแนวโน้มกรวดและความมุ่งมั่นอยู่เสมอที่ดีสำหรับการทำงาน
5. หากคุณคาดการณ์โครงการที่ล้มเหลวคุณคาดว่าจะมีการประชุมภายหลังประชุมชันสูตร ในการประชุมชันสูตรทุกคนจะถูกจัดขึ้นในบัญชี เตรียมพร้อมที่จะปกป้องรหัสของคุณทั้งหมด [หมายเหตุ: ตามกฎทั่วไปคุณควรเขียนโค้ดที่สะอาดเสมอเพื่อให้ง่ายต่อการป้องกันในภายหลัง] หากคุณมีอีเมลหรือเอกสารการออกแบบที่เป็นแรงบันดาลใจในการตัดสินใจของคุณ
6. ในการประชุมชันสูตรลองพยายามคิดบวก และแสดงเฉพาะเอกสารอีเมลและเอกสารการออกแบบของคุณหากมีการตัดสินการตัดสินใจความพยายามหรือฝีมือของคุณ

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

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

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

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

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

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

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

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

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

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

นี่คือข้อสังเกตบางอย่างที่ฉันจำได้

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

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

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

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

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

การพิพากษาไม่ได้มาจากความสำเร็จ แต่มาจากความล้มเหลว บริษัท ส่วนใหญ่ต้องการจ้างคนที่เคยล้มเหลวมาก่อนโดย ...

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

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

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

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

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

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

มีรีมของคำแนะนำที่ปฏิบัติได้ (และอื่น ๆ ) ที่นี่แล้ว แต่สำหรับฉันกุญแจสู่ความลึกลับนี้คือสองรายการต่อไปนี้ (ของฉันที่เน้น):

กำหนดเส้นตายใน1.5 เดือน

และ

... จริง ๆ แล้วเราเพิ่งได้รับโครงการนี้ (พร้อมกับระเบียบ) ประมาณ1-2 เดือนที่ผ่านมาจากทีมพัฒนาอื่นภายใต้ผู้จัดการคนเดียวกัน ...

ดังนั้น....

ยินดีต้อนรับสู่Team Patsy The Avengers

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

การแก้ไข: ทีมก่อนหน้าถูกแทนที่, ~ 3 เดือนก่อนกำหนด

-> ค้นหาวิธีที่ทีม dev ก่อนหน้านี้จัดการเพื่อหลบหนีและทำเช่นนั้น <-

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

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

รุนแรง? ใช่. แต่ในขณะที่การวางแผนไม่ดี (อย่างน้อย) โดยทีมงานล่วงหน้า / ผู้จัดการไม่ได้เป็นความผิดของคุณ 'ความล้มเหลวในการส่งมอบ' จะเป็น

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

ทีม 5 คนและ 1.5 เดือนที่จะไป ทีมใหม่ได้มีเพียงโครงการสำหรับ 1-2 เดือนเพื่อให้ทีมใหม่ไม่ได้แม้กระทั่งในช่วงโค้งการเรียนรู้ การคาดเดาคร่าวๆกับขนาดของโครงการนี้ดูเหมือนว่าฉันจะไม่มีทางที่ทีมใหม่จะได้ผ่านช่วงการเรียนรู้แม้ว่าโครงการจะไม่มีปัญหาเลย

ดังนั้นฉัน (ยัง) คิดว่าคุณได้ถูกทำให้อาย

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

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

แต่โปรดจำไว้เสมอ : อย่ารับคำแนะนำอาชีพจากคนแปลกหน้าบนอินเทอร์เน็ต

นี่เป็นโอกาสที่เหลือเชื่อสำหรับคุณ! มาดูความคิดเห็นของผู้ประกอบการกัน

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

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

รับรู้โอกาสของคุณที่นี่เพื่อพัฒนาทักษะของคุณ

[1] การยกเลิกโครงการจะสำเร็จได้จริง ความล้มเหลวจะใช้จ่ายเงินดีหลังจากเลว

คุณทำอะไรได้บ้าง

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

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

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

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

สิ่งที่คุณทำไม่ได้ แต่ฝ่ายบริหารของคุณน่าจะทำ

• พวกเขาไม่ควรเพิ่มคนอื่นในโครงการ "เพื่อช่วย" ให้เห็นสิ่งนี้

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

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

• อัปเดตการจัดการที่สูงขึ้นของพวกเขาเองมันจะช่วยให้พวกเขาทำงานได้ดีขึ้น ...

สิ่งที่คุณไม่ควรทำ

• ขอให้เพิ่มคนอื่นในโครงการ (ดูสิ่งนี้ )

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

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

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

• โทษผู้คน (หรือตัวคุณเอง) มันไม่ได้ช่วยอะไรเลย

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

นั่นเป็นเพียงสองเซ็นต์ของฉัน YMMV

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

• คุณภาพของรหัสคงที่สามารถวัดปริมาณได้ด้วยเครื่องมือการวิเคราะห์เชิงสถิต คุณสามารถทำให้มันเรียบง่ายหรือละเอียดตามที่เห็นสมควร ตัวชี้วัดที่ฉันแนะนำให้คุณเริ่มต้นด้วย:
  • ความซับซ้อนของวัฏจักร
  • ขนาดของรหัสของคุณ (เช่น Nr ของบรรทัดต่อฟังก์ชัน / คลาสจำนวนไฟล์จำนวนตาราง ... )
  • ระบุโมดูลที่มีขนาดใหญ่เกินไป
  • การทำสำเนา
  • ยึดมั่นในสไตล์รหัส
• อัตราข้อบกพร่อง
  • ต่อ KLOC โดยโมดูลและหรือระบบย่อย (ระบุส่วนที่เป็นปัญหาของระบบของคุณ)
  • คุณสามารถคำนวณจำนวนสมาชิกต่อทีมได้ แต่ฉันคิดว่าคุณควรรักษาไว้เพื่อตัวคุณเอง
  • แก้ไขแล้วพบ
  • เวลาที่ใช้ในการแก้ข้อบกพร่อง (บางทีถ้านี่คือการทำกราฟของสิ่งนี้)
  • อาจประมาณว่าต้องใช้เวลาเท่าไรถ้าสิ่งนี้ยังคงเป็นไปตามอัตราปัจจุบัน
• การวางแผน
  • ประมาณเวลาที่ใช้สำหรับฟีเจอร์ที่สร้างขึ้น คำนึงถึงความซับซ้อนของคุณสมบัติ สิ่งนี้ไม่จำเป็นต้องแม่นยำมากนัก สิ่งที่คุณต้องการถ่ายทอดด้วยนี้จะเป็นไปตามเส้นของ "คุณสมบัติ A, B และ C มีความซับซ้อนเหมือนกันของ D, E และ F ด้วยคุณสมบัติ ABC ใช้ 170% ถ้าเวลาที่วางแผนไว้ถ้าไม่มีอะไรเปลี่ยนแปลงเราคาดหวังเหมือนกัน เวลาที่ต้องการสำหรับ DEF "หรือตามแนว" คุณลักษณะเฉลี่ยใช้เวลาในการคำนวณนานกว่า X% เราไม่มีเหตุผลที่จะสันนิษฐานว่าส่วนที่เหลือของการทำงานนั้นง่ายต่อการสร้างดังนั้นเราควรชดเชยสิ่งนี้ในการวางแผนในอนาคต มันไม่มีประโยชน์อะไรที่จะมีการวางแผนถ้ามันไม่สมจริง
  • พยายามที่จะมีตารางเวลาการเปิดตัวรายเดือนหรือสั้นกว่าโดยเฉพาะอย่างยิ่ง ถ้าภายในเท่านั้น สิ่งนี้สามารถช่วยคุณเพิ่มเติมในการประมาณเวลาที่คุณต้องการสำหรับโครงการ สิ่งนี้อาจช่วยให้คุณประหยัดจากภาระผูกพันที่ไม่สมจริง (ถ้าคุณไม่ผูกมัดกับงานใหม่ก่อนที่จะมีการเผยแพร่) ทำการวางแผนสำหรับแต่ละ cylce และให้แน่ใจว่าคุณสมบัติใหม่จะเข้าสู่รอบถัดไปเท่านั้น (เช่นไม่สามารถเพิ่มลงในรอบปัจจุบัน)
• การครอบคลุมการทดสอบ: อธิบายค่าความครอบคลุมการทดสอบ "ปกติ" และแสดงว่าการครอบคลุมปัจจุบันของคุณเป็นอย่างไร
• เอกสาร: เอกสาร% เท่าไหร่จริง? ดีอย่างไร?
• modularity:
  • ตามระดับ (การมีเพศสัมพันธ์และการทำงานร่วมกัน)
  • แพ็คเกจตาม
  • ระบบย่อยที่ใช้ (มีเส้นทางการสื่อสารกี่เส้นทาง?)

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

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

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

ฉันสามารถย้ำสิ่งที่คนอื่นพูดเท่านั้น แต่ฉันเน้นย้ำอย่างเด่นชัด: พยายามทำงานให้ดีที่สุดเสมอ สำหรับทั้ง CYA และเหตุผลทางเทคนิค

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

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

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

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