Sự năng động của tuổi trẻ và kinh nghiệm tuổi già trong ngành phần mềm

Trong một buổi training + open talk về kĩ thuật cho công ty của một người bạn, có một bạn trẻ đặt cho tôi 2 câu hỏi:
1/ Em thấy nhiều người cho rằng kinh nghiệm của những người đi làm lâu năm chiếm ưu thế hơn so với sự nhạy bén và sáng tạo của tuổi trẻ - theo anh, quan điểm này đúng hay sai? Em cảm thấy rằng, người trẻ thường nhanh nhạy trong việc giải quyết vấn đề. Và em nghĩ đây mới là điều quan trọng trong ngành phần mềm.

2/ Em nghĩ rằng tuổi thọ của ngành phần mềm chỉ dừng lại ở độ tuổi 40. Vì sau thời điểm đó, con người không còn đủ sự nhanh nhạy và sáng tạo nữa - mà sáng tạo chính là yếu tố sống còn đối với một người đi theo ngành này. Vậy điều này có đúng không? Nếu đúng, anh hãy cho em 1 lời khuyên: em nên làm gì khi ở tuổi 40?

Tôi nghĩ rằng đây là cũng là thắc mắc của khá nhiều người. Vì vậy tôi post 2 câu hỏi này lên đây để chúng ta cùng trao đổi.

Dưới đây là nguyên văn câu trả lời của tôi cho bạn trẻ đã nêu ra 2 câu hỏi trên:
1/ Anh đánh giá rất cao sự sáng tạo và nhạy bén của tuổi trẻ. Ngành phần mềm hay bất cứ ngành nào khác đều rất cần sự sáng tạo. Tuy nhiên, kinh nghiệm cũng là một yếu tố rất quan trọng. Kinh nghiệm giúp ta định hướng vấn đề đúng đắn hơn. Một cách dễ hình dung, có thể xem rằng:

Sự sáng tạo của người trẻ thường giúp trả lời nhanh cho câu hỏi: HOW, WHAT.
Kinh nghiệm của người già thường giúp trả lời nhanh câu hỏi WHY

Biết HOW, WHAT, mà không trả lời được WHY thì sẽ không định hướng được và không hiểu được bản chất vấn đề. Biết WHY, mà không trả lời được HOW, thì sẽ không hiện thực được bất cứ điều gì.

Tuy nhiên, WHY là câu hỏi được đánh giá quan trọng nhất trong cuộc sống. Nếu nhìn lại lịch sử của khoa học, tất cả mọi phát minh, tri thức của nhân loại phần lớn đều bắt đầu từ câu hỏi TẠI SAO. Chính vì vậy, kinh nghiệm được ưu tiên hơn một chút so với sáng tạo. Tuy nhiên, điều này không hẳn hoàn toàn đúng - vì nó còn phụ thuộc vào hoàn cảnh cụ thể.

Nên kết hợp cả hai yếu tố này để tối đa hóa sức mạnh sẵn có của chúng.

2/ Nếu nhìn lại những cây đại thụ trong ngành phần mềm: Robert C. Martin, Kent Beck, Martin Fowler... Phần lớn họ là những người đã vượt qua 40 tuổi. Tuy nhiên, ngày nay họ vẫn tiếp tục đóng góp rất nhiều cho ngành phần mềm và đạt được nhiều thành công trong cuộc sống.

Như anh đã đề cập ở trên, sáng tạo là cần thiết nhưng ko phải là tất cả. Khi có nhiều kinh nghiệm, em sẽ được sắp xếp ở vị trí để em phát huy tối đa sức mạnh đó - và thường là những vị trí quan trọng. Cũng không ai nói rằng người già thì không còn sáng tạo. Giá trị của những sáng tạo ở tuổi già thường đem lại những đóng góp vĩ đại vì nó được thai nghén và kết hợp với kinh nghiệm thực tiễn.

Do đó, đừng quá lo sợ. Điều đáng sợ nhất là: mình đã quá già nhưng không có kinh nghiệm mà cũng không có sự sáng tạo.


Anh không thể cho em lời khuyên ở tuổi 40, nhưng anh có thể cho em lời khuyên ở hiện tại: hãy cố gắng rèn luyện bản thân, nâng cao kinh nghiệm trong công việc, trau dồi kiến thức. Và điều cơ bản hơn cả là: hãy đam mê. Trong bất cứ ngành nghề nào, nếu leo đến đỉnh cao sự nghiệp cũng đều đem lại vinh quang như nhau.

Những câu hỏi trong một khóa đào tạo leadership

