Định nghĩa câu nói ‘Đã làm xong việc’

Linh Le

Năng suất của một đội ngũ phụ thuộc rất nhiều vào việc thiết lập định nghĩa “hoàn thành” một công việc là gì cho đội ngũ đó, điều đã được tranh luận trong ít nhất một thập kỷ qua. Có thể đặt câu hỏi rằng liệu có thể xem là “đã làm xong” một việc gì đó hay không trong một môi trường mà luôn luôn có sự cải tiến như ngày nay. Tôi cho rằng tuy được xác định rõ ràng, nhưng điều quan trọng là phải hiểu những trở ngại mà các tổ chức vô tình áp đặt vào, từ đó khiến cho định nghĩa “làm xong” đi quá xa. Tất cả những điều này – cho dù nguyên nhân nằm ở vấn đề văn hóa hay quy trình – đều có thể khắc phục được.

Hãy bắt đầu với các đội ngũ đa năng. Trừ khi nhóm Scrum hoặc Agile được tham gia cùng với các hoạt động CNTT, thì định nghĩa của cụm từ “làm xong” có thể khác nhau. Chẳng hạn, nhóm Scrum có thể tập trung vào duy nhất những gì họ đang làm, tách biệt với những gì đang diễn ra trong thế giới của khách hàng: câu việc đã hoàn thành, bước kiểm tra được thông qua, đánh giá code và bảo mật, code sẵn sàng để hợp nhất, và cứ tiếp tục như thế. Nhưng tất cả những điều này tập trung vào nhà phát triển, chứ không phải việc cung cấp giá trị kinh doanh cho thế giới bên ngoài.

Hãy tưởng tượng sự thất vọng sau khi đưa vào sử dụng một ứng dụng mới và vào ngày đầu tiên, bộ phận hỗ trợ kỹ thuật nhận được một cuộc gọi từ một khách hàng quốc tế quan trọng, yêu cầu dòng địa chỉ thứ 2 phải cho phép điền 65 ký tự thay vì 45 ký tự.

Tệ hơn nữa là khi một đội ngũ tin rằng họ sẽ chuyển đến khâu sản xuất vào tối thứ ba, vậy mà bất thình lình, một chuyên gia về IT lại làm họ mất hứng khi thông báo rằng cần lên lịch thay đổi cơ sở dữ liệu trước 3 tuần.

Ước tính

Các nhà phát triển cũng có thể bị phân tâm bởi việc phải giải quyết ngay một vấn đề và sửa lỗi, điều này có thể làm hỏng lịch trình và đòi hỏi chúng ta phải thực hiện bước tiếp theo. Đó là ước tính. Chẳng hạn, việc phân bổ 60% thời gian của nhà phát triển vào các câu chuyện trong một lần lặp (tức là, có năng suất) nghe có vẻ hợp lý, nhưng mọi thứ có thể xảy ra. Ngoài ra, các đội nổi tiếng đấu tranh với ước tính; họ có thể phân bổ quá mức hoặc dưới mức phân bổ.

Một trong những nguyên lý chính của Agile là chia các dự án thành từng phần nhỏ và hoàn thành công việc sớm. Bản thân nó là một cách làm tốt để xác định cả hai yếu  tố”làm xong” và “làm tốt”. Trong chu kỳ phát hành kéo dài 4 tuần, điều quan trọng là có tất cả các câu chuyện được lên kế hoạch cho tuần đầu tiên thực sự xảy ra trong tuần đó và không bị vỡ trận vào tuần tiếp theo – và mỗi tuần tiếp theo.

Can thiệp

Chúng ta đều biết rằng trong một dự án, mọi người có thể hiểu được những đề xuất tuyệt vời, hợp lệ để cải thiện. Điều này có thể ảnh hưởng đến không chỉ các khung thời gian giao hàng mà còn gây ra creep scope. Quay trở lại ví dụ phát hành bốn tuần đó, chúng ta có thể nhận ra khung thời gian như vậy đủ dài để nhiều ý tưởng tuyệt vời có thể được thêm vào. Tuy nhiên, tốt hơn là nên gắn bó với kỷ luật hoàn thiện những gì đã bắt đầu. Có những lợi ích văn hóa lâu dài cho việc này, không ít trong số đó là giữ cho các nhà phát triển có động lực và tránh nợ kỹ thuật, cả hai đều cản trở việc thực hiện.

Đây là một kịch bản điển hình. CEO đưa ra một gợi ý cho các tính năng bổ sung. Về nguyên tắc, chúng có vẻ tốt, nhưng trong thực tế, việc thực hiện các ý tưởng trong bản phát hành hiện tại có thể có nghĩa là giới thiệu các yếu tố chưa được ước tính. Điều này có thể buộc các lối tắt, hoặc tạo ra các phụ thuộc khác quay trở lại ám ảnh bản phát hành tiếp theo. Thay đổi không phải lúc nào cũng tương đương với Agile. Tất nhiên, không có gì được đặt trong đá và, nếu một đề xuất vẫn mang lại giá trị và có thể được xây dựng vững chắc trong cùng một khung thời gian, có lẽ sẽ có ý nghĩa khi thực hiện bổ sung đó.

