Nhân dịp dự án của mình mới được giải “Best Project Of The Year” của công ty, ngày hôm nay mình xin phép trao đổi 1 chút kinh nghiệm và những bài học rút ra trong quá trình làm dự án. Mặc dù sản phẩm chưa release nhưng đến thời điểm này có thể coi là thành công do đảm bảo được tiêu chí kiên quyết là hoàn thành công việc, làm vừa lòng khách hàng, không OT, đảm bảo cho mọi người làm việc trong môi trường thoải mái.

1. Quản lý Change Request là yếu tố sống còn quyết định thành bại dự án

Ngày nay chúng ta ít làm việc với mô hình Waterfall, và hầu hết làm việc theo mô hình Agile, hoặc lai giữa Waterfall và Agile. Nói về Agile, chúng ta không thể quên nguyên tắc số 2

WELCOME CHANGING REQUIREMENTS, EVEN LATE IN DEVELOPMENT. AGILE PROCESSES HARNESS CHANGE FOR THE CUSTOMER’S COMPETITIVE ADVANTAGE.

Chúng ta luôn chào đón sự thay đổi trong specs. Tuy nhiên điều đó không có nghĩa là cứ thay đổi là làm. Quản lý Change Request là yếu tố quan trọng quyết định sống còn đến thành công của dự án. Mọi thay đổi của khách hàng, chúng ta nên chủ động trao đổi để làm rõ vấn đề, tại sao lại như vậy, hơn là chỉ biết tuân thủ làm theo. Những thay đổi tốn thời gian càng cần xem xét kỹ càng, bởi không phải đơn thuần là thêm effort là thêm cost, còn những hậu hoạ không lường trước được nếu chúng ta vội vàng chiều theo khách hàng.

Kinh nghiệm bản thân

Có 3 điều chúng tôi thực hiện xuyên suốt dự án khi làm việc với Change Request

1. Tất cả ticket về change request đều được gom lại bên dưới 1 ticket lớn để có cái nhìn tổng thể và dễ dàng thống kê estimate time. Bạn có thể có cách thực hiện khác, nhưng nguyên tắc là làm sao có thể nhìn thấy những thay đổi này nhanh nhất có thể.
2. Thái độ đầu tiên với change request, không phải là “ngoan ngoãn” vâng lời, mà bình tĩnh nghiên cứu, nghĩ đến những khó khăn lớn nhất có thể xảy ra để thương lượng với khách.
3. Tuyệt đối không vội vàng làm luôn. Kể cả khi thấy thay đổi đó là hợp lý thì cũng cần xem xét độ ưu tiên trước khi quyết định làm. Và điều may mắn là, có khá nhiều change request, sau 1-2 tuần chúng tôi chưa làm đến, khách đã tự reject. Thử tưởng tượng chúng ta làm luôn thì sẽ tốn công như thế nào.

2. Xây dựng quy trình là điều cực kỳ quan trọng

Quy trình là thứ không thể thiếu, đặc biệt là với các dự án lớn với cơ cấu con người đa dạng và specs phức tạp. Trước khi dự án tôi bắt đầu, tôi có khoảng 1 tháng để nghiên cứu specs lên plan và xây dựng quy trình cho toàn dự án.

Quy trình quản lý ticket trên Redmine, quy trình review code, quy trình deploy, quy trình Q&A,… cho đến quy trình thêm 1 người mới vào dự án đều được lên sẵn để đảm bảo mọi thứ được vận hành trơn tru.

Giai đoạn lên plan, lên quy trình thường bị xem nhẹ và chính nó gây ra hậu quả khôn lường về sau. Chúng ta chỉ mải làm và nghĩ rằng làm càng sớm càng tốt, trong khi dưới góc độ nhà quản lý và đặc biệt quản lý hệ thống lớn, việc xây dựng quy trình mới thực sự quan trọng. Làm sớm đôi khi chỉ dẫn đến đập đi làm lại sớm, trong khi 1 quy trình tốt sẽ giúp hạn chế những rủi ro của con người.

Con người sinh ra không ai không có khuyết điểm, công việc của con người không lúc nào hoàn thiện tuyệt đối, chính vì vậy quy trình sinh ra để hạn chế sai sót của con người!

Tôi chia sẻ với các bạn hình trên đây là 1 quy trình của chúng tôi, quy trình Q&A. Bạn có thể thấy người trực tiếp tham dự vào quá trình Q&A là Questioner (Dev hoặc QA) và BrSE. Nhưng người cập nhật specs lại là 1 người trung gian, Comtor. Tại sao lại vậy?

