Cách tốt nhất để cho phép khách hàng đóng góp cho một dự án là gì?


12

Chúng tôi đã và đang xây dựng một CRM cho một khách hàng. Bây giờ giai đoạn chính đầu tiên đã kết thúc và giai đoạn thứ hai đã đồng ý, khách hàng muốn nhận một số công việc, thực hiện các sửa đổi nhỏ cho lược đồ cơ sở dữ liệu và xử lý giai đoạn đầu tiên trong khi chúng tôi xây dựng giai đoạn thứ hai .

Tôi không quyết định liệu điều này có thực tế hay không, nhưng giả sử là vậy, tôi muốn một số gợi ý về các biện pháp có thể được thực hiện để làm cho điều này hoàn toàn khả thi. Đây là những gì tôi đã có cho đến nay:

  • Cho đến nay, khách hàng hầu hết đã nhìn thấy dự án từ quan điểm của người dùng; rõ ràng, một cuộc hội thảo gồm hai phần nên diễn ra nơi chúng tôi giới thiệu anh ấy với các hoạt động bên trong:

    • đầu tiên, hiển thị lược đồ cơ sở dữ liệu hiện có và, bằng cách ví dụ, mở rộng nó,
    • sau đó, hiển thị một số mã mẫu và viết một quy trình kinh doanh mới để cải tiến lược đồ.
  • Mã hiện đang nằm trong kho Subversion nội bộ. Mặc dù chúng tôi có thể thiết lập một hoặc một mạng công khai trên mạng của anh ấy (mà chúng tôi có thể VPN), tôi cảm thấy một hệ thống phân tán sẽ hoạt động tốt hơn. Tuy nhiên, tôi dường như là người duy nhất cảm thấy như vậy, vì vậy tôi có thể sử dụng một số lập luận thuyết phục tốt.
  • Tôi không chắc chắn làm thế nào để ủy quyền / đảm bảo rằng mã chạy trong sản xuất được cam kết. Có vẻ như "x đã thực hiện một thay đổi quan trọng, không có giấy tờ ngay trước khi đi nghỉ; bây giờ bạn đang cố gắng tìm ra lỗi này đã xảy ra kể từ đó" thảm họa là không thể tránh khỏi. Lý tưởng nhất là tất cả các thay đổi, trước khi triển khai, sẽ:

    • được ghi lại trong một hệ thống theo dõi vấn đề,
    • xảy ra trên một môi trường thử nghiệm riêng biệt trước tiên và
    • phải vượt qua các bài kiểm tra tự động.

    Than ôi, tôi nghi ngờ kỷ luật cho bất kỳ trong số đó sẽ thắng thế.

Giả sử rằng kiến ​​trúc trình cắm hoặc dự án riêng biệt không có các tùy chọn khả thi, bởi vì 1) cái trước không tồn tại và 2) cái sau sẽ cấm khách hàng nhìn vào và có thể sửa đổi mã hiện có, một khả năng mà tôi tin rằng anh ta sẽ nhấn mạnh vào.


2
Nói với họ bạn cần họ đóng vai trò của một cây nấm. Giữ chúng trong bóng tối và cho chúng ăn bs.
capdragon

@capdragon Tôi đồng ý, (và Mark Whalberg từ The Departed cũng vậy )
Chani

1
Bạn đã xem xét các khía cạnh pháp lý của một sự sắp xếp như vậy? Ai chịu trách nhiệm bảo trì mã sửa đổi của khách hàng? Ai sở hữu bản quyền về mã do bạn và khách hàng sản xuất, bạn có muốn bán hệ thống hoặc các bộ phận của hệ thống cho khách hàng khác không?
Jaydee

Đúng; các khía cạnh pháp lý đang được quan tâm. Bản quyền không liên quan (hoặc, đúng hơn, không phải là vấn đề cụ thể đối với dự án này ), vì đó là mã dành riêng cho khách hàng, vì vậy dù sao họ cũng sở hữu nó.
Sören Kuklau

Câu trả lời:


2

Đây sẽ là câu trả lời ít được yêu thích nhất - nhưng dù sao nó vẫn ở đây!


Đó là rủi ro (nhiều như cho phép một người mới lái một chiếc xe hoàn toàn mới) - nhưng đó không phải là một ý tưởng tồi.

Hiểu lý do tại sao họ muốn làm điều này: không phải là họ có tài nguyên dự phòng, mà chỉ để khiến bản thân cảm thấy bị kiểm soát.

