Làm thế nào để bắt đầu một dự án phát triển khi có quá nhiều bên liên quan tiềm năng


15

Tôi vừa nhận một công việc mới tại một trường đại học với tư cách là nhà phát triển ứng dụng Web (duy nhất).

Các trường đại học có một số khác nhau nhưng tất cả các hệ thống di sản được mã hóa khá xấu. Chủ yếu được xây dựng trong PHP họ xử lý các vấn đề như tham dự, kết quả thi, chấm điểm, v.v.

Công việc đầu tiên của tôi là xây dựng một hệ thống kết hợp nhiều dữ liệu này, hiện đang nghỉ ngơi trong các cơ sở dữ liệu khác nhau mà không có bất kỳ loại API thân thiện nào để loại bỏ nó (các hệ thống hiện tại được mã hóa bằng vanilla PHP mà không tách rời dữ liệu và chế độ xem) với một nền tảng mới để ghi lại thông tin mục vụ về sinh viên và trình bày nó cho gia sư và nhân viên cấp cao một cách hữu ích để họ có thể phản ứng nhanh với các vấn đề với sinh viên.

Trong cuộc họp đầu tiên của chúng tôi, có 18 người! Không có nhà lãnh đạo rõ ràng hoặc tiếng nói đại diện cho đa số. Không có khách hàng nhận dạng . Cuộc họp xoay quanh các ý tưởng triển khai chi tiết về các tính năng nhỏ từ các trưởng khoa đến các cuộc tranh luận về việc chúng ta có nên sử dụng bảng tính Excel hay không cho nhập dữ liệu!

Như bạn có thể tưởng tượng đầu của tôi đã quay cuồng vào cuối. Tôi thực sự đã có rất nhiều ý tưởng hay nhưng tôi không thể nghe được. Đây là một vai trò rất mới đối với tôi, trước khi tôi là thành viên của một nhóm phát triển trong một công ty tiếp thị. Chúng tôi đã có các vai trò được xác định rất rõ: Quản lý dự án, Khách hàng, Nhà thiết kế, Nhà phát triển.

Tôi muốn biết liệu bất kỳ nhà phát triển hoặc nhà quản lý dày dạn nào có thể cung cấp cho tôi một số gợi ý về cách tôi có thể đưa các đồng nghiệp của mình vào một cái gì đó tương tự như một nhóm dự án. Là nhanh nhẹn để đi? Làm thế nào bạn sẽ tiếp cận xử lý tất cả các giọng nói khác nhau? Rõ ràng là một số quy trình cần được đưa vào vị trí rất nhanh, tôi chỉ không chắc đó là gì.


8
Nếu bạn là nhà phát triển duy nhất, 17 người khác trong cuộc họp là ai?
pdr

1
Câu hỏi hay. Hiệu trưởng của trường, nhiều thành viên của đội ngũ giảng viên (thậm chí cả giáo viên thể dục cũng ở đó) và rất nhiều người có tên viết tắt.
Matt Harrison

1
@MattHarrison: nhưng họ có điểm gì chung với ứng dụng web của bạn? Họ có phải là người dùng tiềm năng không? Họ có duy trì những hệ thống di sản mà bạn đề cập? Bạn nên làm rõ điều đó để bạn chắc chắn rằng bạn biết bạn sẽ yêu cầu ai và bạn có thể bỏ qua ai.
Doc Brown

1
@DocBrown Tôi xin lỗi có lẽ tôi đã không rõ ràng. Tất cả họ sẽ là người dùng tương lai của hệ thống. Ứng dụng này sẽ được liên thông đại học và được sử dụng bởi hơn 3000 người. Tôi nghĩ những gì đã xảy ra ở đây là những người mời mọi người và cuộc họp đã trở thành một rạp xiếc. Những gì tôi sẽ làm là nhấn mạnh sự cần thiết phải có sự tham gia của các bên liên quan nhỏ hơn.
Matt Harrison

5
@Để downvoter ẩn danh / gần hơn: điều này có vẻ quá cục bộ ngay từ cái nhìn đầu tiên. Nhưng tôi nghĩ rằng câu hỏi thực sự là một câu hỏi phát triển được quan tâm chung: "làm thế nào để bắt đầu một dự án phát triển khi có quá nhiều bên liên quan tiềm năng" và những câu hỏi đó là chủ đề IMHO ở đây.
Doc Brown

Câu trả lời:


26

