namcungkiem
Senior Member
Cái nay thô nhưng đúng. Cơ mà nếu ae nào đi BID project sẽ hay thấy trường hợp. Vô khách nó hỏi giá trước xong sau đó...ko có sau đó. Meeting end trong 10'
))
thảo luận Cuộc tranh luận nảy lửa về #NoEstimate và thực tế lead dự án
- Thread starter hoctrokha
- Start date
))
Quốc Vương Namekian
Senior Member
30 % risk lắm phen. thường là 50% hoặc X2 qua mồm sếp nó sẽ x1.5 đến 3 lần nữa
Kinh nghiệm, dự án dev làm 1 tháng, sự thực làm 3 tuần, sếp bảo với đối tác, dự tính 3 tháng
Hideto Takahashi
Senior Member
Ở những tập đoàn lớn thì mình không thay đổi cuộc chơi này được. Est vẫn phải làm dù nó có value hay không :stick:
tunghm
Senior Member
Thím @hoctrokha tham khảo ở đây nhé . Video đã giải thích khá chi tiết và phân tích kỹ càng cho trường hợp của thím ấy
Có hai kiểu là thuê headcount thì giống thế này, và thuê khoán app/features, thread cố tình cắm headcount hiểu theo thuê khoán thôi, 1 dạng mix chứ không có gì mới, cứ bảo khách chơi headcount thôi, tranh cãi làm gì, còn vẽ pải hay gì không đúng mindsets khách thì cũng toạch, nó thuê tháng thì nó quyết vụ perform sao cho ổn, mình chỉ tư vấn thôi, éo tin thì chơi phương án b c d...
Lucianz
Senior Member
30% thôi à, tôi cứ 300% cho chắc. Mẹ, khổ nhất là lên plan xong chính bên mình lại làm vỡ plan như tự dưng thiếu nguồn lực: BA/Dev nghỉ, các dự án cũ bàn giao chưa xong lại lòi ra requirement mới, stage mới, v.v
Lucianz
Senior Member
Cái nay thô nhưng đúng. Cơ mà nếu ae nào đi BID project sẽ hay thấy trường hợp. Vô khách nó hỏi giá trước xong sau đó...ko có sau đó. Meeting end trong 10'
Khách cần phải nhanh, đẹp, ít bug và rẻ nữa nhé
Lucianz
Senior Member
Nhất cự li nhì tốc độ.
Không cần ngồi chung nhưng nên chia theo dạng Junior-Senior or Junior-Middle vừa kèm vừa làm, ông lead cũng chắc tay hơn mà mấy ông le ve ở dưới cũng nhanh lên trình.
Sau này theo team như vậy chia đầu Function nhanh gọn lẹ vì mấy ông thần làm với nhau có cách lviec riêng rồi, không cần phải micro-managment nữa.
hoctrokha
Member
Chào mọi người, bài này sau khi đăng phần 1, mình thấy các bạn còn quá nhiều lăn tăn. Nguyên nhân chủ yếu mình thấy do các bạn chưa thử và chính bản thân mình vào thời điểm đó cũng chưa có nhiều ví dụ để minh hoạ cho mọi người. Lấy 1 ví dụ ra thì không khách quan lắm. Bởi vậy mình lùi phần này lại nửa năm, thử trên vài dự án nữa để cho thuyết phục. Nhưng cơ bản quan điểm của mình vẫn vậy thôi, không thay đổi gì cả.
Mình sẽ đi qua từng case cụ thể và sẽ dẫn dắt các bạn theo một góc nhìn khác.
Case 1: Một công ty product startup lớn quy mô 2-3 trăm dev
Công ty này trước đây rất chú trọng vào con số cá nhân, ví dụ như số lượng ticket done, thời gian hoàn thành ... các team vẫn estimate, có milestone các thứ. Mỗi khi làm xong 1 tính năng là PO đem đi khoe, mọi người xúm vào khen các kiểu ... nhưng rất nhiều lần mình nhìn thấy các tính năng bị bóp lại để kịp release, thành thử nó không đem lại value gì nhiều cho end user cả.
Điểm chết người nữa khi công ty đặt KPI/metric mục tiêu là:
- Revenue, không phải value đem lại cho người dùng. Điều đó dẫn đến toàn bộ công ty nhìn user như những con hàng, những con cá phải câu bằng được. Họ không nhìn user là những người mình làm sản phẩm ra để giúp đỡ, họ quên cả core value lẫn mission ... Phần lớn các tính năng đem ra chỉ để khuyến khích người dùng làm một việc X gì đó đem lại revenue cho công ty ...
- Milestone, và tất nhiên không phải value. Khi bạn có một cái milestone, slideshow trên màn hình meeting của C-level thì lẽ đương nhiên cả công ty sẽ phải chạy theo nó. Kể cả có phải bóp cho feature méo mó cỡ nào thì cũng phải lọt qua được cái deadline.
Không có gì ngạc nhiên khi công ty tự lao dốc không phanh cho dù chỉ mới là startup.
Giờ thử nghĩ: Estimate có khiến công ty thành công hơn không?
Mình không nói là nên bỏ estimate nhé, mình chỉ đang hỏi Estimate có khiến công ty thành công hơn không?
Với mình, estimate giúp feature ra đúng hạn hơn và ... hết. Vâng, chỉ vậy thôi. Feature ra đúng hạn không có nghĩa công ty thành công. Value của nó mới là thứ khiến công ty thành công.
Còn mặt hại của nó thì chắc mình không cần nói thêm nữa.
Hiện tại công ty đã bớt quan tâm đến storypoint và quan tâm nhiều hơn đến số lượng ticket, một bước đi hợp lý nhưng vẫn còn đặt khá nặng revenue.
Case 2: Một công ty startup 20 dev
Startup này có anh Founder rất rất chú trọng vào độ hoàn thiện của sản phẩm, anh ý muốn từng chi tiết được hoàn thiện, trải nghiệm người dùng phải được chỉnh chu trước khi release. Do tiềm lực có hạn, số lượng dev không nhiều nên anh ý muốn lập plan thật chặt để có được ngày public release. Đại khái là công ty quan tâm đến value của sản phẩm, nhưng cũng rất cần nó release sớm để gọi vốn.
Khi mình join vào thì dự án đã bị trễ gần 6 tháng rồi và deadline đã bị dời đi 3-4 lần gì đó (milestone này do techlead estimate). Cùng lúc đó anh Founder thuê 2 bạn PM scrum master hoành tráng về để làm giúp anh ý. Hai bạn này lập plan các kiểu, bắt dev estimate từng task theo giờ rồi sau đó cộng lại ra ngày release. Dev kêu trời, mình vào nói làm vậy không được đâu, sao mà estimate theo giờ được.
Cả team dev đồng ý, 2 bạn PM đổi qua bắt estimate theo ngày, mình bảo: "ko đc đâu, sản phẩm có thể sẽ thay đổi rất nhiều trong quá trình phát triển, estimate kiểu gì cũng sai hết.
Nếu giờ bắt estimate thì dev ko dám estimate chuẩn, chỉ dám buffer lên gấp 3 thôi, tại mức uncertainty đang quá cao, mà buffer như vậy thì estimate làm gì nữa?"
Hai bạn PM đuối, hỏi mình chứ giờ muốn như nào? (thực chất đoạn này mình hơi sai, tại mình không muốn nói thẳng là hai bạn đó non quá nên mới đặt câu hỏi cho 2 bạn ý suy nghĩ ra giải pháp, nhưng cuối cùng lại bị 2 bạn này mách lại với anh founder rằng mình là kẻ politic, haizz. Nhẽ ra nói thẳng ra giải pháp luôn cho rồi).
Mình bảo đơn giản nhất là các bạn chạy thử 1-2 sprint, sau đó đếm số lượng ticket hoàn thành trong 1 sprint rồi project ra ngày hoàn thành sản phẩm là ok. ko cần phải estimate cho từng ticket làm gì.
Các bạn ý nghe vậy thì k tin, tại đã nghe đến cách làm đó bao giờ đâu nên ầm ờ và xem đó là 1 option, bởi cũng chả mất gì, chỉ là số ticket thôi mà. Tuy nhiên vẫn yêu cầu estimate theo ngày, ok thì mất vài tiếng để estimate cho các bạn PM 1 ngày deadline.
Nhưng chạy vài tháng thì mọi ng đều nhận ra ngày deadline đó lại trật lất nữa. Cuối cùng cũng phải quay lại option là đếm số lượng ticket để ước lượng ngày hoàn thành.
Vậy trong case này, estimate có giúp công ty thành công hơn không?
Rõ là không thể đặt deadline 5 tháng cho bà đẻ được, tại founder chăm chút về value quá, k cho cắt xém thì 5 tháng mà đẻ thì chỉ có toi thôi. Và kể cả có cho người vào được để làm nhanh hơn đi nữa thì 2 bạn PM kia cũng cho ra 1 ngày deadline mới ngắn ngủn và sai bét thôi.
Vậy ta thấy, thời gian ra sản phẩm không đổi, founder tốn thêm tiền cho 2 PM + thời gian cho cả team estimate, con số estimate chỉ có vai trò duy nhất là để chất vấn nhau tại sao chưa làm xong. Với số tiền đó, ta hoàn toàn có thể thuê thêm ít nhất 1 senior + 1 junior dev nữa để giúp sản phẩm release sớm hơn.
Mình không thấy có bất kì một lợi điểm nào của estimate trong case này cả.
Case 3: Công ty product lớn, khoảng 500 dev
Mình thì chỉ làm ở 1 team nhỏ trong c.ty này thôi, tuy nhiên mình thấy văn hoá các team khác cũng khá same same. Thường khi công ty lớn và đã ổn định lâu năm như công ty này thì bộ manager cũng phải ngang ngửa team dev. Mấy ông manager chỉ làm đúng 1 thứ: lấy con số đi báo lên bên trên. Thậm chí công ty đó còn có 1 cái role rất ngộ: release manager.
Release manager là một role tách biệt hoàn toàn với product owner. Product owner nói user cần gì, còn release manager chỉ làm 1 thứ: thúc đít cho team release tính năng đúng lịch và báo lại lên bên trên (WTF?).
Mỗi khi nhớ lại ông release manager này mình lại buồn cười, vì ông ý có lẽ nắm một role vô dụng nhất mình từng biết.
Trong case này mình hoàn toàn không làm được gì nhiều và phải thú thực là mình phá hơn là làm. Bởi thời điểm này mình đang làm cho 3 dự án cùng 1 lúc nên mình đã chấp nhận estimate task và chơi theo kiểu sửa vài dòng text thôi mình estimate cho 1 ngày. Thêm code logic nhẹ nhàng vào thì mình quất cho 2 -3 ngày. Có gọi API rồi sửa nhiều mình chơi cho 1 tuần. Các bạn liền hỏi, ô thế mấy ông manager kia ngu ah mà ko thấy estimate như vậy là quá đáng?
Có thể họ biết chứ, nhưng họ k care, tại cái họ care là milestone, k phải estimate. Đầu tiên khi mình estimate mình tính giải thích cho họ tại sao lại lâu như vậy, nhưng manager gạt/chặn họng luôn, nói là mình k cần giải thích, chỉ cần có con số và phải đảm bảo release đúng ngày đó là được. Vâng, thực tế nó như vậy, mình nghĩ sẽ phải giải thích nhưng họ còn k muốn nghe giải thích nữa.
Công ty này mình không tiện nói tên, nhưng mình chắc chắn rằng tất cả các bạn đang dùng sản phẩm của một công ty X và công ty X có dùng sản phẩm của công ty này.
Bởi đây là B2B product nên nguồn thu của họ khá ổn định, rất ít đối thủ cạnh tranh nên họ không cần phải tối ưu operation làm gì cả, bởi vậy có làm chây ra cũng k ai quan tâm.
Việc estimate trong hoàn cảnh này hoàn toàn chẳng có ý nghĩa gì cả. Dẫu nó có lợi cho mình, cơ bản nó vẫn là việc ngu ngốc và vô dụng nhất mình từng làm cho một công ty.
Có lẽ cũng không cần phải hỏi estimate có khiến công ty thành công hơn không, hãy hỏi nếu công ty này bỏ estimate đi thì chuyện gì sẽ xảy ra?
Áp dụng #NoEstimate
Vấn đề estimate được xem là bình thường ở hầu hết các công ty, nhưng nhìn lại thì nó đem đến hại nhiều hơn là lợi.
Nhưng ngược lại, bạn không thể phủ nhận rằng việc các người cấp cao cần một ngày cụ thể, một con số nào đó là việc họ đáng được có. Việc đưa cho họ một con số nào đó thể hiện sự tôn trọng của mình cho họ, nhưng đồng thời họ cũng phải tôn trọng lại mình bằng cách hiểu rằng, con số đó chỉ là lời đoán mò tốt nhất mà mình có ở thời điểm hiện tại, nhằm giúp họ có quyết định tốt nhất.
Nếu bạn không hiểu được vấn đề này và nghĩ: tôi không thể đưa cho ông một con số được tại vì nó không chính xác, bạn đang không tôn trọng họ và sẽ không bao giờ áp dụng #NoEstimate được.
Thay vào đó, hãy giải thích cho họ hiểu việc estimate từng task rồi cộng lại ra 1 con số là cách kém hiệu quả nhất để có được ngày hoàn thành tính năng. Thay vào đó, hãy lấy tổng số ticket hoàn thành trong mỗi sprint để tính ra ngày hoàn thành sẽ hiệu quả và chính xác hơn nhiều. Bên cạnh đó sẽ tiết kiệm được một mớ tiền cho công ty khi phải trả cho thời gian ngồi estimate.
Hãy thay đổi tư duy của bạn, kiến thức là để gíup người khác chứ không phải để nghĩ người kia ngu si đần độn. Khi bạn dùng kiến thức để tạo lợi ích cho đối phương hoặc tạo cho họ một cảm giác được học hỏi cái mới, họ sẽ dễ dàng chấp nhận. Nhưng nếu bạn dùng kiến thức đó để thay đổi đối phương, chỉ đơn giản bởi bạn nghĩ cách họ đang làm không hợp lý thì sẽ bị kháng cự rất mạnh, và khả năng bạn sẽ thất bại.
Bởi vậy, quan trọng nó nằm ở cái thái độ.
Thay đổi văn hoá
Khó khăn lớn nhất của #NoEstimate có lẽ là cơ hội để bạn nói chuyện với CEO. Nếu bạn được nói chuyện với CEO ở một quán cafe một cách vui vẻ, mang tính chia sẻ thì mọi thứ sẽ dễ dàng hơn rất rất nhiều. Bởi CEO là kẻ có khả năng thay đổi văn hoá của một công ty trong thời gian ngắn nhất có thể. Nhưng khả năng cao là bạn sẽ không có cơ hội.
Nếu chấp nhận rằng ta không thể thay đổi được văn hoá của công ty, ta có thể làm gì khác?
Giải pháp rất đơn giản: đừng cố thay đổi họ, thay vào đó, hãy trở nên hữu ích cho họ hơn.
Có nghĩa: thay vì ép họ thay đổi, hãy giúp họ có một con số được tính bằng #NoEstimate và đưa cho họ tham khảo, giúp quyết định của họ có độ tin cậy cao hơn. Không ai không muốn có thêm con số cả, họ chỉ không muốn vứt bỏ cái họ đang có đi thôi.
Dần dần họ sẽ tự nhận ra cái nào tốt hơn và để họ tự quyết định. Một team làm được thì các team khác sẽ học theo, và nên nhớ, bạn không phải người duy nhất đọc được bài này của mình. Có lẽ đồng nghiệp của bạn cũng đang thử áp dụng ở 1 team nào đó khác cũng nên.
Những kẻ lười biếng
Khó khăn thứ 2 của #NoEstimate đến từ chính giả thuyết của nó. Những người ủng hộ #NoEstimate thường đặt giả thuyết và tin rằng: mọi người trong team đều làm việc tích cực, thành thử kể cả khi không còn áp lực từ bên trên thì release date vẫn không đổi.
Nhưng thực tế không phải vậy, con người lười biếng và chỉ quan tâm đến lợi ích của họ, mình cũng vậy. Nếu có thể làm việc nhàn hơn 1 xíu, mình sẽ nhận job thứ 2 chứ k làm 1 job này 8 tiếng.
Điều đó có lợi cho mình, chẳng có lý do gì mình phải chăm chỉ khi ko có deadline cả.
Mình đã thử cho 2 team ở 2 dự án khác nhau rảnh rang hơn 1 xíu, điều đầu tiên các thành viên làm là kiếm thêm job để tăng thu nhập. Quá dễ hiểu.
Cách gỉai quyết cho vấn đề này cũng cực kỳ đơn giản nhưng cũng cực kỳ phức tạp: pair programming.
Đơn giản ở chỗ bạn chỉ cần là team lead cũng có thể yêu cầu các thành viên phải pair programming với nhau bao nhiêu giờ trong 1 ngày. Mình thường yêu cầu tối thiểu 4 tiếng. Mình đảm bảo với các bạn, việc pair với nhau tối thiểu 4 tiếng 1 ngày sẽ giúp chất lượng phần mềm + tốc độ release nhanh hơn hẳn. Não dev lúc đó sẽ chạy 150% công lực và độ cẩn thận sẽ tăng lên 300%.
Một người làm, người kia ngồi nhìn góp ý thôi cũng được, không quan trọng là senior hay junior, pair được hết. Cỡ 2 tiếng thì đổi qua pair với người khác là ok, không cần pair với 1 người nguyên 4 tiếng. hoặc pair. 2 tiếng buổi sáng, buổi chiều pair với người khác.
Nhưng cái khó ở chỗ nếu bạn làm remote thì pair programming trở nên quá khó. Khó không phải do không làm được, khó do dev rất ngại pair, và cảm giác pair sẽ tốn thời gian và không thoải mái. Nhiều khi thay đổi mỗi cái label thì pair làm gì?
Cho dù bạn có giải thích cho dev cỡ nào họ cũng ầm ờ chứ không tin và nghĩ là bạn xàm.
Bởi vậy, mình nghĩ elon musk đúng hoàn toàn trong việc đòi nhân viên lên công ty.
Kết
Túm lại, hãy nhìn #NoEstimate như một công cụ. Nếu mọi người đang dùng thước để đo một sân bóng đá, đừng xỉ vả cái thước đó rồi nói nó lạc hậu, kèm theo lời quảng cáo thước laser tốt hơn.
Bạn chỉ cần lấy cái thước laser và đo thử, sau đó đưa cho họ con số.
Hãy giúp ích thay vì chỉ nói suông.
Mình sẽ đi qua từng case cụ thể và sẽ dẫn dắt các bạn theo một góc nhìn khác.
Case 1: Một công ty product startup lớn quy mô 2-3 trăm dev
Công ty này trước đây rất chú trọng vào con số cá nhân, ví dụ như số lượng ticket done, thời gian hoàn thành ... các team vẫn estimate, có milestone các thứ. Mỗi khi làm xong 1 tính năng là PO đem đi khoe, mọi người xúm vào khen các kiểu ... nhưng rất nhiều lần mình nhìn thấy các tính năng bị bóp lại để kịp release, thành thử nó không đem lại value gì nhiều cho end user cả.
Điểm chết người nữa khi công ty đặt KPI/metric mục tiêu là:
- Revenue, không phải value đem lại cho người dùng. Điều đó dẫn đến toàn bộ công ty nhìn user như những con hàng, những con cá phải câu bằng được. Họ không nhìn user là những người mình làm sản phẩm ra để giúp đỡ, họ quên cả core value lẫn mission ... Phần lớn các tính năng đem ra chỉ để khuyến khích người dùng làm một việc X gì đó đem lại revenue cho công ty ...
- Milestone, và tất nhiên không phải value. Khi bạn có một cái milestone, slideshow trên màn hình meeting của C-level thì lẽ đương nhiên cả công ty sẽ phải chạy theo nó. Kể cả có phải bóp cho feature méo mó cỡ nào thì cũng phải lọt qua được cái deadline.
Không có gì ngạc nhiên khi công ty tự lao dốc không phanh cho dù chỉ mới là startup.
Giờ thử nghĩ: Estimate có khiến công ty thành công hơn không?
Mình không nói là nên bỏ estimate nhé, mình chỉ đang hỏi Estimate có khiến công ty thành công hơn không?
Với mình, estimate giúp feature ra đúng hạn hơn và ... hết. Vâng, chỉ vậy thôi. Feature ra đúng hạn không có nghĩa công ty thành công. Value của nó mới là thứ khiến công ty thành công.
Còn mặt hại của nó thì chắc mình không cần nói thêm nữa.
Hiện tại công ty đã bớt quan tâm đến storypoint và quan tâm nhiều hơn đến số lượng ticket, một bước đi hợp lý nhưng vẫn còn đặt khá nặng revenue.
Case 2: Một công ty startup 20 dev
Startup này có anh Founder rất rất chú trọng vào độ hoàn thiện của sản phẩm, anh ý muốn từng chi tiết được hoàn thiện, trải nghiệm người dùng phải được chỉnh chu trước khi release. Do tiềm lực có hạn, số lượng dev không nhiều nên anh ý muốn lập plan thật chặt để có được ngày public release. Đại khái là công ty quan tâm đến value của sản phẩm, nhưng cũng rất cần nó release sớm để gọi vốn.
Khi mình join vào thì dự án đã bị trễ gần 6 tháng rồi và deadline đã bị dời đi 3-4 lần gì đó (milestone này do techlead estimate). Cùng lúc đó anh Founder thuê 2 bạn PM scrum master hoành tráng về để làm giúp anh ý. Hai bạn này lập plan các kiểu, bắt dev estimate từng task theo giờ rồi sau đó cộng lại ra ngày release. Dev kêu trời, mình vào nói làm vậy không được đâu, sao mà estimate theo giờ được.
Cả team dev đồng ý, 2 bạn PM đổi qua bắt estimate theo ngày, mình bảo: "ko đc đâu, sản phẩm có thể sẽ thay đổi rất nhiều trong quá trình phát triển, estimate kiểu gì cũng sai hết.
Nếu giờ bắt estimate thì dev ko dám estimate chuẩn, chỉ dám buffer lên gấp 3 thôi, tại mức uncertainty đang quá cao, mà buffer như vậy thì estimate làm gì nữa?"
Hai bạn PM đuối, hỏi mình chứ giờ muốn như nào? (thực chất đoạn này mình hơi sai, tại mình không muốn nói thẳng là hai bạn đó non quá nên mới đặt câu hỏi cho 2 bạn ý suy nghĩ ra giải pháp, nhưng cuối cùng lại bị 2 bạn này mách lại với anh founder rằng mình là kẻ politic, haizz. Nhẽ ra nói thẳng ra giải pháp luôn cho rồi).
Mình bảo đơn giản nhất là các bạn chạy thử 1-2 sprint, sau đó đếm số lượng ticket hoàn thành trong 1 sprint rồi project ra ngày hoàn thành sản phẩm là ok. ko cần phải estimate cho từng ticket làm gì.
Các bạn ý nghe vậy thì k tin, tại đã nghe đến cách làm đó bao giờ đâu nên ầm ờ và xem đó là 1 option, bởi cũng chả mất gì, chỉ là số ticket thôi mà. Tuy nhiên vẫn yêu cầu estimate theo ngày, ok thì mất vài tiếng để estimate cho các bạn PM 1 ngày deadline.
Nhưng chạy vài tháng thì mọi ng đều nhận ra ngày deadline đó lại trật lất nữa. Cuối cùng cũng phải quay lại option là đếm số lượng ticket để ước lượng ngày hoàn thành.
Vậy trong case này, estimate có giúp công ty thành công hơn không?
Rõ là không thể đặt deadline 5 tháng cho bà đẻ được, tại founder chăm chút về value quá, k cho cắt xém thì 5 tháng mà đẻ thì chỉ có toi thôi. Và kể cả có cho người vào được để làm nhanh hơn đi nữa thì 2 bạn PM kia cũng cho ra 1 ngày deadline mới ngắn ngủn và sai bét thôi.
Vậy ta thấy, thời gian ra sản phẩm không đổi, founder tốn thêm tiền cho 2 PM + thời gian cho cả team estimate, con số estimate chỉ có vai trò duy nhất là để chất vấn nhau tại sao chưa làm xong. Với số tiền đó, ta hoàn toàn có thể thuê thêm ít nhất 1 senior + 1 junior dev nữa để giúp sản phẩm release sớm hơn.
Mình không thấy có bất kì một lợi điểm nào của estimate trong case này cả.
Case 3: Công ty product lớn, khoảng 500 dev
Mình thì chỉ làm ở 1 team nhỏ trong c.ty này thôi, tuy nhiên mình thấy văn hoá các team khác cũng khá same same. Thường khi công ty lớn và đã ổn định lâu năm như công ty này thì bộ manager cũng phải ngang ngửa team dev. Mấy ông manager chỉ làm đúng 1 thứ: lấy con số đi báo lên bên trên. Thậm chí công ty đó còn có 1 cái role rất ngộ: release manager.
Release manager là một role tách biệt hoàn toàn với product owner. Product owner nói user cần gì, còn release manager chỉ làm 1 thứ: thúc đít cho team release tính năng đúng lịch và báo lại lên bên trên (WTF?).
Mỗi khi nhớ lại ông release manager này mình lại buồn cười, vì ông ý có lẽ nắm một role vô dụng nhất mình từng biết.
Trong case này mình hoàn toàn không làm được gì nhiều và phải thú thực là mình phá hơn là làm. Bởi thời điểm này mình đang làm cho 3 dự án cùng 1 lúc nên mình đã chấp nhận estimate task và chơi theo kiểu sửa vài dòng text thôi mình estimate cho 1 ngày. Thêm code logic nhẹ nhàng vào thì mình quất cho 2 -3 ngày. Có gọi API rồi sửa nhiều mình chơi cho 1 tuần. Các bạn liền hỏi, ô thế mấy ông manager kia ngu ah mà ko thấy estimate như vậy là quá đáng?
Có thể họ biết chứ, nhưng họ k care, tại cái họ care là milestone, k phải estimate. Đầu tiên khi mình estimate mình tính giải thích cho họ tại sao lại lâu như vậy, nhưng manager gạt/chặn họng luôn, nói là mình k cần giải thích, chỉ cần có con số và phải đảm bảo release đúng ngày đó là được. Vâng, thực tế nó như vậy, mình nghĩ sẽ phải giải thích nhưng họ còn k muốn nghe giải thích nữa.
Công ty này mình không tiện nói tên, nhưng mình chắc chắn rằng tất cả các bạn đang dùng sản phẩm của một công ty X và công ty X có dùng sản phẩm của công ty này.
Bởi đây là B2B product nên nguồn thu của họ khá ổn định, rất ít đối thủ cạnh tranh nên họ không cần phải tối ưu operation làm gì cả, bởi vậy có làm chây ra cũng k ai quan tâm.
Việc estimate trong hoàn cảnh này hoàn toàn chẳng có ý nghĩa gì cả. Dẫu nó có lợi cho mình, cơ bản nó vẫn là việc ngu ngốc và vô dụng nhất mình từng làm cho một công ty.
Có lẽ cũng không cần phải hỏi estimate có khiến công ty thành công hơn không, hãy hỏi nếu công ty này bỏ estimate đi thì chuyện gì sẽ xảy ra?
Áp dụng #NoEstimate
Vấn đề estimate được xem là bình thường ở hầu hết các công ty, nhưng nhìn lại thì nó đem đến hại nhiều hơn là lợi.
Nhưng ngược lại, bạn không thể phủ nhận rằng việc các người cấp cao cần một ngày cụ thể, một con số nào đó là việc họ đáng được có. Việc đưa cho họ một con số nào đó thể hiện sự tôn trọng của mình cho họ, nhưng đồng thời họ cũng phải tôn trọng lại mình bằng cách hiểu rằng, con số đó chỉ là lời đoán mò tốt nhất mà mình có ở thời điểm hiện tại, nhằm giúp họ có quyết định tốt nhất.
Nếu bạn không hiểu được vấn đề này và nghĩ: tôi không thể đưa cho ông một con số được tại vì nó không chính xác, bạn đang không tôn trọng họ và sẽ không bao giờ áp dụng #NoEstimate được.
Thay vào đó, hãy giải thích cho họ hiểu việc estimate từng task rồi cộng lại ra 1 con số là cách kém hiệu quả nhất để có được ngày hoàn thành tính năng. Thay vào đó, hãy lấy tổng số ticket hoàn thành trong mỗi sprint để tính ra ngày hoàn thành sẽ hiệu quả và chính xác hơn nhiều. Bên cạnh đó sẽ tiết kiệm được một mớ tiền cho công ty khi phải trả cho thời gian ngồi estimate.
Hãy thay đổi tư duy của bạn, kiến thức là để gíup người khác chứ không phải để nghĩ người kia ngu si đần độn. Khi bạn dùng kiến thức để tạo lợi ích cho đối phương hoặc tạo cho họ một cảm giác được học hỏi cái mới, họ sẽ dễ dàng chấp nhận. Nhưng nếu bạn dùng kiến thức đó để thay đổi đối phương, chỉ đơn giản bởi bạn nghĩ cách họ đang làm không hợp lý thì sẽ bị kháng cự rất mạnh, và khả năng bạn sẽ thất bại.
Bởi vậy, quan trọng nó nằm ở cái thái độ.
Thay đổi văn hoá
Khó khăn lớn nhất của #NoEstimate có lẽ là cơ hội để bạn nói chuyện với CEO. Nếu bạn được nói chuyện với CEO ở một quán cafe một cách vui vẻ, mang tính chia sẻ thì mọi thứ sẽ dễ dàng hơn rất rất nhiều. Bởi CEO là kẻ có khả năng thay đổi văn hoá của một công ty trong thời gian ngắn nhất có thể. Nhưng khả năng cao là bạn sẽ không có cơ hội.
Nếu chấp nhận rằng ta không thể thay đổi được văn hoá của công ty, ta có thể làm gì khác?
Giải pháp rất đơn giản: đừng cố thay đổi họ, thay vào đó, hãy trở nên hữu ích cho họ hơn.
Có nghĩa: thay vì ép họ thay đổi, hãy giúp họ có một con số được tính bằng #NoEstimate và đưa cho họ tham khảo, giúp quyết định của họ có độ tin cậy cao hơn. Không ai không muốn có thêm con số cả, họ chỉ không muốn vứt bỏ cái họ đang có đi thôi.
Dần dần họ sẽ tự nhận ra cái nào tốt hơn và để họ tự quyết định. Một team làm được thì các team khác sẽ học theo, và nên nhớ, bạn không phải người duy nhất đọc được bài này của mình. Có lẽ đồng nghiệp của bạn cũng đang thử áp dụng ở 1 team nào đó khác cũng nên.
Những kẻ lười biếng
Khó khăn thứ 2 của #NoEstimate đến từ chính giả thuyết của nó. Những người ủng hộ #NoEstimate thường đặt giả thuyết và tin rằng: mọi người trong team đều làm việc tích cực, thành thử kể cả khi không còn áp lực từ bên trên thì release date vẫn không đổi.
Nhưng thực tế không phải vậy, con người lười biếng và chỉ quan tâm đến lợi ích của họ, mình cũng vậy. Nếu có thể làm việc nhàn hơn 1 xíu, mình sẽ nhận job thứ 2 chứ k làm 1 job này 8 tiếng.
Điều đó có lợi cho mình, chẳng có lý do gì mình phải chăm chỉ khi ko có deadline cả.
Mình đã thử cho 2 team ở 2 dự án khác nhau rảnh rang hơn 1 xíu, điều đầu tiên các thành viên làm là kiếm thêm job để tăng thu nhập. Quá dễ hiểu.
Cách gỉai quyết cho vấn đề này cũng cực kỳ đơn giản nhưng cũng cực kỳ phức tạp: pair programming.
Đơn giản ở chỗ bạn chỉ cần là team lead cũng có thể yêu cầu các thành viên phải pair programming với nhau bao nhiêu giờ trong 1 ngày. Mình thường yêu cầu tối thiểu 4 tiếng. Mình đảm bảo với các bạn, việc pair với nhau tối thiểu 4 tiếng 1 ngày sẽ giúp chất lượng phần mềm + tốc độ release nhanh hơn hẳn. Não dev lúc đó sẽ chạy 150% công lực và độ cẩn thận sẽ tăng lên 300%.
Một người làm, người kia ngồi nhìn góp ý thôi cũng được, không quan trọng là senior hay junior, pair được hết. Cỡ 2 tiếng thì đổi qua pair với người khác là ok, không cần pair với 1 người nguyên 4 tiếng. hoặc pair. 2 tiếng buổi sáng, buổi chiều pair với người khác.
Nhưng cái khó ở chỗ nếu bạn làm remote thì pair programming trở nên quá khó. Khó không phải do không làm được, khó do dev rất ngại pair, và cảm giác pair sẽ tốn thời gian và không thoải mái. Nhiều khi thay đổi mỗi cái label thì pair làm gì?
Cho dù bạn có giải thích cho dev cỡ nào họ cũng ầm ờ chứ không tin và nghĩ là bạn xàm.
Bởi vậy, mình nghĩ elon musk đúng hoàn toàn trong việc đòi nhân viên lên công ty.
Kết
Túm lại, hãy nhìn #NoEstimate như một công cụ. Nếu mọi người đang dùng thước để đo một sân bóng đá, đừng xỉ vả cái thước đó rồi nói nó lạc hậu, kèm theo lời quảng cáo thước laser tốt hơn.
Bạn chỉ cần lấy cái thước laser và đo thử, sau đó đưa cho họ con số.
Hãy giúp ích thay vì chỉ nói suông.
Last edited:
XTtinhdauTK17
Senior Member
Mình đang làm trong 1 công ty outsource và gặp tình trạng overload. Làm theo mô hình onshore (customer) - offshore. Team mình là team offshore. Công việc thì estimate trước rồi mới ra ticket. Thế mà các thành viên trong team implement xong hết trước rồi mới ra ticket và cũng chả ai xài jira board để quản lý point của khách hàng. Thấy quá là độc hại.
Gặp đúng bài viết về chủ đề mình đang quan tâm tìm hiểu.
Thanks chủ thớt
via theNEXTvoz for iPhone
Gặp đúng bài viết về chủ đề mình đang quan tâm tìm hiểu.
Thanks chủ thớt
via theNEXTvoz for iPhone
