Có nhiều LTV tỏ ra rất chuyên nghiệp trong buổi phỏng vấn, song tính chuyên nghiệp này không được duy trì những ngày sau đó khi họ làm việc trong tổ chức. Điều đó là không nên, hãy chuyên nghiệp trong mọi việc, kể cả sau khi chia tay.

Nếu bạn đã đến đúng giờ trong buổi phỏng vấn, tại sao không đúng giờ trong các hoạt động khác của công ty?

Nếu bạn đã ăn mặc rất chỉnh chu trong buổi phỏng vấn, tại sao không ăn mặc chỉnh chu trong các hoạt động quan trọng khác của công ty?

Nếu bạn đã tỏ ra mình là người thông minh, nhạy bén và chủ động trong buổi phỏng vấn, tại sao không thông minh, nhạy bén và chủ động trong từng công việc hàng ngày?

Nếu bạn gửi một thư cảm ơn sau buổi phỏng vấn, sao không tiếp tục gửi thư hay nói lời cảm ơn với đồng nghiệp mỗi khi họ giúp đỡ mình một công việc?

Nếu bạn thể hiện sự yêu mến tổ chức cũ, liên tục nhắc đến họ với sự biết ơn, sao không thể hiện sự yêu mến với tổ chức hiện tại?

Nếu bạn liên tục nói về tổ chức cũ với những điều không hay, sao không nhắc đến và tìm cách giải quyết những vấn đề trong tổ chức hiện tại?

Hàng loạt những điều nhỏ nhặt như trên mà tôi không thể kể hết. Nhỏ thôi, nhưng những hành động nhỏ thể hiện tính chuyên nghiệp của một LTV. Sau cùng, tổ chức nào cũng muốn thấy sự gắn kết của nhân viên vào tổ chức và tương lai của tổ chức. Bởi khi đội ngũ cho thấy sự gắn kết, các lãnh đạo dễ hơn trong việc vẽ ra và thực thi chiến lược phát triển.

Tôi quan sát thấy nhiều LTV, sau khi bắt đầu công việc ở tổ chức mới được một thời gian, vẫn mắc 2 sai lầm sau thông qua lời nói. Thứ nhất, vẫn sử dụng cụm từ “công ty em” để chỉ tổ chức cũ. Đây là điều thực sự tệ hại. Thứ hai, liên tục sử dụng câu “công ty cũ của em làm… (thế này)”. Bạn à, nếu công ty cũ của bạn thật sự vượt trội như vậy, tại sao bạn lại ở đây? Kể cả khi bạn nhắc về công ty cũ với những điểm đáng chê, đó là điều không hay. Bạn đã bao giờ hình dung việc mình liên tục nhắc về người yêu cũ trước mặt người yêu hiện tại? Điều đó không tốt chút nào, cho thấy mối quan hệ hiện tại cũng không có tương lai lâu dài.

Hãy thể hiện sự gắn kết với tổ chức hiện tại, ngay từ ngày đầu tiên tới những giờ phút cuối cùng. Chỉ đơn giản là sống hết mình cho từng công việc nhỏ hiện tại, không quan tâm tới quá khứ hay tương lai.

Tới đây, tôi muốn dành một phần để nói về sự chia tay – điều mà theo tôi quan sát, là rất không ổn trong giới CNTT. Nói chung, nếu sự việc kết thúc một mối quan hệ không xảy ra ổn thoả, trách nhiệm đến từ 2 phía. Song trong khuôn khổ của cuốn sách này, tôi muốn LTV làm tốt nhất về phía mình.

Có 3 kịch bản để mối quan hệ giữa LTV và tổ chức đi đến hồi kết.

Thứ nhất, LTV tìm được công việc mới. Đây là kịch bản hay xảy ra nhất, và kết quả của việc chia tay phụ thuộc nhiều vào LTV. Ngay sau khi nhận được thư mời làm việc từ công ty mới, LTV thông báo việc nghỉ với tổ chức hiện tại; thường là thông báo với quản lý trực tiếp. Quản lý trực tiếp sẽ tổ chức một buổi nói chuyện, tìm hiểu nguyên nhân và tìm cách giữ LTV ở lại nếu muốn – song điều này, theo kinh nghiệm của tôi, ít có khả năng thành công. Trong buổi nói chuyện này, LTV cũng đưa ra ngày mong muốn được chấm dứt hợp đồng – đây thường là ngày ngay trước ngày nhận công việc mới theo thư mời làm việc. Một điều rất kỳ lạ là các LTV luôn đưa ra mong muốn là “cuối tuần” hoặc “cuối tháng” với không một chút cân nhắc về các điều khoản trong hợp đồng (thường là thông báo trước 45 ngày) hay tình hình công việc hay dự án họ đang tham gia. Điều này đã được tôi đề cập tới trong phần Phỏng vấn; các tổ chức luôn muốn các LTV bắt đầu sớm. Nhưng tôi cho rằng, đây là trách nhiệm của các LTV, khi họ quá dễ dàng nhận lời khi con số về lương thưởng được đưa ra, phớt lờ những gì đang cam kết với tổ chức hiện tại. Điều này đẩy các tổ chức vào vòng xoáy tuyển dụng gấp nhân sự thay thế. Tự mình đưa ra con số “cuối tuần” hoặc “cuối tháng” thể hiện sự thiếu chuyên nghiệp của LTV, sự thiếu tôn trọng với tổ chức hiện tại. Điều đáng tiếc là việc này xảy ra quá thường xuyên, gần như tất cả những LTV nói chuyện với tôi về việc chấm dứt hợp đồng đều rơi vào mô-tuýp này. Một số LTV được tôi yêu cầu thực hiện đúng cam kết, không được rời đi trước 45 ngày; họ thể hiện thái độ không hợp tác – đây là điều không nên.

Thứ hai, cắt giảm hoặc sa thải. Cắt giảm là tình huống không hay nhưng dù sao cũng tốt hơn sa thải vì khi có nhiều cộng sự cùng cảnh ngộ, LTV thấy ít bị tổn thương hơn. Có nhiều lý do để một tổ chức đi đến quyết định cắt giảm nhân sự: thay đổi định hướng, tình hình tài chính,… Nhưng dù tình huống nào xảy ra, bạn cũng nên biết rằng tổ chức của mình đã làm việc rất chăm chỉ để đi tới quyết định; và những quản lý của bạn đã trải qua những thời khắc khó khăn khi quyết định ai đi ai ở. Tôi không thể nói đây là một trải nghiệm thú vị, song là một trải nghiệm hữu ích với mọi nhà quản lý; và có vẻ COVID-19 đã mang lại điều kiện tuyệt vời để nhiều nhà quản lý có trải nghiệm này. Là một LTV, bạn nên thông cảm và giúp đỡ họ. Thông cảm không có nghĩa là bạn chịu mọi thiệt thòi về bản thân mình. Mọi tổ chức “tử tế” khi thực hiện việc cắt giảm đều có ngân sách cho việc cắt giảm bao gồm: đền bù, hỗ trợ, đào tạo, trợ giúp, … Ở mức tối thiểu, bạn xứng đáng nhận được thông báo sớm trước 45 ngày hoặc khoản hỗ trợ tương đương 45 ngày lương. Nokia khi thực hiện đóng cửa một văn phòng, ngoài việc thông báo và hỗ trợ, họ còn tổ chức các khoá đào tạo cùng việc đôn đáo tìm kiếm những công việc mới giúp nhân viên. Ở Việt Nam, cũng có nhiều công ty như vậy. Tôi cho rằng, đây là cách làm tử tế và mọi doanh nghiệp đều nên như vậy. Nếu bạn không may mắn để có sự hỗ trợ này, đừng ngần ngại đòi hỏi sự minh bạch từ tổ chức về hiện trạng và kế hoạch cắt giảm; điều này không chỉ tốt cho bạn, mà còn tốt cho những người ở lại. Khi mọi thứ được minh bạch và tình hình của tổ chức không đủ tốt để có những khoản hỗ trợ này, hãy thông cảm cho tổ chức và tự tìm con đường khác. Sa thải (một cá nhân) thì phức tạp hơn, điều này thường đến từ việc LTV không đáp ứng được kỳ vọng của tổ chức. Theo luật lao động, tổ chức muốn sa thải một nhân viên phải chứng minh được nhân viên không đạt được hiệu quả làm việc như hai bên đã thống nhất. Khi tình huống này xảy ra, tôi mong bạn hiểu rằng chiếu theo luật lao động và xử lý vấn đề bằng kiện tụng là điều không nên. Nếu hiệu quả làm việc của bạn không tốt, hãy coi đó là một bài học và tiến lên; ngược lại, hãy coi rằng tổ chức không còn xứng đáng để bạn làm việc cùng và tìm một hướng đi mới.

Thứ ba, LTV nghỉ đơn giản vì họ … muốn nghỉ. Điều này cũng hay xảy ra. LTV chỉ đơn giản là không tìm thấy con đường của họ ở tổ chức hiện tại; hoặc họ cảm thấy mệt mỏi và muốn nghỉ ngơi một thời gian. Không sao cả, bạn hãy cởi mở và nói đúng những cảm nghĩ của mình. Tôi đánh giá cao những LTV như vậy, ít nhất họ không đẩy tổ chức vào tình thế khó xử như trường hợp đầu tiên.

