Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
KỸ Năng Chuyên Ngành создатель Mind Map: KỸ Năng Chuyên Ngành

1. SCRUM

1.1. Tạo sản phẩm chất lượng

1.1.1. Product Backlog

1.1.1.1. Product Backlog là gì

1.1.1.1.1. là nơi lưu trữ các tính năng mong muốn của sản phẩm

1.1.1.1.2. là 1 phần rất quan trọng trong Scrum

1.1.1.2. Ai quản lý Product Backlog

1.1.1.2.1. PO là người chịu trách nhiệm quán lý và bảo trì Product Backlog

1.1.1.3. Các hạng mục Product Backlog

1.1.1.3.1. Chứa

1.1.1.3.2. Thể hiện hạng mục Product Backlog - User Story

1.1.1.3.3. được sắp xếp dựa theo độ ưu tiên

1.1.1.3.4. mỗi hạng mục Product Backlog cần được ước tính kích thước - lượng nỗ lực cần để triển khai nó

1.1.1.4. tiêu chuẩn DEEP cho Project Backlog - tiêu chuẩn để xây dựng 1 Project Backlog tốt

1.1.1.4.1. Detail Appropriately

1.1.1.4.2. Estimated

1.1.1.4.3. Emergent

1.1.1.4.4. Prioritized

1.1.1.5. sự tiến hóa của Project Backlog

1.1.1.5.1. ban đầu

1.1.1.5.2. được làm mịn

1.1.1.5.3. sẵn sàng

1.1.1.5.4. kết thúc Sprint 1

1.1.1.5.5. việc cập nhật và làm mịn này được diễn ra liên tục để đảm bảo PB luôn ở trạng thái sẵn sàng, giúp cho hoạt động sản xuất được thông suốt

1.1.2. Sprint Backlog

1.1.2.1. Sprint Backlog là gì

1.1.2.1.1. là bảng công việc được Nhóm Phát triển sử dụng để quản lý quá trình sản xuất trong 1 Sprint

1.1.2.1.2. nội dung cơ bản của 1 Sprint Backlog bao gồm

1.1.2.2. Ai quản lý Sprint Backlog

1.1.2.2.1. Sprint Backlog là do Nhóm Phát triển sở hữu và vận hàng

1.1.2.3. Cấu trúc cơ bản của Sprint Backlog

1.1.2.3.1. các trình bày dưới dạng 1 bảng truyền thống - có thể sử dụng bảng tính truyền thống

1.1.2.3.2. bảng Kanban được sử dụng nhiều vì tính đơn giản và hiệu quả

1.1.2.4. Công cụ quản lý Backlog

1.1.2.4.1. đối với nhóm làm cùng nhau thì nên sử dụng bảng vật lý

1.1.2.4.2. nhóm có thể sử dụng các công cụ trực tuyến khác như

1.1.3. Khái niệm phần tăng trưởng của sản phẩm

1.1.3.1. Phần tăng trưởng là gì?

1.1.3.1.1. là tên gọi ngắn của phần tăng trưởng có khả năng chuyển giao được

1.1.3.1.2. là phần sản phẩm Nhà Phát triển tạo ra cuối mỗi Sprint

1.1.3.1.3. đây là 1 định nghĩa khiến cho Agile khác hoàn toàn so với quy trình phát triển phần mềm truyền thống

1.1.3.2. Các đặc điểm của Phần tăng trưởng

1.1.3.2.1. sử dụng được

1.1.3.2.2. có khả năng chuyển giao được

1.1.3.2.3. phần tăng trưởng phải tuân theo định nghĩa hoàn thành đã được Nhóm phát triển và PO thống nhất trước đó

1.1.3.3. Tại sao bạn cần phần tăng trưởng

1.1.3.3.1. SỚm có được phản hồi từ người dùng/khách hàng

1.1.3.3.2. sớm thu được giá trị từ sản phẩm

1.1.3.3.3. gia tăng tính minh bạch trong quá trình sản xuất

1.1.3.3.4. giúp giảm thiểu rủi ro

1.1.3.4. Làm sao để có được phần tăng trưởng

1.1.3.4.1. nhóm phát triển có đảm bảo tính liên chức năng để hoàn thành các công việc theo định nghĩa hoàn thành hay không

1.1.3.4.2. Product backlog có được xây dựng hợp lý để hỗ trợ việc phát triển tăng dần hay không

