Project manager và Product manager hay bị lầm tưởng là giống nhau nhưng thực tế hai vị trí công việc này có vai trò và phạm vi hoàn toàn khác nhau. Cùng AMELA tìm hiểu trong bài viết hôm nay. Project và Product Project là một kế hoạch có thời gian bắt đầu, kết thúc, yêu cầu kết quả đầu ra cụ thể. Dự án được coi là hoàn tất khi những yêu cầu này được hoàn thành. Product là sản phẩm cụ thể, có thể là sản phẩm vật chất hoặc sản phẩm phần mềm cung cấp đến tận tay người dùng. Giống nhau giữa Project manager và Product manager Project manager và Product manager có sự khác biệt trong vai trò, trách nhiệm nhưng vẫn có sự tương đồng trong tố chất và kỹ năng. Gắn với ‘’manager’’ thì Project manager và Product manager đều khả năng quản lý và lãnh đạo Có khả năng giao tiếp tốt Có trách nhiệm báo cáo công việc với các bên liên quan Hiểu biết về công nghệ và có kỹ năng tech Là người lập kế hoạch, chịu trách nhiệm đưa ra các quyết định Những điểm khác nhau giữa Project manager và Product manager Vai trò Project manager giống như COO của dự án, chịu trách nhiệm giám sát công việc, dự án từ lúc bắt đầu đến khi kết thúc, đảm bảo thực hiện đúng các yêu cầu được đưa ra. Họ tập trung vào technology( kỹ thuật), request (yêu cầu), time( thời gian), cost (chi phí). Vị trí Project Manager thường là vị trí đặc thù ở các công ty outsourcing Product manager được ví như CEO của sản phẩm, chịu trách nhiệm về vòng đời của sản phẩm. Từ lúc nghiên cứu thị trường, quyết định hướng đi của sản phẩm, tạo ra sản phẩm và đưa sản phẩm ra thị trường. Đồng thời, họ cũng dẫn dắt đội phát triển để đảm bảo sản phẩm đạt chất lượng tốt nhất, thân thiện với user và đạt mục tiêu kinh doanh. Product manager tập trung vào user experience ( trải nghiệm người dùng), technology ( công nghệ) và business ( kinh doanh). Product manager  là vị trí phổ biến trong các công ty product. Trách nhiệm Project manager chịu trách nhiệm về How ( Như thế nào) và When ( khi nào): Ngân sách cho dự án? Nguồn lực như thế nào? Thực hiện các  yêu cầu như thế nào? Khi nào dự án hoàn thành? Product manager chịu trách nhiệm về What ( Cái gì) và Why ( Tại sao): Sản phẩm là gì? Giải quyết vấn đề gì? Lên chiến lược cho sản phẩm Đưa sản phẩm ra thị trường Mục tiêu lợi nhuận Phạm vi công việc Project manager và Product manager đều làm việc với rất nhiều bên từ ban lãnh đạo, các cấp quản lý, đội ngũ phát triển nhưng: Project manager làm việc phần lớn với team phát triển như Developer,…

Bạn có phải là Developer đang muốn tìm hiểu về vị trí PM hay đơn giản đang nghiên cứu về các job trong ngành IT. Hôm nay, AMELA sẽ trả lời cho các bạn câu hỏi: Project Manager(PM) là gì? Project Manager là gì? Project Manager là người đứng giữa khách hàng và development team, chịu trách nhiệm tìm hiểu nhu cầu khách hàng, truyền đạt lại với team, thiết lập quy trình làm việc và giám sát chặt chẽ để đảm bảo chất lượng phần mềm và giao dự án đúng hạn. Gắn kết các thành viên trong team, nâng cao tính teamwork của member. Sắp xếp công việc tối ưu, nhằm tận dụng thế mạnh của member. Lắng nghe câu chuyện truyền cảm hứng của chàng PM trẻ nhà A Công việc hàng ngày của một Project Manager Điều phối công việc trong team PM sẽ phải quản lý một đội nhóm nhất định tùy thuộc vào độ lớn của dự án đó. Không chỉ quản lý tốt các đầu việc của mình, mà còn phải phân chia và quản lý công việc của các thành viên trong team. Việc hiểu thế mạnh và sắp xếp công việc phù hợp với họ là điều cần thiết. Tracking công việc theo quy trình để đảm bảo chất lượng phần mềm Trước khi kick off một dự án, PM sẽ phác thảo một bản kế hoạch về cách dự án khởi đầu, cách chúng sẽ được xây dựng và cách chúng sẽ hoàn thành. Người quản lý dự án sẽ đặt tất cả lại với nhau và tiến hành theo quy trình để đảm bảo phần mềm được phát triển đúng quy trình và đảm bảo chất lượng. Tạo không khí làm việc thoải mái trong team Tinh thần ảnh hưởng rất lớn đến hiệu suất công việc. Một không khí làm việc thoải mái sẽ giúp đội nhóm tích cực và nhiệt huyết hơn cho công việc của họ. Sự thoải mái được tạo ra từ một người PM biết lắng nghe ý kiến của member, ghi nhận và tuyên dương sự đóng góp, cống hiến kịp thời. Sự quan tâm, khích lệ nhau sẽ gắn kết các thành viên trong dự án. Định hướng mục tiêu cho member Những member ít kinh nghiệm, họ  quan tâm đến định hướng và con đường phát triển cho công việc đó. Mỗi người đều có những điểm mạnh, điểm yếu khác nhau. Một PM tốt sẽ hiểu rõ member của mình để hướng họ đến con đường phát triển tốt nhất. Từ một Developer có thể phát triển thành Techlead, BrSE hoặc PM. Những kỹ năng cần thiết của một Project Manager Khả năng diễn thuyết tốt Có thể nói đây là một kỹ năng Project Manager cần có khả năng giao tiếp tốt để  truyền tải được thông điệp tới khách hàng và các thành viên trong nhóm. Bên cạnh đó, PM có thể thuyết trình về sản phẩm cũng…

