Clean Coder – Chương 9 – Quản Lý Thời Gian

Tám giờ là một khoảng thời gian đặc biệt ngắn. Nó chỉ là 480 phút hay 28.800 giây. Là một người chuyên nghiệp, bạn luôn mong muốn rằng bạn sẽ dùng những giây phút quý giá đó càng hiệu quả càng tốt. Vậy chiến thuật nào bạn có thể dùng để đảm bảo rằng bạn không lãng phí một chút thời gian nào mà bạn có? Làm cách nào bạn có thể quản lý thời gian của mình một cách hiệu quả?

Vào năm 1986, tôi đang sống ở Little Sandhurst, Surey, nước Anh. Tôi quản lý một bộ phận phát triển phần mềm gồm 15 người cho công ty Teradyne ở Bracknell. Cả ngày của tôi chỉ say sưa với các cuộc gọi điện thoại, các cuộc họp, các vấn đề dịch vụ tại hiện trường, và các gián đoạn. Vì vậy để có thể hoàn thành bất cứ công việc nào tôi đã phải tuân thủ theo những nguyên tắc quản lý thời gian một cách khá quyết liệt.

  • Tôi dậy vào 5 giờ sáng và đạp xe đạp tới văn phòng ở Bracknell vào lúc 6 giờ sáng. Điều này giúp cho tôi có được 2 tiếng rưỡi yên tĩnh trước khi một ngày hỗn loạn mới bắt đầu.
  • Khi đến nơi tôi sẽ viết lịch làm việc lên bảng. Tôi chia thời gian thành từng khoảng 15 phút và điền vào đó những hoạt động tôi sẽ làm trong khoảng thời gian đó.
  • Tôi hoàn thành việc điền công việc cho 3 giờ đầu tiên của lịch làm việc đó. Tới 9 giờ sáng, tôi bắt đầu để ra một khoảng 15 phút mỗi giờ, đó là cách mà tôi có thể đẩy phần lớn những gián đoạn vào một trong những khoảng thời gian trống này và tiếp tục làm việc.
  • Tôi để thời gian sau bữa trưa không lên lịch bởi vì tôi biết rằng sau đó tất cả những thứ quái quỷ sẽ xuất hiện và tôi sẽ phải ở trạng thái đối phó trong suốt thời gian còn lại trong ngày. Trong những buổi chiều hiếm hoi mà sự hỗn loạn không xảy ra, thì tôi đơn giản chỉ làm công việc quan trọng nhất cho đến khi tôi làm xong.

Lịch làm việc này không phải lúc nào cũng thành công. Tỉnh dậy vào lúc 5 giờ sáng không phải lúc nào cũng có thể làm được, và thỉnh thoảng sự hỗn loạn phá vỡ tất cả kế hoạch được tính toán cẩn thận của tôi và tốn của tôi mất cả ngày. Nhưng phần lớn thì tôi có thể giữ được cái đầu của mình trên mặt nước.

Họp hành

Việc họp hành tốn khoảng 200$ mỗi giờ cho mỗi người tham gia. Nó bao gồm tiền lương, phúc lợi, chi phí cơ sở vật chất.v.v. Lần tới mà bạn trong một cuộc họp, hãy tính toán chi phí. Bạn có thể sẽ phải ngạc nhiên đấy.

Có hai sự thật về việc họp hành.

  1. Việc họp hành là điều cần thiết.
  2. Việc họp hành tốn thời gian khủng khiếp.

Thường thì hai sự thật này đều mô tả về cùng một buổi họp. Một vài người tham gia có thể thấy chúng vô giá; một số khác lại có thể thấy chúng dư thừa hoặc vô ích. Những người chuyên nghiệp nhận thức được chuyện chi phí cao của các cuộc họp. Họ cũng nhận thức được rằng thời gian của chính họ là rất quý giá; họ có code cần phải viết và có lịch hẹn để gặp khách hàng. Do đó, họ chủ động từ chối tham dự các cuộc họp nào mà không có lợi ích gì đáng kể và tức thì.

Từ chối

Bạn không phải tham dự mọi cuộc họp mà bạn được mời. Quả thực là thật thiếu chuyên nghiệp nếu bạn tham gia vào quá nhiều cuộc họp. Bạn cần dùng thời gian của mình một cách thông minh. Vì vậy hãy suy nghĩ cẩn thận về những cuộc họp nào mà bạn nên tham gia và cuộc họp nào mà bạn nên lịch sự từ chối.