Dù tình huống nào xảy ra, tôi cũng mong các LTV lưu tâm tới một số gợi ý sau để việc chia tay diễn ra êm đẹp:

  1. Tuyệt đối không được chỉ dùng email cho việc chấm dứt hợp đồng. Bạn có thể thông báo việc chấm dứt hợp đồng qua email nhưng nên có buổi nói chuyện với quản lý trực tiếp, sau đó, email về quyết định của mình. Đừng sử dụng email cho việc trao đổi qua lại hoặc thông tin theo kiểu “đã quyết định rồi… không còn gì để thảo luận…” khi quản lý trực tiếp muốn nói chuyện. 
  2. Nên rõ ràng về lý do bạn muốn ra đi, cũng như nơi bạn muốn tới. Đừng ngần ngại, đôi khi việc đó giúp ích cho tổ chức để có những thay đổi phù hợp hơn với những nhân sự ở lại; đôi khi quản lý trực tiếp cũng giúp bạn giải đáp những thắc mắc và giúp đỡ bạn trong việc định hướng tương lai.
  3. Hãy để người quản lý thông báo với tổ chức về quyết định của bạn, hoặc bạn tự thông báo vào một thời điểm người quản lý cho là phù hợp. Đừng tự quyết định và hành động mà không qua thảo luận.
  4. Trong quá trình làm việc còn lại, hãy chuyên nghiệp như bạn đã từng như vậy. Hãy làm việc như bình thường. Tuyệt đối không đề cập đến việc ra đi hay tổ chức mới, trừ khi việc đó có liên quan đến việc bàn giao.
  5. Hãy thu xếp công việc và bàn bạc với người quản lý trực tiếp về kế hoạch bàn giao công việc cho phù hợp. Đừng để người khác đánh giá rằng bạn đã để lại một “bãi rác”.
  6. Đến ngày chia tay, hãy nói lời chào qua email hoặc gặp mặt trực tiếp những cộng sự của mình. Ưu tiên gặp mặt trực tiếp và hãy nói lời cảm ơn. Các cộng sự của bạn chắc chắn sẽ hỏi chuyện nhiều về công việc sắp tới; hạn chế nói về nó, đừng để tổ chức hiểu nhầm rằng bạn sẽ lôi kéo những cộng sự của mình sang tổ chức mới.
  7. Bàn giao toàn bộ công việc cũng như tài khoản cá nhân. Dù không ai để ý, tự bạn phải xoá bỏ những thông tin này, không lưu trữ bất kỳ dữ liệu nào của tổ chức trừ khi được yêu cầu để hỗ trợ việc bàn giao.
  8. Từ đây, tổ chức hiện tại của bạn đã là “công ty cũ”. Tuyệt đối không nói xấu về công ty cũ.

Tôi luôn cho rằng có thể đánh giá một tổ chức là “tử tế” hay không thông qua cách họ chia tay nhân viên. Một LTV “tử tế” hay không cũng có thể được nhìn nhận theo cách này. Hãy chia tay trong êm đẹp bằng tất cả sự chân thành. Một ngày nào đó, có thể bạn sẽ muốn làm việc cùng tổ chức hiện tại. Hãy để lại những ấn tượng đẹp.

 302 total views,  7 views today

Đến đây, có một câu hỏi  cho mọi ngành nghề: làm vì đam mê hay vì tiền? Đây không phải là một câu hỏi riêng của nhân sự ngành CNTT, song ngành CNTT có những đặc trưng khiến câu hỏi này “hóc búa” hơn nhiều những ngành nghề khác. Bạn không khó để trả lời rằng anh bạn chạy Grab làm vì tiền hay vì đam mê – đa số người làm những công việc đó vì họ không có lựa chọn khác. Nhưng CNTT nói chung và lập trình nói riêng là câu chuyện khác: không ai lựa chọn làm LTV vì lập trình là lựa chọn duy nhất. Lập trình là nghề vất vả, có sự đòi hỏi và đào thải cao. Lập trình là nghề dễ gây “nghiện”. Lập trình là nghề, hiện nay, đang được chi trả cao. Ba yếu tố trên khiến câu hỏi làm vì đam mê hay vì tiền khó trả lời hơn nhiều với LTV. Tôi được hỏi câu này hàng chục lần khi tiếp xúc với các bạn sinh viên hoặc LTV mới vào nghề: theo anh, em nên làm vì đam mê hay vì tiền? Có quá nhiều sách báo và những người nổi tiếng khuyên các bạn theo đuổi đam mê; cũng có quá nhiều người nổi tiếng khác nói điều ngược lại.

Nếu có một lời khuyên rõ ràng cho LTV, tôi đã không đưa câu hỏi này vào phần Hiểu những thế lưỡng nan. Tôi chỉ có thể đưa ra một vài gợi ý.

Thứ nhất, nếu bạn thực sự yêu thích nghề lập trình, hãy yên tâm theo đuổi đam mê. Với nhu cầu lớn từ thị trường hiện nay, LTV có đam mê (và từ đó, dần hình thành kiến thức và kỹ năng tốt) luôn có cơ hội được trả lương cao và rất cao. Đây là điều thuận lợi mà gần như chỉ ngành CNTT có tại thời điểm này. Là một LTV có đam mê với nghề, bạn nên cảm thấy may mắn. Không một nghề nghiệp nào có sự đảm bảo chắc chắn về tiền bạc sẽ đi kèm đam mê nhưng CNTT thì có: LTV có đam mê được đảm bảo sống tốt thậm chí là sung túc, chỉ cần họ thực sự (là đắm chìm vào công việc bằng hành động) chứ không chỉ là thích (và không hành động gì).

Thứ hai, nếu bạn vẫn đang loay hoay với câu hỏi trên, hãy làm vì tiền. Tôi tin rằng những LTV có đủ đam mê đang được trả công xứng đáng, và họ không màng trả lời câu hỏi này. Tuy vậy, không có gì sai trái nếu bạn chọn nghề lập trình vì tiền. Tư duy làm vì tiền thậm chí cũng tốt vì giúp bạn chuyên nghiệp hơn: bạn lo sợ bị đào thải và vì thế, cập nhật công nghệ thường xuyên; bạn muốn được trả lương cao hơn và vì thế, hoàn thành công việc với chất lượng tốt hơn và nhanh hơn… Nỗi sợ hãi và mong muốn về vật chất nhiều khi là động lực tốt để con người phát triển. Phần lớn người Việt Nam, công dân của một nước nghèo đang phát triển, đang làm việc chăm chỉ vì sự ám ảnh nghèo đói từng đã trải qua. Điều đó không có gì sai trái, thậm chí đáng tự hào.

Tôi từng tổ chức một buổi họp nhóm, để từng thành viên chia sẻ thẳng thắn lý do họ gắn bó với công ty và làm việc trong nhóm. Có những LTV nói rằng, họ yêu thích công việc và sản phẩm này, họ học được rất nhiều, họ chấp nhận mức lương thấp hơn nhiều lời đề nghị từ những công ty khác. Có những LTV thể hiện rõ quan điểm rằng họ cần tiền để có khoản tích lũy cho mục đích xa hơn. Tôi đánh giá rất cao những LTV thẳng thắn và rõ ràng. Sau cùng, họ đều nhận được thành quả xứng đáng khi có hành xử chuyên nghiệp để đồng bộ được mục tiêu của cá nhân với mục tiêu của tổ chức.
Đáng ngại nhất là những LTV không rõ ràng trong câu trả lời cho câu hỏi làm vì đam mê hay vì tiền?. Họ không có đam mê và cũng không có nhu cầu có thêm tiền vì đang được xã hội trả công ở mức cao để có một cuộc sống “đủ tốt”. Họ ở đáy của kim tự tháp mà tôi đã đề cập, và cũng không có nhu cầu di chuyển dần lên đỉnh tháp. Không chỉ ảnh hưởng tới bản thân, họ cũng đẩy tổ chức của mình vào thế khó xử.

 274 total views,  28 views today

Ngày nghỉ cafe thảo luận, tôi cho rằng thế giới Agile đang ngày càng phức tạp. Phạm Anh Đới cũng đồng ý rằng, Agile đang bị bias – thành kiến: kẻ thích trở nên cuồng, người không thích trở thành căm ghét.

Bài viết dài, là tập hợp của các ý tưởng lộn xộn. Vì thế bạn có thể nhảy vào bất cứ đoạn nào cũng nhận được các thông tin riêng lẻ; thấy hay thì đọc tiếp, không nhất thiết phải đọc từ đầu.

Agile là gì (và không là gì)?

Tại chính thời điểm này, định nghĩa về Agile hoàn toàn không rõ ràng. Quay lại lịch sử, thuật ngữ này lần đầu tiên được giới thiệu là “Agile Software Development”, sau một cuộc hội thảo giữa 17 người là tác giả của một số phương pháp phát triển phần mềm hiện đại (có tên và không tên), 2001. Họ chia sẻ chung một số phương pháp, nguyên lý… và Manifesto for “Agile Software Development” ra đời với 4 điều trong Tuyên ngôn và 12 nguyên lý.

Vậy là Agile Software Development có định nghĩa từ hời điểm đó, nhưng không bị giới hạn. Sau này có một số phương pháp nữa ra đời, dựa trên những nguyên lý trên, đồng thời khái niệm Agile cũng dần được thay thế cho Agile Software Development và lan dần sang một số lĩnh vực khác. Định nghĩa này chưa bao giờ được “nâng cấp version” một cách chính thức bởi những tác giả cũ cũng như mới nên nó trở nên không rõ ràng.

Agile thế nào (và không thế nào)?

Nhìn lại 4 điều trong Tuyên ngôn và 12 nguyên lý, dễ nhận thấy là chúng khá chung và đúng. Điều này dễ hiểu vì tìm kiếm điểm chung của nhiều phương pháp cũng như đồng thuận của 17 người, đại diện cho 17 tư duy, quan điểm thì khó mà cụ thể được.

Thời điểm đó, Agile là tập hợp của các phương pháp phát triển phần mềm dựa trên sự kết hợp của phương pháp lặp và tăng trưởng. Lưu ý, tôi đang nói về phần “thể hiện” của các phương pháp, không phải “tư duy” (nguyên lý) phía sau.

Nhưng sau này, dựa trên nguyên lý, nhiều thứ khác được coi là Agile với nhưng thể hiện không giống như ban đầu. Người ta bắt đầu nói về no planning, no estimation, no Sprint,… đủ thứ. Một ví dụ là Kanban, nó chỉ có thể hiện phần tăng trưởng, không rõ ràng đề cập tới lặp nhưng vẫn nằm trong Agile.

Agile có gì (và không có gì)?

Lưu ý rằng Agile Software Development cũng phải dựa trên một số nguyên tắc về quản lý, cách tổ chức nói chung nhưng những thứ này không được định nghĩa rõ ràng. Điều này dẫn đến một số hiểu lầm khá tệ. Ví dụ như “self-organized team”“cross-functional team”, Agile sử dụng mà không sở hữu; vậy nên không thể hiểu chỉ Agile mới xây dựng những team như vậy. Hay như mô hình về team stage của Tuckman cũng không thuộc về Agile. Kỹ thuật 5Whys, Kaizen… cũng vậy. Đó là những công cụ để nhóm hay người quản lý nhóm thực hiện tiến hoá quy trình.

