Xử lý sự không phù hợp với văn hóa của khách hàng / nhà phát triển trong một dự án nhanh

Một trong những nguyên lý của sự nhanh nhẹn là ...

Hợp tác khách hàng qua đàm phán hợp đồng

... một cái khác là ...

Các cá nhân và tương tác qua các quy trình và công cụ

Nhưng theo cách tôi nhìn thấy, ít nhất là khi nói đến tương tác với khách hàng, có một vấn đề cơ bản:

Cách khách hàng nghĩ khác với cách một kỹ sư phần mềm nghĩ

Đó có thể là một chút khái quát, vâng. Có thể cho rằng, có những lĩnh vực kinh doanh mà điều này không nhất thiết là đúng --- tuy nhiên chúng chỉ có rất ít. Trong nhiều lĩnh vực, khách hàng tiêu biểu là:

1. Quan tâm đến mối quan tâm hoạt động hàng ngày - chiến thuật tầm ngắn ... không nhất thiết là chiến lược;
2. Có thể hiểu, chỉ quan tâm đến giải pháp trước mắt;
3. Nhà tư tưởng thực tiễn, không phải nhà tư tưởng trừu tượng;
4. Quan tâm nhiều hơn đến việc "hoàn thành công việc" hơn là xem xét giải pháp sẽ hỗ trợ các mối quan tâm trong tương lai như thế nào.

Mặt khác, trong lý tưởng , các kỹ sư phần mềm thực hành nhanh nhẹn là:

1. Những người nghĩ rất nhiều về chất lượng;
2. Các cá nhân đánh giá cao làm thế nào một chút công việc trả trước có thể tiết kiệm một tấn trong nỗ lực xuống dòng;
3. Kinh nghiệm, tư duy phân tích.

Vì vậy, dường như có một sự khác biệt về văn hóa có xu hướng ức chế "sự hợp tác của khách hàng".

Cách tốt nhất để giải quyết vấn đề này là gì?

Trong nhiều lĩnh vực, khách hàng tiêu biểu là:

• Quan tâm đến mối quan tâm hoạt động hàng ngày - chiến thuật tầm ngắn ... không phải chiến lược;
• Chỉ quan tâm đến giải pháp trước mắt;
• Nói chung là những người suy nghĩ một chiều, không trừu tượng;
• Chủ yếu quan tâm đến việc "hoàn thành công việc", trái ngược với việc đưa ra một giải pháp chất lượng lâu dài.

Và thẳng thắn, họ thường có lý do chính đáng để nghĩ như thế này. Trước hết, họ đang điều hành một doanh nghiệp, sẽ tạo ra doanh thu hôm nay và ngày mai, không phải trong một tương lai xa. Thứ hai, họ không phải là chuyên gia kỹ thuật - họ không biết những gì có thể và những gì không, và hậu quả của các lựa chọn kiến ​​trúc / thiết kế / thi công cụ thể là gì. Đây là những gì chúng ta biết.

Vì vậy, câu trả lời là - hầu như không đáng ngạc nhiên - giao tiếp .

Bạn cần giao tiếp nhiều, giáo dục lẫn nhau, làm cho nhau hiểu quan điểm của bên kia ít nhất là đến mức cơ bản. Bạn cần giải thích cho họ những hậu quả ngắn hạn và dài hạn của các lựa chọn thay thế có thể. Và bạn cần sử dụng ngôn ngữ họ hiểu .

• Nếu bạn nói "đây sẽ là một bản hack, làm cho mã ít đọc và có thể mở rộng hơn" , họ nói, "ừ, sao cũng được" .
• Nếu bạn nói "đây sẽ là một sửa chữa ngắn hạn, sẽ làm cho việc phát triển và bảo trì dài hạn tốn kém hơn và tăng nguy cơ giới thiệu các lỗi" , họ nói "a ha, hãy xem xét" .
• Và nếu bạn nói rằng "giải pháp này sẽ tiêu tốn của bạn 100 đô la ngay bây giờ, nhưng giới thiệu 500 đô la nợ kỹ thuật mà bạn nhất định phải trả lại tiền lãi sớm hay muộn; OTOH giải pháp khác này hiện có giá 400 đô la và không để lại nợ kỹ thuật; muốn " , họ nói " bây giờ chúng ta đang nói! " .

OTOH họ có thể dạy chúng ta một vài điều về quan điểm kinh doanh. Doanh nghiệp muốn có thể sử dụng và đủ tốt - hầu như không hoàn hảo - giải pháp. Và họ biết có lẽ tốt hơn bất cứ ai rằng "hoàn hảo là kẻ thù của sự tốt lành". Vì vậy, bạn cần lưu ý rằng công việc của chúng tôi là cung cấp giải pháp cho các vấn đề của khách hàng, thay vì sản xuất phần mềm hoàn hảo về mặt kỹ thuật. Đôi khi hai điều này hội tụ đến cùng, nhưng thường thì không. Điều này có thể được xem là buồn bởi nhiều người, nhưng đó là thực tế kinh doanh. Đối với tôi, nếu tôi xoay sở để giải quyết vấn đề của khách hàng và tôi thấy rằng điều đó làm cho cuộc sống của họ dễ dàng hơn, tôi cũng hạnh phúc như họ. OTOH nếu tôi quản lý để thực hiện thiết kế hoàn hảo mà tôi có trong đầu, nhưng công ty phá sản vào tuần sau, đó có phải là một chiến thắng cho bất cứ ai không?

