Làm thế nào một người phi kỹ thuật có thể học cách viết một thông số kỹ thuật cho các dự án nhỏ?

Làm thế nào một người phi kỹ thuật có thể học cách viết thông số kỹ thuật cho các dự án nhỏ?

Một người bạn của tôi đang cố gắng thuê ngoài một số phát triển trong một dự án thống kê.

Cụ thể, anh ấy làm rất nhiều công việc trong excel, và muốn thuê ngoài việc tạo ra các kịch bản để làm những gì anh ấy làm bây giờ bằng tay.

Tuy nhiên, bạn tôi cực kỳ phi kỹ thuật. Anh ấy kém trong việc viết thông số kỹ thuật.

Khi anh ta viết một thông số, nó được viết theo cách bạn sẽ mô tả khi làm một cái gì đó trong excel (đi đến ô này và sau đó sao chép giá trị vào ô đó). Nó cũng quá dài dòng và làm ví dụ nhiều lần. Tôi không chắc anh ấy có mô tả đúng các trường hợp góc không.

Dự án đầu tiên anh thuê ngoài là một thất bại. Tôi nghĩ rằng ông đã mô tả quá mức một số chi tiết, nhưng các trường hợp góc được mô tả. Điều đó và / hoặc người viết mã mà anh ta thuê đã không nghĩ qua các trường hợp góc và đặt câu hỏi thích hợp. Tôi không chắc. Tôi đã nhắn tin với anh ấy và tôi mất nửa giờ để tìm ra một mô tả đáng lẽ phải mất năm phút hoặc ít hơn để mô tả. Cuối cùng tôi đã viết kịch bản cho anh ta, nhưng không kiểm tra được tại sao quá trình của anh ta với người viết mã thất bại.

Anh ấy đã nhờ tôi giúp đỡ. Tuy nhiên, tôi từ chối tham gia, bởi vì lấy thông số kỹ thuật của anh ấy và chuyển nó thành các yêu cầu rõ ràng là công việc gấp 10 lần so với thực hiện trên một thông số rõ ràng bằng văn bản.

Cách đúng đắn để anh ta học hỏi là gì? Có tài nguyên nào anh ta có thể sử dụng? Có cách nào để anh ấy có thể học hỏi từ các dự án thực hành nhỏ, áp suất thấp với các lập trình viên không?

Hầu hết các kịch bản của ông là thống kê và xử lý dữ liệu theo định hướng. ví dụ: lấy cột này và chạy trung bình trên nó. Loại bỏ các hàng trong các điều kiện này. Vì vậy, thách thức này khác với việc chỉ định một ứng dụng web.

Tôi thấy hai cách tiếp cận tốt cho vấn đề này. Tuy nhiên, điều quan trọng là nhận ra hai điều. Đầu tiên, yêu cầu kỹ thuật là công việc khó khăn - biến một ý tưởng thành một đặc tả chính thức đủ để xây dựng một hệ thống tốn rất nhiều thời gian, công sức và thực hành. Thứ hai, nếu bạn có các yêu cầu tốt (ở bất kỳ định dạng nào, từ đặc tả chính thức đến các câu chuyện người dùng và trường hợp sử dụng ít chính thức hơn), việc xây dựng phần mềm (và xây dựng phần mềm ngay trước đó) sẽ dễ dàng hơn, rẻ hơn và nhanh hơn.

Nếu bạn của bạn sẽ yêu cầu xây dựng nhiều công cụ phần mềm hoặc dự định ký hợp đồng với họ, anh ta nên học cách viết các yêu cầu phần mềm, ít nhất là ở cấp độ mục tiêu kinh doanh và khái niệm hoạt động. Hai cuốn sách hàng đầu về kỹ thuật yêu cầu phần mềm là của Karl Wiegers - Yêu cầu phần mềm (Ấn bản 2) và Thông tin thêm về Yêu cầu phần mềm: Các vấn đề nhức nhối và Lời khuyên thực tế . Tôi hy vọng rằng hầu hết những người anh ta sẽ thuê sẽ muốn một loại tài liệu mô tả hệ thống, ít nhất là ở mức độ mục tiêu kinh doanh hoặc khái niệm hoạt động, và những cuốn sách này đi vào đó. Họ cũng đi sâu vào cách thức và lý do các khía cạnh khác của kỹ thuật yêu cầu mà tôi nghi ngờ một nhà phát triển giỏi sẽ trải qua sớm trong dự án.