Tôi không mong đợi bất kỳ "quy trình phát triển nhanh" nào ở đây là giải pháp cho vấn đề hiện tại của bạn. Điều đầu tiên cho bạn nên là: làm rõ nhiệm vụ của bạn . Điều đó có nghĩa là:

  • làm rõ trách nhiệm của bạn là gì
  • làm rõ trách nhiệm của các bên liên quan khác là gì
  • xác định ai chịu trách nhiệm cho từng hệ thống cũ
  • nếu không có ứng dụng khách nào cho ứng dụng web của bạn, hãy tìm một người sẽ sử dụng nó trong tương lai và xin phép kết hợp anh ta với tư cách là người dùng đại diện của hệ thống của bạn (một người bạn có thể thảo luận các yêu cầu với)
  • nếu có các bên liên quan khác nhau với các mục tiêu khác nhau, hãy thu thập các yêu cầu của họ (ví dụ: bằng cách phỏng vấn từng người một, không phải 18 người cùng một lúc trong một phòng). Viết kết quả vào danh sách. Sau đó, bắt đầu ưu tiên.
  • viết ra một lộ trình (bức tranh lớn) và một thông số nhỏ để phát hành 0.1 và khiến sếp của bạn cũng như khách hàng đại diện đồng ý với nó một cách chính thức
  • EDIT: xem bình luận của GlenH7

Điều này có thể mất một lúc, bạn có thể sẽ không viết nhiều mã ở giai đoạn này của dự án. Trong tình huống như vậy, trước tiên bạn nên thực hiện một số "yêu cầu kỹ thuật". Nhưng bắt đầu nhỏ, nghĩ lớn. Khi bạn đã phát triển bản phát hành đầu tiên của mình, bạn sẽ có thứ gì đó để hiển thị, thảo luận lại các yêu cầu với các bên liên quan, v.v.


Lời khuyên tuyệt vời. Cảm ơn bạn! Tôi có thể chỉ làm rõ; khi bạn nói 'xóa trách nhiệm của bạn', bạn có nghĩa là làm cho họ rõ ràng, hoặc xóa chúng như để loại bỏ chúng? Xin lỗi, tôi là người Anh nên có lẽ đó là một thứ tiếng Anh Mỹ.
Matt Harrison

1
@MattHarrison: hy vọng bản chỉnh sửa của tôi làm cho điều này rõ ràng hơn - mặc dù đôi khi nó cũng có thể là một ý tưởng tốt để loại bỏ một số trách nhiệm ;-)
Doc Brown

4
Câu trả lời tuyệt vời. Mục duy nhất tôi muốn thêm là xác định một bên liên quan chính hoặc điều hành. Người này có thẩm quyền cuối cùng trong việc xác định mức độ ưu tiên và phạm vi. Có nhiều cách khác nhau để đạt được điều đó, nhưng ai đó có trách nhiệm cuối cùng trong dự án. Và vâng, hãy thoải mái đánh cắp nhận xét này để thêm vào câu trả lời của bạn nếu bạn muốn. :-)

6

Tách những người thực sự muốn dự án này hoạt động từ đàn.

Do nhiều chính trị, một người nào đó đã kết hợp cuộc họp này với một danh sách những người tham dự nơi thành viên được xác định bởi ai sẽ là người khó chịu nhất nếu tôi không mời họ. Nó xảy ra. Mục tiêu này đã được thực hiện đầy đủ nhưng là nhà phát triển, bạn thấy rằng không có gì được quyết định. Không ai được chỉ định làm gì. Nếu bạn may mắn, họ đã sắp xếp được cuộc họp tiếp theo hoặc thần cấm, họ sẽ tổ chức một cuộc họp tái diễn vào thứ ba thứ 3 mỗi tháng.

Tiếp theo sẽ đến việc thành lập các ủy ban, tiểu ban và lực lượng đặc nhiệm. Đây là betteer, nhưng bạn sẽ thấy tất cả đều vô giá trị như nhau.

Cuối cùng, bạn sẽ tìm ra ai thực sự quan tâm đến dự án này. Ai thực sự muốn đặt thời gian để làm điều đó đúng. Hy vọng, người này sẽ có người giám sát cho phép họ có thời gian để làm việc này và không chỉ biến nó thành một mục khác trong danh sách việc cần làm đã kéo dài của họ. Tìm những người này càng sớm càng tốt! Giúp họ quản lý kỳ vọng của sếp và nhận được số tiền cam kết đã thỏa thuận.

Nhận được một cái gì đó trước mặt nhiều người trong nhóm ban đầu thậm chí sẽ bận tâm để trở lại. Tất cả họ có thể là những người thông minh và / hoặc có học thức nhưng họ sẽ không đọc một loạt các thông số kỹ thuật. Họ sẽ thích một số thứ, ghét những thứ khác và muốn nhiều hơn nữa. Sẽ không hại khi viết ra các đề xuất, nhưng hãy cố gắng để bên đó theo dõi với một số giao diện trong trò chơi. Đừng hứa sẽ làm mọi thứ. Chỉ cần giải quyết những gì có thể được thực hiện trong tương lai gần.

Nếu bạn thường xuyên phải tiếp xúc với hơn 5 người, thì đó là vì một số người quản lý đã khiến một số người của họ tham gia, những người không thực sự muốn ở đó.


