Thao Trinh – Người thích tự do và lang thang như gió -
  • Trang chủ
  • Chuyện nghề
  • Đọc
  • Me
Thao Trinh – Người thích tự do và lang thang như gió -
Trang chủ
Chuyện nghề
Đọc
Me
  • Trang chủ
  • Chuyện nghề
  • Đọc
  • Me
Agile (APM), Đọc

Định nghĩa công việc theo phương pháp S.M.A.R.T

thaotrinh.info__dinh-nghia-cong-viec-theo-phuong-phap-s-m-a-r-t

Nếu phải chọn một hành động quan trọng nhất trước khi bắt tay làm bất cứ một công việc nào, bạn sẽ chọn hành động gì? Tôi đã hỏi rất nhiều người và câu trả lời tôi thường nhận được là lập kế hoạch. Thật đáng tiếc, đó không phải là câu trả lời tốt. Lập kế hoạch chỉ nên là hành động đứng thứ hai bởi nó phải nhường chỗ cho hành động định nghĩa công việc. An bắt đầu việc học tiếng Anh bằng cách lên một lịch trình chi tiết về việc đăng ký một khoá học, dành mỗi thời gian cuối tuần để luyện tập thêm; sau 6 tháng thực hiện kế hoạch hoàn hảo, An có thể đọc và viết các tài liệu bằng tiếng Anh, song An vẫn thấy thất vọng vì khả năng giao tiếp của mình. Một kế hoạch hoàn hảo cùng những nỗ lực tuyệt vời đã được An thực hiện nhưng không mang lại hiệu quả như An mong đợi; chỉ vì An đã bỏ đi hành động đầu tiên, và cũng là hành động quan trọng nhất, định nghĩa hoàn thành cho việc học tiếng Anh.

An không phải là một trường hợp đặc biệt. Theo nghiên cứu của Đại học Scran-ton, chỉ 8% những người được khảo sát nói rằng họ đạt được mục tiêu của mình trong năm 2014, phần nhiều nói rằng họ không chắc chắn đạt được mục tiêu hay chưa. Điều này nghe thật nực cười, nhưng sự thực là, hầu hết chúng ta không thể đánh giá kết quả công việc của mình chỉ vì đã bỏ qua hoặc thực hiện rất sơ sài hành động quan trọng nhất định nghĩa công việc.

Phương pháp định nghĩa công việc SMART dựa trên 5 yếu tố tạo nên từ này: S.M.A.R.T = Specific, Measurable, Achievable, Relevant, Time-Bound. Trong đó:

Specific (Cụ thể). Nếu công việc mông lung, làm sao chúng ta biết phải làm gì?

Một trong những sai lầm chúng ta hay gặp phải là xác định công việc một cách mơ hồ; và mơ hồ nhất là việc chúng ta bước ra khỏi nhà vào buổi sáng chỉ với một công việc duy nhất: đi làm. Nhưng cụ thể đến mức lập trình chức năng A, gặp đối tác B… thì không nhiều người xác định được trước khi chúng ta bước chân ra khỏi nhà vào 8 giờ sáng.

Measurable (Đo được). Nếu công việc không đo được, làm sao chúng ta biết khi nào mình đã hoàn thành?

Đây chính là yếu tố chúng ta dễ dàng bỏ qua và rồi vắt kiệt sức mình với một công việc mơ hồ; và mơ hồ nhất có lẽ là việc kiếm tiền. Nhưng nếu không định nghĩa rõ ràng việc kiếm 5 triệu hay 10 triệu thì bao giờ chúng ta sẽ dừng lại đây? Trở thành tỉ phú đô la dù sao cũng khoa học hơn kiếm được nhiều tiền.

Achievable (Khả thi). Nếu công việc không khả thi, làm sao chúng ta thực hiện?