Người mời bạn tới một cuộc họp không chịu trách nhiệm quản lý thời gian của bạn. Chỉ có bạn là có thể làm được việc đó. Vì vậy khi bạn nhận một lời mời họp, đừng chấp nhận ngay trừ khi đó là cuộc họp mà sự tham gia của bạn rất khẩn cấp và cần thiết cho công việc mà bạn bây giờ đang làm.

Đôi khi cuộc họp sẽ bàn về những điều thú vị đối với bạn, nhưng không phải là điều cần thiết ngay. Bạn sẽ phải lựa chọn xem bạn có đủ thời gian hay không. Bạn phải cẩn thận – những cuộc họp này có thể đủ để bạn mất cả ngày.

Đôi khi cuộc họp sẽ bàn về những điều bạn có thể đóng góp nhưng không phải quan trọng ngay tới thứ mà bạn hiện đang làm. Bạn sẽ phải lựa chọn xem tổn thất cho dự án của bạn có đáng cho lợi ích của cuộc họp không. Điều này nghe có vẻ yếm thế, nhưng trách nhiệm của bạn là phải dành cho dự án của bạn trước tiên. Dù sao thì việc một nhóm giúp đỡ một nhóm khác cũng là một điều tốt, vì vậy bạn có thể cần thảo luận về sự tham gia của bạn với người quản lý và nhóm của bạn trước.

Đôi khi sự có mặt của bạn tại cuộc họp được yêu cầu bởi một người có quyền hành, như một kỹ sư cấp cao ở một dự án khác hoặc một quản lý của một dự án khác. Bạn sẽ phải lựa chọn xem quyền hành đó có nặng hơn lịch làm việc của bạn không. Một lần nữa, người quản lý và nhóm của bạn có thể giúp bạn trong việc đưa ra quyết định đó.

Một trong những nhiệm vụ quan trọng nhất của người quản lý của bạn là giữ bạn tránh khỏi những cuộc họp. Một người quản lý tốt sẽ sẵn sàng bảo vệ quyết định từ chối tham gia họp của bạn bởi vì người quản lý đó cũng quan tâm tới thời gian của bạn như chính bạn vậy.

Rời họp

Các cuộc họp không phải lúc nào cũng như kế hoạch. Thỉnh thoảng bạn sẽ thấy mình đang ngồi trong một cuộc họp mà có lẽ bạn sẽ từ chối nếu bạn biết trước nhiều hơn. Thỉnh thoảng những chủ đề mới lại được thêm vào, hoặc ai đó độc diễn trong buổi thảo luận. Trải qua nhiều năm, tôi đã phát triển được một nguyên tắc đơn giản: Nếu cuộc họp nhàm chán, hãy rời đi.

Tôi phải nhắc lại, bạn có bổn phận phải quản lý thời gian của mình thật tốt. Nếu bạn thấy mình bị mắc kẹt trong một cuộc họp thì có nghĩa là thời gian của bạn đang bị sử dụng không tốt, và bạn cần tìm cách để ra khỏi cuộc họp đó một cách lịch sự.

Rõ ràng là bạn không nên kêu lên trong cuộc họp “Thật là nhàm chán!”. Bạn không cần phải thô lỗ như vậy. Bạn có thể chỉ cần đơn giản hỏi, vào một thời điểm thích hợp, xem sự hiện diện của bạn có cần thiết nữa hay không. Bạn có thể giải thích rằng bạn không có nhiều thời gian hơn, và hỏi xem có cách nào xúc tiến cuộc thảo luận hoặc thay đổi lịch không.

Điều quan trọng nhất để nhận thấy là phần còn lại của cuộc họp sẽ trở thành một sự lãng phí thời gian của bạn, và bạn thì không thể đóng góp được gì nhiều hơn nữa, điều này thật là thiếu chuyên nghiệp. Bạn có bổn phận phải sử dụng một cách thông minh thời gian và tiền của sếp bạn, vì vậy việc lựa chọn một thời điểm thích hợp để rời cuộc họp không hề là việc không được làm.

Có một đề tài thảo luận và một mục tiêu

Nguyên nhân chúng ta sẵn sàng chịu chi phí của các cuộc họp đó là chúng ta đôi khi cần phải cùng nhau tham gia trong một phòng để giúp nhau đạt được một mục tiêu cụ thể. Để dùng thời gian của những người tham gia một cách thông minh, cuộc họp nên có một đề tài thảo luận rõ ràng, với khoảng thời gian cụ thể cho mỗi chủ đề và một mục tiêu đặt ra.