Tục ngữ vẫn có câu ''biết mình biết ta, trăm trận trăm thắng''. Communicate với người Nhật mà không hiểu phong cách làm việc của họ thì dự án khó diễn ra suôn sẻ được. Sau đây, AMELA sẽ giới thiệu cho các bạn top 5 đặc trưng trong phong cách làm việc của người Nhật nhé! Đúng giờ là phong cách làm việc đặc trưng của người Nhật Đúng giờ là văn hóa làm việc quan trọng của người Nhật. Ở Nhật, mọi người đều vô cùng coi trọng tức chữ thể diện, trong đó bao gồm sự tự hào cá nhân, danh tiếng và địa vị trong xã hội. Đặc biệt trong đó phải kể đến thể diện của từng cá nhân trước tập thể hay cộng đồng, vì vậy trong mỗi cuộc hẹn hay buổi làm việc, người Nhật luôn có văn hóa đúng giờ, thậm chí đến sớm hơn. Việc đúng giờ là cách thể hiện sự tôn trọng đối với người khác và đặc biệt hơn trong công việc, khi đến sớm có thể giúp bạn có thêm thời gian để chuẩn bị kỹ lưỡng mọi thứ, từ đó tăng hiệu quả cho công việc. Tăng ca Ở Nhật Bản mọi người có xu hướng tăng ca, làm thêm mỗi ngày. Người Nhật có quan niệm rằng tăng ca là cách thể hiện sự cống hiến cho doanh nghiệp. Đồng thời, chính doanh nghiệp cũng thường dựa vào thời gian làm việc ngắn hay dài để quyết định tăng chức hay bổ nhiệm. Từ đó mọi người coi thời gian làm tăng ca là tất yếu cho công việc để đem tới hiệu quả và năng suất lao động lớn hơn. Phong cách làm việc của người Nhật là thích nói giảm, nói tránh Người Nhật luôn có xu hướng hạn chế sự đối đầu hay hiềm khích lẫn nhau cả trong lời nói hay hành động. Chính vì thế thay vì nói “Không được” họ sẽ dùng những từ ngữ khác để biểu đạt ý cần nói của mình sao cho người nghe có thể dễ dàng chấp nhận và không quá đau buồn. Trong từng lời nói họ rất chú ý để không làm người khác phật ý hay bực bội, khó chịu. Khi giao tiếp với khách hàng Nhật, trao đổi thẳng thừng như ruột ngựa sẽ rất dễ làm phật lòng khách hàng, ảnh hưởng đến kết quả dự án. Khéo léo và linh hoạt sẽ là giúp việc communicate giữa hai bên trở nên thuận lợi hơn. Làm ra làm, chơi ra chơi Đây là nguyên tắc có lẽ mà nhiều người cần phải áp dụng cho bản thân vào công việc bởi lẽ công việc sẽ hiệu quả rất nhiều nếu dành hết thời gian, công sức vào nó thì mới đạt được kết quả cao nhất. Còn việc thư giãn nghỉ ngơi cũng rất cần thiết, đây là một cách để ta lấy lại năng lượng và hồi phục…