Công ty cho mình học một khóa đào tạo về leadership - management. Dưới đây là một số câu hỏi/ câu trả lời nghĩ ra trong đầu sau 2 buổi học đầu tiên. Có thể câu trả lời sẽ không giống với những gì tôi đã học. Tuy nhiên, đó là những gì tôi đã chiêm nghiệm.
Có một số câu hỏi tôi không muốn trả lời - tôi mong đợi ý kiến phản hồi của các bạn.



1/ Sự khác nhau giữa quản lý (management), quản lý dự án (project management), quản lý dự án phần mềm (software project management) là gì?
Trả lời:
a. Quản lý là một hoạt động bao gồm 4 chức năng: leading (lãnh đạo), controlling (điều khiển), tracking (theo dõi) và planning (lên kế hoạch)
b. Quản lý dự án là việc áp dụng 4 chức năng này vào những dự án cụ thể
c. Quản lý dự án phần mềm: giống với quản lý dự án nhưng dành cho đặc thù của lĩnh vực phần mềm

2/ Sự khác nhau giữa leading và management:
Trả lời:
Có 2 quan điểm chủ yếu:
Quan điểm 1 (theo kiến thức từ khóa học):
+ Management là việc quản lý con người nói chung. leading là thiên về quản lý NHÓM.
+ Leading hiểu theo nghĩa tiếng Việt là lãnh đạo - sẽ bao hàm việc định hướng - vạch ra chiến lược - điều khiển - kiểm soát một nhóm để đạt được mục tiêu chung. Management chỉ vạch ra mission và goal ở mức tổng thể - không bao hàm việc định hướng/ điều khiển nhóm để đạt được mục tiêu ở mức hiện thực chi tiết.
Quan điểm 2 (quan điểm từ bản thân và một số kiến thức trước đây):
+ Leading là một trong những chức năng của management.
+ Một người làm management thực ra luôn luôn thực hiện 4 chức năng: leading, controlling, tracking và planning. Tuy nhiên việc phân bổ trọng số cho 4 chức năng này sẽ khác nhau tùy vào vị trí của cấp quản lý.
+ Có 3 cấp quản lý chính: quản lý cấp thấp (thiên về controlling + tracking + leading), quản lý cấp điều hành ( thiên về leading), và quản lý cấp cao (thiên về planning).
3/ Dự án phần mềm có gì đặc thù so với những loại dự án khác? Quản lý dự án phần mềm khác gì so với quản lý dự án?
Trả lời:
Dự án phần mềm là loại dự án đặc thù gồm các đặc điểm:
+ Là kết tinh bởi chất xám và sự hợp tác giữa nhiều con người trong một nhóm. Do đó việc quản lý dự án phần mềm có xu hướng thiên về con người.
+ Việc đánh giá sự đóng góp của con người trong dự án phần mềm không có một độ đo cụ thể và chính xác so với những loại dự án khác.
+ Việc gia tăng số lượng người trong một nhóm sản xuất không tỉ lệ thuận với việc thúc đẩy tiến độ dự án. Do đó trong quản lý dự án phần mềm không thể áp dụng nguyên tắc dùng số đông để đẩy nhanh tiến độ.
+ Việc lãnh đạo một nhóm sản xuất phần mềm không chỉ đơn thuần là việc đưa ra phương hướng và bắt người khác đi theo như những loại dự án khác. Nó đòi hỏi việc truyền cảm hứng và tạo sự đồng thuận cho nhóm để bám sát và hoàn thành mục tiêu.
+ Quản lý dự án phần mềm đòi hỏi người quản lý phải có kiến thức tốt về phần mềm để đưa ra những quyết định, kế hoạch hợp lý.
Câu hỏi bổ sung: liệu một người đã từng làm tốt vị trí quản lý dự án nhưng ít kinh nghiệm quản lý dự án phần mềm có thể quản lý tốt một dự án phần mềm?
Trả lời: đợi ý kiến phản hồi

4/ Chọn ra những tính cách và kĩ năng quan trọng nhất của một người lãnh đạo giỏi?
Trả lời

Tôi không muốn lặp lại những điều đã học trong lớp - vì đây là một câu hỏi đã có câu trả lời trong buổi thảo luận. Tuy nhiên quan điểm của tôi là việc lựa chọn này tùy thuộc vào phong cách lãnh đạo phù hợp.
Mỗi người có thể lựa chọn cho mình một phong cách lãnh đạo khác nhau. Với mỗi phong cách sẽ có một tập những tính cách và kĩ năng cần trau dồi khác nhau.

Ở những hoàn cảnh/ môi trường/ tập thể con người cụ thể phải có một phong cách lãnh đạo khác nhau vì để lãnh đạo hiệu quả thì không thể áp dụng cùng một phong cách cho mọi hoàn cảnh.

