- Khi thực hiện các dự án kỹ thuật quy mô lớn, để duy trì động lực và đi đến đích, kết quả hữu hình hằng ngày là rất quan trọng
- Tôi chia dự án không phải thành những khối lớn và mơ hồ, mà thành những đơn vị nhỏ có thể nhìn thấy được, và chọn cách để có thể xác nhận tiến độ thực chất ở mỗi giai đoạn
- Ở giai đoạn đầu, việc tạo demo nhanh với vòng lặp phản hồi chặt chẽ giúp rất nhiều cho sự tập trung và tự tạo động lực
- Cách làm hiệu quả là trước tiên phát triển những chức năng cần thiết cho riêng mình, rồi tiếp tục hoàn thiện thông qua việc sử dụng thực tế
- Tôi coi trọng tiến triển hơn sự hoàn hảo, và việc lặp lại những trải nghiệm thành công nhỏ sẽ dẫn đến việc hoàn thành các dự án dài hơi
Ở điểm khởi đầu
- Khi bắt đầu một dự án lớn, trở ngại lớn nhất là quyết định nên bắt đầu từ đâu
- Nếu cân nhắc mọi thành phần cùng một lúc, mọi thứ sẽ trở nên quá mơ hồ và rất dễ mất hứng thú
- Điều quan trọng là bắt tay từ những đơn vị nhỏ có thể cho thấy kết quả nhanh
- Mỗi dự án con nên độc lập và phải cung cấp dấu hiệu hoàn thành rõ ràng
- Càng có nhiều kinh nghiệm, bạn càng nắm bắt tốt hơn hình dáng tổng thể và các thành phần con của dự án
Tạo ra kết quả ban đầu
- Công việc ở giai đoạn đầu có thể ít biểu hiện ra bên ngoài, nên tiến độ có thể khó nhìn thấy
- Trong trường hợp đó, điều quan trọng là tận dụng hợp lý kiểm thử tự động (ví dụ: unit test) để tạo ra kết quả hữu hình
- Ví dụ, khi tạo một trình phân tích cú pháp terminal, bạn có thể kiểm tra ngay kết quả phân tích của chuỗi đầu vào bằng test
- Việc lặp đi lặp lại trải nghiệm test chạy qua tự nó đã mang lại cảm giác thành tựu
- Thông qua những thành công nhỏ như vậy, bạn có thể liên tục tích lũy bằng chứng khách quan về tiến độ của toàn bộ dự án
Tạo demo thật nhanh
- Mục tiêu ban đầu không phải là một thành phần con hoàn hảo mà là một bản triển khai đủ dùng để demo
- Những độ phức tạp cần thiết về lâu dài (ví dụ: cơ sở dữ liệu, cấu trúc dữ liệu nâng cao, v.v.) tạm thời được gác lại, và ưu tiên hàng đầu là tiến nhanh bằng triển khai đơn giản
- Luôn ghi nhớ rằng 'sự hoàn hảo có thể trở thành kẻ thù cản trở tiến bộ'
- Tôi đặt mục tiêu làm demo đơn giản một hoặc hai lần mỗi tuần
- Dù là demo chưa hoàn chỉnh, việc trực tiếp kiểm chứng và nhận phản hồi trực quan vẫn rất hữu ích và góp phần lớn vào việc duy trì động lực
Phát triển cho chính mình
- Đặc biệt với dự án cá nhân, tôi ưu tiên triển khai những chức năng mà bản thân cần trước, và coi trọng quá trình tự áp dụng và tự sử dụng chúng
- Trong lúc trực tiếp sử dụng, tôi cảm nhận được những điểm còn thiếu, rồi cải thiện bằng cách tập trung vào các tính năng thực sự cần thiết, từ đó phát triển dự án từ góc nhìn của một người dùng thực thụ
- Ở giai đoạn đầu sử dụng, những bất tiện hay lỗi sẽ lộ ra, nhưng chính điều đó lại cho biết rõ việc cần làm tiếp theo là gì
- Niềm tự hào khi sử dụng phần mềm do chính mình viết ra là một yếu tố giúp duy trì dự án
- Ban đầu tôi lược bỏ toàn bộ các tính năng không cần thiết (cuộn, chọn bằng chuột, tab, v.v.)
Cách đóng gói toàn bộ dự án
- Chia toàn bộ vấn đề thành những vấn đề nhỏ có thể nhìn thấy được. Mỗi vấn đề phải cho phép xác nhận kết quả thực chất
- Mỗi vấn đề nhỏ chỉ cần được giải quyết đến mức đủ để làm demo rồi chuyển sang vấn đề tiếp theo
- Tạo demo hoạt động được càng sớm càng tốt, sau đó bổ sung tính năng theo cách lặp lại
- Ưu tiên triển khai những tính năng có ý nghĩa với chính mình
- Khi cần, lặp lại việc cải thiện từng thành phần và xoay vòng quy trình này
Kết luận
- Với cách làm trên, tôi có thể tự tạo động lực và hoàn thành nhiều kiểu dự án khác nhau như cá nhân, nhóm, công việc hay học tập
- Trọng tâm không phải là phát hành hay tooling, mà là cách nào thực sự giúp duy trì động lực một cách bền vững
- Không phải phương pháp nào cũng phù hợp với tất cả mọi người, nhưng kết quả tiến triển có thể nhìn thấy được là sức mạnh lớn nhất để hoàn thành các dự án dài hơi
- Điều quan trọng là hiểu rõ sở thích và cách bản thân được tạo động lực, rồi xây dựng quy trình làm việc phù hợp với điều đó
1 bình luận
Ý kiến trên Hacker News
Tôi đồng ý với mọi ý trong bài và đồng thời muốn bổ sung thêm một điều: tầm quan trọng của vòng lặp phản hồi nhanh
Khi bạn thay đổi gì đó và có thể thấy kết quả ngay lập tức, điều đó thực sự tạo động lực
Khi nghịch sửa mã và quan sát tác động của nó, nhiều vấn đề sẽ biến mất hoặc chuyển thành dạng dễ giải quyết hơn
Ở các dự án lớn, tôi thấy có mối tương quan rõ ràng giữa việc thiết lập/chạy dự án dễ đến đâu và số lượng vấn đề của dự án đó (bug, trễ deadline, v.v.)
Bài nói chuyện này nói về vòng lặp phản hồi
Liên kết YouTube
Tôi đang cân nhắc áp dụng e2e test cho các bug đã phát hiện để xác nhận rằng chúng thực sự đã được sửa
Khi bạn muốn thử hoặc sửa một thứ gì đó mà chỉ riêng việc setup đã mất vài tiếng, bạn sẽ mất động lực và cuối cùng cứ trì hoãn
Vì thế tôi thích những ngôn ngữ có REPL hữu dụng như lisp
Có cảm giác thỏa mãn tức thì khi có thể thấy kết quả ngay tại chỗ
Ngay khi bạn mất động lực, dự án đó coi như bốc hơi
Vì vậy, việc biến chính quá trình phát triển thành một trải nghiệm thú vị gần như là yếu tố quan trọng nhất
Tôi thấy kinh nghiệm đôi khi lại cản trở
Tôi thường thấy các kỹ sư cấp cao đào rất sâu để làm ra thứ hoàn hảo, nhưng đến lúc demo thì kết quả lại không ra sao
Phần triển khai có thể rất tốt, nhưng bản thân tính năng hay sản phẩm lại hoàn toàn không ổn
Đôi khi tôi chỉ muốn tắt não và viết ào một đống mã xấu xí
Trước đây tôi từng làm nhiều dự án nghịch ngợm và nhét toàn bộ mã nguồn vào một file duy nhất
Chẳng bận tâm đến modular hóa, nhưng vẫn vui và vẫn chạy
Nhưng giờ thì ngay cả việc hoàn thành một dự án nhỏ để nghịch cũng trở nên rất khó
Có vẻ vì đã từng làm một lần rồi nên ta có xu hướng nhét vào đủ loại tính năng phụ không cần thiết
Ví dụ, nếu tham gia các coding challenge như Advent of Code, các bài đầu thường đơn giản và chỉ về sau mới cần tối ưu hay thuật toán phức tạp
Hoặc như pico-8, môi trường bị giới hạn nên không thể ngồi code lê thê quá lâu
Hay thử trong bối cảnh bị giới hạn thời gian như hackathon hoặc game jam cũng có ích
Vì những người còn ít kinh nghiệm có thể quên hết các 'best practice' đã phát chán ở ngôn ngữ cũ và thử nghiệm một cách tự do
Tôi tự thiết kế các bảng DB, còn phần triển khai thì giao cho LLM tự do xử lý hơn một chút
Tôi ấn tượng với ý rằng mục tiêu của các dự án con ở giai đoạn đầu không phải là tạo ra một 'sub-component hoàn chỉnh', mà là tạo ra một sub-component 'đủ ổn' để có thể chuyển sang bước tiếp theo
Để thực hành cách này, tôi nhận ra rằng phải 'bỏ qua' một số thứ
Người khác nói họ sẽ bỏ qua việc modular hóa mã trong chế độ này, nhưng với tôi, giữ mã gọn gàng lại đem đến cảm giác thỏa mãn và động lực
Vì vậy tôi định 'bỏ qua' các phần như thuật toán, cấu trúc dữ liệu và hiệu năng
Rốt cuộc, mấu chốt là chắc chắn phải lướt qua một vài thứ, nhưng nếu chính thứ đó lại là yếu tố tạo động lực cho mình thì không nên bỏ qua
Demo đóng vai trò là bước trung gian giữa việc phát triển phần mềm (lập trình) và giải thích nó bằng chữ viết (tài liệu hóa)
Thông qua demo, tôi có thể liên tục kiểm chứng giả thuyết về việc dự án của mình nên làm gì, và nó trở thành một dạng cơ chế phản hồi
Demo tồn tại lâu dài nên khi làm hỏng một tính năng, bạn có thể nhận ra ngay và tiếp tục vòng lặp sửa chữa
Cá nhân tôi đang làm việc theo cách này với game engine mình đang phát triển
Ví dụ demo trên github
Tôi ước gì cách này trở thành điều hiển nhiên với mọi người
Nó có cảm giác tập trung vào các dự án cá nhân
Điều tôi muốn biết là cách tốt để mọi người cùng làm việc hướng tới một mục tiêu trong các dự án kỹ thuật quy mô lớn, và thực sự hoàn thành mọi thứ cho tử tế
Sau gần 15 năm làm việc, tôi chưa từng thấy một dự án kỹ thuật nào không vượt ngân sách, trễ tiến độ, thiếu tính năng hoặc khiến mọi người kiệt sức
Ngược lại, nếu có ví dụ nào về các dự án lớn được dẫn dắt thành công, tôi rất muốn được chia sẻ thêm các liên kết hoặc tài liệu nên đọc
Vượt ngân sách là chuyện rất thường gặp, miễn là tiền chưa thực sự cạn
Đa số trường hợp chỉ là có ai đó than phiền rằng ước tính ban đầu bị sai
Trễ tiến độ cũng vậy, nếu không có một deadline thật sự bắt buộc thì cũng không phải vấn đề nghiêm trọng
Thực ra, những sự kiện gắn với lịch trình như chiến dịch quảng bá lớn tốt nhất là đừng lên kế hoạch cho đến khi dự án gần hoàn tất
Thiếu tính năng thì rốt cuộc cũng là vấn đề của kỳ vọng
Vấn đề thực sự là 'mọi người bị rút cạn hoàn toàn và burnout'
Ít nhất thì đó là điều chắc chắn phải tránh
Cá nhân tôi ngày càng có thiện cảm với Scaled Agile Framework
Tôi dùng nó như một framework, tức một kiểu 'bù nhìn' có thể biến đổi theo tình huống
Nhờ đó tôi đi sâu hơn vào các tài liệu gốc và tự rút ra kết luận
Tôi đã học được rằng thành công thực sự bắt đầu từ việc 'hiểu rõ vì sao mình làm cái này'
Nếu mục tiêu không rõ ràng, bạn sẽ không thể sắp xếp ưu tiên và cũng không biết nên bắt đầu từ đâu
Sự rõ ràng đó giúp ích rất nhiều cho việc quyết định 'xây cái gì và khi nào', và đôi khi còn giúp đưa ra quyết định 'không xây nó luôn'
Điều quan trọng tiếp theo là 'sự đồng cảm'
Bạn phải thật sự hiểu vấn đề của khách hàng từ góc nhìn của họ và đưa ra giải pháp
Không phải chỉ là làm hết mọi thứ khách hàng đòi hỏi, mà là hiểu chính xác nỗi đau cốt lõi để trao giá trị thật sự
Lý do thật sự khiến đa số dự án thất bại là vì đội ngũ dành quá nhiều thời gian để xây 'nhầm thứ'
Nếu ta liên tục tập trung vào những thứ cần thiết, những tính năng mà mọi người thực sự muốn hoặc sẵn sàng trả tiền, thì sẽ có nhiều dự án được hoàn thành thành công hơn rất nhiều
Có rất nhiều người nhìn vào một dự án lớn rồi rơi vào phân tích quá mức
Thứ thực sự khó là hoàn thành nó
Nếu bạn xây phần mềm để chính mình dùng, bạn có thể tự giải quyết vấn đề của bản thân
Bạn cũng có thể phát hiện bug của phần mềm khi trực tiếp sử dụng nó
Thực tế, tôi đã tìm ra nhiều bug khi tự xây và dùng web server của mình
Một văn hóa phát triển tập trung, lặp lại và luôn hướng đến các kết quả đang hoạt động