Đối với một dự án outsource thì việc communicate tốt đóng một vai trò rất quan trọng, quyết định đến 70% thành công hay thất bại của dự án. Đứng trên phương diện của một người quản lý chất lượng dự án với khách hàng Nhật, chuyên gia của AMELA sẽ chia sẻ về cách communicate hiệu quả trong dự án với khách hàng Nhật. Đề cao tính tập thể hơn là ‘’cái tôi’’ Trong một dự án, việc giao tiếp win-win để vừa đạt được mục đích đôi bên, vừa giữ được sự hài hòa là điều hết sức quan trọng. Bạn hoàn toàn có thể đưa ra ý kiến riêng mang tính tích cực để cải thiện sản phẩm nhưng nên cân nhắc điều đó có phải điều thích hợp để nói trong tình huống đó hay không. Hãy lắng nghe tất cả những phản hồi từ phía khách hàng rồi thẳng thắn đưa ra ý kiến với thái độ mềm mỏng, nhẹ nhàng và luôn giữ hòa khí. Communicate lịch sự và tôn trọng với khách hàng Nhật Khách hàng Nhật tôn trọng và duy trì các mối quan hệ theo thứ bậc. Chúng ta đứng ở trên phương diện là người cung cấp dịch vụ nên cần lịch sự và tôn kính cần thiết với khách hàng kể cả trò chuyện trực tiếp, qua email hay skype. Thành thạo keigo (tôn kính ngữ) là điều bắt buộc. Ngoài ra, tùy vào từng khách hàng sẽ có cách ứng xử khác nhau. Đôi khi, việc lạm dụng kính ngữ quá nhiều sẽ làm cuộc trò chuyện trở nên trang trọng quá mức cần thiết và làm khách hàng không thoải mái. Giao tiếp thể hiện ‘’sự quan tâm’’ với khách hàng Người Nhật rất quan tâm đến khái niệm “気遣い”, ”気が利く” . ・気遣い: Là sự quan tâm, để ý, lo lắng cho đối phương. ・気が利く: Là sự biết ý, biết điều. Đối với người Nhật, chất lượng sản phẩm tốt là điều đương nhiên. Khi điều kiện cơ bản đó đã được đáp ứng thì họ bắt đầu có những yêu cầu cao hơn về chất lượng dịch vụ khác. Ví dụ như họ sẽ muốn người tiếp đón mình phải niềm nở, phải hiểu được những nhu cầu mà họ không nói ra, biết cách lắng nghe, chú tâm vào họ,... Cách giao tiếp Sử dụng ngôn từ thông dụng Thành thật Thể hiện sự hứng thú với câu chuyện của khách hàng Những câu nói quan tâm lo lắng rất hữu dụng Chú ý tiểu tiết khi communicate với khách hàng Hôm nay khách vui hay buồn? Khách có đang khó chịu không? Khách đồng tình với mình khoảng bao nhiêu phần trăm? Khách có hiểu mình đang nói gì không? Khách này có đặc điểm tính cách gì? Vì sao khách lại yêu cầu như vậy? Điều họ thật sự muốn là gì? Lời nói của khách mang hàm ý gì? Lời ít ý…

