Làm thế nào để bạn quản lý các yêu cầu tính năng và thay đổi phần mềm? [đóng cửa]


21

Tôi là một Kỹ sư phần mềm và trong vài năm qua, tôi đã trở thành người quản lý dự án phần mềm thực tế đơn giản chỉ vì không có ai. Vì vậy, để giữ sự tỉnh táo của chúng tôi trong bộ phận R & D / Engineering, khách hàng đã quen với việc đến với tôi với các yêu cầu của họ. Tôi không có kinh nghiệm trong lĩnh vực này vì vậy đây là lần đầu tiên tôi đóng vai trò là người quản lý dự án cho các dự án phần mềm. Tôi đã quản lý những thứ khác nhưng không phải phần mềm.

Vì vậy, làm thế nào để bạn quản lý các dự án phần mềm và đánh dấu các ưu tiên? Yêu cầu đến trong khoảng thời gian không thường xuyên vì vậy chúng tôi rất có thể đang làm việc gì đó cho người khác và sau đó một người khác đến với một công việc "vội vàng" cần làm việc. Là dễ dàng hơn khi chỉ nói First Come, First Serve hay đó là người có nhiều tiền nhất?



1
và có lẽ điều này cũng vậy: lập trình
viên.stackexchange.com/questions/3747/ trên

1
Tôi sử dụng khẩu hiệu của Nancy Reagan: "Chỉ cần nói KHÔNG!" Nghiêm túc. Không bao giờ cam kết với bất cứ điều gì tại chỗ. Đó là một trong những cách mà các kỹ sư phần mềm gặp rắc rối lớn. Điều rất quan trọng là phải chống lại việc đưa ra các cam kết thông thường hoặc thậm chí ước tính xem liệu một cái gì đó là "cứng" hay "dễ dàng". Luôn luôn trì hoãn quyết định và sau đó đưa ra một số lời khuyên tuyệt vời sẽ xuất hiện trong các câu trả lời. Danh tiếng của bạn phụ thuộc vào việc có thể thực hiện các cam kết của bạn-- và nó sẽ bị suy giảm nghiêm trọng ngay khi bạn thực hiện quá nhiều cam kết.
Angelo

Câu trả lời:


21

Tôi thấy rằng càng có nhiều khách hàng phàn nàn về yêu cầu của họ khẩn cấp như thế nào, trừ khi họ cũng là nhà phát triển theo cách riêng của họ, đó thường là một dấu hiệu tốt cho thấy yêu cầu đó không khẩn cấp. Một trong những giáo sư của tôi ở trường đại học luôn nói với chúng tôi rằng đừng để sự khẩn cấp làm gián đoạn những điều quan trọng.

Tôi thường phân loại các yêu cầu theo thứ tự này (YMMV):

  1. Các vấn đề liên quan đến nâng cấp hoặc di chuyển gần đây (quan trọng nhất).
  2. Sửa lỗi bảo mật.
  3. Chức năng bị hỏng của hệ thống hiện có.
  4. Chức năng bị hỏng trong các tính năng RC và beta.
  5. Yêu cầu tính năng trả phí.
  6. Yêu cầu tính năng R & D từ một phần lớn của cơ sở người dùng.
  7. Yêu cầu tính năng R & D từ chỉ một hoặc hai người dùng.

Điều cuối cùng này thực sự tốn nhiều thời gian hơn vì chúng có xu hướng là những yêu cầu "cấp bách, tôi cần nó ngày hôm qua". Trong thực tế, người dùng hiếm khi nghĩ hoàn toàn thông qua những gì họ thực sự cần hoặc nó sẽ hỗ trợ mô hình kinh doanh của họ như thế nào. Thông thường, các yêu cầu khẩn cấp này, một khi được gửi, cuối cùng sẽ được sử dụng một hoặc hai lần và quên đi. Và một khi bị lãng quên, họ trở thành một cơn đau đầu vô tận của các lỗ hổng bảo mật và hậu quả không lường trước được.