Nếu bạn được đề nghị tham gia một cuộc họp, hãy chắc rằng bạn biết được điều gì sẽ được thảo luận, thời gian dành cho chúng là bao lâu, và mục tiêu cần đạt được là cái gì. Nếu bạn không thể có một câu trả lời rõ ràng về những điều này thì bạn nên lịch sự từ chối tham gia.

Nếu bạn tới một cuộc họp mà bạn thấy đề tài thảo luận bị chiếm đoạt hoặc bị lãng quên, thì bạn nên đề nghị rằng chủ đề mới sẽ bàn sau và cần phải bám theo đề tài thảo luận chính. Nếu vẫn không được, thì bạn nên lịch sự rời đi khi có thể.

Các cuộc họp đứng

Những cuộc họp kiểu này là một phần của khẩu pháo Agile. Tên của chúng xuất phát từ thực tế là những người tham gia đều đứng trong khi cuộc họp diễn ra. Mỗi người tham gia đều có một lượt để trả lời ba câu hỏi:

  1. Tôi đã làm gì hôm qua?
  2. Tôi sẽ làm gì hôm nay?
  3. Có vấn đề gì trong công việc của tôi không?

Tất cả chỉ có vậy. Mỗi câu hỏi không được trả lời quá hai mươi giây, vì vậy mỗi người tham gia không mất quá một phút để trả lời cả ba câu hỏi. Ngay cả trong một nhóm có mười người thì những cuộc họp này cần phải kết thúc sau mười phút.

Các cuộc họp lập kế hoạch mỗi chu kỳ công việc

Đây là kiểu cuộc họp khó nhất trong khẩu pháo Agile để có thể làm được tốt. Nếu làm không tốt thì chúng ta sẽ mất rất nhiều thời gian. Bạn cần phải có kỹ năng mới thực hiện tốt được những cuộc họp kiểu này, một kỹ năng đáng để học hỏi.

Các cuộc họp lập kế hoạch mỗi chu kỳ có tác dụng lựa chọn công việc chưa làm nào sẽ được thực hiện trong chu kỳ làm việc tiếp theo. Các công việc ứng cử lựa chọn cần phải được ước lượng khoảng thời gian để hoàn thành trước đó. Việc đánh giá giá trị của từng công việc cũng cần phải được hoàn thành trước khi họp. Trong những tổ chức thực sự tốt thì thậm chí cả những bài acceptance/component test cũng đã được viết trước, hoặc ít nhất thì cũng đã được phác thảo ra rồi.

Cuộc họp cần tiến hành nhanh chóng với từng công việc chưa làm được thảo luận sơ bộ và sau đó hoặc là lựa chọn hoặc là từ chối. Mỗi công việc ứng cử không tốn quá năm hoặc mười phút. Nếu cần phải thảo luận lâu hơn thì cần phải đặt lịch vào một khoảng thời gian khác với một nhóm nhỏ hơn.

Kinh nghiệm của tôi là cuộc họp đó không được mất nhiều hơn 5% tổng thời gian của mỗi chu kỳ công việc. Như vậy nếu chu kỳ công việc là một tuần (40 giờ) thì cuộc họp đó nên kết thúc trong vòng 2 giờ.

Demo và rút kinh nghiệm mỗi chu kỳ công việc

Những cuộc họp này được thực hiện vào cuối mỗi chu kỳ công việc. Các thành viên trong nhóm thảo luận những gì đã đi đúng và những gì đã đi sai. Khách hàng xem một bản demo của những chức năng mới hoạt động. Cuộc họp kiểu này có thể bị lạm dụng một cách tệ hại và có thể chiếm rất nhiều thời gian, vì vậy hãy đặt lịch cho chúng khoảng 45 phút trước khi ra về vào ngày cuối cùng của chu kỳ công việc. Bạn hãy dành không quá 20 phút cho việc rút kinh nghiệm và khoảng 25 phút cho việc demo. Hãy nhớ rằng, mỗi chu kỳ công việc chỉ có một hoặc hai tuần nên sẽ không có quá nhiều thứ để nói.

Tranh cãi/Bất đồng

Kent Beck đã từng nói với tôi vài điều chân thành: “Bất cứ cuộc tranh cãi nào mà không thể kết thúc trong 5 phút thì sẽ không thể kết thúc bằng cách tranh cãi.” Nguyên nhân mà nó kéo dài là do cả hai bên đều không có chứng minh rõ ràng nào cả. Tranh cãi khi đó có lẽ chỉ là niềm tin, chứ không phải là thực tế.

