20/07/2020
Làm sao để handover dự án ?
Cách đây ít tháng mình chuyển việc, nhắc tới chuyển việc mình nợ các bạn 1 bài về chủ đề “làm sao để nhảy việc ở Nhật”. Vừa vào chân ướt chân ráo đã được (bị) hù là cho ướt cả … 3 chân. Mấy tháng rồi mình không viết bài được cũng vì vụ này, vừa phải làm quen môi trường – đồng nghiệp – sếp – dự án – qui trình … tất cả đều mới toanh. Cho đến thời điểm hiện tại mọi thứ có vẻ khá hơn 1 chút, “lửa” bắt đầu nhỏ dần và đoàn tàu tiếp tục lăn bánh, đích còn xa nhưng bản thân mình đã kịp ngồi chung vs anh em trên cùng 1 toa, giờ là thời điểm nhìn lại, đánh giá và tự nghĩ ra giải pháp cho giai đoạn tiếp theo – mà các bác nhật hay gọi là furikaeri(振り返り).
Giải thích sơ sơ về handover cho các mem còn sinh ziên. Tiếng nhật là hikitsugi 引き継ぎ, tiếng việt là … gắp lửa bỏ tay người … ah mà chả biết tiếng việt gọi là gì. Đại khái có 1 mem đang làm thì nghỉ – có lý do chính đáng hoặc không, nói chung là ko còn tiếp tục, sẽ có 1 khoảng thời gian để truyền đạt nội dung công việc cũng như các vấn đề mà dự án đang gặp phải cho người tiếp nhận (mình là người tiếp nhận trong hoàn cảnh này). Khoảng thời gian này dài hay ngắn cũng phụ thuộc nhiều yếu tố, nếu dài thì tốt, còn ko thì cũng phải chấp nhận chứ biết sao được.
Nội dung truyền đạt lại cũng thế, nếu ông nào kỹ tính thì đưa nhiều, ông nào vớ vẩn thì nói qua loa, còn những bạn có tâm thì ngoài nội dung công việc cần làm ra còn chỉ cho người sau biết chỗ này chỗ kia đang cháy to, chỗ nọ ngập nước. Đấy là về mặt công việc, còn mặt con người – nhân sự nữa, phải tính hết trong khoảng thời gian có hạn. Vậy phải làm răng, đang lúc căng mà cứ đòi đi nha sĩ hoài … Có mấy cái gạch đầu dòng bên dưới.
Về mặt công việc
Phải lên danh sách những mục bắt buộc.
Cấu trúc source
Phần mình cần phải làm
Cây thư mục tài liệu : dự án tổ chức tốt thì có cây, còn ko thì thành 1 bãi … cũng phải lo hốt cho hết ? chia buồn
Arsenal
Danh sách những tài liệu bắt buộc phải đọc (trong 1 mớ hỗn độn phải chỉ ra chứ hem có thời gian nhai hết)
Account login system : có nhiều loại, cái này tuỳ dự án – công ty – khách.
Thể chế vận hành : có mấy bên tham gia, công ty nào, phụ trách cái gì. Mình làm gì trong đó.
Qui trình dự án : cái này nghe hơi to tát nhưng giải thích ra thì đó là luồng làm việc giữa các member. Xem thêm bài qui trình để biết chi tiết.
Scope dự án : kiểu như làm từ đâu tới đâu. Chứ ko phải nhảy vô cái hỏi linh tinh kiểu “anh ơi sao khách không gửi detail design sao em làm”, trong khi dự án làm từ khâu BD – DD – CODE – TEST.
Những qui tắc – qui định chung của dự án.
Trên đây là 9 mục tiêu biểu bắt buộc phải có, đối với mỗi mục phải đặt ra plan : ngày start, ngày end. Cộng với note tình hình vào. Ví dụ : Cấu trúc source, Plan ngày 20/10 start, Status : chưa tiến hành được, lý do : vợ PTL bắt ở nhà rửa bát – cấm đi làm ngày này, dự kiến : ngày 21 sẽ tiếp tục tiến hành … đại loại vậy. Share cho sếp vs các bên check thường xuyên, có chuyện gì các bác ấy còn nhảy vào can thiệp. Cái dở của anh em là hay nghĩ sếp cái gì cũng biết, thực ra ko nói sao biết được, sếp cũng là con người, cũng từ dev đi lên chứ có phải thánh đâu.
Về mặt con người
Để tâm cũng được mà không thì cũng … ko được. Tuỳ vào phong cách làm việc mỗi người mà đặt trọng tâm vào công việc hoặc quan hệ con người. Với BrSE thì cái sau quan trọng hơn nhé, Dev thì tập trung vào vế trước.
Cái này không hẳn là về tính cách mỗi người, ai mà hiểu cho hết được. Ý mình muốn nói là cách làm việc. Ví dụ ông khách A có tính hay quên, nếu người cũ đã quen thì mỗi việc sẽ nhắc 2 – 3 lần, người mới vào không biết cứ để task confirm nó trôi mấy tuần, trong khi dev – test ở nhà hóng dài cổ. Ông B thì có tính thích làm việc bằng Excel, cực ghét Word, mình đưa teian thì cũng chịu khó mà làm bằng Excel – coi như được approve 50% rồi. Ông C thì ghét họp, chỉ thích chat vs mail, anh em cũng lựa cách mà liên lạc sao cho tốt.
Đối với dev, mặt này ko cần quá chú tâm nhưng ko để ý thì cũng khó làm việc. Trước mắt khi vào tiếp nhận thì với tinh thần học hỏi trước, cho dù kỹ thuật có siêu đẳng đi chăng nữa thì cũng không thể ngày một ngày hai nắm hết được. Để nhanh chóng cần phải có sự giúp sức của anh em trong team, và anh em có chịu giúp mình hay không nó phụ thuộc vào thái độ đó. Anh em hay trêu nhau là “do ăn ở “. Ngẫm cũng có lý.
Về mặt tâm thế
Mặt này sẽ quyết định bạn có thể làm việc được với team hay không. Hãy nên nhớ 1 điều trước khi không có bạn tham gia thì dự án vẫn chạy, cho dù sau này không có bạn thì nó vẫn chạy được. Vậy nên đừng bao giờ coi mình là ngôi sao hay cái gì đó tương tự. Đừng nhảy vào chỉ trỏ bắt người này phải thế này, người kia phải thế kia.
Bạn nên nhớ cái gì tồn tại nó cũng đã có 1 quá khứ, cũng có 1 lý do riêng, ngay cả 1 cái file check list cũng vậy. Cả 1 câu chuyện dài nằm sâu trong đó. Trước khi muốn cải tiến thì phải tìm hiểu ngọn nghành từng Item, sau đó bàn bạc xin ý kiến rồi mới tiến hành, chứ bạ đâu làm đấy thì chỉ toàn cải lùi. Vô tình trở thành kẻ ngáng đường là rất không nên, còn cố tính làm vậy thì … ờ thì làm đi rồi biết ?
Kết lại:
Tiếp nhận dự án – handover cũng như chơi trò nhảy dây tập thể. Trước khi nhảy cùng team phải có khoảng thời gian quan sát, xem thử chu kỳ quay tay .. ah quay dây nhanh chậm ra sao rồi mới nhảy vào. Cứ nhắm mắt ào 1 phát mà ko để ý trước sau thì một là hại thân, hai là ngáng đường người khác. Bởi vậy nên lúc dự án cháy ko phải cứ thêm người vào là tốt, nhiều cái phát sinh từ việc handover ẩu sẽ làm cho mọi người dẫm chân nhau. Nếu team có vài người thì không cần bàn nhiều, nhưng lên tới vài chục, vài trăm người và kéo dài cả năm trường thì việc phải có 1 lộ trình handover cho tất cả các vị trí. BrSE cùng với PM sẽ phải vạch ra đường đi nước bước ngay từ đầu, tới khi có người ra người vào sẽ có đủ tài liệu cần thiết để trao lại chứ không phải lớ ngớ kiểu “tôi là ai, đây là đâu”.
——
Nguồn bài viết: BrSE
Biên tập: AMELA