Tester đóng vai trò quan trọng trong việc đảm bảo chất lượng phần mềm. Đồng thời, đáp ứng yêu  cầu của khách hàng hoặc mang lại trải nghiệm tốt nhất cho người dùng. Một khi mà đã qua khâu kiểm thử mà phần mềm vẫn lỗi thì hãy nhìn về phía Tester. Nói như vậy để biết vai trò quan trọng của một Tester trong một dự án phát triển phần mềm và nghề Tester luôn được coi trọng. Để có góc nhìn tổng quan về nghề Tester, hãy cùng lắng nghe những chia sẻ của người trong ngành về công việc này nhé! Lý do chọn nghề Tester Mình tốt nghiệp ngành CNTT, khởi đầu bằng công việc PQA.  Sau đó bén duyên sang Tester do yêu thích làm việc teamwork, phân tích nghiệp vụ dự án và mỗi lần tìm được bug là cảm thấy thích thú. Đối với những người chưa có base IT nhưng có tiếng Nhật tốt cũng đang chuyển hướng sang nghề này. Các bạn có thể tham khảo khóa học đào tạo Tester từ con số 0 tại AMELA hoàn toàn miễn phí tại đây Công việc của một Tester Tester có thể lựa chọn làm việc trong môi trường outsource hoặc product. Với AMELA là công ty outsource thị trường Nhật Bản, tester sẽ có các đầu việc gần giống như các công ty outsource khác. Phân tích nghiệp vụ, tìm hiểu requirement: Requirement là gì? Requirement là tất cả các yêu cầu về phần mềm do người dùng nêu ra. Nó bao gồm các chức năng của phần mềm, hiệu năng của phần mềm,  giao diện của phần mềm và một số các yêu cầu khác. Thông thường các yêu cầu phần mềm được phân loại dựa trên 4 thành phần của phần mềm như sau: · Các yêu cầu về phần mềm · Các yêu cầu về phần cứng · Các yêu cầu về dữ liệu · Các yêu cầu về con người Mục tiêu quan trọng nhất đối với chất lượng phần mềm là phần mềm phải thỏa mãn được các yêu cầu và mong muốn của người dùng. Phân tích nghiệp vụ, tìm hiểu requirement Người dùng thường chỉ đưa ra những ý tưởng, nhiều khi rất mơ hồ về phần mềm mà họ mong muốn xây dựng. Việc của đội dự án đó là phải giúp họ đưa những ý tưởng mơ hồ đó thành hiện thực. Xây dựng được một phần mềm có đầy đủ các tính năng cần thiết thỏa mãn yêu cầu của người dùng. Hơn thế nữa, ý tưởng của người dùng thường xuyên thay đổi và việc của nhà phát triển là phải nắm bắt và đáp ứng được các yêu cầu thay đổi đó một cách hợp lý. · Đọc và cố gắng hiểu mục đích của ứng dụng đang mong muốn là gì? · Vừa đọc và hình dung, tưởng tượng xem phần mềm /màn hình đó sẽ chạy như…

Business Analyst đang là một trong những ngành nghề hot hiện nay và được nhiều bạn trẻ hướng đến. Bạn bắt đầu với công việc này là một tờ giấy trắng và hoang mang không biết bắt đầu như thế nào. Lúc này việc lắng nghe những kinh nghiệm của các tiền bối sẽ giúp các bạn có cái nhìn rõ nét hơn về nghề và tìm được hướng đi để bắt đầu công việc. Cùng lắng nghe chia sẻ của chàng BA nhiều hoài bão, cầu tiến nhà A với những kinh nghiệm làm Business Analyst của mình nhé! Cơ duyên đến với business analyst Mình là du học sinh Nhật, đại học Kinh tế Luật Osaka, chuyên ngành kinh tế quốc tế. Do dịch covid nên mình phải về Việt Nam sớm sau 3 năm rưỡi học tập tại Nhật và bắt đầu con đường lập nghiệp. Lúc đầu thì mình cũng chưa biết sẽ làm công việc như thế nào, ngành nghề nào. Mình đã thử đi thực tập ở một công ty vận tải biển của Nhật Bản, có văn phòng ở VN, sau đấy là đi làm ở 1 nhà máy sản xuất nhựa cũng của Nhật rồi chờ cơ hội quay lại Nhật. Mặc dù đãi ngộ ở 2 nơi cũng khá tốt, nhưng mình không thấy hài lòng về công việc của mình lắm. Mình đã xin nghỉ sau 1 tháng rưỡi làm việc ở nhà máy. Trong thời gian mình đi làm thực tập ở công ty vận tải, mình có được anh chị tư vấn cho nghề Business Analyst(BA) là ngành nghề hot hiện nay, mà cũng phù hợp vs chuyên ngành kinh tế mình theo học. Đó là lần đầu tiên mình nghe đến nghề Business Analyst. Lang thang tìm việc trên facebook, linkedin,  thì tình cờ mình đọc được bài tuyển dụng intern BA ở Amela và mình đã thử ứng tuyển. May mắn mình đã pass phỏng vấn và bắt đầu công việc tại đây. Khó khăn ban đầu và cách giải quyết?     Khó khăn lúc đầu vào nghề: Mình gặp rất nhiều khó khăn, vì ngoài chút ít kiến thức về ngoại ngữ, mình là dân ngoại đạo hoàn toàn. Không biết về tech: Mình mù tịt về khoản này. Máy tính mình chỉ để xem youtube và đọc truyện, chơi game. Khi bắt đầu thực tập, mình đã phải tìm hiểu rất nhiều các trang web tương tự những dự án mình làm, đọc thêm tài liệu về IT, học thêm từ vựng tiếng anh để có thể hiểu các bạn Developer, Tester đang nói về điều gì. Học về figma, biết những thao tác cơ bản nhất. Mình cũng đang học thêm về C++, SQL,... Khó khăn khi bước vào một công ty trẻ nhưng đầy áp lực, công việc nhiều: Giai đoạn đầu mình khá vất vả với điều này, nhận nhiều dự án, chưa biết được hết công việc mình phải…