Tùy chọn thứ hai là thuê một người có kinh nghiệm về phát triển phần mềm và yêu cầu kỹ thuật (và thậm chí có thể là một loại kỹ thuật hệ thống hoặc kiến ​​trúc hệ thống) để hiểu không gian vấn đề và xác định nơi cần giải pháp phần mềm và nơi giải pháp phần mềm sẽ không có lợi, viết các tài liệu, và thậm chí có thể giám sát hoặc thực hiện các nỗ lực phát triển. Tuy nhiên, điều này có thể sẽ tốn kém hơn và số tiền để thuê một nhà phát triển phần mềm toàn thời gian trong một thời gian dài để phát triển không chỉ hệ thống yêu cầu, mà cả các yêu cầu và kiến ​​trúc cần thiết.

Thành thật mà nói, tôi không nghĩ những gì bạn của bạn đang trải qua là không phổ biến đối với người không hiểu quy trình phát triển phần mềm. Tôi cũng không nghĩ rằng sự đổ lỗi hoàn toàn nằm ở anh ấy. Nếu dự án phần mềm đầu tiên không có yêu cầu tốt, thì nhà phát triển đã thuê ngoài nên đã làm rõ, tinh chỉnh và ghi lại các yêu cầu. Thành thật mà nói, tôi không chắc chắn rằng bạn là người phù hợp để tham gia, nếu bạn không sẵn sàng dành thời gian hoặc nỗ lực làm việc với người dùng / khách hàng phi kỹ thuật và phát triển các thông số kỹ thuật tốt (điều này là một vai trò quan trọng của bất cứ ai thực hiện yêu cầu kỹ thuật trong bất kỳ ngành kỹ thuật).

Tôi nghĩ rằng giải pháp tối ưu thực sự là sự kết hợp của hai lựa chọn của tôi. Tôi nghĩ rằng bạn của bạn (và có lẽ bạn cũng vậy) nên tìm hiểu về những gì liên quan đến kỹ thuật yêu cầu và lợi ích mà việc yêu cầu vững chắc có thể mang lại cho một dự án. Bạn, với tư cách là nhà phát triển phần mềm, cũng sẽ trở nên quen thuộc hơn với kỹ thuật yêu cầu và cách khơi gợi, lập tài liệu, phân tích và quản lý các yêu cầu phù hợp với các dự án phần mềm - đó thực sự là một kỹ năng quý giá cho bất kỳ ai làm việc ở bất kỳ phần nào trong vòng đời phần mềm.

Khi tôi cần thông số kỹ thuật từ một khách hàng phi công nghệ, tôi thường yêu cầu họ viết bằng ngôn ngữ đơn giản chính xác những gì họ muốn thực hiện. Như trong "ứng dụng nên làm A đến B khi tôi nhấn C, nhưng chỉ khi D". Phần thưởng thêm cho "vì D có nghĩa là ...".

Trong thực tế "lấy cột này và chạy trung bình trên nó." là một bước đi đúng hướng. Một lời giải thích tốt hơn sẽ là "Bảng chứa cái này và cái kia" (nếu cấu trúc được xác định trước); "Lấy trung bình X". Về cơ bản, cách kỹ thuật ít nhất có thể mà không làm mất các chi tiết.

Nói cách khác, mô tả ý tưởng, không phải việc thực hiện.

Sau đó, một lập trình viên chu đáo sẽ có thể hiểu được mục đích thực tế của những gì anh ta ủy thác để làm và tự mình chọn đúng bước, đặt câu hỏi cho bất cứ điều gì không rõ ràng.

Nếu không có ai quan tâm đủ và hiểu quy trình, dự án sẽ thất bại trong mọi trường hợp.

Anh ta có thể thử sử dụng cách tiếp cận bảng phân cảnh .

Yêu cầu anh ta viết ra một danh sách những điều ( câu chuyện ) mà ứng dụng sẽ phải làm và trong danh sách đó, chi tiết hơn về chức năng của mỗi câu chuyện.

Anh ta có thể sử dụng một công cụ như Asana để bổ sung phạm vi và chức năng của dự án, và thậm chí tương tác với nhà phát triển của mình.

Chuyển nó thành các yêu cầu rõ ràng là công việc gấp 10 lần so với thực hiện trên một thông số rõ ràng bằng văn bản.

Amen. Điều đó cũng giải thích tại sao:

lập trình viên mà anh ta thuê đã không nghĩ qua các trường hợp góc và đặt câu hỏi thích hợp.

Hiểu các yêu cầu là phần khó nhất (và đắt nhất) trong hầu hết các dự án lập trình. Khi một người không có kỹ thuật viết các yêu cầu, họ thường chỉ ghi lại công việc mà họ muốn thay thế ("mở Excel, nhấp vào ô B3 ..."). Điều tốt nhất họ có thể hy vọng là một bản sao chính xác của khó khăn hiện tại của họ!

