Khi ở trong tình huống khẩn cấp, thật khó để hoàn thành bất cứ việc gì quan trọng. Trong thế giới công nghệ, đang có một xu hướng thời thượng khi tự tin nói rằng bạn vẫn ổn dù gặp thất bại. Nhưng thất bại để lại một dư vị thật tồi tệ đối với bạn. Cách duy nhất để giải quyết vấn đề là chứng minh rằng bạn đã học được gì từ sai lầm của mình.

Trên tinh thần đó, các nhóm kỹ sư tại Altassian đã bắt đầu một cuộc thảo luận về việc đặt ra deadline (thời hạn) vì lợi ích mà nó mang lại, và việc ưu tiên deadline đó hơn cả giá trị của khách hàng hoặc chất lượng của tổng thể sản phẩm (và cả nhóm phát triển). Đây rõ ràng không chỉ là vấn đề riêng của các nhóm phát triển tại Atlassian.

Điều này thật khó để thảo luận, vì việc thừa nhận rằng bạn đang bị ám ảnh bởi deadline không hề dễ chịu chút nào. Nhưng nếu không đối mặt trực tiếp, với tư cách là một cộng đồng các nhà phát triển phần mềm, chúng ta sẽ tiếp tục mắc sai lầm. Hãy ngăn chặn điều đó bằng cách chia sẻ những gì ta học được và tiếp thu từ bài học đó.

Đợi một chút! Deadline có gì tồi tệ vậy?

Bất cứ khi nào bạn cam kết xây dựng một thứ gì đó, câu hỏi tự nhiên tiếp theo sẽ là Khi nào nó được hoàn thành?. Và khi bạn trả lời câu hỏi đó với một ngày tháng cụ thể – hay nói cách khác, khi bạn đặt ra thời hạn, bạn đã đặt uy tín lên hàng đầu. Các nhà quản lý, chủ sở hữu sản phẩm và nhà phát triển đều muốn cho thấy bản thân họ tuyệt vời như thế nào bằng cách bàn giao những gì đã hứa theo đúng thời gian và ngân sách.

Vấn đề chính là, bạn vừa đặt ra ngày bàn giao sản phẩm cho một dự án non trẻ mà thậm chí bạn còn chưa khám phá hết. Không có một cơ sở hợp lý nào để ước tính mức độ khó khăn của nó. Ngoài ra, hầu hết các dự án cũng không tồn tại trong môi trường chân không, và những dự án nhìn qua có vẻ không liên quan nhưng sẽ có sự phụ thuộc và xung độ ở mức tối thiểu. Thời hạn dành cho việc hoàn thành chúng, gần như không bao giờ được điều chỉnh cho phù hợp.

Tại thời điểm đó, tất cả những gì mọi người quan tâm là tìm ra được một thứ gì đó để họ khỏi bị mất mặt. Các tính năng cần được hoàn thiện đúng hạn, chu đáo. Cân bằng giữa công việc và cuộc sống chỉ là một kỷ niệm đẹp. Những gì bạn có chỉ là một môi trường gần như không thể làm điều gì đúng đắn. Điều này gây tổn hạn cho cả nhóm phát triển và khách hàng của bạn.

Công bằng mà nói, sự khẩn cấp không hẳn là một điều xấu. Bạn không thể luôn luôn hoạt động trong chế độ cấp bách như vậy. Đôi khi bạn sẽ làm việc toàn bộ thời gian mình có, vì việc bàn giao dự án càng sớm càng tốt là rất quan trọng. Nhưng sau đó, bạn cần phải cố gắng, dù là dành thời gian nghỉ ngơi, tìm ra một ý tưởng bạn đang ấp ủ, hay cải thiện điểm yếu trong sản phẩm của mình – chính là cân bằng lại mọi thứ.

Hãy ghi nhớ 10 dấu hiệu của sự phát triển chạy theo thời hạn dưới đây. Từng dấu hiệu riêng biệt không phải là vấn đề quá lớn, nhưng khi bạn nhận thấy nhóm của mình đang gặp phải nhiều vấn đề, hay có nhiều người đang đối mặt với một tình trạng nào đó, thì có lẽ đã có một điều gì đó không ổn.

1. Bạn cần phải bảo đồng nghiệp của mình ngừng làm việc ngoài giờ làm việc bình thường của họ

Bắt đồng đội kiểm tra mã nguồn hoặc xem xét một pull request sau khi kết thúc giờ làm việc đã lâu (hoặc vào sáng sớm) không phải là vấn đề nếu nó chỉ xảy ra đôi lần. Tuy nhiên, nếu điều đó diễn ra thường xuyên và không phải là tình huống mà cả nhóm đã thỏa thuận, thì có lẽ người đó đang làm việc quá sức. Chúng ta không thể phát huy hết khả năng của mình trong tình trạng đó.

