Hỏi chứ anh làm mảng gì đấy
cái bạn nói là đặc thù cty bạn. cty tôi khác. và cách điều phối resource và lên plan của tôi khác. có những lúc ko làm theo scrum ko tính sprint. đẩy thêm người OT buổi tối t7 cn. tất cả để đẩy nhanh nhất có thể.
Cụ thể hơn, có quy luật là law of diminishing returnsTrong điều kiện lý tưởng thì workload có thể chia nhỏ để xử lý parallel nhưng mà thực tế thì không bao giờ đạt được parallel hoàn hảo chỉ có thể concurrent thôi. Luôn có những thứ phải serial và switch context, hồi xưa học môn hệ điều hành thầy bảo vậy
Tùy trường hợp thôi chứ
đã biết chi tiết đâu mà
muốn biết ai google như nào thì xem con bot youtube là biết dm để bọn net nó đập gậy tùm lum cuối cùng phải chấp nhận trả tiền bảo kê
lai so nướng bánh vs phụ nữ sinh con. bó tay. 1 cái cần thời gian. 1 cái làm càng nhanh xong càng sớmTùy trường hợp thôi chứ
đẩy nhanh cũng chỉ tới 1 mức nào đó thôi, task nướng bánh tốn 10 phút thì 100 thằng cùng làm cũng phải tốn 10 phút bánh mới nướng xong chứ
Ông tào lao
Tôi lại nghĩ phía anh làm integration cho service đã có sẵn ấy, vì Product nó đặc thù ở chỗ là progress nó ko flexible, chưa kể permission để access các resource cũng cực kỳ gắt, rồi lại có xung đột văn hoá giữa các team nữa. Riêng thằng gg này turn từ R&D ra Production lại là câu chuyện khác khó hơn nữa.
A nói đúng với các trường hợp bình thường của cty.
Đó là câu chuyện mà tôi thường thấy khi có team cố gắng kéo thêm người là thế nàyÔng tào lao
1 Story chia nhỏ từng task, coi như 1 task nó có thể chia nhỏ ra nhiều subtask đi nhé, cho nó dễ
Ông nghĩ 10 người làm 1 subtask nó nhanh hơn 1 người hả
xong project anh A cũng phải quay lại refactor cho đúng style của anh A.
Tăng người trong cùng 1 dự án thì chỉ tăng hiệu quả đến mức nào đó thôi. Không lẽ 1 function mà chia ra mỗi đứa viết 1 dòng? Vậy còn lâu hơn. Nên nói tăng người k tăng hiệu quả thì không đúng, nhưng chỉ tăng đến hữu hạn chứ không là vô hạn.
Đó là câu chuyện mà tôi thường thấy khi có team cố gắng kéo thêm người là thế này
Anh A phụ trách 1 story dự kiến 3 ngày, anh A kéo 2 người vào phụ task, xong anh A phải meeting giải thích story, rồi cấp quyền, rồi PR, review code, sau đó anh A còn phải trả lời lý do phải làm như này như kia, anh A mất tg để comment kêu 2 bạn kia resolve, xong anh A mất thêm tg để fix bug sau khi merge đell hiểu sao code cũ chạy ko đúng
Nhìn ông đấy review code còn mệt hơn ổng tự làm
bên mình làm từ đầu tới cuối luôn bạn. từ lúc meeting vs designer đưa ra plan phù hợp tới lúc golive.
Ko thể một tháng có 9 đứa trẽ bằng cách làm 9 phụ nữ có bầu
Ai từng là dev thì sẽ hiểu nỗi khổ nàyNghe giống câu chuyện tầm hơn chục năm trở của tôi quá
Hồi đấy mới ra trường, lead team lúc đó chia việc cho t, lúc t làm xong ông review code, xong tá hỏa kêu fix vì code tiềm ẩn bug
Kể case study chi tiết đi fence, dự án gì như nào, techstack, teamsize. Task tăng productivity là task gì.
https://en.m.wikipedia.org/wiki/Brooks's_law
dự án hơi nhạy cảm nên ko nói được. tech thì vue nuxt, nodejs. xong hết dự án trong 2 tuần golive tính từ lúc chốt design. vd đơn giản. cắt 1 page html từ design mất 2 ngày 1 dev thì h x2 lên mất 1 ngày hoặc 1.5 ngày
Nói chuyện kiểu huề vốn, đặc thù công ty anh khác thế chắc anh làm ở Google à mà biết cách của anh sẽ hiệu quả với Google?