Những bất đồng về mặt kỹ thuật có khuynh hướng đi quá xa. Mỗi bên đều có các lời biện hộ cho luận điểm của mình nhưng lại hiếm khi có dữ liệu. Mà không có dữ liệu thì bất cứ cuộc tranh cãi nào cũng sẽ không thể đi tới được sự nhất trí trong vòng vài phút được (khoảng giữa 5 và 30), thậm chí đơn giản là không bao giờ nhất trí được. Chỉ có thứ duy nhất cần phải làm lúc đó là đi lấy dữ liệu.

Một vài người sẽ cố gắng để chiến thắng cuộc tranh cãi bằng sức mạnh cá nhân. Họ có thể quát tháo hoặc sừng sộ trước mặt bạn, hoặc cư xử trịnh thượng. Điều này cũng không có tác dụng gì; sức mạnh của ý chí không thể giải quyết bất đồng được lâu dài. Nhưng dữ liệu thì có thể.

Một vài người thì sẽ phản kháng lại một cách thụ động. Họ sẽ đồng ý chỉ với ý định là kết thúc cuộc tranh cãi, và sau đó phá hoại kết quả bằng cách từ chối tham gia vào giải pháp đó. Họ sẽ nói với bản thân rằng “Đây là cách mà mấy người muốn, và bây giờ mấy người đi mà làm.” Đấy có lẽ là kiểu hành vi thiếu chuyên nghiệp tệ hại nhất. Không bao giờ, đừng bao giờ làm như vậy. Nếu bạn đồng ý, thì bạn bắt buộc phải tham gia.

Bạn lấy dữ liệu cần thiết để chấm dứt cuộc tranh cãi như thế nào? Đôi khi bạn có thể chạy những thí nghiệm, hoặc làm một vài mô phỏng hoặc làm mẫu. Nhưng đôi khi cách thay thế tốt nhất chỉ đơn giản là tung đồng xu để lựa chọn một trong hai con đường trong câu hỏi.

Nếu mọi thứ suôn sẻ thì con đường đó khả quan. Còn nếu bạn gặp phải rắc rối thì bạn có thể quay trở lại và đi theo con đường khác. Sẽ là khôn ngoan nếu bạn đồng ý kèm với những điều kiện để giúp bạn xác định xem có nên từ bỏ con đường đã chọn hay không.

Bạn hãy cẩn thận với những cuộc họp mà nó thực sự chỉ là nơi phơi bày những bất đồng và để lấy sự ủng hộ từ bên này hoặc bên kia. Và bạn hãy tránh những cuộc họp mà chỉ có một người tranh luận trình bày ý kiến.

Nếu cuộc tranh cãi phải thực sự được chấm dứt thì bạn hãy đề nghị mỗi người tranh luận trình bày trường hợp của họ cho cả nhóm trong 5 phút hoặc ít hơn. Sau đó để cả nhóm bỏ phiếu. Toàn bộ buổi họp đó sẽ diễn ra ít hơn 15 phút.

Manna tập trung

Xin thứ lỗi cho tôi nếu phần này có mùi của lý thuyết suông, hoặc có thể giống như trong trò chơi Địa ngục & Rồng (Dungeons & Dragons). Đây chỉ là cái cách mà tôi nghĩ về chủ đề này.

Việc lập trình là một công việc trí não đòi hỏi sự tập trung kéo dài. Sự tập trung cũng là một tài nguyên khan hiếm, cũng giống như manna[1]. Sau khi bạn sử dụng manna tập trung, bạn phải nạp lại chúng bằng các hoạt động không đòi hỏi sự tập trung trong một giờ hoặc nhiều hơn.

Tôi không biết loại manna tập trung này là gì, nhưng tôi có cảm nhận đó là một chất vật lý (hoặc có thể là không) ảnh hưởng tới sự tỉnh táo và sự chú ý. Dù nó là gì đi nữa, bạn có thể cảm nhận được nó ở đó, và bạn có thể cảm nhận được khi nó rời đi. Những lập trình viên chuyên nghiệp học cách để quản lý thời gian của họ để tận dụng manna tập trung của họ. Họ viết code khi manna tập trung của họ ở mức cao; và họ làm việc khác, những thứ ít hiệu quả hơn khi không có.