Chúng ta có thể nghĩ lớn, đặt ra những mục tiêu vĩ đại cho cuộc đời mình. Nhưng hãy lưu ý, đó chỉ là tầm nhìn; khi định nghĩa một công việc cụ thể, chúng ta cần chắc chắn rằng công việc đó khả thi tại thời điểm hiện tại hoặc tương lai gần. Gặp tổng thống Obama vào tuần sau để bàn về giải pháp chống khủng bố là một công việc bất khả thi với 99.999% dân số thế giới; tại sao không bắt đầu bởi việc gửi thư cho tổng thống Obama để nêu quan điểm của mình về giải pháp chống khủng bố vào tuần sau? Thật bất ngờ là công việc đó khả thi với ít nhất 30% dân số, những người sử dụng Internet; và chúng ta có thể thực hiện.

Relevant (Liên quan). Nếu công việc không có sự liên quan (tới cuộc sống, những mục tiêu khác), chúng ta thực hiện công việc có ý nghĩa gì?

Đây là điểm đặc biệt quan trọng, bởi trong thế giới cá nhân, chúng ta có thể có hàng trăm việc để làm mỗi ngày, hãy lựa chọn đúng công việc cần thiết.

Time-Bound (Có thời hạn). Nếu công việc không giới hạn thời gian, khi nào nó được bắt đầu và kết thúc?

Hãy nhớ lại phương pháp quản lý thời gian; bởi thời gian của chúng ta là hữu hạn, ai quản lý thời gian tốt hơn, người đó có khả năng thành công cao hơn.

Nguồn: Trích sách Agile Y (Hien Nguyen)

Ví dụ về một vài cách định nghĩa công việc:

22h tối gửi email các thông tin cho anh X gồm: file nội dung, file slide, xác nhận tham gia trình bày ngày 23.08. yêu cầu anh X confirm lại email.

22h tối viết bài blog về SMART dựa theo sách Agile Y, có thêm 3 ví dụ về đầu việc theo tiêu chí SMART.

10h sáng viết Review sách Agile Y về các nội dung: Agile, Dev, Phát triển cá nhân. Mỗi nội dung lấy 1 ví dụ (trích dẫn trong sách – 3 ví dụ)

January 10, 2023by thaotrinh
Chuyện nghề, Đọc

Giá trị của Scrum Master trong case study của Leflair

thaotrinh.info__gia-tri-cua-scrum-master-trong-case-study-cua-leflair

Leflair là một case study hấp dẫn.
Nhân viên cao cấp của Leflair không đồng ý với cách CEO “đốt tiền” bằng việc thuê nhà thầu ở Úc làm app di động.
App di động đa chức năng, high-performance phát triển hoàn toàn tại Úc tầm giá 1 triệu đô đổ lên.
Giá các team gia công ở Việt Nam chào ở khoảng từ 10 nghìn – 100 nghìn đô.
Bài toán nghe tưởng dễ, làm ở Việt Nam đi cho nó rẻ. Để tiền đó để tăng trưởng người dùng, hoàn thiện khâu vận hành.

Nhưng thực tế không hiếm khi các sếp startup mặc dù có nguyên team phát triển ở Việt Nam, vẫn chấp nhận mang đi outsource với một giá cao hơn rất nhiều.

Tại sao nhỉ?

Mình xin mạn phép đưa ra một số giả thuyết cá nhân, và xin phép các cây đa, cây đề công nghệ trong danh sách bạn bè “sửa lưng” nếu có ý sai.
Qua kinh nghiệm làm thiết kế trải nghiệm cho các sản phẩm tech, và việc thường xuyên làm “người bắc cầu” giữa đội chỉ huy và đội phát triển. Mình thấy chuyện thị trường phần mềm, và web ở Việt Nam như sau:
Khúc 1: Làm gia công cho phần mềm doanh nghiệp lớn, khách hàng chủ yếu là Nhật Hàn. Sử dụng những hệ thống đã khá lâu năm, ổn định. Nhóm này có FPT, CMC
Khúc 2: Nghiên cứu và phát triển dựa trên những tiến bộ về kĩ thuật mới như AI và cryptocurrency. Khúc này có công ty cũ của mình: Kyber Network
Khúc 3: Làm sản phẩm cho khách hàng cá nhân hoặc doanh nghiệp nhỏ. Tập trung vào các nền tảng web mới, Java Script, RoR, nền tảng di động Android, iOS.

