Kỹ năng thiết yếu để trở thành Product Manager (phần 2)

Ở phần trước, mình đã viết về những soft-skills cần thiết đối với một Product Manager (bạn có thể đọc lại phần một ở đây).

Trong phần hai này, mình sẽ nói về những hard-skills (hay technical skills) mà theo mình thì ở level Product Manager bắt buộc phải có.

Tuy vậy, có một vài điểm mình muốn chú thích một chút trước khi đi vào chi tiết.

# THỨ NHẤT LÀ, bản thân mình thấy những gì mình liệt kê ở đây (bao gồm cả bài này và bài trước), nó thay đổi theo thời gian mình làm việc, hay nói cách khác, là thay đổi khi mình ngày càng có thêm trải nghiệm – kinh nghiệm trong nghề. Bằng chứng là, mình thỉnh thoảng vẫn phải vào đây để update lại một chút về những gì mình đã từng viết, cốt để cho những gì mình chia sẻ tới các bạn được sát nhất với những gì mà thời điểm hiện tại mình cho là đúng.

# THỨ HAI LÀ, những skill này không chỉ cần thiết ở level Manager, mà cần thiết ở gần như tất cả các level trong career roadmap của một bạn làm nghề Product. Tuy thế, tùy vào level (cũng như phạm vi công việc tương ứng) mà mức độ thuần thục của mỗi skill sẽ được đòi hỏi ở những mức khác nhau.

• Ví dụ như, một Product Executive có thể phải rất thành thạo trong việc tài liệu hóa những yêu cầu kinh doanh thành yêu cầu kỹ thuật cho development team, nhưng có thể chỉ cần một mức độ hiểu biết sơ cấp (basic level) cho kỹ năng liên quan đến Product Strategy.
• Trong khi đó, những người ở vị trí Product Manager rồi thì cần thuần thục và phải giỏi trong kỹ năng nói trên, phải đủ khả năng để lên kế hoạch cho việc phát triển sản phẩm trong thời gian trung hạn tới dài hạn, hay phải có những hiểu biết nhất định trong việc định hướng chiến lược cho sản phẩm (Product Vision & Product Strategy).

# THỨ BA LÀ, những kỹ năng mà mình nói tới trong cả hai phần – là thiên về vị trí Product Manager trong một công ty product, không phải công ty outsource. Đa số các công ty outsource mà mình biết và có bạn bè làm trong đó thường không yêu cầu những kỹ năng giống hệt như những kỹ năng được yêu cầu cho một Product Manager làm tại công ty product.

# THỨ TƯ LÀ, những kỹ năng mà mình nói tới trong cả hai phần – là thiên về vị trí Product Manager cho công ty local, không phải công ty global nếu như bạn đang làm ở Việt Nam. Bạn sẽ thấy điều này rõ hơn nếu bạn từng làm qua vị trí này ở cả hai loại hình công ty trên. Thường thì ở công ty global (tại Việt Nam), ví dụ như Grab/ Baemin/ Shopee v.v…, bạn sẽ có ít cơ hội để tham gia build một sản phẩm qua đủ tất cả các giai đoạn trong vòng đời (product cycle) của nó, mà có thể bạn sẽ chỉ làm về ‘product localization’ – tinh chỉnh lại sản phẩm từ một sản phẩm gốc đã được xây dựng trước đó ở một quốc gia khác, để cho nó phù hợp hơn với thị trường và người dùng tại Việt Nam.

Tóm lại, bạn cứ tham khảo những tiêu chí (vẫn còn được mình tiếp tục update) ở bài viết này và kể cả bài trước để có một cái nhìn tổng quát nhất. Nhưng đừng quên là với mỗi loại hình công ty, mỗi level tương ứng, sẽ có sự điều chỉnh chứ không công ty nào giống công ty nào cả.

Đọc thêm bài viết: Kỹ năng thiết yếu để trở thành Product Manager (phần 1)

Quay lại chủ đề chính, vậy thì những hard-skills (hay technical skills) nào cần có ở vị trí PM?

Theo mình có một vài tiêu chí sau.

1- Domain knowledge