Cách hiệu quả nhất mà tôi biết để giải quyết vấn đề này là khuyến khích người này viết Ca sử dụng ("sử dụng" vần với "lỏng lẻo"). Thay vì viết các yêu cầu, hãy mô tả cách hệ thống sẽ được sử dụng. Điều này khiến nhà phát triển một số phòng ngọ nguậy để đề xuất một giải pháp tốt hơn so với những gì người dùng đang làm.

Có vẻ như vấn đề này trở nên trầm trọng hơn bởi kỹ năng giao tiếp bằng văn bản kém về phía bạn của bạn. Anh ấy / cô ấy hoặc phải đưa công việc vào việc truyền đạt hiệu quả ý tưởng của họ, hoặc trả tiền cho lập trình viên để thu thập thông tin từ họ. Cả hai quá trình đều đau đớn và tốn thời gian, nhưng tự mình làm nó ít tốn kém hơn so với việc trả tiền cho ai đó để làm điều đó với bạn.

Trong mọi trường hợp, đây là một khó khăn phổ biến và gây nản lòng khi những người sáng tạo có một ý tưởng không hoàn chỉnh hoặc không có khả năng mô tả nó trong chưa đầy một triệu từ. Người này nên cố gắng tìm một lập trình viên cực kỳ kiên nhẫn và sâu sắc, người sẵn sàng đi đến tận cùng của những gì họ đang thực sự cố gắng để làm và biến nó thành hiện thực.

lập trình viên mà anh ta thuê không ... hỏi những câu hỏi thích hợp

Đó là một công thức cho thảm họa. Điều đó, và cũng là kỳ vọng mà lập trình viên sẽ hỏi. Các lập trình viên thích mã hóa, không giao tiếp, mong muốn họ phá vỡ thói quen của họ mà không có động lực là khá phi thực tế.

Nếu bạn của bạn muốn hoàn thành công việc, tốt nhất họ nên thiết lập một quy trình liên quan đến giao tiếp liên tục với lập trình viên - và đó là bạn của bạn, người phải đóng vai trò tích cực trong đó, chứ không phải là lập trình viên. "Cho tôi xem những gì được thực hiện vào mỗi thứ Hai và thiết lập hai giờ để thảo luận về điều này vào mỗi thứ Ba", đại loại như thế.

• Để giới thiệu, hãy cung cấp cho họ một số tổng quan nhẹ về các phương pháp phát triển lặp và Agile (các bài viết trên Wikipedia sẽ làm), để họ có cảm giác về việc nó sẽ như thế nào.
   
• Để giúp họ hiểu về thất bại trong quá khứ, hãy cung cấp cho họ một số tổng quan nhẹ về Waterfall / Big Design Up Front (những bài viết bao gồm chỉ trích - một lần nữa, các bài viết trên Wikipedia sẽ làm) lên phía trước

Theo kinh nghiệm của tôi, cách đáng tin cậy nhất để khiến phần mềm hoạt động như mong muốn với các khách hàng không có kỹ thuật là liên lạc vĩnh viễn và lặp lại các mô tả tính năng, không cố gắng chỉ định nó đến chết trong một lần bắn.

Hầu hết các kịch bản của ông là thống kê và xử lý dữ liệu theo định hướng. ví dụ: lấy cột này và chạy trung bình trên nó. Loại bỏ các hàng trong các điều kiện này. Vì vậy, thách thức này khác với việc chỉ định một ứng dụng web.

Nó khác biệt - có vẻ đơn giản hơn nhiều so với việc chỉ định một ứng dụng web. Đó là một quá trình hợp lý. Đây là công cụ dễ dàng.

Bạn của bạn rất đơn giản chỉ cần viết ra các bước mà anh ta thực hiện khi anh ta thực hiện quy trình này. Anh ta có thể làm điều đó theo cách anh ta muốn nhưng điều quan trọng cần tập trung vào là sự chính xác, ngắn gọn và rõ ràng. Không có lý do gì mà nó không thể được thực hiện hoàn toàn bằng văn bản như bản thảo; nó sẽ được hưởng lợi từ một số phân chia hợp lý của các thành phần hoặc nhiệm vụ, và có thể sẽ hoạt động tốt như một sơ đồ hoặc sơ đồ.