Con đường sự nghiệp của Business Analyst ( Business Analyst Career Path) là một hành trình với rất nhiều ngã rẽ, bạn sẽ làm chủ lựa chọn của mình dựa trên kiến thức, kỹ năng và kinh nghiệm của bạn. Tham khảo bài viết dưới đây có thể giải quyết giúp bạn bài toán lớn về định hướng công việc của một Business Analyst.   Hành trình bắt đầu từ Fresher BA Giai đoạn này thường dành cho các bạn bắt đầu tiếp cận với các đầu việc của BA. Bạn sẽ được training, hỗ trợ từ các bạn BA có level cao hơn để hiểu cách làm dự án, cách làm document, được giới thiệu hệ thống, các tool sử dụng,... Ở level này bạn cần tích lũy thêm kiến thức nền tảng về BA, tranh thủ học hỏi, tận dụng các cơ hội trải nghiệm thực tế nhiều nhất có thể. Đối với các tập đoàn, công ty lớn với quy trình rõ ràng, nhiều lợi ích có thể là lựa chọn tốt cho người bắt đầu. Với các công ty startup, ngược lại bạn sẽ được làm nhiều  hơn, khả năng tự học cao hơn và có thể trưởng thành nhanh hơn. Lời khuyên cho bạn: nên tập trung vào việc xác định mục tiêu và định hướng công việc ngay giai đoạn này, tránh lan man và tốn thời gian vô ích. Tìm kiếm cơ hội cho vị trí BA tại AMELA. Giai đoạn thứ 2 Junior Sau một thời gian làm việc, tích lũy kinh nghiệm, bạn có thể phân tích và viết tài liệu ở mức thành thạo hơn, có thể làm việc độc lập ở một số đầu việc trong dự án. Bạn vẫn được hỗ trợ từ các Senior BA ở các dự án lớn, phức tạp. Thời điểm này, bạn nên học hỏi thêm những kỹ năng mềm cần thiết và các kỹ năng phân tích để đưa ra các giải pháp trong dự án. Đối với các bạn chuyển việc từ các vị trí khác sang làm BA thường bắt đầu từ Junior phát triển lên. Những xuất thân nào sẽ phù hợp cho vị trí BA? Tháo lớp Junior, hướng tới Senior BA   BA chính hiệu là gì? Khi bạn đã đạt level BA thì sự chủ động và quản lý task là điều cực kỳ quan trọng. Hiểu đơn giản, bạn phải hoàn thành task đúng deadline và chất lượng, không có người cầm tay chỉ việc cho bạn nữa. Giai đoạn này, hãy thể hiện bản thân và chứng minh năng lực của bạn sau khoảng thời gian đủ dài để tích lũy kinh nghiệm và kỹ năng. Chứng minh năng lực qua các task ‘’xịn’’, đòi hỏi chuyên môn cao và thể hiện bản thân khi biết quản lý task hiệu quả, biết say no đúng lúc, tránh ôm đồm quá nhiều các task support.   Đạt tới level Senior BA Ở senior BA, phạm…

