Hiển thị các bài đăng có nhãn CHIA SẺ. Hiển thị tất cả bài đăng
Hiển thị các bài đăng có nhãn CHIA SẺ. Hiển thị tất cả bài đăng

Con đường của một lập trình viên (Phần 3)

Trong bài viết trước tôi đã trình bày về nấc thang lãnh đạo – một nấc thang rất quan trọng đánh dấu sự trưởng thành trong sự nghiệp lập trình viên của bạn. Bài viết này, tôi sẽ viết về vai trò của kiến trúc sư phần mềm – một vị trí/vai trò mà rất nhiều bạn lập trình viên mong muốn đạt đến.
Vị trí kiến trúc sư phần mềm – trong quan điểm của tôi chỉ là bước chân đầu tiên để đưa bạn lên những vị trí cao hơn mang tầm chiến lược của tổ chức như: giám đốc kĩ thuật, CTO và các loại XXO mà bạn thường thấy trên các kệ rượu trên thị trường :).
ruoucamus-xo-elegance.jpg
Với những ai đã từng trải qua vị trí này – thì trong bài này tôi muốn trình bày một vài quan điểm riêng mà tôi nghĩ rằng có thể gây tranh cãi. Với một số bạn hiện tại đang chuẩn bị hoặc đang bước một chân lên nấc thang này, tôi hy vọng được chia sẻ một vài trải nghiệm của riêng tôi. Có thể đúng, có thể sai. Tuy nhiên, tôi vẫn hy vọng nó có ích.

Kiến trúc sư phần mềm – anh là ai?

Ở rất nhiều tổ chức, người ta đặt ra rất nhiều vị trí có tên gắn với chữ ‘kiến trúc sư’, ví dụ: Technical Architect (kiến trúc sư kĩ thuật), Solution Architect (kiến trúc sư giải pháp) … và khá nhiều cải biên khác về cái tên như: Technical Expert (chuyên gia kĩ thuật), Guru ….
software_architect
Suy cho cùng, trong quan điểm của tôi: những cách phân chia ở trên chỉ là một cách để phân cấp về mặt level và benefit trong tổ chức mà thôi. Vai trò chung của tất cả những anh được gắn với chữ kiến trúc sư ở trên giống hệt như nhau. Họ là những người giúp định hình và xây dựng nên bộ khung của một hệ thống phần mềm.
Bộ khung này không nên chỉ được hiểu là những thành phần kĩ thuật xây dựng nên nó, mà còn bao gồm những thành tố kể cả con người, quy trình, giải pháp để tạo ra một hệ thống ‘tốt’.
Hệ thống cũng không chỉ dừng lại ở mức một sản phẩm, một dự án mà cũng nên hiểu rộng hơn là cả một tổ chức và văn hoá của những con người trong tổ chức đó.

Thực tế và chi tiết hơn nữa đi, cuối cùng anh làm gì?

duties-of-software-architect.png
Trong những công ty mà tôi từng trải nghiệm – thì thông thường một anh kiến trúc sư phần mềm sẽ làm những công việc sau đây:
Tham gia các hoạt động pre-sale: kiến trúc sư phần mềm đóng vai trò quan trọng trong giai đoạn pre-sale khi lấy hợp đồng. Họ tham gia viết proposal, xây dựng PoC (Proof Of Concept – một loại demo để thể hiện khả năng hiện thực được của hệ thống), lên sườn những giải pháp tổng thể sẽ sử dụng trong hệ thống – từ kĩ thuật đến hạ tầng.
Hỗ trợ dự án: khi một dự án bắt đầu, kiến trúc sư phần mềm là người giúp truyền đạt những giải pháp từ giai đoạn pre-sale đến cho team. Anh ta cũng là người hỗ trợ nhóm trong các giải pháp, quy trình, ràng buộc về hệ thống để đáp ứng được nhu cầu của khách hàng. Nếu dự án quan trọng, kiến trúc sư phần mềm sẽ tham gia như một thành viên của nhóm phát triển – định hướng và dẫn dắt nhóm về mặt giải pháp.
Vai trò đào tạo trong tổ chức: là người dẫn dắt về kĩ thuật, kiến trúc sư phần mềm là người giúp tham gia định hướng và đào tạo các bạn lập trình viên để đáp ứng nhu cầu của tổ chức về nền tảng và những kĩ thuật mũi nhọn.
Vai trò định hướng kĩ thuật: kiến trúc sư phần mềm cũng là những người tham gia đóng góp vào các hoạt động nghiên cứu và định hướng công nghệ cần đầu tư để đón đầu nhu cầu bán hàng và sản xuất.
Tất nhiên, tuỳ theo đặc thù mỗi công ty hoặc từng giai đoạn: trọng số ưu tiên và vai trò của kiến trúc sư phần mềm sẽ được phân bổ vào các nhóm hoạt động trên nhiều hay ít. Tuy nhiên, đây là những vai trò và công việc chính mà một kiến trúc sư phần mềm thường tham gia.