“Domain knowledge” hay “Domain insight” là sự am hiểu (sâu sắc) về lĩnh vực mà bạn đang làm. Sẽ rất khó để một Product Manager xây dựng và phát triển một sản phẩm khi không hiểu gì về thị trường và lĩnh vực của sản phẩm ấy, hiểu về đối thủ xung quanh, hiểu cách mà thị trường đang vận hành, cách mà những sản phẩm trong lĩnh vực này tạo ra giá trị và lợi nhuận dựa trên việc cung cấp một thứ gì đó hữu dụng cho người dùng.

Bản thân mình sau khi làm qua vài domain khác nhau, mình nhận thấy rằng việc sở hữu domain knowledge cũng như update thường xuyên domain knowledge là cực kỳ quan trọng. Khi đã ở level Product Manager, bạn không những phải hiểu rõ các phương pháp phân tích thị trường và đối thủ, mà còn phải hiểu sâu sắc về tất tần tật những yếu tố liên quan đến ngành mà bạn đang làm, cập nhật liên tục về xu thế của ngành nói riêng và thị trường nói chung. Việc này sẽ giúp bạn tăng ‘độ nhạy’ cho những thời điểm cần ra quyết định trong việc xây dựng chiến lược phát triển đúng đắn cho sản phẩm của mình.

Để ước lượng một khoảng thời gian cần thiết giúp bạn có vừa đủ ‘knowledge’ trong một domain nào đó, thì mình nghĩ cần ít nhất khoảng một năm. Đặc biệt, với những lĩnh vực có đặc thù phức tạp (thường là liên quan đến tài chính), cá nhân mình cho rằng sẽ cần lâu hơn một năm để bạn tự tin rằng mình hiểu đủ sâu và tường tận những gì đang xảy ra trong ngành, trong thị trường.

Vậy nên thông thường, nếu mình bắt đầu làm cho một domain mới, mình sẽ cố gắng kiên trì ít nhất là một năm để tiếp thu tối đa những kiến thức và hiểu biết cần có. Nếu mọi thứ tốt đẹp, và mình cảm thấy vẫn còn những thứ mình có thể học và phát triển, mình sẽ gắn bó lâu hơn và tiếp tục học thêm. Thường thì với mình, trung bình ba năm sẽ là một con số lý tưởng để cá nhân mình tự tin về domain knowledge ở một domain nào đó mà mình làm.

2- Business savvy

Như mình đã từng đề cập trong rất nhiều bài viết trước đây, mục tiêu cuối cùng của việc build sản phẩm vẫn là khiến sản phẩm được sử dụng, tạo ra giá trị cho người dùng, từ đó đem lại giá trị cho công ty đang sở hữu sản phẩm ấy.

Trừ khi bạn đang xây dựng sản phẩm thuộc các NPO (nonprofit organization – tổ chức phi lợi nhuận), thì có thể công ty của bạn (và bạn) sẽ không cần quan tâm đến câu chuyện tạo ra doanh thu từ sản phẩm. Ở các trường hợp còn lại, cuối cùng thì sản phẩm nào cũng hướng tới việc làm sao để đổi giá trị mà sản phẩm cung cấp cho người dùng thành một giá trị tài chính rõ ràng cho công ty.

Do vậy, sẽ là một điều thiết yếu đối với một Product Manager, về việc cần có ‘business savvy’ – và theo mình thì việc này không chỉ dừng lại ở sự hiểu biết về business, mà còn nằm ở cách tư duy, cách nhìn nhận vấn đề từ góc độ business trong những tình huống cần thiết (cần định hướng/ cần ra quyết định).

Đối với việc đáp ứng các nhu cầu từ business, thay vì chỉ tiếp nhận một cách bị động những mong muốn và nhu cầu của họ, một Product Manager có thể đứng ở thế chủ động hơn, ngồi cùng business sâu sát hơn ngay từ bước đầu của quá trình xây dựng business strategy. Trong những buổi này, Product Manager có thể lắng nghe, đưa ra thông tin, tư vấn dựa trên những am hiểu về thị trường, về sản phẩm và đặc biệt là về người dùng.

Những trao đổi như thế này không chỉ giúp cho business team và product team hiểu nhau hơn, từ đó dễ dàng cùng hiểu được mục tiêu chung, mà còn giúp cho Product Manager có thêm cơ sở để đánh giá về thứ tự ưu tiên của các công việc, cân bằng giữa nhu cầu người dùng và nhu cầu kinh doanh (vốn dĩ là thứ cần nhiều linh hoạt và nhạy bén trong từng tình huống), từ đó đưa ra một Product Roadmap hợp lý nhất.

