4 giải pháp tốt nhất để xây dựng nhiều ứng dụng hoàn hảo nhanh hơn

Người ta nói rằng code mà không có bug là code chưa được viết ra. Cố gắng ngăn chặn lỗi sai khi mà chắc chắn nó sẽ xảy ra không giải quyết được gì cả. Phương án tệ hại này không giải quyết được gốc rễ vấn đề; nó chỉ là tấm vải thưa che đậy sự thật trong chốc lát mà thôi.

Đó là lí do tại sao nhiều công ty chuyển sang dùng Agile, giải pháp “sai sớm, sai liên tục”, từ đó nhận thấy được lỗi và sửa sớm nhất có thể. Tuy nhiên, chúng ta chưa nhắc nhiều tới việc văn hóa công ty cần phải được bồi dưỡng để tạo nên môi trường tích cực luôn khuyến khích tư duy “sai sớm”. Bất cứ công ty nào muốn thành công trong thị trường cạnh tranh ngày nay đều phải xem “sai phạm” là một phần quan trọng của văn hóa công sở và loại bỏ cảm giác khó chịu với giải pháp này. Cuối cùng, tất cả những gì cần thiết là các team năng động sẽ mang tới những ý tưởng mới nhằm thúc đẩy tăng trưởng và tạo ra nhiều kết quả.

Hãy hiểu rõ là team phần mềm không phải là một cỗ máy được lập trình sẵn. Các team không chỉ đơn giản là cứ tạo ra động lực và rồi hi vọng sẽ mang lại hàng loạt phần mềm tuyệt vời mà không có sự hỗ trợ hay quy trình đúng đắn nào. Bước nhảy vọt từ “sai sớm” cho tới “tiến lên sớm” yêu cầu có một văn hóa phù hợp để thật sự học hỏi và thay đổi từ những sai phạm không thể tránh khỏi, không kể tới dữ liệu và kiến thức chuẩn xác để đem lại những mục tiên và ưu tiên thực tế, cũng chưa nói tới công nghệ và công cụ thích hợp để hoàn thành công việc. Thời gian chính là nguồn lực quý giá nhất trong thế giới phần mềm hiện đại, nhưng việc tạo ra một môi trường đặt tốc độ sáng tạo lên hàng đầu sẽ phản tác dụng.

May mắn là còn có cách tốt hơn: không chỉ triển khai nhanh, mà hãy học cách xây dựng phần mềm tốt hơn một cách nhanh hơn.

4 phương pháp dưới đây có thể giúp tổ chức của bạn sai sớm hơn và tốt hơn trên hành trình xây dựng nên nhiều phần mềm hoàn hảo hơn.

1. Bồi dưỡng một nền văn hóa an toàn về mặt tâm lý

Điều đầu tiên, nếu bạn dự định thử nghiệm tại nơi làm việc, bạn cần làm sao cho cả team của mình cảm thấy an tâm và thoải mái khi phạm sai lầm thường xuyên. Các nghiên cứu từ Google và các công ty khác cho thấy tâm lý an toàn là một trong những yếu tố quan trọng nhất của các team luôn tiến bộ nhanh. Đơn giản thì cảm giác an toàn xuất hiện khi các team có thể chấp nhận rủi ro lớn mà không sợ cảm giác rối bời – điều cực kỳ quan trọng khi bạn muốn tung sản phẩm mới ra thị trường. Hãy xem cảm giác an toàn tâm lý là một yếu tố doanh nghiệp then chốt, cũng như doanh thu, giá bán và thời gian vận hành. Nó, cùng với những yếu tố doanh nghiệp then chốt khác sẽ hỗ trợ cho hiệu quả, năng suất và giữ chân nhân viên của team bạn.

Lời khuyên: Nhấn mạnh vào mục đích và giá trị, thể hiện tính khiêm tốn trong vai trò là leader, chịu khó đặt câu hỏi, làm hết sức để loại bỏ tâm lý ghét sai phạm.

2. Tạo nên một thực tại chung cho mọi người

Để có được văn hóa “sai sớm” và văn hóa thử nghiệm, mọi người trong công ty cần đồng hành sát sao cùng với chiến lược toàn cảnh. Nếu không, các team sẽ trải qua hiện tượng nhập nhằng giữa các bộ phận, gây nên những xích mích nội bộ, và lệch khỏi quỹ đạo thực hiện những nhiệm vụ ưu tiên và chiến lược tổng quát. Một dấu hiệu phổ biến của một team không tiến triển đủ nhanh là khi việc quản lý, thiết kế và chế tạo sản phẩm không thống nhất và không hiểu các ưu tiên và thách thức của các nhóm khác là gì.

3. Phân quyền (và trang trọng hóa) việc ra quyết định

Các leader nhất thiết phải nhận ra rằng để thực sự khuyến khích các thử nghiệm, team của họ không cần phải chờ đợi hàng tuần để được chấp thuận. Trì hoãn phán quyết sẽ hủy hoại mục tiêu tạo nên văn hóa “sai liên tục”. Mỗi team nên phát triển khả năng tính toán rủi ro và cho ra mắt phần mềm mới nhanh chóng trong quá trình giải quyết nhu cầu của khách hàng của mình.

Hiểu được cách đưa ra quyết định sẽ giúp cho các team tiến hành quá trình này với cái nhìn rõ ràng hơn. Trách nhiệm của leader là thiết lập các quy tắc đưa ra quyết định và cho trao quyền quyết định cho người khác.