Những kĩ năng cần có của một kiến trúc sư phần mềm

Tư duy và góc nhìn kinh tế

Là một kiến trúc sư phần mềm – bạn là người đưa ra những giải pháp cấu thành nên hệ thống. Trên thực tế, giải pháp tốt không phải là giải pháp hoàn hảo mà là giải pháp phù hợp. Phải hiểu thật sự khách hàng muốn gì. Đâu là giá trị thực sự mình cần cung cấp cho họ. Trên hết, hãy đặt mình vào vị trí của họ để chi từng đồng cho dự án, bạn sẽ hiểu mình cần chọn giải pháp nào.
Tôi từng làm việc với rất nhiều những khách hàng tham vọng. Họ đặt ra rất nhiều tính năng và nhu cầu cho một hệ thống được dự liệu là sẽ vận hành với cả triệu người dùng, phải đáp ứng vài ngàn truy cập đồng thời. Đó là một tâm lý phổ biến và là bản chất tự nhiên của một khách hàng. Họ luôn muốn mỗi đồng tiền chi ra phải xứng đáng và có giá trị lâu dài.
Điều mà một kiến trúc sư phần mềm cần phải giải quyết đó là: tư vấn khách hàng để giúp họ nhìn ra chi phí phát sinh và cách thức đầu tư cho phần mềm hiệu quả. Phải hiểu rõ khách hàng có khả năng chi trả bao nhiêu và giải pháp tối ưu với quỹ tiền tương ứng. Đừng từ chối họ mà hãy cho họ những lựa chọn khác nhau về kinh phí. Đó mới là giải pháp khôn ngoan và khéo léo.

Hiểu về nguyên lý giá trị

Tôi đề cập vài lần trong những bài viết trước về việc làm đúng việc ở đúng thời điểm để đem lại giá trị đúng lúc. Nếu bạn đọc câu này thấy nhức đầu, thì chỉ cần nhớ 3 chữ: JIT – Just In Time. Điều này có nghĩa là gì?
JIT là một nguyên lý được áp dụng trong dây chuyền sản xuất của Toyota. Tư duy chính là loại bỏ các giá trị, hoạt động dư thừa – sản xuất vừa đủ để đáp ứng nhu cầu. Nếu bạn có thời gian và thích đọc sách thì có thể đọc quyển: Toyota Production System để hiểu chi tiết hơn. Quyển này có bán ở Việt Nam – tựa là Phương pháp sản xuất Toyota.
Nếu bạn thực sự hiểu rõ nguyên lý này, bạn sẽ biết khi nào cần tập trung làm gì, định hướng cách thức vận hành của nhóm sản xuất như thế nào một cách hiệu quả nhất. Những practices về lean startup hay các phương pháp luận về sản xuất tinh gọn, agile cũng áp dụng cùng một tinh thần chung như vậy cho những practices trong thực tế.

Khả năng quyết định, xử lý tình huống khi thông tin còn chưa rõ ràng

Là một kiến trúc sư phần mềm, bạn sẽ được đặt vào rất nhiều tình huống cần xử lý khi thông tin còn chưa rõ ràng mà bạn vẫn phải ra quyết định. Có thể đó là những buổi nói chuyện với khách hàng cần quyết định nhanh về budget, những tranh luận trong các dự án hợp tác nhiều bên, những câu hỏi cần trả lời nhanh trong những buổi presentation …
software-architect-tshirt.jpg
Bạn cần phải trang bị cho mình khả năng xử lý thông tin nhanh, lập luận sắc bén và đôi lúc … là sự dũng cảm để đưa ra phán đoán. Có những tình huống chỉ cần bạn ú ớ vài phút, bạn có thể mất những dự án giá trị lớn vì khách hàng không thấy bạn tự tin.
Tôi học rất nhiều từ anh Martin (CTO) khi tôi còn làm ở Pyramid Consulting. Trong những buổi nói chuyện với khách hàng và các partner, bằng lý luận sắc bén, phản ứng nhanh và khả năng tranh luận – anh luôn mang lại những yếu tố có lợi cho công ty.
Cách đây vài năm – trong một buổi meeting với khách hàng cùng anh, họ hỏi tôi một câu mà lúc đó thực sự tôi cũng không biết phải trả lời như thế nào. Tôi bảo rằng cần phải check lại với team xem giải pháp đó có khả thi hay không. Xong buổi họp, Martin bảo tôi ngồi lại và chỉ nói đúng một câu: là một kiến trúc sư phần mềm, em không được thể hiện thái độ không chắc chắn hoặc thiếu tự tin trong bất kì tình huống nào.
Câu nói đó làm tôi suy nghĩ rất nhiều và thay đổi hoàn toàn cách mình hành xử với bất kì những tình huống đột ngột nào phát sinh về sau, dù ở đâu hay bất kì tình huống nào. Sau này tôi hay nói đùa với anh em: phải tập bản lĩnh để cho dù trời sập cũng không chớp mắt thì mới thành chính nhân quân tử. Thực ra, ai cũng có những nỗi sợ: sợ trách nhiệm, sợ thể hiện cái mình không biết, sợ người khác đánh giá …. Tuy nhiên, vượt qua nỗi sợ của bản thân  mới là cách làm cho mình tiến bộ.
Những điều tôi nói ở trên không phải là tôi xúi bạn làm thầy phán, nói đại. Điều tôi muốn bạn trang bị là khả năng ứng phó tình huống – và sự tự tin tuyệt đối khi cần ra quyết định. Đó là một kĩ năng cần luyện tập và trải nghiệm lâu dài. Trang bị nó như thế nào thì tôi xin trình bày ở một bài viết khác.