Ý tưởng: Nếu bạn nhận thấy một đồng nghiệp đang làm việc một cách bất thường trong nhiều ngày, hãy cân nhắc nói chuyện với họ. Nếu bạn có thể làm gì đó để giảm bớt gánh nặng cho họ, hãy làm điều đó. Nếu không, hãy khuyến khích họ nói chuyện với trưởng dự án. Điều tốt nhất mà nhà quản lý có thể làm là kéo dài thời hạn hoặc giảm nhẹ khối lượng công việc cho nhân viên.

2. Tuần lễ sáng tạo bị trì hoãn hoặc hủy bỏ

Tuần lễ sáng tạo là một thời điểm có thể thực hiện việc cân bằng lại bản thân bạn sau một chuyển biến lớn, chẳng hạn một phiên bản phát hành quan trọng? Các nhà phát triển có cơ hội thử nghiệm các ý tưởng, tính năng, một thư viện mã nguồn mở mới, trong khi chủ sở hữu sản phẩm có cơ hội hiệu chỉnh lại các yêu cầu tồn đọng, còn nhà thiết kế có thể phác thảo lại các concept cho vòng làm việc tiếp theo. Không phải mọi tuần lễ sáng tạo đều tạo ra những sản phẩm được đưa vào sản xuất, nhưng một số lượng lớn trong đó đã thành hiện thực. Có một sự thật thú vị rằng Jira Service Desk được sinh ra từ một dự án trong tuần lễ sáng tạo, và giờ đây, nó đã trở thành một sản phẩm hoàn chỉnh.

Nếu những khoảng thời gian này bị ảnh hưởng, tinh thần của cả nhóm cũng sẽ bị tác động. Điều này càng phức tạp hơn nếu tuần lễ sáng tạo của công ty bạn được thực hiện bởi nhiều nhóm. Chỉ cần một nhóm trì hoãn hoặc cắt giảm thời gian, mọi thứ sẽ trượt ra khỏi quỹ đạo vốn có của nó.

Ý tưởng: Xây dựng văn hóa doanh nghiệp với những tuần lễ sáng tạo, tôn vinh những dự án được tạo ra từ đó, và hãy giúp giá trị của chúng ăn sâu vào tâm trí của các nhà quản lý và khách hàng.

3. Mọi người đề nghị sử dụng các tuần sáng tạo để “trả nợ kỹ thuật”

Xây dựng mọi thứ đúng cách và hoàn thành các nhiệm vụ liên quan đến sức khỏe kỹ thuật nên được phản ánh trong ước tính và lộ trình của bạn ngay từ đầu. Tuần lễ sáng tạo chỉ là để sáng tạo. Không phải mọi ý tưởng đều sẽ thành công, nhưng không sao cả. Các nhóm sẽ học được những cách làm việc mới mẻ thông qua những công việc đa dạng trong tuần lễ đó.

Khi tuần lễ sáng tạo được sử dụng để trả nợ kỹ thuật, sự đổi mới đã bị cản trở. Bạn sẽ bắt đầu nghe thấy những câu như Chúng tôi vừa dành một tuần để sửa lỗi. Tại sao lại sửa lỗi này ngay bây giờ? Chúng ta có thể đợi đến tuần lễ sáng tạo tiếp theo không? Việc trả nợ kỹ thuật vốn có từ những bản phát hành trước đây dẫn đến sự cố ngừng hoạt động và các sự cố khác, khiến tốc độ chậm chạp hơn và làm phát sinh những xung đột kỹ thuật trong nhóm.

Ý tưởng: Hãy dành thời gian cho khoản nợ kỹ thuật trong toàn bộ kế hoạch của bạn, ngay cả khi nó chỉ là một chút thời gian trong mỗi sprint. Điều đó sẽ tạo nên một sản phẩm lành mạnh hơn trong suốt nhiều tháng hoặc nhiều năm.

4. Không thể thương lượng phạm vi dự án, hoặc không còn phạm vi thị trường

Bạn có thể tiếp tục cắt giảm phạm vi để đạt được thời hạn không? Câu trả lời là không. Cuối cùng thì các bản phát hành trở thành các tính năng nửa vời không thể bán trên thị trường. Có rất nhiều sắc thái cần được xem xét ở đây, nhưng không phải lúc nào bạn cũng có thể tuân thủ ngày hẹn bàn giao dự án và phạm vi dự kiến ban đầu. Vì vậy, bạn có thể giữ ngày bàn giao và phát hành trên phạm vi nhỏ hơn, hoặc tăng thời gian một chút để phù hợp với phạm vi lớn. Dẫu sao thì, trời vẫn chưa sập mà!

Tuy nhiên, điều thật sự nguy hiểm là làm cho phạm vi trở nên không thể thương lượng được. Nó phá hủy ý tưởng rằng một nhóm sở hữu công việc của họ. Bạn có thật sự sở hữu một dự án nếu bạn không được phép điều chỉnh phạm vi?

