Header image

Có cần tài liệu thiết kế (design document) trong phát triển phần mềm Agile?

27/08/2021

1.79k

Xin chào tất cả mọi người.

Tôi là Ueki – một thành viên của SupremeTech Co.,Ltd. Với vai trò là một Phó Giám đốc tôi hỗ trợ cho các dự án phát triển về mặt quản lý với các role như Project Management Office (PMO) hay Resource Management Office (RMO).

Sau khi đọc được một bài viết thú vị với chủ để mà tôi rất quan tâm là  lý do tại sao các programer không viết document , tôi đã có suy nghĩ đặt bút để viết nên bài viết này.

Có cần tài liệu thiết kế (design document) trong phát triển phần mềm Agile?

Mục lục

1. Tại sao nhiều dự án vẫn làm việc được mà không cần đến tài liệu thiết kế?

2. Vai trò Product backlog (và những hạn chế)

3. Vai trò của Design documents

4. Bạn hiểu rõ tầm quan trọng của Design documents nhưng nó lại quá phiền phức

5. Ba mẹo để ứng dụng tốt cả Product backlog và Design documents

6. Kết thúc

1. Tại sao nhiều dự án vẫn làm việc được mà không cần đến tài liệu thiết kế?

Trước khi đến Việt Nam, tôi từng là một system engineer tại một công ty SI ở Nhật Bản. Lúc đó chủ yếu các dự án phát triển theo mô hình waterfall, nên tuần tự công việc của chúng tôi sẽ là: tự viết design document, review, sau đó dựa trên design đó để tiến hành coding, tạo test cases, chạy test. Vì thế mà, tôi chưa từng nghĩ đến việc phát triển hệ thống mà không có design document.

Khi chuyển công việc sang một công ty chuyên về WEB, tôi đã rất shock khi thấy một số project vẫn chạy bình thường mà không hề có design document.

Chuyện xảy ra một thời gian trước đây khi tôi còn làm ở một công ty Offshore ở Việt Nam. Khi đó, tôi có tham gia vào một dự án từ Phase 2. Tôi có nhờ Project manager (PM) phụ trách Phase 1 chia sẻ cho tôi tài liệu về design document thì lại nhận được URL của một tool quản lý task có tên là Redmire, tool này được dự án sử dụng để quản lý Product Backlog.

PM đó nói với tôi rằng tất cả yêu cầu đều được mô tả trong ticket Redmine, nên đó chính là design document.

Lúc đó, khi tôi đặt ra câu hỏi “Nếu yêu cầu có thay đổi thì có update trong ticket đó không? “. Câu trả lời tôi nhận được là “Trong trường hợp đó, sẽ tạo ticket mới”. Nếu như vậy thì chẳng phải sẽ có trường hợp yêu cầu của 1 màn hình có thể bị trải dài ra nhiều ticket khác nhau, và ngược lại yêu cầu của nhiều màn hình có thể chỉ được gom lại trong một ticket hay sao? Như vậy thì những ticket Redmine đó không thể làm vai trò của một design document được.

Bỏ qua nhiều câu hỏi trong đầu, cuối cùng tôi đã bỏ ra vài tuần để tạo lại từ đầu design document của Phase1, trước khi bắt đầu Phase2. 

Người PM mà tôi vừa nhắc đến cũng là một thành viên thuộc team PMO của công ty, đến cả một người ở level này và có nhiều kinh nghiệm như thế mà cũng chấp thuận và làm theo cách này, quả thật lúc đó tôi đã rất shock. Thế nhưng, nếu như đã quen với mô hình phát triển Agile, họ chỉ cần nhận được tài liệu khái quát từ khách hàng, Product backlog hay whiteboard, thông qua việc thảo luận với khách hàng, họ sẽ không cần đến design document mà vẫn có thể tiến hành coding, do đó, dù ko nắm được tầm quan trọng của design document hay sự khác biệt giữa Product Backlog và design document thì họ vẫn có thể phát triển dự án được. 

bài blog tôi có nói đến ở phần đầu cũng đã viết “cho dù không có document cũng không có trở ngại gì cả”, nhưng đó lại là sự thật.

Vậy nên, nếu không cần design document mà vẫn có thể phát triển được thì design document cũng trở nên không cần thiết nữa sao?

Có thật sự không cần đến design document nếu đã có Product backlog không?

Thực ra, Product backlog và design đều được mô tả bằng chung một từ là “specification” nhưng vai trò của nó lại khác nhau.

Nói cách khác, không phải cái nào tốt hơn cái nào, mà là cả hai đều cần thiết cho các mục đích khác nhau. 

2. Vai trò của Product backlog (và những hạn chế khi sử dụng nó như một tài liệu thiết kế)

Ở SupremeTech, chúng tôi quản lý các Product backlog bằng các tool quản lý ticket như Backlog, Github issue, Redmine.

Chúng tôi sẽ quản lý 1 product backlog bằng những tickets được PO tạo ra, khi cần thiết sẽ cùng thảo luận, đặt Q&A ở phần comment, sau đó sẽ bổ sung những nội dung được quyết định cuối cùng vào phần overview của ticket đó.

Trong mô hình phát triển mà yêu cầu thường không được rõ ràng ở giai đoạn đầu như Agile, thì phương pháp này rất có hiệu quả và cho phép nhiều bên liên quan (Stakeholders) tham gia vào quá trình xây dựng yêu cầu để yêu cầu được tốt hơn.

Những product backlog item (PBI) đã hoàn thành sẽ được close, nếu có yêu cầu thay đổi thì sẽ tạo một ticket mới để các kĩ sư có thể chỉ cần tập trung vào phần hiện tại mình làm.

Vì có thể nhìn thấy được số lượng ticket, nó sẽ giúp bạn lên schedule dễ dàng hơn dựa theo estimate và cũng có thể thúc đẩy các engineer làm việc hiệu quả hơn thông qua các mục tiêu đã đề ra.