Kĩ năng mềm

Tôi không nói dong dài về kĩ năng mềm cần có của một kiến trúc sư phần mềm. Chỉ muốn giới thiệu cho bạn một quyển sách mà tôi nghĩ là khá thú vị cho những bạn đang muốn trải nghiệm vị trí này. Nó sẽ làm thay đổi khá nhiều góc nhìn của bạn – đặc biệt là các bạn lập trình viên. Quyển này tên là: 12 Essential Skills for Software Architects (12 kĩ năng cần thiết của kiến trúc sư phần mềm). Tiếc là quyển này chưa có bản dịch tiếng Việt. Tuy nhiên, nó thực sự đáng đọc và để bạn chiêm nghiệm lại những điều mình cần trang bị.
12-essential-skills-for-software-architects.jpg
Bạn sẽ tìm thấy ở quyển sách này từ lý do bạn không được tăng lương đến thấp thoáng đâu đó một hình bóng của mình (trước đây hoặc hiện tại).  Tin tôi đi. Đọc thú vị đấy.

Vài câu hỏi bâng quơ

Công ty em không có vị trí kiến trúc sư phần mềm, biết bao giờ em mới có cơ hội để lên vị trí này ạ?
Sau này tôi có một quan điểm khác về vai trò của kiến trúc sư phần mềm. Nếu một nhóm thực sự giỏi và có tính tiến hoá thì mỗi lập trình viên là một kiến trúc sư phần mềm. Đừng nghĩ quá xa xôi về những thiết kế, hình ảnh dày cộp và hoành tráng để trong các proposal bán cho khách hàng. Mỗi dòng code bạn viết ra, mỗi thiết kế bạn đưa ra là một giải pháp. Nếu thật sự suy nghĩ về nó thật nghiêm túc từ các yếu tố giải pháp, bảo mật, tối ưu hoá … thì đó đã là một vấn đề kiến trúc. Một ngôi nhà được xây dựng từ những viên gạch – nhà có chắc hay không là do gạch được nung chín và đặt vào đúng vị trí. Hơn thế nữa, tôi tin rằng cách làm cho bạn leo nhanh là nên xây cho mình nền tảng từ chính những công việc mình đang làm hàng ngày.
Điều thứ hai, vị trí trong một tổ chức hay con đường thăng tiến la do chính bạn quyết định. Nếu bạn đủ bản lĩnh, bạn sẽ tìm ra được con đường và vị trí mình mong muốn mà không phụ thuộc nhiều vào môi trường. Điều quan trọng hơn bạn cần phải làm là phải đam mê và đặt mục tiêu cho nấc thang kế tiếp trên con đường đến vị trí này.
Mất bao lâu để một người từ khi bước chân vào nghề để đạt được vị trí này?
Theo kinh nghiệm của tôi, để vững bước khi là một kiến trúc sư phần mềm thật sự – bạn cần phải trải qua nghiêm túc vai trò lãnh đạo (leader) trong các dự án hoặc một nhóm kĩ thuật. Để một người thật sự chín chắn để trở thành một leader giỏi thì cần ít nhất là 2-3 năm tham gia với vai trò này. Trừ khi bạn thật sự xuất sắc – thì trung bình để lên vị trí kiến trúc sư phần mềm, bạn cần ít nhất 7 năm lăn lộn với nghề.
Ở nước ngoài, các vị trí này đòi hỏi bề dày kinh nghiệm và sự từng trải, nên có người đi làm đến 10 – 15 năm mới lên vị trí kiến trúc sư cũng là chuyện bình thường. Thậm chí có người làm lập trình viên đến 50 – 6o tuổi. Đơn giản là vì họ đam mê với công việc. Đối với họ vị trí chỉ là một tên gọi. Chưa chắc lý luận của mình về giải pháp kĩ thuật có thể hơn một lão lập trình viên 50 tuổi.

Lời kết cho loạt bài “Con đường của một lập trình viên”

