Làm thế nào để xử lý, bạn có thể thêm chỉ một vài trường nữa Loại yêu cầu của khách hàng không?

Rất phổ biến, chúng tôi có các yêu cầu tính năng cho các lĩnh vực mà chỉ một khách hàng muốn. Điều này, tốt nhất, làm lộn xộn mã của ứng dụng. Thông thường khi chúng tôi tìm kiếm trong cơ sở dữ liệu của họ một vài tháng sau khi thêm các trường, chúng tôi có thể thấy rằng họ thậm chí không sử dụng các trường bổ sung. Ngoài ra, đây là một ứng dụng khá cũ nên việc thêm một trường yêu cầu nhiều thay đổi mã, thay đổi báo cáo và đảm bảo rằng nó không ảnh hưởng đến các khách hàng khác, những người không cần phải xem trường.

• Làm thế nào chúng ta có thể chắc chắn rằng một khách hàng thực sự cần những yêu cầu tính năng này?

• Làm thế nào để chúng tôi lịch sự nói "bạn không thực sự cần điều đó"?

Hiện tại chúng tôi đang bắt đầu tính phí cho các yêu cầu tính năng nhất định. (Trước đây, các yêu cầu tính năng thường miễn phí) Chúng tôi có thể làm gì khác không?

Họ đang trả tiền cho các tính năng bổ sung? Nếu vậy, thì đó thực sự không phải là việc của bạn cho dù họ có sử dụng chúng hay không. Cung cấp cho họ những gì họ phải trả cho. Tuy nhiên, nếu đó không phải là trường hợp, thì tùy thuộc vào sự lãnh đạo của bạn để quyết định xem họ có sẵn sàng tiếp tục thêm các tính năng mà không có thêm thu nhập hay không.

Chúng tôi có một tình huống tương tự. Cách chúng tôi xử lý là xây dựng mối quan hệ dựa trên niềm tin, cho phép chúng tôi tự do nói "bạn không cần điều này". Phải mất thời gian, sự bình tĩnh và bạn phải chuẩn bị để nói nhiều và ăn trưa và các công việc nhàm chán khác. Những cuộc họp nhàm chán này sẽ tự trả tiền trong thời gian dài, nơi bạn có thể tập trung vào việc tạo ra các tính năng thực sự quan trọng.

Nói chuyện cũng sẽ khiến bạn thấy nếu những gì họ hỏi thực sự quan trọng.

Tôi không nghĩ bạn có thể tham gia vào "bạn có thực sự cần nó không?" tranh cãi với khách hàng. Cá nhân, tôi muốn hỏi, "Làm thế nào điều này sẽ làm cho công ty của bạn có nhiều tiền hơn?" nhưng thực tế của vấn đề là, một số người quản lý, vì một số lý do muốn theo dõi nó và họ đang sử dụng để đi theo con đường của họ. Nếu bạn không muốn làm điều đó, hãy nói không hoặc tính một số tiền lớn như vậy để ngăn cản yêu cầu.

Bắt đầu xem xét các cách để giúp ứng dụng của bạn dễ dàng xử lý số lượng lớn hơn các lĩnh vực khách hàng.

1. Cho phép nhãn trong các báo cáo và biểu mẫu được đặt bởi khách hàng để sử dụng các trường hiện có.
2. Thêm các trường chung (String12) vào các bảng trường tùy chỉnh hiện có hoặc bổ sung.
3. Có một hệ thống trường do người dùng xác định trong đó tất cả được xử lý bằng cách nhập dữ liệu và không phải tạo các cột mới trong các bảng (Tôi không thể nhớ cái này được gọi là trợ giúp.).

Bạn có thể thấy rằng các khách hàng hiện tại đang phát triển hệ thống của bạn. Ngành công nghiệp có thể đang thay đổi nên các yêu cầu mới đang xuất hiện.

Xin lỗi, nhưng nếu bạn không thể cung cấp cho khách hàng của mình những gì họ muốn hoàn toàn vì lý do kỹ thuật và không sinh lợi, bạn cần phải bắt kịp tiến độ. Sẽ không khó để một người mới tham gia vào thị trường của bạn với nhiều lĩnh vực hơn, vì vậy đừng để điều đó xảy ra.