Vai trò của Product backlog (và những hạn chế khi sử dụng nó như một tài liệu thiết kế)
Quản lý Product backlog bằng Github issue

Mặt khác, nếu chỉ quản lý bằng  Product backlog, sẽ có những câu hỏi chỉ có thể trả lời bằng kí ức phát sinh như là “đâu là spec đúng hiện tại” hay “cái nào mới chính xác”.

Ví dụ ở Product backlog có những thông tin như sau:

1. Muốn develop màn hình A bao gồm các function A-1, A-2, A-3

2. Log các yêu cầu của màn hình A ở ticket ①

3. Engineer tiến hành develop → Close ticket ①

4. Thay đổi spec ở function A-1 và A-2 ở màn hình A

5. Log các yêu cầu thay đổi của function A-1, A-2 ở ticket ②

6. Engineer tiến hành develop → Close ticket ②

7. Thay đổi spec ở function A-2 ở màn hình A

8. Log các yêu cầu thay đổi của function A-2 ở ticket ③

9. Engineer tiến hành develop → Close ticket ③

Ở đây, nếu bạn muốn kiểm tra spec chính xác của màn hình A, bạn cần phải tìm tất cả các ticket ①②③  đã close và sắp xếp chúng theo thứ tự thời gian. (Trong ví dụ này, spec đúng của màn hình A bao gồm function A-1 được log ở ticket ②, function A-2 được log ở ticket ③ và function A-3 được log ở ticket ①).

Các ticket đã close có thể được tìm thấy bằng cách search trên tool quản lý ticket, nhưng nếu search bị sót 1 thông tin gì đó hoặc kết hợp sai, thì spec sai sẽ bị nhầm thành spec đúng.

Nếu bạn cố gắng xây dựng spec mới dựa theo cái đã bị nhầm trước đó, sự nhầm lẫn qua lại sẽ ngày một tăng lên.

Vai trò của Product backlog (và những hạn chế khi sử dụng nó như một tài liệu thiết kế)
Product backlog không phải vạn năng

Cũng có cách để tách ticket cho từng function A-1, A-2, A-3, nhưng ở ví dụ này nó chỉ là một function, và spec có thể thay đổi ngay cả chỉ với một image hay một button, vì vậy sẽ không thực tế nếu chia các yếu tố thành ticket được.

Cũng có ý kiến ​​cho rằng “những gì được viết trong code mới là đúng”, và nó có thể đúng trong trường hợp bây giờ, nhưng chưa chắc đã đúng hết như thế.

Vì không có gì đảm bảo rằng không có bug xảy ra nên không thể cho răng nội dung code là spec đúng được.

3. Vai trò của design document

Vậy tại sao chúng ta cần phải cần có một spec đúng?

Bạn hoàn toàn có thể implement dựa trên nội dung ghi trong Product backlog, nhưng chỉ nên duy trì điều đó trong một thời gian ngắn.

Ở mô hình phát triển Agile, chúng ta sẽ bắt đầu phát triển với một mô hình hệ thống nhỏ tối thiểu, thường trước hết chúng ta sẽ release MVP (Minimum Viable Product: Sản phẩm khả dụng tối thiểu), và liên tục cải thiện trong thời gian dài dựa theo feedback của người dùng.

Trường hợp các member tham gia dự án ngay từ đầu, nắm rõ ngọn ngành và spec thì có thể duy trì dự án mà không gặp vấn đề gì với Product backlog, tuy nhiên nếu có member mới join vào, hoặc ngược lại, các member cũ rời khỏi dự án vì nhiều lý do, thì khó có thể tránh khỏi nhiều hiểu lầm xảy ra nếu dự án được tiếp tục duy trì lâu dài.

Khi đó, cần phải có design document với những yêu cầu cơ bản chính xác và mới nhất ở thời điểm hiện tại để không phải chỉ truyền đạt với nhau bằng miệng.

Trước hết, trí nhớ của con người không phải lúc nào cũng hoàn chỉnh (duy trì thông tin đầy đủ và nhất quán), nên điều quan trọng là phải có một nơi (tài liệu) lưu giữ thông tin chính xác (source of truth) thay vì dựa vào trí nhớ.

Vì design là nội dung đã được thống nhất thông qua review của client và engineer, nên nếu có action nào khác với description trong product, thì có thể là bug hoặc đã bỏ sót thông tin.

Tóm lại, Product backlog hữu ích trong vòng đời phát triển (life cycle develop) ngắn hạn, còn design document có thể được coi là công cụ cần thiết để lưu trữ lâu dài.

Vai trò của design document
Cần phân biệt giữa Product backlog và design

4. Bạn hiểu rõ tầm quan trọng của Design document nhưng nó lại quá phiền phức

Tôi sẽ tạm dừng phần giải thích về vai trò của Product backlog hay design document ở đây.

Các engineer thường hay nói “Tôi hiểu design document rất quan trọng, nhưng tôi không có thời gian để tạo chúng”, hoặc “Nó không thú vị bằng viết code (tôi không có hứng thú).”

Những người như vậy thường tránh viết tài liệu vì họ muốn tập trung coding trong một khoảng thời gian đã được đề ra, nhưng nếu cứ tránh thì họ sẽ không tiến bộ và sẽ tạo nên một vòng luẩn quẩn ngày càng muốn né tránh.

Ở SupremeTech, chúng tôi phân chia và triển khai đầu công việc thành hai mảng là document và coding với hệ thống resource gồm có Business Analyst (BA) – người sẽ cùng với client và engineer triển khai yêu cầu thành Product backlog, design document, và Software Engineer (SE) – người sẽ phát triển phần mềm dựa trên những yêu cầu đó.

Việc tạo design document thường tập trung chủ yếu vào phase 0 đến 1 trong thời gian đầu của project, và một khi design document được tạo xong, phần còn lại chỉ là update các phần cần thay đổi, vì vậy giả sử bên SE phải update thì rào cản tâm lý cũng sẽ giảm đi đáng kể, do phần tài liệu mà họ cần phải làm chỉ là phần update.