Đây xem như là bài kết thúc trong chuỗi bài về con đường của một lập trình viên. Cách tôi trình bày các nấc thang nghề nghiệp là một lát cắt phẳng cho bạn dễ hình dung:
Mỗi nấc thang có những yêu cầu riêng. Bạn không nhất thiết phải đi qua từng nấc thang. Tuy nhiên, có 3 bậc thang rất quan trọng mà bạn sẽ cần đầu tư rất nhiều thời gian để phá vỡ những giới hạn của bản thân mình và đạt được, đó là: Lập trình viên, Lãnh đạo và Kiến trúc sư phần mềm. Đó là những cột mốc để trang bị hành trình cho bạn vững chắc hơn trên con đường của một lập trình viên.
Tôi hy vọng rằng loạt bài viết này của tôi sẽ giúp bạn nhìn lại con đường mình đang đi và cho bạn vài giá trị tham khảo. Tuy nhiên, tôi hiểu rằng: không ai hiểu rõ mình bằng chính mình. Bạn có thể xem đây là một góc nhìn tôi đưa ra để so sánh và nhìn lại mình đang ở đâu, cần trang bị gì cho bước tiếp theo. Quan trọng nhất vẫn là chính bản thân bạn.

Review lại những vấn đề tôi đã trình bày trong loạt bài của dự án Veagle

Nếu bạn đọc kĩ về các bài viết trong chủ đề này, bạn sẽ thấy tôi cố tình trình bày từng quan điểm theo trình tự:
  • Đạo lập trình: trình bày quan điểm về đạo đức nghề nghiệp và là kim chỉ nam trong những hành xử cua một lập trình viên. Vì quan điểm của tôi đơn giản là: sống không có đạo, thì dễ lạc lối. Rất nhiều bạn thường không để ý hoặc bỏ qua bài viết này. Tôi nghĩ nó khá quan trọng.
  • Con đường của một lập trình viên: là loạt bài tôi chia sẻ những trải nghiệm và những nấc thang định hướng trong nghề nghiệp.
  • Những bài viết sau tôi sẽ đi sâu vào chi tiết những điều quan trọng trong chính công việc và cuộc sống mà tôi nghĩ rằng sẽ dẫn dắt bạn thay đổi.
Trân trọng.
PS: nếu bạn thấy bài viết này thú vị, hãy đừng ngại ngần chia sẻ nó. Nếu bạn thấy có những quan điểm cần bổ sung, đừng ngại ngần comment. Chúc bạn vui và tìm thấy những điều thú vị trong cuộc sống và con đường nghề nghiệp của mình đang đi.
<Nguồn: Điều thú vị>

Con đường của một lập trình viên (Phần 2)

Như đã hứa, hôm nay tôi viết tiếp phần 2 cho bài “Con đường của một lập trình viên”. Bạn nào chưa đọc phần 1 thì có thể xem lại tại đây. Theo dự định ban đầu, tôi định viết tiếp 2 nấc thang kế tiếp, đó là: Lãnh đạo (leader) và Kiến trúc sư phần mềm (Software Architect) trong bài này. Tuy nhiên, tôi nghĩ mình nên viết nhiều về nấc thang “Lãnh đạo nhóm” vì nó là một bước quan trọng và đòi hỏi rất nhiều kĩ năng bạn cần phải học. Do đó, trong phạm vi bài viết này, tôi chỉ trình bày về nấc thang này.
Ghi chú: Vị trí “leader” ở bên ngoài, người ta thường dịch là trưởng nhóm. Tuy nhiên, tôi dịch nó là lãnh đạo để sát nghĩa hơn.
Nhiều bạn sẽ dừng ngay ở đây vì nghĩ rằng bài viết này tôi chỉ nói về kĩ năng mềm. Chả còn gì liên quan đến kĩ thuật nữa thì đọc làm quái gì nhỉ? Bình tĩnh! Bạn cứ nên đọc đến hết bài.
abraham-lincoln

Lãnh đạo là gì?

Lãnh đạo là quá trình gây ảnh hưởng và dẫn đắt hành vi của cá nhân hay nhóm người nhằm hướng tới mục tiêu của tổ chức (Theo wikipedia)
Người lãnh đạo trong một tổ chức chính là người thực hiên vai trò lãnh đạo được định nghĩa ở trên.
Ở các công ty phần mềm, người ta hay tách biệt 2 vai trò lãnh đạo:
  • Lãnh đạo dự án (Project Leader): là người  chịu trách nhiệm dẫn dắt nhóm thực hiện dự án để đi đến thành công.
  • Lãnh đạo nhóm  (Team leader, một số nơi còn gọi là Team manager) – để định hướng và phát triển một nhóm kĩ thuật để đạt được mục tiêu/ sứ mạng công ty đưa ra.
Tôi sẽ phân tích những điểm chung và riêng của 2 vai trò này chi tiết hơn ở phần sau. Bây giờ, quay trở lại – bạn được mong đợi gì khi được tấn phong lên vị trí này?