Manna tập trung cũng là một tài nguyên bị phân hủy. Nếu bạn không dùng nó khi nó ở đó thì bạn nhiều khả năng sẽ mất nó. Đó là một trong những nguyên nhân mà các cuộc họp có thể có sức tàn phá ghê gớm. Nếu bạn dùng tất cả manna tập trung của bạn trong một cuộc họp thì bạn sẽ không còn chút nào dành cho việc code nữa.

Sự lo lắng và gây sao lãng cũng ngốn manna tập trung. Cuộc cãi vã của bạn với vợ hay chồng tối hôm trước, vết lõm trên hàng rào của bạn sáng nay, hay hóa đơn bạn quên không trả tuần trước, tất cả đều hút cạn manna tập trung của bạn nhanh chóng.

Ngủ

Tôi không thể nhấn mạnh đủ được điều này. Tôi có lượng manna tập trung nhiều nhất sau một giấc ngủ ngon lành. Bảy tiếng ngủ thường sẽ cho tôi lượng manna tập trung dùng cho trọn vẹn tám tiếng. Những lập trình viên chuyên nghiệp quản lý lịch ngủ của họ để đảm bảo rằng họ tràn đầy manna tập trung vào thời điểm họ đi làm vào buổi sáng.

Cà-phê-in

Không có nghi ngờ gì về việc một số trong chúng ta có thể dùng manna tập trung hiệu quả hơn bằng cách uống một lượng vừa đủ cà-phê-in. Nhưng bạn hãy cẩn thận. Cà-phê-in cũng tạo ra một sự “bồn chồn” trong lúc tập trung của bạn. Nếu bạn sử dụng quá nhiều thì nó có thể đưa sự tập trung của bạn theo những hướng rất lạ. Một lượng cà-phê-in đủ mạnh có thể khiến bạn lãng phí nguyên một ngày tập trung cao độ vào những thứ không đâu.

Việc sử dụng lượng cà phê bao nhiêu là đủ dùng thì sẽ tùy từng người. Sở thích cá nhân của tôi là một tách cà phê đen vào buổi sáng và một cốc coca ăn kiêng vào bữa trưa. Tôi thỉnh thoảng cũng nhân đôi liều lượng này, nhưng rất hiếm khi tôi dùng hơn thế.

Nạp lại

Manna tập trung có thể nạp lại một phần bằng sự “khử tập trung”. Một buổi đi bộ dài, một cuộc trò chuyện với những người bạn, một khoảng thời gian chỉ nhìn qua khung cửa sổ, tất cả đều có thể giúp bơm thêm lượng dự trữ manna tập trung.

Một vài người ngồi thiền. Một vài người khác thì có một giấc ngủ ngắn. Một số khác thì nghe đài podcast hoặc xem lướt qua một quyển tạp chí.

Tôi thấy một khi manna đã hết thì bạn sẽ không thể cố ép mình tập trung được nữa. Bạn có thể vẫn viết code, nhưng bạn sẽ gần như chắc chắn phải viết lại đoạn code đó vào ngày tiếp theo, hoặc sẽ phải chung sống với một mớ bòng bong đó trong nhiều tuần, nhiều tháng. Vì vậy tốt hơn hết là bạn hãy dùng 30 hoặc thậm chí là 60 phút để “khử tập trung”.

Tập trung cơ bắp

Có một số thứ đặc biệt khi thực hiện việc rèn luyện thể chất như võ thuật, thái cực quyền hoặc yoga. Mặc dù những hoạt động này đòi hỏi sự tập trung cao độ, nhưng nó lại là một dạng khác của tập trung so với việc tập trung code. Đó không phải là tập trung trí óc, mà đó là tập trung cơ bắp. Và bằng cách nào đó thì việc tập trung cơ bắp cũng giúp cho việc nạp lại khả năng tập trung trí óc. Tuy nhiên nó không chỉ đơn giản là một lần nạp. Tôi thấy một chế độ tập trung cơ bắp bình thường cũng làm tăng khả năng của việc tập trung trí óc của tôi.

Sự lựa chọn tập trung cơ bắp của tôi là đi xe đạp. Tôi đạp xe trong 1 hoặc 2 tiếng, đôi khi đi tới 20 hoặc 30 dặm[2]. Tôi đạp xe trên con đường chạy song song với sông Des Plaines, nên tôi không phải quan tâm tới những chiếc xe ô tô.