Việc tạo design document ban đầu là một trong những nhiệm vụ của BA và thông qua quá trình này, họ có thể nắm được yêu cầu và hỗ trợ cho project với tư cách là spec holder.

Mặc dù vậy, khi quy mô MVP lớn hoặc trong trường hợp tiến hành dự án đã được phát triển từ phía công ty khác nhưng lại không có design document thì gánh nặng cho BA sẽ rất lớn. Trong trường hợp đó, Japanese Communicator (JC) sẽ đảm nhiệm phần biên/phiên dịch để có tạo ra design. Trong career path của chúng tôi, những JC sau này đều sẽ có hướng phát triển thành BA nên điều này cũng vừa có ích cho việc đào tạo công việc BA cho JC để phát triển trong tương lại.

Bằng cách phân chia công việc như thế này, việc tạo/ duy trì design document được thực hiện như yếu tố cần thiết để phát triển phần mềm, tương tự như coding của SE, hoặc việc phân chia task, lập kế hoạch và quản lý tiến độ của PM là không thể thiếu.

Bạn hiểu rõ tầm quan trọng của Design document nhưng nó lại quá phiền phức

5.  Ba cách để ứng dụng tốt cả Product Backlog và Design document

Trước đây khi còn là Senior BA tại công ty phát triển phần mềm Offshore tại Việt Nam, cũng đã từng điều hành dự án sử dụng cả Product backlog và Design.

Nên tôi muốn giới thiệu cho mọi người một số mẹo mà cá nhân tôi thấy dễ thực hiện.

1. Update timing

Product backlog được sử dụng để thiết lập spec trong life cycle develop ngắn hạn nên thường xuyên được update.

Mặt khác, design document dùng để duy trì lâu dài không yêu cầu phải cập nhật realtime, nên tôi nghĩ nó có thể sắp xếp thời gian để update nó khi mà yêu cầu đã ổn định hơn, không còn thay đổi nhiều nữa. Cụ thể, thời điểm SE bắt đầu coding, hay thời điểm tiếp nhận yêu cầu từ client, yêu cầu sẽ được đưa lên Product backlog, sau đó chúng ta mới tiến hành update design document.

Tất nhiên, điều này không áp dụng nếu project được phát triển dựa hoàn toàn trên design document.

2. Sử dụng tool

Bạn nên sử dụng tool quản lý ticket để có thể quản lý Product backlog. Có rất nhiều tool khác nhau như Backlog, Github issue, Redmine,… nhưng bạn có thể lựa chọn tuỳ thích miễn là tool đó có thể assign function, set milestones, change status, change notifications. Github issues có thể sẽ hữu ích cho engineer khi họ còn có thể sử dụng Github để quản lý task và code version cùng 1 chỗ.

Tôi thường thấy nhiều trường hợp sử dụng Spreadsheet để quản lý Product backlog, nhưng tôi nghĩ đây lại là một antipattern. Ở life cycle develop ngắn hạn hay được update thường xuyên, Spreadsheet lại không có function thông báo về các cập nhật, nên khả năng sẽ xảy ra nguy cơ không để ý và bỏ quên nội dung nếu có ai đó add/change/delete chúng.

Hơn nữa, so với Product backlog, ta thường sử dụng Spreadsheet cho các design có tần suất update thấp. Các thay đổi sẽ bị lưu lại trên sheet lịch sử thay đổi. Cũng có ý kiến khắt khe cho rằng không nên sử dụng Spreadsheet cho bất cứ cái gì ngoại trừ cho bảng tính (excel), nhưng tôi nghĩ dùng công cụ gì cũng được miễn là nó được sử dụng một cách thích hợp với nhu cầu trên thực tế.

3. Có cần tách riêng giữa client và internal không 

Tốt hơn là nên tách Product backlog thành một bên cho client (client và BA sử dụng) và một bên cho internal (Project members như BA, PM, SE sử dụng).

Đầu tiên phải kể đến vấn đề ngôn ngữ. Việc chuẩn bị product backlog cần những  đổi phức tạp, hoặc mang tính khái quát cao về product sẽ như thế nào, nên nhiều trường hợp client muốn thảo luận bằng ngôn ngữ mẹ đẻ (tiếng Nhật hoặc tiếng Anh) càng nhiều càng tốt. Nhưng kĩ sư người Việt lại không sử dụng thành thạo tiếng Nhật hoặc tiếng Anh giao tiếp, nên Communicator sẽ phải dịch sang tiếng Việt hoặc tiếng Anh, và như thế nhiều ngôn ngữ sẽ bị trộn lẫn và đoạn hội thoại sẽ trở nên khó đọc.

Tiếp theo là vấn đề về độ chính xác, chi tiết của thông tin. Việc spec thay đổi thường xảy ra trong quá trình thảo luận, nhưng có nguy cơ là PBI của client được bắt đầu triển khai sớm ngay cả khi yêu cầu đó vẫn đang trong giai đoạn thảo luân, dẫn đến phải làm lại. Ngoài ra, nếu nhiều yêu cầu được thảo luận trong một ticket hoặc ngược lại, các yêu cầu tương tự được thảo luận trong nhiều ticket, thì phải tách riêng/ tổng hợp nếu cần và sau đó truyền đạt lại cho kĩ sư, như thế sẽ tránh hiểu sai về nội dung công việc.

Từ những điểm trên, chúng tôi đã áp dụng phương pháp tách từng tool và quản lý Product backlog cho client giao tiếp bằng tiếng Nhật và Product backlog cho internal giao tiếp bằng tiếng Anh hoặc tiếng Việt.

Mặt khác, vì cần phải có được sự thống nhất của cả client và engineer sau khi tạo xong design document, nên sẽ tốt hơn nếu viết bằng tiếng Anh trên Spreadsheet chung để mọi người có thể cùng thấy. Nếu dịch những gì đã tạo từ tiếng Nhật sang tiếng Việt, bạn sẽ phải quản lý 2 phiên bản tiếng Nhật và tiếng Việt, và nếu có một bản được chỉnh sửa, nhưng bản kia lại bị sót, thì khả năng hiểu sai spec giữa client và engineer sẽ xảy ra.