Điều mọi người chờ đợi ở bạn khi là một “lãnh đạo”

leadership
“Đạo” là con đường. Lãnh đạo là người chỉ đường và dẫn dắt tập thể để đi đến mục tiêu. Để là một lãnh đạo thành công, bạn phải làm được 2 việc:
  • Chỉ ra con đường phù hợp để đạt được mục tiêu.
  • Dẫn dắt, tác động, ảnh hưởng các thành viên trong nhóm để kéo mọi người đi theo con đường đã vạch ra.
Vậy thì, lãnh đạo một dự án hay lãnh đạo một nhóm kĩ thuật – về mặt bản chất bạn cũng làm đúng 2 vai trò này. Điều khác biệt chính chỉ là: mục tiêu xây dựng cho nhóm và dự án là khác nhau mà thôi. Mục tiêu khi lãnh đạo nhóm là: định hướng và phát triển con người để đáp ứng sứ mạng của tổ chức. Mục tiêu khi lãnh đạo dự án là: phải làm cho dự án thành công. Vì mục tiêu khác nhau nên cái HOW của việc dẫn dắt, tác động mọi người cũng có sự khác nhau về mặt chi tiết.

Bạn cần trang bị điều gì khi là một lãnh đạo?

Những kĩ năng chung

  • Kĩ năng chuyên môn: vì bạn phải đóng vai trò định hướng, nên khả năng kĩ thuật của bạn chắc chắn phải giỏi để có thể xem xét, đánh giá các giải pháp và lựa chọn hướng đi đúng. Ở vai trò này, bạn nên biết nhiều mảng kĩ thuật. Nó sẽ giúp bạn có cái nhìn rộng hơn để chọn lựa và đánh giá các giải pháp.
  • Thuật đắc nhân tâm và khả năng ảnh hưởng mọi người: bạn không thể dẫn dắt một nhóm nếu bạn không tác động và ảnh hưởng được họ. Bạn đừng nghĩ rằng mình cần lên vị trí “lãnh đạo” thì mới trang bị cho mình kĩ năng này. Đây là một kĩ năng quan trọng mà để xây dựng được nó đòi hỏi rất nhiều thời gian. Tôi sẽ không lan man ở chủ đề này nhiều. Tuy nhiên, nếu bạn muốn luyện kĩ năng này từ bây giờ, hãy đọc và thực hành:
    • “Đắc nhân tâm” => đây là quyển sách mà tôi nghĩ rằng rất hữu ích để xây dựng kĩ năng này cho bạn.
    • Bạn cũng có thể tham khảo 3 bài đầu tiên của tôi viết trong cụm chủ đề: “Trở thành lãnh đạo nhóm phần mềm sau 18 ngày”. Xây dựng 4 yếu tố: lòng tin, khả năng trình bày, lắng nghe – thấu hiểu và kĩ năng chuyên môn tương đối là một nền tảng tốt để bạn tạo ra sức ảnh hưởng đến những người khác.

Những kĩ năng cần thiết của vai trò lãnh đạo dự án

Khi dẫn dắt một nhóm dự án, những kĩ năng sau đây là cực kì quan trọng để quyết định sự thành công của dự án.

Quản lý rủi ro

rui-ro
Bạn cần phải có khả năng phân tích, đánh giá và hoạch định cho tất cả những tình huống rủi ro có thể xảy ra của dự án. Để làm tốt được điều này, bạn phải hiểu sâu về kĩ thuật, đánh giá được độ phức tạp và những tình huống có thể phát sinh. Đồng thời, bạn cũng phải hiểu rất rõ về nguồn lực, nhóm mình đang có, tính chất của khách hàng. Đây là một kĩ năng cực kì khó. Người ta thường nói rằng: quản lý rủi ro là vai trò của quản lý dự án (Project Manager). Tuy nhiên, là một leader – bạn chính là người phải đưa ra những định hướng và giải pháp nên bạn phải biết điều gì có thể xảy ra và cách xử lý nó thế nào cho hiệu quả.
Ví dụ: bạn làm một dự án web cho khách hàng. Bạn không hỏi bất cứ điều gì về môi trường mà dự án mình sẽ deploy sản phẩm. Đến ngày cuối, khách hàng bảo: tao đang xài Amazon Web Service – sử dụng mô hình load balancing. Xong phim. Bạn sẽ phải đối đầu với hàng loạt các bài toán tích hợp, cấu hình để xử lý các vấn đề liên quan đến session, lưu trữ file chung hay đồng bộ hoá file giữa các web server …. Không suy nghĩ về rủi ro này khi bắt đầu làm dự án sẽ gây ra thảm hoạ cho bạn ở phút cuối.

Quản lý cấu hình

