Đi tới nội dung chính
Docksoft
English, Tiếng Việt

Cách làm việc

Làm rõ, thử sớm, xây dựng, ra mắt, cải thiện.

Quy trình cần sơ đồ để giải thích thì khó làm đều. Của chúng tôi gói trong một dòng. Mỗi bước có một quy tắc — quy tắc đó giải quyết tranh cãi khi lịch gấp.

Quy trình

Năm bước. Thứ tự quan trọng hơn tên — nhiều dự án thất bại vì bỏ qua bước thứ hai.

  1. 01

    Làm rõ

    Thu gọn yêu cầu đến khi mô tả được bằng một câu.

    Nhiều dự án thất bại vì phạm vi, không phải vì kỹ thuật. Trước khi thiết kế, chúng tôi cần một câu: ai gặp vấn đề, vấn đề tốn gì, và làm sao biết đã giải quyết. Câu có 'và' thường là hai dự án. Giai đoạn kết thúc khi câu đó chịu được cách đọc khắt khe.

    Kết quả của bước này

    • Một câu mô tả vấn đề
    • Quyết định hoặc tác vụ phần mềm phải cải thiện
    • Những gì cố ý không build
  2. 02

    Thử sớm

    Làm phần khó, phần còn nhiều câu hỏi trước — không bắt đầu từ phần dễ.

    Dễ bị cuốn vào màn hình đăng ký, cài đặt, landing — việc dễ vì không chứa rủi ro. Chúng tôi bắt đầu ở chỗ dễ sai nhất: tích hợp chưa ai đọc kỹ tài liệu, model chưa chứng minh độ chính xác, quy trình chưa ai quan sát người thật. Biết sớm là giá trị của giai đoạn này.

    Kết quả của bước này

    • Một lát cắt chạy được của phần khó nhất
    • Danh sách những gì giờ đã biết mà trước đó chưa
    • Ước lượng cập nhật, hoặc khuyến nghị không triển khai
  3. 03

    Xây dựng

    Type end-to-end, test theo hậu quả, quan sát được trước khi scale.

    Type từ database đến giao diện để đổi shape làm vỡ build thay vì làm hỏng buổi chiều của user. Test tập trung nơi lỗi tốn tiền, lộ dữ liệu hoặc không undo được. Log, error tracking và metric quan trọng gắn từ deploy đầu — gắn sau khi đã tải là dự án khác và tệ hơn.

    Kết quả của bước này

    • Type an toàn xuyên server và client
    • Test tập trung nơi lỗi đắt
    • Error tracking và log có cấu trúc từ deploy đầu
    • Màn admin cho đội vận hành
  4. 04

    Ra mắt

    Release thật, cadence cố định, cho user thật.

    Ngày release trượt dần dạy team rằng ngày không quan trọng. Chúng tôi giữ cadence và dời scope, buộc ưu tiên sớm và công khai. Mỗi release có flag hoặc rollout phù hợp rủi ro — và là thứ user có thể nhận ra.

    Kết quả của bước này

    • Nhịp release dự đoán được
    • Rollout từng bước và cách rollback đã tập
    • Release note viết cho user, không chỉ changelog
  5. 05

    Cải thiện

    Đo trước, đơn giản hóa sau. Release tốt thường bớt thứ gì đó.

    Sau launch, câu hỏi chuyển từ thêm gì sang cái gì không ai dùng. Tính năng chết là thuế trên mọi thay đổi sau. Chúng tôi đối chiếu dữ liệu với câu vấn đề ban đầu, xác nhận phần thật sự chết, và gỡ bỏ. Sản phẩm giữ chất thường cố ý giữ gọn.

    Kết quả của bước này

    • Dữ liệu sử dụng so với câu vấn đề gốc
    • Danh sách ứng viên để gỡ
    • Câu mô tả tiếp theo

Tiêu chuẩn kỹ thuật

Cam kết giữ vững, bất kể loại dự án.

Không thương lượng theo từng hợp đồng. Đó là lý do ước lượng trông như thế nào — và vì sao năm thứ hai của codebase không đột biến đắt hơn năm đầu.

Type an toàn end-to-end

Type xuyên mọi ranh giới — database, server, client. Compiler là reviewer đầu tiên; đổi shape nên vỡ build thay vì thành ticket support.

Test theo hậu quả

Phần trăm coverage có thể tăng mà không an toàn hơn. Test nặng nơi lỗi tốn tiền, lộ dữ liệu hoặc không hoàn tác; nhẹ nơi chỉ cần reload.

Quan sát được trước scale

Log có cấu trúc, error tracking và vài metric sức khỏe từ deploy đầu. Gắn sau khi hệ thống đã tải là cuộc cứu hộ.

Accessibility là tiêu chí hoàn thành

Bàn phím, thứ tự focus, contrast và nhãn là done — không phải audit sau launch tạo backlog không ai lên lịch.

Ngân sách hiệu năng rõ ràng

Trọng lượng trang và độ trễ tương tác thống nhất trước và kiểm trong CI. Giữ liên tục thì bền; sửa trong một sprint thường trượt lại.

Tài liệu sống sót khi team đổi

Quyết định kiến trúc được ghi kèm lý do — câu đắt sau này thường là vì sao, không phải code làm gì.

Hình thức hợp tác

Ba hình thức, tùy giai đoạn bạn đang ở.

Phần lớn dự án bắt đầu từ hình thức đầu, kể cả khi sau này chuyển sang hình thức thứ ba. Chúng tôi muốn chắc về vấn đề trước khi cả hai cam kết build.

Bắt đầu trao đổi

Discovery sprint

Phạm vi và phí cố định

Engagement ngắn, kết thúc bằng khuyến nghị bằng văn bản: câu vấn đề, phần rủi ro, hướng kỹ thuật và ước lượng trung thực. Đôi khi khuyến nghị là không build — kết quả đó vẫn đáng phí.

Phù hợp khi: Bạn có vấn đề và nhiều ý kiến về giải pháp.

Build partnership

Theo milestone

Thiết kế và build cùng bạn theo cadence release ở trên. Bạn nhận code, hạ tầng và tài liệu suốt quá trình — không chỉ ở handover cuối.

Phù hợp khi: Bạn biết cần build gì và cần đội hoàn thiện.

Product ownership

Dài hạn

Chúng tôi build và vận hành: release, monitoring, công cụ support và roadmap. Cách chúng tôi chạy sản phẩm riêng, áp dụng cho sản phẩm của bạn.

Phù hợp khi: Bạn cần sản phẩm tồn tại và chạy ổn, không muốn tự dựng team.

Discovery

Dự án tốt thường bắt đầu từ một câu hỏi khó.

Gửi vấn đề thay vì spec. Nếu discovery sprint là bước tiếp theo hợp lý, chúng tôi sẽ nói — và nếu nghĩ bạn không nên build, chúng tôi cũng nói thẳng.

Gửi email cho chúng tôi

Một địa chỉ email — tin nhắn đến trực tiếp người sẽ làm dự án. Không qua form hay lịch hẹn tự động.

tphamdn@gmail.com
Lý do liên hệ khácPhản hồi trong hai ngày làm việc