Dù được viết bằng tiếng Anh, design cũng chỉ đơn giản là mô tả các yêu cầu với nội dung giải thích dài thành một câu giải thích ngắn hơn, nên trừ khi client của bạn là người không thích tiếng Anh, thì nó vẫn có thể chấp nhận được.

Ba cách để ứng dụng tốt cả Product Backlog và Design document
Luồng thực hiện khi tóm tắt Tips 1-3

Flow hoạt động này chỉ là phương pháp hay nhất từ ​​kinh nghiệm của riêng tôi nên không có nghĩa là sẽ áp dụng được trong mọi tình huống.

Cơ bản, tôi nghĩ sẽ không sao khi lựa chọn work flow hay tool dựa trên đặc điểm của từng dự án, sở thích và kinh nghiệm của các bên liên quan (stakeholder), hoặc là quan điểm tôn giáo (^^).

Nếu design documentation hiện tại của bạn không hữu dụng nhiều, bạn có thể lấy cách làm này để tham khảo.

6. Kết thúc

Bài viết này dùng để truyền đạt vai trò của design document và cách tương tác cho những bạn không hiểu vì sao lại cần design document hoặc những bạn đang gặp vấn đề về cách vận dụng nó.

Ngay cả ở công ty SupremeTech, tôi cũng muốn hỗ trợ và truyền đạt cho các member của chúng tôi có thể nhận thức rõ tính quan trọng của design document và những rủi ro khi không có nó, cũng như để phân bổ nguồn nhân lực cần thiết.

※ Bài viết này được phiên dịch từ bản tiếng Nhật được viết trên Enlyt Blog.

Related Blog

online retailing triumph 1 modern offshore development

Our success stories

Software Development