Tương tự, DevOps ra đời sau, và “có liên quan” tới Agile. Nhưng ngày nay, cách hiểu Agile quá lớn nên DevOps được hiểu như là “nằm trong”. Holacracy?

Trách nhiệm có lẽ thuộc về những nhà tư vấn, đào tạo không phân biệt rõ, gây ra những hiểu nhầm rằng “Agile là con đường duy nhất để đạt được những điều này”.

Agile hướng tới gì (và không hướng tới gì)?

Agile hướng tới giá trị (value oriented), không hướng quy trình (process oriented). Quy trình trong Agile cũng buộc phải thể hiện được giá trị mới có lý do để tồn tại. Để tìm được giá trị, bắt buộc phải trả lời câu hỏi “tại sao (why)?”. Để tìm được quy trình, câu hỏi là “thế nào (how)?”. Câu hỏi why khó hơn rất, rất nhiều câu hỏi how. Và thông thường, để trả lời được câu hỏi why, chúng ta cần dựa trên how đang tồn tại.

Rắc rối ở đây, các nhà tư vấn, huấn luyện hoặc quản lý mong muốn đưa how vào trước; và kỳ vọng thời gian sau tổ chức sẽ tự trả lời được câu hỏi why. Công bằng mà nói, cách làm này không sai, nhưng nếu why không dần được tổ chức nhận ra, họ vẫn cứ loay hoay trong how. Và vô tình, Agile trở thành process oriented. Dù vậy, các “process” trong các phương pháp Agile vẫn khá tinh giản (so với các mô hình phát triển phần mềm khác), nên các team đã có quy trình trước đó khi chuyển sang Agile vẫn thấy bình thường. Điều tệ hại là, hầu hết các team ngày nay đều không áp dụng một phương pháp nào trước đó cho tới khi thực hành Agile, họ bỗng thấy Agile “cồng kềnh” và trở nên căm ghét.

(Ví dụ, team trong Scrum là self-organized, thật khó tin là đưa 5, 7 con người vào một team và hy vọng self-organized được nên vẫn cần có một số quy tắc, quy trình cơ bản ban đầu; nếu team không có sự tiến hoá, sẽ trở thành process oriented).

Sau không trào “doing Agile”, giờ là phong trào “being Agile” – dù không dễ, tôi vẫn thấy nó thiết thực. Nhưng “go Agile” thì không. Tôi chẳng biết trông nó sẽ thế nào.

Agile phù hợp với gì (và không phù hợp với gì)?

Nên nhớ, Agile ra đời với “Agile Software Development” tức là để giải quyết bài toán của phát triển phần mềm. Scrum nói rõ nó phù hợp với các dự án / sản phẩm nằm trong miền “phức hợp và phức tạp tương đối” về yêu cầu và kỹ thuật – tức là các dự án / sản phẩm đơn giản (đã rõ ràng) hoặc quá phức tạp (VD: R&D, công nghệ quá cao…) cần được xem xét. Thế nào là đơn giản, phức tạp… phụ thuộc nhiều yếu tố: con người, trình độ, công cụ,… nên (ví dụ) Scrum có thể phù hợp với team này ở sản phẩm này nhưng không phù hợp với team khác ở chính sản phẩm đó.

Agile dựa trên giả định về việc “chào đón sự thay đổi” (welcome change, Scrum: adapt to change, XP: embrace change); tức là, mọi cá nhân trong tổ chức đều thống nhất rằng “thay đổi là điều được chấp nhận”. Tổ chức không đồng tình với sự thay đổi, không “chào đón” mà áp dụng Agile là sai từ gốc.

Hầu hết các phương pháp Agile đều dựa trên gỉa định “cá nhân có động lực làm việc” nên các tổ chức còn loay hoay trong việc này cũng nên cẩn trọng.

Nếu nhìn lại các câu hỏi đã được trả lời trên, Agile có thể giải quyết rất nhiều bài toán khác, không chỉ với việc phát triển phần mềm (trong Agile Y tôi còn nói tới cá nhân). Cùng với sự thống trị của các công ty công nghệ (mà lõi là sản phẩm phần mềm), Agile lan rộng sang những lĩnh vực khác, “nuốt chửng cả thế giới”. Cần lưu ý:

– Vì vậy Agile càng không rõ ràng.
– Các lĩnh vực khác không có chỉ dấu rõ ràng về hiệu quả vượt trội của Agile như trong phát triển phần mềm – nơi Agile ra đời do trải qua sự khủng hoảng về phương pháp.

hãy cẩn trọng.

Agile trở thành “thuốc chữa bách bệnh”.

Agile thực sử trở nên không rõ ràng. Cách hiểu gần nhất (của tôi) có thể là “Agile là công cụ (mindset, toolset) để tăng tính linh hoạt (agility) của tổ chức, qua đó thích ứng tốt với thay đổi (hoặc dẫn dắt thay đổi)”.

Và cho đến giờ này, đây có vẻ là “bệnh” rõ nhất của các doanh nghiệp; và với hổ lốn những thứ được gắn tag Agile, Agile có vẻ được kỳ vọng quá lớn để chữa bách bệnh.

Và khi không chữa được, đương nhiên Agile bị đổ lỗi.

Như trên, tôi cho rằng trách nhiệm nằm ở những nhà tư vấn, đào tạo Agile trong việc rạch ròi Agile là gì, và Agile trong phạm vi anh cung cấp dịch vụ là gì, nó thế nào, hướng tới đâu. Bằng cách vơ vét tất cả mọi thứ vào Agile cùng sự quảng cáo quá đà, gây ra sự ảo tưởng về sức mạnh từ tổ chức.

Agile trở thành “đạo”.

Agile dự trên pull-system, giả định “cá nhân có động lực làm việc”, điều này đi ngược với phần lớn cách tư duy về quản lý hiện có. Dù có hệ thống lý thuyết chặt chẽ đứng sau, Agile vẫn cần niềm tin để thực hiện trong tổ chức. Khi phương pháp cần tới “niềm tin” là điểm xuất phát thì nó không khác gì “đạo” – sẽ có kẻ sùng đạo và phản đạo.

Có fan và anti-fan là điều dễ hiểu.

Scrum đã làm tốt gì (và không làm tốt gì)?

Scrum thực sự tuyệt vời. Nó là một mô hình tuyệt vời với đủ sự tinh gọn, hiệu quả cho phép tổ chức “nhận diện vấn đề”. Đây là điều siêu quan trọng để phát triển sản phẩm cũng như phát triển tổ chức.

Scrum không làm việc giải quyết vấn đề. Vậy nên nếu nhóm không giải quyết những vấn đề được nhận diện, Scrum là đống rác cạnh hàng ăn. Nhưng có phương pháp nào giải quyết vấn đề không?

Scrum làm tốt trong việc ghi chú “Scrum dễ hiểu, khó làm chủ”.

Scrum (đúng hơn là các tổ chức cấp chứng chỉ Scrum (Master, Developer, PO)) làm không tốt trong việc đào tạo. Khá dễ dãi. Có 2 lỗ hổng lớn, khiến các ScrumMaster cầm chứng chỉ và nếu không chịu học hỏi thêm sẽ mắc phải:

1. Không trả lời được rõ ràng các câu hỏi trên. Cái gì thuộc Scrum, cái gì không? Dẫn đến ngộ nhận trong lỹ thuyết lẫn thực hành.

2. ScrumMaster không yêu cầu kiến thức về phát triển phần mềm. Về lý thuyết, điều này không sai; song thực tế thật khó để tham gia vào nhóm phát triển phần mềm mà không hiểu gì về cách nhóm thực hiện.

Từ đây dẫn tới những hệ luỵ vô cùng phức tạp. Chuyển giao cái gì? Technical debt là gì? Simple design là gì? Xử lý thế nào? Tài liệu thế nào là đủ?…

ScrumMaster yếu về chuyên môn (ngành) và non tay dẫn dắt nhóm có trình độ cao hơn mình sẽ là thảm hoạ. Đội bóng cần HLV tương xứng. Vấn đề là, tốc độ phát triển của thành viên Nhóm phát triển thường nhanh hơn (và khởi đầu tốt hơn) những ScrumMaster. Vậy nên nhiều nhóm phát triển bắt đầu chán ghét Scrum.

Trách nhiệm này thuộc một phần vào các tổ chức cấp chứng chỉ Scrum, phần lớn thuộc về các ScrumMaster khi không thể hiện được vai trò tương ứng, và cả các nhà đào tạo – không trang bị đủ hệ thống lý thuyết và thực hành.

Trách nhiệm của những nhà đào tạo, tư vấn?

Đừng trách sự tồn tại của những nhà đào tạo, tư vấn. Đừng trách những quảng cáo, khóa học. Đó là nhu cầu tất yếu, và thiết thực, bởi họ giúp rút ngắn con đường tổ chức tiếp cận Agile (nếu muốn). Nếu họ làm việc trên nguyên tắc cung cấp đúng giá trị và đạo đức.

Nhưng, đến lúc này, tôi cho rằng những nhà đào tạo, tư vấn cần phải có câu trả lời rõ ràng cho mình, cho khách hàng rằng với anh, Agile là gì (và không là gì), Agile (trong phạm vi đó) mang lại giá trị gì và lấy đi gì…?

Giống như bác sỹ, cần rõ ràng rằng những thành phần này là gì, tổ hợp lại được gọi tên gì, chữa bệnh gì, chống chỉ định gì, tác dụng phụ gì…?

Tuyệt nhiên không thể mông lung như Agile làm nhóm hạnh phúc hơn, Agile giúp tăng năng suất, Agile giúp tăng tốc độ hoàn thành dự án… – những điều Agile nguyên thuỷ không hề đề cập.

Những chuyện “nhỏ nhặt” khác:

Còn một mớ trao đổi khác. Cơ chán rồi. Có phản hồi mà rảnh thì viết tiếp, thế cho nó Agile.

 2,012 total views,  4 views today

Nhân chuyện được thanh niên đam mê khởi nghiệp chia sẻ về ý tưởng làm sản phẩm, viết qua về câu hỏi: khi nào bắt đầu? Hay là, khi nào thì có thể quyết định bắt tay vào làm một sản phẩm thương mại?

Làm sản phẩm thương mại là quá trình để kiểm chứng 3 giả định:

  1. Bài toán là có thật
  2. Khách hàng là có thật
  3. Thị trường là có thật

