Là một developer có cần biết cách "làm sản phẩm"?

Là một developer có cần biết cách "làm sản phẩm"?

Những mẩu tin ngắn hàng ngày dành cho bạn
  • Hẳn là nhiều người ở đây đã nghe đến kiểu tấn công bảo mật Clickjacking rồi nhỉ. Kẻ tấn công thường nhúng một website (thường là mục tiêu) vào trong một iframe trên website của chúng, sau đó làm mờ hoặc ẩn nó đi rồi đặt vào vị trí các nút bấm trên web, ví dụ "Bấm vào để nhận quà". Đâu ai ngờ rằng phía trên nút bấm đó là một nút bấm khác trong iframe. Khá nguy hiểm!

    Nhưng trình duyệt đã có cách ngăn chặn kiểu tấn công này bằng các quy tắc như tiêu đề X-Frame-Options, frame-ancestors của CSP và SameSite: Lax/Strict của Cookies...

    Mới đây, đã xuất hiện thêm kiểu tấn công mới - "DoubleClickjacking" 😨. Đại ý là "hắn" lợi dụng hành động double click để lừa người dùng bấm vào một nút mà hắn muốn. Chi tiết hơn trong bài viết này: DoubleClickjacking: A New Era of UI Redressing.

    » Xem thêm
  • Mọi người đã nghe nói đến Jujutsu - jj - một dạng quản lý phiên bản cho mã nguồn (version control system) chưa? Có vẻ như nó đang nhận được nhiều sự quan tâm.

    Chờ xíu! Chẳng phải git đã quá tốt rồi sao? Thế thì chế ra thằng jj để làm gì nữa? Cũng hơi khó trả lời nhỉ? Mỗi công cụ sinh ra chắc chắn phải cải thiện hoặc khắc phục được nhược điểm của cái trước. Cho nên jj ắt hẳn phải làm được điều gì đó mà git chưa làm được nên mới nổi lên như vậy.

    Thật ra mình đã nghe nói đến jj từ vài tháng trước rồi, nhưng vào đọc thì toàn kiến thức cao siêu. Hoặc là đang mang nặng cái lối suy nghĩ của git vào trong đầu rồi nên chưa lĩnh hội ra được điều gì cả.

    Mình hay có kiểu cái gì đọc lần 1 mà không hiểu thì đọc tiếp lần 2, lần 2 không hiểu thì đọc tiếp lần 3... đến lần thứ n mà vẫn không hiểu thì bỏ. Cơ mà không phải là từ bỏ mà một thời gian sau đó quay lại đọc tiếp. Đến một lúc nào đó khả năng mình sẽ hiểu ra một ít vấn đề, thế mới tài 😆.

    Thì cái jj này có vẻ như nó đang mở ra được tính linh hoạt trong việc "cam kết" mã. Tưởng tượng bạn đang làm việc trên một dự án, đang ở nhánh này, muốn sang nhánh khác để sửa, nhưng mà lại đang viết dở ở nhánh này, thế là phải stash, rồi checkout, rồi commit, rồi merge hoặc rebase lại vào nhánh cũ... nhìn chung quá trình làm việc với git nghiêm ngặt đến mức cứng nhắc, cần nhiều thao tác để giải quyết một vấn đề, chưa kể cái cây commit (commit-tree) nữa thì ôi thôi, khỏi xem cho đỡ nhức mắt. Thế nên ông jj này đang làm cách nào đó để bạn khỏi cần phải quan tâm đến các nhánh luôn, sửa trực tiếp vào commit. Nghe ảo nhỉ 😂.

    Đấy mới lĩnh hội được đến đấy, hy vọng sau n lần đọc lại nữa mình sẽ viết được một bài chi tiết hơn về công cụ này.

    » Xem thêm
  • Gòi gòi tới công chiện gòi 🤤🤤🤤

    » Xem thêm

Vấn đề

Học code từ những năm tháng còn là sinh viên, được tiếp xúc với nhiều ngôn ngữ lập trình, chúng ta biết cách chọn cho mình ngôn ngữ thích nhất, để sau này dùng nó như một kĩ năng chính của mình. Lúc đi làm nghe đồng nghiệp, anh em bạn bè bàn tán về ngôn ngữ này tốt hơn ngôn ngữ kia, ngôn ngữ này đáng học hơn... khiến bạn tò mò và khát khao một ngày nào đó sẽ sử dụng thành thạo tất cả mọi thứ.