1.1.3.4.3. Nhóm phát triển cần biết cách lập kế hoạch Sprint tốt nhằm thuận lợi trong việc tạo ra phần tăng trưởng

1.1.3.4.4. Nhóm phát triển có vận hành tốt để đạt được mục tiêu chung hay không?

1.1.3.4.5. công cụ hỗ trợ có tốt không

1.1.3.4.6. khung thời gian của Sprint có đủ dài không?

1.1.4. Định nghĩa hoàn thành

1.1.4.1. định nghĩa hoàn thành là gì

1.1.4.1.1. là một danh sách quy định những công việc thực hiện xong trước khi một hạng mục được công nhận là đạt trạng thái có khả năng chuyển giao được

1.1.4.2. tại sao chúng ta cần định nghĩa hoàn thành

1.1.4.2.1. đảm bảo một cách hiểu chung, gia tăng tính minh bạch trong phát triển

1.1.4.2.2. ngăn ngừa 1 số mâu thuẫn xảy ra trong giao tiếp khi đề cập đến trạng thái hoàn thành của các hạng mục

1.1.4.2.3. nâng cao chất lượng sản phẩm

1.1.4.3. xậy dựng định nghĩa hoàn thành phụ thuộc vào

1.1.4.3.1. đặc điểm của sản phẩm

1.1.4.3.2. công nghệ và kỹ thuật đang được sử dụng

1.1.4.3.3. các quy định của tổ chức

1.1.4.3.4. trình độ Nhóm phát triển

1.1.4.4. định nghĩa hoàn thành cho những cấp độ khác nhau

1.1.4.4.1. cơ bản

1.1.4.4.2. nâng cao

1.1.4.4.3. user story - định nghĩa sẵn sàng

1.1.4.4.4. công việc trong Sprint

1.1.4.4.5. phiên bản phát hành

1.1.4.5. định nghĩa hoàn thành và tiêu chí chấp nhận

1.1.4.5.1. định nghĩa hoàn thành

1.1.4.5.2. tiêu chí chấp nhận

1.1.4.5.3. một hạng mục chỉ được công nhận là hoàn thành khi nó đáp ứng các định nghĩa hoàn thành chung và tiêu chí chấp nhận riêng cho từng hạng mục đó

1.1.4.5.4. ví dụ

1.2. Tổ chức nhóm làm việc

1.2.1. Các vai trò trong Scrum

1.2.1.1. Product Owner tối ưu hóa gúa trị của sản phẩm

1.2.1.1.1. Quản lý Product Backlog, sắp xếp chúng sao cho hợp lý

1.2.1.1.2. chịu trách nhiệm định hướng sản phẩm

1.2.1.1.3. Chi tiêt

1.2.1.2. Nhóm phát triển có nhiệm vụ làm việc và chuyển giao hạng mục trong Product Backlog thành các phần tăng trưởng ở cuối mỗi sprint

1.2.1.2.1. vai trò của Nhóm Phát triển

1.2.1.2.2. tính tự tổ chức

1.2.1.2.3. tính liên chức năng

1.2.1.2.4. độ lớn của nhóm phát triển

1.2.1.2.5. tính ổn định của nhóm

1.2.1.2.6. đóng góp của nhóm phát triển trong việc định hình sản phẩm

1.2.1.3. Scrum Master đảm bảo Scrum hoạt động tốt thông qua việc tuân thủ các nguyên lý, kỹ thuật, quy tắc của Scrum

1.2.1.3.1. Giúp nhóm giải quyết khó khăn trong quá trình sản xuất, tạo điều kiện cho nhóm làm việc tốt

1.2.1.3.2. không phải là quản lý của nhóm

1.2.1.3.3. là một lãnh đạo theo phong cách phục vụ (servant leader). Các đối tượng phục vụ của ScrumMaster gồm

1.2.1.3.4. Làm thế nào để trở thành một ScrumMaster tốt

1.2.2. Các đặc điểm của nhóm Scrum

1.2.2.1. cần được trao quyền dưới hình thức tự tổ chức, có toàn quyền lựa chọn và quyết định những gì mình cần làm để đạt kết quả cao nhất mà không phải dựa vào sự chỉ đạo của bất cứ ai bên ngoài nhóm

1.2.2.2. tính tự tổ chức

1.2.2.2.1. nhóm Scrum lựa chọn và cam kết phần sản phẩm họ sẽ sản xuất và chuyển giao ở cuối mối sprint

1.2.2.2.2. từ cam kết đó nhóm sẽ tự phân tích và lên kế hoạch cho chính mình