Sản phẩm phải xuất phát từ bài toán thực tế. Giả định đầu tiên cần kiểm chứng là “bài toán này có tồn tại thật không?” hay chỉ là cách diễn tả của một bài toán khác, hay đã được giải bằng một phương pháp khác…? Ví dụ, chúng ta có ý tưởng về sản phẩm thu thập câu hỏi trong các buổi hội thảo, thì cần phải trả lời: bài toán đó của ai, người tổ chức sự kiện hay người tham dự…? vấn đề họ gặp phải là gì, số lượng hay chất lượng câu hỏi…? Cần nhớ, người dùng cuối không luôn đồng nghĩa với người có bài toán cần giải; cần tìm đúng người để interview về bài toán của họ.

Sản phẩm thương mại phải có khách hàng. Giả định tiếp theo cần kiểm chứng là “khách hàng có tồn tại thật không?”. Có ai sẵn sàng bỏ tiền (hoặc có thể chuyển đổi ra tiền) để sử dụng sản phẩm như một giải pháp giải quyết bài toán của họ không? Mà tốt nhất là bỏ từ “sẵn sàng” đi, thấy tiền vào tài khoản rồi mới kiểm chứng được giả định này. Có thể bài toán của khách hàng là có thật, song nó không đủ lớn để họ đổi tiền lấy sản phẩm; hay nói cách khác, ROI không đủ tốt thì cũng hỏng. Đặc tính của sản phẩm thương mại là phải có khách hàng chịu trả tiền nên kiểm chứng giả định này phải qua bán hàng. Bán hàng có bao giờ dễ?

Sản phẩm thương mại phải sống được. Giả định tiếp theo cần kiểm chứng là “thị trường có tồn tại thật không” hay chỉ một vài bài toán riêng rẽ của khách hàng đơn lẻ…? Có bao nhiêu khách hàng tiềm năng? Dung lượng thị trường ra sao? Sản phẩm muốn sống lâu dài đương nhiên ROI phải dương; chi phí phát triển, marketing, bán hàng… tựu chung là invest đã xác định, dung lượng thị trường có đủ mang lại return để ROI dương không? Có thể bài toán của khách hàng là có thật, có khách hàng chịu trả tiền thật, song số lượng quá bé để có ROI dương thì cũng hỏng. Kiểm chứng giả định này rất khó, có tới 42% trong số các startup fail là do thị trường không tồn tại hoặc 29% do không đủ tiền để hình thành thị trường.

Vậy khi nào thì nên bắt tay vào làm sản phẩm thương mại?

Là khi đã trả lời thật cẩn thận câu hỏi “tại sao không nên làm (sản phẩm này)?”. Thường thì chúng ta quá dễ dàng tìm được lý do để làm một sản phẩm: interview vài người, thấy một vài bài toán… Nhưng như trên, họ có thực sự chịu trả tiền cho sản phẩm không? Có nhiều người sẽ trả tiền giống họ không?

Đấy là lý do chúng ta phải trả lời câu hỏi “tại sao sản phẩm này không nên tồn tại?”, “tại sao sản phẩm này không cần tồn tại?”, “tại sao không ai làm sản phẩm này?”, “tại sao mình không nên làm sản phẩm này?”… Cứ sau mỗi lý do được đưa ra, là một lần thì trường bị bóp nhỏ lại. Khi tất cả các lý do được đưa ra, rất cẩn trọng, mà thị trường vẫn còn đủ lớn (ROI), thì đấy là lúc sớm nhất để có thể nói “yes, bắt đầu thôi.”

 1,661 total views,  6 views today

Đánh dấu một chặng đường, ghi lại vài dòng kỷ niệm.

Chiều 9/5/2013, tôi gặp Mikkel tại sân bóng, “tìm hiểu” nhau độ 30 phút trên đường đi bộ từ sân bóng ra quán bia. Mikkel nói chuyện về sản phẩm, công ty, mong muốn mở văn phòng development tại Việt Nam sau một số trải nghiệm không tốt với Ấn Độ. Tôi hỏi Mikkel “chắc chắn sẽ không mở văn phòng development tại Trung Quốc?”, Mikkel trả lời “không bao giờ”. Vậy là đủ để tôi tạm đồng ý trên quan điểm, cũng vừa khi tới quán bia hơi. Hai bên tập trung nhậu thêm 30 phút nữa cùng đội bóng, nói thêm dăm ba câu chuẩn bị cho cuộc gặp tiếp theo vào sáng hôm sau.

Sáng 10/5, tôi chạy xe qua khách sạn Mikkel ở, cùng đi bộ tới một nhà hàng gần đó để dùng bữa sáng. Hai bên chỉ đơn giản có những điểm chung: dùng iPhone, dùng Macbook để code .NET (đều dùng Thinkpad trước đó, chuyển sang Macbook vì có thêm project về iOS; với Mikkel chính là app Planday) – đủ vui để bắt đầu câu chuyện. Sản phẩm đâu? Source code đâu? Định hướng ra sao?… được trao đổi sau khi cả 2 gọi món. Món lên, thảo luận xong, chuyển sang chuyện phiếm. Ăn xong, cả hai gọi cafe và cùng thảo luận về bước tiếp theo. Mikkel nói đã gửi CV của tôi cho những cộng sự ở CPH, tất cả đều hài lòng; tôi chỉ ra một số lỗi nhỏ trên website và sản phẩm Planday nhận ra khi tìm hiểu về Planday tối hôm trước.

9:00 giờ gặp, 10:30 chia tay. Chốt. Tôi đã nhận lịch dạy của học kỳ tới nên sẽ chờ tới khi xong việc ở ĐH FPT sẽ bắt đầu làm việc tại Planday. Mikkel nhờ một công ty của bạn tại Việt Nam chuẩn bị hợp đồng. 23/5 ký hợp đồng. 15/7 chính thức làm việc.

Cả hai gần như bộc lộ cách làm việc của mình và hiểu cách làm việc của nhau ngay trong lần gặp đầu tiên: vui vẻ nhưng nhanh gọn, không rào đón nhưng đủ cẩn trọng (làm rất nhiều việc background, tìm hiểu trước; gặp gỡ chỉ tập trung trao đổi để quyết định nhanh). Hai người sau đó vẫn giữ cách thức này để làm việc với nhau trong gần 4 năm; mỗi năm Mikkel sang Việt Nam 1-2 lần, hầu hết các quyết định được đưa ra trên đường đi taxi từ sân bay về văn phòng; hoặc khi Mikkel rời văn phòng vào buổi chiều, hỏi “Hiển, có muốn ra ngoài hút thuốc không?” – tôi tiễn Mikkel ra ngõ, vừa đi vừa hút thuốc, khi thuốc tàn cũng là lúc Mikkel bắt được taxi, thảo luận xong. Thời gian còn lại để làm việc, giao lưu với những cộng sự ít gặp. Những lần tôi làm việc tại HQ cũng không khác. Làm ra làm, chơi ra chơi.

5 năm cùng Planday là thời gian đáng nhớ: thời gian “sóng gió” khiến tôi thay đổi cả về con người, cuộc sống, công việc; và cả gia đình – tất cả đồng điệu và phù hợp tới kỳ lạ. 5 năm chứng kiến startup đi từ siêu nhỏ tới series B; góp tay vào một nơi đi từ nhỏ như gara tới văn phòng thứ 3 đẹp đẽ. 5 năm đã cho tôi rất nhiều bài học. Một số trong đó là:

Winner takes all? Lúc nào cũng có bài toán để giải.

5 năm trước, Planday nằm trong số những công ty tăng trưởng ấn tượng nhất Đan Mạch, song vẫn không có gì đáng kể – một doanh nghiệp tăng trưởng 100% từ 100 khách hàng khác hẳn doanh nghiệp tăng trưởng 100% với 10.000 khách hàng. Với tư cách là sản phẩm nhỏ, ít người dùng, Planday mất nhiều chi phí liên hệ và phát triển để tích hợp với những hệ thống khác. Tại Việt Nam, Planday là con số không: không văn phòng, không công ty; với chẳng tư cách gì cả, kiếm người đồng hành cũng khó khăn.

Giờ, Planday vẫn nằm trong số những công ty tăng trưởng ấn tượng nhất Đan Mạch, với quy mô khác biệt và thu hút những ánh nhìn đầu tư toàn cầu. Với tư cách sản phẩm có nhiều người dùng, các sản phẩm khác cũng bắt đầu muốn được tích hợp vào hệ sinh thái. Tại Việt Nam, Planday đã có văn phòng, có tư cách pháp nhân, những cộng sự tiềm năng cũng không còn ngây ngô “công ty này làm gì?” trong lần đầu gặp mặt.

5 năm trước là bộn bề công việc. Giờ, mọi chuyện có trở nên dễ dàng? Vẫn bộn bề công việc… khác.

Khi Planday bắt đầu với những khách hàng đầu tiên tại Copenhagen, tất nhiên là không dễ dàng, Mikkel làm tất cả mọi công việc: phát triển, chăm sóc khách hàng, thu tiền… Sau khi phủ được một phần thị trường, việc bán hàng dễ dàng đến kỳ lạ, “Nửa nhà hàng ở Copenhagen đã dùng Planday rồi, bạn muốn đi sau không?”; thì có bài toán khác: giới hạn thị trường. Muốn mở rộng thì phải đi ra những thị trường mới, lại bắt đầu lại nhưng không thể giống cách cũ: chọn thị trường nào? chọn ngành nào?… Giải xong phần nào thì đến bài toán mới: đi cùng ai? chọn nhà đầu tư nào để phát triển hết tiềm năng?

Khi Planday bắt đầu với những công việc tại Việt Nam, tôi phụ trách nhiều việc: phát triển, tuyển dụng, văn phòng… Sau khi có những cộng sự, những dòng code đầu tiên, việc phát triển thêm một tính năng hay tuyển thêm một cộng sự  mới không còn tốn nhiều thời gian như trước thì có bài toán khác: làm sao để các nhóm làm việc hiệu quả ở quy mô lớn hơn? Giải xong phần nào thì đến bài toán mới: làm sao duy trì sáng tạo? làm sao để các thành viên phát triển hết tiềm năng?