Trong khi tôi đạp xe, tôi nghe các đài podcast về vũ trụ hoặc chính trị. Thỉnh thoảng tôi chỉ đơn giản là nghe những bài hát mình yêu thích. Và thỉnh thoảng tôi cũng bỏ tai nghe xuống và lắng nghe thiên nhiên.

Một vài người dành thời gian để làm những công việc chân tay. Có lẽ họ thích thú với công việc làm mộc, hoặc xây dựng mô hình, hoặc chăm sóc vườn cây. Dù hoạt động gì đi nữa, thì luôn có những hoạt động tập trung vào cơ bắp và giúp tăng cường khả năng làm việc trí óc của bạn.

Đầu vào vs Đầu ra

Một điều mà tôi thấy cần thiết cho sự tập trung là làm cân bằng đầu ra của tôi với đầu vào một cách phù hợp. Việc viết phần mềm là một hoạt động sáng tạo. Tôi cảm thấy tôi sáng tạo nhất khi tôi trông thấy sự sáng tạo của người khác. Vì vậy tôi đọc nhiều truyện khoa học viễn tưởng. Sự sáng tạo của những tác giả này bằng cách nào đó đã kích thích nguồn sáng tạo của tôi đối với phần mềm.

Khung thời gian và quả cà chua

Một cách rất hiệu quả mà tôi thường dùng để quản lý thời gian của mình và sự tập trung là dùng kỹ thuật rất nổi tiếng Pomodoro[3], còn được biết đến với cái tên quả cà chua. Ý tưởng cơ bản rất đơn giản. Bạn đặt một đồng hồ nấu ăn tiêu chuẩn (có hình dạng truyền thống giống như một quả cà chua) trong 25 phút. Trong khi bộ hẹn giờ đó đang chạy, bạn không để bất cứ thứ gì ảnh hưởng tới công việc bạn đang làm. Nếu điện thoại kêu, bạn sẽ trả lời và lịch sự đề nghị xem bạn có thể gọi lại sau 25 phút được không. Nếu ai đó dừng và hỏi bạn một câu hỏi, bạn cũng lịch sự đề nghị xem bạn có thể trả lời họ sau 25 phút được không. Dù cho sự gián đoạn nào đi nữa, bạn đơn giản chỉ trì hoãn nó cho đến khi bộ hẹn giờ kêu lên. Dù gì thì cũng có rất ít sự gián đoạn nào mà khẩn cấp kinh khủng đến nỗi họ không thể đợi được trong 25 phút!

Khi bộ hẹn giờ cà chua kêu lên thì bạn dừng công việc bạn đang làm ngay lập tức. Bạn xử lý với những gián đoạn đã xảy ra trong 25 phút trước đó. Sau đó bạn nghỉ giải lao khoảng 5 phút. Sau đó bạn đặt thời gian cho 25 phút khác và bắt đầu chu kỳ cà chua tiếp theo. Sau mỗi bốn chu kỳ cà chua bạn lại nghỉ một khoảng dài hơn vào khoảng 30 phút.

Có khá nhiều bài viết về kỹ thuật này, và tôi mong bạn nên đọc nó. Tuy nhiên, những mô tả phía trên cũng đã cung cấp đầy đủ cho bạn những ý chính của kỹ thuật này rồi.

Bằng việc sử dụng kỹ thuật này, thời gian của bạn được chia thành các chu kỳ cà chua và “không cà chua”. Chu kỳ cà chua là khoảng thời gian năng suất. Trong những chu kỳ cà chua này, bạn sẽ hoàn thành những công việc thực sự. Thời gian nằm ngoài những chu kỳ cà chua ví dụ như những sao lãng, họp hành, nghỉ giải lao, hoặc các thời gian khác sẽ không được dùng để làm những nhiệm vụ của bạn.

Vậy bao nhiêu quả cà chua bạn có thể hoàn thành được một ngày? Nếu là một ngày đẹp trời thì bạn có thể hoàn thành 12 thậm chí 14 quả cà chua. Nhưng nếu là ngày tồi tệ, bạn có thể chỉ hoàn thành được 2 hoặc 3 quả mà thôi. Nếu bạn đếm, và vẽ đồ thị chúng, bạn sẽ nhanh chóng cảm thấy bạn dành được bao nhiêu thời gian làm việc hiệu quả trong ngày và bạn dành được bao nhiêu thời gian để xử lý với các “vấn đề”.