Một chủ doanh nghiệp hợp lý sẽ hiểu - nếu bạn giải thích họ bằng ngôn ngữ của họ - tại sao điều quan trọng là giữ sạch phần mềm, viết bài kiểm tra đơn vị, để tái cấu trúc, v.v. Mặc dù những điều này dường như không đóng góp trực tiếp bất cứ điều gì trong ngắn hạn, rất cần thiết cho bảo trì dài hạn. Và khách hàng hợp lý quan tâm đến khả năng duy trì lâu dài của doanh nghiệp của họ, vì vậy họ chắc chắn sẵn sàng đầu tư vào đó khi họ thấy giá trị đầu tư của họ tạo ra. Tuy nhiên, cả tài nguyên của họ và thời gian của bạn đều có hạn, vì vậy bạn cần ưu tiên và tập trung vào những điều quan trọng nhất. Nhưng nó chỉ quan trọng nếu nó quan trọng với cả hai bạn.

Bạn có thể muốn cấu trúc lại mô-đun A vì mã trong đó thật khủng khiếp và bạn có một ý tưởng tuyệt vời làm thế nào để cấu trúc lại mã để ngắn gọn, thanh lịch và sạch sẽ, sử dụng một mẫu thiết kế mà bạn vừa đọc. Tuy nhiên, nếu mô-đun đó không được chạm trong nhiều năm và nó hoạt động đáng tin cậy, rất có thể bạn nên tập trung vào mô-đun B, sẽ được mở rộng vào tuần tới với một tính năng mới rất quan trọng và nó chứa hàng tấn lỗi đã sẵn sàng.

Làm thế nào khách hàng của bạn nhìn nhận bản thân:

• Tôi có một dự án mà tôi cần phải hoàn thành càng sớm càng tốt
• Tôi biết nhu cầu kinh doanh của tôi
• Tôi cần giải quyết vấn đề theo cách không gây gián đoạn cho các hoạt động kinh doanh hiện tại
• Tôi có một ngân sách hạn chế để thực hiện điều này.

Mặt khác, họ thấy nhóm của bạn là:

• Những người không hiểu rằng họ đang hút tiền từ ngân sách của tôi.
• Không hiểu nhu cầu kinh doanh của chúng tôi
• Muốn thiết kế lại mọi thứ mặc dù điều đó sẽ khiến việc triển khai nó trở nên khó khăn hơn đối với doanh nghiệp.
• Muốn có giải pháp khéo léo khéo léo khi tất cả tôi có ngân sách cho là chức năng và hiệu quả.

Vấn đề chính của bạn dường như là cả hai bạn đều không hiểu họ cần gì từ bên kia.

Chà, đầu tiên và quan trọng nhất, Agile không phải là giải pháp cho tất cả các vấn đề bạn gặp phải trong dự án của mình.

Cách khách hàng nghĩ về cơ bản khác với cách một kỹ sư phần mềm nghĩ

Đúng. Đôi khi nó là sự thật. Thậm chí có trường hợp khách hàng không biết họ muốn gì và như thế nào (nghĩa là các yêu cầu không rõ ràng). Dù thế nào đi nữa, nếu bạn nhanh nhẹn, bạn sẽ nhận được kết quả sau mỗi lần chạy nước rút (giả sử 2 tuần) và bạn có cơ hội nhận phản hồi của khách hàng và đảm bảo tất cả đều ở trên cùng một trang. Điều này giúp xác định và khắc phục sớm các vấn đề sẽ giúp xây dựng lòng tin.

Ngoài ra còn có một câu nói, người dùng giống như những đứa trẻ điên, vì vậy khi họ yêu cầu một khẩu súng và bạn biết nó không an toàn, bạn có thể cân nhắc việc đưa một khẩu súng đồ chơi để trấn tĩnh họ .

Cách tốt nhất để giải quyết vấn đề này là gì?

Như tôi đã nói, không có cây gậy ma thuật nào có thể giải quyết mọi vấn đề . Bạn cần phải tham gia nhiều hơn với khách hàng của mình để có sự hiểu biết tốt về những gì nhau làm. Thúc đẩy truy cập trang web, phản hồi mở, vv

Hãy chắc chắn rằng chủ sở hữu sản phẩm của bạn và những người nắm giữ cổ phần tham dự các bản giới thiệu nước rút và đưa ra gợi ý có giá trị để cải thiện sản phẩm .

Nếu bạn không mua từ khách hàng, Agile có thể gần như không thể.

Bằng cách mua vào, tôi có nghĩa là nhận được một số phần trăm bảo đảm của thời gian đại diện khách hàng mỗi tuần hoặc tháng. Tỷ lệ này sẽ thay đổi tùy thuộc vào dự án.

Rõ ràng là họ có công việc hàng ngày của họ, vì vậy không chỉ phụ thuộc vào đại diện khách hàng của họ, mà còn quản lý của họ để dành thời gian cho họ.

Vì vậy, nhận được sự đồng ý từ ban quản lý về phía khách hàng là chìa khóa cho vấn đề này

Hãy nhớ rằng nhanh nhẹn không có nghĩa là khách hàng có liên quan đến việc đứng lên hàng ngày hoặc một số khía cạnh hàng ngày khác của nhanh nhẹn. Agile, từ quan điểm của khách hàng, là về giao tiếp. Điều đó không có nghĩa là họ đang liên lạc với các kỹ sư về chi tiết thực hiện.

Khách hàng hợp tác với chủ sở hữu sản phẩm để nhận và đưa ra phản hồi liên tục. Chủ đề là các tính năng, nhưng không phải cách chúng được thực hiện. Bạn đang cung cấp các tính năng thích hợp? Bạn có đúng tiến độ không? Họ có thay đổi yêu cầu bạn cần để thích nghi?

Agile giúp bạn và khách hàng của bạn trả lời những câu hỏi đó.