1.2.2.2.3. nhóm cũng có quyền quyết định trật tự các hạng mục công việc mà mình sẽ thực hiện

1.2.2.3. liên chức năng

1.2.2.3.1. nhóm có đầy đủ các chức năng cần thiết để hoàn thành và chuyển giao các hạng mục mà không cần đến sự trợ giúp từ bên ngoài

1.2.2.3.2. không phân biệt dựa theo chuyên môn của mình như kiểm thử viên, nhà thiết kế, nhà kiến trúc mà được gọi chung là thành viên nhóm scrum

1.3. Vận hành quy trình hoạt động hiệu quả và chất lượng

1.3.1. Lập kế hoạch Sprint

1.3.1.1. Các sự kiện trong Scrum

1.3.1.1.1. Toàn bộ khoảng thời gian của Scrum sẽ diễn ra trong 1 Sprint, mỗi Sprint này sẽ diễn ra trong 1 tháng hoặc ít hơn, một Sprint mới bắt đầu ngay sau khi 1 Sprint trước khép lại

1.3.1.1.2. Mỗi Sprint có thể coi là 1 tiểu dự án trong đó diễn ra các hoạt động như

1.3.1.2. Lập kế hoạch Sprint

1.3.1.2.1. Xác định mục tiêu Sprint

1.3.1.2.2. Lên kế hoạch cần thực hiện trong Sprint

1.3.1.2.3. trả lời các câu hỏi

1.3.1.2.4. độ dài của buổi lập Sprint

1.3.1.3. Phần 1: Chúng ta sẽ làm gì trong Sprint này?

1.3.1.3.1. toàn bộ thành viên Scrum phải tham gia phần đầu của sự kiện

1.3.1.3.2. kết quả của phần này là mục tiêu Sprint với các hạng mục trong Product Backlog để phát triển trong Sprint

1.3.1.3.3. quá trình

1.3.1.4. Phần 2: Chúng ta sẽ làm như thế nào?

1.3.1.4.1. PO có thể vắng mặt nhưng phải luôn sẵn sàng hỗ trợ nhóm phát triển để làm rõ các hạng mục khi cần thiết

1.3.1.4.2. kết quả của phần này là Sprint Backlog - tức là bảng công việc được Nhóm phát triển sử dụng trong suốt Sprint

1.3.1.4.3. nhóm phát triển ước tính nỗ lực cho từng công việc một

1.3.1.4.4. nếu nhóm phát triển thấy lượng công việc quá nhiều hoặc quá ít có thể thương lượng với PO để thêm hoặc bớt công việc

1.3.1.4.5. Nhóm phát triển cũng có thể nhờ thêm trợ giúp kĩ thuật từ ngoài để phục vụ cho việc sản xuất

1.3.1.5. Bắt đầu sản xuất

1.3.1.5.1. diễn ra với hình thức tự tổ chức

1.3.2. Ước tính

1.3.2.1. Ước tính là gì

1.3.2.1.1. là việc dự đoán độ lớn của 1 hạng mục sẽ được phát triển

1.3.2.2. Tại sao cần phải ước tính

1.3.2.2.1. để lập kế hoạch sản xuất một cách hiệu quả

1.3.2.2.2. trả lời cho câu hỏi

1.3.2.3. Ai thực hiện việc ước tính

1.3.2.3.1. được ước tính bởi nhóm phát triển

1.3.2.3.2. tăng tính chính xác của ước tính

1.3.2.3.3. một vài cách thức ước tính

1.3.2.4. Các đơn vị được sử dụng trong ước tính

1.3.2.4.1. số lượng dòng mã

1.3.2.4.2. số điểm chức năng

1.3.2.4.3. số điểm tương đối

1.3.2.4.4. thời gian lý tưởng

1.3.2.5. Ước tính các hạng mục Product Backlog

1.3.2.5.1. thời điểm

1.3.2.5.2. ước tính lại

1.3.2.6. Ước tính các hạng mục công việc trong Sprint

1.3.2.6.1. có thể kết hợp ước tính bằng điểm tương đối và thời gian lý tưởng

1.3.3. Planning Poker

1.3.3.1. Planning Poker là gì

1.3.3.1.1. là một kỹ thuật hiệu quả và phổ biến, được sử dụng để ước tính

1.3.3.1.2. dựa trên cả 3 cách

1.3.3.1.3. việc sử dụng Planning Poker khá nhanh chóng và đem lại kết quả khá tin cậy

