Là một lập trình viên solo, bạn quản lý công việc một cách có hệ thống như thế nào?

 (news.ycombinator.com)
53 điểm bởi xguru 2024-06-25 | 6 bình luận | Chia sẻ qua WhatsApp
  • Khi làm việc cùng một nhóm, các mục tiêu ngắn hạn kiểu scrum và một backlog công việc có tổ chức thực sự giúp duy trì sự tập trung và theo dõi những việc cần làm
  • Nhưng khi phát triển một mình, tôi chưa tìm ra cách tiếp cận thực sự phù hợp, và thường bị chệch hướng rồi đánh mất mục tiêu
  • Mọi người dùng công cụ và kỹ thuật nào để bám sát mục tiêu?

CharlieDigital

  • Dùng sổ giấy
  • Khi không cần chia sẻ thông tin, khó có gì tốt hơn một cuốn sổ để bung hết ý tưởng ra và xem đi xem lại nhiều lần. Không cần đăng nhập, có thể mang đi bất cứ đâu, ngồi trên ghế công viên để nghĩ ý tưởng, hoặc đến phòng gym rồi ghi chúng lại.
  • Chỉ cần viết mục tiêu hằng ngày thành checklist và đánh dấu từng mục. Không cần chia sẻ trạng thái với người khác nên cũng không cần thứ như GitHub Projects

olooney

  • Dùng file TODO.md
  • Viết danh sách bằng GFM(GitHub flavored markdown) như sau 
      1. [X] Dockerfile  
  2. [ ] Bulk Inference  
  3. [ ] CLI  
  4. [ ] Logging
  • Ở trên cùng có một mục tên là backlog cho các ý tưởng tương lai, một mục bugs cho các lỗi cần sửa, và một mục không tên chứa các hạng mục hiện tại
  • Khi đạt một cột mốc như phát hành bản release, xóa toàn bộ các mục đã hoàn thành

jasonb05

  • Viết rất nhiều thứ cho bản thân trong tương lai
    1. Trello có các cột theo tuần, tháng, quý và năm
    2. Mở cuốn sổ đặt cạnh chuột
      2a. Trang bên trái: checklist việc cần làm hằng ngày bằng bút và giấy. (2~3 dòng mỗi ngày)
      2b. Trang bên phải: ghi nháp, phác thảo bố cục, giấy note dán, v.v.
    3. Nhật ký phát triển để ghi lại nghiên cứu, URL, bài báo, suy nghĩ, ý tưởng, tiến độ, phần mở rộng, v.v.
    • Mọi dự án GitHub đều có thư mục dev/ cho các ghi chú này, với tên file dạng yyyymmmdd-n.txt
    • Tạo file mới mỗi ngày cho từng dự án khi cần
    1. Giấy note màu vàng cho các ý tưởng tạm thời (dán ở mép dưới màn hình, sổ hoặc bảng trắng)
    • Thường là các châm ngôn chỉ ra hướng đi đúng của dự án (ví dụ: "không ai đời nào đọc rtfm")
    1. Bảng trắng, các cột theo từng dự án, bản in + nam châm (biểu đồ tiến độ dự án theo tháng), giấy note, ý tưởng cho các dự án tương lai, và đủ loại đồ đạc khác
  • Tôi cố gắng giao tiếp quá mức với chính mình trong tương lai
    • Điều đó giúp tôi sắp xếp suy nghĩ hiện tại về kỳ vọng, tiến độ, trở ngại, v.v.
    • Chính tôi là chướng ngại, không phải công việc
    • Công việc thường được biểu diễn thành các con số sau khi đã "nghĩ rất kỹ"
  • Tôi đã làm việc một mình theo cách này suốt 8 năm
    • Từ thời làm tiến sĩ đầu những năm 2000, tôi đã dùng thư mục /dev và các file .txt làm nhật ký phát triển theo thời gian thực. Nó đã tiết kiệm cho tôi vô số thời gian (grep).
  • À, và tôi làm cùng một kiểu việc mỗi ngày. Gần như mỗi ngày
    • Ví dụ hỗ trợ khách hàng, quảng bá, viết lách, code, rồi... không cần suy nghĩ, cứ làm việc đó rồi chuyển sang việc tiếp theo

liampulles