Ý tưởng: Đầu tư thời gian vào một hoặc cả hai kỹ thuật sau: 1) Khám phá các dự án và tính năng đủ kỹ lưỡng từ trước để bạn có được đầy đủ thông tin, ý tưởng về phạm vi và thời hạn hợp lý bạn có thể bàn giao sản phẩm. 2) Đồng ý về những đánh đổi bạn sẵn sàng thực hiện (ví dụ như khả năng mở rộng thay vì khả năng sử dụng) khi bắt đầu dự án để mọi người có thể đưa ra quyết định độc lập trong việc duy trì phạm vi.

5. Deadline phụ thuộc vào những thông báo chỉ để “làm màu”

Nếu các nhóm tiếp thị sản phẩm cảm thấy rất đau đầu khi phải dời lại một lịch trình nào đó và bỏ lỡ cơ hội công bố điều gì đó ở một hội nghị hoặc một thời điểm chín muồi, thì các nhóm phát triển lại cảm thấy uể oải khi lịch trình giữ nguyên một cách cứng nhắc. Còn khách hàng thì kiểu gì cũng thấy mệt, dù là phần mềm đến muộn, hay đúng giờ nhưng chất lượng kém, vì đằng nào họ cũng phải chờ đợi để có được những gì họ thật sự muốn.

Ý tưởng: Có lẽ chúng ta nên thêm một chút sự linh hoạt về những gì sẽ được ra mắt và ra mắt vào thời điểm nào để giảm sự bất mãn của mọi người xuống mức tối thiểu.

6. Mọi người căng thẳng một cách bất thường và khó chịu với nhau

Quá rõ ràng, điều này làm mọi thứ chậm lại. Trong một môi trường bị định hướng bởi thời hạn, con người sẽ có xu hướng lấn sang các lĩnh vực ngoài chuyên môn của mình để nỗ lực dẫn đầu cuộc chơi, thay vì dành thời gian mang lại những đóng góp chất lượng trong thế mạnh của họ.

Ý tưởng: Khuyến khích mọi người đánh giá cao đồng nghiệp của họ. Trong một nhóm, lập trình đôi là một cách hiệu quả để mang lại điều này. Giữa các nhóm, các sự kiện như lunch and learn có thể giúp họ trao đổi công việc của hai nhóm một cách thoải mái và tìm cách hỗ trợ lẫn nhau.

7. Phương thức thông thường bị lãng quên và trách nhiệm bị bỏ qua

Thời hạn có xu hướng đánh cắp sự tập trung của chúng ta vào các văn hóa của nhóm và phương thức cộng tác đã được thiết lập trước, bởi vì bạn sẽ không còn cảm nhận được điều gì khác ngoài sự cấp bách. Sprint Retrospective? Làm gì có thời gian! Bữa trưa của nhóm? Không quan trọng! Sửa bản build? Lát nữa, tôi đang bận rồi! Điều này sẽ kết hợp với dấu hiệu số 6: Khi mọi người lấn sân để vượt lên mọi thứ, họ không còn tập trung vào những việc quan trọng hằng ngày nữa.

Ý tưởng: Hãy đầu tư thời gian củng cố lại những điều cơ bản thực sự giúp các nhóm tiến hành nhanh hơn và bàn giao được nhiều hơn.

8. Không có thời gian để giao lưu và xây dựng mối quan hệ với mọi người

Yếu tố này khác với điều số 6. Thật khó để dồng cảm với những người lạ vì bạn cần phải hiểu và cảm nhận được vấn đề của họ, điều này gần như là không thể khi bạn có thể chỉ biết mỗi tên của họ. Một phần của việc dễ chịu với nhau là tạo điều kiện và hỗ trợ lẫn nhau. Khi bị áp lực về thời gian, con người có xu hướng chỉ tập trung vào công việc của mình, sau đó đổ lỗi cho người khác khi mọi việc diễn ra không như ý muốn.

Ý tưởng: Tận dụng tối đa những khoảnh khắc nhỏ để giao lưu, bất kể bạn đang ở đâu trong tiến độ, ngay cả khi chỉ là một tách cà phê nhanh chóng. Chờ đợi cho đến ngày bàn giao sản phẩm mới bắt đầu làm quen nhau – đặc biệt là khi làm việc với những người lạ, giống như việc dọn dẹp một chiếc cốc bị rơi từ trên bàn xuống dù trước đó bạn hoàn toàn có thể dời nó vào bên trong một cách an toàn vậy.

9. Những nhân viên mới chú trọng kết quả hơn việc học hỏi