1.3.3.2. Cách tiến hành Planning Poker

1.3.3.2.1. chuẩn bị các bộ bài Planning Poker dành cho các thành viên

1.3.3.2.2. tất cả các thành viên đều tham gia buổi ước tính sử Planning Poker, các thành viên có các kỹ năng khác nhau

1.3.3.2.3. PO tham gia phiên ước tính nhằm làm rõ các hạng mục chứ không trực tiếp tham gia vào việc ước tính

1.3.3.2.4. Ước tính

1.3.3.3. Chia thành nhiều nhóm ước tính

1.3.3.3.1. khi có quá nhiều hạng mục cần ước tính thì nên chia nhóm thành các nhóm nhỏ để cùng ước tính

1.3.3.3.2. số lượng của mỗi nhóm nhỏ là phải có từ 3 thành viên trở lên

1.3.3.3.3. ban đầu các nhóm nhỏ cần ước tính cùng với nhau để hiểu được độ lớn của Point cơ sở

1.3.3.3.4. các điểm số ở các team có giá trị như nhau

1.3.3.4. Planning Poker cho nhóm phân tán

1.3.3.4.1. sử dụng 1 công cụ Planning Poker trực tuyến để sử dụng

1.3.4. Scrum hằng ngày

1.3.4.1. Mục đích của Scrum hằng ngày

1.3.4.1.1. đây là buổi trao đổi ngắn ko quá 15 phút

1.3.4.1.2. mục đích giúp nhóm phát triển

1.3.4.1.3. để tránh cho việc phức tạp cần diễn ra tại 1 địa điểm cùng 1 khung thời gian

1.3.4.2. Những ai tham gia?

1.3.4.2.1. danh cho nhóm phát triển

1.3.4.2.2. SM tham dự chỉ để đảm bảo nhóm thực hiện đúng công việc này

1.3.4.2.3. PO và lãnh đạo có thể tham dự nhưng chỉ được lắng và không đóng bất cứ vai trò nào

1.3.4.3. 3 câu hỏi cần trả lời

1.3.4.3.1. tôi đã làm được gì

1.3.4.3.2. tôi sẽ làm gì

1.3.4.3.3. tôi gặp khó khăn gì

1.3.4.4. những vấn đề cần tránh

1.3.4.4.1. tránh lan man

1.3.4.4.2. scrum hằng ngày thành buổi báo cáo lãnh đạo

1.3.4.4.3. scrum hằng ngày thành buổi báo cáo với Scrum Master

1.3.4.4.4. Scrum hằng ngày trở thành 1 phiên thảo luận để giải quyết các vấn đề

1.3.4.4.5. Scrum hằng ngày diễn ra quá xa nơi làm việc điều này khiến mất thời gian và gây khó khăn cho việc tổ chức Scrum hằng ngày

1.3.4.4.6. Nhóm phát triển không thấy giá trị của Scrum hằng ngày

1.3.4.4.7. các thành viên thường báo cáo là không gặp vấn đề gì kể cả có các dấu hiếu không ổn trong sản xuất

1.3.4.5. hoạt động scrum hằng ngày để

1.3.4.5.1. cập nhật tiến độ

1.3.4.5.2. thanh tra

1.3.4.5.3. thích nghi

1.3.4.6. nhiệm vụ của SM trong Scrum hằng ngày

1.3.4.6.1. đảm bảo thuận lợi nhất cho nhóm tiến hành sự kiện

1.3.5. Sơ kết Sprint

1.3.5.1. Mục đích

1.3.5.1.1. đây là 1 hoạt động thanh tra và thích nghi sản phẩm

1.3.5.1.2. kết thúc buổi sơ kết Sprint thì lộ trình Product Backlog có thể được điều chỉnh để phù hợp hơn với tình hình phát triển mới

1.3.5.2. thành phần tham dự

1.3.5.2.1. Nhóm phát triển

1.3.5.2.2. Product Owner

1.3.5.2.3. Scrum Master

1.3.5.3. thời gian

1.3.5.3.1. thời gian tối đa được đóng khung trong 1h tương ứng với 1 tuần làm việc của Sprint

1.3.5.4. kiểm tra kết quả Sprint

1.3.5.4.1. nhóm phát triển và PO trao đổi và nắm tình hình của nhau

1.3.5.4.2. bắt đầu PO trình bày tổng quan về các hạng mục trong Product backlog được lựa chọn đã hoàn thành và các hạng mục chưa được hoàn thành