Tehnix

  • Đặt mục tiêu theo ngày/tuần/tháng, rồi hệ thống hóa chúng bằng các app như Linear, Todoist, Notion
  • Mục tiêu theo tháng ở mức rất cao và chỉ có vài cái (ví dụ: "làm PoC", "thiết kế lại và tái phát hành blog")
  • Mục tiêu theo tuần cụ thể và giới hạn hơn (ví dụ: "quyết định cách gọi Rust từ mã Swift" hoặc "hoàn tất thiết kế và styling cho bài đăng")
  • Mục tiêu theo ngày thì rất cụ thể (ví dụ: "thiết lập pipeline UniFFI để tạo Swift bindings" hoặc "triển khai theme mới cho toàn bộ các trang blog")
  • Đôi khi trong lúc triển khai phát sinh việc mới nên mục tiêu ngày bị dời sang hôm sau
  • Cho đến nay, cách này khá hiệu quả để tăng tập trung; tôi chọn mục tiêu ngày dựa trên trọng tâm theo tuần trong danh sách nhiều công việc/vấn đề đang mở của nhiều dự án
  • Nếu đặt từng công việc đang diễn ra thành một project và gán ưu tiên ngay khi thêm việc, sẽ rất dễ có cái nhìn tổng quan về các dự án lớn nhỏ đang làm hoặc muốn làm tiếp theo
  • Tôi thích giấy nhưng chỉ dùng cho những việc tạm thời. Tôi thích cách làm số hóa hơn vì có thể dễ dàng thêm ý tưởng bằng điện thoại khi đang di chuyển. Viết bằng bàn phím cũng nhanh hơn nhiều, và trong khi làm việc hoặc nghiên cứu thứ gì đó, tôi dùng nhiều task khác nhau như một kho lưu trữ thông tin

OogieM

  • Quản lý trong Obsidian Vault, mỗi thứ là một thư mục riêng
  • Các thư mục có những thành phần chung tương tự nhau
    • Một ghi chú kanban dùng plugin kanban cho cấu trúc màn hình (màn hình nào có tính năng hay hoạt động gì)
    • Một ghi chú roadmap chứa chi tiết của từng tính năng
    • Một ghi chú thông thường chứa nhiều tác vụ khác nhau liên quan đến app hoặc thành phần đó
  • Dùng plugin tasks để theo dõi cụ thể những gì đang làm
    • Thư mục này còn có tài liệu bổ sung như ảnh chụp màn hình, tài liệu tham khảo và các ghi chú khác liên quan đến app cụ thể đó
  • Các dự án của tôi là một bộ chương trình quản lý gia súc và đăng ký giống hiếm
    • Vì vậy tôi có riêng các repo GitLab cho Farm Mobile(Android), Farm Desktop(Python), registry web(Flask), registry desktop(Python) và schema cơ sở dữ liệu(SQLite)
  • Giờ đã có thêm 3 cộng tác viên nên tôi chia sẻ Obsidian Vault qua Obsidian Sync. Hệ thống từng dành cho solo đã được mở rộng để xử lý teamwork

robomartin

  • Nhiều năm nay dùng một file văn bản đơn giản lấy cảm hứng từ kanban
  • Quản lý mọi thứ bằng cách này, từ dự án nhỏ đến dự án trị giá hàng triệu đô
  • Mỗi dự án có một file log chính, và các file riêng theo từng lĩnh vực (điện tử, cơ khí, quang học, sản xuất, kiểm thử, v.v.)
  • Nội dung file 
    <tên dự án> log file  
-------------------------------- WORKING ON NOW   
<công việc đang làm>  

-------------------------------- TO DO   
- <mỗi công việc bắt đầu bằng dấu gạch>  
  - <thụt lề cho subtask hoặc ghi chú liên quan>  

-------------------------------- IDEAS  
<ghi chú tự do>  

-------------------------------- RESOURCES  
<tài nguyên tự do>  

-------------------------------- DONE  
<chuyển các việc đã xong vào mục này>  
<nếu muốn thì để lại timestamp>

kkfx

  • Quản lý bằng Emacs/org-mode/org-roam
  • org-agenda của ghi chú năm hiện tại; các ghi chú theo kiểu mỗi ngày một file, mỗi năm một thư mục trong thư mục org-roam chung, được chia file theo mốc thời gian
  • Cách này giúp giảm lượng file mà org-agenda phải duyệt, và giảm lượng tài liệu kéo dài nhiều năm từ ghi chú tổng hợp năm này sang năm khác

makz

  • Trước khi tan làm, để lại comment trong code: "Tôi đang làm phần này, và để nó chạy được thì cần làm A, B, C..."
  • Lần sau mở editor ra sẽ biết chính xác cần làm gì