5/ Đỉnh cao của nghệ thuật quản lý là gì?
Trả lời:
Quan điểm 1 (từ một người bạn): đỉnh cao của nghệ thuật quản lý là quản lý mà người được quản lý không có cảm giác đang bị quản lý.
Quan điểm 2 (quan điểm của tôi): đỉnh cao của nghệ thuật quản lý là định hướng và tạo ra những con người có thể tự quản lý chính mình và làm tốt những gì mình cần làm trong tổ chức.

Quan điểm n: đợi phản hồi của mọi người.

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

Là dân IT hẳn mọi người không còn xa lạ với cụm từ Software Architect (SA) - ở đây tôi tạm dịch là kiến trúc sư phần mềm. Tuy nhiên không phải ai cũng hiểu được vai trò, trách nhiệm, công việc thực sự và con đường sự nghiệp của một SA. Đây là những câu hỏi mà tôi đã từng đặt ra khi bước vào những nấc thang đầu tiên của vị trí này. Tôi tự đi tìm lời giải đáp cho mình.

Phân loại kiến trúc sư phần mềm

Thật ra có nhiều cách để phân loại kiến trúc sư phần mềm. Tuy nhiên, ở đây tôi sử dụng cách phân loại của Microsoft.  Đây cũng là một cách thức phân chia khá phổ biến trong ngành phần mềm hiện nay.

Tên	Mô tả
Kiến trúc sư nghiệp vụ (enterprise architect)	Là cầu nối giữa chủ sở hữu sản phẩm và đội ngũ kĩ thuật. Họ  là những người có kinh nghiệm chiều sâu trong lĩnh vực mà sản phẩm đang xây dựng. Chịu trách nhiệm trong việc xây dựng và phát triển yêu cầu - thiết lập viễn cảnh, bộ khung của môi trường IT trong sản phẩm.
Kiến trúc sư hạ tầng (infrastructure architect)	Là người chịu trách nhiệm trong việc thiết lập, xây dựng giải pháp về cơ sở hạ tầng IT (ví dụ: mạng, các vấn đề bảo mật, thiết bị/ phương thức lưu trữ, ..) trong sản phẩm để đáp ứng nhu cầu của doanh nghiệp.
Kiến trúc sư giải pháp (solution architect)	Là người chịu trách nhiệm trong việc thiết kế, xây dựng giải pháp cho những yêu cầu của sản phẩm.
Kiến trúc sư kĩ thuật (Technology-specific architect)	Là người chịu trách nhiệm về một hoặc một số lĩnh vực kĩ thuật cụ thể.

Trong một số công ty hiện tại ở Việt Nam, có một vị trí gọi là Technical Architect (kiến trúc sư kĩ thuật) trong tổ chức. Vị trí này chịu trách nhiệm cho việc phân tích, đánh giá giải pháp, xây dựng kiến trúc hệ thống. Nếu ánh xạ với cách phân loại trên thì TA chính là Solution Architect.

Những tính cách cần thiết của một kiến trúc sư phần mềm giỏi

Cho dù bạn có là kiến trúc sư phần mềm nào, thì dưới đây là những tính cách bắt buộc phải có để đạt được đỉnh cao của nghề này:

1. Nhạy bén về kinh tế: mọi kiến trúc sư khi đưa ra giải pháp cho bất cứ bài toán nào cũng đều phải cân nhắc chi phí, lợi ích tương quan của doanh nghiệp. Đây là yếu tố then chốt đánh giá hiệu quả của một giải pháp.
2. Có tầm nhìn xa: khi tham gia vào một dự án, kiến trúc sư phải cân nhắc những giải pháp, công nghệ sắp xuất hiện, xem xét những thay đổi gần đây trong lĩnh vực công nghiệp đang phát triển... và làm cách nào để tận dụng tối đa giải pháp hiện tại trong tương lai.
3. Nghiên cứu kĩ thuật mới: một kiến trúc sư phải luôn luôn nghiên cứu những hướng kĩ thuật mới, từ kiến trúc IT cho đến những ứng dụng và xu hướng phát triển ứng dụng
4. Hiểu và có khả năng ứng dụng những framework,kiến trúc hệ thống, phương pháp luận trong quá trình phát triển phần mềm
6. Có thể làm việc trên những thông tin còn chưa rõ ràng.
7. Khả năng truyền đạt và giao tiếp

Làm sao để tôi có thể trở thành một kiến trúc sư phần mềm

