Trong bài viết này, tôi sẽ chia sẻ kinh nghiệm của mình trong việc lựa chọn các ý tưởng để phát triển chức năng của các sản phẩm của chúng tôi và cho bạn biết cách giữ các vectơ phát triển chính.
Chúng tôi đang phát triển một hệ thống thanh toán tự động (ACS) - thanh toán. Thuật ngữ
Tuổi thọ của sản phẩm của chúng tôi là 14 năm. Trong thời gian này, hệ thống đã chuyển từ các phiên bản đầu tiên của máy đánh giá công nghiệp thành một tổ hợp mô-đun bao gồm 18 sản phẩm bổ sung cho nhau. Một trong những khía cạnh quan trọng nhất của tuổi thọ cho các chương trình là sự phát triển liên tục. Và ý tưởng là cần thiết cho sự phát triển.
Ý tưởng
nguồn
Có 5 nguồn:
- Người bạn chính của nhà phát triển hệ thống thông tin doanh nghiệp là khách hàng. Và khách hàng là hình ảnh tập thể của những người ra quyết định, nhà tài trợ dự án, chủ sở hữu và người thực hiện các quy trình, chuyên gia CNTT nội bộ, người dùng thông thường và một số lượng lớn những người quan tâm ở các mức độ khác nhau. Điều quan trọng đối với chúng tôi là mỗi đại diện của khách hàng đều có khả năng là nhà cung cấp ý tưởng. Trong trường hợp xấu nhất, chúng tôi chỉ nhận được phản hồi tiêu cực về các vấn đề trong hệ thống. Tốt nhất, có một người ở phía khách hàng là nguồn ý tưởng liên tục để cải tiến, cung cấp thông tin có cấu trúc về nhu cầu của khách hàng.
- Của chúng tôi người bán và người quản lý tài khoản là nguồn ý tưởng cải tiến quan trọng thứ hai. Họ giao tiếp rất nhiều và tích cực với các đại diện trong ngành, nhận các yêu cầu trực tiếp về chức năng thanh toán từ các khách hàng tiềm năng. Người bán và tài khoản phải nhận thức được tất cả những thay đổi quan trọng trong chức năng của họ và các bản cập nhật phần mềm mới nhất của đối thủ cạnh tranh, có thể biện minh cho ưu và nhược điểm của các giải pháp khác nhau. Chính những nhân viên này của chúng tôi là những người đầu tiên cảm nhận được liệu một số tính năng thanh toán có trở thành tiêu chuẩn trên thực tế hay không, nếu không có tính năng này thì phần mềm không thể được coi là hoàn chỉnh.
- Chủ sở hữu sản phẩm là một trong những nhà quản lý hàng đầu của chúng tôi hoặc một nhà quản lý dự án rất giàu kinh nghiệm. Ghi nhớ các mục tiêu chiến lược của công ty và điều chỉnh các kế hoạch phát triển sản phẩm phù hợp với chúng.
- Kiến trúc sư, một người hiểu rõ khả năng và hạn chế của các giải pháp công nghệ được lựa chọn/sử dụng và tác động của chúng đối với quá trình phát triển sản phẩm.
Nhóm phát triển và thử nghiệm. Những người trực tiếp tham gia phát triển sản phẩm.
Phân loại lượt truy cập
Chúng tôi nhận dữ liệu thô từ các nguồn - thư, vé, yêu cầu bằng miệng. Tất cả
kháng cáo được phân loại:
- Tham vấn với nghĩa "Làm thế nào?", "Làm thế nào?", "Tại sao nó không hoạt động?", "Tôi không hiểu...". Các cuộc gọi thuộc loại này sẽ chuyển đến Đường dây hỗ trợ cấp 1. Có thể đào tạo lại cuộc tư vấn thành các loại khiếu nại khác.
- Sự cố với ý nghĩa "Không hoạt động" và "Lỗi". Được xử lý bởi 2 và 3 dòng hỗ trợ. Nếu cần nhanh chóng sửa chữa và phát hành một bản vá, nó có thể được chuyển trực tiếp từ bộ phận hỗ trợ sang bộ phận phát triển. Có thể phân loại lại thành yêu cầu thay đổi và gửi đến backlog.
- Yêu cầu thay đổi và phát triển. Tham gia vào sản phẩm tồn đọng, bỏ qua các Dòng hỗ trợ. Nhưng đối với họ có một quy trình xử lý riêng.
Có số liệu thống kê về lượt truy cập như vậy - ngay sau khi phát hành, số lượt truy cập tăng 10-15% trong một thời gian ngắn. Ngoài ra còn có các cuộc gọi bùng nổ khi một khách hàng mới với số lượng lớn người dùng đến với các dịch vụ đám mây của chúng tôi. Mọi người đang học cách sử dụng các tính năng phần mềm mới, họ cần lời khuyên. Ngay cả một khách hàng nhỏ khi bắt đầu làm việc trong hệ thống cũng dễ dàng đốt cháy hơn 100 giờ tư vấn mỗi tháng. Do đó, khi kết nối một khách hàng mới, chúng tôi luôn dành thời gian để tư vấn ban đầu. Thường thì chúng tôi thậm chí chọn ra một chuyên gia cụ thể. Tất nhiên, chi phí thuê nhà không trả hết những chi phí lao động này, nhưng theo thời gian, tình hình sẽ chững lại. Thời gian thích ứng thường kéo dài từ 1 đến 3 tháng, sau đó nhu cầu tư vấn giảm đi đáng kể.
Trước đây, chúng tôi đã sử dụng các giải pháp tự viết để lưu trữ các cuộc gọi. Nhưng dần dần chuyển sang các sản phẩm của Atlassian. Đầu tiên, quá trình phát triển được chuyển giao để giúp làm việc trên Agile dễ dàng hơn, sau đó là hỗ trợ. Giờ đây, tất cả các quy trình quan trọng đều có trong Jira SD, ngoài ra, chúng còn được cung cấp nhiều plugin khác nhau cho Jira, cộng với Confluence. Các giải pháp tự viết vẫn chỉ dành cho các quy trình không quan trọng đối với các hoạt động của công ty. Hóa ra các nhiệm vụ của chúng tôi hiện là từ đầu đến cuối, chúng có thể được chuyển giữa bộ phận hỗ trợ và phát triển mà không cần chuyển từ hệ thống này sang hệ thống khác.
Từ gói này, chúng tôi có thể lấy dữ liệu về tất cả các nhiệm vụ, chi phí lao động theo kế hoạch và thực tế, sử dụng các tùy chọn thanh toán khác nhau cho khách hàng và tạo tài liệu cho các nhu cầu nội bộ cũng như báo cáo cho khách hàng.
Xử lý yêu cầu thay đổi
Thông thường, những yêu cầu này ở dạng yêu cầu tính năng. Nhà phân tích của chúng tôi nghiên cứu yêu cầu, tạo thông số kỹ thuật và TOR cấp cao nhất. Chuyển thông số kỹ thuật và TOR cho người đã gửi yêu cầu này để phê duyệt - chúng tôi phải đảm bảo rằng chúng tôi nói cùng một ngôn ngữ với khách hàng.
Sau khi nhận được xác nhận từ khách hàng rằng chúng tôi đã hiểu chính xác về nhau, nhà phân tích sẽ nhập yêu cầu vào sản phẩm tồn đọng.
Quản lý tính năng sản phẩm
Công việc tồn đọng tích lũy các yêu cầu thay đổi và phát triển nhận được. Sáu tháng một lần, hội đồng kỹ thuật, bao gồm giám đốc, trưởng bộ phận bảo trì, phát triển, bán hàng và kiến trúc sư hệ thống, họp. Ở dạng thảo luận, hội đồng phân tích và ưu tiên các ứng dụng từ hồ sơ tồn đọng và đồng ý về 5 nhiệm vụ phát triển để triển khai trong phiên bản tiếp theo.
Trên thực tế, hội đồng kỹ thuật đáp ứng các yêu cầu của ngành và thị trường, xem xét các nhu cầu được ghi trong đơn đăng ký. Mọi thứ ít liên quan vẫn tồn đọng và không đạt được sự phát triển.
Phân loại Yêu cầu Thay đổi và Tài chính
Phát triển là tốn kém. Do đó, chúng tôi sẽ ngay lập tức cho bạn biết những lựa chọn mà chúng tôi có thể có nếu yêu cầu thay đổi đến từ khách hàng chứ không phải nhân viên.
Yêu cầu thay đổi được phân loại như sau: nhu cầu đặc thù của ngành hoặc đặc điểm riêng của doanh nghiệp; một số lượng đáng kể các chức năng mới hoặc một bản sửa lỗi nhỏ. Các bản sửa lỗi nhỏ và các yêu cầu riêng lẻ được xử lý mà không có bất kỳ sự rườm rà nào. Các yêu cầu cá nhân được tính toán và thực hiện cho một khách hàng cụ thể như một phần của dự án làm việc với anh ta.
Nếu đây không phải là nhu cầu lớn của ngành và số lượng chức năng lớn, thì có thể đưa ra quyết định phát triển một mô-đun riêng biệt mới sẽ được bán cùng với chức năng chính. Nếu nhận được yêu cầu như vậy từ khách hàng, chúng tôi có thể trang trải chi phí phát triển mô-đun, cung cấp cho khách hàng mô-đun miễn phí hoặc thanh toán một phần và đưa mô-đun vào miền công cộng để bán. Trong tình huống như vậy, khách hàng đảm nhận một phần gánh nặng về phương pháp và trên thực tế, tiến hành triển khai thí điểm mô-đun.
Nếu đây là nhu cầu lớn của ngành, thì có thể đưa ra quyết định đưa chức năng mới vào sản phẩm cơ bản. Chi phí trong trường hợp này hoàn toàn do chúng tôi chịu và chức năng mới xuất hiện trong phiên bản hiện tại của chương trình.
Khách hàng cũ được cung cấp một bản cập nhật.
Cũng có thể một số khách hàng có nhu cầu giống nhau nhưng không kéo theo sản phẩm đại chúng. Trong trường hợp này, chúng tôi có thể gửi thông số kỹ thuật cho những khách hàng này và đề nghị chia sẻ chi phí phát triển giữa họ. Cuối cùng, mọi người đều thắng: khách hàng nhận được việc triển khai chức năng với chi phí thấp, chúng tôi làm phong phú sản phẩm, sau một thời gian, những người tham gia thị trường khác cũng có thể nhận được chức năng để họ sử dụng.
DevOps
Sự phát triển chuẩn bị hai bản phát hành chính mỗi năm. Trong mỗi lần phát hành, thời gian được dành cho việc thực hiện 5 nhiệm vụ nhận được từ hội đồng kỹ thuật. Vì vậy, đằng sau doanh thu, chúng tôi không bao giờ quên sự phát triển của sản phẩm.
Mỗi bản phát hành đều trải qua một bộ thử nghiệm và tài liệu thích hợp. Hơn nữa, bản phát hành này được cài đặt trong môi trường thử nghiệm của khách hàng tương ứng, người này sẽ kiểm tra mọi thứ một cách tỉ mỉ và chỉ sau đó bản phát hành mới được chuyển sang sản xuất.
Ngoài hệ thống phát hành, có một định dạng sửa lỗi nhanh chóng để khách hàng không phải sống chung với lỗi trong sáu tháng. Định dạng trung gian này sẽ cho phép bạn nhanh chóng ứng phó với các sự cố thuộc các ưu tiên hàng đầu và đáp ứng SLA đã nêu.
Tất cả những điều trên chủ yếu đúng đối với khu vực doanh nghiệp và các giải pháp tại chỗ. Đối với các dịch vụ đám mây tập trung vào phân khúc SMB, không có nhiều cơ hội như vậy để khách hàng tham gia phát triển sản phẩm. Định dạng cho thuê cho SMB thậm chí không đề xuất điều này. Thay vì yêu cầu thay đổi dưới dạng yêu cầu rõ ràng từ một bên công ty, chỉ có phản hồi và mong muốn thông thường đối với dịch vụ. Chúng tôi cố gắng lắng nghe, nhưng sản phẩm rất lớn và mong muốn của một khách hàng mang lại thứ gì đó quen thuộc từ hệ thống lịch sử cũ của mình có thể mâu thuẫn với chiến lược phát triển của toàn bộ hệ thống.
Nguồn: www.habr.com