qntmfred

  • Có template daily routine trong Obsidian Daily Note. Nó giúp tôi tập trung và thấy hào hứng với ngày hôm đó
  • Dấu [X] đầu tiên tôi tự cho mình mỗi ngày là hoàn thành checklist routine hằng ngày
    • Một chiến thắng miễn phí để bắt đầu ngày làm việc năng suất
  • Thực tế tôi viết phần lớn ghi chú bằng tính năng voice typing của Windows, nên khá giống như đang làm daily standup
  • Tôi cũng thường livestream suốt cả ngày, ngay cả khi người xem chỉ có mình tôi (dĩ nhiên là livestream riêng tư nên ngày nào cũng làm vậy, để khi cần nhớ lại khoảng 20 phút trước mình đang làm gì/nghĩ gì trước khi lạc vào một rabbit hole nào đó. Thực ra Windows Recall cũng khá tốt)
  • Ngày làm việc của tôi diễn ra khá giống khi làm việc với người khác trong một tổ chức có từ 2 người trở lên (còn gọi là họp)

mentos

  • Một bảng Trello với ba danh sách Done/Doing/ToDo
    • Liệt kê mọi việc cần làm
    • Ưu tiên chúng
    • Chuyển mục trên cùng sang danh sách việc đang làm rồi bắt đầu xử lý
    • Khi xong thì chuyển sang Done. Lấy mục tiếp theo từ ToDo và lặp lại
  • Tôi dùng các danh sách khác trong Trello để quản lý các thẻ nghiên cứu hoặc loại bỏ khỏi ToDo các tính năng chưa cần cho v1

macNchz

  • Tôi thích làm việc theo cách gần giống khi làm cùng một nhóm nhỏ
    • Quản lý các issue trên GitHub, được sắp lỏng theo milestone bằng những checklist có nhiều hạng mục
      • Vì nó gần với code nên rất dễ ghi chú để nhớ mình đã dừng ở đâu, bằng các link dòng code, code block copy-paste hoặc bản nháp PR được liên kết
      • Rất dễ truy cập từ bất kỳ thiết bị nào, nên nếu nảy ra ý tưởng hoặc nhận email báo lỗi, tôi có thể nhanh chóng tạo issue ngay trên điện thoại hoặc thiết bị khác không phải máy phát triển
      • Cũng đơn giản để gọi thêm người khác vào đúng thời điểm và bắt tay làm ngay
      • Có API tốt và nhiều tích hợp khác nhau (ví dụ tạo hoặc liên kết issue trực tiếp từ hệ thống theo dõi lỗi)

rerdavies

  • Dùng GitHub Projects
    • Không hẳn là muốn đặc biệt khuyến nghị
    • Nhưng việc quản lý danh sách công việc và bug thực ra không phải khoa học tên lửa
    • Tôi đã dùng những giải pháp quản lý dự án trị giá hàng trăm nghìn đô, và chúng còn tệ hơn nhiều
  • GitHub Projects dù hơi kỳ quặc và không được yêu chiều, nhưng về các chức năng tối thiểu thì là đủ
    • Có nhiều thứ bạn nghĩ lẽ ra phải tự động hóa được
      • Như rollover sang sprint mới chỉ bằng vài cú click mà không cần sửa tay mọi truy vấn của scrum board
    • Nhưng bạn vẫn có thể làm được việc mình muốn
      • Còn tốt hơn nhiều so với việc phải sống gò bó trong một quy trình cứng nhắc do người khác áp đặt
      • Ở một khía cạnh nào đó, tính tối giản cũng có thể là ưu điểm
  • Về mặt tinh thần, đây là bài toán quản lý danh sách. Không quá phức tạp. Và GitHub Projects làm việc quản lý danh sách rất ổn
  • Một lý do tôi khuyên dùng GitHub Projects hơn danh sách công việc trên giấy hoặc thẻ là
    • Người dùng có thể công khai nhìn thấy bug report và feature request đang được xử lý ra sao
    • Ngoài ra cũng rất dễ biến nội dung trên bảng thảo luận thành bug report hoặc thành công việc phát triển (trì hoãn hoặc đang hoạt động)
  • Các quy tắc scrum thông thường vẫn áp dụng. Mọi bug đều được sửa trước khi làm việc mới, và một việc chỉ được chuyển sang hoàn thành khi thật sự hoàn tất
  • Bạn cần một danh sách. Tôi thích có thêm cấu trúc sprint ở phía trên các task vì nó tạo ra milestone hữu ích cho các cập nhật giữa kỳ và phát hành liên tục