Kiến trúc sư phần mềm là đỉnh cao của thang nghề nghiệp khi bạn chọn đi theo con đường kĩ thuật. Để trở thành một kiến trúc sư phần mềm, bạn nên theo những bước sau:
1. Định hướng rõ ràng về loại kiến trúc sư phần mềm bạn muốn trở thành
2. Xác định và xây dựng những kĩ năng cần thiết. Liên tục bổ sung kiến thức phù hợp cho loại hình kiến trúc sư mà bạn chọn
3. Không ngừng phấn đấu và khẳng định vai trò của một kiến trúc sư trong chính những dự án mà bạn đang tham gia.
4. Cố gắng rèn luyện và lấy những chứng chỉ quốc tế về kiến trúc sư kĩ thuật của những tập đoàn công nghệ lớn (Microsoft hoặc Sun). Microsoft bạn cần lấy được MCA (Microsoft Certificate Architect). Đối với Sun, bạn cần lấy được chứng chỉ: SCEA (Sun Certificate Enterprise Architect)

Con đường để trở thành một kiến trúc sư phần mềm đỉnh cao và chuyên nghiệp vẫn còn ở rất xa. Và có một điều tôi luôn tâm niệm là: dù ở bất kì ngành nghề nào, vị trí nào - việc phấn đấu để đạt được đỉnh cao trong sự nghiệp cũng đều đem lại những lợi ích như nhau so với những vị trí hoặc ngành nghề khác.

Cố gắng hơn nữa!

Request đi từ Windows live writer preview mode - tìm ra rồi

Vừa ăn Tết xong đã bị khách hàng dzí vì một issue trên plugin viết cho Windows Live Writer. Issue đơn giản như thế này:

Module mình vừa release là một plugin viết cho Windows Live Writer (một công cụ soạn thảo blog của Microsoft có thể tích hợp với nhiều blogging platform). Chức năng chính của module là cho phép tìm kiếm một số thông tin đặc biệt và nhúng nội dung tìm được vào cửa sổ blog editor của Windows Live Writer. Khách hàng mong đợi ở chế độ preview của editor này có thể nhìn thấy nội dung hiển thị như khi xem trên blog thật. Tuy nhiên, vì một số hạn chế kĩ thuật dưới đây nên ở preview mode, html content bị vỡ layout và không show được một số phần content liên quan đến business của khách hàng.
1. Windows Live Writer sử dụng một browser engine khác trong preview mode và chặn một số script đặc biệt
2. Cơ chế render nội dung của browser engine này xử lý không tốt cho CSS 2.0 => vỡ layout.

Chính vì những hạn chế này, product manager của khách hàng yêu cầu: chỉ render ra một nội dung HTML đơn giản (chỉ show image tag) ở chế độ preview mode.

Sau khi suy nghĩ về solution trong vài ngày đầu - mình hoàn toàn bị tắc nghẽn. Vì để làm được điều này ta cần biết được request nào đi từ Windows Live Writer và request nào đi từ browser mà user đang duyệt web bình thường. Biết được điều đó ta có thể chặn và render ra những đoạn javascript để sinh ra HTML đúng như mong đợi.

Dưới đây là những phương pháp tôi đã thử:
1. Phân tích http request header khi đi từ Windows Live Writer và request đi từ các browser khác.
Kết quả: hoàn toàn giống nhau. WLW sử dụng một browser engine build từ một version trước của Internet Explorer.
2. Kiểm tra URL referer ở phía client trên WLW và các browser khác:
Kết quả: đều bằng null. Điều này chứng tỏ: WLW preview page được render trực tiếp mà không đi qua trang trung gian nào

Đã trao đổi với technical team của khách hàng để họ hiểu được issue. Critical bug này được chuyển sang cho một developer của team họ để giải quyết. Kết quả: Họ cũng không có solution sau hơn 3 tuần mò mẫm.
Tuyệt vọng!!!

Ngày đầu năm, bị sếp dzí và cho biết khách hàng đang complain. Sếp yêu cầu viết mail cho Microsoft nhờ support. Lên trao đổi với anh T - production manager để giúp anh hiểu vấn đề về những khó khăn hiện tại.
Bước ra khỏi thang máy với cái đầu hoang mang trăm chuyện. Quyết định: uống một ly cafe cho sáng suốt. Đúng là cafe có tác dụng cho những hoàn cảnh như thế này. Uống xong bỗng lóe lên một hy vọng.
Phát hiện ra là mình chưa kiểm tra URL referer khi WLW request về phía server (lúc trước chỉ kiểm tra toàn http header).
Và dưới đây là kết quả:
Đứng từ WLW ở preview mode khi request về server thì URL Referer luôn bằng null. Thông thường, khi ta include một file javascript vào một trang - nếu chặn ở server ta sẽ thấy URL referer của request đến nó chính là URL của trang đang chứa đoạn script include này. Riêng với WLW, nó lại là NULL. Đây chính là tín hiệu giúp ta phân biệt được đâu là request từ Windows Live Writer và đâu là request đi từ browser bình thường.

Xong!