Xem thêm: Khóa học Product Management – Quản lý sản phẩm cho người mới bắt đầu

3- Research

Research là một phần không thể thiếu trong việc phát triển sản phẩm. Với những công ty quy mô lớn và có team phát triển sản phẩm nhiều nhân sự, có thể sẽ có đội research riêng, đội này có thể cover từ Market & competitor research (nghiên cứu thị trường và đối thủ) tới cả User Research (nghiên cứu người dùng). Tuy nhiên, đa phần thì trong các công ty product, team product sẽ chịu trách nhiệm luôn phần research (với sự giúp đỡ của một vài team liên quan).

Trong khuôn khổ của bài này, mình muốn nhấn mạnh nhiều hơn về mảng User Research, vì đây là đầu vào rất quan trọng cho team product trong việc lên kế hoạch xây dựng một sản phẩm lấy người dùng làm trung tâm. Khi thực hiện nghiên cứu người dùng, ta mới có thể hiểu được nhu cầu hoặc khó khăn của họ, từ đó biết được mình nên build sản phẩm/tính năng gì và build nó như thế nào để phục vụ được những nhu cầu này một cách tốt nhất.

Một vài lưu ý rất phổ quát có thể bao gồm việc cần chuẩn bị một kế hoạch nghiên cứu cụ thể với một mục đích cụ thể, xác định rõ đối tượng cần nghiên cứu là ai và có tiêu chí nào để lựa chọn đối tượng tham gia nghiên cứu không, phạm vi cần nghiên cứu bao gồm những gì và để kiểm chứng những giả định nào, cũng như loại thông tin nào ta mong muốn đạt được sau khi nghiên cứu.

Ngoài ra, cần cố gắng giảm thiểu tối đa ảnh hưởng từ researcher’s bias (định kiến của người làm research) lên quá trình cũng như kết quả research (trong trường hợp bạn làm usability testing); hoặc khi thực hiện những research theo hình thức survey thì cần có một size tập đủ lớn để kết quả đủ độ tin cậy; hay khi làm depth interview (phỏng vấn sâu) thì cần có một kịch bản rõ ràng, những câu hỏi mang tính logic và chặt chẽ để tìm hiểu được chính xác những thông tin cần biết. Những thứ này bạn sẽ ngày càng có kinh nghiệm nhiều sau khi bạn đã tự mình tham gia triển khai nhiều buổi research, nên cũng đừng quá lo lắng.

Trong việc thực hiện user research, việc lựa chọn sử dụng phương pháp nào hay cách thực hiện mỗi phương pháp ra sao thực ra không quá khó. Bạn có thể tìm thấy các thông tin này rất nhiều ở trên mạng và có thể học để áp dụng theo.

Việc mà mình thấy khó hơn, là sau khi đã chọn được phương pháp phù hợp nhất với từng giai đoạn hoặc từng nhu cầu nghiên cứu rồi, ta cần hiểu rõ cách thức làm sao để triển khai nó thật chuẩn và từ đó lấy được những kết quả research giá trị, cụ thể là đủ độ tin cậy để xác thực lại những giả định ban đầu, giúp ta có được những kết luận và quyết định đúng đắn tiếp theo đó.

Thực hiện research tốt sẽ giúp người làm product có thêm nhiều dữ liệu để tham khảo và ra quyết định trong tất cả các giai đoạn cả trước, trong và sau khi release sản phẩm hoặc tính năng, cho nên đối với mình, đây là một kỹ năng mà PM nào cũng nên có. Và dù bạn có đang ở trong happy case là có riêng một team Research hỗ trợ thực hiện việc research này, thì bạn vẫn phải là người đi rất sát quá trình ấy để đảm bảo được rằng team research đang có kế hoạch nghiên cứu đúng với những gì bạn mong muốn tìm ra.

4- User Experience (UX)

Mình viết tới UX ngay sau phần Research là vì hai phần này khá liên quan tới nhau, khi mà phần lớn input cho việc tối ưu UX có thể lấy từ output của User Research.