leros

  • Tôi tách riêng các vai trò như product manager, project manager, software developer, marketing, vận hành kinh doanh, lãnh đạo toàn bộ doanh nghiệp... và chỉ làm một vai trò tại một thời điểm
  • Ví dụ
    • Tôi có thể ngồi xuống với vai trò lãnh đạo doanh nghiệp để quyết định hướng chiến lược mình muốn
    • Sau đó đội mũ product manager để quyết định sẽ xây gì
    • Rồi quản lý dự án cho ý tưởng đó và sắp xếp ưu tiên
    • Sau đó thành product manager/designer để cụ thể hóa các tính năng đã ưu tiên
    • Rồi dành ra thời gian hoàn toàn tách biệt (thường là trọn một ngày) để phát triển tính năng
    • Khi tính năng được phát hành, tôi đội mũ marketing và làm phần tiếp thị sản phẩm liên quan
    • Đó là một dạng vòng đời để phát triển một tính năng
  • Điều nguy hiểm là nhảy qua lại tất cả các vai trò cùng lúc. Năng suất có thể giảm mạnh
  • Có lúc cần tư duy chiến lược, có lúc cần sáng tạo, có lúc chỉ cần thực thi; và các loại công việc này cần những không gian tinh thần khác nhau
  • Tôi lập mọi kế hoạch trong Notion và dùng vài bảng kanban khác nhau tùy theo mục đích

urda

  • Tôi dùng một hệ thống "tri thức" theo tầng nấc
    • Ghi những suy nghĩ chợt đến, ghi chú, mẩu vụn, sơ đồ, v.v. vào sổ Moleskine bỏ túi
    • Cuối cùng chúng sẽ trở thành một "ticket" trong issue tracker, hoặc thành "wiki" hay "wiki update" trên máy chủ wiki của tôi
    • Rồi từ đó tiếp tục dẫn đến snippet, ghi chú cấu hình, tài liệu hồ sơ, lưu trữ, runbook, v.v.
  • Cuối cùng, việc giữ tài liệu luôn cập nhật hoặc đưa issue vào đúng backlog khi phát hiện ra nó đã trở thành điều "tự nhiên"

Bài viết liên quan

6 bình luận

 
xguru 2024-06-30

Tôi nghĩ rằng với tư cách là một dev solo, cách tốt nhất là biến bất cứ thứ gì thành thói quen phù hợp với bản thân. Nếu phải chuẩn bị quá nhiều thứ khác nên việc mở tài liệu quản lý rồi mới bắt đầu trở nên mất thời gian và phiền phức, thì dần dần bạn sẽ ngày càng xa rời nó. Ngay cả việc dọn bàn xong rồi lấy chiếc laptop đã cất ở đâu đó ra và mở lên cũng tự nó đã thấy như một công việc rồi.

Ở điểm này thì với tôi, vì VS Code gần như luôn mở sẵn trên máy tính ở nhà và ở công ty, nên việc ghi rồi xóa nội dung trên 할일.txt đang mở trên đó là công việc hằng ngày. Tôi thấy cách này tốt vì không cần nghĩ xem phải mở gì, mọi thứ đã thành thói quen. Nội dung thì tôi đồng bộ bằng GitHub Private Repo.
 
mytory 2024-06-26

Tôi chia toàn bộ công việc cần làm của dự án trên Google Sheets thành các đơn vị 30 phút đến 1 giờ, ghi lại hết và cũng ghi luôn thời gian đã tốn cho đến khi hoàn thành. Nhờ vậy dễ dự đoán hơn và cũng có cảm giác lần lượt hoàn thành từng việc một.
 
devsepnine 2024-06-26

Tôi có vẻ chủ yếu dùng Trello, liệt kê mọi thứ ra rồi sắp xếp phần mô tả...
Có thể truy cập từ bất cứ đâu nên...
 
tested 2024-06-25

Tôi tạo một server cá nhân trên Discord, rồi phân loại bằng category/channel và dùng nó cho mục đích cá nhân như TODO.
 
porteleaf 2024-06-25

Mình đã thử nhiều cách khác nhau nhưng vẫn chưa thể ổn định với một phương pháp duy nhất. Hiện tại mình ghi chú trong Obsidian, còn công việc thực tế thì khi cần sẽ ghi vào legal pad.
Có lẽ vì đây cũng là những ghi chú để thay thế trí nhớ ngắn hạn, nên sau một thời gian mình thường hay quên mất là trước đó đã ghi gì..
Chắc mình sẽ tham khảo bài viết này để sắp xếp lại hệ thống của mình..
 
hwan0317 2024-06-25

Ngay cả khi không nhất thiết là phát triển một mình, đây vẫn là những nội dung hữu ích để quản lý động lực và kế hoạch một cách tổng quát!