Winner takes all. Winner là ai? All là cái gì? Startup dù có là unicorn thì vẫn chẳng hiểu là nên tranh đấu với ai ngoài chính mình của ngày hôm qua. Winner là kẻ chiến thắng được chính mình do giải quyết được bài toán của ngày hôm qua và được luôn bài toán của ngày hôm nay – all.

Chừng nào còn đi được, còn được giải những bài toán mới là còn mừng. Giải mãi một bài toán là thất bại.

Thực sự không có gì? Chăm chỉ, tập trung và niềm tin thì sao?

Tôi vẫn hay nói đùa “Các ông startup ở Việt Nam có nghề dự event hay quan hệ cộng đồng à? Sao không thấy tập trung làm sản phẩm, toàn thấy lang thang chém gió ở các event và tương tác Facebook?”. Nói là vậy nhưng cũng không thể phủ nhận rằng đấy là việc nên làm.

5 năm trước, Planday tại Việt Nam có gì? Không văn phòng, không tư cách pháp nhân, không bánh vẽ… chỉ có một ít… tiền và chút uy tín cá nhân. 3 năm là khoảng thời gian tôi phải giải thích cho các ứng viên rằng “Nếu bạn nhận được offer letter thì đừng ngạc nhiên vì nó được gửi từ bộ phận nhân sự của công ty R, mời bạn ký hợp đồng với công ty P nhưng bạn làm việc cho Planday” – giống công ty ma không? Nhưng thành lập doanh nghiệp thời điểm đó không phù hợp vì khiến bộ máy phức tạp và kéo theo hàng loạt những công việc khác cùng khoản tiền ký quỹ lớn của doanh nghiệp FDI. Tôi may mắn nhờ vả được người lo giúp những vấn đề về hồ sơ, pháp lý, kế toán… để tập trung vào việc xây dựng nhóm và sản phẩm. Nhưng như vậy là chưa đủ, làm sao để tìm kiếm cộng sự? Với quan hệ và uy tín cá nhân, tôi tìm được những cộng sự đầu tiên, những cộng sự tiếp theo không dễ dàng – và không thể phủ nhận Facebook hay event cũng giúp sức một phần. Điều khác biệt là tôi không thích chém gió, kết nối sáo rỗng; tôi xuất hiện tại sự kiện và trên Facebook để giới thiệu về một môi trường khoáng đạt, một sản phẩm chất lượng, một cách làm việc khoa học… tại Planday. Rất nhiều ứng viên sau đó tìm đến Planday sau khi đã tìm hiểu qua talk, Facebook hay blog cá nhân của tôi. Một thời gian, tôi và Planday tại Việt Nam gần như không có ranh giới đến mức nhiều người lầm tưởng rằng đây là công ty của tôi. Để làm tốt, luôn cần nỗ lực cao; để tự tin nói rằng mình làm tốt, luôn cần nỗ lực thêm một chút, tin thêm một chút.

Thời gian đầu là bộn bề của sản phẩm, kỹ thuật, văn phòng, tuyển dụng, xây dựng thương hiệu… đã giúp tôi học được rất nhiều; dẫn đường bằng niềm tin và đi qua từng ngày bằng chăm chỉ, tập trung vào từng thứ một. Tôi xa rời dần chuyện trà trưa, những cuộc nhậu vô bổ và tập trung hơn để làm việc. Sẽ luôn có những khoảng trống để chúng ta có thể phủ lấp chỉ bằng việc cố gắng thêm một chút, tập trung hơn một chút. May mắn là những cộng sự của tôi đều như vậy. Mikkel làm việc rất nhiều (so với chuẩn của người Đan Mạch), luôn nỗ lực giải quyết công việc trong ngày. 10 giờ tới, 4 giờ rời văn phòng không bao giờ đồng nghĩa với thời gian làm việc. Ngày làm việc luôn cần bắt đầu từ 8 giờ (thậm chí 6 giờ), kết thúc 11-1 giờ đêm và bất cứ thời gian nào không dành cho gia đình. Thời gian đầu, khi thông tin bị tập trung nhiều, tôi nói với mọi người rằng mọi email, message… đều được tôi đọc trong tối đa 2 giờ (thời gian tối đa tôi trong sân bóng – khoảng thời gian duy nhất không thể liên lạc).

Tôi nghĩ rằng, với những startup cứ kêu rằng họ chẳng có gì, thì đúng là họ không có gì thật. Những thứ cuối cùng là niềm tin, thời gian để tập trung, chăm chỉ làm thêm một việc nữa cũng đã bị đánh mất khi họ ngồi đó và phàn nàn.

Thay đổi thế giới, chiến lược lớn, tầm nhìn xa có thể là vitamin nhưng thực dưỡng hàng ngày của startup chính xác là get shit done – từng việc một.

Tìm được partner đúng gần như là tất cả.

Mikkel và board của Planday rất nhất quán áp dụng chính sách partnership. Đến một thị trường, địa phương mới, việc đầu tiên là tìm partner và phải tìm đúng partner sau đó uỷ thác dần công việc. Về bản chất, tất cả đều là nhân viên của Planday, đều có những chính sách như mọi nhân viên khác song mọi phát ngôn và hành động đều thể hiện một sự tôn trọng khác biệt. Planday và tôi luôn mong muốn mang những nhân viên lại gần nhau để không có bất kỳ sự khác biệt nào giữa các văn phòng. Song khác biệt văn hoá tại một tổ chức đa quốc gia luôn là điều cần được thừa nhận; và sẽ có những người làm công việc “cầu nối”. Văn hoá đi trước, công việc đi sau. Công việc sẽ gần như không thể chạy khi các bên chưa hiểu rõ những nét văn hoá của cộng sự. Hiểu văn hoá là nền tảng để hiểu con người nằm trong văn hoá đó. Có hiểu mới tôn trọng. Có tôn trọng mới làm việc được.

Tại Planday Việt Nam, tôi đóng vai trò “cầu nối”, đảm bảo những cộng sự mới phù hợp với văn hoá chung, hiểu đúng và tôn trọng những đồng nghiệp khác, ở văn phòng khác. Những việc này chưa bao giờ được đặt trong JD (mà tôi cũng chưa bao giờ có JD cụ thể), nhưng là việc phải làm. Tôi cũng thích công việc đó; nó đúng với mong muốn của tôi về việc xây dựng một môi trường Agile; nó hợp với Mikkel vì Mikkel chưa biết nên làm thế nào tại Đan Mạch. Lịch sử Planday chứng kiến không ít thất bại tại các thị trường, bản thân Mikkel cũng có trải nghiệm không tốt tại Ấn Độ nên mọi người đều hiểu rằng, quan trọng là tìm được đúng partner – người hiểu đúng văn hoá, đúng mục tiêu.

Mỗi lần nói chuyện không về công việc cụ thể, Mikkel thường hỏi tôi “Hiển, có hài lòng với công việc không?”, thường là 3 lần / năm. Suy nghĩ của Mikkel rất đơn giản “nhiệm vụ của tao là làm cho mày hài lòng, việc còn lại là của mày”. Khi muốn làm việc trực tiếp với một ai đó, nếu có cảm giác lạ, Mikkel đều cẩn thận hỏi xem nên làm thế nào.

Trong giai đoạn đầu tôi cũng rất may mắn tìm được những cộng sự tuyệt vời. Có người miệng nói là tay làm ngay, có người còn phân tích chán – nhưng thế kết hợp lại hay, vừa khéo nên code viết ra đẹp như mơ. Tôi cũng may mắn nhờ vả được một số công việc hành chính, nhân sự (đúng nghĩa là nhờ) tới những người mà mình chỉ cần nói là xong, chẳng cần làm gì thêm. Đến nay thì Planday Việt Nam cũng có gần 30 cộng sự tuyệt vời, đủ để tôi có thời gian đi ra ngoài, giao lưu, học hỏi. Nghĩ ra, thì Planday đi nhanh vì tìm được những partner đúng, và tôi làm được nhiều việc cũng vì có những partner đúng.

Quan trọng là đi với ai, lo gì không đi tới đâu.

Xây dựng đội ngũ: Tin tưởng và trao quyền là hành động, không phải bởi nói suông.

Trao quyền là thứ được người ta nói quá nhiều trong thời buổi ngày nay nhưng hành động thường không tương xứng với những lời đao to búa lớn. Mikkel, qua những hành động của mình, chính là người dạy tôi nhiều nhất những bài học về trao quyền. Khi Mikkel tin và trao quyền cho ai, Mikkel cho họ không gian gần như tuyệt đối để thực hiện. Tất nhiên, cho tới khi họ chứng minh rằng không đáng để tin nữa.

Dự án đầu tiên tôi thực hiện là migrate database và thực hiện một function lớn ảnh hưởng tới toàn bộ code base. Việc migrate DB với rất nhiều optimize vẫn cần không dưới 6 giờ. Sau 1 tháng, tôi nói với Mikkel “chúng ta cần khoảng 3 tuần nữa”; 2 tuần sau Mikkel hỏi “vẫn theo kế hoạch chứ?”, tôi trả lời “còn một chút nữa thôi là chúng ta có thể sẵn sàng”, Mikkel soạn email gửi cho toàn bộ khách hàng, thông báo rằng Planday sẽ bảo trì hệ thống và down time trong 12 giờ vào ngày đã đinh. Đó là lần down time lâu nhất trong 5 năm. Không cân nhắc, không xét đoán, không kiểm tra. Sẽ là hơi quá để nói business sẽ sụp đổ nếu việc migrate / deploy không thành công; song chắc chắn không khách hàng nào hài lòng khi hệ thống phải liên tục bảo trì. Mikkel rất đặc biệt, biết rất nhiều nhưng luôn cố dại khờ để đặt niềm tin vào một số người; và khi tin tưởng thì sẵn sàng đánh cược. Không tin tưởng, không trao quyền, không đánh cược, startup không thể đi nhanh. Đó là bài học lớn đầu tiên.

Thật ra Mikkel và tôi đều là tuýt người thích kiểm soát, luôn muốn đảm bảo mọi thứ được xảy ra theo cách nó-nên-vậy để tối thiểu rủi ro. Cả hai đều là những kẻ mơ mộng trong an toàn . Trong giai đoạn đầu, Mikkel kiểm soát rất nhiều, chỉ một số ít không nằm trong số đó. Sẽ rất tuyệt khi trao quyền cho một người có thói quen kiểm soát; sẽ là thảm hoạ khi trao quyền cho một người không thích hoặc không có khả năng kiểm soát. Đó là bài học lớn thứ hai.