Việc một Product Manager cần có skill về UX có lẽ là điều không cần bàn cãi rồi. Ở những công ty lớn như Sendo, team Product Design sẽ cover luôn phần UX, nhưng việc này cũng chỉ mới áp dụng trong khoảng một năm trở lại đây, còn trước đó thì Product Manager sẽ chịu trách nhiệm luôn về UX (ở tất cả những công ty trước đây mình làm cũng thế). Tuy nhiên, dù scope nằm ở team nào thì mình vẫn nghĩ UX là skill mà một Product Manager cần sở hữu, bởi điều đó sẽ giúp mình chủ động hơn rất nhiều trong các quyết định về sản phẩm.

Hơn nữa, UX cũng là một phạm trù khá rộng và không chỉ liên quan đến việc thiết kế (giao diện) như thế nào, mà còn liên quan đến thiết kế luồng tương tác và trải nghiệm cho người dùng sản phẩm ra sao v.v…, nên nếu Product Manager không có skill về mảng này, thì sẽ dễ rơi vào thế bị động khi cần build User Workflow hay Conceptual Model ban đầu, trước khi ngồi sâu với Product Design để tiến hành các công việc chi tiết.

5- Wireframe/Mock-up & Specifications writing 

Đây chính là kỹ năng mà mình thấy (một cách đáng ngạc nhiên) là vẫn có những Product Manager không hề thuần thục. Về sau này, mình nhận ra chuyện này thường xuất hiện nếu như Product Manager đó là một người chuyển từ một vị trí manager của một lĩnh vực gần gần với lĩnh vực product sang, nói cách khác là không phải một Product Manager đi lên từ các level thấp hơn trong cùng career roadmap của nghề product.

Trong khi đó, khả năng hiện thực hóa ý tưởng và các nhu cầu kinh doanh thành một tài liệu kỹ thuật với đủ thông tin để development team xây dựng thành một sản phẩm sử dụng được – là một trong những kỹ năng tối quan trọng của một người làm nghề product.

Khi ở level Product Manager, các bạn product đã cần phải rất thuần thục cách thức vẽ wireframe/mock-up bằng những công cụ như Axure, Figma v.v… (và những bản vẽ này cần có một UX tốt). Các bạn cũng sẽ cần có khả năng triển khai một cách xuất sắc việc mô hình hóa các use case, activity diagram, viết những đặc tả kỹ thuật ở mức độ chi tiết và chính xác cho các nghiệp vụ (từ đơn giản đến phức tạp) xuất hiện trong toàn bộ luồng tương tác của người dùng.

Ở một vài công ty, khi lên tới level Product Manager, bạn có thể không cần trực tiếp chuẩn bị các wireframe/mock-up hay viết các tài liệu kỹ thuật này nữa, mà sẽ đứng ở góc độ review và tư vấn cho team member dựa trên tài liệu mà những bạn này chuẩn bị. Việc này cũng đòi hỏi bạn phải có một nền tảng rất tốt trong việc tự mình triển khai những công việc này từ trước đó rồi, vì chỉ như thế thì bạn mới đủ khả năng đánh giá được (một cách nhanh chóng) về mức độ đáp ứng của tài liệu/bản vẽ, nhìn ra được có điểm gì chưa hợp lý, các chi tiết nào còn thiếu, những use case nào đang bị bỏ qua, hay những luồng tương tác nào vẫn còn có thể tối ưu.

6- Technical know-how

Đây là thứ mà mình có khá nhiều điều để nói.

Đầu tiên là, mình khẳng định rằng để làm một Product Manager chịu trách nhiệm build các digital products, bạn bắt buộc phải có đủ kiến thức về technical. Câu chuyện là, kiến thức này ở ngưỡng nào thì được coi là đủ?

Có khá nhiều quan điểm khi trả lời câu hỏi phía trên , nhưng chủ yếu vẫn theo một trong hai hướng:

1) Product Manager bắt buộc phải có technical background (học ngành Công nghệ thông tin, biết lập trình, có kinh nghiệm thực tế ở việc coding, từng là developer v.v…);

2) Product Manager không nhất thiết phải đi từ technical background, nhưng cần có đủ technical know-how.

Và dựa trên kinh nghiệm của mình, chỉ cần bạn ở mức 2 thôi cũng đã là đủ rồi.