Những gì bạn cần làm là làm theo:

  1. Giáo dục khách hàng của bạn - phần mềm không chỉ là một mã. Nếu họ muốn tham gia, trước tiên hãy để họ xem xét các khía cạnh kiến ​​trúc, thiết kế, v.v. Đặt câu hỏi cho họ và cho họ thấy ý nghĩa của những lựa chọn họ đưa ra trước.

  2. Bạn nên luôn luôn quay lại với các tùy chọn về ủng hộ / cách tiếp cận (và ghi lại những cuộc họp này tốt) nhưng bạn nên cho phép họ đưa ra một số quyết định. Ít nhất là họ sẽ bắt đầu đánh giá cao rằng họ không biết nhiều - hoặc sẽ tự sở hữu.

  3. Bạn có thể tạo không gian riêng - chẳng hạn như các nhánh để chúng phải có thể mã hóa bất cứ thứ gì chúng muốn - mọi thứ cần được kiểm tra hợp lệ trước khi cam kết hoặc sáp nhập.

Trong khi tôi biết các biến chứng có thể xảy ra, mọi vấn đề là một cơ hội. Nếu mọi việc suôn sẻ, khách hàng của bạn sẽ thực sự đánh giá cao hơn về các vấn đề nội bộ, và sẽ phát triển niềm tin tốt hơn vì họ biết (làm thế nào) bạn đã hoàn thành tốt công việc!

Tái bút: Để cung cấp cho bạn một cái nhìn sâu sắc - tôi đến từ Ấn Độ; và tôi biết rất nhiều cửa hàng CNTT nơi quản lý không thực sự có nhiều đầu mối. Họ thường không bận tâm (thậm chí cảm thấy hạnh phúc) rằng khách hàng đặt thêm tài nguyên để đảm bảo rằng dự án không đi vào thùng rác! Điều này làm việc tuyệt vời cho họ; tất cả họ đều đi với một suy nghĩ "Dù bạn nói gì đi nữa!". Đây không phải là để hạ bệ người đồng hương của tôi - nhưng để cho thấy rằng phát triển chung không phải là một ý tưởng tồi. Rốt cuộc, điều mà nhiều chuyên gia quản lý miêu tả là " Cách tiếp cận ưu việt " đối với các vấn đề kinh doanh.


+1 câu trả lời hay dựa trên kinh nghiệm cá nhân, giống như OP muốn.
Sardathrion - chống lại lạm dụng SE

13

Ouch ... Bạn có ý tưởng đúng nhưng tôi đã thấy điều này có thể trở nên lộn xộn như thế nào và cả hai bên đều phải chịu đựng đáng kể. Tôi đang duy trì một ứng dụng như vậy hiện nay.

Tìm hiểu lý do thực sự tại sao khách hàng thấy cần thiết phải đóng góp trực tiếp cho dự án. Có phải bây giờ họ muốn dự án được thực hiện nhanh hơn bạn thực tế có thể biến nó ra không? Họ có muốn thay đổi không nhưng sợ phải chịu thêm chi phí từ bạn để thực hiện thay đổi thông số hoặc yêu cầu các tính năng bổ sung? Có một cuộc đấu tranh chính trị trong tổ chức của họ, nơi các nguồn lực phát triển nội bộ muốn kiểm soát và đầu vào nhiều hơn trong dự án hoặc nơi họ đang tìm kiếm công việc bận rộn cho các nhà phát triển nội bộ? (cái cuối cùng này gần nhà đối với tôi)

Tìm những gì động lực thực sự của họ và giải quyết chúng nếu có thể. Thực tế là họ thậm chí còn cho rằng đó là một dấu hiệu cảnh báo rất lớn rằng rắc rối đang xảy ra trên đường. Cố gắng làm giảm bớt mối quan tâm thực sự của họ trước khi đồng ý với điều đó bởi vì nhiều khả năng điều sẽ xảy ra là họ sẽ kiểm soát dự án và loại bỏ bạn, hoặc chúng sẽ gây ra sự hỗn loạn lớn và một dự án thất bại.

