จะทำอย่างไรเมื่อลูกค้ามีความคาดหวังที่ไม่สมจริง? [ปิด]

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

เมื่อฉันปรากฏตัวตามลำพังในไซต์ลูกค้านี้ฉันได้รับแจ้งว่าฉันต้องทำให้โครงการเสร็จภายในสองเดือน

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

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

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

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

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

ฉันทำงาน 11-12 ชั่วโมงทุกวันและเดินทาง 3-4 ชั่วโมงและตอนนี้พวกเขาคาดหวังว่าฉันจะมาในวันเสาร์ด้วย

ฉันต้องทำทุกอย่างที่นี่: รับข้อกำหนดออกแบบรหัสและทดสอบ

กรุณาแนะนำฉันว่าจะทำอย่างไรในกรณีเช่นนี้?

_{รายละเอียดเพิ่มเติม: เรามีรายการสิ่งที่ส่งมอบ แต่จากนั้นพวกเขาก็เพิ่มสิ่งต่าง ๆ ลงไปอีกเล็กน้อยโดยบอกว่าสิ่งเหล่านี้ก็มีความสำคัญเช่นกัน พวกเขายังเปลี่ยนการส่งมอบไม่กี่ พวกเขาไม่ได้มีเซิร์ฟเวอร์ UAT ของพวกเขาพวกเขาทดสอบบนเครื่องพัฒนาของฉันเองผ่านที่อยู่ IP}

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

ผู้จัดการของคุณเนื่องจากพวกเขาวางแผนที่จะพบกับเขาจำเป็นต้องได้รับข้อกำหนดเฉพาะจากลูกค้า - โครงการควรทำ A, B, C, D และ E และหลังจากนั้นก็เสร็จสมบูรณ์ ลายเซ็นของลูกค้าจะต้องอยู่ในเอกสารที่ตกลงกับรายการนั้น คุณควรจะมีสิ่งนั้นตั้งแต่เริ่มต้น

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

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

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

หากไม่สามารถกำหนดตารางเวลาที่ต้องการเขียนได้ หากมีการเปลี่ยนแปลงใด ๆ เกิดขึ้นเขียนถึงพวกเขารวมถึงผลที่ตามมา และอื่น ๆ

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

จากสิ่งที่คุณอธิบายปรากฏว่าคุณเข้าร่วมในโครงการ Death March สุดคลาสสิค:

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

ปรากฏการณ์ที่เป็นที่รู้จักกันดีและมีจำนวนมากของวรรณกรรมเกี่ยวกับวิธีการดำเนินการ - รวมทั้งหลักสูตรเชื้อเอ็ดเวิร์ด Yourdon หนังสือตายมีนาคม: คู่มือสำหรับนักพัฒนาซอฟแวร์ที่สมบูรณ์แบบที่จะรอดตาย 'Mission Impossible' โครงการ

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

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

ด้วยวิธีนี้จะทำให้พวกเขารู้ว่าฉันรู้ว่าเกิดอะไรขึ้นและอาจช่วยให้พวกเขาแนะนำฉันในแง่ของกรอบความคิดนี้เช่น"ดูสถานะปัจจุบันของเราใกล้เคียงกับที่อธิบายไว้ในบทXที่ Yourdon ตรวจสอบมัน ออกไปพร้อมกับบทที่เกี่ยวข้องอย่างใกล้ชิดYฯลฯ ... "

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

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

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

มันเป็นความร้ายแรง issue in project managementดูเหมือนว่าคุณProject Managerควรจะทำงานในรายการที่ส่งมอบและจัดลำดับความสำคัญกับลูกค้า

ที่สำคัญที่สุด PM ของคุณshould discussและเห็นด้วยกับลูกค้ากรอบเวลา (รวมถึงการออกแบบและการวิเคราะห์ปัญหา / การแก้ปัญหา) ในการประมาณของคุณ

การมีclear estimation of your work loadและส่งมอบสิ่งของในโครงการจะช่วยลดความเครียดและเพิ่มความอุ่นใจและความมั่นใจในการทำงานของคุณ

ลองใช้วิธี Agile โดยส่งรายการของคุณเป็น sprint (2-3 สัปดาห์) และสร้าง UAT (ทดสอบการยอมรับของผู้ใช้) กับลูกค้า จำไว้ว่าให้วางแผนการวิ่งของคุณทุกครั้งก่อนเริ่มการวิ่ง

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

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

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

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

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

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

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

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

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

จากWiki :

แผนภูมิ Gantt แสดงวันที่เริ่มต้นและสิ้นสุดขององค์ประกอบเทอร์มินัลและองค์ประกอบสรุปของโครงการ