Bạn đã bao giờ phải chứng minh một giải pháp hay một nhiệm vụ thực thi của mình là đúng chưa?
Một điều đáng phải suy nghĩ khi khách hàng hay sếp của mình cần bằng chứng chứng minh điều gì đó là khả thi. Khi đó bạn sẽ phải làm sao?
Không phải họ không tin bạn, không tin giải pháp của bạn, mà là họ cần những con số, hình ảnh, tài liệu cụ thể để có thể triển khai giải pháp hay dự án đó.
Không ai đổ cả một đống tiền để thực hiện một dự án còn mơ hồ cả.
Trong các ngành nghề, đôi khi chúng ta luôn phải thực hiện một điều gọi là "Ném đá dò đường". Điều này sẽ giúp cho bạn được phần nào đó chứng minh hay tăng độ tin cậy cho giải pháp của bạn trước khi nó được triển khai.
Thuật ngữ đó được gọi là POC.
POC là viết tắt của Proof of Concept là một trong những thuật ngữ đang được sử dụng phổ biến từ rất lâu rồi, có lẽ là vào những năm 1967, bởi nó mang lại khá nhiều lợi ích đối với đời sống cũng như công việc của chúng ta.
Thực chất, POC là thuật ngữ được sử dụng để nói đến một ý tưởng hay một thử nghiệm về một Method (phương pháp để làm một việc nào đó) để minh chứng rằng nó có tính khả thi cũng như thực tiễn.
Trong phát triển phần mềm, vấn đề thử nghiệm trước khi đưa ra một giải pháp nào đó hay trước khi đưa ra ngoài thị trường lại càng được biết đến nhiều hơn. Agile hay Scum trong quy trình phát triển của phần mềm cũng phần nào hướng đến điều đó để có thể giảm thiểu sự thay đổi nhằm đáp ứng người dùng, bỏ đi những thứ không cần thiết hay thêm vào những tính năng có giá trị giúp người dùng có thể trải nghiệm tốt hơn.
Chia sẻ kinh nghiệm thành công trong việc chứng POC với khách hàng trước khi "chốt đơn". Video: https://youtu.be/KfwO4_5MoQ4?list=FLsxWbfsnfZknJKC0mOMS-NA
Khách hàng, đặc biệt là khách hàng không nắm rõ công nghệ, họ luôn đặt đâu hỏi liệu thứ đó có tốt không? Công nghệ này có đáp ứng được yêu cầu của hộ không? Nó có dễ dàng để triển khai cũng như bảo trì vận hành hay không?
Thật buồn cười khi bạn mơ hồ mà cứ chém đẹp là có và nhận làm thôi. Sau đó đến khi phát triển gần hoàn thiện thì mới nhận ra nó không đáp ứng được hết yêu cầu của khách hàng đặt ra ban đầu. Như vậy niềm tin khách hàng cho bạn ban đầu chắn chắn sẽ không còn, tiền mất, tật mang. Đừng để mình rời vào tình trạng đó.
Phần mềm cũng như các ngành nghề khác thôi, nó thậm chí còn có rất rất nhiều công nghệ mới ra và quảng bá rất rộng rãi. Nó phổ biến, nó nhanh, nó mạnh, nó abc xyz, khách hàng ai lại chẳng thích sản phẩm của mình vừa đáp ứng được yêu cầu vừa có thể áp dụng được những công nghệ mới nhất chứ.
Tuy nhiên không phải nhà phát triển nào cũng đủ kiến thức và kinh nghiệm của mình đối với những công nghệ mới như vậy. Ngay cả bản thân nhà phát triển cũng chỉ đọc tài liệu trên trang chủ của công nghệ đó (nếu công nghệ đó mới ra và cộng đồng ít sử dụng) thì họ lấy đâu ra thông tin để chứng minh cho khách hàng.
Ngoài phát triển phần mềm mình cũng biết một số ngành khác cũng sử dụng thuật ngữ này. Chẳng hạn:
- POC trong việc thử thi trường marketing
- POC trong làm phim
- POC trong các ngành kỹ thuật điện
- POC trong phát triển kinh doanh
- POC trong phát triển thuốc (y dược)
Có một thuật ngữ khác cũng chỉ sự nghiên cứu và phát triển một công nghệ hay một sản phẩm nào đó. Đó là R&D, nhiệm vụ của R&D bao gồm: Product R&D (Nghiên cứu – phát triển sản phẩm), Technology R&D (Nghiên cứu – phát triển công nghệ), Process R&D (Nghiên cứu – phát triển quy trình). Ngoài ra tùy vào ngành nghề mà có những nghiên cứu và phát triển riêng.
Một ví dụ thực tế mà mình từng gặp đó là hiệu năng, khách hàng hỏi bạn nói website của bạn có thể chịu tải được cả trăm triệu người dùng được một lúc. Bạn biết công nghệ bạn dùng phù hợp, bạn tin tưởng đội ngũ của mình không vấn đề gì trong quá trình phát triển (Nhiều khi thuật toán không đúng dẫn tới xử lý chậm). Bạn lên trang chủ nguồn công nghệ bạn dùng, đọc những bài viết cam kết khẳng định là đáp ứng được. Bạn sẽ đưa những cam kết đó cho khách hàng. Tuy nhiên, họ đổ rất nhiều tiền vào dự án, họ muốn chắc chắn và có những con số cụ thể. Khi đó bạn sẽ mất dần sự tự tin ban đầu. Trong đầu bạn luôn lòng vòng một câu hỏi, làm cách nào chứng minh đây khi thông tin trên mạng chưa đủ sức thuyết phục. Bạn sẽ phải thương lượng với khách hàng, cho bạn thời gian và một lượng chi phí nhất định để thực nghiệm. Xây dựng script đo đạc hiệu năng (benchmark performance) với một demo công nghệ với dự án đó.
Hay như bạn muốn sử dụng một kỹ thuật công nghệ nào đó mới cho dự án đang chạy của mình. Một sản phẩm đang hoạt động, đang đẻ trứng vàng cho bạn hằng ngày. Không dại gì bạn áp ngay tức thì kỹ thuật công nghệ đó vào thẳng dự án cả. Khi đó bạn phải thực hiện POC để có thêm thông tin.
Trong dự án phần mềm, thường những anh role cao như TA (Technical Architechture) hay SSA (Senior Sollution Architechture) đã định hướng cho bạn tại sao sử dụng công nghệ đó rồi. Dựa vào kinh nghiệm thực tế từng sử dụng của họ, họ đã có cái nhìn chi tiết, điểm lợi điểm hại cho kỹ thuật công nghệ đó và có dẫn chứng ở một dự án nào đó họ từng làm. Việc của bạn là thực thi giải pháp kỹ thuật đó thôi.
Nhưng rồi có một ngày bạn đặt câu hỏi tại sao họ sử dụng chưa? Mình nghĩ bạn nên thử một lần đặt câu hỏi này cho các anh ý và nghe họ giải thích ưu nhược điểm. Có lẽ bạn sẽ học được điều gì hay ho ở những câu trả lời đó đấy. Lập trình viên không chỉ là thợ code theo thiết kế, quan trọng là giải quyết vấn đề, hãy cố gắng trả lời câu hỏi tại sao nhé! Mình thì mình rất thích câu "People don't buy what do you, they buy why you do it" -- Simon Sinek
Còn bạn, bạn nghĩ sao về vấn đề này?
St