Một vài người cảm thấy thoải mái với kỹ thuật này đến nỗi họ ước lượng nhiệm vụ của họ theo những chu kỳ cà chua và sau đó đo lường tốc độ cà chua của họ hàng tuần. Nhưng đây chỉ là phần nổi trên miếng bánh. Lợi ích thực sự của kỹ thuật Pomodoro là khung thời gian làm việc hiệu quả 25 phút sẽ khiến bạn phải quyết liệt đề phòng tất cả những gián đoạn.

Tránh né

Thỉnh thoảng con tim bạn không nằm ở một công việc. Nó có thể là do điều cần làm đáng sợ hoặc làm không thoải mái hoặc nhàm chán. Có lẽ bạn nghĩ nó sẽ ép bạn vào một cuộc đối đầu hoặc dẫn bạn tới một ổ chuột không lối thoát. Hoặc có thể chỉ đơn thuần là bạn không muốn làm.

Đảo ngược mức ưu tiên

Dù nguyên nhân gì đi nữa, bạn cũng đang tìm cách để né tránh làm công việc thực sự. Bạn thuyết phục bản thân là có thứ khác khẩn cấp hơn, và bạn phải làm nó ngay. Đây gọi là sự đảo ngược mức ưu tiên. Bạn nâng mức ưu tiên của một nhiệm vụ để bạn có thể trì hoãn nhiệm vụ cần ưu tiên thực sự. Sự đảo ngược mức ưu tiên là một lời nói dối của chúng ta với chính bản thân mình. Chúng ta không muốn đối diện với điều cần phải hoàn thành, vì vậy chúng ta tự thuyết phục bản thân rằng nhiệm vụ khác quan trọng hơn. Chúng ta biết là không phải vậy, nhưng chúng ta lại lừa dối chính mình.

Thực tế thì chúng ta không phải đang lừa dối bản thân. Điều chúng ta thực sự đang làm là chuẩn bị cho một lời nói dối chúng ta sẽ nói ra khi có ai đó hỏi chúng ta đang làm gì và tại sao chúng ta làm nó. Chúng ta đang xây dựng tấm chắn phòng thủ để bảo vệ mình khỏi sự phán xét của người khác.

Rõ ràng đây là hành động thiếu chuyên nghiệp. Những người chuyên nghiệp đánh giá mức độ ưu tiên của mỗi nhiệm vụ, không quan tâm tới nỗi sợ hãi và mong muốn của cá nhân họ, và thực hiện những nhiệm vụ này theo đúng thứ tự ưu tiên.

Những ngõ cụt

Những ngõ cụt là một thực tế sẽ xuất hiện trong cuộc sống của tất cả những lập trình viên phần mềm. Đôi khi bạn sẽ đưa ra một quyết định và đi theo một con đường mà nó chả dẫn tới đâu cả. Bạn càng có quyền đưa ra quyết định, bạn sẽ càng đi lang thang vô định lâu hơn. Nếu bạn đã tạo dựng được danh tiếng nghề nghiệp của mình rồi thì có thể bạn sẽ lang thang mãi mãi.

Sự thận trọng và kinh nghiệm sẽ giúp bạn tránh được một số ngõ cụt, nhưng bạn sẽ không bao giờ tránh được hết. Vì vậy kỹ năng thực sự bạn cần là nhanh chóng nhận ra khi nào bạn đang trong ngõ cụt và có đủ can đảm để quay trở lại. Đây thỉnh thoảng được gọi là Nguyên Tắc Cái Hố: Khi bạn đang trong một cái hố thì hãy ngừng đào tiếp.

Những người chuyên nghiệp tránh để bị dính chặt vào một ý tưởng đến nỗi mà họ không thể từ bỏ được nó và can đảm quay trở lại. Họ luôn cởi mở với những ý tưởng khác để khi đi vào ngõ cụt thì họ vẫn có những sự lựa chọn khác.

Đầm lầy, bãi lầy và những mớ hỗn độn

Tệ hơn ngõ cụt là những mớ hỗn độn. Mớ hỗn độn làm chậm bạn lại, nhưng nó không dừng được bạn. Mớ hỗn độn cản trở tiến trình của bạn, nhưng bạn vẫn có thể tiến bước bằng những lực cưỡng ép. Mớ hỗn độn tệ hơn cả ngõ cụt bởi vì bạn vẫn có thể thấy được con đường phía trước, và nó luôn trông ngắn hơn là việc quay trở lại (nhưng không phải vậy).