Khúc này chạm đến nhiều phần, là phần khúc to nhất và ra nhiều tiền nhất nếu làm đúng, xoay trái xoay phải làm tốt đi đâu cũng ra tiền. Vì giá chúng ta đang chào quá rẻ với thị trường thế giới, chưa kể có rất nhiều mô hình kinh doanh nội địa chúng ta có thể xây được từ khúc này.

Nhưng… chúng ta lại không có được những hợp đồng tốt nhất, và các sếp vẫn đòi đi gia công nước ngoài.

Và mình ấn vào app của Techcombank vẫn lag đều, Timo giao diện rất tốt nhưng phần logic phục hồi tài khoản cực kì “tụt mood”. Dù rất yêu Now nhưng vẫn phải dùng Grab Food cho đỡ lag.

Nguyên nhân của khúc 3 vẫn còn chưa ổn là do những lý do sau đây:

Cấp chỉ huy cao nhất không có nền tảng kỹ thuật, hoặc không tin tưởng vào cấp phó/cố vấn kĩ thuật của mình. Không phải ngẫu nhiên mà 5 năm trở lại đây mà các nhà đầu tư ra rả nói bọn tao muốn đầu tư vào các công ty công nghệ được chỉ huy bằng kĩ sư và người thiết kế sản phẩm – “engineer and design driven”.

Không phải ngẫu nhiên mà HSBC – một huyền thoại banking đang thua trong cuộc chơi digital, và mất đi túi tiền của tập khách hàng trẻ.

Revolut, Transferwise – những kì lân ngân hàng trẻ đều có founder với background kĩ thuật. Điều kiện gọi vốn ban đầu đối với CEO của Canva, một người vốn có tố chất thiết kế sản phẩm là cần tìm một co-founder có nền tảng kĩ thuật.

Văn hoá đội tech tốt cần bình đẳng và tranh luận tích cực.

Với văn hoá Á Đông, chúng ta ít khi “có được những cuộc đối thoại khó khăn” với sếp.
Một người bạn Mỹ làm quản lý công nghệ cao cấp ở Nhật đã nói với mình rằng:
“Khi một kĩ sư trẻ trình bày một vấn đề, anh ta phát hiện lúc code hàng ngày: rằng quy trình team đang vận hành sẽ tạo ra nhiều bug và thứ khó sửa về sau”
Bạn mình thở dài và nói tiếp “Chúng nó, sẽ dùng tất cả các biện pháp có thể, dúi thằng bé xuống – như đóng 1 cái đinh lại vào mặt sàn ấy mày biết không, đóng cho tất cả những cái đinh bằng nhau thì thôi”
Và cái lỗi đấy được chôn sâu, cho đến khi hệ thống vỡ. Bạn kĩ sư trẻ đã học được bài học “phải im lặng”. Team đó đã mất một thời gian dài để hồi phục lại hệ thống, và vĩnh viễn mất đi sự tận tâm của hai kĩ sư tâm huyết.

Văn hoá “mày sai là mày chết”

Phần mới của phim “Những thiên thần của Charlie” có thêm 1 cô điệp viên hacker tốt nghiệp MIT cho hợp thời đại.
Có một đoạn, cô điệp viên hacker đề nghị thử một phương án để cứu nguy cả team trong tình huống nguy cấp. Cô bạn tác chiến cùng đội hỏi: cái này mày nghĩ là “Sự thật hay giả định”? (Fact or Hypothesis?).
Cô hacker hùng hồn trả lời “Dĩ nhiên là giả định – nguyên tắc số 1 của khoa học là bắt đầu bằng giả định”, nói rồi tí toáy hack vào cái thiết bị với khả năng 50/50 – hoặc là ra ngoài, hoặc chết.

Mình đang uống nước tí sặc vì buồn cười.