3
Giáo sư của bạn có thể muốn trèo xuống từ Tháp Ngà một lúc.
JeffO

6
Điều ông muốn nói là rất nhiều người đã để mọi phiền nhiễu cầu xin sự chú ý ngay lập tức của chúng tôi khiến chúng tôi không tập trung vào những điều thực sự quan trọng. Đây là một số năm trước, vì vậy ví dụ của ông là điện thoại. Bất cứ khi nào anh gặp một sinh viên, anh đều đặt điện thoại trực tiếp vào hộp thư thoại. Tôi thấy đó là một tuyên bố tuyệt vời về tính toàn vẹn và hiệu quả.
Michael J. Sabal

4
Whoah, khách hàng trả tiền có mức độ ưu tiên thấp hơn các tính năng beta ?
JBRWilkinson

12

Tôi thích Coveynguyên tắc của:

  1. QI - Quan trọng và khẩn cấp
  2. QII - Quan trọng nhưng không khẩn cấp
  3. QIII - Không quan trọng nhưng khẩn cấp
  4. QIV - Không quan trọng và không khẩn cấp

Nó đến từ đâu vậy?
Rook

First Things First (1994) là một cuốn sách tự giúp đỡ được viết bởi Stephen Covey và A. Roger và Rebecca R. Merrill en.wikipedia.org/wiki/First_Things_First_%28book%29
Adamizer

@Rook - Cũng được liệt kê trong 7 thói quen của những người có hiệu quả cao của Covey. Cuốn sách tuyệt vời
Nemi

6
  1. Thiết lập hệ thống theo dõi tính năng / lỗi / yêu cầu và có vé tập tin khách hàng / đồng nghiệp của bạn. Nếu họ không nộp vé cho nó, bạn sẽ không làm điều đó. Vé phải đủ chi tiết để có thể hành động và phải chỉ định "mức độ khẩn cấp" ("Tôi cần ngay bây giờ" so với "rất tốt để có").
  2. Đi qua vé mới và cẩn thận phạm vi chúng. Nhập chi phí trong vé bằng đô la, nhà phát triển, tài nguyên và / hoặc thời gian. Đây là điều cần thiết . Khi khách hàng của bạn thấy thứ gì đó thực sự sẽ khiến họ phải trả giá, bạn sẽ thấy những lựa chọn rất khác nhau trong lĩnh vực "cấp bách".
  3. Trên cơ sở hàng ngày, hãy tìm ra lịch trình của bạn dựa trên các vé được nộp và mức độ khẩn cấp của họ. Làm cho lịch trình hiển thị cho người khác để rõ ràng những gì bạn đang làm và tính sẵn sàng cho các yêu cầu trong tương lai.

+1 cho theo dõi vấn đề. Tôi đã phải làm điều này với đồng nghiệp trước đây. Tôi nói với họ nếu điều đó thực sự quan trọng đối với tôi phải làm, nó phải có giá trị trong 5-10 phút để họ nộp vé.
GSto

3

Tôi đã thấy các dự án mà các thay đổi yêu cầu được quản lý bởi hệ thống kiểm soát thay đổi rất nặng nề. Điều này tệ đây. Nhiều thay đổi quan trọng không xảy ra vì khách hàng không muốn gặp rắc rối khi gửi kiểm soát thay đổi, vì vậy phần mềm không phù hợp với nhu cầu của họ. Một số thay đổi nhỏ được đưa vào "dưới radar" để tránh quá trình, vì vậy phần mềm thậm chí không khớp với những gì bạn nghĩ.

Ngược lại, tôi cũng đã thấy các dự án mà người quản lý dự án nghĩ rằng "phản ứng" có nghĩa là yêu cầu các lập trình viên đáp ứng mọi yêu cầu từ người dùng, điều đó có nghĩa là bạn không bao giờ thực hiện bất kỳ phát triển cốt lõi nào và mã của bạn trở thành một mớ rắc rối lớn khó sử dụng hack. Về cơ bản, bây giờ bạn không có bất kỳ nhà phát triển nào, bạn có một đội ngũ kỹ sư bán hàng quá chất lượng.