Bây giờ bạn của bạn nên tìm một nhà phân tích / nhà phát triển có thẩm quyền và tham gia từng dịch vụ của họ. Anh ta cần đưa ra những kỳ vọng của mình - hàng ngày hoặc ít nhất nhiều lần mỗi tuần, bạn của bạn nên gặp nhà phát triển và xem bàn tay thể hiện sự tiến bộ. Bạn của bạn sẽ trả cho nhà phát triển thời gian của mình trong các cuộc biểu tình này, nhưng sẽ rất đáng để đảm bảo rằng dự án đang được chạy theo đặc tả. Bất kỳ thay đổi nào về đặc điểm kỹ thuật - tức là những thứ mà bạn của bạn đã bỏ qua - cần phải được thương lượng và có thể được thêm vào giá niêm yết.

Lưu ý rằng tôi đã nói 'có thẩm quyền' - điều này không giống với 'mức trung bình', bởi vì có rất nhiều nhà phát triển 'trung bình' không có năng lực. Nếu bạn của bạn chỉ có một lập trình viên rẻ nhất xung quanh, hoặc chỉ tìm thấy ai đó trực tuyến, anh ta sẽ gặp vấn đề. Không gợi ý rằng những người tìm việc trực tuyến là không tốt, nhưng bạn sẽ không tuyển dụng ai đó mà không có đề xuất.

Bạn của bạn chỉ đơn giản là tìm đúng người. Trong bất kỳ dự án phần mềm nào cũng cần có các nhà phân tích, lập trình viên, quản trị viên hệ thống, người kiểm thử và người quản lý dự án. Bạn càng muốn có nhiều vai trò trong số những vai trò này, nhà cung cấp sẽ càng có nhiều kỹ năng và bạn của bạn sẽ phải trả nhiều tiền hơn.

Xin lỗi để trở thành người phá vỡ điều này với bạn, nhưng đó không phải là công việc của người không có kỹ thuật để học cách viết thông số kỹ thuật chính thức. Đó là công việc của nhà phát triển để phỏng vấn người phi kỹ thuật, cố gắng chắt lọc những gì người đó nói với bạn về những gì họ đang theo đuổi, xác định khách hàng thực sự muốn gì (trái ngược với những gì họ nghĩ họ muốn, đó là không phải lúc nào cũng giống nhau), xây dựng một tài liệu yêu cầu tương đối không chính thức (một tài liệu có cấu trúc tốt nhưng cố gắng tránh biệt ngữ mà khách hàng sẽ không hiểu) và xem xét tài liệu đó với khách hàng.

Khi khách hàng hài lòng với tài liệu yêu cầu không chính thức, bạn có thể sử dụng nó làm cơ sở để soạn thảo một đặc tả yêu cầu chính thức hơn bắt đầu đi sâu vào chi tiết kỹ thuật hơn về những gì cần thiết.

Toàn bộ quá trình này được gọi là "nắm bắt yêu cầu" và nó tạo thành bước đầu tiên trong quy trình công nghệ phần mềm. Trên thực tế, việc viết phần mềm chỉ là một phần tương đối nhỏ của công nghệ phần mềm, một thực tế mà rất nhiều nhà phát triển phần mềm quên mất. Một điều khác mà họ dường như quên mất là có một nhu cầu mạnh mẽ để giao tiếp với khách hàng và giữ một cuộc đối thoại tại chỗ với họ trong toàn bộ quá trình để đảm bảo mọi thứ đi đúng hướng.

Đối với việc giao tiếp với những người không có kỹ thuật, điều cực kỳ quan trọng là bạn cố gắng tránh sử dụng thuật ngữ của máy tính và phát triển phần mềm khi nói chuyện với họ. Nếu họ sử dụng thuật ngữ biệt ngữ từ lĩnh vực của riêng họ thì điều quan trọng là phải hiểu những thuật ngữ này có nghĩa là gì, vì vậy bạn có thể muốn lập một bảng thuật ngữ dự án để có được định nghĩa chính thức cho các thuật ngữ này. Rốt cuộc bạn đang làm việc cho họ, vì vậy điều quan trọng là phải hiểu họ đến từ đâu.

thay vì biệt ngữ, bạn nên thử sử dụng các cách giao tiếp không đáng sợ với khách hàng của mình, các tài liệu viết bằng tiếng Anh đơn giản là một trợ giúp, nhưng nhiều người trong ngành kinh doanh phần mềm thường sử dụng để viết cho máy tính thay vì con người và vì vậy có thể tìm thấy điều này khó khăn. Ngoài ra, khách hàng không thích đọc qua đống giấy lớn, bất kể ngôn ngữ của họ đơn giản đến mức nào, vì vậy bạn có thể muốn dùng đến các phương tiện trực quan. Sơ đồ, khung dây và bảng phân cảnh là những công cụ hữu ích ở đây.

Nhưng tóm lại, điểm cốt lõi là công việc của bạn không phải là học ngôn ngữ của bạn, mà là của bạn để học ngôn ngữ của họ.