Điều này đưa chúng ta đến một điểm cuối cùng và rất quan trọng: giá trị kinh doanh, một thuật ngữ được sử dụng nhiều đến nỗi mắt trừng trừng. Nhưng khi giá trị doanh nghiệp còn mơ hồ thì khó có thể định nghĩa được. Thực hiện nếu tiêu chí thành công do doanh nghiệp xác định không được đáp ứng, thì đã thực hiện điều đó đã không xảy ra.

Câu trả lời

Câu trả lời cho việc định nghĩa giá trị doanh nghiệp, từ đó giúp xác định tình trạng “làm xong” là có một điều lệ rõ ràng về giá trị doanh nghiệp là gì. Đặt mục tiêu rõ ràng, chẳng hạn như: “Bốn tháng sau khi chúng tôi phát hành phiên bản mới của trò chơi video trực tuyến này, doanh thu được mong đợi là sẽ tăng lên rất nhiều. Hoặc trong vòng hai tháng, chúng tôi hy vọng việc mua lại người chơi mới được tạo bởi lời mời người chơi hiện tại sẽ tăng lên 25%.

Chúng ta nên luôn phấn đấu để xây dựng một sản phẩm được thực hiện trên một sản phẩm trực tuyến mang lại giá trị cao nhất cho khách hàng. Trong kế hoạch, sản phẩm, tính năng hoặc phát hành có giá trị nhất phải được ưu tiên cao nhất. Sau đó, trong khi nước rút đang diễn ra, mọi người trong nhóm nên thường xuyên tự hỏi mình, Đây có phải là điều quan trọng nhất tôi nên làm ngay bây giờ không? Và nếu không, tại sao không?

Một lượng thời gian thực tế cần được dự toán cho các khoản nợ kỹ thuật không lường trước được. Tốt hơn là xác định sớm trở ngại tiềm năng này trong quá trình lập kế hoạch. Làm điều đó có thể liên quan đến việc đưa chủ sở hữu sản phẩm xuống với các nhóm nhà phát triển và xem xét liệu câu chuyện có thể thực hiện được hay không, quá lớn, những gì vẫn cần phải hoàn thành, v.v. (nói cách khác, quá trình tinh chỉnh tồn đọng). Điều quan trọng là sự tinh chỉnh này xảy ra trước khi bất kỳ cuộc chạy nước rút nào bắt đầu.

Ngoài định nghĩa đã được thực hiện, thì còn có một trường hợp cho định nghĩa khẩn cấp của người dùng. Ví dụ, đó có phải là tính năng bổ sung hoặc phân tâm từ phạm vi dự án để dập lửa, thực sự là một trường hợp khẩn cấp? Là người quản lý, tôi nên tự hỏi mình, nếu tôi không làm gián đoạn nhà phát triển này khỏi những gì cô ấy đang làm (đó là điều quan trọng nhất chúng ta nên làm), và cô ấy sẽ làm việc với tính năng đề xuất hoặc lỗi sản xuất của CEO, thế giới sẽ Kết thúc? Vượt qua hay, tôi sẽ mất khách hàng quan trọng này? Công việc không có kế hoạch là nguyên nhân tình cờ lớn nhất của việc không đạt được thành công thực hiện đối với hầu hết các đội. Lưu tâm đến tác động của các loại thay đổi này sẽ không chỉ tăng năng suất mà, cũng quan trọng, các nhà phát triển công ty cam kết tin tưởng rằng doanh nghiệp sẽ không làm gián đoạn công việc của họ trong khi họ đang ở sâu trong một dự án.

Tương tự, khi thực hiện các ước tính, điều cần thiết là bao gồm những gì được mong đợi của Ops trong khung thời gian phát hành, chẳng hạn như trong ví dụ về thay đổi cơ sở dữ liệu của chúng tôi. Ngoài ước tính thực tế, bạn cũng nên loại bỏ yếu tố cá nhân. Quan sát theo thời gian vận tốc thực sự của một đội là gì, thay vì dựa vào phỏng đoán cá nhân. Các công cụ lập kế hoạch nhanh nhẹn có thể giúp rất nhiều ở đây.

Có, nhóm Scrum có lẽ nên được tham gia cùng với Hoạt động CNTT. Đây là những gì DevOps nói về. Theo bản chất của nó, DevOps cung cấp sự minh bạch, hợp tác và hoàn thành, một cách cụ thể, về mục tiêu Agile cơ bản là cung cấp giá trị cho khách hàng. DevOps không cung cấp tính linh hoạt cao hơn, nhưng trong khuôn khổ thực tiễn được xác định rõ ràng và được ghi chép rõ ràng. Vì vậy, không có bất ngờ cho bất cứ ai, nội bộ hoặc bên ngoài cho nhóm.

Từ góc độ quá trình, việc cải thiện từng kịch bản mà chúng tôi đã nói ở đây có thể được quản lý theo nhiều cách khác nhau. Tuy nhiên, chính nền văn hóa DevOps được ca ngợi rất nhiều đã đưa phạm vi thực hiện phạm vi lên một cấp độ khác. Đó là một văn hóa công ty tuyệt vời dẫn đến năng suất nhóm lớn hơn được hiểu rõ. Mặc dù đã hoàn thành một cách khác nhau theo từng dự án (và điều đó có thể nằm trong bối cảnh cải tiến liên tục), con đường cơ bản để đạt được điều đó là xác định cách tránh những rào cản mà con người và quy trình có thể tạo ra.

Chia sẻ bài viết ngay

Nguồn bài viết : https://sdtimes.com