Với những trang thương mại điện tử lớn, có những ngày lượt truy cập lên tới hàng triệu mỗi giây. Vậy cách giải quyết của những kiến trúc sư – architect trong những tình huống trên là gì? Cùng trò chuyện cùng anh Trần Phong Phú – Solution Architect đến từ Sendo để học hỏi kinh nghiệm của anh khi đưa ra được cái nhìn tổng quát để có những giải pháp cho từng vấn đề của hệ thống.
Xem thêm Solution Architect là gì? Vai trò của họ trong vận hành hệ thống?
Vài nét về khách mời Trần Phong Phú
Về công ty Sendo:
- Là một công ty công nghệ do chính đội ngũ kỹ sư con người Việt Nam xây dựng nên.
- Vai trò và sứ mệnh của Sendo được đóng gói rất đơn giản, dùng thương mại điện tử đại diện cho quốc gia.
Đảm nhận vai trò Solution Architect, công việc của anh xoay quanh:
- Đóng góp vào sự phát triển tốt lên mỗi ngày của công ty, theo hướng cải thiện những gì chưa tốt.
- Phát hiện ra những yếu tố bất thường để tìm cách giải quyết nó.
- Thúc đẩy planning và chiến lược, làm thế nào để giúp công ty phát triển về mặt công nghệ, sự tăng trưởng.
- Đáp ứng mục tiêu, thay đổi về mặt tổ chức hay về mô hình hoạt động của công ty.
Một ngày làm việc bình thường của mình là sáng đến công ty, mình tham dự các buổi DSM chung với mọi người để nắm bắt công việc, các issue nào đó. Sau đó mình sẽ tìm kiếm trưởng bộ phận khác để trao đổi và thảo luận vấn đề cần giải quyết như thế nào. Sau đó mình về bàn làm việc của mình cứ như vậy làm việc thôi.
Chia sẻ những kinh nghiệm thực tế tại Sendo
Vào những dịp khuyến mãi lớn (10/10, 11/11,…) lượng người truy cập tăng cao. Vậy làm sao để hệ thống không bị chậm hay bị sập?
Cái này mình nghĩ về mặt kỹ thuật hầu như mọi người đều có sự hiểu biết về hệ thống, nên việc đối phó những cái này như nhau. Ví dụ như Tiki, chương trình “Giựt cô hồn”, phần lớn trong trường hợp này chúng ta chuẩn bị một kịch bản, giả lập tình huống, như vậy chúng ta có thể chuẩn bị hạ tầng, máy móc các tình huống chúng ta phải đối phó với nó, Chúng ta xây dựng các nền tảng như vậy để khi có lượng truy cập vào thì đúng với kịch bản của mình chứ không phải mình bị bất ngờ.
Vì khi hệ thống sập, ví dụ như mình chạy chương trình lúc 12h, nhiều khi nó sập mình mất cả nửa tiếng đến một tiếng khắc phục chuyện đó thì gần như nó qua khung giờ vàng rồi cho nên không cần thiết, cơ bản là các nền tảng phải thiết lập sẵn để đối phó với chuyện như vậy. Nhiều khi chúng ta chỉ muốn 1 thôi nhưng offer lên 5 hoặc 10 luôn thì có thể làm được như vậy.
Tỷ lệ rủi ro bị sập là bao nhiêu khi mà nhiều khi mình chuẩn bị sẵn nhưng có nhiều tình huống phát sinh?
Như nãy mình nói, mình muốn 1 nhưng mình có thể chuẩn bị từ 5 đến 10, cho nên là từ khi mình vào công ty, chưa bao giờ chứng kiến những cái đó, những hậu quả mà không ai nghĩ sẽ diễn ra. Về mặt hệ thống, sẽ có những lúc bị chập chờn, cơ bản mình sẽ thiết kế hệ thống nào đó, gần như là trải nghiệm người dùng tại thời điểm đó đơn giản là mình xem sản phẩm gì đó rất hot, người dùng họ vào cái đó và họ mua cái đó thôi, trải nghiệm rất là đơn giản, click được sản phẩm họ chuẩn bị sẵn từ trước đó rồi, họ mua, họ bấm nút và họ thanh toán, mình chỉ làm sao có flow đó nó smoothly thôi, chứ người dùng họ không vào để làm chuyện khác, nói chung huy động hệ thống hơi lớn để đáp ứng phép flow đó. Cá nhân mình thấy các công ty thương mại điện tử, hoặc bất kỳ công ty nào cũng không thể fail trong tình huống đó được.
Từ lúc tốt nghiệp thì anh xác định theo con đường Solution Architect luôn hay anh thử sức với nhiều vị trí khác nhau và cuối cùng chọn con đường này?
Mình cũng chưa từng nghĩ mình làm ra là trở thành Solution Architect. Tới bây giờ mình mới hiểu được là rất khó để một bạn developer nào tốt nghiệp ra trường lại lựa chọn con đường đó, cái đó giống như là khi mình thành công mình quay lại mình tô vẽ career path thì hợp lý hơn. Bất cứ ai cũng đều muốn việc mình thành công, nên đơn giản là một người sinh viên ra trường việc họ muốn là thành công, cái sự thành công đó tùy theo giai đoạn.
Ví dụ như mình đi làm cũng hơn 10 năm, mỗi lúc nghĩ về sự thành công nó đều khác nhau. Thời còn trẻ mới ra trường, thành công của mình là title gì đó nghe nó kiêu kiêu, như là leader chẳng hạn để mình kiếm được nhiều tiền, sau này rồi thì thấy sự thành công khác đi. Tạm thời mình đủ ăn đủ mặc rồi, nên bây giờ mình mong muốn làm sao để đóng góp giá trị bản thân mình cho công ty, cho cộng đồng.
Tại sao Sendo lại lựa chọn mình trở thành Solution Architect, hoặc trước kia ở các công ty là người design các hệ thống, bởi vì trước đây mình là người xây dựng các hạ tầng, ví dụ mình làm ra cái đó mình sẽ chịu trách nhiệm đến cùng với nó. Không thể lúc nào mình desgin từ ban đầu cũng đúng, nhưng khi có cái gì sai thì mình là người có trách nhiệm đi khắc phục, khi đó mình được tin tưởng từ người mentor của mình, người lãnh đạo của mình, họ cho mình cơ hội để mình thực hành chuyện đó.
Anh hãy chia sẻ vấn đề làm một leader có tâm là như thế nào?
Như thế nào là leader có tâm, thì mình tin vào một người, khi mình gặp bế tắc, người đó sẽ chỉ giúp mình, mình sai từ đâu và mình nên làm lại như thế nào cho đúng, làm bản thân mình strong lên, mình có thể đủ lông, đủ cánh, mình có thể tiếp tục cống hiến cho công ty đó tiếp hay mình có thể rời bỏ để chuyển vị trí khác, mình làm, mình phát triển được bản thân. Một người leader, mentor có tâm như một người anh có tâm, không thể để em của mình, đồng nghiệp của mình núp sau bóng mình mãi được. Đối với mình như vậy là có tâm.
Lúc đảm nhiệm vị trí Solution Architect thì anh tưởng tượng công việc đó như thế nào? Và thực tế nó có giống như anh tưởng tượng không?
Mình tốt nghiệp đại học, mình là cử nhân hay kỹ sư gì đó, đó như là certificate chuẩn do bộ cung cấp rồi. Một người đạt tiêu chuẩn như vậy hầu như đều có background về toán học, về triết học, hay cái gì đó nó giống như nhau, gần như là có nền tảng giống nhau.
Còn nói về vị trí công ty, đơn giản như senior, ở đây họ là senior nhưng ở kia chưa chắc là senior. Một vị trí như full-stack developer, thì ở chỗ khác họ define full bao gồm cả devops hay thế này thế nọ, còn ở chỗ khác thì anh biết làm web, anh biết làm back-end, front-end như vậy thì là full-stack rồi. Thì vị trí solution architect cũng vậy, cũng tùy công ty định vị về vai trò này nọ khác nhau. Đối với vị trí của solution architect mình nghe mọi người nói vị trí Architect cần có 4 định hướng hay thấy mọi người làm về chiến lược, về chiến thuật, hay làm về article hay planning.
Phần lớn các tiệm ăn thiên về các mảng phía dưới, không phải làm về chiến lược, chủ yếu làm về chiến thuật, làm về emplacement, planning. Ví dụ như khi công ty giao cho mình việc gì đó, mình nghĩ về mặt placement thì như thế nào, về mặt các kĩ thuật, chiến thuật mình làm như thế nào. Ví dụ các bài toán phải đòi hỏi thực sự về tư duy, về cách làm, chứ không phải cứ nhào vô mà làm được.
Ví dụ như bài toán về notification chẳng hạn, mảng thương mại điện tử, một user có rất nhiều device, mình không biết user xài cái nào và có hàng chục triệu user như vậy. Thì tất nhiên các nền tảng bây giờ mình nghe đơn giản là đã có, chẳng hạn như Google Drive Space này nọ nó bắn rồi, vậy mình care cái gì về nó. Giả sử mình cần thống kê về số lượng notification ai đọc và chưa đọc, mình phải lưu lại thông tin user đó với tin nhắn đã đọc hay chưa True – False, nó lên đến hàng triệu messages, nói chung con số nó khủng khiếp, và nhiều tháng thì con số nó khủng khiếp hơn nữa. Và mỗi lần bắn 1 tin marketing như vậy nó có thể hoàn toàn gây ra tắc nghẽn hay đình trệ. Câu hỏi đặt ra là mình cần có chiến thuật, cách làm để mình đảm bảo được requirement và vừa phát triển tính năng đó không bị bế tắc, nếu như mà sập hệ thống là mình bế tắc rồi. Mình có thể làm được điều đó bằng cách planning, bước 1 làm gì, bước 2 làm gì, thường thường công việc của anh hướng như vậy.
Anh có thể tóm gọn khái niệm về Solution Architect theo quan điểm của anh được không?
Mình có thể tìm hiểu các tổ chức lớn, khi define role như thế nào thì mình có thể nhìn theo đó một cách tổng quát. Nhưng trong buổi phỏng vấn mình chia sẻ về Software Architect thiên về hướng emplacement, về chiến thuật, còn ví dụ như về Technical Architect thiên về strategy cộng với emplacement, đó là các tổ chức người ta làm.
Còn khi nói chung một người làm về software, về mặt bản thân người đó cần có một số skills nhất định, cần có skill về kỹ thuật là một điều kiện kiên quyết, nhưng ngoài ra cần có hiểu biết về business nữa, người làm business đã cực khổ đi kiếm khách hàng về, nhưng người làm về kỹ thuật không hiểu biết về business lại trách móc khách hàng stupid thì hai bên sẽ khó giao tiếp với nhau. Rồi mình phải hiểu về process để cho mọi thứ hoạt động trơn tru, một tổ chức càng lớn thì process càng hoàn thiện. Cuối cùng kỹ năng gần như chúng ta cần phải học suốt đời, kỹ năng communication, xây dựng các mối quan hệ tốt đẹp, giống như là relationship.
Riêng những bạn muốn đi theo con đường Solution Architect thì anh có lời khuyên gì cho xuất phát điểm cũng như lộ trình học tập của mấy bạn không?
Rất khó để mà mình khuyên một bạn nào đó ra trường đi theo con đường Solution Architect, làm thế nào để mình thuyết phục được người khác là tui giỏi lắm rồi, bây giờ tui sẽ đảm nhận vị trí solution architect ở công ty của mình, tui làm vị trí này, tui sẽ đem về benefit thật là lớn cho anh? Công ty mình có tổ chức, có những người đã từng đóng góp có người đồng hành của mình rồi, nên là mình không thể nào thấy một người này mà bỏ người kia, nó có rất nhiều yếu tố khiến cho người lãnh đạo – người đồng ý nhận mình làm vị trí solution architect – họ phải cân nhắc, mình phải thỏa các điều kiện không chỉ bản thân mình thôi là mình sẽ làm được.
Nhưng, một bạn developer làm thế nào trong quá trình từng giai đoạn mình phát triển bản thân thì mình phát triển đúng với giai đoạn của mình. Ví dụ như mình mới ra trường, một trong những điều mình thiếu là skill về technical, tại vì ở trường người ta dạy tổng quát mình cũng phải hoàn thiện các skill còn lại, về mặt ngôn ngữ, hệ thống, chiến thuật, database và tất cả những gì mà mình chưa biết, sau đó mình tiếp tục hoàn thiện các skill về business. Và tất nhiên đầu tiên mình là người mới ra trường, chẳng ai đi trao đổi business với mình cả, đi ra ngoài bô bô về business thì thấy hơi trẻ con một chút; rồi nói về quy trình, những người làm về quy trình phải có kinh nghiệm mới làm về quy trình được, chứ mình còn trẻ mà vào làm quy trình thì sẽ bị xáo trộn mọi thứ, rồi sau này mình lớn, mình trở thành senior rồi thì tất nhiên mình mới nói về xây dựng mối quan hệ tốt đẹp, ý là lúc mình còn trẻ mình cũng có nhưng đó là với bạn bè, đồng nghiệp thôi, còn xây dựng mối quan hệ mà mình muốn đề cập để lúc nào mình làm việc cũng smoothly. Mình nghĩ mọi người cứ đi theo từng giai đoạn, từng nấc của cuộc đời như vậy, đến một lúc nào đó trở thành Solution Architect vị trí manager, hoặc có thể mình chọn trở thành vị trí lập trình viên bình thường thôi, cũng là sự lựa chọn của bản thân mình, happy với sự lựa chọn đó.
Ví dụ như mình làm Solution Architect, và lúc nào mình cũng phải đi tranh luận, thuyết phục người khác, rất tốn năng lượng và mất rất nhiều thời gian, mình nghĩ chuyện này chuyện kia, không có thời gian chăm sóc gia đình con cái, còn khi mình là lập trình viên, mình lên mình nhận đúng task và mình làm và tất nhiên mình cũng tạo ra mọi thứ tốt đẹp trên thế giới này thôi và rồi mình về mình ăn ngon ngủ yên, đó là sự lựa chọn của cuộc đời.
Tại sao anh chuyển sang làm về E-commerce? Có phải do tiềm năng nào đó hay có thách thức mà anh muốn khám phá không?
Bản thân mình mọi thứ đến với mình một cách tự nhiên. Ở những công ty lớn họ có rất nhiều điều hay để mình học hỏi, giống như mình nghĩ ở một công ty nhỏ tất nhiên nó đã có một đầu vấn đề rồi mình làm mình cũng biết, nhưng khi ở công ty to nó càng có nhiều vấn đề nữa và làm thế nào để học vận hành bộ máy to như vậy thì đó là một cái thách thức, nếu như mình nhìn vào và nghiên cứu kỹ phần đó sẽ thấy được cách họ giải quyết rất là hay.
Gameloft là một công ty rất to, vận hành có lớp lang, những người mới vào được training một cách bài bản, công việc thì có công cụ để mà khi giao đến từng người thì rõ ràng, mạch lạc; một công ty có giàn hậu thuận đằng sau rất lớn những người giỏi về mặt kỹ thuật, do vậy khi mình ở đó mình được học rất là nhiều. Bài học đầu tiên ở Gameloft mà mình học được đó là các mình em đồng nghiệp rất là máu lửa, tầm nhìn rất xa, thời điểm đó mình ra trường, mình không hiểu vì sao họ lại có được như vậy, và nó giúp mình đặt ra được khát vọng để mình được giống như họ. Lần thứ 2 là mình hiểu được áp lực của người làm business là như thế nào, mình mới thấy thông cảm cho vị trí quản lý của mình, họ chịu rất nhiều áp lực, đó là bài học đầu tiên khi mình làm ở Gameloft mình nhận được.
Sau đó mình làm về công ty outsourcing, cũng làm về product, nhưng mà trong công ty có phát triển sản phẩm chuyên đi thu thập dữ liệu và tách ra thành công ty gọi là Unit Media, để làm về thu thập và phân tích dữ liệu, ở đó cũng có nhiều bài học, là nơi mình trưởng thành thật sự về mặt kỹ thuật. Requirement của sản phẩm đó, nghe thì đơn giản nhưng mà nó phức tạp thế này, mình phải thu thập dữ liệu làm sao nhanh nhất, những nội dung mà người VN mình trao đổi bằng tiếng Việt có ở tất cả các kênh truyền thông phải thu thập về sau nhanh nhất để khách hàng của mình để họ biết được khách hàng của mình đang complain chuyện gì đó trong thời gian rất ngắn để mà đội xử lý truyền thông can thiệp kịp thời, đánh giá tình hình, xem xét và xem cách giải quyết như thế nào.
Giai đoạn sau mình làm ở Sendo, là công ty to và phát triển nhanh, vì vậy đòi hỏi mình phải thiết kế hệ thống thích nghi được sự phát triển nhanh như vậy, với lượng người dùng, lượng traffic lớn, mình cũng phải thiết kế hệ thống làm sao đáp ứng được những chuyện đó. Về thương mại điện tử thì các công ty đều quan tâm yếu tố security, thì mình cũng phải tìm hiểu những chuyện như vậy.
Quay lại câu hỏi “cơ duyên nào chuyển qua thương mại điện tử”, thực ra mình nghĩ đó chuyện cũng giống bao người. Khi mình cũng trưởng thành và cần tìm một môi trường khác thử thách hơn, người anh hiểu năng lực của mình và giới thiệu mình sang một nơi khác phù hợp và mình tiếp tục qua đó đón nhận những thử thách mới, là lúc mình qua làm e-commerce, mình thấy đó là quyết định đúng đắn.
Công nghệ nào đáng sử dụng cũng như ưu/nhược điểm của công nghệ đó?
Đối với suy nghĩ của mình 1 bạn lập trình viên thì nên học ít nhất là 2 ngôn ngữ và nên giỏi ít nhất là 2 ngôn ngữ. Thí dụ như mình có thể giỏi về Golang cả PHP, hay PhP và NodeJS chẳng hạn, rồi về mặt Database, mình nên giỏi cả dựng như cơ sở dữ liệu quan hệ như MySQL, và các cơ sở dữ liệu không mối quan hệ như MongoDB mình còn gọi là NoSQL á. Về mặt framework mình cũng nên biết ít nhất là 2, mình nghĩ như vậy là bởi vì nó giúp cho mình có 1 cái nhìn rộng mở hơn 1 vấn đề, vì lúc nào mình cũng nghĩ về 1 thứ nên mình tự bóp hẹp bản thân mình và nhìn ngắm bản thân mình trong 1 cái gì đó, khi mình nhìn rộng ra 2 hướng, thì nó sẽ có tính tương hỗ và tương thích với nhau thí dụ cái kia nó làm cái này, cái kia nó làm cái khác, 2 cái đó không thể nào giống nhau được, do đó là mình mới hiểu được những người Creator của ngôn ngữ đó họ suy nghĩ gì, họ có cái triết lý gì, họ có cái quan điểm gì trong bản thân họ. Và đó là cái điều mà khi mình biết những chuyện đó, giống như là mình học hỏi được từ những người đi trước, từ những bộ não siêu việt, là những người thiết kế ra ngôn ngữ, cái framework là họ có cái tư duy về hệ thống rất là tốt, tư duy về tổ chức này nọ, và đó là cái khiến cho mình trở nên gọi là mình hiểu biết rộng ra, không chỉ sâu mà rộng.
Anh có thể chia sẻ về những lỗi nào mà một người nhiều kinh nghiệm như anh vẫn có thể gặp phải và điều đó làm anh thay đổi như thế nào?
Một trong những mistake mình hay gặp phải, thí dụ như mình đo lường vấn đề nó dưới mức mà vấn đề đó thực sự có thể đối mặt. Bởi vì mình có thể do chủ quan dựa trên kinh nghiệm của mình, cái thứ 2 là mình không nhận đủ các nguồn thông tin, không phải người khác giấu mình cái gì mà do trong quá trình trao đổi và nói chuyện với nhau mình có thể dễ dàng bị miss những cái thông tin như vậy, dẫn đến mình estimate cái gì thì mình hay under cái mức đó, thí dụ như các bạn lập trình viên bình thường, thì thường over các task được giao, vì khi manager họ nghĩ được rồi, họ chia cái task cho nó nhỏ nhất đến mọi người, nhưng ông manager lại có cái lỗi hay estimate 1 vấn đề dưới ngưỡng cái mức đó, dẫn đến nhiều dự án thất bại như vậy.
Đó là những lời thay cho manager thường gặp, còn đối với người làm kỹ thuật thông thường như mình, những lỗi hay gặp là mình bị thiếu cái kỹ năng, ví dụ mình không đánh giá hết hậu quả về vấn đề liên quan tới tài chính network, security, mình không đánh giá được tại 1 thời điểm nào đó, cái mạng với cái băng thông của mình nó sẽ có vấn đề, rồi mình cũng không biết trong cái tổ chức của mình nó có những cái lỗ hổng gì về bảo mật, hay lỗi gì mà nó có thể xảy ra, tại vì những lỗ hổng về cái security không hẳn về yếu tố kỹ thuật phải tốt mà nó còn về yếu tố con người, vận hành về hệ thống, nó rất là khó để cho mình có cái nhìn nào mà hoàn thiện về nó hay ngăn ngừa được những chuyện như vậy, nên nó sẽ vẫn diễn ra.
Việc xây dựng hệ thống thương mại điện tử ở Việt Nam có khác gì so với thế giới?
Mình cũng không thực sự làm những công ty nào mà gọi là tầm cỡ thế giới như là Alibaba, Amazon để mà nói về những vấn đề hay thách thức mà thực sự họ phải đối mặt để giải quyết là gì. Nhưng thực sự làm ở công ty và môi trường Việt Nam trong business về thương mại điện tử thì mình biết là những vấn đề đó nó diễn ra hàng ngày và không dễ giải quyết. Nếu như mình có solution giải quyết và dĩ nhiên không diễn ra nữa, thậm chí là người ta sẽ bán solution đó cho mọi người luôn, và ai cũng có solution là thành công rồi. Thật ra để mà giải quyết những vấn đề đó, nó cần 1 thời gian dài, từ cái việc là xã hội mình thay đổi hành vi, được training lại hành vi, giống như những người trẻ của mình thì mình không rảnh đâu mà đi dìm hàng người khác làm niềm vui cả, cái chuyện đó nghe nó xảy ra như vậy là do hiệu ứng lan truyền của mạng xã hội thôi chứ nó không hẳn là cái chuyện nghiêm trọng, phần lớn cái chuyện mà mình cần lo lắng ở đây là giữa các đối thủ, họ chơi xấu lẫn nhau, bây giờ em bán quần áo, bạn kia bán quần áo giống em thì họ sẽ tìm cách phá em, và người dùng sẽ suy xét chuyện đó, cái nguy hiểm nhất là những người khác họ phá 1 ai đó với mục đích tối tăm với cái ý đồ nào đó không tốt, nếu họ phá vì niềm vui thì hôm sau gặp chuyện khác vui họ sẽ không làm điều đó nữa, thì cái chuyện đó đáng lo ngại, thì cái việc đó, nó không chỉ xử lý về mặt kỹ thuật mà cả những cái xử lý về mặt quy định vận hành. Ngoài ra nó cũng có cái yếu tố là những khách hàng thương mại điện tử họ chạy event thì họ sẽ gom ra lượng lợi ích rất là lớn, thí dụ họ bán iPhone với giá rất là thấp, thì lúc đó sẽ có những đội rất là chuyên nghiệp họ săn hàng thưởng như vậy, thì họ sẽ dùng post, hoặc cái thủ thuật nào đó để mà họ lấy những cái lợi ích đó, về cho bản thân họ, thì thực sự cái vấn đề này về mặt yếu tố kỹ thuật là giải quyết được, dựa trên những fact về 2P, dựa trên hành vi họ, để mà ngăn ngừa những chuyện đó diễn ra, để đưa họ vào cái thang đợi, chậm hơn những người bình thường, để mà nó công bằng với tất cả mọi người.
Theo anh tiềm năng của việc ứng dụng AI trong việc detect những fraud trong lĩnh vực E-Commerce có khả thi không? Hay sẽ có những khó khăn thách thức gì? (về nhân lực, cấu trúc, hệ thống, quy trình…)
Thật ra mấy vấn đề về AI, trước đó mình cũng làm về big data cũng vậy, thách thức nhất của AI là làm sao tăng độ chính xác vấn đề mình làm nên, tại vì nó không phải là con người, thì đòi hỏi máy phải có độ chính xác lớn, nếu nó không lớn như kỳ vọng thì sẽ xảy ra chuyện gì, tức là người ta sẽ nghi ngờ là cái tầng giá trị đó vẫn có những cái chính xác và những cái sai sót, thí dụ mình đánh giá cái người đó là gian lận, nhưng thực ra không phải là gian lận, những người không gian lận nhưng bị đánh nhầm là gian lận, vì vậy nó sẽ có rất là nhiều phản hồi tiêu cực từ phía khách hàng về.
Quay lại với Solution Architect, theo anh đâu là 3 tiêu chí tiên quyết cần có đối với vị trí này?
Mình cũng muốn nói ý này là không chỉ ở vị trí kiên quyết, mình xin nhắc lại không phải kiên quyết của vị trí solution architect mà đối với 1 bạn lập trình viên, thì cái đầu tiên quan trọng và kiên quyết nhất là kỹ thuật xây dựng thì các kỹ năng về mặt kỹ thuật phải được xây dựng dựa trên yếu tố phần lớn là phải tự học, không ai hơi đâu mà chỉ, hay ngồi dạy cho mình, còn người khác dạy hay chia sẻ với mình là bởi vì cả 2 cùng nhận ra được điều còn thiếu của người này, mình học hỏi được người này, mình học hỏi từ người kia, cho nên bản thân mình phải là người biết tự học để mình chia sẻ kiến thức với người khác và nhận được từ người còn lại, thì cái kỹ năng tự học đối với mình là cực kỳ quan trọng, coi lại những điều mà cần trước để mấy bạn phát triển bản thân lên, để trở thành 1 lập trình viên giỏi, đối với 1 senior hay 1 người chuyên về làm architect, đầu tiên là kỹ năng tự học, mục tiêu của nó chính là không phải cái gì mình cũng sẽ được biết hết ở trường, hay là tất cả mọi thứ mình sẽ nhận được từ người khác, mà những kiến thức đó nó nằm trên mạng, trong các framework, hay trong các opensource, hay trong những bài viết, bài chia sẻ, có rất nhiều kênh, hay những kênh giáo dục này nọ, mình phải học nó thì mình tiếp cận với những người đồng nghiệp anh em của mình, mình chia sẻ lại đó và nhận lại những cái chia sẻ ngược lại từ những mảng kiến thức khác người khác dành cho mình, thì mình improve bản thân. Thì nói về tự học, 1 trong những cái đặc điểm mình cho rằng là khả năng ghi chép tất cả những thứ đã được học, dùng đầu óc của mình để nhớ và tự trong 1 môi trường công việc nó áp lực và chịu nhiều căng thẳng, tức là đôi khi mình sẽ quên mất hôm trước mình làm cái gì rồi, do đó mình phải ghi chép lại tất cả mọi thứ được học, mình phát triển kỹ năng, việc block lại tất cả thông tin mình học được, những cái lỗi mà mình đã gặp phải để mà review lại bản thân, hay là mình sẽ đem nó chia sẻ lại cho các bạn junior, những người mà mình sẽ thành trainer trực tiếp cho các bạn đó.
Cái thứ 2 là kỹ năng thấu hiểu, thấu hiểu về công việc của người khác, tại vì mình phải thấu hiểu cho bộ phận làm business, như khi mình làm về công ty outsourcing theo kiểu là tìm kiếm và dành lấy từ khách hàng để công việc nó rất là khó rồi mình cũng thấu hiểu cho đồng nghiệp của mình, họ cũng gặp những cái khó khăn trong cái công việc nhất định, tức là mình đi làm mình không thể nào chờ mistake của người khác để mình tấn công họ, mình phải nhìn ra, thông cảm, ông làm wrongmain sẽ thông cảm cho ông làm HM, và ngược lại, thì cái chuyện đó nó giúp mình xích lại gần, hiểu họ.
Theo em thấy việc xây dựng 1 đội dev làm việc hiệu quả rất là quan trọng và cần nhiều yếu tố khác nhau. Anh có thể chia sẻ tips hoặc lời khuyên nào không? Và anh có sử dụng các hình thức như pair programming, cross-training,… hay tạo điều kiện cho các juniors thử sức hay không?
Như em nói mong muốn trở thành người đồng nghiệp tốt của người khác là mong muốn của mình, suy nghĩ của mình đơn giản lắm, mình không muốn ai đi theo sau cái bóng của mình, mình mong muốn tất cả mọi người đều đi song hành cùng mình, tiến lên phía trước cùng mình, vì vậy mà kỹ thuật hay những điều mà mình có thể giúp cho đồng nghiệp của mình bằng cách trực tiếp hay là những cái âm thầm lặng lẽ, mình đều cố gắng làm cả, những cái chiến thực cần có giống như làm pairwork theo nghi thức, đó là phương pháp phát triển phần mềm của công ty, công ty nó có nhu cầu thì mình làm thôi, không vấn đề gì, nhưng tất cả tình cảm, suy nghĩ của mình, mình phải có cái suy nghĩ luôn luôn thúc đẩy các anh em đi lên phía trước, tức là nếu mà có những cái thử thách, hay tìm hiểu những cái điều gì hay mình cũng suy nghĩ làm thế nào để làm cho mọi người thích cái đó, muốn tìm hiểu cái đó, và muốn làm được cái đó, thì cá nhân mình, mình luôn muốn như vậy, thì với những cái suy nghĩ như vậy, cho nên là mình sợ cái người mà minh chia sẻ tất cả mọi thứ, biết tất cả mọi người, giúp cho mọi người hiểu rõ vấn đề, thì khi hiểu rõ mọi người sẽ hiểu là mình có muốn làm chuyện đó hay không, và hiểu rõ thì nhiều khi sẽ thấy thú vị và thấy thú vị thì mọi người sẽ muốn làm, còn mình hay dở trong cái việc mà trở thành 1 người manager tốt giống như là quan tâm chuyện tâm tư tình cảm, gia đình, tình yêu, hay họ ở những cái khía cạnh khác, thì mình không phải là người giỏi trong lĩnh vực đó, như những cái chuyện như là nhiều khi chuyện tình cảm với nhau mình cũng hơi bối rối, mình phải feedback lại hay là mình phải trả lời câu đó như thế nào, nếu câu trả lời của mình hời hợt thì mình nghĩ lại người khác sẽ buồn, mà cái câu hỏi là mình nghĩ để trả lời cho chính xác thì mình phải đào sâu vào trong mối quan hệ đó, thì mình không có thiên hướng như vậy.
Làm thế nào để một bạn xác định được là mình nên đi theo con đường Solution Architect? Anh có lời khuyên nào dành cho các bạn đang muốn hướng tới công việc này không?
Nếu thực sự có quyết tâm để trở thành người top talent về mặt SQL thì giống như mình đã từng xem 1 cái video của TopDev của anh Tùng Nguyễn, trước là làm head về engineering Tiki, sau đó khoảng 1 thời gian mình cũng có buổi ngồi nói chuyện với anh ấy trong quán cà phê. Giống với những gì anh ấy chia sẻ, nói chung để trở thành top talent về mảng SQL, thì có nghĩa là mình viết code giỏi, một cách bài bản, mình phải kiểm chứng và test những phần mềm như QC thực thụ, mình có thể deploy vừa delivery sản phẩm của mình như 1 DevOps 1 cách hoàn chỉnh, thì mình có thể tâm đắc với các chia sẻ của anh Tùng, cách thứ 2 là nhìn vào tính cách của những người như anh Tùng Nguyễn, là người điềm tĩnh, 1 người cẩn trọng, 1 người thông minh nhưng mà khiêm nhường, tại vì mình phải xác định được những điều mình làm, và tất cả những việc làm đó mình sẽ phải học hỏi, thì phải có ai đó, đồng nghiệp chia sẻ mình, giúp đỡ mình, thì với những cái tính cách, công việc thành công như vậy mình có thể tham khảo, học hỏi, nhìn vào đó để đối chiếu với bản thân mình, thì với tính cách của anh Tùng, rất là dễ chia sẻ với người khác, dễ dàng nhận sự hỗ trợ khác, có thể cùng tìm hiểu vấn đề đó chưa đúng, hoàn thiện nó, thì anh nghĩ đó là hình mẫu mà 1 người thành công muốn tham khảo.
Trong team anh có vị trí full-stack developer không? Theo quan điểm của mình, anh có nhận xét gì về vị trí và vai trò của full-stack developer?
Vị trí fullstack developer trong giai đoạn quá trình lịch sử của nước mình nó chia nhiều giai đoạn. Giai đoạn đầu tiên là giống như mình là 1 vương quốc, đế chế như vậy, thì 1 ông vừa biết làm PHP backend có thể làm các HTML frontend thì trở thành fullstack, nên biết làm jQuery, hay Angular này nọ thì trở thành fullstack. Sau này thì những ông biết làm fullstack, thì đòi hỏi cao hơn 1 chút, như biết 1 chút về backend như PHP, biết 1 chút về Frontend, viết app mobile chẳng hạn thì trở thành fullstack. Rồi thậm chí là biết làm về Database nữa, thì gom tất cả những cái đó thì thành fullstack.
Ngày nay fullstack là 1 người có đầy đủ tất cả kỹ năng develop về mặt testing, về mặt operate giống như là DevOps, thì những người đầy đủ tất cả các kỹ năng trở thành fullstack, nhưng mà cho đến thời điểm hiện tại của năm 2020, thì chúng ta sẽ thấy, khái niệm nó bị tác động bởi những cái tổ chức lớn như là Google, Amazon thì phải thêm 1 cái yếu tố mà người developer phải biết nữa đó là security thì tất cả những chuyện đó, trở thành fullstack. Tại sao có sự phát triển đó, thì bởi vì đơn giản, kiến thức nó có sự kế thừa, thí dụ như đất nước mình, mảng công nghệ thông tin cách đây 10 năm chỉ là PHP. Bây giờ mình đã tham gia vô sâu hơn trong cái gọi là cái dây chuyền sản xuất, hay cái dây chuyền công nghệ thông tin của thế giới, mình cũng dần dần tiếp cận và được nhận về những cái project, dự án đó, mình cũng có thể có những công ty được xem là kỳ ân, do đó là mình cũng phải áp dụng mấy cái tư tưởng cao như vậy, để mà duy trì và tiếp tục phát triển, do đó là những cái nền tảng đó, đã được đưa về nước mình và được áp dụng, và nhiều cái đã áp dụng thành công. Bây giờ cái khái niệm đó, nước mình cũng đạt được những cái mức độ cạnh tranh như vậy.
Rất cảm ơn anh Phú đã chia sẻ rất tận tình về quá trình làm việc cũng như các kinh nghiệm, bài học anh tự rút ra. TopDev chúc anh và Sendo ngày càng phát triển và thành công hơn nữa, xóa bỏ khoảng cách giữa công nghệ Việt Nam và thế giới, bắt kịp những tiến bộ mới nhất của công nghệ, cũng hy vọng các bạn độc giả có định hướng về Solution Architect hay các bạn developer hiểu rõ hơn cách phát triển bản thân và định hướng nghề nghiệp của chính mình.
Xem thêm việc làm Solution Architect tại TopDev