Nhìn từ phía bên kia của cửa sổ một lúc, ở công việc cuối cùng của tôi, tôi đã tiếp xúc với một hệ thống ERP cho phép người dùng cuối thêm các cột "tùy chỉnh" vào bất kỳ thực thể / bảng nào. Từ những tương tác ngắn ngủi của tôi với nó, có vẻ như họ đang tự động thêm các cột vào bảng thứ hai với ánh xạ một-một. Ví dụ:

Bảng WIDGET với các cột tĩnh:

• WIDGET_ID
• WIDGET_NAME
• WIDGET_COST
• Vân vân.

Bảng WIDGETCUSTOM với các cột có thể xác định người dùng:

• WIDGET_ID
• WIDGET_weIGHT
• DID_BOB_WORK_ON_WIDGET
• Vân vân.

Cột WIDGET_ID có thể liên kết chúng lại với nhau. Nó tự động hiển thị các trường bổ sung của bạn khi bạn đang chỉnh sửa một tiện ích và bạn có thể đưa chúng vào các báo cáo động hoặc thậm chí tìm kiếm theo chúng. Nó khá hiệu quả vì cơ sở dữ liệu vẫn có thể theo dõi chúng và lập chỉ mục các cột đó nếu cần, v.v.

Từ quan điểm lập trình, tôi thấy làm thế nào điều đó sẽ giữ cho nó lành mạnh. Mỗi khách hàng có thể có các cột tùy chỉnh riêng, nhưng các cột tùy chỉnh đó không can thiệp vào logic cốt lõi của bạn.

Tính năng "yêu cầu" chỉ là, yêu cầu. Nếu họ đang đưa ra yêu cầu thì bạn cần phải quyết định giá trị của công ty là bao nhiêu để "làm lộn xộn" cơ sở mã với điều đó. Nếu nó trở thành một vấn đề đặc hữu thì bạn có thể kiểm soát nó, nhưng nếu họ sẵn sàng trả những gì bạn yêu cầu hoặc một cái gì đó gần với nó và đó chỉ là một vài tính năng ở đây và đó, tôi nói hãy đi với tiền.

Để đi xa hơn, nếu đây là vấn đề thường xuyên với sản phẩm của bạn và nhiều khách hàng đang tìm kiếm các loại tùy chỉnh này, có lẽ đã đến lúc bạn cần suy nghĩ lại về các phần của ứng dụng này và làm cho chúng linh hoạt theo cách mà khách hàng được trao quyền để thực hiện điều này chính họ, có thể là báo cáo đột xuất, thu thập dữ liệu linh hoạt, v.v ... Hãy cố gắng biến những phiền toái này thành một điểm bán hàng. "Mô hình dữ liệu chứng khoán của chúng tôi không đủ tốt cho bạn? Hãy xem các tùy chọn tùy chỉnh của chúng tôi! Bạn có thể tự làm điều đó!"

Bạn nên suy đoán chính xác những gì bạn sẽ làm trong tính năng nói trên và áp dụng thời gian ước tính để xây dựng nó. Nếu khách hàng muốn các lĩnh vực bổ sung là tốt, hãy lập hóa đơn cho họ. Tôi nói với khách hàng của mình rằng nếu bạn muốn thêm các tính năng sau khi tôi đã xây dựng tính năng này, điều đó cũng tốt, nhưng trong một số trường hợp sẽ tốn thêm một chút chi phí để sử dụng chúng.

Tôi đang có một thời gian khó hiểu tại sao bạn quan tâm nếu họ sử dụng nó hay không. Thật đơn giản, bạn xây dựng những gì họ muốn và bạn được trả tiền cho nó.

Mã cơ sở lộn xộn? Nếu bạn cần cấu trúc lại mã của mình khi làm việc trong tính năng mới, hãy tính phí cho mã đó.

Tạo một danh sách một số tính năng bạn xem xét thêm, bao gồm thêm "chỉ một vài trường bổ sung". Hiển thị danh sách cho khách hàng của bạn và yêu cầu họ phản hồi về những gì họ muốn đầu tiên. Giải thích rằng tài nguyên của bạn bị giới hạn và bạn không thể làm tất cả cùng một lúc. Sử dụng phản hồi để quyết định bạn muốn đi theo hướng nào với ứng dụng của mình.

Nếu một khách hàng khẳng định rằng vài trường bổ sung thực sự là điều đó quan trọng và bạn vẫn quyết định không bổ sung chúng, hy vọng khách hàng vẫn có thể thấy lợi ích của tính năng mà bạn đang thực hiện để thay thế.

