Làm fs theo tên online
Hế lô anh em, dịp rồi gồm nhiều đồng đội nhắn tin hỏi mình về phong thái BA viết tư liệu FS.
Bạn đang xem: Làm fs theo tên online
Như tuần trước có bạn nhắn mình: “anh ơi cha mình viết FS như nào anh”. Hoặc có bạn nhắn “anh bao gồm sẵn template FS hông anh”. Hoặc có các bạn vào thẳng luôn vấn đề: “hỏng ấy, anh viết dùm em mẫu FS này luôn được hông….“
Nói chung tất cả rất nhiều câu hỏi liên quan mang lại FS. Phải nay tranh thủ vừa đóng chấm dứt dự án, bản thân xin chú ý lại vài ba ý về chủ thể “BA viết FS như thế nào” nhé anh em.
Ô kê trước lúc bắt tay vào có tác dụng FS, thì bản thân cần nắm vững nó là gì và mục đích tồn tại của nó nhé anh em.
FS trong Software Development là viết tắt của Functional Specification. Nghĩa là Đặc tả tính năng (của phần mềm). Nôm na thì đây là tài liệu miêu tả phần mềm làm cho được mọi gì.
Như bằng hữu biết thì BA có rất nhiều kiểu BA, mỗi công ty lại định nghĩa scope của cha là vô cùng khác nhau. Chưa tính trong cùng 1 công ty, nhưng tía của dự án này lại perform một scope khác hoàn toàn với cha của 1 dự án công trình khác.
Nói vậy để đồng đội hình dung là phạm vi công việc của bố trong từng dự án, từng doanh nghiệp là linh thiêng hoạt. Và hoàn toàn không bao gồm đúng hay sai. Cơ mà là có tương xứng với nhu cầu hiện tại của dự án đó hay không mà thôi.
Kéo từ đó là “việc làm FS của BA” nó cũng sẽ khác nhau theo từng dự án công trình và từng doanh nghiệp nhé anh em.
Ngoài FS ra, thì tư liệu này còn có khá nhiều tên gọi khác nhau, như: SRS – Software Requirement Specification, FRD – Functional Requirement Document, hoặc là viết dưới dạng User Story.
Nhưng dù có tên gì thì mục tiêu duy nhất của chính nó cũng là mô tả: Phần mượt này làm cho được phần đông gì.
Để dễ hình dung thì bạn bè cứ xem văn bản trong FS đó là “điểm giao thoa thân Business và Tech”. Theo đó, mục đích ở đầu cuối của FS là dành cho 2 đối tượng này đọc.
Vậy phía Business và phía Tech đề nghị đọc hầu như gì trường đoản cú FS này?
Business
Như bằng hữu đã biết (hoặc biết cơ mà làm bộ chưa biết) thì thông thường sẽ có 4 một số loại requirements: Business Requirement >> Stakeholder Requirement >> Solution Requirement >> và cuối cùng là Transition Requirement.
Phía Business User nhà yếu lưu ý đến cái Biz Requirement và Stakeholder Requirement được phát biểu trong FS là gì? Nó có thỏa mãn nhu cầu đúng nhu yếu hiện tại của mình hay không?
Và thường xuyên thì đó là phần “văn mẫu” mà anh em BA hay chém bừa duy nhất ?
Mặc dù phần này sẽ không nhất thiết đề xuất phải trình bày rõ ràng, mang tính logic, xuất xắc thuyết phục hùng hồn về chiến thuật có chắn chắn là giải quyết được những requirement hay không. Vày phần này đã-phải-được-làm trước đó trong số câu chuyện “thấm đẫm tiền bạc” như: bidding, làm POC, Business Case… rồi.
Nhưng vấn đề BA trình bày một cách gọn gàng và súc tích về đề bài mà Biz Requirement và Stakeholder Requirement đặt ra là khôn cùng quan trọng. Ráng thể:
Nó có ăn nhậu gì với phần giải pháp dưới không?Khi reviews milestone nào đó, gồm dễ dàng reviews được kpi hiệu quả chiến dịch nào đạt, kpi hiệu quả chiến dịch nào không tốt không?Và đặc trưng nhất, lúc nói rõ và gãi được đúng vị trí ngứa của khách hàng (sponsor, system owner…) thì rất dễ dàng để chúng ta thật sự xem xét docs bản thân viết. Theo đó là rất giản đơn để kéo họ tiếp tục với những phần phía đằng sau (rất thô khan) của FS.
Tech
Còn về phía Tech, đồng đội trong team sẽ quan tâm không ít đến Solution Requirement được diễn tả trong này như thế nào.
Đó là phần lớn Use Case, Business Process Flow, Business Rules, Wireframe hay những Diagram diễn đạt theo từng nội dung nắm thể. Phần Solution Requirement này giúp team đọc được cụ thể từng module. Gọi được độ lớn, với độ tinh vi của nó.
Từ đó có cái quan sát tổng quan. Và rất có thể phân tung thành từng task nhỏ tuổi phù hợp.
Cụ thể hơn một chút thì phía Business rất có thể là các đồng đội đến từ: Sales, Marketing, Operation, CS…Phía Tech thì chắc hẳn rằng sẽ là: Dev, QC, PM, Designer, Infra, Security…
Ô kêêêêê, đến đây phần nào anh em đã cụ được mục tiêu và đối tượng người sử dụng của FS. Tiếp sau sẽ là?
3. FS hay viết nghỉ ngơi đâu?Đâu cũng được. Đây là câu vấn đáp mình nghĩ thực tiễn nhất. Bạn bè nên tháo chuồng à nhầm tháo mở như vậy.
Anh em hoàn toàn có thể viết FS trên:
Word (dĩ nhiên rồi) Hoặc bên trên excel (như mình cũng đã từng, và tác dụng vô cùng) Hoặc bên trên power point (mình đã và đang từng, vì đặc điểm dự án nên hầu hết mô tả BPMN là đủ)Hoặc trên Confluence, Google Docs hoặc ngẫu nhiên platform làm sao có cung cấp viết docs.Nói bởi vậy để một lần nữa khẳng định: FS là 1 trong thứ khôn cùng linh hoạt, rất có thể viết trên ngẫu nhiên đâu.
Nhưng, câu hỏi: “Nên viết ngơi nghỉ đâu?” thì lại phải cân đo đong đếm giữa nhiều yếu tố.
Nếu team có tương đối nhiều người, và đồng đội cần một vị trí share thông thường để viết thì Confluence là quá vừa lòng lý. Gồm tracking history, bao gồm version baseline, có sharing theo permission, formatting thoải mái,…. Nói bình thường là SƯỚNG. Dự án công trình có đk thì chi tiêu quả Confluence viết là chuẩn chỉnh bài nhất.
Nhưng nếu dự án chỉ tất cả 1-2 BA, hoặc chỉ mình đồng đội làm. Và yêu cầu transfer FS mang lại team cũng không quá thường xuyên thì bản thân nghĩ word tốt excel là đủ!!!
Nó là file trên local, phần nào sẽ bảo mật hơn khi nằm tốt nhất trên máy của anh em.Tự mình edit, tự bản thân control, kiêng nhầm nhọt lúc cả bè cánh cùng edit.Xem thêm: Viettel Post Làm Việc Đến Mấy Giờ, Viettel Post Mở Cửa Đến Mấy Giờ
Miễn phí, cấp tốc gọn, không cần cài đặt. Ai ai cũng xem được nhưng mà không cần đăng ký bất kỳ tài khoản gì.Thậm chí nếu cần sử dụng Excel, bạn bè có thể hối hả nhảy qua dancing lại giữa những sheet. Giúp từng trải đọc “ngay trong vòng mắt” và thuận lợi đối chiếu được các phần cùng với nhau.
Có những dự án consulting cả tỷ bạc đãi mà tín đồ ta vẫn dùng file word nhằm deliver tư liệu như thường nhưng mà anh em. Nên bằng hữu cứ tùy thực trạng dự án nhưng liệu cơm gắp mắm nhé.
Chủ trương vẫn là tinh thần: nhanh, gọn, lẹ và nhất là hiệu quả ?
4. Hồ hết quan điểm xô lệch về FS
Mình thấy bằng hữu thường lậm vào 2 cách nhìn sau, nhưng mà theo bản thân 10 phần thì sai hết 11 phần.
1. Ông nào viết FS, ông đó là ba ?
Câu bên trên thoạt chú ý cứ nghĩ là đúng, mà lại theo bản thân nó chỉ đúng được một nửa.
Anh em phải hình dung là: ĐỂ-CÓ-CÁI-VIẾT bên trên FS, thì chúng ta phải làm cho hầm bà lằng rất nhiều thứ trước đó, thì mới có thể ra được cái, để mà viết vào FS.
Nào là đề xuất hiểu về business, rồi đọc về sự việc đang chạm mặt là gì. Nội sương sương hai này thôi cũng đã rất trày đơn lẻ rồi. Hiểu cái hiện tại rồi, bạn bè phải khuyến nghị được vài ba cái solution làm sao đó, để giải quyết vấn đề sao cho phù hợp và buổi tối ưu nhất.
Rồi solution này được so với trên những khía cạnh nào, impact của nó ra sao. Chưa kể còn cần cân đo đong đếm tính hiệu quả, rồi kỹ năng thực thi (technical feasibility). Với phải map nó vô mẫu roadmap ra làm sao cho vừa lòng lý…
Nhìn chung, đồng đội mình bắt buộc làm rất nhiều thứ – với rất nhiều người, thì mới có dòng để viết được vào FS. Khoan kể đến chuyện viết chuẩn. Ví như ngay trường đoản cú đầu, việc định hình bài toán trật, thì giải pháp dù ngon nghẻ cỡ nào thì cũng không gãi trúng được địa điểm ngứa. Kéo theo đó là viết bao gồm xịn cho cỡ làm sao thì cũng toang.
Do đó, để hiểu đúng thực chất vấn đề thì: fan làm quá trình phân tích & thiết kế để rồi mô tả nó lại trong FS mới là BA (là tín đồ làm các bước Business Analysis)
Giá trị của BA không nằm tại vị trí chuyện viết docs. Giá trị của BA nằm ở vị trí khâu đối chiếu & xây dựng để ra-được-thứ viết vào docs.
Và trong câu chuyện phân tích – thiết kế, cá thể mình thường dành ra khoảng:
60% thời gian để mày mò về problem gặp mặt phải40% thời gian còn lại mới lấn sân vào solution (chứ đừng trái lại nhé anh em).Nên để ý đến “Ông làm sao viết FS thì ông chính là BA” chỉ đúng được 1 nửa, và không đi sâu vào nền tảng vấn đề.
Mình biết tại 1 vài công ty, 1 dự án bé dại thôi cũng có thể có tới 2-3 ông làm BA. Tuy vậy lại phân tách theo kiểu:
Rồi 2 ông kia phụ thuộc vào đó, viết lại vào FS, theo sự khuyên bảo của ông ở trên.Nếu nói 2 ông kia làm BA luôn vì 2 ổng là người viết FS thì chả đúng tí nào. Nó không đủ cái đặc điểm của các bước BA.
Mô hình này mình thường bắt gặp ở những công ty oursource. 2 Junior sẽ theo chân 1 Senior. Senior siêng facing với khách hàng để mày mò & so sánh business. Junior ghi meeting minutes rồi viết lại vào FS theo phía dẫn của Senior.
Cách có tác dụng này không hẳn là xấu, tuy nhiên nó ko giúp cho bạn Junior đọc được tường tận vòng đời tự lúc: nhấn yêu mong đến lúc ra được chiến thuật và viết nó vào FS là như nào.
Sẽ tốt hơn ví như cả Senior & Junior thuộc side-by-side cùng với nhau xuyên suốt dự án. Bao gồm cả lúc tìm hiểu về business, bàn luận với khách hàng hàng, giỏi brainstorm tìm giải pháp với team. Rồi kế tiếp là cùng chia ra những phần trong FS để viết với nhau.
Thì chỉ lúc đó, cái anh Senior này new rút chích ra được những điểm giỏi và không tốt của khách hàng kia trong xuyên thấu cả quy trình từ UR -> FS. Từ bỏ đó mới giúp cải thiện lên dần dần được.
Hiệu quả và đi thẳng vào vấn đề là ưu điểm mà phương pháp làm này với lại.
Và cũng một ý kiến khác, liên quan đến vụ này…
2. Viết FS dễ mà, cứ đưa mang lại Junior viết!!!
Câu này có 2 ý:
Viết FS dễ màFS thì cứ đưa mang lại Junior viếtÝ 1, “Viết FS dễ” thật ra không đúng, cũng ko sai. Nó tùy vào công đoạn trước đó bằng hữu làm có kết quả hay không.
Nếu xuất phát điểm từ 1 mớ rối rắm, đồng đội định hình được bài xích toán, đưa chiến thuật phù hợp, với thật sự vẫn phân tích kỹ phương án này. Thì chuyện đưa nó vào trong FS là chuyện… làm cái một.
(…dĩ nhiên khi viết FS nó sẽ có được vài lưu ý để viết thế nào cho ổn, mình sẽ nói ngơi nghỉ chuỗi bài xích sau nhé anh em.Nhưng sau tất cả thì đây không hẳn vấn đề bự nhất).
Hoặc cũng xuất phát từ 1 mớ rối rắm, đồng đội có thể vào và càng làm phức hợp hóa vấn đề. Định nghĩa không đúng đề bài, phương án trớt quớt, không ăn nhậu với loại gì. Và ngay cả phiên bản thân bằng hữu cũng không làm rõ solution kia là như thế nào. Thì vấn đề đưa nó vào FS đúng thật là 1 cực hình.
Xem thêm: Xe Tay Ga Honda Wave Nhập Thái Về Việt Nam Giá Đắt Gấp 3 Lần
Tin bản thân anh em, cá nhân mình đã trải qua “n nón hai” lần rồi đề nghị mình hiểu rõ lắm. Chưa kể áp lực đè nén về thời gian, chưa tồn tại kinh nghiệm lưỡng lự làm sao. Tốt thậm chí áp lực đè nén từ bao gồm team đơn vị mình, từ bỏ Dev, QC, Designer…. đổ lên đầu thuộc lúc.
Sẽ thiệt sự là chuaaaa nếu anh em rơi vào cảnh nào. Nhưng, no pain no gain!
Do đó, chuyện viết FS dễ hay khó khăn hoàn toàn nhờ vào vào quy trình phân tích & thiết kế trước kia nhé anh em. Nhờ vào vào chiếc gọi là “bản hóa học của công việc BA” mà trên mình có nói đó
