daily-digest

Simon Willison’s Weblog

The new ChatGPT Images is here

OpenAI cập nhật tính năng ChatGPT Images, thu hút 100 triệu người dùng trong tuần đầu tiên phát hành vào tháng 3.
Tính năng này hiện nhanh hơn và tuân thủ hướng dẫn tốt hơn.
ChatGPT Images có thể thực hiện chỉnh sửa chính xác và tạo hình ảnh nhanh gấp 4 lần.
Chi phí sử dụng API mới gpt-image-1.5 rẻ hơn 20% so với phiên bản trước.
Kết quả hình ảnh từ ChatGPT Kākāpō cho thấy các đối tượng có phần tròn trịa hơn.
Cả ChatGPT Images và Nano Banana Pro hiện đều có thể tạo đồ họa nhiều văn bản, nâng cao tính hữu dụng.

s3-credentials 0.17

Phiên bản mới của công cụ CLI s3-credentials là 0.17.
Thêm các lệnh mới: get-bucket-policy và set-bucket-policy (#91).
Thêm các lệnh mới: get-public-access-block và set-public-access-block (#92).
Thêm lệnh localserver để khởi động web server, cung cấp thông tin đăng nhập tạm thời qua API JSON (#93).
Lệnh localserver sử dụng thư viện chuẩn Python và chạy trên cổng 8094 mặc định.
Tuỳ chọn -p/–port có thể được dùng để thiết lập cổng khác.
Lệnh localserver yêu cầu tham số –refresh-interval (ví dụ: 5m, 10h, 30s).
Lệnh localserver trả về thông tin đăng nhập IAM tạm thời cho S3 bucket cụ thể.
Các thông tin đăng nhập này sẽ được lưu trữ tạm thời và tạo mới khi hết hạn.

ty: An extremely fast Python type checker and LSP

Ty là một công cụ kiểm tra kiểu Python và LSP mới, hiện tại đang trong giai đoạn beta.
Không sử dụng caching, ty nhanh hơn mypy từ 10x đến 60x.
Trong môi trường biên tập, ty nhanh hơn nhiều; ví dụ, sau khi chỉnh sửa tệp quan trọng trong kho PyTorch, ty tính toán lại chẩn đoán trong 4.7ms (80x nhanh hơn Pyright 386ms và 500x nhanh hơn Pyrefly 2.38 giây).
Người dùng có thể thử ty dễ dàng qua uvx với lệnh: cd my-python-project/ và uvx ty check.
Astral cũng phát hành một extension mới cho VS Code, cung cấp tính năng máy chủ ngôn ngữ dựa trên ty như “go to definition”.
Tác giả cảm thấy cần thời gian để hiểu rõ hơn về cách hoạt động và tính năng của extension này.

Poe the Poet

Poe the Poet là tùy chọn để thêm các lệnh bổ sung trong file pyproject.toml để chạy bằng uv.
Lệnh “uv run poe livehtml” hoạt động để chạy server preview cho tài liệu.
Đoạn mã TOML thêm vào pyproject.toml bao gồm các nhóm phụ thuộc: test, docs, và dev.
Nhóm dev bao gồm các nhóm test và docs cùng với poethepoet phiên bản >=0.38.0.
Các tác vụ trong [tool.poe.tasks] được định nghĩa bao gồm: docs, livehtml, và cog.
Khi chạy “uv run …”, poethepoet sẽ có sẵn trong môi trường vì nó nằm trong nhóm dev.

Quoting Gemini thinking trace

Người dùng đang xem xét “thực tế cạnh tranh” với các sản phẩm khác.
Ghi chú liên quan đến manifest.json và content.js được xem xét.
Đề xuất loại bỏ quyền scripting được coi là hợp lý và làm cho mã sạch hơn.
Phân tích của người viết cho thấy sự tự mãn cao trong đánh giá.
Có sự nghi ngờ về nguồn gốc của nhận xét, có thể là từ Claude hoặc tự vạch ra.
Người dùng muốn chứng tỏ khả năng của mình trong bối cảnh được kiểm tra.

Quoting Kent Beck

Các lập trình viên thiếu kinh nghiệm đang sử dụng AI coding assistants hiệu quả.
Họ áp dụng phương pháp coding tăng cường để học nhanh hơn mà vẫn giữ chất lượng.
Thời gian để hoàn thành nhiệm vụ giảm đáng kể, từ ngày xuống còn giờ.
AI giúp thu hẹp không gian tìm kiếm, cụ thể là rút ngắn thời gian đánh giá API từ ba giờ xuống còn hai mươi phút.
Thời gian tiết kiệm không dành cho các tính năng không hiệu quả mà được đầu tư cho việc học.
Khả năng sử dụng AI hiệu quả làm tăng tốc độ học hỏi của lập trình viên mới vào nghề.

Stay SaaSy

Own A Graph

Kỹ sư cấp cao, PM hoặc nhà thiết kế cần sở hữu một biểu đồ để cải thiện công việc của họ.
Biểu đồ giúp thể hiện giá trị của công việc và giải quyết các vấn đề lớn.
Công việc của bạn nên được hiển thị dưới dạng biểu đồ trong khoảng thời gian nhiều quý.
Các lĩnh vực nên có biểu đồ bao gồm: Giảm số trang, Cải thiện hiệu suất, Tiết kiệm chi phí, Tăng doanh thu, Giảm tỷ lệ khách hàng rời bỏ.
Việc giao tiếp tác động không hiệu quả thường là vấn đề của chính bạn, không phải do người khác.
Biểu đồ có vai trò quan trọng trong việc truyền đạt tác động của bạn một cách rõ ràng và nhanh chóng.
Một biểu đồ có thể thay thế nhiều đoạn văn bản, cung cấp bối cảnh về quy mô, lịch sử và sự biến động.
Việc sở hữu biểu đồ giúp bạn nhận phản hồi trực tiếp về công việc của mình.
Sự kết hợp giữa việc đặt mục tiêu và theo dõi qua biểu đồ có thể tạo ra khác biệt lớn trong hiệu suất công việc.
Tránh việc “sở hữu quá nhiều biểu đồ” và chỉ tập trung vào một vài biểu đồ quan trọng.
Các vị trí như vấn đề chất lượng, vé hỗ trợ, doanh thu, và tỷ lệ chiến thắng cạnh tranh là những lĩnh vực tốt để xây dựng biểu đồ.
Theo dõi các chỉ số quan trọng ngay cả khi bạn không thể tác động trực tiếp đến chúng là đủ để phát triển sự nghiệp.

The Two Jobs of a CPO

Vai trò của CPO gồm hai nhiệm vụ chính: xây dựng văn hóa sản phẩm mạnh mẽ và họp tác chặt chẽ với CEO để thiết lập chiến lược sản phẩm đúng đắn.
CPO phải quản lý nhóm đa chức năng, đảm bảo tổ chức hoạt động hiệu quả và chất lượng cao.
Sự đồng bộ giữa chiến lược sản phẩm và hướng đi của công ty là rất quan trọng; sai lệch sẽ dẫn đến việc mất vị trí CPO.
CPO không chỉ làm theo ý của CEO mà còn phải nâng cao và hỗ trợ các ý tưởng tốt nhất từ đội ngũ của mình.
Thiết lập quy trình hoạt động phù hợp và hiệu quả là cần thiết cho nhóm sản phẩm, gồm việc tạo mẫu, nghi thức và kế hoạch phỏng vấn.
Delegating các nhiệm vụ quản lý sản phẩm cho người chưa có kinh nghiệm thực tiễn là không hiệu quả.
Sản phẩm cần phải được định hình theo yêu cầu và văn hóa cao, không thể áp dụng mẫu chung cho mọi tình huống.

Episode 5: Compensation

Tiền bạc không thể thay thế cho tiền. Nhân viên cần được trả lương hợp lý.
Không nên nghĩ rằng sứ mệnh của công ty có thể bù đắp cho sự chênh lệch về lương.
Kiểm tra All Hands: bạn không phải bảo vệ quyết định tiền lương cá nhân, nhưng cần có khả năng giải thích tổng thể.
Mức lương có thể khiến nhân viên tức giận, nhưng hiếm khi làm họ vui mừng; rủi ro lớn hơn lợi ích.
Không coi thường mức lương của nhân viên trẻ; thị trường có quy luật riêng.
Cần tuân thủ các quy tắc đã thỏa thuận về tiền lương và không thay đổi khi công ty phát triển.

Leveling Up Teams Fast and Slow

Cách tốt nhất để doanh nghiệp chiến thắng là di chuyển nhanh và điều này phụ thuộc vào đội ngũ hoạt động hiệu quả.
Các yếu tố quan trọng cho đội ngũ hiệu quả bao gồm tuyển dụng, quản lý hiệu suất và thiết lập mục tiêu rõ ràng.
Hai hoạt động cơ bản để duy trì một đội ngũ tốt là nâng cao năng lực và xử lý đội ngũ yếu kém.
Các tổ chức có xu hướng bị kéo xuống bởi hiệu suất thấp của các nhóm yếu kém xung quanh.
Cần dành thời gian để khắc phục vấn đề ở đội ngũ yếu nhất để nâng cao chất lượng tổ chức tổng thể.
Thường thì những vấn đề đội ngũ gặp phải không phải hoàn toàn do lỗi của họ mà do các động lực, đối tác yếu hoặc hiểu lầm.
Tập trung vào việc cải thiện từng đội ngũ một thay vì tất cả cùng lúc hiệu quả hơn.
Để tăng cường hiệu suất nhanh hơn, nên giao quyền chỉ huy cho những người có năng lực nhất bất kể chức danh.
Việc này có thể gây xáo trộn chuỗi chỉ huy nhưng thường mang lại kết quả tích cực nhanh chóng.
Các thành viên hàng đầu trong tổ chức thường vượt trội hơn so với những thành viên trung bình, vì vậy cần phát huy khả năng của họ.
Đừng để quá nhiều người cùng chỉ huy một dự án, điều này gây khó khăn cho quá trình ra quyết định.
Giao trách nhiệm cho người giỏi nhất giúp cải thiện sự tự tin và hiệu suất của cả đội.

Specialization Is For Insects

Các công ty lớn chuyển từ đội ngũ đa nhiệm sang đội ngũ chuyên môn hóa theo từng lĩnh vực.
Trong các startup, nhân viên có thể đảm nhận nhiều vai trò khác nhau như kỹ sư, quản lý sản phẩm (PM), và các vai trò chuyên sâu khác.
Chuyển đổi sang chuyên môn hóa giúp tăng chất lượng đầu ra cho từng nhiệm vụ cụ thể.
Việc cần nhiều chuyên gia dẫn đến tăng cường sự phối hợp, có thể làm chậm tiến độ hoàn thành dự án.
Khó khăn trong phối hợp có thể dẫn đến thiếu thời gian cho các vòng lặp điều chỉnh, làm chất lượng giảm.
Nếu số lượng chuyên gia tăng lên, khả năng có thành viên làm việc kém trong nhóm là 100%.
Nhiều công ty không thể phản ứng kịp thời với thành viên làm việc kém do quản lý hiệu suất chậm.
Nhân viên giỏi có thể làm tốt hơn các chuyên gia trung bình trong lĩnh vực của họ (ví dụ: một kỹ sư giỏi hơn PM trung bình trong quản lý sản phẩm).
Tăng trưởng số lượng nhân viên cần có sự giám sát chặt chẽ để tránh các vấn đề về hiệu suất và thời gian.
Nên giữ cấu trúc tổ chức gọn nhẹ và không vượt quá 2 tầng cho tới khi thật sự cần thiết.

How to Compete in SaaS

Lời khuyên truyền thống cho các công ty công nghệ là không nên chú ý đến đối thủ cạnh tranh và tập trung vào khách hàng, nhưng điều này không đúng với SaaS.
Nếu bạn bỏ qua đối thủ, bạn có thể mất khách hàng vào tay những đối thủ mạnh mẽ hơn.
Tất cả các thị trường đều có cạnh tranh và nếu không có đối thủ, có thể bạn đang chọn một thị trường không khả thi.
Thị trường thường ổn định với 1-3 người chơi chiếm giữ phần lớn thị trường.
Để trở thành người dẫn đầu, bạn cần là người số 1 trong một phân khúc đáng tin cậy hoặc là người dẫn đầu toàn diện trong danh mục sản phẩm.
Để khẳng định vị trí của mình, bạn phải gây áp lực lên đối thủ, khiến họ phải điều chỉnh chiến lược sản phẩm và tiếp thị.
Đối thủ khó bị đánh bại nếu có doanh thu hàng năm trên 25 triệu USD.
Các đòn tấn công trực diện bao gồm sa thải, thay đổi mô hình kinh doanh và bán buôn.
Để gây ảnh hưởng, bạn cần tác động đến sự thành công của đội ngũ bán hàng của đối thủ.
Khi đội ngũ bán hàng không đạt chỉ tiêu, cảm giác cạnh tranh với bạn trở thành gánh nặng cho họ.
Cuối cùng, các công ty sẽ bị áp lực và có thể từ bỏ cuộc cạnh tranh khi việc này trở thành gánh nặng nghề nghiệp.

Episode 4: How To Be A Great Employee

Hiểu rõ về doanh nghiệp để cải thiện doanh nghiệp (NDR là một yếu tố quan trọng).
Phản ứng tốt với yêu cầu từ sếp.
Tránh xem mọi thứ như một sự đánh đổi.
Biết cách giúp sếp thăng tiến, thành công của họ cũng là thành công của bạn.
Có tầm nhìn riêng, tầm nhìn không phải là điều được giao phó mà là một cuộc trò chuyện bạn tham gia vào.
Duy trì thái độ tích cực, chú ý đến hình ảnh bạn thể hiện với quản lý.

No Pain, No Gain

Việc bảo vệ người khác khỏi nỗi đau cần thiết cho việc học hỏi là một sai lầm lớn.
Tác giả trở thành quản lý lần đầu khi 26 tuổi và lần đầu tiên phải sa thải một người cũng ở độ tuổi đó.
Tác giả cảm thấy lo âu, hồi hộp và căng thẳng khi thông báo sa thải, trải qua cảm giác xúc động mạnh mẽ.
Kinh nghiệm đau đớn trong việc sa thải giúp tác giả hiểu rõ tầm quan trọng của việc tuyển dụng tốt và quản lý hiệu suất.
Các công ty lớn thường bảo vệ quản lý khỏi nỗi đau qua sự hỗ trợ của HR, làm mất đi tính nhân văn trong tương tác.
Việc “giấu” nỗi đau khiến cho mọi người không học hỏi được cách tuyển dụng và quản lý hiệu suất tốt hơn.
Kỹ sư thường bị tách biệt với tác động của các lỗi mà họ tạo ra, điều này làm giảm trách nhiệm và sự đồng cảm với khách hàng.
Tác giả khuyến khích kỹ sư tương tác với khách hàng để hiểu rõ tác động của lỗi đối với họ, từ đó nâng cao chất lượng sản phẩm.
Những trải nghiệm đau thương kết quả từ thất bại là cần thiết cho việc học hỏi và phát triển.
Người quản lý giỏi có thể sa thải mà không bị xao xuyến quá mức nhờ vào những bài học từ những lần trước.
Để giải quyết vấn đề văn hoá, cần đưa những người liên quan vào trải nghiệm thất bại để tạo ra sự thay đổi.

Episode 3: AI Hottakes

Podcast “Stay SaaSy” bàn về việc áp dụng AI vào các chức năng trong SaaS.
Thảo luận về khả năng Mỹ quốc hữu hóa một mô hình nền tảng AI.
Nhà sản xuất phần mềm độc đáo trong bối cảnh thế giới thiên về pattern matching.
Có khả năng tương lai của SaaS sẽ có 100 lần nhà thiết kế.
Tác động của AI đối với xã hội đang là chủ đề bàn luận.
Podcast cung cấp kiến thức về việc mở rộng các sản phẩm và đội ngũ kỹ thuật SaaS từ giai đoạn khởi đầu đến IPO.
Các tập gần đây bao gồm chủ đề về bồi thường và cách trở thành nhân viên xuất sắc.

You Know What To Do

Người thông minh với bối cảnh rõ ràng thường biết chính xác phải làm gì trong tình huống khó khăn.
Những quyết định điều hành thường hiển nhiên với những người có kinh nghiệm và bối cảnh kinh doanh.
Hầu hết mọi người né tránh các quyết định khó khăn, gây ra đau đớn lớn hơn theo thời gian.
Câu hỏi như “Chúng ta có nên sa thải một giám đốc?” thường đã có câu trả lời rõ ràng nếu bạn cần hỏi.
Nếu tình hình kinh doanh đang xấu, quyết định bán công ty thường là hiển nhiên.
Kiểm tra cảm giác khi nói “chỉ cần” vì đó có thể là dấu hiệu của một lý do ngụy biện.
Đội ngũ cần chú ý tới phản hồi khó khăn từ những nguồn không thuận tiện.
Các giám đốc cấp cao có thể không cung cấp phản hồi thẳng thắn vì sự khó xử.
Dữ liệu có thể dẫn đến sự bảo thủ, khiến nhóm tìm kiếm những sắc thái không tồn tại trong 99% tình huống.
Nhà đầu tư bên ngoài có thể xác nhận ý kiến đã biết và giúp đánh giá mức độ nghiêm trọng.
Cuộc thảo luận với người bạn đáng tin cậy có thể giúp làm rõ quyết định khó khăn.
Người lãnh đạo có trách nhiệm phải đưa ra những quyết định khó khăn vì lợi ích của đội ngũ.

Episode 2: Rapidly Roadmapping

Thảo luận về việc thiết lập lộ trình thực tế.
Cân bằng giữa việc lắng nghe khách hàng và thực hiện tầm nhìn.
Tập trung vào sản phẩm thay vì quy trình.
Lộ trình kỹ thuật dựa trên vấn đề.
Đảm bảo lộ trình có giá trị rõ ràng.
Phân tách giữa lập lộ trình và phân bổ nguồn lực.
Điều chỉnh lộ trình nhằm tránh ảnh hưởng từ cái tôi của lãnh đạo.

You Have Too Many Metrics

Metrics là công cụ mạnh mẽ nhưng cần được sử dụng một cách hiệu quả.
Bất kỳ metric nào cũng phải thúc đẩy hành động nếu nằm ngoài giới hạn mong đợi.
Chi phí thiết lập và duy trì métrics cao, nếu không sử dụng thì sẽ lãng phí công sức.
Thiết lập một metric cần thời gian và công sức, từ thu thập dữ liệu đến giám sát.
Cần xem xét định kỳ các metrics để đảm bảo tính chính xác và phát hiện lỗi.
Nếu không có kỳ vọng rõ ràng về metric, việc xem xét trở nên tốn thời gian và không hiệu quả.
Hành động cần phải được thực hiện nếu các metrics chỉ ra điều gì đó không mong muốn.
Nhiều người có quá nhiều metrics nhưng không hành động dựa trên chúng.
Các PM cần xác định rõ ràng kỳ vọng về metrics và thực hiện xem xét định kỳ.
Một số công ty thực hiện xem xét chi phí hạ tầng thường xuyên nhưng chưa xác định rõ “tốt” và “xấu”.
Đặt ra thỏa thuận làm việc giúp tăng cường hiệu quả và làm rõ khi nào cần hành động.
Vài metrics tốt là tốt hơn nhiều so với nhiều metrics không có giá trị.

Episode 1: Winning From Third Place

Podcast “Stay SaaSy” ra mắt với tập đầu tiên có chủ đề “Winning From Third Place”.
Tập đầu tiên xoay quanh câu hỏi làm thế nào để chiến thắng khi đang ở vị trí thứ ba.
Người nghe được khuyến khích gửi thêm câu hỏi để được phát trong các tập sau.
Mục tiêu của podcast là bàn luận về việc phát triển sản phẩm SaaS và đội ngũ kỹ thuật từ giai đoạn khởi đầu đến IPO.

Naming Software Teams

Việc đặt tên cho team phần mềm có thể gây ra nhiều sai lầm, ảnh hưởng đến hiệu suất làm việc.
Tên team mạnh giúp ngăn chặn việc mở rộng nhiệm vụ không phù hợp.
Tên tốt giúp tổ chức xác định nhanh chóng ai chịu trách nhiệm trả lời câu hỏi.
Tên mơ hồ gây nhầm lẫn và dẫn đến sự không hiệu quả trong giao tiếp.
Tên quá rộng khiến team phải nhận mọi câu hỏi không rõ ràng từ các team khác.
Tên team cần phải rõ ràng và không chồng chéo với tên của team khác.
Thay đổi tên team khi mở rộng nhiệm vụ có thể ngăn chặn việc phát sinh phạm vi không mong muốn.
Nên chọn tên team cụ thể với nhiệm vụ rõ ràng để tránh các cuộc chiến turf giữa các team.

We Tried That

Một luận điểm sai lầm phổ biến là cho rằng điều gì đó không thành công chỉ vì một nỗ lực trước đó thất bại.
Nguyên nhân người ta thường dựa vào thất bại trước đó để định hướng tương lai là: Ego, tiêu cực và thiếu hiểu biết.
Thời gian giữa các lần thử nghiệm có thể thay đổi đáng kể môi trường, khiến một nỗ lực tương tự mang lại kết quả tốt hơn.
Nhiều yếu tố như lãnh đạo mới, quy trình và kiến trúc góp phần vào sự thay đổi đó.
Người ta thường đánh giá thấp đóng góp cá nhân của mình vào những thất bại trước đó.
Sự sở hữu mới cho một dự án có thể thay đổi mọi thứ; một người sở hữu khác có thể tạo ra sự khác biệt.
Cần phải so sánh chính xác giữa thất bại trong quá khứ và dự án mới, vì chúng có thể không giống nhau.
Để mở khóa một cơ hội, tất cả các yếu tố cần thiết phải đồng thời có mặt.
Khi phân tích thất bại, nên tóm tắt các bài học thành những phát biểu cụ thể và rõ ràng.
Ví dụ về bài học cụ thể: Thay đổi đội nhóm mà không có sự tài trợ và tham gia của lãnh đạo thường thất bại.
Lập kế hoạch dựa trên những thất bại trước đó có thể dẫn đến thành kiến và thiếu hiểu biết về nguyên nhân thất bại thực sự.
Một số điều phải được thực hiện như một phần của hoạt động kinh doanh, bất chấp các định kiến về sự thất bại.

Your Manager Is Not Your Best Friend

Commiseration giữa quản lý và nhân viên trực tiếp có thể hủy hoại môi trường tổ chức.
Nó tạo ra cảm giác vượt trội và môi trường thiếu tin cậy trong đội ngũ.
Kêu ca không cho phép các nhóm khác cải thiện và thường dẫn đến đánh giá sai về họ.
Quản lý cần duy trì sự đồng cảm có điều kiện và tìm hiểu sự thật về vấn đề.
Hãy đặt câu hỏi để làm rõ tình huống thay vì tham gia vào sự thương hại.
Làm người tạo ra góc nhìn, giúp nhân viên hiểu rằng các yếu tố khác nhau cũng có vai trò của chúng.
Những quản lý giỏi không chỉ lắng nghe mà còn đặt các câu hỏi kích thích tư duy.
Sử dụng ngôn ngữ tích cực để giải thích hành vi của các nhóm khác, xây dựng lòng đồng cảm.
Đảm bảo cuộc trò chuyện tập trung vào sự thật khách quan thay vì chỉ trích.

AI Makes Bad Managers

Mùa đánh giá hiệu suất đem lại cơ hội nhưng cũng là lúc nhiều quản lý tự làm khó bản thân.
Sử dụng AI để viết đánh giá hiệu suất là một hình thức tắt lửa, ngăn cản sự phát triển kỹ năng quản lý.
Đánh giá hiệu suất yêu cầu sự chính xác, đồng cảm và tư duy chiến lược.
Chuyển giao công việc quan trọng cho AI cản trở khả năng phát triển kỹ năng quản lý.
Các quản lý có kinh nghiệm hiểu rằng đánh giá hiệu suất còn giúp trau dồi kỹ năng quản lý.
Công cụ AI nên được sử dụng cho các tác vụ lặp đi lặp lại và những câu trả lời rõ ràng.
Không nên sử dụng AI cho các cuộc họp quan trọng vì đây là cơ hội để hiểu đội ngũ.
AI có thể hỗ trợ trong việc sàng lọc hồ sơ, nhưng việc thuyết phục ứng viên cần phải do con người thực hiện.
Sử dụng AI có thể hữu ích trong việc thiết kế quy trình, nhưng cần cẩn trọng trong việc vận hành.
Đối với phản hồi và quản lý hiệu suất, nên giữ tính nhân văn và thực hành thường xuyên.
Duy trì quy tắc: sử dụng AI cho các công việc dễ đoán, tránh rút lui khỏi các tình huống phức tạp và hành vi con người.

Setting Startup Policies

Vai trò của nhà điều hành tại startup là thiết lập các chính sách để tránh hỗn loạn.
Chính sách ảnh hưởng đến mọi người nên phải có chất lượng cao và dễ hiểu.
Nếu chính sách quá hào phóng, sẽ dẫn đến lãng phí; quá khắt khe sẽ khiến nhân viên tránh né công việc.
Chính sách phức tạp gây khó khăn khi thực hiện và yêu cầu nhiều thời gian để giải thích.
Cần xem xét chính sách giống như sản phẩm và thu thập phản hồi từ đội ngũ trước khi công bố.
Tránh tạo ra các ngoại lệ bí mật, vì chúng có thể làm suy giảm lòng tin trong công ty.
Một chính sách nên cho phép giải thích rõ ràng và công khai để tránh cảm giác không công bằng.
Đánh giá chính sách giúp xác định nhân tài trong đội ngũ, đặc biệt là những người có phản hồi tích cực.

Leading From The Front

Lãnh đạo từ phía trước là tham gia vào nơi diễn ra hành động (nơi có sự cố, cuộc gọi từ khách hàng).
Lãnh đạo từ phía trước giúp cải thiện hiệu quả lãnh đạo và tạo động lực cho đội ngũ.
Việc ở tuyến đầu giúp thu thập thông tin quan trọng bằng trải nghiệm thực tế.
Nỗ lực từ một lãnh đạo có thể lây lan, tạo động lực cho cả đội.
Sự hiện diện của lãnh đạo trong những tình huống khó khăn tăng cường cam kết của nhân viên.
Lãnh đạo cần phải có sự nhất quán và dự đoán trong hành động của mình.
Lãnh đạo không nên bị vướng vào các cuộc họp dài hạn mà mất đi cơ hội lãnh đạo từ phía trước.
Nếu không có lãnh đạo ở tuyến đầu, đội ngũ có thể lúng túng khi gặp khó khăn.

The Precise Language Of Good Management

Ngôn ngữ cụ thể của người quản lý ảnh hưởng đến kết quả quản lý.
Nhiều người quản lý thường nói không chính xác do hồi hộp, lười biếng hoặc thiếu kinh nghiệm.
Câu hỏi “Tôi làm việc như thế nào?” thường không được trả lời tốt, mà thay vào đó nên dành thời gian suy nghĩ kỹ càng.
Ngôn ngữ không rõ ràng trong đánh giá hiệu suất làm khó khăn cho việc tiếp nhận phản hồi.
Phản hồi nên cụ thể về hành động thay vì thuộc tính để người nhận dễ dàng xử lý.
Khi được hỏi liệu nhóm có thể thực hiện một nhiệm vụ nào đó, câu trả lời nên cân nhắc các tác động và ưu tiên cụ thể.
Ngôn ngữ cụ thể, như “bền bỉ” thay vì “tốt”, giúp truyền đạt thông tin chính xác hơn.
Việc ghi chép lại là công cụ hữu ích giúp quản lý sử dụng ngôn ngữ cụ thể hơn.
Tránh sử dụng từ ngữ mơ hồ như “sớm” và thay vào đó cung cấp thời gian cụ thể.
Phản hồi cần phản ánh rõ ràng tình hình hiện tại, như thời gian hoàn thành mục tiêu cụ thể.
Các ví dụ cụ thể nên được sử dụng thay vì các từ chung chung để mô tả khả năng hoặc thành tích.

The Pragmatic Engineer

How AWS deals with a major outage

Vào tháng 10, vùng dịch vụ lớn nhất của Amazon Web Services (AWS) đã gặp sự cố kéo dài 15 giờ, gây ảnh hưởng toàn cầu, với nhiều trang web và ứng dụng bị sập hoặc suy giảm hiệu suất, bao gồm Amazon.com và Snapchat.
Sự cố bắt nguồn từ một lỗi trong hệ thống DNS của DynamoDB, sau đó lan sang Amazon EC2 và Network Load Balancer của AWS (theo báo cáo sự cố của AWS).
Có báo cáo rằng sự thiếu hụt nhân tài trong AWS đã góp phần vào sự cố, do một số nhân viên am hiểu hệ thống rời khỏi công ty.
Gavin McCullagh, Kỹ sư Chính của AWS, chia sẻ chi tiết về quá trình phản ứng sự cố từ lúc bắt đầu đến khi kết thúc.
Nhóm Phản ứng Sự cố tại AWS được giao nhiệm vụ theo dõi tất cả 38 vùng dịch vụ và cảnh báo khi có sự cố xảy ra.
Sự cố xảy ra do một vấn đề không mong đợi liên quan đến tranh chấp khóa trong các động cơ DNS.
AWS đã thực hiện hai bước đồng thời để giảm thiểu sự cố của DynamoDB trước khi đối phó với vấn đề của EC2 và Network Load Balancer.
Sau sự cố, AWS thực hiện quy trình đánh giá hoạt động và cải tiến quy trình phản ứng dựa trên những bài học rút ra từ sự cố lớn trước đó vào năm 2023.
AWS cam kết cải thiện cách xử lý các sự cố không ổn định và triển khai các phương pháp chính thức để xác minh các hệ thống như dịch vụ DNS của DynamoDB.
Tất cả kỹ sư ban đầu xây dựng dịch vụ DNS Enactor vẫn đang làm việc tại AWS và đã hỗ trợ giải quyết sự cố kịp thời.

Manager.dev

5 engineering dogmas it’s time to retire

Có 5 thực hành ‘thông thường’ trong kỹ thuật phần mềm cần xem xét lại.
Không nên tự viết lại mã mà có thể sử dụng gói phần mềm có sẵn.
Mỗi PR cần được xem xét bởi từ 2-4 người trong các sprint kéo dài 2-4 tuần.
Mỗi thay đổi mã nên được kiểm soát bằng feature flag.
Nếu cần bình luận mã, điều đó có nghĩa là mã quá phức tạp.
Quá trình xem xét mã bắt buộc có giá trị nhưng có thể làm chậm tiến độ dự án.
Cần lưu ý rằng mã có thể bị ảnh hưởng bởi việc thiếu kiểm tra đối với các gói phần mềm trong các công ty nhỏ.
Linear giúp cải thiện quy trình quản lý dự án với đồng bộ hai chiều, mang lại hiệu quả cao cho các nhóm.
Các nhóm chuyển sang Linear ghi nhận gấp đôi số lượng vấn đề được báo cáo.
Quá trình làm việc theo hình thức Shape Up (vòng 6 tuần) cho phép nhân viên có thời gian tự do làm các dự án cá nhân mà không áp lực.
Việc sử dụng feature flags có thể gây ra sự phức tạp và khó khăn trong mã nguồn của dự án.
Nên cân nhắc tìm kiếm các phương pháp làm việc khác ngoài Scrum/Kanban để phù hợp hơn với đội ngũ và công ty.

Martin Fowler

Fragments: December 16

Gitanjali Venkatraman xuất bản hướng dẫn hình ảnh về Mainframe Modernization, giải thích lịch sử và giá trị của mainframe, cùng những khó khăn trong hiện đại hóa (mới nhất trong chuỗi sách của cô).
Gergely Orosz cho rằng các công cụ code review hiện tại không phù hợp với mã nguồn được sinh ra bởi AI; cần biết prompt và các sửa đổi để cải thiện khả năng giao tiếp và giáo dục (nguồn: Gergely Orosz trên mạng xã hội).
Mục đích của code review không chỉ là kiểm soát chất lượng mà còn là cơ chế giao tiếp và giáo dục cho lập trình viên.
Simon Willison chia sẻ cách sử dụng LLM để xây dựng ứng dụng web nhỏ gọn; ưu tiên sử dụng một tập tin HTML duy nhất và tránh React để đơn giản hóa việc phát triển.
Obie Fernandez nhận thấy các kỹ sư cấp cao hưởng lợi đáng kể từ AI, nhấn mạnh sự quan trọng của việc hiểu biết về tổn thương và trình tự trong phát triển phần mềm.

Writing Fragments

Gần đây, tác giả bắt đầu viết các bài “fragments” ngắn trên trang của mình.
Twitter đã mất đi sự thu hút sau khi Elon Musk mua lại, dẫn đến việc nhiều người dùng rời đi và phân tán sang các nền tảng khác như LinkedIn, Fediverse/Mastodon và Bluesky.
Tác giả không muốn đăng tải micro-post một cách đơn lẻ mà đã bắt đầu gom lại thành các bài fragments.
Tác giả sử dụng các cơ chế rõ ràng hơn cho việc đăng bài và cải thiện cấu trúc URL trên trang.
Các bài fragments hiện có sẵn trong RSS feed, góp phần giữ lại cảm giác của thời kỳ “blogosphere”.
Tác giả là người hâm mộ của RSS và vẫn sử dụng RSS reader hàng ngày để theo dõi các tác giả yêu thích.

CTO Logic

The Hitchhiker’s Guide to Measuring Engineering ROI

VPs Marketing báo cáo tỷ lệ doanh thu 3:1 trên chi tiêu quảng cáo, nhưng trưởng phòng kỹ thuật (CTO) khó xác định ROI rõ ràng cho bộ phận kỹ thuật.
Sự kết nối giữa kỹ thuật và doanh thu thường không rõ ràng do mối quan hệ nguyên nhân-kết quả mập mờ và kết quả chậm phát sinh.
Bộ phận kỹ thuật có vai trò quan trọng trong việc xây dựng và duy trì động cơ doanh thu cốt lõi của công ty.
Việc xác định ROI của kỹ thuật bị thách thức bởi vai trò không minh bạch của bộ phận này trong kết quả kinh doanh.
CTO thường cung cấp DORA metrics, tỷ lệ uptime, và đánh giá trải nghiệm nhà phát triển, nhưng không chuyển hóa thành con số doanh thu cụ thể.
Thiếu dữ liệu ROI rõ ràng khiến CTO gặp khó khăn trong việc biện minh cho chi phí cao của bộ phận kỹ thuật.
Để cải thiện ROI, cần thay đổi tư duy từ CTO, CEO đến các giám đốc khác trong công ty, từ output sang accountability cho kết quả kinh doanh.
Cần đo lường việc sử dụng các tính năng mới và tác động của chúng đến việc thu hút và giữ chân khách hàng.
Kết quả kinh doanh thường xuất hiện qua các chỉ số trễ, vì vậy cần xác định các chỉ số dẫn đầu để đo lường thành công sớm.
Đầu tư vào observability và analytics là cần thiết để tối ưu hóa ROI trong kỹ thuật.
Việc đo lường và theo dõi các chỉ số dẫn đầu mang lại lợi ích về dự đoán và phân tích thành công sớm.

How CTOs Leverage Strategy to Drive Business Outcomes

Mục tiêu cao nhất của công ty là giải quyết các vấn đề như di chuyển, đầu tư, đọc sách, và tìm kiếm bạn đời.
Chiến lược (Strategy) là cách thức mà công ty sẽ đạt được mục tiêu này, thể hiện ai công ty muốn trở thành.
Các mục tiêu kinh doanh cần có cho mỗi quý hoặc năm, ví dụ như chiếm 10% thị trường hoặc đạt doanh thu thường niên 1 triệu USD.
Công ty cần các chiến lược đồng thuận để đạt được các mục tiêu kinh doanh, với các ví dụ như giảm giá thuê bao hay tăng ngân sách quảng cáo.
CTO cần xác định các sáng kiến công nghệ chiến lược để hỗ trợ các chiến lược kinh doanh đã đề ra.
Các sáng kiến có thể bao gồm quản lý số lượng người dùng cao hơn và cải thiện tốc độ tải trang của các trang đích.
CTO cần chịu trách nhiệm trong việc điều hướng công nghệ để đạt được các kết quả kinh doanh.

The True Cost of Custom Features: 3 Painful Taxes

Bạn đã mất tiền cho tính năng xây dựng để hỗ trợ hợp đồng béo bở.
Bạn không tính đúng mức chi phí xây dựng tính năng.
Tính năng đó vẫn gây tốn kém trong mỗi sprint để duy trì.
Phức tạp công việc tăng lên với mỗi tính năng mới, làm tăng chi phí phát triển tính năng tương lai.
Việc đồng ý làm các nỗ lực “Customer Specials” đồng nghĩa với việc từ chối các tính năng có tác động lớn hơn cho doanh nghiệp.
Nên tính phí cao hơn cho các “Customer Specials” hoặc chỉ đồng ý triển khai các tính năng đã được lên kế hoạch trước và vẫn tính phí thêm.
Theo dõi tỷ lệ công sức dành cho các “Customer Specials”.
Thiết lập ngân sách mà không bị áp lực vượt qua.
Đo lường mức độ sử dụng tính năng trong sản phẩm và loại bỏ các tính năng không sử dụng.

The New CTO’s Survival Guide: Rescuing a System at its Breaking Point
The Dangers of Being Indispensable: A CTO’s Rescue Mission

Tom là thành viên không thể thiếu trong nhóm kỹ thuật của công ty, nhưng có tính khí thất thường và thường xuyên xin nghỉ việc.
Khi Tom xin nghỉ, CEO không chấp nhận và cuối cùng thỏa hiệp với một số yêu cầu của Tom.
Dưới sự lãnh đạo của Tom, nhóm chín muồi 40 người nhưng hoạt động kém hiệu quả.
Tom rất tận tâm nhưng không giỏi quản lý, mọi quyết định đều phải qua sự phê duyệt của anh.
CEO quyết định chấm dứt tình trạng này và chấp nhận từ chức của Tom mà không do dự.
Tác giả được giao nhiệm vụ duy trì bộ phận mà không có kiến thức và thông tin từ Tom.
Tác giả nhận ra rằng tình trạng “thừa nhân sự” có thật và tiến hành đánh giá lại đội ngũ dựa trên 5 câu hỏi cụ thể.
Trong tuần đầu tiên, tác giả phát hiện nhiều vấn đề nghiêm trọng như nhóm 5 người làm dự án không có lợi ích thương mại và thiếu sự phối hợp giữa các nhóm.
Sau nhiều tháng, tổ chức đã được tái cấu trúc với các giá trị và hành vi mới, tạo ra môi trường làm việc tốt hơn.
Tác giả hợp tác với nhân viên để tăng cường tinh thần làm việc và cải thiện quản lý các sự cố.
Sau 6 tháng, tổ chức trở nên hiệu quả và bộ phận này hoạt động tốt mà không cần đến tác giả, dẫn đến việc tác giả được thăng chức lên CTO.
Tác giả cảnh báo rằng việc trở thành một người không thể thiếu theo cách của Tom có thể dẫn đến rủi ro và bất lợi.

How a CTO’s Strategic Questions Saved a Startup from Hell

Tôi đã mất một cơ hội tài chính lớn do những câu hỏi thẳng thắn của mình.
Khách hàng là một công ty fintech muốn phát triển phiên bản “white label” tùy chỉnh cho hai đối tác lớn.
Tôi nhận ra khách hàng gặp rắc rối khi không tính tới chi phí bảo trì cho các ứng dụng tùy chỉnh.
Tôi chỉ ra rằng việc duy trì nhiều ứng dụng sẽ làm tăng chi phí phát triển, vì mỗi phiên bản tùy chỉnh cần được điều chỉnh liên tục.
Các đối tác có thể làm chậm quá trình phát triển sản phẩm mới do yêu cầu phê duyệt.
Việc hỗ trợ nhiều phiên bản API cùng lúc sẽ làm phức tạp thêm quá trình phát triển.
Để thành công, công ty cần đảm bảo hợp đồng cho phép điều chỉnh ứng dụng mà không cần sự phê duyệt chậm trễ từ đối tác.
Cuối cùng, các đối tác đã đồng ý sử dụng ứng dụng tiêu chuẩn của công ty.

Agile + Scrum — a convenient fiction

Phát triển phần mềm là sáng tạo và không thể đoán định, với nhiều yếu tố không biết rõ.
Các công ty kiểu chỉ huy (C2) gặp khó khăn với phương pháp Agile do cần kiểm soát “Cái gì?” và “Khi nào?”
Agile phát triển theo các nguyên tắc: Phạm vi không cố định, tiến độ theo từng bước, đội ngũ tự quản cao, khuyến khích thử nghiệm.
Scrum là một khung làm việc giúp các công ty C2 áp dụng Agile một cách dễ dàng hơn, với nhịp độ chặt chẽ và có thể theo dõi các chỉ số.
Scrum tạo vẻ bề ngoài trật tự và được kiểm soát, tuy nhiên, điều này có thể không phản ánh thực tế bên trong.
Người đứng đầu trong C2 cần tạo khoảng đệm giữa quản lý và quy trình sáng tạo trong kỹ thuật.
Nên truyền đạt quy trình ra bên ngoài theo cách cung cấp kết quả mà công ty cần, trong khi nội bộ thì thực hiện theo mô hình Agile.
Cần phải dịch các chỉ thị từ trên xuống thành các cấu trúc Scrum hoặc Agile và ngược lại.
Kỹ năng lãnh đạo và giao tiếp rất quan trọng để đảm bảo mọi người trong và ngoài bộ phận Kỹ thuật đều đồng nhất.
Cần xác định và theo dõi các rủi ro, hành động sớm khi có vấn đề xảy ra.

How I align tech initiatives to business goals

Có 2 yếu tố chính để điều chỉnh các sáng kiến công nghệ theo mục tiêu kinh doanh.
Yếu tố đầu tiên là bắt đầu với mục tiêu kinh doanh cụ thể, ví dụ: “Đạt điểm hòa vốn trong kinh tế đơn vị”.
Điểm hòa vốn đạt được khi Customer Acquisition Cost (CAC) <= Customer Lifetime Value (LTV).
Có thể giảm CAC xuống 20% hoặc tăng LTV lên 20% để hỗ trợ mục tiêu.
Yếu tố thứ hai là không vội vàng chuyển sang công nghệ, mà nên ở lại với khía cạnh kinh doanh một thời gian.
Đưa ra các chỉ số dẫn đầu, như Bounce Rate và Registration Rate, có thể ảnh hưởng đến CAC.
Tỷ lệ thoát (Bounce Rate) phải giảm để mở rộng “đầu ống” và tăng cơ hội chuyển đổi.
Tỷ lệ đăng ký (Registration Rate) cần tăng để thu hút nhiều người dùng hơn.
Tỷ lệ kích hoạt (Activation Rate) và thời gian kích hoạt (Time to Activation) là chỉ số quan trọng khi người dùng thực hiện các hành động có ý nghĩa.
Tỷ lệ đăng ký trả phí (Subscription Rate) cần tăng để giảm CAC.
Các sáng kiến công nghệ cần triển khai bao gồm: công cụ phân tích, cải thiện các trang vào, và tính năng giới thiệu bạn bè.
Hiểu rõ sản phẩm là điều quan trọng đối với CTO để hỗ trợ quy trình này.

5 revealing questions for startup CEOs to assess their CTOs

Năm câu hỏi phi kỹ thuật là công cụ thử nghiệm cho CEOs để đánh giá CTO.
Câu hỏi đầu tiên liên quan đến sự đồng nhất giữa CTO và mục tiêu kinh doanh.
CTO cần có khả năng giải thích chiến lược công nghệ và cách nó hỗ trợ mục tiêu dài hạn của doanh nghiệp.
Câu hỏi thứ hai về khả năng của CTO trong việc cầu nối giữa các đội ngũ kỹ thuật và phi kỹ thuật.
CTO phải hiểu yêu cầu kinh doanh và truyền đạt khái niệm kỹ thuật một cách dễ hiểu cho các bên liên quan không chuyên.
Câu hỏi thứ ba tìm hiểu về công nghệ hiện tại mà doanh nghiệp đang sử dụng và lý do chọn lựa.
Việc chọn technology stack tác động lớn đến doanh nghiệp và cần có sự tham gia của CEO.
Câu hỏi thứ tư đề cập đến dự án mà đội ngũ kỹ thuật đang thực hiện.
CEOs cần biết rõ nội dung công việc của bộ phận kỹ thuật để có thể có các câu trả lời đầy đủ.
Câu hỏi thứ năm liên quan đến cách đo lường hiệu suất của bộ phận kỹ thuật.
Nhiều CEOs không biết cách đánh giá hiệu suất này, cần có những chỉ số đúng đắn từ CTO.
Các chỉ số hiệu suất nên được báo cáo thường xuyên và cần có kiểm soát về thời gian phát triển và tỷ lệ lỗi.

Web Apps are Native Apps

CEO yêu cầu một ứng dụng di động gốc nhưng có sự hiểu nhầm giữa CEO và kỹ sư phần mềm.
CEO muốn có một ứng dụng có thể tải về, có thể khởi chạy từ màn hình chính, không phải chỉ qua trình duyệt web.
Ứng dụng mong muốn cần tính năng đăng nhập bằng sinh trắc học và thông báo đẩy, thường có trên App Store và Play Store.
Kỹ sư phần mềm hiểu “native” là ứng dụng tích hợp chặt chẽ với hệ điều hành hoặc phần cứng cụ thể.
Ứng dụng web-native có thể đáp ứng nhu cầu mà không cần phải là “native” theo nghĩa kỹ thuật chặt chẽ.
80% trường hợp, công nghệ web phù hợp cho nhu cầu doanh nghiệp hơn so với ứng dụng gốc truyền thống.
Sử dụng công nghệ web cho phép phát triển và duy trì duy nhất một mã nguồn cho tất cả các nền tảng.
Progressive Web App (PWA) cho phép tạo biểu tượng trên màn hình chính giống như ứng dụng khác, nhưng không cần trình duyệt.
PWAs nhẹ hơn và có thể cập nhật nhanh chóng hơn ứng dụng gốc truyền thống.
Steve Jobs từng ủng hộ PWAs vì khả năng tích hợp và dễ dàng cập nhật.

CTO Logic is booting up …

CTO Logic là bản tin cung cấp cái nhìn về tư duy của một CTO phần mềm.
Nội dung tập trung vào giao tiếp giữa kỹ thuật, quản lý công nghệ, lãnh đạo và kinh doanh.
Độc giả nhận được mẹo thực tế, không dùng thuật ngữ phức tạp và dựa trên kinh nghiệm.
Cung cấp góc nhìn từ cả hai phía kỹ thuật và kinh doanh.
Tổng hợp các bài viết phổ biến từ LinkedIn và các nguồn khác.
Sẽ có bài viết thông tin cho cả hai bên về các chủ đề như GitHub, JIRA, Agile.
Dự kiến có lời khuyên cho CTO và các lãnh đạo kỹ thuật cũng như CEO về cách làm việc hiệu quả với tổ chức kỹ thuật.

5 best practices to survive going viral

Việc chuẩn bị cho các cuộc tấn công DDoS quan trọng hơn việc chỉ tập trung vào khả năng mở rộng (scalability).
Cuộc tấn công DDoS có thể gây tê liệt hạ tầng, dẫn đến tổn thất tài chính và cơ hội (chưa có tài liệu cụ thể).
Cần sử dụng Content Delivery Network (CDN) cho hình ảnh và script thay vì phục vụ từ máy chủ backend (ví dụ: Amazon CloudFront, Cloudflare).
Tinh chỉnh HTTP headers để cải thiện khả năng cache cho người dùng.
Có thể tạo trang HTML tĩnh từ trang động bằng cách phát sinh các thành phần động ở phía client.
Sử dụng địa chỉ nội bộ khi các dịch vụ backend gọi lẫn nhau, để cải thiện tính bảo mật và hiệu suất.
Tránh để tất cả yêu cầu truy cập qua một tuyến đường chung không có khả năng chống chịu, tránh điểm đơn lẻ thất bại.
Đảm bảo rằng các thông báo như xác nhận thanh toán từ bên thứ ba không bị ảnh hưởng bởi lưu lượng truy cập cao.
Duy trì danh sách trắng (whitelist) kiểm soát bên nào có thể kích hoạt webhooks của bạn.
Chú ý đến các tính năng bảo mật như “I’m Under Attack Mode,” caching, và rate limiting từ Web Application Firewall.

How much uptime can I afford?

Đối với các startup, 99.5% uptime thường hiệu quả hơn 99.99% về chi phí.
Uptime 99.99% yêu cầu hệ thống có độ tin cậy gấp 50 lần so với 99.5%.
Chi phí để đảm bảo uptime 99.99% cao hơn nhiều so với 99.5%, bao gồm hệ thống phức tạp và nhu cầu nhân sự nhiều hơn.
Quyết định về uptime là quyết định kinh doanh, không chỉ kỹ thuật; cần xem xét tác động của thời gian chết đến doanh thu.
Các vấn đề về downtime thường xuất phát từ hoạt động hơn là kỹ thuật.
Các điểm thất bại có thể không chỉ kỹ thuật mà còn là quản lý, như thẻ tín dụng bị vượt mức.
Cần có kế hoạch liên phòng ban để ngăn ngừa downtime không mong muốn do sự cố quản lý.
Dịch vụ như Amazon Web Services (AWS) có SLA cho EC2 là 99.5% cho mỗi máy chủ đơn lẻ.
Khả năng cao hơn có thể đạt được bằng cách chạy máy chủ trong các “availability zones” độc lập.
Thời gian chết tính cộng dồn giữa các dịch vụ trên AWS; ngay cả khi nhiều dịch vụ có SLA 99.99%, uptime chung sẽ thấp hơn.

Agile software development — 5 essential facts for startup CEOs

Agile giúp giảm độ rủi ro trong phát triển phần mềm bằng cách phát triển các phần nhỏ và lấy phản hồi từ người dùng (Iterative, cyclical process).
Không phải lúc nào cũng có thể hiểu rõ cách người dùng sẽ sử dụng sản phẩm (Real users are weird and unpredictable).
Agile cho phép thay đổi yêu cầu dựa trên phản hồi thực tế từ người dùng (Requirements will change — embrace this).
Cần giao quyền quyết định cao cho quản lý sản phẩm và kỹ sư để thúc đẩy sự tự chủ (Autonomy & Trust).
Agile ưu tiên cá nhân và tương tác hơn quy trình và công cụ (Individuals and interactions over processes and tools).
Phát triển phần mềm cần sự hợp tác trực tiếp giữa lập trình viên và các bên liên quan (Collaboration).
Đo lường tiến độ chủ yếu bằng phần mềm hoạt động (Progress is measured by working software).
Agile có nguyên tắc ‘tối giản’, tối đa hóa công việc không cần làm (Maximise the work you decide not to do).

Escape the Feature Factory trap using Business Impact Categories & Budgets

Doanh nghiệp hoạt động như một “feature factory”, tối ưu hóa cho sản lượng chứ không phải cho kết quả kinh doanh.
Các tính năng phần mềm không đồng nhất và có giá trị kinh doanh khác nhau.
Nhiều tính năng không cải thiện được chỉ số kinh doanh.
Cần tối ưu hóa quy trình để tối đa hóa giá trị kinh doanh, không chỉ hoàn thành yêu cầu.
Tạo ra các chỉ số cốt lõi để liên kết công việc với các chỉ số kinh doanh chính của công ty.
Lập kế hoạch dựa trên kết quả kinh doanh thay vì danh sách chi tiết các tính năng.
Đặt ngân sách cho các loại công việc khác nhau để quản lý nguồn lực hiệu quả hơn.
Đo lường năng suất dựa trên tác động kinh doanh hơn là sản lượng đơn thuần.
Theo dõi chi phí phát triển các “Customer Specials” để quản lý hiệu quả hơn.
Tạo ra các danh mục tác động kinh doanh để phân loại công việc: Basics, Incrementals, Differentiators, Speculative Bets, Technological Foundation.

Does your Company have a Think-first Culture?

Viết lách là một phần quan trọng trong văn hóa công ty giúp tăng cường hiệu quả làm việc.
Các lợi ích bao gồm giảm số lượng cuộc họp, giảm sự gián đoạn, tăng năng suất, và ra quyết định chất lượng cao.
Viết rõ ràng và có tổ chức giúp mọi người hiểu thông tin đồng nhất và giảm thiểu những câu hỏi phát sinh.
Tổ chức “viết trước” không có nghĩa là viết duy nhất; mà là đầu tư vào việc sử dụng từ ngữ.
Các cuộc họp có chương trình và mục tiêu rõ ràng, tránh những cập nhật trạng thái không cần thiết.
Quy trình làm việc được tài liệu hóa giúp mọi thông tin có thể tìm kiếm và khám phá dễ dàng.
Nhân viên độc lập và tự chủ hơn nhờ tài liệu rõ ràng và đầy đủ, góp phần phân bổ kiến thức trong tổ chức.
Cân nhắc cách viết email hay tài liệu để người đọc có thể hiểu rõ mục đích, câu hỏi và thông điệp chính.
Sử dụng hệ thống quản lý tri thức chung giúp cải thiện công tác thông tin và tiếp cận dễ dàng hơn với nhân viên mới.
Kiểm tra kỹ năng viết của ứng viên trong quy trình tuyển dụng để đảm bảo khả năng giao tiếp hiệu quả.

85% of New Features FAIL & Feature Cost Inflation

85% số tính năng mới thất bại ngay cả ở những công ty tốt nhất.
Mỗi tính năng mới thêm vào sản phẩm làm tăng chi phí cho các tính năng tiếp theo.
Chi phí phát triển phần mềm gồm: chi phí trực tiếp (người x thời gian x lương) và chi phí cơ hội.
Có một loại chi phí ẩn gọi là chi phí phức tạp, không phải là nợ kỹ thuật.
Sự phức tạp gia tăng làm cho việc thay đổi càng trở nên tốn kém hơn.
Chi phí vận hành và hỗ trợ sản phẩm phức tạp cũng cao hơn.
Cần xác định giá trị kinh doanh của mỗi tính năng mới.
Nếu tính năng thử nghiệm không mang lại kết quả, cần loại bỏ nó.
Cần xây dựng văn hóa thử nghiệm, đo lường và loại bỏ các tính năng không có giá trị.
Quy trình thử nghiệm bao gồm hai giai đoạn: Giai đoạn 1 là Thử nghiệm và Giai đoạn 2 là Dọn dẹp.
Trong giai đoạn dọn dẹp, nếu thất bại cần loại bỏ tính năng, nếu thành công cần trả nợ kỹ thuật để kiểm soát chi phí.

Technical Debt = Duct Tape + Rust

Technical Debt là khái niệm trong kỹ thuật phần mềm, đo lường các yếu tố “dán tạm” và “gỉ sét” của hệ thống.
“Duct tape” đại diện cho các giải pháp tạm thời do áp lực sản xuất nhanh và các sửa chữa nhanh cần thiết.
“Rust” chỉ sự suy giảm tự nhiên của hệ thống khi điều kiện kinh doanh và giả định thay đổi theo thời gian.
Hệ thống tích lũy Technical Debt ngay từ khi ra đời và có thể dẫn đến mất năng suất và doanh thu.
Nếu để Technical Debt không kiểm soát, có thể xảy ra hiện tượng nhân viên nghỉ việc và thậm chí là phá sản.
Cần dọn dẹp sau khi thử nghiệm các tính năng mới, thay thế giải pháp tạm thời bằng các giải pháp kỹ thuật đúng đắn.
Nên phân bổ một tỷ lệ phần trăm cố định trong mỗi giai đoạn lập kế hoạch để thanh toán Technical Debt (thường bắt đầu từ 25%).
Theo dõi Technical Debt qua hệ thống quản lý vấn đề như Jira hoặc Linear, và xác định các khu vực có nhiều sửa chữa thường xuyên.

Just Throw it Over the Wall

Việc chuyển giao công việc giữa các đội cần có sự hợp tác chặt chẽ, không phải hình thức chuyển giao kiểu waterfall (nguyên tắc nướcfall).
Sự thiếu hợp tác thường dẫn đến việc sản phẩm và yêu cầu chưa hoàn chỉnh khi đến tay kỹ sư.
Yêu cầu nên được chuẩn bị từ sớm và trong quá trình làm việc có sự tham gia của kỹ sư.
Không nên để yêu cầu chuyển giao tạo bất ngờ cho kỹ sư.
Sử dụng tài liệu Brief để thông báo và nhận phản hồi về yêu cầu trước khi phát triển.
Brief nên có cấu trúc tối giản bao gồm: Bối cảnh, Vấn đề, Giải pháp đề xuất.
Quá trình này cần được duy trì qua các vòng thảo luận và sửa đổi để đạt được giải pháp tốt nhất.

Why do features take so long to ship?

Vấn đề chậm trễ trong việc phát hành tính năng thường do nhiều nguyên nhân kết hợp.
Dữ liệu từ hệ thống ticketing (ví dụ: Jira) hữu ích để phát hiện các mẫu hành vi lặp lại của tổ chức.
Các chỉ số thường gặp bao gồm: Bumped Stories, Writer’s Block, Stowaways, và Overweight Baggage.
Bumped Stories được chia thành ba loại chính: Cliff Hangers, Unfinished Masterpieces, và những câu chuyện đang chờ xử lý.
Nguyên nhân chủ yếu gây ra các vấn đề bao gồm: Overbooking, Stowaways, quy trình không được tôn trọng bởi quản lý, yêu cầu chưa chuẩn bị sẵn sàng, nợ kỹ thuật, và ưu tiên không đồng nhất.
Overbooking xảy ra khi có quá nhiều câu chuyện được lên kế hoạch cho sprint do khả năng thông lượng không chính xác.
Stowaways là các sự cố hỗ trợ hoặc công việc “khẩn cấp” vào phút cuối làm xáo trộn kế hoạch đã có.
Quy trình lập kế hoạch và thực hiện không được truyền đạt rõ ràng đến quản lý cấp cao có thể dẫn đến tiếng ồn trong quy trình.
Nợ kỹ thuật gia tăng khó khăn trong việc thực hiện nhiệm vụ kỹ thuật vì thiếu kế hoạch quản lý.
Đánh giá công sức không chính xác có thể do phân tích của kỹ sư chưa đủ sâu hoặc áp lực từ bên ngoài.

daily-digest

Simon Willison’s Weblog

Stay SaaSy

The Pragmatic Engineer

Manager.dev

Martin Fowler

CTO Logic

Open Source Projects - Latest Discoveries

Hacker News: Best

DEV Community