configuration-management
Có rất nhiều bạn nghe về “Quản lý cấu hình” cảm thấy rất mơ hồ. Quản lý cấu hình chính là cách mà bạn quản lý tất cả những hoạt động/quy trình liên quan đến sự thay đổi trong dự án, bao gồm:
  • Mã nguồn
  • Môi trường deploy và cấu hình hệ thống
  • Tài liệu yêu cầu, thiết kế
  • Bug & tính năng
  • Dữ liệu
  • … và bất cứ gì khác có thể có sự thay đổi trong một quy trình phát triển phần mềm.
Tôi sẽ cho bạn vài ví dụ về những thảm hoạ nếu bạn không quản lý cấu hình tốt dưới đây:
Ví dụ 1 – quản lý mã nguồn:
Bạn vừa release ra sản phẩm. Team đang phát triển tính năng mới trên nhánh trunk (nhánh code chính). Bỗng dưng, khách hàng gửi bạn 1 bug critical cần phải fix gấp. Bạn quyết định fix bug trên chính nhánh code hiện tại mà team đang phát triển. Sau khi fix xong bug, bạn ngộ ra rằng mình không thể nào release nhánh code chính mà mình đã sửa để deploy cho khách hàng. Lý do đơn giản là vì hàng loạt bug khác phát sinh do cả team đang phát triển thêm tính năng mới.
Tôi không muốn trình bày quá sâu về chủ đề này. Tuy nhiên, bạn nên hiểu rõ các công cụ quản lý mã nguồn phổ biến (git, svn, mercurial…). Tìm hiểu rõ những chiến lược phân nhánh (branching), trộn (merging) mã nguồn và khi nào thì nên dùng chiến lược nào.
Ví dụ 2 – quản lý cấu hình hệ thống và deploy
Mỗi lần deploy dự án lên môi trường mới là một lần bạn chật vật vì không biết cần thay đổi những giá trị cấu hình nào. Mỗi lần team thêm tính năng mới là y như rằng code commit lên đè mất vài giá trị cấu hình cũ. Ác chiến hơn nữa, có bạn còn commit luôn cả connection string database của khách hàng lên git/svn.
Nếu bạn rơi vào những hiện trạng này thì có nghĩa là bạn đang bị lủng hoàn toàn về cách quản lý cấu hình hệ thống. Hãy quay lại với nhóm – cùng thống nhất và định nghĩa ra những rule và cách thức mà hệ thống đang được phát triển về mặt cấu hình, điều gì cần tuân thủ khi thêm/xoá/sửa cấu hình đang có, cập nhật lại cấu hình của các môi trường như thế nào. Nên tìm hiểu những giải pháp CI/CD (Continous Integration/Deployment) để chuẩn hoá và làm tự động hoá quá trình tích hợp – test và deploy hệ thống..

Phương pháp luận và kiến thức về quy trình phát triển phần mềm

software-methodologies
Bạn cần phải trang bị cho mình rất nhiều kiến thức về SDLC (Software Development Life Cycle – Quy trình phát triển phần mềm). Đây là một mảng kiến thức khá rộng. Tuy nhiên, tôi cho rằng có thể tách ra thành 2 thành tố:
  • Các mô hình và phương pháp luận phát triển phần mềm, ví dụ: Waterfall, RUP, Agile …
  • Mỗi mô hình và phương pháp luận sẽ có nhiều best practices được triển khai và vận dụng. Ví dụ: trong XP, có rất nhiều practice hay như: Pair programming, Test First Programming, Real customer involvement …
Điều quan trọng khi làm dự án là cần cân nhắc tuỳ theo tình huống để xem trong dự án mình nên vận dụng phương pháp luận nào và dùng những practices nào để làm cho nó hiệu quả. Mỗi phương pháp luận chỉ nên được áp dụng cho những ràng buộc về ngữ cảnh cụ thể. Không có mô hình nào là tuyệt đối đúng hay tuyệt đối sai trong mọi hoàn cảnh.

Những kĩ năng cần thiết của vai trò lãnh đạo nhóm

Kĩ năng quản lý/phát triển con người

build-and-grow
Bởi vì bạn đóng vai trò phát triển con người trong tổ chức, bạn phải biết được cách:
  • Hiểu được team của mình cần gì? mỗi thành viên đang mạnh/yếu ở điểm nào.
  • Làm sao để động viên mọi người/ cách phát triển những hoạt động nhóm để làm cho mọi người hào hứng/tự hào khi tham gia tổ chức của bạn. Làm sao để khuyến khích mọi người nói ra suy nghĩ của mình, cùng đưa ra giải pháp và những cải tiến để làm cho nhóm càng ngày càng phát triển.
  • Vận dụng những công cụ/ quy trình để làm tăng hiệu suất công việc của nhóm.