EDIT: Thật không may, con tàu đó đã đi thuyền cho bạn, nhưng đừng tuyệt vọng. Vẫn còn những điều bạn có thể làm để giảm thiểu rất nhiều nỗi đau sẽ đến. Cho dù thế nào, hãy chắc chắn rằng họ là MỘT VÀ CHỈ MỘT NGƯỜI QUẢN LÝ DỰ ÁN và NGƯỜI SỞ HỮU SẢN PHẨM và người này được liên kết với tổ chức / công ty của bạn. Người này phải có khả năng lập kế hoạch chạy nước rút, bao gồm hoặc xóa câu chuyện của người dùng và phân công nhiệm vụ cho các tài nguyên trong công ty của bạn cũng như công ty của khách hàng. Bất cứ điều gì xảy ra, vui lòng đảm bảo rằng các tài nguyên phát triển tại công ty của bạn không hoạt động riêng biệt từ các tài nguyên khách hàng của bạn và thậm chí quan trọng hơn là KHÔNGcho phép các nhà phát triển trong công ty của bạn báo cáo cho người quản lý dự án hoặc chủ sở hữu sản phẩm của họ! Họ sẽ tận dụng tối đa công việc miễn phí không có trong hợp đồng hoặc họ sẽ loại bạn ra khỏi dự án của riêng bạn. Đó là một sự chắc chắn.


Hai lý do đầu tiên có thể là tại chỗ, nhưng có lẽ là bất biến; một cách tự nhiên, có chi phí cao trong việc thu thập các yêu cầu thay đổi, chuyển chúng cho chúng tôi, trả tiền cho chúng, để chúng tôi kiểm tra nội bộ, sau đó thực hiện một số thử nghiệm của riêng chúng. Tôi lo lắng rằng con tàu có thể đã ra khơi, và do đó, tôi đang tìm cách giảm thiểu vấn đề, vì vậy câu hỏi của tôi.
Sören Kuklau

@ SörenKuklau Sau đó, tôi xin lỗi bạn đã thua trận chiến đó. Tôi sẽ chỉnh sửa câu trả lời của tôi và cung cấp một sự thay thế.
maple_shaft

Tôi đồng ý, nó đủ để khách hàng trả tiền . Trên thực tế, tính phí cho họ thêm cho bất kỳ sự tham gia tăng từ phía họ!
Chani

6

Từ góc độ pháp lý, về cơ bản, bạn đang hỏi "Cách tốt nhất để cưỡi lừa bịt mắt qua cánh đồng mỏ là gì?"

Từ góc độ lập trình, tôi sẽ hỏi thêm thông tin - khách hàng có thể yêu cầu triển khai bằng cách sử dụng một số loại hệ thống EAV do người dùng xác định hoặc với các móc có thể được thêm vào hệ thống không? Lý tưởng nhất là tôi muốn giữ mã của khách hàng tách biệt với mã của bạn càng tốt vì nhiều lý do.


10
What's the best way to ride a donkey blindfolded through a mine field?Tôi đoán câu trả lời là "Say rượu !!"
Thất vọngWithFormsDesigner

'Từ góc độ pháp lý, về cơ bản, bạn đang hỏi "Cách tốt nhất để cưỡi lừa bịt mắt qua cánh đồng của tôi là gì?" đây. Ẩn dụ tốt đẹp, mặc dù. :) Đối với kiến ​​trúc trình cắm hoặc dự án riêng biệt, hãy xem chỉnh sửa của tôi; họ không có triển vọng thực tế.
Sören Kuklau

Nếu đó là trường hợp, có gì sai khi bán cho khách hàng giấy phép nguồn cho CRM, với SLA?
Jonathan Rich

Khách hàng có quyền hợp pháp đối với mã. Đó không phải là vấn đề ở đây; hợp tác làm việc trên đó là.
Sören Kuklau

1
Nếu khách hàng có quyền hợp pháp đối với mã, thì giải pháp tốt nhất rõ ràng là coi mã là của họ, yêu cầu họ thiết lập kiểm soát phiên bản trên máy chủ của họ và lập hóa đơn cho bất kỳ bảo trì hàng giờ.
Jonathan Rich

3

Một người thường đóng vai trò là khách hàng ở đây. Tôi thực sự không gặp phải vấn đề này bởi vì nếu điều này xảy ra thì bạn sẽ kiểm soát nguồn của mình, sử dụng thiết lập CI và thiết lập QA của tôi để kiểm tra mọi thứ. Sự sắp xếp này có thể khá khó khăn để thiết lập - tôi nhận được rất nhiều phản hồi từ các chuyên gia tư vấn, đặc biệt là khiến mọi thứ diễn ra. Có quá trình intereferes với giờ hóa đơn có vẻ như.