Những người làm việc hiệu quả nhất với Mikkel và tôi là những người đủ khả năng kiểm soát, kiên trì đeo bám mục tiêu, luôn cập nhật thông tin và tìm kiếm tư vấn khi cần thiết; họ đương nhiên được quyền và chịu trách nhiệm trao quyền cho bất kỳ ai họ tin tưởng. May mắn cho tôi rằng ngay trong thời kỳ đầu, đã có những cộng sự tuyệt vời để có thể trao quyền; họ đủ say mê để muốn kiểm soát và đủ khả năng kiểm soát trong phạm vi của mình. Tôi thực sự, thực sự may mắn vì có được điều ấy. Về lý thuyết, đó là hệ quả của việc tôi kiên trì tìm kiếm những người phù hợp; song tôi phải thừa nhận rằng mình rất may mắn có được đủ những người phù hợp từ rất sớm và đúng thời điểm.

Lasse, một cộng sự thân thiết của tôi, cũng thuộc tuýt như vậy. Lần gọi điện đầu tiên giữa Lasse với cộng sự tại Hà Nội không thực sự suôn sẻ: “how are you?”, “I’m 30 years old”. Nhưng Lasse vẫn tin rằng “không sao đâu, sẽ ổn thôi”. Và mọi thứ ổn thật.

Tin tưởng, trao quyền và đừng quên plan B.

Xây dựng đội ngũ: Luôn có cơ hội với sự thật.

Trước đây tôi luôn thắc mắc startup, doanh nghiệp nhỏ làm sao tìm kiếm được cộng sự tốt? Không tương lai, không hình ảnh (cả thật và ảo), ít tiền… làm sao cạnh tranh trong tuyển dụng? Cho tới khi chính mình phải làm việc đó. Planday tại Việt Nam khởi đầu bằng việc ngồi chung với một văn phòng khác trước khi tồn tại 1.5 năm trong văn phòng rộng 14m2. Nhiều khi họp tôi xuống quán cafe. Phỏng vấn thì đưa ứng viên qua phòng họp mượn tạm. Và tất nhiên, chẳng nhiều ứng viên tốt nào hào hứng với việc tham gia một nhóm như vậy; họ đơn giản còn nhiều lựa chọn. Không phải có vì lịch sự không, tôi nhận được nhiều email từ chối theo kiểu “mình ấn tượng khi nói chuyện với Hiển, giá mà Hiển…”, rồi blah blah điền vào chỗ trống: ở công ty to hơn, có tương lai hơn, có cơ hội thăng tiến hơn, đề xuất mức lương cao hơn…

“Anh muốn cả đời đi bán nước đường hay cùng tôi thay đổi thế giới?” – xin lỗi, câu nói đó chỉ xuất hiện trong truyền thuyết, thế giới có mấy Steve Jobs? Tuy vậy, đấy vẫn là bài tuyển dụng kinh điển của startup và doanh nghiệp nhỏ nếu họ không muốn định vị mình thấp hơn, chấp nhận những ứng viên thấp hơn. Tôi là người thực tế và không giỏi vẽ bánh. Tôi gần như không bao giờ nói về tương lai quá xa của việc triệu đô, thay đổi thế giới, thăng chức… với những cộng sự tiềm năng. Tôi định vị Planday tại Việt Nam là một cơ hội học tập. Tôi luôn nhất mực khẳng định rằng đấy là lợi thế duy nhất của Planday so với những lựa chọn khác mà ứng viên đang có trong tay. Ở đây không có văn phòng đẹp nhất, và sẽ không bao giờ có văn phòng đẹp nhất; ở đây không có những chế độ tốt nhất, và mọi người vẫn phải tự đi mua đồ ăn khi hết bằng tiền của công ty; ở đây không có mức lương cao nhất thị trường. Nhưng ở đây chắc chắn sẽ là môi trường khoáng đạt nhất; ở đây sẽ là nơi có cách làm việc khoa học nhất; ở đây sẽ là nơi bạn có cơ hội tiệm cận đẳng cấp của developer trên thế giới. Và ở đây có một kho thông tin được transparent; để dù bạn ở đẳng cấp nào thì vẫn còn muôn vàn thứ có thể học được về cách một sản phẩm đi ra thế giới, cách cá nhân và một nhóm làm việc cùng nhau hiệu quả. Và chừng nào tôi còn ở đây, bạn luôn có ít nhất một cộng sự không ngừng học tập và chia sẻ. Ở đây không xây dựng cho bạn một sự nghiệp thẳng tiến lên những vai trò manager, nhưng bạn có rất nhiều không gian để phát triển chuyên môn, và nếu chịu khó học hỏi, bạn luôn có cơ hội đủ kỹ năng để tham gia hay làm manager của bất kỳ đội nhóm sản phẩm nào tại Việt Nam. Khi ứng viên lưỡng lự, tôi cho họ xem source code.

Tham gia Planday là chấp nhận rủi ro nhưng tham gia Planday bạn luôn sẵn sàng có khả năng đi tới bất kỳ nơi đâu. Tất cả là sự thật. Có một thời gian, việc tuyển dụng không tiến triển, nhiều cộng sự nói với tôi rằng “anh khó tính quá, mà không có bánh vẽ thì làm sao tuyển?” – nhưng tôi không thể nói về những thứ tôi không chắc như ngày mai, ngày kia… Tôi chỉ thấy vui vẻ khi nói sự thật và cộng sự của mình nói sự thật. Điều này làm chậm rất nhiều quá trình mở rộng nhưng nó đủ tốt để tạo sự tin tưởng với những người lựa chọn tham gia Planday. Mà đó mới thực sự là những người tôi cần quan tâm.

Planday tại Đan Mạch cũng vậy, giai đoạn đầu việc tuyển dụng cũng chẳng dễ dàng hơn, nhưng cũng từ sự thật, Mikkel tìm kiếm được những cộng sự rất chất lượng từ Skype, VISA…

Bây giờ, khi Planday có tiếng hơn, có văn phòng đẹp hơn, có nhiều chế độ hơn… có nhiều người chủ động tìm đến; tôi vẫn không muốn nói về ngày mai hay một tương lai quá xa (thực tế là chúng tôi cũng chẳng có những thứ đó), tôi vẫn muốn định vị Planday là một cơ hội học tập và phát triển bản thân.

Startup đừng nên vẽ mình hoành tráng quá đến mất cơ hội của sự thật. Quan trọng là sự thật đủ tốt.

Xây dựng đội ngũ: Con người là đầu tiên và cuối cùng.

Thực hiện công việc: con người là điều đầu tiên. Phân tích hậu quả: con người là điều cuối cùng.

Bài toán được phát hiện ra bởi con người, và cần giải quyết trước nhất bởi con người. Con người là điểm bắt đầu chứ không phải công cụ hay máy móc. Nếu có việc gì cần làm ngay, hãy thực hiện ngay, quy trình hay công cụ sẽ đi sau nếu việc đó lặp lại. Trước khi code, hãy ngồi nói chuyện với nhau. Cách thức, kiến trúc nào là tốt? Là cách thức, kiến trúc mà cả nhóm tự tin trong việc đảm bảo chất lượng. Có hàng tá những thứ khách hàng của Planday được hưởng lợi chỉ qua nỗ lực rất nhanh của cá nhân và hệ thống theo sau đó khi có khách hàng tiếp theo.

Khi phân tích những hậu quả, những điều bất ổn, con người luôn là yếu tố được xem xét sau cùng. Có điều gì không ổn? Quy trình có buộc chân chúng ta ở đâu không? Manager và Planday còn support được gì? Cần thay đổi gì?… “Có phù hợp với nhau không?” là câu cuối cùng tôi muốn nghĩ tới. Tôi có nhiều quyết định về nhân sự khiến cộng sự khó hiểu, một số chia tay ngay trong 1-2 tháng đầu tiên, một số chia tay sau một thời gian dài dù hiệu quả làm việc rất thấp. Tôi chỉ nhìn thấy thời điểm, đấy đúng là thời điểm tôi đã đủ dữ liệu để khẳng định đó thực sự là vấn đề “con người”. Có cộng sự tôi mất rất nhiều thời gian hàng ngày để học tiếng Anh cùng, cho họ giảm thời gian làm việc để tự học thêm, động viên, treo thưởng… nhưng thấy bạn bắt đầu thoả mãn và ngừng phát triển cũng là thời điểm chia tay. Với những người chủ động chia tay, tôi cũng sẽ tìm hiểu, nếu đó là vấn đề “con người” (cơ hội cho bản thân…), tôi sẽ không giúp họ thay đổi quyết định.

Đây là một trong những thay đổi rất lớn của cá nhân tôi trong 10 năm qua. Bản tính trời sinh là sự nghi kỵ con người, cho rằng mọi thứ xàm xí đều do con người mà ra (tôi nghĩ nhiều người giống tôi, thật khó nghĩ khác khi chúng ta sống trong môi trường này). Tôi đặc biệt biết ơn 4 năm làm việc tại Đại học FPT và 5 năm làm việc tại Planday – nơi cách ly tôi khỏi những thứ xàm xí để tập trung làm việc với những con người trong trắng, ngây thơ và văn minh. Khi ở ĐH FPT, đa phần tiếp xúc với giảng viên và sinh viên – chắc quay bài là lỗi lớn nhất. Khi ở Planday, thật khó để tìm thấy một người Bắc Âu nào không tử tế; văn phòng Việt Nam cũng vậy: “không nói xấu sau lưng” là nguyên tắc số 1. Tính cách của tôi dần được thay đổi. Giờ đây tôi rất ngại phải làm những thủ tục hành chính hay tham gia những đội nhóm “có vấn đề về con người”.

Nếu đã coi con người là tất cả, hãy để con người trải dài từ đầu tiên tới cuối cùng.

Linh hoạt hay là quan trọng: Chúng ta chẳng thể biết hết về ngày mai.

Tôi đương nhiên sẽ nói về linh hoạt. Tham gia vào một suốt một chặng đường chuyển mình của startup phát triển không chậm, không thể không nhận thấy cái giá của sự linh hoạt. Không linh hoạt là chết, có phải lời nói quá không?