Trước đây, khi mới lên vị trí lãnh đạo nhóm, tôi cũng khá ngơ ngác và không biết mình sẽ cần phải làm gì. Tôi tự vạch cho mình những bước đầu tiên để học và trải nghiệm, bao gồm:
  • Tự phân tích mình có điểm mạnh/ yếu gì và tạo sự ảnh hưởng lên các bạn thành viên bằng cách hỗ trợ họ. Làm cho họ cảm thấy rằng mình đem lại giá trị cho công việc của họ. Khi bạn giúp người khác, họ sẽ tự cởi bỏ rào cản khoảng cách với bạn. Họ sẽ tin tưởng bạn hơn. Và đó là bước nên làm để tạo những sức ảnh hưởng ban đầu.
  • Tự tìm hiểu những lý thuyết về quản lý nhân sự – mà tôi đề cập ở trên. Trao đổi với những anh em làm trong mảng nhân sự. Tôi cũng cố gắng đọc một số sách liên quan về quản lý con người, tự trải nghiệm từ cách xây dựng các hoạt động team building (tự đứng ra tổ chức cho nhóm) đến những hình thức motivation (các giải thưởng, phong trào …). Một điều rất quan trọng cần phải lưu ý là: sách chỉ trang bị cho bạn lý thuyết, phải tự vận dụng một cách chọn lọc và trải nghiệm thì bạn mới thấy nó thực sự chuyển thành kĩ năng bạn có.

Kĩ năng uỷ nhiệm (delegate) công việc

Lãnh đạo nhóm là người làm những công việc quan trọng – chứ không phải là làm tất cả mọi việc. Người ta nói: người giỏi không phải là người làm tất cả. Ai cũng biết câu này, ai cũng hiểu. Tuy nhiên không phải ai cũng làm được.
Businesswoman handing papers to businessmen
Businesswoman handing papers to businessmen
Mỗi khi nhận một sứ mạng quan trọng, bạn lập ra bao kế hoạch, chỉ ra được từng bước cần xử lý. Vậy mà, khi giao một công việc cho một thành viên, bạn rất lo lắng vì sợ rằng họ làm sai, không đúng ý bạn. Bạn sẽ có xu hướng tự mình trực tiếp làm công việc đó – hoặc sẽ luôn làm song song để đề phòng trường hợp thành viên của mình làm thất bại. Nếu tiếp tục như vậy, bạn sẽ bị quá tải và dần dần sẽ bị sa lầy trong chính cái bẫy bạn tạo ra cho mình.
Vậy thì, nên làm thế nào? Chỉ cần bạn giữ một số nguyên tắc như sau, bạn sẽ làm tốt việc uỷ nhiệm.
  • Đầu tiên, hãy vượt qua nỗi sợ thất bại. Chính nỗi sợ của bạn cũng sẽ tạo ra sự sợ hãi của chính người được uỷ nhiệm. Thất bại, làm lại – thay đổi cách làm. Bạn còn vài chục năm để sống. Một lần thất bại không thể làm bạn chết được.
  • Hiểu được tính cách, điểm mạnh/yếu của từng người để giao việc phù hợp.
  • Đảm bảo là người được giao việc hiểu rõ mong đợi của bạn. Nếu công việc khá phức tạp, phân chia nó ra thành những công việc nhỏ. Truyền tải định hướng để người ta hiểu rõ bức tranh toàn cảnh, nhưng phải đảm bảo người ta hiểu chi tiết mong đợi của mình ở công việc gần nhất cần làm.
  • Nếu công việc khó hoặc kĩ năng chuyên môn của bạn nhân viên yếu, đừng để đến phút cuối mới kiểm tra kết quả/ cung cấp sự hỗ trợ.
  • Cách bạn kiểm tra công việc cũng phải khéo léo. Không nên hỏi: em làm xong chưa? bao nhiêu % rồi? bao giờ xong? Người lãnh đạo tốt chỉ cần hỏi đúng một câu: em có cần anh giúp gì không và quan sát/lắng nghe trong vài phút là hiểu được thành viên của mình làm đến đâu rồi. Đồng thời, bạn nên cung cấp nhiều sự hỗ trợ cho những thành viên yếu. Nên đưa cho họ hướng giải quyết hơn là tự xông pha vào làm thay công việc cho họ (trừ trường hợp quá gấp).
Cách đây vài năm, tôi được tham gia một lớp học xây dựng kĩ năng cá nhân. Có 1 trò chơi làm tôi thấy rất thú vị. Người dẫn trò yêu cầu mọi người chia thành những cặp chơi. Người đứng phía trước sẽ ngã hết người ra sau. Người phía sau có nhiệm vụ dùng 1 tay để chống lưng cho bạn mình. Cặp nào ngã sâu về phía sau nhất sẽ thắng. Sau khi chơi vài vòng, người dẫn trò chỉ cho chúng tôi thấy một số trường hợp thất bại điển hình.
  • Trường hợp 1: người ở ngoài sau đặt tay quá xa vì muốn thắng nhanh. Khi người phía trước ngã về sau lần đầu, họ bị hụt hẫng và tạo ra nỗi sợ. Vì vậy, những lần sau họ không dám ngã hết mình nữa.
  • Trường hợp 2: người ở ngoài sau biết bạn mình sợ (đặc biệt là bạn nữ), nên chỉ đặt tay ở rất gần. Cứ như thế, đến cuối cuộc chơi thì họ không tạo ra được cú ngã sâu để đạt được mục tiêu.
