Viết về Lean Learning
Với một thằng đam mê consume thông tin, học hết mọi thứ trên đời như t từ Coding Interview Patterns, System Design Patterns, Devops, Backend, Frontend, AI, English, Leadership, Politics, Psychology,.… Nó dẫn đến cảm giác overwhelmed không bao giờ biết đủ, còn không có thời gian dành cho các phần khác của cuộc sống t như: relationship của t, responsibilities với gia đình, bạn bè và xã hội,…
Và sâu hơn nữa là cảm giác trì hoãn, hoàn hảo quá mọi thứ trong suy nghĩ, ngồi judge quá nhiều vì sự under-valued bản thân và người khác, chứ không bắt đầu start cho 1 cái project thực tế với lượng kiến thức “vừa đủ”.
Và cách nào để giải quyết cái cảm giác “không đủ” này =)) Bạn à, t chơi hệ thinking nên không solve bằng mấy cái phép màu cảm xúc như “self-acceptance” hay “thông cảm với những điều không hoàn hảo” được đâu :))) Có 1 phương pháp khác là Lean Learning.
Đại loại là phương pháp này là hãy nhìn 1 big picture từ đầu, bao gồm các stakeholders liên quan trong 1 cái system, tìm mọi cách để đạt được final value m muốn, hoặc value cho nhiều stakeholders trước, rồi đào sâu trong từng step mình làm sau. Rồi sau đó cứ update dần, nhưng đầu tiên là optimize được cái idea mình làm trước.
Ví dụ, m làm system design cho 1 product đi. Ở view đào sâu tech, m sẽ đi phân tích rất sâu vào system design về các tiêu chí như reliability, scalability, handle bottlenecks, read-heavy, write-heavy, real-times,… Xong m sẽ đem 1 cái bản phân tích cực sâu này đưa vào implement cho business, nhưng thực tế cái value stream m đem lại cho toàn bộ hệ thống cho mấy người đó là không cao =))
Vì sao ? Đối với view business, thứ nó quan tâm là GTM (go-to-market time) để nó test thị trường và chiếm chỉ số early competition, còn đống chỉ số System Design trên là để không làm mất lòng khách hàng thôi. Đối với stakeholders khác, ví dụ PM hay tech lead đi thì thứ nó quan tâm là cái khả năng release của dự án để nó chạy kpi, marketing thì nó thích UX đẹp với fancy AI để tự tin đi lùa khách hàng. Cho cùng thì non-functional requirements cũng là để không làm mất khách thôi :)))
Một ví dụ khác đi, m build 1 dự án. Thứ m quan tâm đâu phải là mỗi cái design như trên hay technical stack. Một big picture start từ product-market fit, xong technical development, deployment nhé.
- Đầu tiên là m phải xem cái product m nó fit vô market như thế nào đã, user segment nào, revenue stream từ đâu, hidden value từ đâu.
- Thứ hai, m dùng technical stack nào code để nó tốt nhất.
- Thứ ba, m deployment như thế nào, dùng kiến thức devops và Kubernetes, CI/CD ở đây nè, dùng cloud thì dễ hơn không.
- Thứ tư, cái việc m hoàn thành đó đem lại lợi ích gì cho team m, cho sếp m, những người liên quan dự án như thế nào.
Thay vì m đi học hết bao nhiêu sách về Kubernetes, CI/CD, System Design, AI. Học sâu những cái sẽ áp dụng vào dự án là được, và view value stream của dự án để “định giá” tốt hơn nha.