+0

    Online Retailing Triumph #1: Explore Modern Offshore with SupremeTech & Classmethod

    Unlock the Power of Partnership in Customer Service in Online Retailing with SupremeTech, a journey through excellence, collaboration, and innovation. SupremeTech's commitment to continuous improvement led to vital projects, thanks to their partnership with Classmethod. They excel in managing data, ensuring security, and tailoring solutions to client needs. Their ongoing support and dedicated client teams ensure sustained success. Together we prove that the Modern Offshore model is a winning formula for offshore development. Let's explore how we did that in the series of Online Retailing Triumph. Online Retailing Triumph - Episode 2 Online Retailing Triumph - Episode 3 Tackling Data Challenges in Customer Service Digitalization When discussing Customer Service Digitalization, individuals often focus on optimizing the user experience with every click of a button. However, the cornerstone of this digital transformation lies hidden behind each user interface - Data. In the customer service industry, safeguarding customer data is of paramount importance. This is precisely where SupremeTech initiated a collaboration, partnering with a major coffee chain in Japan and Classmethod. This strategic partnership commenced with the critical task of managing a substantial segment of their extensive system. Without effective data management, the system remains devoid of valuable information for analytics. It is this expertise that led to SupremeTech's selection to handle this pivotal case, marking the beginning of a promising partnership. Identifying the Key Challenges Now, with a few stepIn the realm of customer service digitalization, recognizing and addressing challenges is paramount to success. One of the most pivotal challenges faced by businesses is effectively managing data. This is where the power of partnership comes into play, as exemplified by the collaborative efforts of SupremeTech and Classmethod. Collaborating with multiple vendors in one project SupremeTech's journey in overcoming these challenges begins with a crucial partnership role. Our company and Classmethod work as one of the multiple vendors within a complex project of a big brand of coffee chain. This collaboration laid the foundation for tackling the intricate data management needs of the customer service industry. Offshore development, in this context, plays a pivotal role in efficiently executing the project. It leverages a global approach to resource allocation, enabling us to harness a diverse pool of talent, cost advantages, and time zone differences to meet the project's multifaceted demands. As we work cohesively with Classmethod and other vendors, offshore development ensures a dynamic and comprehensive solution to tackle the intricacies of data management in the customer service industry. Dealing with Unpredictable Daily Data Imports A significant hurdle in this endeavor was dealing with the unpredictable nature of daily data imports. SupremeTech, in partnership with Classmethod, needed to develop solutions that could adapt to the ever-changing influx of data, ensuring seamless operations and data security. Collaborating seamlessly alongside Classmethod, our joint team conducted research and maintained a robust line of communication. Every update was consistently shared and cross-verified with the customer, ensuring optimal outcomes. Extracting Data from Store Sources Furthermore, recognizing the paramount importance of data security in the business sphere, SupremeTech unwaveringly prioritized safeguarding every feature and piece of information. The process of extracting data from diverse store sources demands a delicate balance of precision and security, and SupremeTech excels in this critical domain. Here's a closer look at how they manage this intricate task. SupremeTech's approach begins with meticulous research and analysis. They recognize that the data extracted holds the key to unlocking invaluable insights for data analytics. Thus, they leave no stone unturned in understanding the nuances of each client's store sources. One of the standout qualities of SupremeTech is their commitment to maintaining the utmost secrecy and precision during data extraction. Recognizing that data is often a company's most closely guarded asset, they implement stringent security protocols to ensure that data remains confidential and protected throughout the extraction process. SupremeTech's Successful Challenge Conquest SupremeTech's journey in conquering challenges in data management is a testament to its commitment to excellence and its invaluable partnership with Classmethod. From Research to Specialized Data Management Expertise Our success story begins with thorough research, leading to the development of specialized expertise in data management. Supreme Tech's dedication to staying at the forefront of industry knowledge has empowered them to provide innovative solutions. Careful and Methodical Problem Solving with Partner In partnership with Classmethod, SupremeTech approaches challenges with a careful and methodical problem-solving approach. Their synergy ensures that complex issues are addressed comprehensively and efficiently. SupremeTech Customized Solutions for Client-Centric Success SupremeTech's expertise shines through in its ability to tailor solutions that seamlessly align with each client's unique objectives and intricate system requirements. These customer-centric solutions are the cornerstone of their partnership-driven approach. Ongoing Support and Follow-Up Beyond the initial implementation, Supremetech's commitment to its clients is an unwavering promise of continued support and follow-up, ensuring that the journey toward sustained success remains smooth and fruitful. SupremeTech understands that the digital landscape is dynamic, and business needs can change rapidly. Therefore, they provide dedicated client support teams, equipped with deep expertise and a thorough understanding of the client's specific objectives. This personalized approach ensures that clients have a reliable partner to turn to for assistance, guidance, and troubleshooting. Maintaining Strong Client Partnerships - Classmethod  SupremeTech's dedication to maintaining strong client partnerships, exemplified by its collaboration with Classmethod (CM), underscores its commitment to fostering enduring relationships built on trust and reliability. Committed to Continuous Improvement SupremeTech's unwavering commitment to continuous improvement has earned them a series of significant projects with CM. Their dedication to staying ahead in industry trends and emerging technologies ensures they offer cutting-edge solutions. This commitment has solidified their partnership with CM, demonstrating the tangible benefits of their innovative approach.  In essence, SupremeTech's journey of continuous improvement not only keeps them competitive but also strengthens partnerships and attracts vital projects, underlining their dedication to excellence. Development systems and technologies Below are the resources and technologies we use to develop the services: Details of entrustment: Implementation, Testing, Migration, Maintenance & Operation Platform: Web Development language: PHP, Javascript Let SupremeTech help you to start the system now! Start to invest for your start now with the help of SupremeTech. Our expertise and solutions will empower you to request! Don't wait, let's take the first step towards digitizing your customer service now!

    27/10/2023

    1.11k

    Khanh Nguyen

    Our success stories

    +1

    • Software Development

    Online Retailing Triumph #1: Explore Modern Offshore with SupremeTech & Classmethod

    27/10/2023

    1.11k

    Khanh Nguyen

    virtual office for remote workers

    Our success stories

    +0

      A Virtual Office for Remote and Hybrid Workers

      Today.ly is a virtual office service that provides all of the benefits of a physical office for professionals working from the comfort of their homes. Engaging Alternative for Remote Work The debate between working remotely and working in the office rages on. We won't get into the pros and cons of each work style. However, we believe that working remotely in Today.ly's office simulation can make remote work more fun and interactive (and potentially more attractive to die-hard in-office workers). Sure, the days of everyone being cooped up for months on end are over. For some companies and industries, working from home is no longer a necessity. Today.ly allows teams to work remotely without completely losing the serendipitous moments that physical offices provide.  Working Together as Partners SupremeTech started developing Today.ly after being approached by our current business partner in Singapore. They came to us with the idea of creating a virtual office space during the peak hours of remote work. Our partner relied on us to leverage our expertise in R&D to create and develop an MVP. One of the main reasons for choosing SupremeTech as their partner was the proximity of Vietnam to Singapore. However, they also recognized our ability to deliver a quality product quickly and efficiently.  Communication and Cross-border Collaboration As with most offshore development projects, the communication element can make or break a partnership. SupremeTech works with many companies from all over the world. Our expertise is mainly in the Japanese market. There were some initial challenges in getting used to communicating with a Singaporean partner, but our team overcame these challenges and worked smoothly and successfully with all members of the project. We used Today.ly to organize calls and meetings with our foreign partners because we felt that the product would help create cross-border collaboration. Developing Something More than A Video Call Tool The business idea was born during the pandemic, as were many online learning and work tools. However, we did not build Today.ly with a focus on online calls. We developed Today.ly to mimic more of the spontaneous happenings of the office. It was designed to function like an online office while allowing employees to enjoy the convenience and comfort of their home. We wanted to provide a virtual office that could strengthen the bonds of employees. This is not a video calling service; this is a virtual office that increases collaboration and teamwork amongst team members, even when they are physically separated.  But that was actually one of the main challenges of this project: how can we build something that takes advantage of the benefits of office work, but isn't redundant or completely useless in the market? The answer was to create an online space for communication, not just a communication tool. Nearly all companies use meetings to interact and discuss ongoing projects. For remote meetings, this means using a video call to communicate. There's nothing wrong with a regular video call; in fact, in some cases, it's probably more useful than any other method. Even if you think an email or message would suffice, meetings are inevitable.  Virtual Offices Doing More for Your Business! Sometimes a video call or DM just isn't enough; there's a technological barrier between us and the other participants. Today.ly simulates a meeting room in a way that feels more personal than talking heads in a square. It emulates the physical space. There's crystal clear audio, multi-screen sharing, and even a meeting table and chairs. Nothing can replace face-to-face communication, but Today.ly allows companies to mimic certain aspects while users are sitting in their own living rooms. It will always be a challenge to replicate the old-fashioned face-to-face dialogue, but Today.ly users have found greater motivation and connection within their teams.  Today.ly was initially for companies and industries that support working from home. The features were designed to make working online an interactive experience. While many companies have already returned to traditional office life, Today.ly is still a valuable tool for hybrid work environments and provides all businesses with an exciting alternative to traditional working environments.

      27/10/2023

      1.2k

      Logan Johnson

      Our success stories

      +0

        A Virtual Office for Remote and Hybrid Workers

        27/10/2023

        1.2k

        Logan Johnson

        How Agile development influences developer and QA tool choices

        Software Development

        +0

          How Agile Development Influences Developer And QA Tool Choices

          On the surface, it might seem like the Agile methodology is simply about reimagining waterfall development by keeping an open mind. However, this approach has far-reaching implications for people, tools and processes. That said, let’s dissect the major Agile development characteristics that affect developer and quality assurance (QA) tool choices and talk about some great examples of Agile development tools: Increased Collaboration Agile development pushes for greater synergy amongst teams. It's hard to release higher-quality products faster if many of the people involved aren't openly communicating with each other about challenges. For example, a developer working alone can easily store, manage and reuse code using one machine. However, things get trickier once a project needs more hands and numerous software units are being created. You'll need a space where everyone's work can be converged, with changes indicated coherently. Photo by Tim van der Kuip on Unsplash  This is where tools like GitHub come in. GitHub will enable developers to combine their code into modules and easily perform version control. More importantly, developers can do all this remotely since it's cloud-based. It’s also worth noting that GitHub isn’t the only code hosting/management solution out there. You can always try others like TaraVault, AWS CodeCommit, Bitbucket, SourceForge, and many more. By the way, collaboration doesn’t begin only when the team has been formed. It’s an ethos that can be applied even when building the team and responding to talent departure or unavailability. With tools like Crowdsource.io, you can set up a project folder, post your needs and respond to interested developers. This social approach simplifies recruitment, especially during emergencies. Continuous Testing In continuous testing, teams don’t have to wait for all units to be ready before they start. Instead, they endeavor to test whatever small piece is ready as others are prepared. By doing so, they are less likely to be blindsided by complex problems in the software that delay a release as the team tries to fix them. This approach often means the testing workload will fluctuate as the project progresses, so quality assurance teams will have to be swifter at scaling testing capacity accordingly. One of the best ways to achieve this is by using test automation tools. Photo by freestocks on Unsplash More specifically, you'll need user-friendly test automation tools if teams are to quickly add new automations in response to changes in the testing workload. They should also facilitate reusability and easily plug into your CI/CD pipelines, which is what tools like Leapwork are good at. Additionally, an Agile testing team needs robust tracking and reporting capabilities to excel at continuous testing. This is where tools like JIRA and nTask Issue Tracker shine. They’ll offer features tailored to defect tracking while also helping you analyze QA team performance in real time so you can know how to increase efficiency and remain on schedule. Value-Driven Development You can only offer so much value if you aren't listening and responding to users. So to get better at value-driven development, you must create a smoother path for user feedback to be absorbed into the development lifecycle promptly. Photo by krakenimages on Unsplash One critical piece in this area is the usability testing tools you rely on. They should have functionality that speaks to agility, such as; Recruiting participants remotelyA/B testingIntegration with various tools like prototyping solutions, design tools, productivity tools and more. These are some of the crucial functions needed because: You want to be able to start user feedback collection from anywhere as soon as you get the green light. In that sense, participant recruitment should involve as little bureaucracy as possible and be easier to manage as you conduct more tests down the road. Testers should be able to compare feature variations side-by-side instead of testing one, then trying another later. So through A/B testing, you shorten the time it takes to discover whether a slight tweak in a feature caused a significant improvement in usability. Once you have user opinions and usability metrics, there shouldn't be that many error-prone processes to link the data to the concerned parties and the different tools they use to respond to the feedback. Whoever is going to modify a product should be able to quickly see how their previous contribution fared. The other leaders who have to sign off on additional changes should also be able to view this information simultaneously, so there isn't much sitting and waiting. Tools like UserZoom, Loop11, UsabilityHub, Userlytics and Maze will go a long way in helping you increase the customer value realized with each iteration. The glue that holds everything together While we’ve talked about the Agile QA process and Agile development software, another key aspect is more about the administrative side of an Agile project. When it comes to this area, you'll hear a lot of buzzwords and office terminology thrown around, like modularity, effective communication and visibility. But to be clearer about the tenets of organizational agility, here’s what Agile teams should emphasize during the development life cycle: Teams should be able to zoom in on the smallest of processes as this is how they'll know what's essential and what isn't and also what could be improved. Organizations should give more autonomy to the lower ranks so they can do some things at their discretion. If every small move has to first be run up a long chain of command, all in the name of maintaining control and minimizing risk, you can forget about faster releases. Whatever you practice should be incremental. For example, when figuring out how to communicate better, you don't just set benchmarks and lean back. Instead, you should revisit them to see if they are working and decide whether to maintain, increase, decrease or move sideways. So how exactly do these principles shape tool choices? Well, you’ll need Agile project management tools that offer features like automated notifications, workflow customization, analytics and recommendations. There are plenty of options to try; Agilean, ProofHub, ActiveCollab, MeisterTask, Axosoft, JIRA and DailyScrum. Wrapping Up Ultimately, tools that work for some may not work for you, so it starts with understanding your existing organizational culture and how much you're willing to alter it in pursuit of agility. That’s when you’ll know where tools are applicable and which functionality they must have. To learn more about how to pick the right developer and QA tools for Agile development, contact us for a free consultation.

          17/11/2022

          1.31k

          Software Development

          +0

            How Agile Development Influences Developer And QA Tool Choices

            17/11/2022

            1.31k

            Anh Hoàng - “Người truyền lửa” trên hành trình vươn mình của SupremeTech

            Our culture

            +0

              Anh Hoàng – “Người truyền lửa” trên hành trình vươn mình của SupremeTech

              “Khởi nghiệp với rất nhiều “không”. Không bệ phóng. Không mối quan hệ. Không đội ngũ. Tất cả những gì anh có là bản thân mình với một tinh thần lạc quan và ý chí không bao giờ bỏ cuộc.”Anh Hoàng, Chủ tịch SupremeTech. Gặp anh Hoàng lần đầu sau khi bắt đầu làm việc tại văn phòng chừng 1 tuần, ấn tượng của tôi đúng với những gì mường tượng về anh sau buổi phỏng vấn online trước đó 2 tháng. Là một người anh lớn với phong thái giản dị, điềm tĩnh từ cử chỉ tới cách nói chuyện, nhưng mỗi lời nói của anh đều toát lên nhiệt huyết của người dẫn đường. Còn nhớ trong buổi trò chuyện hôm đó, không có khi nào anh đề cập tới mục tiêu, kế hoạch hay KPI. Bắt đầu từ câu chuyện trở về Việt Nam của anh, rồi hành trình đặt những viên gạch đầu tiên ở thị trường IT, Tech còn rất hoang sơ ở Đà Nẵng năm 2014 và cuối cùng là điểm dừng chân hiện tại - SupremeTech - ngôi nhà của 200 nhân sự tài năng, tất cả những gì đọng lại trong một nhân viên mới khi đó là sự hứng khởi khi được đồng hành trên chặng đường phía trước, có thể sẽ gập ghềnh nhưng chắc chắn vô cùng đáng nhớ. Sự hứng khởi, và có phần an tâm ấy, được nhen nhóm từ chính những chia sẻ rất đời thường của anh Hoàng.  Có lẽ sẽ hẹn một dịp khác để kể lại từng dấu mốc trong 11 năm khởi nghiệp của anh Hoàng. Còn trong buổi trò chuyện đặc biệt nhân dịp kỉ niệm 5 năm thành lập SupremeTech này, khi ngồi cùng với nhóm các nhân viên, cả những người đã gắn bó với công ty từ ngày đầu, chúng tôi muốn nghe và kể nhiều hơn về quá trình xây dựng và phát triển công ty từ con số 0. Dưới góc nhìn của anh Hoàng - người đã mở đường và vẫn đang dẫn đường, câu chuyện ấy sẽ thêm phần thú vị. Hành trình vạn dặm bắt đầu từ một bước chân Năm 2014, Đà Nẵng đã nổi tiếng là một thành phố du lịch hút khách bậc nhất miền Trung. Nhưng nhắc tới công nghệ thì cái tên Đà Nẵng còn rất xa lạ. Giáo dục các ngành IT, Tech cũng chưa được chú trọng và phần lớn nhân tài ngành này chọn lập nghiệp ở những thành phố nhiều cơ hội như Hà Nội và Hồ Chí Minh. Nhân sự IT chất lượng ở Đà Nẵng khi đó có lẽ chỉ đếm trên đầu ngón tay. Khó khăn vậy mà khi được hỏi tại sao anh lại chọn trở về Việt Nam khi đã có sự nghiệp vững chắc tại Nhật, anh Hoàng chia sẻ: “Thời anh đi học ở Nhật, khoảng cách phát triển giữa hai nước còn rất xa về mọi mặt. Anh nung nấu ý định trở về để làm đất nước mình lớn mạnh hơn. Anh nghĩ người Nhật làm được thì người Việt chúng ta cũng làm được. Bắt đầu từ việc phát triển bản thân mình để trở thành một người có ích cho xã hội, mang lại giá trị cho những người xung quanh mình, rồi tiến tới đóng góp vào sự phát triển của đất nước. Nhưng mong muốn thôi là chưa đủ để biến ước mơ thành hiện thực, nhất là khi mình chưa tích lũy nội lực cho bản thân. Quãng thời gian ở Nhật cho anh tiếp cận với rất nhiều góc nhìn mới. Cả tính kỷ luật và tư duy tốt lên mỗi ngày cũng được rèn giũa trong những năm tháng anh học và làm việc ở đó. Có thể nói khi đủ đam mê, đủ nhiệt huyết và đủ năng lực theo đuổi đam mê thì cơ duyên về Việt Nam cũng xuất hiện để anh trở về khởi nghiệp và đạt tới những thành công nhất định như ngày hôm nay.” Sự thật là hành trình vạn dặm nào cũng bắt đầu từ một bước chân. Mà trong câu chuyện này, đó là bước chân trở về. Chặng đường đáng nhớ cùng SupremeTech Không khó để hình dung những khó khăn của một công ty được thành lập ngay giữa đại dịch Covid-19 rúng động thế giới. Những ngày đầu, công ty chỉ có vài chục nhân sự là những người em mà anh Hoàng từng dẫn dắt. Vào đúng giai đoạn cần nhiều kết nối con người làm nền tảng phát triển đội ngũ mới, cả công ty phải làm việc ở nhà để đảm bảo an toàn. “Cái khó ló cái khôn”, khoảng cách địa lý lại là động lực thúc đẩy những ý tưởng sáng tạo để gắn kết nhân sự, điển hình như cuộc thi “Capture WFH moments” hay hoạt động viết blog. Đúng như mindset tự chủ, trưởng thành từ hành động, không ngại thử thách mà anh Hoàng vẫn lan tỏa: “Chưa bao giờ anh có cảm giác chùn bước vì anh luôn sẵn sàng đối diện với khó khăn. Càng khó khăn thì anh càng muốn chinh phục và nâng cao nội lực bản thân mình. Anh luôn giữ trong đầu câu hỏi “Vì sao người khác làm được?” làm kim chỉ nam để tiến về phía trước. Ban đầu cần luyện tập để nâng cao khả năng chịu stress cả về tinh thần và tính cách. Lâu dần nó “ngấm” vào con người mình lúc nào không hay (cười).”  Ý tưởng sản phẩm MiaHire cũng thành hình trong chính giai đoạn này. Làm sao để tuyển dụng gần 100 nhân sự/năm với nguồn lực có hạn và hạn chế về địa lý trong đại dịch? Khi những “pain points” phát sinh từ câu hỏi này được giải quyết cũng là lúc sản phẩm MiaHire - Nền tảng phỏng vấn video ra đời và có những khách hàng đầu tiên.  Rồi tới biến động kinh tế, khủng hoảng thị trường, sự rớt giá của đồng Yên…lần lượt từng thử thách đi qua khiến cho đội ngũ SupremeTech thêm vững vàng hơn, trưởng thành hơn. Khi được hỏi khoảnh khắc nào đáng nhớ nhất với anh Hoàng trong 5 năm thăng trầm vừa qua, câu trả lời không phải là những con số doanh thu, những dự án mới, sản phẩm mới, khách hàng mới hay thị trường mới. Đối với anh Hoàng, di sản của 5 năm gieo mầm chính là những con người đang trưởng thành trong môi trường SupremeTech.  “Khi anh thấy những người đã đồng hành từ những ngày đầu giờ đây đang trưởng thành lên từng bước một, đó là khoảnh khắc làm anh xúc động nhất. Giờ đây anh không cần phải có mặt trong từng sự kiện hay hoạt động để dẫn dắt mọi người nữa, mà mọi người đã tự tin tổ chức, tự mình dẫn dắt, làm mọi thứ bằng nhiệt huyết và tinh thần của chính các bạn.  Anh mong muốn tất cả những người đến với anh, đi cùng anh, đều có thể từng bước trưởng thành hơn. Anh luôn tâm niệm rằng sống một đời thì không quá dài, nên anh muốn sống cho thật có ích. Anh muốn mình trở thành hình mẫu mà mình thích trước tiên, và tạo nên SupremeTech là nơi mà không chỉ cho riêng anh, mà còn cho tất cả các bạn đi cùng anh được sống đúng với giá trị của mình, được phát triển, và rồi một ngày nào đó, chính họ lại trở thành người truyền lửa cho người khác và đem đến sự phát triển của đất nước, xã hội.” Có lẽ chính triết lý phát triển con người đó của anh Hoàng là xương sống cho sự phát triển bền bỉ của công ty. Một khi đồng hành cùng những người có chung tầm nhìn, khó khăn hay thử thách chỉ là chất xúc tác làm cho tinh thần đồng đội thêm bền chặt. Tự chủ trong mỗi bước đi Từ khi thành lập tới nay, một trong những hoạt động nổi bật được giới thiệu tới mọi nhân viên mới đó là học và thi lấy chứng chỉ chuyên môn. Mọi người đều được khuyến khích nâng cao năng lực trong lĩnh vực của mình và học thêm kiến thức mới. SupremeTech coi đây là một khoản đầu tư chiến lược cho nội lực của công ty.  Ngoài chuyên môn, định hướng trao quyền tự chủ về nhiều mặt cho mỗi thành viên là một trong những động lực lớn cho sự phát triển văn hóa công ty và kết quả kinh doanh tích cực. Anh Hoàng giải thích: “Tự chủ không chỉ là khi công ty có thể tự vận hành, tự đưa ra định hướng, mà còn là khi mỗi cá nhân trong tập thể biết cách chịu trách nhiệm với công việc của mình, biết cách đóng góp giá trị một cách độc lập và chủ động. Đó là lý do năm 2025, SupremeTech tổ chức rất nhiều hoạt động nội bộ để tôn vinh tinh thần tự chủ: từ sinh hoạt ST, nơi các bạn có thể tự điều hành và chia sẻ suy nghĩ của mình, đến các hoạt động nội bộ, các hội thi thể thao…”   Một cột mốc rực rỡ khép lại là lúc mở ra những chương mới hứng khởi hơn. Ở vị trí của người cầm đuốc, anh Hoàng giúp chúng tôi hình dung rõ ràng về SupremeTech của 5 năm tiếp theo. “Nếu giai đoạn 5 năm đầu là lúc chúng ta gieo mầm từ văn hoá, con người đến nội lực công ty thì 5 năm tới, anh mong được thấy sự tự chủ thật sự của SupremeTech. Mục tiêu của chúng ta là vững vàng đứng trên đôi chân mình. Các sản phẩm product của chúng ta sẽ lớn mạnh và gặt hái được nhiều thành công hơn, và SupremeTech sẽ ngày càng trưởng thành và vững mạnh, dù là trong vận hành hay trong việc tìm kiếm cơ hội.” Ngày mai tốt hơn hôm nay, một centimet là đủ  Buổi nói chuyện cùng anh Hoàng như thước phim tua lại những khoảnh khắc đáng nhớ trong suốt hành trình 5 năm. Mỗi người đều có dịp ôn lại góc nhỏ của mình trong bức tranh chung của SupremeTech. Vì thời lượng có hạn nên dù còn nhiều điều muốn chia sẻ, cả team đành phải hẹn anh Hoàng ở một dịp khác. Như muốn giữ lại chút dư âm sau cuộc trò chuyện, chúng tôi đồng lòng:  “Còn điều gì anh muốn gửi gắm tới tập thể SupremeTech trong dịp đặc biệt này không?” Anh Hoàng: “Hãy enjoy với mọi trải nghiệm dù là tốt hay xấu. Hành trình nào cũng đáng quý kể cả khi nó gập ghềnh, khó khăn. Miễn là ta không bỏ cuộc, vẫn còn đi tiếp, và giữ được sự tích cực trong mỗi bước đi. Người thành công không phải là người may mắn nhất, mà là người không bỏ cuộc. Người dám đi tới cùng với đam mê lớn mạnh của mình sớm muộn cũng sẽ đến được đích. Các bạn hãy nhớ rằng không ngừng trau dồi và rèn luyện bản thân mỗi ngày, ngày mai tốt hơn hôm nay một centimet là đủ.” Hành trình tiếp theo vẫn là những bước chân bền bỉ 5 năm không phải một chặng đường quá dài, nhưng đủ để một hạt mầm vươn mình trở thành cây vững gốc. SupremeTech đã và đang lớn lên như thế bằng sự bền bỉ, bằng nội lực, và bằng tinh thần "tốt hơn hôm qua một centimet". Cảm ơn anh Hoàng vì cuộc trò chuyện đầy cảm hứng và ý nghĩa! >>> Đọc thêm: From Seeking The Path to Leading The Way: Phuoc’s Journey at SupremeTechAnh Duong – A Journey of Rising Above to Shine Bright

              18/07/2025

              98

              Our culture

              +0

                Anh Hoàng – “Người truyền lửa” trên hành trình vươn mình của SupremeTech

                18/07/2025

                98

                Customize software background

                Want to customize a software for your business?

                Meet with us! Schedule a meeting with us!