Thứ nhất, chúng tôi luôn cập nhật specs, để chắc chắn specs luôn up-to-date. Đã có dự án tôi làm, mọi người lội cả trăm dòng của file Q&A chỉ để confirm 1 dòng specs nhỏ. Do vậy tại dự án này, chúng tôi chú trọng việc cập nhật specs để chắc chắn nó luôn up-to-date và mọi người có thể cùng theo dõi.

Thứ hai, chúng tôi chọn ra 1 người trung gian với quá trình Q&A để cập nhật specs. Ở đây là comtor. Điều đó đảm bảo 1 người thứ 3 khi đọc file Q&A cũng hiểu vấn đề đang trao đổi là gì và khi cập nhật thì có cái nhìn khách quan, khiến ai cũng có thể hiểu vấn đề.

Còn nhiều quy trình khác trong dự án, tuy nhiên cá nhân tôi thấy nó vẫn chưa thực sự hoàn thiện và trong sự nghiệp của mình, tôi sẽ cố gắng tìm hiểu để hoàn thiện nó hơn.

3. Nói không với OT

Nguyên tắc thứ 8 trong 12 nguyên tắc của Agile đề cập đến vấn đề này

AGILE PROCESSES PROMOTE SUSTAINABLE DEVELOPMENT. THE SPONSORS, DEVELOPERS, AND USERS SHOULD BE ABLE TO MAINTAIN A CONSTANT PACE INDEFINITELY.

Rõ ràng, chúng ta cần một môi trường làm việc thoải mái và bền vững cho các thành viên, để họ có thể thực hiện “trường kỳ kháng chiến” chứ không phải “trường kỳ OT”. Việc OT gây ra rất nhiều hậu quả xấu, ảnh hưởng đến sức khoẻ và tinh thần của các thành viên. Và với toàn dự án, là ảnh hưởng đến hiệu suất công việc. Không phải cứ OT, làm thêm giờ là tốt. Hãy nhớ lại xem loài người đã phải đấu tranh như thế nào để có 8 tiếng làm việc một ngày còn lại là nghỉ ngơi. Việc làm quá nhiều thường không đem lại hiệu quả như số lượng thời gian đem lại.

Vậy hãy thử tìm hiểu xem tại sao chúng ta OT.

1. Vì chúng ta estimate sai, dẫn đến phải làm thêm giờ để sửa sai.
2. Vì chúng ta muốn thể hiện với khách hàng. Cố gắng làm cho nhanh, có Change Request là sửa thật nhanh để gây ấn tượng.
3. Vì khả năng của chúng ta có hạn, estimate tương đối đúng với 1 số người, nhưng đôi khi team “tạ” quá không đỡ nổi.
4. Khách ép tiến độ, bắt phải xong trong một khoảng thời gian nhất định.

Có rất nhiều nhiều nguyên nhân OT và tôi liệt kê ở đây 1 vài nguyên nhân tôi hay gặp nhất trong công ty.

Nguyên nhân số 1 và 3 mang tính chủ quan thuộc về cá nhân chúng ta. Tuy nhiên việc estimate không chính xác hoàn toàn có thể thương lượng với khách, nếu chúng ta giải thích cho họ vấn đề phát sinh (ví dụ dự án của tôi là khó khăn khi làm việc với thư viện của bên thứ 3). Nguyên nhân chủ quan khác về mặt con người thì đúng là chúng ta phải tự sửa. Nên nhớ là man-month không thể thay thế cho nhau, không phải cứ member trình độ kém làm chậm là thêm người vào, chúng ta cần tìm hiểu rõ năng lực của member qua đó có cách thức phân chia task, training và điều chính tiến độ phù hợp.

Nguyên nhân số 2 hoàn toàn đến từ phía chúng ta. Nên nhớ rằng bạn càng làm được nhiều thì bạn càng phải làm nhiều, bạn đáp ứng Change Request càng nhanh thì khách càng có lắm Change Request. Không phải mọi thay đổi đều cần thiết nhưng mọi thay đổi đều tốn thời gian, do vậy 1 lần nữa, hãy xem xét kỹ điều này.

Nguyên nhân số 4 là trong 1 vài hoàn cảnh có thể thương lượng được, 1 vài hoàn cảnh thì không. Về căn bản thì sẽ tuỳ tình hình dự án và cá nhân tôi không có nhiều bình luận. Tuy nhiên tôi chắc chắn 1 điều là OT triền miên chỉ gây mệt mỏi và giảm hiệu suất công việc.

Ở một góc độ chủ quan khác, OT thuộc về mindset của từng người. Khi một người có tư tưởng OT, họ sẽ chuẩn bị tinh thần OT, dẫn đến lơ là trong giờ làm việc, đi làm muộn hơn vì …đằng nào tối chả OT. Nhân rộng ra, OT hay không là mind set của dự án. Nếu PM cứ muốn OT thì member khó lòng nghe. Nếu BrSE thích OT thì cuối giờ cứ ép anh em phải làm rồi cũng lại dẫn đến OT. Nếu member thích OT thì trong giờ đi trà đá, lướt Facebook, rồi tối lại OT, quản lý cũng rất mệt mỏi,…