Với những người ủng hộ quan điểm số 1, mình đã gặp qua nhiều và đã từng được chia sẻ nhiều về những suy nghĩ của các bạn ấy, nhưng tóm tắt một cách ngắn gọn thì: Product Manager chả biết gì về tech, không biết viết một dòng code nào, thì không thể làm product và build các sản phẩm công nghệ được v.v…

Tuy nhiên trên thực tế, mình thấy điều đó không đúng.

Mình đã gặp nhiều bạn Product Manager có background về technical nhưng vẫn không thể hoặc gặp khó khăn nhiều trong khi làm việc dưới vai trò là một người ở nhánh product. Trong vài tình huống, việc trao đổi giữa một bạn tech và một bạn product chuyển thành cuộc tranh luận liên quan đến chỉ mình technical (bởi vì bạn Product Manager hiểu rất rõ về tech – hoặc ít nhất là bạn ấy nghĩ thế, nên bạn can thiệp luôn cả vào việc nên viết code thế nào, xử lý issue ra sao v.v…).

Thậm chí có trường hợp mình thấy Product Manager còn chọc thẳng vào sửa code – mà điều ấy thực sự là không nên một chút nào. Vì vậy, mình vẫn ủng hộ quan điểm người nào việc nấy, chuyên môn về technical thì hãy để các bạn tech team xử lý thôi, và đối với một Product Manager, vị trí này đòi hỏi bạn biết nhiều kỹ năng khác nữa chứ không phải chỉ mình tech.

Note: Nếu bạn search trên LinkedIn về profile của các Product Manager ở những big tech companies trong nhóm FAANG (Facebook, Amazon, Apple, Netflix, Google), bạn sẽ thấy các Product Manager này có background từ rất nhiều mảng khác nhau, có thể là kinh doanh, tư vấn, luật, quản trị v.v… chứ không nhất thiết phải học về lập trình hoặc các lĩnh vực tương tự.

Đọc thêm bài viết: Học gì để trở thành Product Owner?

Quay trở lại câu chuyện về việc tại sao một Product Manager không cần có background về tech, nhưng vẫn cần có technical know-how.

Đầu tiên là, ở giai đoạn discuss với business/ operations team (stakeholders nói chung), bạn sẽ có thể hình dung luôn được những công việc cần làm, ước lượng một cách bao quát về khối lượng công việc và thời gian cần có để triển khai, đề xuất các giải pháp tức thời chung dựa trên hiểu biết về sản phẩm cũng như kiến thức về tech.

Ở giai đoạn tạo các Product Backlog items (PBI) cho team triển khai, bạn sẽ dễ dàng hình dung được dự án cần làm những gì, đụng tới phần nào (front-end? back-end? platform? app? v.v…), và cũng hình dung được luôn team nào sẽ triển khai các phần này, ai là người bạn cần đi nói chuyện để hỏi thêm thông tin và check thêm về các solution tiềm năng hoặc các khó khăn kỹ thuật nếu có.

Trong suốt quá trình chạy dự án, việc hiểu về technical cũng giúp bạn support team dev trong quá trình triển khai, hiểu được các bug đang xảy ra như thế nào và tại sao, bạn cần làm những thao tác gì để kiểm thử sản phẩm trên mỗi môi trường phát triển. Nhưng hơn cả, là khi bạn hiểu về tech và có thể nói chung ngôn ngữ với team tech, bạn có thể giao tiếp tốt hơn với team và đặc biệt là dễ thấu hiểu, dễ cảm thông hơn với đồng đội của bạn trước những tình huống khó khăn nào đó mà tech team chưa thể xử lý.

Nếu bạn mới ở giai đoạn vào nghề và muốn hướng tới vị trí Product Manager, muốn hiểu thêm về cách để phát triển technical know-how nếu bạn không phải người đi từ background technical, thì mình cũng từng viết một bài mà bạn có thể đọc lại ở đây. 

7- Data. A good sense of data.

Data là một thứ mà nhiều Product Manager có-khả-năng-sẽ-bỏ-quên, nhất là nếu làm cho các công ty outsource. Việc không ngó ngàng tới data có khả năng sẽ trở thành một quán tính, bởi thứ mà bạn cam kết với khách hàng thường sẽ chỉ là release date và một sản phẩm đáp ứng đủ tính năng được yêu cầu, sau đó là tiếp tục maintain về mặt hệ thống ở một mức độ nhất định, chứ ít khi là chỉ số liên quan đến performance của sản phẩm ấy.