Hiện nay, có rất nhiều Tester đang chuyển hướng sang làm Business analyst nhờ lợi thế chuyên môn về công nghệ thông tin, hệ thống cùng những sự tương đồng trong nghiệp vụ. Như vậy, hành trình chuyển hướng từ Tester sang Business Analyst liệu có phải là bài toán dễ dàng? Cùng AMELA tìm hiểu thật kỹ về vấn đề này nhé! Trước khi đọc tiếp, hãy thử tìm hiểu qua về nghề Business Analyst (BA) tại đây Từ bỏ nghề Tester để làm Business Analyst (BA). Liệu có đáng? Nền tảng của Tester tiệm cận với Business Analyst Kiến thức hệ thống chuyên sâu: Tester chú ý đến chi tiết và nắm rõ về hệ thống phần mềm được xây dựng, thậm chí còn tốt hơn các BA và chắc chắn là nhiều hơn Quản lý dự án. Tester thông qua công việc đảm bảo chất lượng của họ để biết lý do một kịch bản thất bại. Điều này làm cho một Tester một BA rất tốt. Tester giỏi phân tích: Tester được yêu cầu đọc, phân tích và xem xét các tài liệu đặc tả yêu cầu. Kỹ năng phân tích của Tester có thể giúp Business Analyst chỉ ra sự không rõ ràng trong các đặc tả yêu cầu nếu có. Tester có kỹ năng giao tiếp tốt Tester không chỉ ngồi trên máy tính xách tay chạy các kịch bản kiểm tra nhiều lần mà còn có khả năng giao tiếp cực tốt. Tester làm việc và trao đổi với các vị trí khác như Developer, BA, PM,... về những vấn đề trong quy trình mà họ nhìn thấy. Trao đổi về các vấn đề môi trường thử nghiệm và quy trình thủ công mà người dùng doanh nghiệp có. Tester cũng đảm bảo rằng các kết quả kiểm tra được ghi lại trong các công cụ kiểm tra để bất kỳ ai đọc nó cũng hiểu được những gì sai với hệ thống. Những cơ hội phát triển của nghề Business Analyst Business Analyst giỏi là sự tổng hòa của nhiều kỹ năng có tính chuyên môn cao để áp dụng thành công cho bất kỳ lĩnh vực nào. BA được tiếp xúc được nhiều khách hàng, thuộc nhiều lĩnh vực khác nhau. Từ việc trao đổi, giao tiếp với họ sẽ có thêm nhiều kỹ năng, hiểu rõ hơn về nghiệp vụ. Điều này cho phép các BA thay đổi ngành, công ty hoặc lĩnh vực khác một cách dễ dàng. Nghề BA thuộc mức thu nhập cao đang dần chiếm lợi thế trong thị trường tuyển dụng ngày nay. BA sẽ luôn nhận được mức lương lý tưởng khi là những chiếc “cầu nối” thông tin vững chắc mà họ xây dựng được từ khách hàng tới bộ phận phát triển dự án. Họ hiểu và tạo dựng các mối quan hệ kinh doanh bền chặt cho doanh nghiệp. Top kỹ năng đặc trưng của một Business Analyst khác với Tester…

Business Analyst là gì?   Business Analyst (BA) chịu trách nhiệm lấy yêu cầu từ khách hàng, sau đó chuyển thông tin đến đội dự án( Developer, QC, PM). Đồng thời họ cũng trao đổi, đề xuất các giải pháp đối với các yêu cầu nhằm tối ưu các hoạt động kinh doanh của doanh nghiệp. Công việc của Business Analyst - Làm việc với khách hàng để lấy yêu cầu và chuyển đến đội dự án - Thảo luận và phân tích những yêu cầu, giải pháp đối với đội dự án. - Viết và quản lý document Xuất thân của Business Analyst BA xuất thân IT( developer, QC) Những người xuất thân IT họ có lợi thế nhờ kiến thức chuyên môn nhưng thiếu kỹ năng mềm và các kiến thức nghiệp vụ bổ sung như kế toán, nhân sự, tài chính… Nếu chuyển hướng sang BA, họ cần bổ sung, trau dồi các kiến thức về kinh doanh như nghiên cứu khách hàng, phân tích thị trường thông qua số liệu,...Ngoài ra, họ cũng phải nâng các kỹ năng mềm đặc biệt là kỹ năng giao tiếp.     BA xuất thân kinh doanh( tài chính, ngân hàng, bảo hiểm,...) So những BA xuất thân IT, họ có kỹ năng mềm tốt hơn và có sự hiểu biết sâu rộng trong các lĩnh vực. Tuy nhiên, họ có nền tảng về kinh tế nhưng cần học hỏi và nắm được hệ thống, công cụ liên quan đến IT. Việc hiểu rõ về những yêu cầu của khách hàng và các kiến thức về IT sẽ giúp họ kết nối dễ dàng giữa cả khách hàng và dự án. Sinh viên mới ra trường hướng đến vị trí BA Nếu bạn có kiến thức tổng quát về nhiều ngành nghề, thích giao tiếp, kỹ năng ngoại ngữ tốt thì có thể cân nhắc việc thử sức với vị trí này Các bạn có xuất thân IT hay có kiến thức về IT nếu chuyển hướng đến công việc của BA sẽ giúp các bạn phát triển rất nhiều kỹ năng và kiến thức về sau. Con đường của BA chuyển sang các vị trí công việc khác rất rộng. Nếu bạn có định hướng trở thành một BA, tham khảo ngay vị trí BA mà nhà A đang mở nhé!