Tôi nghĩ rằng quan điểm của bạn là khá trung thực một chút sai lệch. Đầu tiên, hãy nhớ rằng đó không phải là cơ sở mã của bạn mà là cơ sở mã của chúng tôi. Thứ hai là, trong hầu hết các trường hợp, cửa hàng CNTT ở phía khách hàng có thêm động lực để đảm bảo sản phẩm này hoạt động như thiết kế và dễ bảo trì, quản lý và hỗ trợ trong tương lai. Quay trở lại để sửa lỗi không phải là nhiều giờ hơn đối với chúng tôi không giống như hầu hết các chuyên gia tư vấn. Hơn nữa, việc xây dựng mọi thứ có thể dễ dàng cấu hình và thất bại theo những cách có thể dự đoán được là vô cùng quan trọng hơn khi bạn sở hữu mặt hoạt động của đồng tiền. Bạn có thể kết thúc với một dự án chất lượng cao hơn vì một phần của đội ngũ phát triển không bị hạn chế bởi số giờ có thể thanh toán.

Trong chừng mực làm thế nào để nó hoạt động, DCVS chắc chắn là con đường để đi nếu nó có thể được thực hiện. Chọn một cái gì đó trung tính (bitbucket, github) có thể giúp đỡ. Có CI tại chỗ cũng là một ơn trời ở đây - khó khăn hơn để mọi thứ thoát khỏi đòn đánh khi mọi người đều biết rằng nó đã thoát khỏi đòn đánh vào lần cam kết cuối cùng. Nếu bạn có thể buộc mọi thứ phải triển khai thông qua CI - điều mà chúng tôi thường phải buộc các nhà cung cấp - bạn thực sự có thể đảm bảo tất cả các thay đổi được cam kết. Đào tạo-khôn ngoan, bạn đã xem xét việc ghép đôi với khách hàng trong một vài ngày? Đó có thể là một cách tốt để thiết lập các mối quan hệ bên mà bạn cần. Nhìn chung, đặt cược tốt nhất là thuyết phục mọi người họ ở cùng một đội. Bởi vì họ ở cùng một đội.


3

Có vẻ như đây là một vấn đề quản lý vì nó là một vấn đề kỹ thuật. Tôi đã xử lý các tình huống như thế này ở cả hai công ty tư vấn và phần mềm. Từ một tổng thể "Khách hàng sẽ nhận được bao nhiêu giá trị từ phần mềm?" và "Tôi cần bao nhiêu nỗ lực để duy trì hậu kỳ?" đây thực sự là một tình huống tốt cho bạn Nhiều khách hàng nhấn mạnh vào người của họ có liên quan. Nó sẽ mất rất nhiều công việc mặc dù.

Bắt đầu với kết thúc trong tâm trí, bạn sẽ cần là một Tuyên bố công việc tốt . Điều này sẽ liệt kê những gì bạn đang ở trên móc và những gì họ đang ở trên móc. Một Vai trò và Trách nhiệm ma trận là một văn bản mang tính pháp lý ít mô tả những người sở hữu từng hạng mục, người có liên quan, và những người chỉ cần được thông báo. Cả hai đều cho rằng bạn có Cấu trúc phân chia công việc được xác định rõ , liệt kê ở mức thấp (đủ thấp để ước tính) mỗi nhiệm vụ là gì.

Về mặt sáng tạo, nó thường là thứ tự ngược lại: Phạm vi (mà bạn rõ ràng đã có) -> WBS (mà bạn có thể có) -> Ma trận Vai trò và Trách nhiệm -> SOW.

Khi bạn có quyền sở hữu được xác định rõ ràng, đã đến lúc quản lý mã và môi trường. Tôi khá bất khả tri về các công cụ quản lý mã. Điều tôi sẽ nói là điều quan trọng là thực hiện đánh giá mã cho mọi thứ được thực hiện bởi ai đó bên ngoài nhóm cốt lõi. Nếu công cụ bạn đang sử dụng cờ này, thì tốt hơn hết. Bạn muốn tránh ai đó kẹp một cái gì đó đi ngược lại các quyết định kiến ​​trúc quan trọng đã đưa ra trước đó. Khái niệm 4 mắt (2 mắt bổ sung xem xét mọi thứ) là quyết định chiến thuật quan trọng nhất bạn có thể đưa ra.

Môi trường cũng đau đớn để quản lý. Thông thường tôi đã trải qua các tình huống trong đó "Chúng tôi thực hiện công việc của mình trên môi trường của chúng tôi, khi chúng tôi hoàn thành nó sẽ đến với bạn" và cả nhà cung cấp và khách hàng đấu tranh thông qua. Tình hình của bạn có vẻ phức tạp hơn. Tôi khuyên bạn nên thử và tìm cách để họ làm việc trong môi trường của bạn cho đến khi dự án kết thúc. Nếu bạn có thể tìm cách đào tạo khách hàng trong việc quản lý môi trường của họ (đừng cho rằng họ giỏi việc này) thì tốt hơn hết.