Vì làm sản phẩm startup công nghệ cũng có lúc cãi nhau chán chê xem cái này có đúng không? Và mọi người quên rằng nhiều thứ chỉ là dự đoán cho đến khi có đầy đủ dữ liệu.
Xây một hệ thống đầu tiên cho 10,000 người dùng thì ổn. Khi bung ra 10x thì một team trẻ chưa có kinh nghiệm bắt đầu từ đâu? Dĩ nhiên bắt đầu bằng giả định.

Làm thế nào để làm được việc chưa ai làm bao giờ, ở quy mô lớn chưa từng có bao giờ? Dĩ nhiên phải bắt đầu bằng giả định.

Với giả định thì rất có thể sẽ sai. Cái khó là làm sao chúng ta có thể vui vẻ chấp nhận “sự sai đấy” ở mọi cấp quản lý và yêu lại từ đầu.

Bạn không tin mình ư? Hãy nhìn vào killedbygoogle.com – tập hợp những giả định sai của Google.

Mình nhận ra rằng chúng ta vẫn còn rất nặng nề với chuyện thất bại, hay ai sai ai đúng ở VN, và đặt rất nhiều gánh nặng lên cấp quản lý.

Lâu dần những sự nặng nề thành văn hoá ngại thử nghiệm, ngại sai, ngại học, ngại góp ý.

Tại sao tao phải thử framework hoạt động mới khi cái cũ vẫn tạm dùng được. Bất chấp những yêu cầu mới của khách hàng, thị trường. Thói quen này là đòn chí mạng với các team hoạt động ở Khúc 3, khi thị trường trả lời cực nhanh cho những team không thích ứng được.

Cũng là nguyên nhân tại sao chúng ta vẫn chưa chạm tay được vào những hợp đồng outsource hấp dẫn nhất.

Ghi chú: Bài viết đã được hiệu chỉnh 1 chút về mặt hiển thị, và thêm 1 cái tiêu đề khá kêu để các bạn Scrum Master thử đặt mình vào case Study để giải quyết thử vấn đề ở mức đội nhóm, coach về Agile mindset và Scrum framework cho Team.
Bài viết đi lượm trên internet, lỡ quên nguồn. Xin lỗi tác giả!

March 5, 2021by thaotrinh
Agile (APM), Đọc

Sự khác biệt giữa làm việc chăm chỉ và làm việc chăm chỉ một cách thông minh.

su-khac-biet-giua-lam-viec-cham-chi-va-lam-viec-cham-chi-mot-cach-thong-minh-thaotrinh.info

Chuyện kể rằng có chàng trai to khỏe nghe tin bà chủ khu rừng nọ tuyển thợ cưa. Anh tới ứng tuyển thì thấy “đối thủ” của mình là một bác nhìn như người lùn.
Tới ngày thi, bà chủ đưa cho mỗi người một cái cưa và hai người sẽ ở hai mảnh rừng khác nhau để thử thách. Chàng trai tin chắc phần thắng trong tay mình và hì hục cưa ngày cưa đêm không ngừng nghỉ. Điều làm chàng băn khoăn nhất là rất nhiều lúc trong ngày, thấy bác thợ lùn vác cưa đi ngang qua với tách trà nóng hổi, vừa đi vừa huýt sáo và lúc nào cũng tươi cười. Chàng nghĩ bụng: “Đã già, lùn, lại còn… lười. Ta mặc kệ, phần thắng ắt hẳn về ta”.

Hết thời gian, bà chủ tới nghiệm thu và thông báo kết quả. Bác lùn kia được chọn. Chàng trai bực lắm và quyết hỏi bà chủ cho ra nhẽ. Bà chủ đáp rằng: “Bác kia cưa được gỗ nhiều gấp rưỡi anh!”
Chàng trai suy nghĩ mãi vẫn không thể lý giải nổi vì sao “người đàn ông vừa lùn vừa lười” kia lại có thể thắng mình nên đã quyết định tới hỏi chuyện.

  • “Này, bác ăn trộm gỗ của tôi hả? Bác lười thế sao mà nhiều gỗ hơn tôi được?”

thaotrinh.info__su-khac-biet-giua-lam-viec-cham-chi-va-lam-viec-cham-chi-mot-cach-thong-minh