Do vậy, tư tưởng không OT cần được truyền đạt và thông suốt trong toàn dự án. Có thể mới tạo ra 1 tập thể đoàn kết và làm việc có hiệu quả.

4. Hãy quản lý cơ sở dữ liệu thật chặt chẽ

Đây là một vấn đề mang nặng tính kỹ thuật và thường không được nhắc đến khi nói chuyện ở mức độ quản lý. Tuy nhiên, tin tôi đi, nếu làm tốt nó thì bạn sẽ cảm giác rất an tâm dù cho đã phó thác dự án của mình cho hơn 40 con người ở đủ các level khác nhau.

Bạn đã bao giờ gặp trường hợp 2 người làm 2 màn hình khác nhau, nhưng có 1 số trường liên quan đến nhau. Cập nhật ở màn hình này lại không thấy cập nhật ở màn hình kia. Chỉ vì do 2 người khác nhau và làm với 2 dữ liệu khác nhau trong DB.

Hay bạn có bao giờ gặp trường hợp 1 người chỉ xoá hoặc đổi tên 1 trường trong bảng liên quan đến màn hình của mình, để rồi làm die màn hình của người khác chưa?

Hoặc một ngày đẹp trời bạn mở DB ra, và thấy sao lắm trường tên lạ hoắc thế, hay có 2 trường mà tên chỉ khác nhau một chữ “s” =))

Tất cả đều đến từ sự không nhất quán của DB do quản lý lỏng lẻo. Nếu làm việc dự án nhỏ, bạn sẽ chỉ thấy 1,2 người thay đổi DB nên bạn sẽ thấy DB quá đơn giản. Nhưng với những cơ sở dữ liệu hàng trăm bảng, do 3-4 team quản lý thì sao? Thường là họ chỉ quan tâm đến chức năng mình làm (mà xét cho cùng khó mà bắt 1 dev hiểu toàn bộ hệ thống 40 con người làm), không quan tâm đến việc người khác làm. Việc đặt tên bảng tuỳ tiện thiếu thống nhất hay đặt trên trường khó hiểu rất dễ xảy ra gây khó khăn cho giai đoạn phát triển về sau.

Do vậy, lời khuyên của tôi là nên có 1 người hiểu specs toàn dự án và quản lý DB toàn dự án. BrSE là người phù hợp nhất, tuy nhiên nếu BrSE không có kiến thức tốt về cơ sở dữ liệu, có thể nên giao cho 1 leader phụ trách, với đảm bảo là người này hiệu specs toàn dự án.

Mọi hệ thống, dù to đến mấy thì gói gọn lại là quá trình data in, data out. Do vậy việc quản lý cơ sở dữ liệu tốt sẽ giúp giảm thiểu rất nhiều sai sót, đặc biệt là về business hệ thống.

Ở dự án của tôi, BrSE quản lý toàn bộ DB, mọi thêm sửa xoá đều thông qua BrSE. Khi xoá 1 cột hoặc thay đổi cấu trúc 1 bảng, BrSE sẽ xác định nó ảnh hưởng của thay đổi đó lên các chức năng, các màn hình nào, qua đó sẽ có các chỉnh sửa phù hợp đến từng team một.

5. Vấn đề quản lý con người luôn rất đau đầu

Quản lý con người là một vấn đề hết sức nan giải. Điều đáng lo hơn là dù bạn có cố xây dựng một quy trình tốt, nhưng nếu những con người trong đó không thực sự “happy” thì bạn có cố mấy cũng vậy. Tôi chú trọng ở đây là quản lý các mối quan hệ, và cụ thể là giữa Developer và QA.

1 tháng đầu dự án của tôi chìm trong căng thẳng, khi QA và dev không có tiếng nói chung. Chủ yếu là vì mọi người còn chưa có kinh nghiệm, cách trao đổi đôi khi hơi quá gay gắt hoặc bất lịch sự.

Developer cho rằng QA cố gắng bới móc sai lầm của họ. QA cho rằng developer không tôn trọng công việc của họ. Sự căng thẳng tiếp diễn khi những cái đầu không tìm được tiếng nói chung.

Công việc của những người có kinh nghiệm trong dự án là đứng ra hoà giải, phân định đúng sai. Nhưng chúng ta cần mềm dẻo và tỉnh táo, nên xác định được cái cuối cùng chúng ta cần làm là giải quyết vấn đề của specs, của bug, chứ không phải đi bới móc sai lầm của người khác.