Kỹ sư cầu nối (BrSE) là gì? BrSE hay còn gọi kỹ sư cầu nối (Bridge system engineer) là người đóng vai trò kết nối giữa khách hàng và project team. Họ là người sử dụng tốt kỹ năng giao tiếp, nghiệp vụ về kỹ thuật của mình. Họ giúp cho quá trình trao đổi giữa bên khách hàng và project team được thực hiện một cách thuận lợi giúp bàn giao dự án thành công, đem lại sự hài lòng đến với khách hàng.   Công việc của một kỹ sư cầu nối ( BrSE) BrSE phải đảm nhận nhiều chức năng trong một dự án phần mềm. Bắt đầu từ việc lên kế hoạch phát triển dự án, quản lý đội nhóm đến việc giao tiếp giữa khách hàng với đội nhà…. Cụ thể công việc của một BrSE như sau:  Giai đoạn đầu dự án: - Tìm hiểu, nắm chắc nghiệp vụ và các yêu cầu liên quan đến dự án. - Truyền đạt rõ ràng và chi tiết những yêu cầu của khách hàng tới đội dự án - Đề xuất các ý tưởng và phương án giải quyết cho vấn đề của dự án. - Trong một số trường hợp phải viết tài liệu thiết kế hoặc chỉ cần hiểu tài liệu mà khách hàng đã làm. - Lập kế hoạch,  thời gian cũng như nhân lực cần thiết để phát triển. Giai đoạn phát triển dự án: - Trả lời Q&A liên quan đến nghiệp vụ và kỹ thuật của dự án. - Theo dõi và báo cáo tiến độ dự án cho khách hàng định kỳ. - Hỗ trợ vào quá trình code nếu cần. - Kiểm tra lại chất lượng sản phẩm trước khi release cho khách hàng. Giai đoạn kết thúc dự án: - Release sản phẩm đã hoàn thiện cho khách hàng. - Có thể tham gia vào giai đoạn deploy nếu khách hàng yêu cầu. - Nếu khách hàng phát hiện ra bug thì sẽ đối ứng các bug này cho khách hàng. - Tổng kết lại và hoàn tất dự án. Kỹ năng cần có của một kỹ sư cầu nối (BrSE)   Kỹ năng để trở thành một kỹ sư cầu nối (BrSE) sẽ tương ứng với yêu cầu công việc dành cho vị trí này: + Thành thạo ngoại ngữ để giao tiếp với khách hàng là điều tiên quyết cho các BrSE + Có kiến thức về Tech, hiểu và nắm rõ các nền tảng lập trình. Biết code là một lợi thếnhưng BrSE cũng cần đến khả năng về thiết kế. + Kỹ năng giao tiếp là một kỹ năng rất quan trọng khi bạn là một kỹ sư cầu nối. Bạn cần phải đảm bảo việc truyền tải thông tin giữa khách hàng và team dự án là chính xác, dễ hiểu. Ngoài ra, kỹ năng giải quyết những vấn đề xung đột trong dự án cũng cần thiết. + Kỹ năng quản…

1. ReactJS là gì?  React được Facebook giới thiệu vào năm 2011, họ quảng bá đây là thư viện cho phép Developer tạo ra các dự án ứng dụng web lớn, có giao diện UI phức tạp từ một đoạn mã nguồn nhỏ và độc lập. ReactJS (đôi lúc cũng có thể gọi là React.JS hay React) là một thư viện Javascript giúp bạn nhanh chóng xây dựng giao diện ứng dụng (UI). ReactJS có thể xây dựng website hoàn toàn sử dụng Javascript (để thao tác với HTML), được tối ưu hiệu năng bởi kỹ thuật Virtual DOM. Cách cài đặt và bắt đầu làm việc với ReactJS tham khảo nguồn: https://viblo.asia/p/cai-dat-moi-truong-de-chay-reactjs-oOVlY1Pvl8W  2. ReactJS làm được những gì?    ReactJS giúp cho việc viết các đoạn code Javascript sẽ trở nên dễ dàng hơn vì nó sử dụng một cú pháp đặc biệt đó chính là cú pháp JSX. Thông qua JSX cho phép nhúng code HTML và Javascript. ReactJS cho phép Developer phá vỡ những cấu tạo UI phức tạp thành những component độc lập. Dev sẽ không phải lo lắng về tổng thể ứng dụng web, giờ đây Developer dễ dàng chia nhỏ các cấu trúc UI/UX phức tạp thành từng component đơn giản hơn.  Đi kèm với ReactJS là rất nhiều các công cụ phát triển giúp cho việc  debug code một cách dễ dàng hơn. Một trong những ưu điểm nữa của ReactJS đó là sự thân thiện với SEO. Hầu như các JS Framework không thân thiện với các tìm kiếm mặc dù đã được cải thiện nhiều nhưng dưới sự hỗ trợ của các render dữ liệu trả về dưới dạng web page giúp cho SEO chuẩn hơn.  3. Kiến thức nền tảng về ReactJS    React Components:  Components giúp phân chia các UI (giao diện người dùng) thành các phân nhỏ để dễ dàng quản lý và tái sử dụng. Giả sử mình có một website gồm nhiều phần bố cục khác nhau và mình muốn chia nhỏ các phần ra để dễ quản lý. Trong mỗi React App đều có thể chứa rất nhiều components, mỗi components trong đó thường nhận về các props và trả về React elements từ đó hiển thị ra cho UI. Components trong React thường được viết theo 2 loại chính đó là functional components và class components. Functional Components và Class (Stateful) Components  +  Functional Components là một function Javascript / ES6 function, phải trả về 1 React element và nhận props làm tham số nếu cần. +  Class (Stateful) Components là một class ES6, nó sẽ là một component khi nó "kế thừa" React component, có thể nhận props (trong hàm khởi tạo) nếu cần, có thể maintain data của nó với state và phải có 1 method render() trả về 1 React element (JSX), or null. Props và State:  + Props là viết tắt của Properties. Props có thể đến từ parent, hoặc có thể được thiết lập bởi chính component đó. +…