Một vài cảnh báo khác ...

  1. Đừng cho rằng khách hàng có năng suất như nhóm của bạn. (Bạn sẽ nhận được những bất ngờ về kiến ​​thức tên miền, những bất ngờ về tốc độ cụ thể cho phần mềm của bạn.)

  2. Đừng cho rằng khách hàng biết phương pháp của bạn.

  3. Đừng cho rằng khách hàng chia sẻ công việc của nhóm bạn. (Tôi đã thấy cả những bất ngờ lên và xuống.)

  4. Dành nhiều thời gian đào tạo và đồng định vị.

  5. Mỗi giờ dành cho việc dạy khách hàng khắc phục sự cố sẽ tiết kiệm được nhiều ngày trong tương lai.

  6. Sử dụng khách hàng để làm việc thông qua tổ chức nội bộ của họ cho bạn và tìm các chuyên gia về câu hỏi nội dung và tên miền.

  7. Hãy tận dụng khách hàng để bán đào tạo tổ chức của họ.

  8. Theo mặc định liên quan đến khách hàng trong quá trình phát triển của bạn sẽ buộc bạn phải suy nghĩ như một công ty dịch vụ chuyên nghiệp. David Maister đã viết cuốn sách hay nhất về chủ đề này. Ngay cả khi chỉ có 20% có liên quan đến bạn, nó vẫn đáng để đọc.

Mặc dù tất cả những cảnh báo này, bao gồm các khách hàng trong nhóm của bạn có thể làm điều kỳ diệu để đưa bạn đến gần hơn với người mua của bạn. Những khách hàng này là những người có nhiều khả năng là tài liệu tham khảo trong tương lai. Chúc may mắn trong việc làm tốt nhất của tình huống này!


1
Tôi đồng ý, nhưng đối với một trong những mối quan tâm kỹ thuật, mỗi tổ chức có kho lưu trữ và chuỗi công cụ riêng của họ đều ổn, nhưng nếu đó là con đường bạn đi, việc khai báo nguồn 'chính' là rất quan trọng: hoặc của bạn, của họ hoặc của một duy trì riêng biệt 'chia sẻ tổng thể.' Nếu không có 'bậc thầy', khả năng tích hợp và hoàn nguyên sẽ không có vấn đề như OP nghi ngờ. Kho lưu trữ 'chính' sẽ đơn giản hóa các kiểm tra ánh xạ và các lỗi trở lại thành một phiên bản nguồn duy nhất, thay vì có ánh xạ kép trước cho phiên bản chính, sau đó đến từng bản sao độc lập, 'cục bộ'.
JustinC

1
Có thể có lý do chính trị hoặc kinh tế tại sao một trong hai bên ngần ngại từ bỏ quyền kiểm soát hoặc cấp quyền truy cập, nhưng nếu mục tiêu là làm việc cùng nhau, đồng thời, không bên nào có hiệu lực mà không cần đàm phán trước. Ví dụ. người phụ trách và chăm sóc chủ, các tranh chấp về chủ được giải quyết như thế nào và bạn sẽ chuyển quyền kiểm soát từ chủ trở lại khách hàng như thế nào (nếu bạn là công ty ký hợp đồng duy trì và kiểm soát chủ).
JustinC

@JustinC - Tôi nghe bạn. Một trong những dự án của tôi có một nửa FTE chỉ giữ hai kho lưu trữ khiếm khuyết đồng bộ.
MathAttack

0

Khách hàng của bạn chắc chắn nên được hướng dẫn về cách mọi thứ được thiết lập, nó phải là một yêu cầu để đăng xuất trong giai đoạn đầu tiên. Bạn nên đẩy lùi việc cho phép khách hàng của bạn chỉnh sửa trực tiếp mọi thứ, anh ta nên điền vào yêu cầu thay đổi được đưa vào hệ thống theo dõi vấn đề của bạn và ưu tiên với phần còn lại của công việc. Tùy thuộc vào bạn và khách hàng của bạn để quyết định những yêu cầu nằm ngoài phạm vi của hợp đồng. Làm thế nào điều này xảy ra nên được thiết kế trong một số loại công việc / tài liệu quản lý thay đổi, nếu không tồn tại, tôi khuyên bạn nên tạo một cái và khiến khách hàng đồng ý rằng đây là quá trình anh ta có thể thay đổi mọi thứ và có được điều này viết. Nếu không, bạn không thể làm gì khác ngoài cầu nguyện, không có gì sai cả.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.