it-swarm-vi.com

Xử lý các thông số kỹ thuật xấu / không đầy đủ / không rõ ràng?

Tôi đang làm việc trong một dự án nơi nhóm phát triển của chúng tôi có được các thông số kỹ thuật từ bộ phận kinh doanh của công ty. Cả quản lý kinh doanh và quản lý CNTT đều yêu cầu ước tính và dự kiến ​​thời hạn, như họ nên làm.

Điều tốt là các ước tính chủ yếu được thực hiện bởi các nhà phát triển thực tế, những người có thể thực hiện các tính năng cần thiết. Điều tệ hại là các thông số kỹ thuật thường quá đơn giản (hóa ra bạn để lại rất nhiều dấu hỏi trên đầu vì rất nhiều thông tin dường như bị thiếu) hoặc quá phức tạp (đến mức bạn có thể 'thậm chí hình dung nơi mọi thứ sẽ "phù hợp" trong ứng dụng). Thường xuyên hơn không, phần kinh doanh của thông số kỹ thuật là không đầy đủ hoặc không biết về những gì có thể và không thể thực hiện được (do logic kinh doanh đã triển khai trước đó).

Nhóm phát triển được đưa ra khoảng một ngày cho mỗi thông số kỹ thuật mới để đưa ra ước tính và chúng tôi cố gắng xóa những điều không chắc chắn, thường là bằng cách gặp gỡ bất cứ ai đã làm thông số kỹ thuật. Hầu hết các lần, hóa ra các nhà văn đặc tả không thực sự nghĩ về mọi thứ, và thường chỉ khi chúng ta bắt đầu thiết kế và phát triển thì chúng ta mới gặp rắc rối, vì rất nhiều thông số kỹ thuật dường như có lỗ hổng.

Làm thế nào để bạn đối phó với điều này? Bạn có hào phóng về ước tính trước?

44
eagerMoose

Nếu bạn đang tìm thấy vấn đề trong giai đoạn thiết kế, bạn có thực sự có vấn đề không?

Hãy chắc chắn rằng những người tạo ra thông số kỹ thuật không cảm thấy như họ phải làm mọi thứ trước mắt. Họ không thể nghĩ về mọi thứ và chúng ta cũng không thể. Họ cũng cần biết rằng họ không thể thực hiện toàn diện hơn trên một số tài liệu cụ thể và sau đó được thực hiện với dự án. Cách làm này cũng dẫn đến việc họ thêm mọi điều nhỏ nhặt mà họ có thể nghĩ đến vì họ 'có thể' cần nó và nếu họ không hỏi bây giờ, họ sẽ nhận được nó. Họ phải có sẵn để xem xét, kiểm tra và phê duyệt các yêu cầu của họ nhiều lần.

Đừng cố thiết kế hoặc xây dựng toàn bộ ứng dụng cùng một lúc. Bất kỳ dự án/ứng dụng nào cũng có thể được chia thành một số giai đoạn, bộ phận, mô-đun hoặc bất cứ điều gì họ muốn gọi nó. Bạn không cần phải nhanh nhẹn nếu đó không phải là điều của bạn. Bắt đầu với phần Bảo mật người dùng và đi từ đó.

Dành thời gian để ngồi xuống với những người này và tìm hiểu những gì họ thực sự muốn. Tôi rất thích có ai đó trao cho tôi thông số kỹ thuật cho phép tôi tạo toàn bộ dự án cùng một lúc, nhưng tôi sẽ làm gì trong năm rưỡi tới?

13
JeffO

Tôi sử dụng Nón không chắc chắn Nói với giọng bùng nổ

Về cơ bản bạn làm ước tính tốt nhất bạn có thể cung cấp thông tin bạn có.
[.___.

Khi bạn tiến tới mục tiêu và thắt chặt các thông số kỹ thuật, bạn có thể cập nhật ước tính của mình và thắt chặt sự không chắc chắn.

20
Martin York

Vâng, tôi rất hào phóng về ước tính. Đừng quên luật của Hofstadter

Luật của Hofstadter: Luôn mất nhiều thời gian hơn bạn mong đợi, ngay cả khi bạn tính đến Luật của Hofstadter. Từ Gôdel, Escher, Bach: Một bím tóc vàng vĩnh cửu.

9
Brian Carlton

Quá trình bạn đang mô tả là thực sự khá bình thường. Vấn đề là các loại hình kinh doanh có xu hướng nghĩ về mọi thứ theo "giai đoạn yêu cầu", sau đó là "giai đoạn thiết kế", v.v. Khi một nhóm đang tạo ra một sản phẩm, bạn thực sự cần một cách tiếp cận lặp lại. Một vài ý tưởng mà tôi tìm thấy công việc là:

  • Xác định các mục tiêu chính cho các thay đổi được đề xuất/ứng dụng mới. Đây là những liên quan đến kinh doanh mục tiê như "giảm 10% chi phí xử lý khiếu nại" hoặc "nghiên cứu thị trường chia sẻ từ các văn phòng vệ tinh của chúng tôi để sản phẩm đáp ứng nhu cầu của khách hàng tốt hơn". Nó giúp tập trung vào các yêu cầu kết thúc mở về nhu cầu thực sự là gì.
  • Thực hiện Swag ban đầu của bạn (Nghiêm túc Wild-A ** Đoán) cho các yêu cầu xấu khi chúng được viết, nhưng ghi lại những gì bạn giả định việc thực hiện sẽ là gì. Đây là phản hồi mà những người kinh doanh (và khách hàng của bạn) cần cải thiện và suy nghĩ về những điều này. Họ đang dựa vào bạn cho họ.
  • Nếu bạn có một sự lựa chọn giữa một ước tính thực sự dài và một ước tính thực sự ngắn, luôn luôn đi dài. Nó có thể sẽ gây sốc cho bất cứ ai đang yêu cầu bạn làm việc, đó là một điều tốt. Nó sẽ buộc hai bạn thảo luận về những gì họ thực sự sau đó.

Hãy nhớ ước tính đầu tiên của bạn không thể chính xác. Dựa trên các ước tính hợp lý của bạn về các yêu cầu bạn nhận được và ghi lại các giả định/diễn giải của bạn. Sẽ có nhiều yêu cầu xuất phát hơn do các lỗ bạn phát hiện ra. Điều này là bình thường.

6
Berin Loritsch

Trở nên hào phóng với các ước tính nghe có vẻ hay, nhưng nó giải quyết vấn đề gì? Nó sẽ không làm cho thông số kỹ thuật tốt hơn, nó sẽ không làm cho kế hoạch dễ dàng hơn. Nó đang nói 'nó không thể tệ hơn X', trái ngược với câu 'nó có thể là Y'. Sự thật là bạn không biết. Tìm hiểu những gì bạn có thể.

Nếu các nhà phân tích kinh doanh cần liên quan đến các nhà phát triển sớm hơn, hãy nói với họ. Một báo cáo bằng văn bản không thực sự là phương pháp tốt nhất để giao tiếp. Nếu bạn có thể có một nhà phát triển trợ giúp với việc thu thập các yêu cầu ban đầu và một nhà phân tích kinh doanh giúp phát triển và thử nghiệm, kết quả của bạn sẽ tốt hơn.

Tôi vừa mới đọc Nón không chắc chắn; đó là thứ tốt, nhưng thật dễ để hiểu sai. Quản lý có thể nhìn vào bức tranh đầu tiên và nói: 'ok, chúng tôi có các yêu cầu kinh doanh, vì vậy ước tính của bạn phải chính xác 50% theo hình nón của bạn. Nói với tôi'. Điều đó sẽ không giúp được gì.

Tương tự xe hơi: ai đó hỏi bạn một chiếc xe có giá bao nhiêu, và đưa cho bạn một tờ giấy với yêu cầu của anh ta. Tờ báo nói rằng nó nên nặng khoảng 1200kg, có bốn bánh xe và ít nhất hai cửa, nhưng có lẽ bốn, nên ngồi bốn người, và đèn pha tốt là thực sự quan trọng. Màu nên là màu xám (nhưng cũng có thể là màu đen?).

Bạn có thể nói $ 25K, và nếu sau đó anh ta muốn có một chiếc Range Rover hoàn toàn mới, bạn sẽ bị lừa. Điều đó không làm cho nó chính xác hơn, hoặc hữu ích hơn để nói rằng nó có giá 100 nghìn đô la. Anh ta có thể chỉ cần một chiếc Prius đã được sử dụng (xin lỗi, sở hữu trước). Nếu bạn không có thời gian để tìm hiểu cái nào, bạn sẽ không bao giờ biết.

3
Jaap

Hầu hết các lần, hóa ra các nhà văn đặc tả không thực sự nghĩ về mọi thứ, và thường chỉ khi chúng ta bắt đầu thiết kế và phát triển thì chúng ta mới gặp rắc rối, vì rất nhiều thông số kỹ thuật dường như có lỗ hổng.

Việc sử dụng most là không chính xác.

Người viết đặc tả không thể nghĩ mọi thứ thông qua. Giai đoạn = Stage. Nếu họ nghĩ mọi thứ thông qua, họ sẽ biết có bao nhiêu dòng mã để viết và dòng mã nào là chính xác.

Vì thông số kỹ thuật phải không chính xác, bạn không thể làm gì nhiều về điều đó.

cuối cùng gặp rắc rối là vấn đề.

Cả quản lý kinh doanh và quản lý CNTT đều yêu cầu ước tính và dự kiến ​​thời hạn, như họ nên làm.

Có lẽ không. Ước tính tổng thể và thời hạn không phải là những điều hữu ích nhất.

Do đó sự phát triển của các phương pháp Agile.

Vấn đề là đây. Tất cả các ước tính dựa trên thông số kỹ thuật phải có lỗi. Họ chỉ đúng bởi may mắn. Một nửa thời gian, ước tính là cách dưới và một nửa thời gian ước tính là cách. Đây là một kết quả hợp lý của việc cố gắng dự đoán tương lai với thông tin không đầy đủ.

Vì nó phải xảy ra, bạn không nên gặp rắc rối khi bạn sai. Bạn phải sai. Và bạn phải nhất quán và ngẫu nhiên sai. Nếu không, bạn đang làm mờ các con số.

2
S.Lott

Bạn nên giải thích cho ban quản lý rằng với các thông số kỹ thuật mơ hồ có mức độ tin cậy thấp trong ước tính. tức là bạn ước tính có thể thay đổi 30% hoặc 40% hoặc 50% hoặc bất cứ điều gì bạn nghĩ. Vì vậy, nếu một cái gì đó được ước tính là 2 ngày mà thực sự là một phạm vi từ 2-3 ngày.
[.___.] Sau đó tạo đăng ký phát hành dự án (có thể trên wiki hoặc Jira, v.v.). Tạo tất cả các câu hỏi của bạn dưới dạng các vấn đề và khiến doanh nghiệp trả lời câu hỏi của bạn. Chừng nào một vấn đề vẫn chưa được giải quyết thì việc ước tính vẫn không chắc chắn. Nếu có thể hãy nhờ một nhà phân tích kinh doanh làm ống dẫn để tạo điều kiện thuận lợi cho việc này và đưa ra những yêu cầu tốt hơn. Yêu cầu nhóm thử nghiệm của bạn xem xét các thông số kỹ thuật vì chúng phải tạo ra các trường hợp thử nghiệm so với thông số kỹ thuật. Thông thường sự tham gia của họ có thể dẫn đến việc viết thông số kỹ thuật tốt hơn. Báo cáo hàng ngày/hàng tuần để quản lý có bao nhiêu vấn đề chưa được giải quyết. Càng được giải quyết, ước tính của bạn sẽ càng tốt. Luôn trình bày các số liệu cho quản lý vì các số liệu khiến họ suy nghĩ khách quan và cũng đặt bạn vào thế mạnh.
[.___ Có nhiều hội thảo với các doanh nghiệp vừa và nhỏ cố gắng hiểu họ và lần lượt giải thích quan điểm của bạn để đưa ra kết luận. Chỉ sau khi các trường hợp sử dụng chính đã được hiểu và ước tính của bạn đạt độ tin cậy khoảng 80% thì bạn mới nên tiến hành xây dựng giai đoạn.

1
softveda

Giao tiếp thường giúp, ít nhất là trong một tổ chức lành mạnh.

Đây không phải là viên đạn bạc, nhưng những gì tôi đã cố gắng làm (và nó đã làm việc tại công ty chúng tôi) đang thuyết phục những người kinh doanh giải thích vấn đề, thay vì đề xuất một giải pháp ngay lập tức. Vì vậy, các yêu cầu tính năng của chúng tôi bắt đầu bằng một mô tả về vấn đề hoặc mục tiêu mà họ muốn đạt được.

Sau đó, một nhà phát triển với một số kiến ​​thức về miền cố gắng đưa ra giải pháp, trong khi tham khảo ý kiến ​​với ai đó về khía cạnh kinh doanh. Thông thường quá trình này mang lại một số giải pháp thay thế, hoàn thành với các ước tính.

Tại thời điểm này, tùy thuộc vào việc lựa chọn một doanh nghiệp dựa trên chi phí và mức độ hoàn thiện của một giải pháp. Đây cũng là cách bạn có thể bán phương thức này cho họ, rằng ở đây họ có các tùy chọn, không chỉ là một số nhiệm vụ, lấy nó hoặc bỏ nó. Tất nhiên, nó cũng cần nhiều tài nguyên hơn về phía họ nhưng nếu bạn gặp vấn đề với ước tính và thông số kỹ thuật, thì đó là một khoản đầu tư xứng đáng.

0
biziclop

Tại sao bạn chấp nhận một đặc tả yêu cầu không đầy đủ, chứa các yêu cầu mâu thuẫn hoặc không khả thi? Tôi sẽ đề nghị rằng quy trình của bạn bao gồm một cách để bạn đánh giá thông số kỹ thuật và gửi lại để sửa chữa trước khi bạn chấp nhận và đưa ra bất kỳ ước tính nào.

0
oosterwal

Thuyết phục quản lý/khách hàng rằng đáng để đầu tư vào thông số kỹ thuật tốt hơn. Cố gắng khiến những người có kiến ​​thức về miền tham gia nhiều hơn. Cuối cùng mọi người sẽ có lợi từ nó.

0
FabianB

Loại bỏ các thông số kỹ thuật.

Thuyết phục doanh nghiệp dùng thử Agile (hoặc ít nhất là quy trình Agile-ish) cho một dự án.

Thay vì viết ra thông số kỹ thuật

  • gặp gỡ những người kinh doanh để xác định tính năng
  • làm việc với họ để xác định tập hợp các tính năng/chức năng tối thiểu sẽ hữu ích (ngay cả khi chỉ để phát hành nội bộ)
  • thẻ lên công việc
  • đặt ngày cho công việc (càng ít tính năng/công việc thì càng dễ ước tính chính xác ngày).
  • làm việc với doanh nghiệp để ưu tiên công việc, đảm bảo họ có khả năng thay đổi suy nghĩ về thứ tự thẻ, cho họ biết ảnh hưởng của nó đến ngày
  • với mọi tính năng đã hoàn thành đều có hệ thống làm việc để hiển thị chúng và để chúng đăng xuất trên từng phần công việc khi hoàn thành
  • giải phóng
  • rửa sạch
  • nói lại

Hiển thị các tính năng khi chúng được thực hiện. Phát hành sớm và thường xuyên. Hãy minh bạch và đáp ứng. Tôi đã tìm thấy điều này sẽ dẫn đến việc loại bỏ các thời hạn vô nghĩa.

Chỉnh sửa kiến ​​trúc

Bất cứ ai là người dẫn đầu nên có một cuộc họp khởi động để truyền đạt cho các nhà phát triển kiến ​​trúc nên là gì. Người dẫn đầu cũng thực sự là người cần sự cẩn trọng để đảm bảo tất cả các nhu cầu đang được đáp ứng.

Nếu bạn cần các bước bổ sung trong quy trình của mình hơn là thêm chúng vào. Một quy trình có sẵn để tạo điều kiện cho khả năng của nhóm để hoàn thành công việc. Nếu một cái gì đó về không làm việc thay đổi nó. Thêm vào nó, xóa khỏi nó, thay đổi nó để đáp ứng của bạn nhu cầu. Nếu bạn cần đặc biệt quan tâm về bảo mật, hãy thêm các bước cho nó.

0
dietbuddha

Hãy nhớ rằng, mỗi khi thông số kỹ thuật được thay đổi để thêm chức năng mới hoặc để xóa câu hỏi, thì đó là lúc để xem lại ước tính. Nó không quá nhiều đến nỗi ước tính ban đầu của chúng tôi là xấu khi đưa ra những gì chúng tôi đã nói nhưng chúng tôi không đẩy lùi và nói không chúng tôi cần điều này khi có thêm chi tiết. Nếu tôi là một nhà thầu xây dựng một ngôi nhà và tôi ước tính chi phí dựa trên việc sử dụng mặt bàn lamiante và một tháng sau khách hàng muốn có một viên đá granit, bạn có thể đặt cược tôi sẽ xem xét lại dự toán chi phí với anh ta. Chúng tôi để cho khách hàng của mình thoát khỏi những yêu cầu kém chất lượng và sau đó không đẩy lùi khi hóa ra còn nhiều việc phải làm hơn so với dự kiến ​​ban đầu.

0
HLGEM