1
+1 để làm nổi bật các khía cạnh chính trị của một tình huống như vậy.
Doc Brown

4

Hãy đưa ra một danh sách các ý tưởng mà bạn nghĩ sẽ củng cố / cải thiện các hệ thống hiện có dựa trên các quan sát của bạn và "nhu cầu" của chúng và đảm bảo bạn tập trung vào nơi bạn có thể đạt được lợi ích thực tế có thể nhìn thấy. Bao gồm trong danh sách đó mỗi ý tưởng bạn nghĩ sẽ hữu ích, cũng như bất kỳ đề xuất "hợp lý" nổi bật nào từ những người không phải là nhà phát triển.

Xây dựng một danh sách tính năng của những thứ "nên" được bao gồm trong các nỗ lực phát triển của bạn. Cung cấp cho mỗi thành viên quyền biểu quyết, có thể dưới dạng "ngôi sao dính" và tìm hiểu xem toàn bộ thực sự muốn gì của mỗi thành viên đặt các ngôi sao bên cạnh những gì họ cho là quan trọng. Một số người có thể kết thúc với nhiều ngôi sao hơn nếu họ ký séc, có tiếng nói cuối cùng, v.v. Sau đó, hy vọng bạn và mọi người khác sẽ thấy điều gì là quan trọng đối với toàn bộ, và hy vọng họ sẽ đồng ý với mức độ ưu tiên. sau đó chuyển thành lộ trình

1). Khảo sát nhóm - Tìm hiểu những gì mỗi thành viên cho là quan trọng / cần thiết / ưu tiên hàng đầu

2). Nhanh chóng lấy thứ gì đó ra khỏi đó - Đừng cố gắng giải quyết tất cả các vấn đề cùng một lúc, lấy chức năng "tối thiểu trần" ra khỏi đó và để chúng chấp thuận, sau đó cùng tiến lên dựa trên phản hồi của người dùng.

3). Sử dụng phản hồi của họ và phản hồi của người dùng khác để hướng dẫn quy trình phát triển

(Xây dựng, Đánh giá Phản hồi, Xây dựng, Đánh giá Phản hồi) Rửa sạch và Lặp lại.

Ngoài ra, bạn có thể xem xét đưa "điểm nỗ lực" hoặc số giờ ước tính để hoàn thành .. điều đó cũng có thể hỗ trợ cho việc ưu tiên.


1
+1, đó là cách để lái xe khi bạn di chuyển :-)
Doc Brown

1
+1 cho cái này, mặc dù tôi vẫn nói rõ hơn rằng bạn cần cảnh giác với một "hệ thống xấu" thực sự làm những gì nó cần làm. Ưu tiên theo cách mà bạn không sửa chữa những thứ không bị hỏng, tập trung vào nơi bạn có thể đạt được lợi ích thực tế có thể nhìn thấy.
Joris Timmermans

@MadKeithV, đã đồng ý .. "Tập trung vào nơi bạn có thể đạt được lợi ích thực tế có thể nhìn thấy", nhận xét cập nhật để đưa vào tuyên bố đó.
hanzolo

2

Thử thách đầu tiên của bạn là xác định sự cần thiết của dự án này. Tổ chức một cuộc họp khác với tất cả những người đó và yêu cầu họ viết ra những vấn đề cần giải quyết. Đừng để họ nói về nhiều cách mà dự án này sẽ là giải pháp. Buộc họ phải thực sự xác định nhu cầu / vấn đề.

Một cách để làm điều này là yêu cầu từng cá nhân ghi lại những nhu cầu đó trên ghi chú dán - một ý tưởng cho mỗi lần dán. Sau đó chạy Sơ đồ mối quan hệ để giúp họ nhóm các ý tưởng khác nhau đó vào các nhu cầu cụ thể. Cuối cùng, làm cho họ bỏ phiếu ( Đa phiếu ) để bạn có thể thấy những nhu cầu lớn nhất.

Agile nhắc nhở chúng ta giải quyết tính năng có giá trị khách hàng nhất trước tiên. Bắt đầu với nhu cầu lớn nhất và sau đó tiếp tục chia nhỏ mục đó cho đến khi bạn có phần nhỏ đầu tiên mà bạn thực sự có thể làm trong một khoảng thời gian ngắn.


0

KISS - Thực hiện một hành trình. Cảm ơn tất cả mọi người đã đến, xem xét nó, làm điều đó. Theo dõi bên sẽ chậm lại nếu bạn giải quyết nó bằng cách chia sẻ mối quan tâm của họ và yêu cầu họ ở lại SAU cuộc họp. Đưa ra quyết định bằng cách bỏ phiếu nơi có tranh cãi để giữ hạnh phúc nhất. Động lực hướng tới việc tham gia vào bất kỳ hệ thống nào có liên quan trực tiếp đến niềm tin của cá nhân vào các phương pháp của 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.