Nguồn lực của startup không bao giờ đủ để làm những việc lãng phí và vô nghĩa nên chỉ có tập trung và linh hoạt là giải pháp. Chuyện có một khoản tiền nhỏ và phải cân nhắc nên mở văn phòng hay tuyển thêm người hay mua dịch vụ… là chuyện thường xuyên. Cân nhắc khi nào chịu, khi nào trả technical debts, product debts… là chuyện cần thiết. Nguyên chuyện packaging và pricing cũng rất vui: một thời gian sản phẩm được tách thành 2 gói, basic và advanced; một thời gian sau lại hợp lại làm một, bán một giá; một thời gian sau lại tách ra… Sản phẩm cũng vui: một thời gian dùng custom control, một thời gian sau dùng native control theo OS… Tích hợp cũng vui: một thời gian tích cực tích hợp; một thời gian cố gắng không phân mảnh; rồi lại tích cực tích hợp… Công nghệ cũng vui: một thời gian duy trì công nghệ đồng nhất; một thời gian chấp nhận phân mảnh; rồi lại đồng nhất…

Nghe có quen quen? Tôi gặp hàng trăm câu chuyện như vậy qua những buổi nói chuyện trong cộng đồng, mọi người ca thán rằng thấy “loay hoay, lúc thế này, lúc thế khác; chẳng hiểu đi được tới đâu”. Và tôi chỉ ước mọi người đừng hỏi “Planday có thế không?”. Startup không như vậy thì sống kiểu gì? Nhưng “loay hoay” và “linh hoạt” có một ranh giới mà chỉ trong cuộc mới hiểu và họ hiểu bởi họ sở hữu dữ liệu. Quan trọng là, dữ liệu cho anh thấy, anh đã giải được bài toán hiện tại chưa, nếu chưa mà anh cứ tiếp tục thì sẽ là “loay hoay”, nếu khẳng định được để anh đi tiếp hay chuyển sang bài toán khác thì sẽ là “linh hoạt”.

Một đặc tính nổi bật (và là lợi thế) của các công ty Bắc Âu là khả năng ra quyết định và chuyển mình nhanh. Nhưng tất cả đều được minh bạch và giao tiếp tốt nên việc hoài nghi về “một thứ gì đó khác trong quyết định” không thường xảy ra. Văn phòng Hà Nội được xây dựng với định hướng trở thành nơi phát triển quan trọng về hệ thống. Một thời gian ngắn sau, mobile trở thành việc quan trọng nên ngay lập tức có thêm nhóm làm mobile. Một thời gian sau, việc mở rộng nhóm hệ thống không thực sự khả thi do không tìm được nhân sự đủ tốt, cùng lúc đó là cơ hội để có những nhân sự chất lượng tại Đan Mạch, phần công việc được chuyển giao lại… Rất nhiều những chuyện như vậy vẫn xảy ra, đòi hỏi doanh nghiệp phải linh hoạt để giải quyết các bài toán về sản phẩm, thị trường, nhân sự, công nghệ…

Đúng sai là chuyện của khoảnh khắc, linh hoạt để bắt đúng khoảnh khắc.

Phải làm, muốn làm và được làm: Ranh giới mong manh.

Tại startup, sẽ là một ranh giới rất, rất mong mong manh giữa 3 loại công việc: phải làm, muốn làm, được làm. Startup gần như không có giới hạn về những việc “được làm”, có muôn vàn công việc để “muốn làm”, và một ít việc “phải làm”. Đừng quá nhầm lẫn, startup có cả một thế giới những việc “cần làm” nhưng rất ít người định hình rõ công việc cho bạn; nên nếu bạn coi “phải làm” là hệ quy chiếu thì bạn cũng chẳng bận rộn hơn so với làm việc trong một tổ chức ổn định. Thậm chí là nhàn hơn. Thật sự là như vậy. “Không phải việc của tôi” là câu nói luôn đúng trong startup, bởi startup làm gì có JD cụ thể, làm gì có process cụ thể? Mà cũng chẳng ai mất công đi tranh cãi, ăn thua việc đó làm gì cho tốn thời gian, còn cả ngàn việc “cần làm”. Bởi câu nói đó, khi được nói ra, cũng đúng như chuyện “chúng ta không hợp nhau”. Thế thôi.

Làm việc tại startup là nghệ thuật của xác định những việc “cần làm”, chuyển chúng thành việc “phải làm”; và chẳng cần chờ tới may mắn đâu, đó thường là những việc bạn “được làm” – quan trọng đó có phải là việc bạn “muốn làm” hay không. Vận hành startup cũng vậy, là nghệ thuật của việc tối đa số “muốn làm” của cá nhân và “cần làm” của tổ chức khớp với “được làm” (đủ khả năng). Đó là cách tạo ra giá trị lớn nhất trong một nguồn lực giới hạn.

Có một câu chuyện vui. Khi mở văn phòng tại Việt Nam, tôi là người phụ trách gần như mọi công việc. Thời đó tôi lấy bừa title “Team Lead” vì cũng chẳng biết đặt là gì nhưng cũng cần title để nói chuyện, phỏng vấn, giao tiếp với bên ngoài. Sau này, Planday phát triển, mỗi người mới vào đều có title và JD cụ thể. Vào một ngày đẹp trời gần đây, board nhận ra tôi chưa bao giờ được có title hay JD một cách chính thức; tôi tất nhiên cũng chẳng để ý. Nhưng giờ đặt thế nào thì cũng conflict với công việc và các vị trí hiện tại. Cuối cùng chốt bừa một cái, còn vẽ organizational chart, dù JD của tôi không thực sự đúng với title. Để duy trì startup spirit, nên giờ dù Planday đã “nề nếp”, JD của tôi vẫn rất mở.

Startup nào cũng có những giai đoạn, những người gom những việc “phải làm”, “muốn làm” và “được làm” trộn vào với nhau và get shit done.

Khởi nghiệp: giấc mơ của bạn, không phải của chung.

Điều tôi cực kỳ ấn tượng và tôn trọng Mikkel bởi sự rõ ràng về chuyện khởi nghiệp. Mikkel rất đam mê, rất chăm chỉ với việc lập trình, việc làm sản phẩm, việc giúp đỡ người dùng và luôn mong muốn mọi người chung tay xây dựng giá trị cho người dùng song Mikkel không bao giờ bắt ép mọi người làm việc đến điên rồ như mình. Mikkel luôn tôn trọng không gian cá nhân và chỉ yêu cầu mọi người làm việc có trách nhiệm.

Bản tính thận trọng và hiểu biết rộng giúp Mikkel không bao giờ đưa Planday vào tình thế khó xử, ít nhất ở vấn đề tài chính. Không ít lần dòng tiền công ty chỉ ra rằng Planday chỉ đủ tuyển thêm 1 người, người làm sản phẩm, UX hay development? Hay mua thêm công cụ / dịch vụ? Hay mở văn phòng? Tất cả được cân nhắc kỹ lưỡng để không ai phải làm thêm việc. Trong 3 năm, 4 lần Mikkel hỏi rằng “Hiển, có cần người support không? Mày còn phải đá bóng mà? Tao phải làm việc trực tiếp với chừng này người và biết sẽ bận đến mức nào.”. Lần thứ 4 là khi chúng tôi quyết định sẽ chính thức có tư cách pháp nhân tại Việt Nam.

Những điều này giúp tôi thay đổi suy nghĩ khá nhiều, giống như Mikkel, tôi chỉ yêu cầu mọi người có trách nhiệm với công việc như đã cam kết với công ty. Tất nhiên, startup có hàng ngàn việc cần làm, ai cố gắng làm thêm, tôi rất trân trọng; nhưng không có nghĩa rằng những người không xả thân sẽ bị nguyền rủa hay ghẻ lạnh – điều hay xảy ra tại những doanh nghiệp khác khi những ông chủ luôn muốn nhân viên xả thân cho giấc mơ của mình. CB, CEO của Planday, lần nào gặp cũng nói “mỉa” rằng: Hiển, người Đan Mạch không làm việc thứ 7 – để chỉ trích chính sách làm việc sáng thứ 7 tại Việt Nam của tôi (thật ra là để học, không phải làm việc).

Khởi nghiệp không hẳn là giấc mơ chung. Không ai phải chết cho giấc mơ của người khác chính là tiền đề cho một mối quan hệ bền vững.

Không nhậu không chết được đâu.

Gắn kết đội ngũ và gắn kết đội ngũ với manager luôn là một trong những ưu tiên hàng đầu của mọi tổ chức và manager. Có ba phương pháp cực hiệu quả thường thấy là nhậu, nhậu và nhậu. Công bằng mà nói, chẳng đội nhóm nào gắn kết được mà thiếu nhậu – đấy là lúc người ta có thể dễ dàng cười vào quá khứ, trải lòng về hiện tại và mơ mộng về tương lai – những chất liệu làm nên sợi dây gắn kết trong đội nhóm. Học hỏi từ những đàn anh đi trước, tôi cũng đã thử áp dụng trong nhóm của mình, sinh ra một thứ gọi là “big Friday” hàng tuần (đến giờ chúng tôi vẫn dùng “thuật ngữ” này cho việc nhậu – nhưng không phải hàng tuần): đưa nhau ra quán. Tại HQ chúng tôi cũng có một chương trình tương tự, gọi là “Friday bar” nhưng chỉ tại văn phòng và kéo dài dưới 1 giờ, mọi người tập trung nói chuyện nhiều hơn là uống.

Một thời gian rất ngắn, tôi bắt đầu lược bỏ chuyện nhậu, thu gọn 2-3 lần / năm; những cuộc nhậu tự phát vẫn tiếp tục nếu có thành viên thích thú, tôi không phản đối; song tôi chỉ tham gia 2-3 cuộc nhậu được coi là “chính thức” và biến những cuộc đó thành những ấn tượng mọi người không thể nào quên. Một phần tôi muốn tiết kiệm thời gian làm việc, một phần để giảm áp lực tới các thành viên rằng nhậu không phải là công việc, bất kỳ ai cũng có quyền từ chối nếu không hứng thú, chẳng cần phải phán đoán ý sếp hay lo sợ mất cơ hội biết thêm thông tin trên bàn nhậu.