Tôi đã từng nhìn thấy những sản phẩm bị tàn lụi và những công ty bị hủy hoại bởi vì những mớ phần mềm hỗn độn. Tôi đã từng thấy hiệu quả làm việc của nhóm giảm từ chỗ chỉ chút ít cho tới khi mọi người phải than khóc chỉ trong vòng vài tháng. Không gì có ảnh hưởng tiêu cực kéo dài và sâu sắc tới hiệu quả làm việc của nhóm hơn là một mớ hỗn độn. Không gì cả.

Vấn đề khởi đầu ra mớ hỗn độn, cũng giống như trường hợp đi vào ngõ cụt, là điều không thể tránh được. Kinh nghiệm và sự thận trọng có thể giúp bạn tránh được chúng, nhưng cuối cùng bạn sẽ vẫn có thể đưa ra một quyết định dẫn tới một mớ hỗn độn.

Sự phát triển của một mớ hỗn độn như vậy rất âm thầm, lặng lẽ. Ban đầu bạn đơn giản chỉ tạo ra một giải pháp cho một vấn đề, vẫn cẩn thận giữ cho code được đơn giản và sạch. Khi vấn đề lớn dần cả về phạm vi và sự phức tạp, bạn vẫn mở rộng code base đó, tiếp tục giữ cho nó được sạch sẽ nhất có thể. Nhưng tới một điểm nào đó thì bạn nhận ra rằng bạn đã lựa chọn một thiết kế sai từ lúc bắt đầu, và code của bạn đang không phát triển tốt theo hướng mà những yêu cầu của hệ thống đang đưa ra.

Đây chính là điểm uốn! Bạn có thể quay trở lại và sửa thiết kế. Nhưng bạn vẫn có thể vẫn tiếp tục tiến về phía trước. Việc quay trở lại trông có vẻ rất đắt giá bởi vì bạn sẽ phải làm lại toàn bộ phần code đang có, nhưng thực sự việc quay trở lại sẽ không bao giờ dễ dàng hơn vào lúc này. Nếu bạn tiếp tục tiến về trước thì bạn sẽ dẫn cả hệ thống vào trong vũng lầy mà nó có thể sẽ không bao giờ thoát ra được.

Những lập trình viên chuyên nghiệp sợ mớ hỗn độn hơn là họ sợ ngõ cụt. Họ luôn luôn đề phòng những mớ hỗn độn bắt đầu lớn dần không có giới hạn, và sẽ dành tất cả nỗ lực cần thiết để thoát khỏi chúng càng sớm và càng nhanh càng tốt.

Tiến bước qua một vũng lầy, khi bạn biết nó là một vũng lầy, thì đó là điều tồi tệ nhất của sự đảo ngược ưu tiên. Tiếp tục tiến bước nghĩa là bạn đang lừa dối chính bạn, lừa dối nhóm của bạn, lừa dối công ty của bạn, và lừa dối cả khách hàng của bạn. Bạn đang nói với họ rằng tất cả đều sẽ tốt đẹp, trong khi thực tế là bạn đang đâm đầu vào sự diệt vong.

Kết luận

Những lập trình viên chuyên nghiệp rất siêng năng trong việc quản lý thời gian và sự tập trung của họ. Họ hiểu được những cám dỗ của sự đảo ngược ưu tiên và chiến đấu với nó với tất cả danh dự của mình. Họ luôn cởi mở về những giải pháp thay thế. Họ không bao giờ trở nên dính quá chặt vào một giải pháp đến nỗi họ không thể từ bỏ nó. Và họ luôn luôn đề phòng những mớ hỗn độn lớn dần lên, và họ sẽ dọn dẹp chúng ngay khi họ nhận ra. Không có cảnh tượng nào đau buồn hơn cảnh một nhóm các lập trình viên đang bì bõm lội qua một bãi lầy sâu trong vô vọng.


[1] Manna là vật phẩm phổ biến trong các trò chơi nhập vai như Dungeons & Dragons. Mỗi người có một lượng manna nhất định, đó là một loại vật chất ma thuật được dùng khi người chơi sử dụng phép thuật. Phép thuật càng mạnh thì lượng manna cần phải dùng càng nhiều. Manna tự nạp lại hàng ngày ở tốc độ chậm và cố định. Vì vậy manna có thể bị dùng hết chỉ với vài lần thi triển phép.

[2] khoảng 32 đến 48km.

[3] http://www.pomodorotechnique.com/

Trả lời

Email của bạn sẽ không được hiển thị công khai.