Có vẻ như bạn có thể được hưởng lợi từ một số loại hệ thống kéo. Hãy để người dùng chọn tính năng nào sẽ được triển khai tiếp theo, nhưng giới hạn số lượng có thể được phát triển tại bất kỳ thời điểm nào. Một bảng Kanban là tuyệt vời cho việc này. Nó có thể cung cấp cho người dùng quyền sở hữu của quá trình đánh giá cao (còn gọi là ít trách nhiệm và căng thẳng hơn cho bạn). Tin tôi đi, nếu người dùng buộc phải quyết định tính năng nào sẽ được phát triển tiếp theo, biết rằng các yêu cầu khác sẽ được đặt sang một bên, họ sẽ đầu tư nhiều hơn vào việc thực sự quyết định những gì họ cần phải có.

Tôi nghĩ bạn nên yêu cầu khách hàng của bạn đưa một hoặc nhiều bạn qua "ngày tại văn phòng" để xem họ thực sự sử dụng phần mềm như thế nào ... Đợi ... Thuê tôi với giá 250 đô la / giờ và tôi sẽ đi tìm hiểu. Ngoài ra, xin vui lòng, xin đừng mạ vàng. Làm cho nó chỉ hoạt động. Hầu hết các doanh nghiệp không quan tâm rằng nó trông xấu khi nó hoạt động tốt.

Theo dõi các yêu cầu. Khi bạn thiết kế / phát triển các tính năng lớn , hãy chọn một số yêu cầu ưu tiên để đưa vào bản phát hành đó.

Xây dựng một hệ thống đàm phán tiêu chuẩn cho các yêu cầu. Có thể một cái gì đó dựa trên một hệ thống yêu cầu báo cáo lỗi hoặc tính năng, như Fogormsz. Cho phép khách hàng của bạn đặt yêu cầu và ưu tiên dựa trên:

• tính khả thi / chi phí kỹ thuật của tính năng
• tính năng này có yêu cầu "trả tiền" không? Nếu nó có trong hợp đồng và / hoặc họ đã trả tiền cho nó, thì hãy đặt nó vào
• tính năng "có ý nghĩa" không? Đây là một chút nghệ thuật, nhưng, nói chung, nếu đủ khách hàng yêu cầu một tính năng, sau đó thực hiện nó miễn phí. Đó là một cơ hội để làm cho sản phẩm của bạn tốt hơn và bán cho khách hàng tiếp theo dễ dàng hơn
• Bạn có sử dụng, chu kỳ trả tiền có sẵn? Nếu bạn bao gồm một bộ giờ hàng tháng để bảo trì / hỗ trợ như một phần trong hợp đồng của bạn (tôi thực sự khuyên bạn nên làm, ngay cả khi số lượng rất thấp) và chúng sẽ không được sử dụng, hãy bắt đầu thực hiện những thay đổi này

Nếu khách hàng có toàn quyền sở hữu ứng dụng, thì hãy làm những gì họ yêu cầu. Hãy để họ thổi tiền của họ; nó là của họ.

Tuy nhiên, nếu bạn không muốn, bạn muốn đi đến một giải pháp cho các trường phụ trợ này liên quan đến việc lưu trữ chúng bên ngoài mô hình dữ liệu cốt lõi. Sau đó, bạn có thể sử dụng một cái gì đó như chế độ xem cơ sở dữ liệu để hợp nhất các trường bổ sung trở lại cho khách hàng cụ thể này. (Có một số cách để lưu trữ phụ trợ, tùy thuộc vào bản chất của dữ liệu được lưu trữ; đơn giản nhất chỉ là một bảng có cùng khóa chính với một số PK trong bảng chính của bạn, nhưng không hiệu quả khi sử dụng của lĩnh vực này rất thưa thớt. Nó thực sự chỉ là vấn đề khi họ muốn các tính năng của lĩnh vực yêu cầu những thứ như lập chỉ mục.)

Bạn cũng có thể tắt yêu cầu của khách hàng nói rằng bạn không có đủ tài nguyên để thực hiện chúng ở giai đoạn này. Nó thực sự hữu ích nếu tại thời điểm đó bạn chỉ ra lộ trình của bạn nói rằng (ước tính tốt nhất của bạn tại) khi nào có thể thực hiện những gì họ muốn với giá rẻ. Và bạn nên ưu tiên đưa ứng dụng vào trạng thái có thể hỗ trợ các tính năng với giá rẻ, vì tính năng meta đó trở thành một tính năng bán hàng cốt lõi của ứng dụng chính của bạn.