Để không gây sai phạm, mang lại giá trị trong thời gian chỉ định ngắn nhất yêu cầu phải phân quyền việc đưa ra quyết định. Không có gì ngạc nhiên khi các team trở nên trì trệ khi họ phải chờ cho quyết định của mình được chấp thuận. Thậm chí còn tệ hơn khi việc ban hành quyết định từ bên trên sẽ giới hạn khả năng cải thiện của team.

Lời khuyên: Hãy dùng mô hình DACI trong tổ chức của bạn. Mô hình đưa quyết định DACI là một mô hình được thiết kế để cải thiện hiệu quả của team và tạo động lực cho các dự án, thông qua việc phân rõ vai trò và nhiệm vụ cụ thể cho từng thành viên của team khi cần đến quyết định nhóm. Tên của các vai trò và trách nhiệm này tạo nên cái tên DACI: Driver -Người điều hành (người thực hiện quyết định), Approver – Người phê chuẩn thuận (người thông qua quyết định), Contributors – Người đóng góp (người hoặc team đóng góp vào dự án), và Informed – Người có liên quan (người có thể bị ảnh hưởng công việc từ các quyết định này và vì thế cần phải theo dõi cùng mọi người)

Chỉ định người nắm giữ và mốc thời gian cho các quyết định để tăng thêm trách nhiệm. Tương tự, với vai trò là người sáng lập của Amazon, Jeff Bezos đã giải thích rằng việc hiểu sự khác nhau giữa các quyết định một chiều và hai chiều là điều bắt buộc. Nói một cách văn vẻ thì không có đường lui với các quyết định một chiều. Mặc dù các quyết định hai chiều có thể có cảm giác tạo nên tác động về sau, nhưng chỉ với chút ít thời gian và nỗ lực (thường là ít hơn bạn nghĩ) thì chúng có thể đảo ngược lại.

4. Đầu tư vào một nền tảng chắc chắn

Để xây dựng văn hóa “sai sớm, sai thường xuyên” có thể mất tới hơn hai tuần để tạo ra một phần mềm và đưa nó vào sản xuất. Để bắt đầu, các công ty nhất thiết phải có một nền tảng ở cấp độ doanh nghiệp, nó cho phép các team tiến hành các thử nghiệm liên tục nhanh chóng. Bạn cần đảm bảo rằng team kỹ thuật luôn làm việc với giá trị riêng biệt cho các khách hàng và không được lặp đi lặp lại những thứ giống nhau (ví dụ như dùng cùng mẫu widget cho UI, cùng dịch vụ, ….). Để đảm bảo các team tập trung vào việc đem lại giá trị cho khách hàng, hãy đầu tư vào việc xây dựng “con đường kỹ thuật hạnh phúc” cho team kỹ thuật – phương án này bao gồm việc tạo nên một mô hình chung như thư viện, dịch vụ và lựa chọn triển khai để lấy code trước mặt khách hàng nhanh nhất có thể.

Lời khuyên: Dùng phương án “con đường kỹ thuật hạnh phúc” sẽ giúp các kỹ sư của bạn đứng trên đôi vai của những gã khổng lồ thay vì phải xây dựng mọi thứ từ đầu mỗi khi họ nghĩ ra ý tưởng sản phẩm mới. Dùng những thông tin có sẵn từ trước giúp họ thao tác nhanh gọn hơn.

Mỗi lần chỉ tìm ra một lỗi sai

Tình hình thực tế của những môi trường phần mềm phức tạp tăng trưởng không ngừng ngày nay đó là các lỗi hệ thống và hư hại phần mềm là điều gần như không thể tránh khỏi, và không phải lúc nào chúng cũng là điều tệ hại nhất. Thực tế, đôi khi chúng không xấu tí nào. Có những thứ còn tệ hơn có thể ảnh hưởng bất lợi tới những giá trị quan trọng nhất: mâu thuẫn các phòng ban trong tổ chức, thiệt hại lâu dài sau một lỗi nào đó từ đầu, thiếu thời gian tìm lỗi và dữ liệu thiếu nhất quán.

Ít nhất là bạn biết mình đang đứng ở đâu và bạn vẫn có chuyện để làm. Mục tiêu tổng thể của việc sai sớm hơn và tốt hơn là dùng những lỗi không thể tránh khỏi này như chất xúc tác để đạt được thành công – học hỏi từ từng lỗi một khi bạn liên tục cải tiến phần mềm và doanh nghiệp của bạn.

Lời khuyên: Team lãnh đạo phải hiểu những mục tiêu dài hạn, mục đích của từng bộ phận và những sáng kiến then chốt của công ty trước khi đem thực tại chung xuống cấp độ team. Team lãnh đạo bên trên cần khích lệ lòng tin, trao quyền cho nhân viên, và đưa các quản lý ra khỏi tư tưởng “bộ phận của tôi”, thay vào đó là tư tưởng “tổ chức của tôi”. Phá bỏ mâu thuẫn giữa các bộ phận yêu cầu các quản lý team ủng hộ ý tưởng rằng nếu có một dòng chảy thông tin tự do thì toàn bộ tổ chức sẽ được lợi. Các kỹ thuật có thể giúp điều đó trở thành hiện thực bao gồm việc thiết lập mô hình mục tiêu và kết quả then chốt (OKR), tổ chức các buổi họp mặt toàn công ty, tập trung vào việc lên kế hoạch dài hạn nhanh chóng, và xây dựng các team đa chức năng.

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