Nếu làm cho công ty product, câu chuyện này sẽ khác. Khi là Product Manager ở một công ty product, thứ bạn cần quan tâm sẽ không chỉ là xây dựng và bàn giao sản phẩm đúng hạn, đúng yêu cầu, mà còn là theo dõi các chỉ số thể hiện sức khỏe và chất lượng của sản phẩm, đảm bảo sản phẩm đang đi đúng mục tiêu và đạt được các success metrics – các chỉ số thành công đã đề ra.

Nhanh nhạy với data sẽ giúp một Product Manager rất nhiều trong quá trình quản lý sản phẩm, mà cụ thể là cho:

• data-driven decision making – ra quyết định dựa trên dữ liệu.
  • Thông thường, sẽ có những tình huống mà ta có thể đưa ra quyết định dựa trên việc phân tích và suy luận logic bằng tư duy đơn thuần.
  • Tuy nhiên, trong nhiều trường hợp khác, ta cần có dữ liệu để có một căn cứ tin cậy hơn khi vạch ra những bước mà ta sẽ làm tiếp theo.
• hypothesis validation – kiểm nghiệm lại các giả định.
  • Trong nhiều trường hợp, bạn có thể cảm thấy một phần của tính năng không đủ tốt vì lý do nào đó mà bạn không biết, hoặc nghĩ rằng làm theo option A có thể sẽ tốt hơn option B.
  • Những lúc này, thường thì ta sẽ chạy các a/b testing và sau đó việc đánh giá những data thu được sẽ giúp bạn kiểm chứng lại các giả định mà trước đó chỉ dừng ở mức phân tích và suy đoán.
• product success measurement – đo lường mức độ thành công của sản phẩm.
  • Điều này cũng quá hiển nhiên rồi, bởi nếu chỉ quá tập trung vào làm mà không quan tâm đến việc đo đạc, kiểm chứng xem những gì mình làm có đủ tốt, bạn sẽ luẩn quẩn mãi trong một nỗ lực cho ra nhiều sản phẩm hoặc tính năng nhất có thể, nhưng không biết rằng nó có đóng góp gì vào target của sản phẩm nói riêng và target của business/của công ty nói chung hay không.
  • “You can’t manage what you can’t measure” – said Peter Drucker.

Cuối cùng thì, nói chuyện bằng số bao giờ cũng có cảm giác chắc chắn hơn, nhưng không phải lúc nào dựa vào số cũng là chính xác, và không phải lúc nào cũng có số để nhìn, nhất là khi những tính năng/ sản phẩm bạn làm liên quan nhiều tới cảm xúc, tâm lý của con người.

Rất nhiều hệ quy chiếu cố gắng quy đổi các bậc của cảm xúc thành một tập data có thể định lượng, mà thường gặp nhiều nhất chính là các bài survey yêu cầu người dùng đánh giá mức độ hài lòng theo thang điểm từ 1 đến 5, từ 1 đến 10, từ một mức độ cảm nhận này tới một mức độ cảm nhận khác v.v…

Mọi sự quy đổi liên quan đến cảm xúc, đều chỉ mang tính tương đối, và đây mới chỉ là một ví dụ nhỏ thôi về việc data đôi khi sẽ không thể hiện chính xác thứ đang thực sự diễn ra.

Do đó, với tùy từng trường hợp, ta sẽ cần kết hợp việc phân tích cả data lẫn những dữ liệu khác mà ta có, để đi đến một kết luận hợp lý cuối cùng cho bài toán đang cần tìm lời giải.

—

Trên đây là những gì mình hệ thống lại được cho tới thời điểm này, rất có thể trong tương lai sẽ còn update thêm. Mình hy vọng bài viết này giúp ích phần nào cho các bạn có mong muốn đi tiếp tới level Product Manager, và một ngày nào đó chúng ta có cơ hội làm việc như những người đồng đội, cùng nhau.

Cám ơn bạn đã đọc bài. Đừng quên like và share nếu bạn thấy bài viết hữu ích nhé!

—

Đọc thêm các bài viết về nghề Product Management:

• The team series – Product Owner là ai?
• Học gì để trở thành Product Owner?
• Hành trình trở thành Product Manager từ con số 0

Xem thêm: Khóa học Product Management – Quản lý sản phẩm cho người mới bắt đầu