Cách làm đúng là bạn đứng sau nên đặt tay ở khoảng cách vừa phải – tạo cho bạn mình có lòng tin trong những cú ngã đầu. Từ từ tăng khoảng cách, phải hiểu khi nào bạn mình sợ để quyết định tăng lên hay vẫn duy trì khoảng cách mình đặt ra. Cứ lặp lại như vậy đến khi mình đạt đến mục tiêu cần ngã.
Làm lãnh đạo cũng vậy, bạn phải hiểu và vận dụng nguyên tắc này để các thành viên của mình từ từ vượt qua vùng an toàn của họ, tiến xa hơn đến những mục tiêu mà mình đặt ra, chứ không quá hụt hẫng và bỏ cuộc.
nang-do
Thực tế, có đôi lúc tôi phải tự thú nhận là mình có đôi lần vì sức ép từ khách hàng, công ty – tôi buộc phải tạo ra một áp lực rất lớn cho nhóm để đi thật nhanh đến một mục tiêu khá xa. Thậm chí, rất nhiều bạn cũng từng cho rằng dự án ở thời điểm đó không thể nào thành công. Tuy nhiên, khi làm điều này – tôi thật lòng chia sẻ với tất cả mọi người vì sao tôi phải làm vậy. Đồng thời, phải đóng vai trò người đứng ở đầu tàu, xắn tay áo vào làm và cùng dẫn dắt cả nhóm bằng tất cả ngọn lửa trong trái tim mình. Ở những thời điểm đó, điều kì diệu sẽ đến với bạn. Không có điều gì là không thể nếu bạn thật sự muốn làm và nỗ lực hết mình.

Xây dựng quan hệ

xay-dung-quan-he
Bạn không thể biết mọi thứ. Hãy chấp nhận đó là sự thật. Vậy thì hãy bù đắp lại bằng cách tạo quan hệ với nhiều người giỏi trong những mảng bạn đang thiếu. Có càng nhiều quan hệ thì bạn cũng sẽ có nhiều sức mạnh hơn và sức ảnh hưởng của bạn cũng lớn hơn.
Anh Hoà (một người bạn của tôi – Founder của YouNet) từng đặt cho tôi một câu hỏi làm tôi giật mình:
Em có bao giờ lấy thử tất cả những business card mà em đang có, đặt lên bàn. Thử suy nghĩ xem đã bao lâu mình chưa liên hệ với người này, người kia. Mình đang có những cơ hội hợp tác nào có thể chia sẻ và phối hợp với họ để làm nên thành công? Hay đơn giản chỉ là một buổi hẹn cafe, nhưng nó sẽ làm cho mọi người không quên bạn, chia sẻ nhiều hơn với bạn.
Tôi nghĩ rằng đây là một thói quen tốt nếu bạn làm điều này thường xuyên. Nó thực sự sẽ làm thay đổi mọi thứ xung quanh bạn. Thử đi, bạn sẽ thấy.

Lời kết cho bài này

Dù làm ở vị trí lãnh đạo nào, bạn cũng phải thật giỏi năng lực chuyên môn. Tuy nhiên, khi ở vai trò này – bạn phải đi sâu hơn về quy trình và phương pháp luận phát triển phần mềm,  biết cách quản lý rủi ro, quản lý cấu hình và vận dụng những practices/ công cụ để làm cho nhóm hoạt động tốt nhất.  Tôi chỉ cho bạn một định hình. Còn về cách học – bạn nên tự tìm hiểu và thử trải nghiệm. Đó là cách tốt nhất để bạn thấm. Nói lý thuyết nhiều chỉ nghe đã tai chứ không thể làm bạn cảm được bằng cả trái tim.
Bên cạnh đó, phải xây dựng cho mình những kĩ năng mềm cần thiết. Mặc dù tôi chia ra một số kĩ năng cần cho Lãnh đạo dự án và lãnh đạo nhóm dựa theo độ quan trọng và cần thiết. Tuy nhiên, tôi khuyến khích các bạn nên luyện cho mình tất cả những kĩ năng này. Chúng sẽ luôn có ích cho bạn. Tin tôi đi.
Đừng bao giờ nghĩ rằng: vì em chưa làm lãnh đạo nhóm, em chưa cần rèn luyện chúng. Mỗi một kĩ năng tôi trình bày ở trên đòi hỏi một khoảng thời gian rất lâu để cảm, vận dụng và chuyển thành kinh nghiệm. Hãy bắt đầu từ những điều nhỏ nhất mà bạn có thể học và làm được trong chính công việc bạn đã, đang và sẽ làm.
Trân trọng.
<Nguồn: Điều thú vị>