คำถามติดแท็ก customer-relations

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

2
ความฉลาดเป็นปริมาณเวกเตอร์
ฉันกำลังอ่านหนังสือที่ยอดเยี่ยมเล่มนี้ชื่อว่า"Coders at Work: Reflections on Craft of Programming"โดย Peter Seibelและฉันก็เป็นส่วนหนึ่งของการสนทนากับ Joshua Bloch และฉันก็พบคำตอบนี้ซึ่งเป็นจุดสำคัญสำหรับโปรแกรมเมอร์ ย่อหน้ามีบางอย่างเช่นนี้ มีปัญหานี้ซึ่งก็คือการเขียนโปรแกรมเป็นเรื่องของการทำบุญทางปัญญามากมายและบ่อยครั้งที่คนเหล่านี้เป็นคนที่ฉลาดที่สุดในองค์กร ดังนั้นพวกเขาคิดว่าพวกเขาควรได้รับอนุญาตให้ทำการตัดสินใจทั้งหมด แต่ความจริงที่ว่าพวกเขาเป็นคนที่ฉลาดที่สุดในองค์กรไม่ได้หมายความว่าพวกเขาควรทำการตัดสินใจทั้งหมดเพราะความฉลาดไม่ได้เป็นปริมาณสเกลาร์ มันคือปริมาณเวกเตอร์ ในประโยคสุดท้ายนี้ฉันไม่เข้าใจว่าเขาพยายามแบ่งปันอะไร มีคนอธิบายได้ในอีกสักครู่ว่าสิ่งที่เขาหมายถึงปริมาณเวกเตอร์อาจพยายามนำเสนอข้อมูลเชิงลึกเดียวกัน ยิ่งไปกว่านั้นฉันได้รับจุดที่เขาไม่ได้รับเกี่ยวกับการมีองค์กรที่ไม่ใช่คนเทคนิค (บางครั้ง clueless) สามารถเป็นผู้จัดการของคนทางเทคนิคด้วยเหตุผลบางอย่างที่พวกเขาสามารถใช้เวลามากขึ้นในการเขียนอีเมลที่ดีเพราะต่อไป คำสั่งต่อไปนี้ย่อหน้าข้างต้นคือ และถ้าคุณขาดความเห็นอกเห็นใจหรือความฉลาดทางอารมณ์คุณก็ไม่ควรออกแบบ APIs หรือ GUI หรือภาษา ฉันเข้าใจว่าเขากำลังพูดว่าในวิศวกรรมซอฟต์แวร์โปรแกรมเมอร์ควรรู้ว่าผู้ใช้จะเห็นผลิตภัณฑ์และการออกแบบของพวกเขาอย่างไร ฉันรู้สึกว่าย่อหน้าข้างต้นน่าสนใจมาก

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

6
เปลี่ยนโลกของลูกค้า - เราจะจัดการสิ่งนี้ได้อย่างไร
เมื่อไม่นานมานี้เราได้รับมอบหมายให้โครงการเข้ามาแทนที่ระบบเมนเฟรมเก่าของลูกค้าด้วยโซลูชัน ASP.NET อินทราเน็ตใหม่โดยใช้ SQL Server เป็นส่วนหลัง ส่วนหนึ่งของสิ่งนี้คือการปรับโครงสร้างของธุรกิจเช่นกัน - โดยพื้นฐานแล้วเมื่อเราเปลี่ยนระบบเราต้องคิดว่าเราจะทำธุรกิจได้ดีขึ้นอย่างไร ดังนั้นงานแรกคือการเข้ามาและทำแบบจำลองทางตรรกะและข้อมูลทางกายภาพ ลูกค้าอยู่ใน dicussions เหล่านี้และได้ลงชื่อออกอย่างสมบูรณ์ ขั้นตอนต่อไปคือการออกแบบและสร้างของแต่ละโมดูล เพื่อให้เนื้อเรื่องสั้นสั้นการเขียนโปรแกรมก็เสร็จสิ้นและตอนนี้เรากำลังทำการทดสอบระบบแบบขนาน สิ่งที่กำลังจะยอดเยี่ยมสำหรับส่วนใหญ่ของโมดูลจนถึง - ยกเว้นหนึ่ง เรามีระบบเดียวที่ - หากคุณต้องการให้ผู้ใช้ทางธุรกิจเห็นแอปพลิเคชันและรายงานทั้งหมดจะดี ทำงานร่วมกับเวิร์กโฟลว์แบบรวมใหม่และดำเนินกระบวนการแบบแมนนวลโดยอัตโนมัติก่อนหน้านี้และทำงานได้อย่างยอดเยี่ยมตามข้อกำหนด การทดสอบแบบขนานได้เปิดเผยปัญหาบางอย่างด้วยข้อมูลการย้ายข้อมูลแบบเดิม ผู้สร้างระบบเดิมกำลังทำความเข้าใจกับ schema และกระบวนการทางธุรกิจใหม่อย่างหนักดังนั้นพวกเขาจึงมีเวลาที่ยากลำบากมากในการทำความเข้าใจวิธีการใช้ข้อมูลดั้งเดิมและนำมาไว้ในสคีมาใหม่ ด้วยเหตุนี้พวกเขาจึงเรียกประชุมผู้ใช้ทางธุรกิจและผู้มีส่วนได้ส่วนเสียและบอกพวกเขาว่าระบบใหม่ไม่ได้ให้ข้อมูลที่ระบบเก่าทำ (เมื่อเป็นจริง) - ทำให้ระบบใหม่ดูไม่ดี นี่มันน่าหงุดหงิดที่จะพูดน้อยที่สุด ระบบใหม่ใช้งานได้ดีและให้ทุกสิ่งที่พวกเขาต้องการและต้องการและหากไม่ใช่เพราะเจ้าหน้าที่ไอทีไม่สามารถกรอกข้อมูลลงในตารางใหม่ด้วยข้อมูลเก่าผู้ใช้ทางธุรกิจจะพึงพอใจกับคุณสมบัติและฟังก์ชั่นใหม่ ฉันขอคำแนะนำเกี่ยวกับวิธีจัดการกับสิ่งนี้ เนื่องจากการเคลื่อนไหวทางการเมืองบางอย่าง "สถาปนิก" ใหม่จึงไม่ทราบว่าระบบทำงานอย่างไรและไม่สามารถเข้าใจถึงการเปลี่ยนแปลงที่เจ้าหน้าที่ไอทีร้องขอได้อย่างเต็มที่ เจ้าหน้าที่ไอทีต้องการเปลี่ยนแปลงระบบพื้นฐานซึ่งไม่จำเป็นโดยพื้นฐานและเป็นการออกแบบที่ไม่ดี แต่เป็นลูกค้า ความคิดใด ๆ