Tôi từng có suy nghĩ sẽ code cả đời, bởi vì ngoài code ra tôi không biết còn có thể làm gì nữa, thế nên tôi cố gắng trau dồi kỹ năng code ngày một tốt hơn bằng cách không ngừng học hỏi, tìm kiếm những tài liệu liên quan. Bỗng một ngày chân ướt chân ráo nộp hồ sơ vào làm cho một công ty chuyên cung cấp sản phẩm dưới dạng SaaS, tại đây tôi được học hỏi thêm nhiều điều mới, những kiến thức mà tôi thấy như mở ra chân trời mới. Một trong số đó là khả năng tư duy sản phẩm.

Tư duy sản phẩm là gì?

Bạn có thể tìm kiếm Google để biết được khái niệm, còn đối với tôi hiện tại nó là biết cách tạo ra sản phẩm có giá trị cho người dùng. Thế nào là có giá trị? Là sản phẩm giải quyết được một vấn đề gì đó cho nhiều người dùng và họ thích sử dụng sản phẩm của bạn. Để làm được điều đó đòi hỏi bạn phải "thấu hiểu" người dùng, luôn phải cập nhật kiến thức bởi vì khách hàng của bạn luôn đổi mới.

Tôi là một developer, tôi thấy nhiều người rất thích đọc blog. Bản thân tôi lại là người thích viết lách thế nên tôi bắt đầu với nền tảng viết bài Blogger. Trải qua một thời gian sau đó, tôi nhận thấy Blogger quá nặng nề và phức tạp, khó có thể tuỳ biến mọi thứ theo cách mình muốn. Vì thế tôi quyết định tự làm cho mình một trang blog để giải quyết hết những vấn đề trên. Nhưng mọi thứ không hề đơn giản chút nào, tôi mất nhiều thời gian để phân tích xem tôi muốn gì và người dùng muốn gì, mất nhiều thời gian để phát triển và thu thập dữ liệu, cũng như phân tích chúng. Bù lại tôi đã học hỏi được nhiều điều khi tự làm blog.

Một developer có tư duy sản phẩm sẽ suy nghĩ về tính năng của sản phẩm theo hướng có thể khác với những người khác. Họ quan tâm đến người dùng hơn, tò mò về hành vi cũng như suy nghĩ của người dùng. Quan trọng hoá cách làm sao để người dùng hài lòng khi sử dụng sản phẩm. Cẩn trọng khi thêm một tính năng mới bởi vì họ biết một tính năng được thêm vào đồng nghĩa với độ phức tạp cũng tăng theo. Với họ trải nghiệm của người dùng là quan trọng hơn kỹ thuật để tạo ra sản phẩm.

Một tính năng gửi email, người dùng chỉ quan việc tâm đến việc họ gửi được email, còn bên kia sẽ nhận được một cách nhanh chóng, chứ không cần biết đằng sau đó là cả một hệ thống phức tạp mà bạn đã vất vả tạo ra. Nếu như hệ thống gửi email có vấn đề, bạn không thể giải thích một cách cặn kẽ cho họ hiểu lý do lỗi, còn họ cũng chỉ quan tâm khi nào email được gửi đi bình thường. Hay nếu như một tính năng quá phức tạp, quá nhiều bước để hoàn thành thử hỏi xem có mấy ai kiên nhẫn để thao tác hết trước khi họ thoát hẳn ứng dụng của bạn? Đối với tôi, một tính năng hay đó là không để người dùng phải suy nghĩ quá nhiều trước khi quyết định bấm vào nó.

Tại sao developer nên biết làm sản phẩm?