1.3.5.4.3. nhóm phát triển trình bày

1.3.5.5. trực tiếp sử dụng sản phẩm

1.3.5.5.1. đây là cơ hội để người tham gia trực tiếp thanh tra kết quả của Sprint

1.3.5.5.2. rà soát Product Backlog và thị trường xác định các thay đổi có thể có

1.3.5.5.3. kết quả của quá trình ra soát là đưa ra Product Backlog mới đã được sắp xếp phù hợp với các Sprint tiếp theo

1.3.5.5.4. nếu có những thay đổi lớn ảnh hưởng tiến độ của sản phẩm cần cập nhật lại tiến độ phát hành của sản phẩm

1.3.5.6. hiểu lầm nên tránh

1.3.5.6.1. đây là buổi demo sản phẩm, thực ra đây chỉ là 1 hạng mục trong buổi sơ kết Sprint

1.3.5.6.2. nếu chỉ tập trung vào demo sản phẩm sẽ bỏ qua 1 hoạt động quan trọng khác là THẢO LUẬN giữa các thành viên tham gia

1.3.5.7. điều chỉnh sản phẩm

1.3.6. Cải tiến Sprint

1.3.6.1. Mục đích của buổi Cải tiến Sprint

1.3.6.1.1. là buổi diễn ra vào cuối sprint, ngay sau buổi sơ kết Sprint

1.3.6.1.2. mục đích là thanh tra và thích nghi qui trình làm việc

1.3.6.2. Thành phần tham dự

1.3.6.2.1. Nhóm Phát triển

1.3.6.2.2. Scrum Master

1.3.6.2.3. Không bắt buộc

1.3.6.3. Thời gian

1.3.6.3.1. Sprint 1 tháng: 3 giờ

1.3.6.3.2. Sprint 2 tuần: 1h 30 phút

1.3.6.3.3. 45p cho 1 tuần

1.3.6.4. Nội dung của buổi Cải tiến Sprint

1.3.6.4.1. ScrumMaster(hoặc người khác bên ngoài nhóm) hỗ trợ buổi cải tiến

1.3.6.4.2. liệt kê những điểm đã làm tốt

1.3.6.4.3. liệt kê những điểm đã làm chưa tốt

1.3.6.4.4. đưa ra các hành động để cải tiến

1.3.6.4.5. nên tránh cách làm không tốt

1.3.6.4.6. một số kỹ thuật cải tiến Sprint

1.3.6.5. Kỹ thuật Glad, Sad, Mad

1.3.7. Làm mịn Product Backlog

1.3.7.1. Mục đích của hoạt động làm mịn Product Backlog

1.3.7.1.1. mục đích phân tách các hạng mục lớn thành hạng mục nhỏ hơn

1.3.7.1.2. phân tích tìm hiểu các hạng mục

1.3.7.1.3. tái ước lượng kích thước

1.3.7.1.4. tái đánh giá độ ưu tiên của các hạng mục nhằm chuẩn bị sẵn sàng đưa vào sản xuất trong các Sprint sắp tới

1.3.7.2. Ai thực hiện?

1.3.7.2.1. diễn ra với sự cộng tác của nhiều bên bao gồm

1.3.7.3. Thời gian

1.3.7.3.1. hoạt động này được Product Owner liên tục cập nhật với các bên liên quan

1.3.7.3.2. đối với Nhóm Phát triển tổng thời gian dành cho hoạt động này không nên vượt quá 10% 1 Sprint

1.3.7.4. Làm mịn Product Backlog như thế nào?

1.3.7.4.1. chia nhỏ, phân tách các hạng mục Product Backlog

1.3.7.4.2. thêm các chi tiết cần thiết cho từng hạng mục (xác định tiêu chí chấp nhận)

1.3.7.4.3. ước tính độ lớn của các hạng mục

1.3.7.5. Tổ chức buổi làm mịn Product Backlog

1.3.7.5.1. thường tổ chức vào giữa hoặc cuối Sprint hiện tại để chuẩn bị cho Sprint tiếp theo

1.3.7.5.2. do nhóm Phát triển tổ chức

1.3.7.5.3. cách đánh giá buổi làm mịn Product Backlog có hoạt động tốt hay không?

1.3.7.6. Sự tiến hóa của Product Backlog

1.3.7.6.1. thời điểm ban đầu

1.3.7.6.2. sau đó