9
ส่วนแบ่งรายได้กับลูกค้าที่ไม่สามารถชำระค่าธรรมเนียมการพัฒนา [ปิด]
ปิด. คำถามนี้เป็นคำถามปิดหัวข้อ ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้เป็นหัวข้อสำหรับ Software Engineering Stack Exchange ปิดให้บริการใน4 ปีที่แล้ว ฉันมีลูกค้าที่มีไอเดียสำหรับแอปพลิเคชัน ipad แต่ไม่สามารถหาแหล่งเงินทุนที่เพียงพอสำหรับสิ่งนี้ แนวคิดหนึ่งที่เกิดขึ้นคือฉันทำงานให้ฟรีหรือเสียค่าธรรมเนียมเล็กน้อยจากนั้นรับเปอร์เซ็นต์ของรายได้จาก appstore ฉันจะตัดสินใจว่าเปอร์เซ็นต์ที่เป็นจริงได้อย่างไร สิ่งนี้ได้รับผลกระทบจากราคาใน appstore และฉันจะป้องกันตัวเองจากสถานการณ์ที่ลูกค้าตัดสินใจนำเสนอแอปฟรีได้อย่างไร

4
คุณให้ความรู้ลูกค้าของคุณอย่างไร?
ลูกค้าต้องการการศึกษาเพราะพวกเขาคิดแตกต่างกัน ลูกค้าคิดว่า: การเปลี่ยนแปลงไม่ได้เป็นปัญหาในเวลาใด ๆ ของโครงการ รายละเอียดไม่สำคัญ (ข้อยกเว้นแม้แต่น้อย) เวลาไม่เสียค่าใช้จ่าย (มีการแก้ไขราคาตกลง) หนึ่งประโยคในข้อกำหนดสามารถขยาย / อ่านได้อย่างอิสระเพื่อให้เหมาะกับความต้องการที่แท้จริง - และสิ่งนี้ไม่ส่งผลกระทบต่อสัญญา (ที่นี่เราเห็นการสนทนา "สามัญสำนึก" บ่อยครั้ง - ตัวอย่าง: "แน่นอนว่าเราต้องการหน้าจอการจัดการใบแจ้งหนี้เมื่อเราพูดถึงการจัดการบัญชี - นี่เป็นสามัญสำนึก!") รายการไปที่ ... ปัญหาหลักคือลูกค้า (ไม่ว่าภายนอกหรือภายใน / แผนก) ไม่ต้องการหรือไม่เข้าใจ ฉันใช้เวลาหลายปีในการทำความเข้าใจกระบวนการสร้างซอฟต์แวร์และฉันยังคงเรียนรู้อยู่ดังนั้นพวกเขาจะทำได้ในเวลาเพียงไม่กี่เดือน ประสบการณ์ของคุณคืออะไรวิธีที่ดีที่สุดในการให้ความรู้แก่ลูกค้าคืออะไร?
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.