วิธีจัดการกับสถานการณ์“ ซอฟต์แวร์สิ้นสุดอายุการใช้งาน”?


14

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

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

สิ่งที่ฉันคิดได้:

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

ความคิดอื่น ๆ ?

  • สมมติว่าไม่มี "การหลบเลี่ยง" ที่เกี่ยวข้อง (ไม่มี DRM หรือ DMCA) ไม่มีการกู้คืนข้อมูลหรือวิศวกรรมย้อนกลับทางกฎหมาย / ยอมรับได้หรือไม่?

หมายเหตุการแก้ไข:

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


เส้นเวลานี่คืออะไร? คุณเป็นลูกค้าหรือสร้างผลิตภัณฑ์ที่อยู่ด้านบนของผู้ขายดังกล่าวหรือไม่?

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

2
ทำให้สงสัยว่าทำไมข้อมูลไม่ได้ถูกจัดเก็บในรูปแบบเปิดบางประเภทเพื่อเริ่มต้นด้วย ... ถ้ามันถูกเก็บไว้เป็นข้อความธรรมดาใน db คุณสามารถคัดลอกได้ หากเก็บไว้ในข้อความ xml / plain คุณสามารถคัดลอกได้ หากเป็นไบนารี่ / เข้ารหัสคุณต้องถอดรหัส มันเป็นไปได้ทั้งหมด
งาน

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

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

คำตอบ:


2

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

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


2

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


2
ฝึกงาน: เทียบเท่าท้องถิ่นของการจ้าง
Earlz

Internsourcing!
พอลนาธาน

0

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

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

One note: หากระบบเป็นสิ่งที่เปิดเผยต่อสาธารณะนี่เป็นแนวทางที่ไม่ดีเพราะคุณไม่มีวิธีรับการปรับปรุงความปลอดภัย

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.