Những tuần đầu tiên nên là thời gian để mọi người học hỏi, tìm hiểu và được chào đón. Không nên để họ cảm thấy áp lực phải làm việc hết năng suất trong tuần đầu tiên (mốc thời gian này có một chút khác biệt đối với thực tập sinh). Các cuộc trò chuyện trong thời gian này nên tập trung hơn vào việc đảm bảo cho họ có thông tin và tài nguyên cần thiết để có thể làm việc hiệu quả.

Ý tưởng: Tạo ra một kế hoạch 90 ngày cho những nhân viên mới để hướng dẫn họ vượt qua tất cả những khó khăn nhưng vẫn mang lại kết quả, ví dụ như: Chọn một lỗi từ backlog để sửa trong tuần đầu tiên của bạn và học hỏi dần từng chút một.

10. Những cuộc họp 1-1 với người quản lý có nội dung về dự án và thời hạn

Những cuộc họp này nên có chủ đề là sự phát triển, hỗ trợ, phản hồi và những ước mơ lớn. Khi những cuộc trò chuyện này thay đổi, quỹ đạo của mọi người (bao gồm cả người quản lý) và tốc độ của dự án sẽ chậm lại. Khi những buổi gặp 1-1 trở nên giống như sprint planning, retrospectives, hay stand-ups,  chắc chắn sẽ làm nảy sinh nhiều vấn đề hơn sau đó.

Ý tưởng: Dành một số lần nhất định trong những cuộc gặp 1-1 để phát triển sự đồng cảm. Chia sẻ về những gì đang xảy ra với mỗi cá nhân ngoài công việc (trong phạm vi họ cảm thấy thoải mái để chia sẻ). Bày tỏ lòng biết ơn về cách mọi người đã giúp đỡ lẫn nhau. Hỏi thăm xem người khác cần những gì để thành công hơn trong công việc của họ lúc này. Thậm chí chỉ cần trút bỏ được bất cứ điều gì trong lòng cũng có thể giúp xoa dịu mỗi người và giúp tinh thần phấn chấn hơn khi quay trở lại công việc.

Những ý tưởng tốt hơn để cân bằng mọi thứ

Câu trả lời cuối cùng mà chúng ta cần trả lời là: Ta đang làm mọi việc dựa trên sự khẩn cấp hay sự quan trọng? Bạn có thể ưu tiên một số công việc khẩn cấp, nhưng nếu tất cả mọi việc đều khẩn cấp thì sẽ không có gì quan trọng được hoàn thành cả. Nhưng không có nghĩa là chúng ta cho mình được tự mãn. Khách hàng mong chờ các tính năng và bản sửa lỗi được bàn giao, còn các đối thủ cạnh tranh thì ngang tài ngang sức với bạn (hoặc tệ hơn là vượt mặt bạn). Dưới đây là hai ý tưởng tổng thể giúp bạn đạt được sự cân bằng tốt hơn:

• Bản phát hành nhỏ hơn: Hầu hết (không phải là tất cả) các sản phẩm tại Atlassian đã chuyển sang lịch trình phát hành chặt chẽ hơn, trong đó phạm vi của mỗi bản phát hành là tương đối nhỏ. Đầu tiên, việc ước tính phạm vi những gì bạn có thể phân phối trong hai tuần sẽ dễ dàng hơn khi xét về hai tháng. Hơn nữa, khách hàng có thể cảm thấy hứng khởi hơn. Vì vậy, khi nói rằng một tính năng sẽ sớm được ra mắt, họ sẽ đặt nhiều niềm tin hơn vào điều đó. Ngoài ra, các phản hồi cũng được trao nhận nhanh hơn, giúp các quyết định kỹ thuật sáng suốt hơn được đưa ra và giảm thiểu rủi ro bàn giao những chức năng không đúng mong muốn của khách hàng.
• Những cuộc trò chuyện thoải mái về tính năng và ngày tháng: Đây là cách để chiến thắng sự mong đợi của mọi người. Tốt hơn hết là nên mơ hồ một chút về ngày bàn giao sản phẩm hơn là hứa hẹn rõ một ngày, sau đó phải công khai sửa đổi nó nhiều lần. Các đồng nghiệp trong lĩnh vực tiếp thị cũng sẽ dễ dàng hơn khi họ không phải lên lịch lại nhiều lần hoặc từ chối công khai khi các dự án bị chậm tiến độ hoặc không được thực hiện.

Lập kế hoạch, ước tính và quản lý tốt hơn là  điều luôn được tìm cách phát triển trong công nghệ phần mềm trong hơn 60 năm, vì vậy chúng ta không nên đặt hy vọng cao quá về việc chạy theo thời hạn hoặc phát triển sản phẩm trong một sớm một chiều. Tuy nhiên, chúng ta vẫn nên cố gắng thực hiện theo hạn định, và nên cẩn thận để không đổ lỗi hết cho các nhà quản lý. Đó là trách nhiệm của tất cả mọi người.

Nguồn: Atlassian Blog