1.3.7.6.3. khi sprint 1 kết thúc, các hạng mục cho Sprint thứ 2 đã được làm mịn, sẵn sàng cho việc đưa vào xây dựng sản xuất

1.3.8. Theo doi tiến độ sản phẩm

1.3.8.1. Tại sao cần theo dõi tiến độ Sản phẩm

1.3.8.1.1. tiến độ sản phẩm như thế nào luôn là câu hỏi mà các bên liên quan quan tâm

1.3.8.1.2. nắm được tiến độ sản phẩm sẽ đưa ra các điều chỉnh hợp lý liên quan đến lộ trình phát triển của sản phẩm

1.3.8.2. Ai theo dõi tiến độ sản phẩm

1.3.8.2.1. Product Owner là người chịu trách nhiệm chính trong việc theo dõi tiến độ sản phẩm và hải đảm bảo tiến độ sản phẩm phải minh bạch với tất cả các bên liên quan

1.3.8.2.2. khi bắt đầu xây dựng 1 sản phẩm chúng ta xây dựng Kế hoạch phát hành cho sản phẩm dựa vào các hạng mục yêu cầu của khách hàng

1.3.8.2.3. để theo dõi tiến độ sản phẩm hướng đến mục tiêu, các nhóm thường sử dụng 1 chỉ số quan trọng là lượng nỗ lực còn lại để hoàn thành bản phát hành

1.3.8.3. Sử dụng BIểu đồ Phát hành Burndown

1.3.8.3.1. trục ngang

1.3.8.3.2. trục dọc

1.3.8.3.3. ví dụ

1.3.8.3.4. chúng ta có thể vẽ đường biểu đồ lý tưởng trong biểu đồ Burndown

1.3.8.3.5. các công cụ sử dụng biểu đồ Burndown

1.3.9. Theo dõi tiến độ Sprint

1.3.9.1. Tại sao phải theo dõi tiến độ Sprint

1.3.9.1.1. Scrum hoạt động dựa trên tính thực nghiệm, tất cả các hoạt động của Scrum dựa vào 3 trụ cột là minh bạch, thanh tra và thích nghi

1.3.9.1.2. nâng cao tính minh bạch hằng ngày dựa vào Scrum hằng ngày, trong đó sự cộng tác, tính tự giác cần được duy trì, theo dõi

1.3.9.2. Ai theo dõi tiến độ Sprint

1.3.9.2.1. đây là công việc của nhóm phát triển vì họ làm việc theo hình thức tự tổ chức

1.3.9.2.2. nhóm cần phải

1.3.9.3. Theo dõi tiến độ Sprint như thế nào

1.3.9.3.1. thường xuyên cập nhật Sprint Backlog

1.3.9.3.2. sử dụng biểu đồ Sprint burndown

2. Web

2.1. Web Builder

2.1.1. Thrive

2.1.2. Elementor

2.1.2.1. Khóa học trên kênh YT

2.1.2.1.1. 1- Hướng dẫn cho người mới bắt đầu (9)

2.1.2.1.2. 2- Yếu tố 101

2.1.2.1.3. 3- Hiệu ứng chuyển động

2.1.2.1.4. 4- Hướng dẫn xây dựng popup

2.1.2.1.5. 5- Hướng dẫn Xây dựng Chủ đề

2.1.2.1.6. 6- Nghệ thuật tốc độ xây dựng web

2.1.2.1.7. I- hướng dẫn xây dựng website trong 1h

2.1.3. Clone 1 web mới từ đầu

2.1.3.1. Lấy từ link của Thạch Phạm

2.1.3.2. 2- crack Elementor ( hiện ko thể hack đc load template)

2.1.3.2.1. Sửa 2 file

2.2. Traffic

2.2.1. Google Analytics

2.2.2. Facebook

2.2.3. Zalo

2.2.4. Tictok

3. Chatbot

3.1. Kịch bản welcome

3.1.1. Danh sách sản phẩm

3.1.1.1. Chia theo danh mục sản phẩm hoăc nếu ít hiển thị bằng Galery

3.1.1.1.1. Sản phẩm 1 (tùy xem có tài nguyên gì sẽ show cái đó)

3.1.1.1.2. Sản phẩm 2

3.1.2. Ưu Đãi hoặc game/tarrot/xem phong thủy

3.1.3. Feedback khách hàng hoặc báo chí hoặc trang chủ

4. Youtube

4.1. Làm Video

4.2. Quay Khóa học

4.3. Làm Hình Ảnh