Có rất nhiều lý do để bạn cần quan tâm đến tư duy sản phẩm cũng như làm sản phẩm. Dưới đây là một số quan điểm của tôi về lợi ích của việc này.

  • Tiếp cận sản phẩm theo một cách mới. Trong vai một người dùng, bạn thấu hiểu được họ. Kỹ thuật lúc này không còn quá quan trọng nữa. Đó là một hướng tiếp cận khác lạ so với những người còn lại, khi họ luôn luôn cố gắng tối ưu những dòng code mà đôi khi quên mất trải nghiệm cho người dùng. Suy cho cùng các sản phẩm bạn làm ra là để phục vụ cho người dùng, trừ khi đó là sản phẩm phục vụ cho mỗi mình bạn.

  • Quan tâm đến doanh nghiệp, về hành vi người dùng và dữ liệu đó. Lúc này bạn cần quan tâm đến mô hình và tình hình kinh doanh của doanh nghiệp để biết đến tập khách hàng mà họ đang hướng đến. Đó là tiền đề cho tính năng và sản phẩm mà bạn chuẩn bị làm. Nhóm người dùng khác nhau sẽ có những hành vi khác nhau và dữ liệu thu thập được sẽ nói lên chúng khác nhau như thế nào. Hơn nữa điều đó sẽ giúp bạn thấu hiểu doanh nghiệp hơn để hướng đến một môi trường phù hợp với bản thân.

  • Luôn là tại sao? Tại sao phải thêm tính năng này, tại sao phải bỏ tính năng kia... nhiều câu hỏi tại sao và bắt buộc bạn phải tìm ra câu trả lời. Để làm được điều đó, bạn cần dựa vào rất nhiều thứ, một trong số đó là dữ liệu thu thập được, hay là "phản hồi" của người dùng khi họ sử dụng, từ đó rút ra câu trả lời cho mình.

  • Mở rộng domain, nghiệp vụ. Bạn nhận ra Developer không chỉ còn quan tâm đến code mà còn nhiều thứ khác nữa để tạo nên sự thành công cho bạn cũng như cho sản phẩm mà bạn đang phát triển. Điều này mở ra những hướng đi mới trong sự nghiệp phát triển. Biết đâu bạn sẽ không còn thích ngồi code nữa mà lại làm một công việc khác thì sao.

  • Kỹ thuật không còn là trên hết, cân bằng kỹ thuật với trải nghiệm người dùng. Thông thường khi đón nhận một vấn đề thì chúng ta thường suy nghĩ luôn giải pháp mà quên mất việc đánh giá vấn đề đó. Liệu trải nghiệm người dùng có gặp vấn đề gì khi giải pháp thiên về kỹ thuật hơn không? Có gây khó khăn hay mang lại trải nghiệm tồi cho họ chỉ vì muốn áp dụng công nghệ mới nhất? Một sản phẩm khó sử dụng chắc chắn không phải là một sản phẩm được nhiều người yêu thích, lúc đó buộc bạn phải cân bằng giữa kỹ thuật và trải nghiệm người dùng.

  • Có những suy nghĩ về sản phẩm như một người dùng. Trong vai người dùng sản phẩm bạn biết cách để tạo ra những tính năng làm sao "đáng giá" nhất cho người dùng. Để đạt được điều đó phải trải qua rất nhiều thời gian học hỏi, sử dụng những sản phẩm khác. Hình thành một thói quen phân tích, đánh giá khi sử dụng một sản phẩm mới. Đó là kho dữ liệu rất có ích cho bạn sau này.

  • Phát triển bản thân. Tạo ra một sản phẩm tốt không phải trong ngày một ngày hai, cũng không phải chỉ cần biết mỗi code. Đó là cả một quá trình nỗ lực học hỏi không ngừng nghỉ và buộc bạn phải luôn luôn đổi mới bản thân. Nhiều kiến thức phải học thêm đồng nghĩa với việc chúng ta cần cố gắng hơn nữa.

Tổng kết

Trên đây là những quan điểm của tôi về việc developer có thể đi xa hơn nữa bằng cách trang bị tư duy sản phẩm. Tôi là một developer với hy vọng sau này có thể làm ra một cái gì đó có ích cho cuộc sống này. Nhưng có lẽ trước mắt, tôi chỉ có thể chia sẻ kinh nghiệm, dù đúng dù sai vẫn mong nhận được phản hồi của tất cả mọi người.

Cao cấp
Hello

Bí mật ngăn xếp của Blog

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.

Bình luận (1)

Nội dung bình luận...
Avatar
Trịnh Cường2 năm trước
hay lắm bạn ơi, mình cũng có suy nghĩ như vậy
Trả lời
Avatar
Xuân Hoài Tống2 năm trước
Bạn đã có ý tưởng làm sản phẩm nào hay chưa bạn Cường
Bấm hoặc cuộn mạnh để sang bài mới