Agile và Waterfall là hai mô hình phát triển phần mềm rất phổ biến được sử dụng trong các tập đoàn, công ty công nghệ ngày nay. Vậy Agile và Waterfall cụ thể là gì? Sự khác biệt chính giữa hai mô hình này? Agile và Waterfall nên chọn cái nào? AMELA sẽ cùng bạn tìm hiểu về mô hình Agile và Waterfall trong bài viết này nhé! Mô hình Agile là gì? Mô hình Waterfall là gì? Mô hình Agile    Là phương pháp xây dựng và phát triển các dự án phần mềm. Phương pháp này rút ngắn đáng kể thời gian phát triển, lặp đi lặp lại các bài test trong một khoảng thời gian ngắn, từ đó phát triển dự án một cách nhanh chóng. Mô hình Waterfall Là phương pháp vòng tuần hoàn dạng vòng lặp. Phương pháp giúp triển khai dự án phần mềm theo tuần tự và do đó nhóm phát triển dự án chỉ chuyển sang giai đoạn phát triển hoặc thử nghiệm tiếp theo nếu bước trước đó hoàn thành thành công. Khác biệt giữa Agile và Waterfall   Agile và Waterfall là hai mô hình phát triển phần mềm có những đặc điểm rất khác nhau:  + Agile cho phép khách hàng có thể request thay đổi yêu cầu hoặc bổ sung specs bất kỳ lúc nào trong quá trình phát triển. Waterfall phải thực hiện thay đổi specs và các yêu cầu đặc tả khác trước khi bắt đầu phát triển.  + Agile có thể cung cấp dịch vụ ở mỗi lần lặp (Iteration) nên sẽ nhanh chóng. Còn đối với Waterfall chỉ cho phép cung cấp dịch vụ sau khi đã hoàn thành toàn bộ các quy trình, do vậy sẽ tốn thời gian hơn.  + Trong mô hình phát triển Agile không bắt buộc phải có tài liệu, tuy nhiên nếu đó là một phương thức truyền đạt thông tin hiệu quả thì vẫn nên tạo tài liệu. Ngược lại, với mô hình phát triển Waterfall, tài liệu cần được tạo cho mỗi quy trình và được kết nối với quy trình tiếp theo. Ngoài ra, tài liệu cũng là bằng chứng của dự án sau khi toàn bộ quá trình hoàn tất. + Agile yêu cầu việc test thường xuyên ứng với từng implement, Waterfall thì việc kiểm tra chỉ được thực hiện trong giai đoạn test. + Trong phát triển Agile, mỗi kỹ sư sẽ thực hiện công việc phát triển của mình mà không cần phải có một lĩnh vực chuyên môn cụ thể; nhưng với mô hình Waterfall, bắt buộc phải có một người phụ trách từng quy trình. + Phương pháp Agile giúp bạn học hỏi thực tế thông qua các phát triển lặp đi lặp lại. Vì phải chịu trách nhiệm đối với tất cả các vòng phát triển, bạn sẽ có nhiều kinh nghiệm cũng như dễ dàng thích ứng hơn trong nhiều lĩnh vực. Còn phát triển Waterfall thiên…