Và kết quả là… chẳng có gì khác biệt. Tôi không phản đối việc các manager gắn kết nhân viên thông qua nhậu, song tôi không phải là fan của việc nhậu và cũng không cho rằng đấy là cách hay khi bị lạm dụng, nó quá mất thời gian và không tạo ra nhiều giá trị. Nhậu rất tuyệt để thực hiện ice breaking, song đừng sử dụng nhậu làm sợi dây gắn kết nhau trên đường dài. Sao không thay việc nhậu hàng tuần, hàng tháng bằng việc học hàng tuần, hàng tháng? Tôi thích cảm giác mỗi khi CB hay Mikkel nhíu mày “Hiển, mai là thứ 7 rồi, uống đi mà”.

Về lâu dài, các manager / leader nên gắn kết với đội ngũ và để họ gắn kết với nhau thông qua sự tôn trọng, thấu cảm và suồng sã rất tốt nhưng startup còn nhiều việc lắm, có đáng đánh đổi thời gian thế không?

————————————————–

5 năm là một chặng đường đủ dài để cho tôi rất nhiều bài học qua những con người, những bài toán rất khác nhau. Tôi vẫn không bao giờ nói về một tương lai quá dài, “chừng nào vẫn còn bài toán để giải, vẫn còn thứ để học, tôi sẽ vẫn tiếp tục”. Và thật may mắn, đến giờ, vẫn còn.

 3,101 total views,  4 views today

There are some researches about team stages, the famous ones are Tuckman’s model and ShuHaRi. To be honest, both Tuckman’s and ShuHaRi models are generic and support for group development instead of cross-functional and self-organized team in Agile. But both of them are very well known and well explained to be borrowed to Agile. I usually use those models in common Agile article/training/coaching, and in this post as well. Tuckman defined team stages with Forming, Storming, Norming and Performing in his first publish. It’s a sequence, means each stage has it own obstacle that needs to be overcome for moving team to next stage (see Agile Y, chpt. 6).

While Tuckman is the team model of performance, ShuHaRi isn’t. ShuHaRi is the team model of learning and practicing Agile with Shu, Ha and Ri (following, branching, owning). But Agile is the iterative and empirical approach for building team and process, learning and practicing seem to be ‘everything’ that directly affect to the team performance.

Working in Agile team as an Agile coach, I like the idea of combining Tuckman and ShuHaRi: bringing the team through Tuckman’s stages by supporting them to overcome their obstacles following ShuHaRi. That bases on understanding team’s stages and its needs in each stage as ShuHaRi.

Stage 1: The child (Forming, Storming) & Shu: Need a ‘manager’

Team should be in a chaotic stage, a group of people with an initial agreement (on vision, working method…) but lots of disagreement (on process). What team needs is a very clear direction, who team needs is a leader with strong management skill, to quickly bring team out of chaotic state. Like a child, team doesn’t need to understand why red light is for stop, just stop. Command and control is acceptable here by well explained the reasons and high level of ‘command’: following code review, applying TDD…

Many people believe that Agile team shouldn’t have a leader – that I cannot agree. Any team has a leader itself in many ways, with or without title or responsibilities in the job description. In Scrum, ScrumMaster is a leader of process. My experience, there are 2 reasons for Agile team never steps out of those stages: team has a manager who lacks of leadership spirits, and team has a leader who lacks of management skills. Team needs both, a ‘leader’ to set the direction, and a ‘manager’ who make sure team do right (Shu). If one plays multiple roles (TeamLead or ScrumMaster…), team should expect the clear communication that they are SHUring, be patient to Ha and Ri in the next steps.

Stage 2: The teenager (Norming) & Ha: Need a ‘leader’

Team should be in organized stage, a half-team with some agreements that were built up from their experiences. What team needs is the clear objectives and a methodology to reflect their learning. Like a teenager, team understands why red light is for stop, green to go, and sometimes try the new things with yellow ones. Team needs a ‘leader’ who supports their decisions to try various things in their own ways, thing by thing, step by step. Team has few knowledge and skills of managing, then still needs but weak ‘manager’ could be good here. Together, managing skills can be built up by leadership spirit.

Stage 3: The mature (Performing) & Ri: Need a ‘coach’

Team should be in out-standing stage, a true team with self-organized and has enough skillset to perform well. What team needs is a methodology for keeping the continuous improvement, and who team needs is a coach. Like a mature, team understands why the lights exist in places, when it should be red, when it should be green. The method and coaching help both: team and team member. How team works well together is still an important knowledge and skills to be built up but team shouldn’t expect the big steps as in child and teenager stages. Keeping or stepping out of this stage needs team deep understanding about the methodology behind rather than just practice. Team and each member needs  a coach who tells them the missing knowledges and skills, manage the improvement process and give feedbacks continuously.

FSNP-SHR

You could see it as a model or pattern to be applied in team. But the hard and trick part is the leader/manager needs to recognize the correct stage of the team to shift his role or responsibilities in the right time. The metrics are helful out there.

 3,918 total views,  2 views today

How could we have the high performance team for a software development project at getting started? It may take long time to get a team having the same mindset and working together with high performance but with the good setup at the beginning, time would be shorter. Five things below, in my opinion, are simple but very important that every software development team should do.

0. Working method

Very important. Remember that in the first step, we don’t have a team that targets the same goal, we have a group of people that works in the same project even though in a sustainable organization where the working method or process is defined. So what we need to form a team?

Mission & vision: No one works without the vision and objective. A group needs it at least to become a team. It’s a direction for team and also a glue to get people worked together.

Working agreement: What team commit to do? I try my best to complete the day job or I just want to work at most 6 hours daily no matter the result is? It must be agreed in team.

Write down mission & vision and working agreement in a eye-catching place to remind everyone in team. Before all, let’s discussed and agreed in team, and get everyone signed off.

Choose a working method: Everyone in team has to understand how they work together. It’s good to pick a “standard” method or framework to start with such as Scrum, Kanban… in order to help people more easily to understand and follow. In case of people don’t understand it right, make sure they get trained to reach the level of start.

Working method (or process) must be visualized

1. Team collaboration tools

When working method is set, team needs a tool for collaboration. If team chooses Scrum or Kanban, team board is more than important. It can be the physical board or online board such as Jira, Trello, Pivotal Tracker…

Choose a single official toolset. A lot of good communication tools today makes team difficult to decide. Slack or Skype? Google Docs or Zoho?… Then team never feels happy enough with one tool, Slack is good but Skype has better video call quality. Choose both? No. Let choose a single official tool where every main information, decision, solution… are placed there. Extra discussion can be worked over others that the contributors feel comfortable with. It helps people simply find the decision.

Choose a single official tool where every main information, decision, solution… are placed there

2. Source code version control

I don’t need to explain more about the needs of source code version control. Choose one that all team members are familiar with, otherwise it will become the headache by overhead. Git is the best one today. But Git is so uncomfortable without diff tools. Meld, Kdiff3, WinMerge… are the good tools that work for most of Git clients.

Choose which?

3. IDE & team environment settings

IDE / text editor is a sword to kill dragons. Find the best one. It’s so easy to have an agreement in team if the project is working on .NET, iOS… with the vendor tool. There’s a bit harder with the language or technology that can be done by many choices. TextMate or Atom, Sublime or InteliJ for PHP? Which is the best for Android, Eclipse or Android Studio?

Once team chooses a single IDE, set the team environment settings and make sure to manage it in the right place, good one usually is source code repository. Keeping team environment settings reduce the conflict issues that usually be the overhead. It also helps for continuous integration and continuous delivery.

Environment shouldn’t be a place for personal creativity at beginning. Do it later.

4. Continuous delivery pipeline

Agile is becoming standard working method today, then continuous delivery and continuous deployment is crucial. The age of continuous integration was passed by, team needs more powerful toolset that’s near production or staging. That’s why DevOps is becoming important in developing software service.

That’s a pattern for setting up a software project that should be longer than 2 months within more-than-3-persons team. It’s very important with the initial setup with a specific method or toolset the team uses – it becomes material for improvement after each iteration. Lacking of agreement on a single method or toolset get the road harder to success.

 1,974 total views,  2 views today

Sau giai đoạn nhà nhà nói về “tinh thần Agile” như một thuật ngữ cửa miệng, giờ người ta bắt đầu nói về “tinh thần MVP”.

Nhưng giống như bao nhiêu thứ “tinh thần” khác được hô hào, cổ vũ mà thiếu nền tảng và thực hành rõ ràng – rất nguy hiểm. Chạy theo “tinh thần Agile” mà thiếu thực hành tạo ra một nhóm hỗn độn. Chạy theo “tinh thần MVP” mà thiếu thực hành tạo ra một sản phẩm tạp nham.

Tôi bắt đầu gặp nhiều nhóm làm sản phẩm với một công cụ MVP duy nhất là “tinh thần”:

  1. MVP không đồng nghĩa với kém chất lượng. “Có bug chút cũng được, chắc gì đã có ai dùng”. Nếu bạn đã không tin sẽ có người dùng (chức năng đó), tại sao lại làm? Rồi bạn sẽ biết người dùng không sử dụng do chức năng đó thực sự không nằm trong nhu cầu của họ hay nó tệ đến mức không thể sử dụng? Chúng ta có thể đặt nhỏ scope nhưng không được thoả hiệp với chất lượng.
  2. MVP không đồng nghĩa với “cứ làm đi”. MVP phải dựa trên giả định, phải tìm kiếm, nghiên cứu trước để củng cố phần nào cho giả định… MVP là công cụ để kiểm chứng lại giả định trong thực tế. MVP không phải là cứ có ý tưởng là lao vào làm, rồi để thực tế trả lời mà không định nghĩa rõ những giả định nào cần kiểm chứng.
  3. MVP rồi cũng phải dừng hoặc đi tiếp. Cần phân biệt rõ ràng, test là test. Khi đã đủ dữ liệu để kiểm chứng giả định, học từ đó và quyết định: đi tiếp hay dừng lại. Đã quyết định dừng lại thì phải thẳng tay loại bỏ chức năng không hữu ích. Đừng biến sản phẩm thành bãi rác.

Một sản phẩm làm sao phát triển bền vững nếu nó cứ loanh quanh trong việc “test” để tìm ra phần hồn của mình? “Tinh thần MVP” không có thực hành sẽ tạo ra một mớ hổ lốn không còn đúng với nguyên lý 80/20 mà chính MVP theo đuổi nữa.

 1,631 total views,  3 views today