Vì vậy, người ta có thể hy vọng có một tình huống giữa hai cực này hoạt động tốt và tôi hy vọng rằng những gì tốt nhất cho bạn là cả sự lựa chọn cá nhân và nằm. Chắc chắn có giá trị trong việc nắm bắt chi phí của mỗi thay đổi. Trong một khung như Scrum, bạn có thể biểu thị chi phí theo điểm câu chuyện và nhóm có thể đánh đổi công việc họ làm trong mỗi lần lặp so với tổng nỗ lực có sẵn. Nếu bạn có người quản lý sản phẩm, bạn có thể yêu cầu người đó định lượng lợi ích mong đợi của yêu cầu thay đổi hoặc tính năng. Điều này thường được thực hiện dưới dạng doanh thu được bảo vệ (có bao nhiêu khách hàng sẽ rời đi nếu bạn không làm điều này) và thu hút doanh thu (có bao nhiêu khách hàng sẽ đến nếu bạn làm điều này). Điều đó có thể giúp ưu tiên, nhưng cũng có thể chỉ phản ánh sự thiên vị hoặc sở thích cá nhân của người quản lý sản phẩm.


2

Đây là một vài suy nghĩ ...

Có rất nhiều phần mềm trên thị trường giúp bạn, http://www.fogcalet.com/ với Fogormsz, GeneXus USA với XPM http://www.genexususa.com/xpm , v.v.

Nó giống như một nghệ thuật để cân bằng các yêu cầu tính năng mới với sửa lỗi và với ý tưởng của riêng bạn. Bạn phải có thức ăn cho mùa đông tới, nhưng hôm nay bạn cũng phải ăn.

Bạn có thời gian, tài nguyên và phạm vi, tận dụng tốt nhất của nó.

Henry Ford cũng từng nói một cách nổi tiếng, nếu tôi lắng nghe khách hàng, tôi đã cho họ một con ngựa nhanh hơn "...

Cá nhân: hãy năng động, đừng đặt quy tắc như những gì bạn đã nói ... và hãy cẩn thận với quy tắc của người khác ... họ có thể làm việc tốt trong ngữ cảnh của họ, nhưng không phải trong quy tắc của bạn.


2

Những gì chúng tôi đã kết thúc là chúng tôi sẽ có các cuộc họp kỹ thuật / bán hàng hai tháng một lần để thảo luận về các dự án hiện tại và các yêu cầu tính năng sắp tới hoặc trong tương lai. Các kỹ sư bán hàng sẽ trở thành người quản lý dự án và ít nhất họ sẽ đồng điệu với các dịch vụ sản phẩm mới nhất. Trong quá khứ, thật dễ dàng để vượt qua nó cho Kỹ thuật và quên nó đi. Điều này có thể sẽ giảm bớt tải mà một kỹ sư phần mềm phải làm và đưa trách nhiệm bán hàng và quản lý để sử dụng thời gian của chúng ta một cách khôn ngoan.


1

Công ty tôi làm việc sử dụng hai ứng dụng chính, một công cụ dựa trên web có tên là JIRA để xử lý các khía cạnh liên quan đến dự án và hệ thống bàn trợ giúp của chúng tôi để xử lý yêu cầu thay đổi thông qua chức năng rfc của nó


1

Các câu trả lời tôi thấy cho đến nay là tốt. Một điều mà tôi sẽ đánh vần cụ thể là bạn sẽ phải giỏi nói "Không" với một số yêu cầu.

Nếu bạn cho phép khách hàng đặt mức độ khẩn cấp, thì hầu như sẽ luôn là "Cao" (hoặc cao hơn).

Bạn (hoặc chính bạn hoặc một nhóm, tùy thuộc vào thiết lập của bạn) sẽ cần đánh giá các yêu cầu này và ưu tiên chúng dựa trên các tiêu chí của riêng bạn.

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.