Bác lùn cười lớn rồi giải thích rằng khi chàng ta cưa hì hục như thế mà không nghỉ, lưỡi cưa sẽ ngày càng cùn, hiệu suất sẽ ngày càng giảm. Còn bác cứ cưa khoảng một tiếng, lại xách cưa ra bờ suối ngồi mài, nhờ đó mà lưỡi cưa luôn sắc bén, giúp bác cưa nhanh hơn mà không mất quá nhiều sức.

 

Đôi khi trong cuộc sống, thông minh thôi là chưa đủ. Hãy thông minh một cách chăm chỉ hoặc ngược lại, chăm chỉ một cách thông minh sẽ khiến bạn làm được nhiều việc hơn và thu được kết quả khả quan hơn. Bác lùn trong câu chuyện trên chẳng phải là một ví dụ sinh động đó sao?

January 16, 2021by thaotrinh
Đọc

Một tách trà

Một kẻ tầm sư học đạo nghe nói vị guru thông thái nhất toàn cõi Ấn Độ sống trên đỉnh ngọn núi cao nhất của Ấn Độ. Vì vậy anh ta vất vả lặn lội khắp núi non và thành Delhi cho đến khi tới được ngọn núi trứ danh nọ. Ngọn núi dốc đứng quá sức tưởng tượng, anh ta trầy trật leo lên ngã xuống không ít lần. Lên được tới đỉnh núi, anh ta trầy xước thâm tím khắp cả mình mẩy, nhưng rốt cuộc đã gặp được vị guru đang ngồi kiết già trước cửa hang.
– “Ôi, thưa tôn sư thông thái,” kẻ tầm sư học đạo lên tiếng.
– “Con đến để hỏi thầy bí mật của cuộc sống là gì ạ.”
– “À, bí mật của cuộc sống,” vị guru nói.
– “Bí mật của cuộc sống là một tách trà.”
– “Một tách trà? Con cực nhọc đi bao đường đất tới đây để tìm ý nghĩa cuộc sống, thế mà thầy lại bảo con rằng nó là một tách trà thôi ư!”
Vị guru nhún vai.
– “Vậy có thể nó không phải là một tách trà.”

Như vậy, vị guru thừa nhận rằng xác định được ý nghĩa của cuộc sống là điều nan giải. Hơn nữa, không phải với ai nó cũng là một tách trà.

December 4, 2020by thaotrinh
Page 1 of 71234»...Last »

About me

Đề xuất cho bạn

Định nghĩa công việc theo phương pháp S.M.A.R.T

Định nghĩa công việc theo phương pháp S.M.A.R.T

Revision database

Revision database

Tạo đối tượng trong C# từ url API hoặc Json String

Git hướng dẫn cơ bản cho người mới

Git hướng dẫn cơ bản cho người mới

Không phải làm bao nhiêu mà là tạo ra bao nhiêu

Không phải làm bao nhiêu mà là tạo ra bao nhiêu

Bài mới

  • Định nghĩa công việc theo phương pháp S.M.A.R.T
  • Họp xong việc và họp thêm việc
  • Giá trị của Scrum Master trong case study của Leflair
  • Sự khác biệt giữa làm việc chăm chỉ và làm việc chăm chỉ một cách thông minh.
  • Một tách trà

Mọi người quan tâm

No comments to show.

Chuyên mục

  • Agile (APM)
  • Chuyện nghề
  • Đọc
  • Học nghề
  • Làm thợ
  • Uncategorized

Tags

Agile Dev Kanban Marketing Nhóm Scrum Sách Sản phẩm Think Tôi tự học

Người học thức, tức là người thà biết ít mà thật biết những gì mình biết, còn những gì mình không biết, thì cũng biết rõ là mình không biết. “Không có sự dốt nát nhục nhã bằng tin tưởng rằng mình đã biết trong khi mình chưa biết”. Văn hóa là một vấn đề thuộc phẩm chứ không phải thuộc lượng

© 2015 copyright thaotrinhminh@gmail.com // All rights reserved // Privacy Policy