Tóm tắt: Khám phá 10 mẹo nhỏ cần thiết để tạo các ứng dụng Phần mềm là dịch vụ (SaaS) hoàn thành đúng hạn và tiết kiệm ngân sách, mang lại lợi nhuận đầu tư dương và thích hợp hơn.
Phần mềm được cung cấp như một dịch vụ trực tuyến, chứ không phải là một ứng dụng trên máy tính để bàn, tiếp tục ngày càng được công chúng yêu thích hơn với tốc độ theo cấp số nhân. Tôi đã dành hết tâm trí cùng với một số doanh nghiệp tập trung vào SaaS. Và trong thời gian đó, tôi đã sưu tập 10 yếu tố then chốt cụ thể để phát triển phần mềm có thể xác định xem một ứng dụng SaaS có trở nên thành công không và — trong nhiều trường hợp — liệu nó có được phát hành không. Những mẹo nhỏ này nhằm mục đích đưa ra một viễn cảnh sáng tỏ về phát triển dựa trên SaaS.
1. Làm cho UXD trở thành tài sản có giá trị nhất của bạn
Với sự ra đời của Internet, sự chú ý đến trải nghiệm người dùng đã biến mất. Tuy nhiên, chắc đã có cú hích ngược lại rõ ràng và hiển nhiên về hướng đặc điểm quan trọng này của phần mềm thành công trong những năm gần đây. Sự trở lại này đã được đánh dấu khi thuật ngữ Web 2.0 lần đầu tiên đã trở thành một từ thông dụng, cuối cùng chuyển thành một cái gì đó có ý nghĩa hơn: các ứng dụng Internet phong phú (RIA). Tôi cố ý đặt thiết kế trải nghiệm-người dùng (UXD) ở vị trí số 1 trong bài viết này bởi vì trải nghiệm người dùng là một đặc điểm có thể nhận biết được, ngay lập tức làm cho người dùng máy tính chọn một ứng dụng này hơn ứng dụng khác.
Hình 1 và Hình 2 thể hiện hai kỹ thuật UXD thú vị. Hình 1 minh họa một khái niệm được biết đến là ở lại trang này.Vì đây là một ứng dụng máy khách RIA nhẹ được xây dựng bằng cách sử dụng Adobe® Flex, nên rõ ràng không có trang nào. Tuy nhiên, kỹ thuật này vẫn còn hợp lệ. Kịch bản trường hợp sử dụng này là một người dùng muốn thay đổi các thiết lập tài khoản cá nhân của mình. Thay vì rời khỏi trạng thái (hoặc trang) hiện tại của ứng dụng, một cửa sổ phủ ngoài được hiển thị cho phép người dùng thực hiện các thay đổi cần thiết, sau đó đóng cửa sổ và quay trở lại nhiệm vụ sắp tới.
Hình 1. Ví dụ về kỹ thuật UXD được gọi là ở lại trang 
Hình 2 hiển thị một khung nhìn gần gũi hơn của cửa sổ đã đưa ra trong Hình 1, nhưng theo hai cách. Trường hợp sử dụng này cụ thể hơn ở chỗ nó được giả định rằng người dùng muốn thay đổi các giá trị Company Information (Thông tin công ty) một cách riêng biệt và, do đó, cần lựa chọn thanh tiêu đề tương ứng. Cửa sổ 1 hiển thị trạng thái cửa sổ khi được hiển thị lần đầu. Cửa sổ 2 cho thấy trạng thái cửa sổ sau khi người dùng đã nhấn vào thanh Company Information. Kỹ thuật này được gọi là trình đơn đàn ắc-coóc-đê-ông (accordion menu) do cách các ngăn trượt lên và xuống giống như đàn ắc-coóc-đê-ông khi thanh tiêu đề tương ứng của chúng được lựa chọn. Hoạt động này nâng cao kinh nghiệm người dùng bởi vì nó làm cho người dùng dễ dàng xác định vị trí và cập nhật nhanh chóng và dễ dàng một hoặc nhiều giá trị khi phải phân loại các thiết lập.
2. Thích ứng với các yêu cầu thay đổi
Nếu có một điều không thể tránh khỏi trong quá trình phát triển phần mềm, thì đó là ứng dụng khách, khách hàng, hoặc chủ sở hữu sản phẩm sẽ thay đổi các yêu cầu của dự án sau khi đã hoàn thành tất cả thiết kế, lập kế hoạch, tạo biểu đồ, và tạo nguyên mẫu. Hầu hết các nhà quản lý dự án được đào tạo theo các phương pháp luận truyền thống, và một phần của chương trình đào tạo đó là đối phó với thay đổi; kết quả là một mức độ tăng dần nguy hiểm về sự "thoái hóa" gần giống với sản phẩm đạt đến bản phát hành chính thức đầu tiên của nó.
Việc phát triển phần mềm tiến triển nhanh đến mức thật không khó để tìm ra phương pháp luận quản lý dự án lõi đang thay đổi nhiều lần trong suốt vòng đời của quá trình phát triển ban đầu. Kết quả là, sẵn sàng thực hiện các phương pháp luận phát triển mới hoặc các biến thể của phương pháp luận hiện có với mọi dự án.
3. Chấp nhận các chuẩn mở
Các công ty dựa vào SaaS phải xem xét việc chấp nhận các chuẩn mở vì khả năng tương thích với các thiết bị, các nền tảng, các dịch vụ, và các ứng dụng Web khác thể hiện qua việc mã hóa ít hơn các quá trình lặp lại và việc chấp nhận người tiêu dùng sản phẩm lớn hơn trong tương lai. Người tiêu dùng đánh giá cao và bị hút về ứng dụng SaaS cho phép họ hoàn thành nhiều nhiệm vụ. Ví dụ, Hình 3 cho thấy TweetDeck, một ứng dụng làm việc trên nhiều nền tảng sử dụng các API mở của Twitter và Facebook trong một giao diện. TweetDeck đang nhanh chóng trở thành một trong những ứng dụng khách Twitter phổ biến nhất, chủ yếu là do những người dùng Twitter cũng có thể xem các cập nhật trạng thái của các bạn bè Facebook của họ mà không cần chuyển đổi các ứng dụng.
Hình 3. Ứng dụng TweetDeck phổ biến sử dụng các API mở của Twitter và Facebook
Có thể làm giảm đáng kể chi phí tài chính cho một doanh nghiệp bằng cách sử dụng các công cụ dựa trên các chuẩn mở vì lệ phí cấp giấy phép được loại bỏ, và chi phí tài nguyên giảm bớt bởi vì bạn có một điểm khởi đầu vượt xa nơi bạn sẽ tới nếu bạn vẫn đang xây dựng từ đầu. Sau đó, bạn có thể phân phối tài nguyên để thay đổi mã nguồn nhằm đáp ứng các nhu cầu và các thách thức kinh doanh. Ví dụ, các tác giả của TweetDeck có thể tập trung vào việc xây dựng các tính năng trải nghiệm người dùng trong các ứng dụng, thay vì phải làm việc trên các API của Twitter và Facebook, vốn rất nặng nề.
Hãy xem: Điều gì sẽ xảy ra nếu Twitter và Facebook tính tiền sử dụng các API của họ? TweetDeck sẽ có thể phải thu phí sử dụng hàng tháng với người dùng sao cho công ty có thể trả cho Twitter và Facebook phí để sử dụng các API của họ. Hoặc người dùng sẽ phải trả cho Twitter và Facebook một khoản phí hàng tháng chỉ để sử dụng ứng dụng TweetDeck. Ảnh hưởng mang lại sẽ làm thiệt hại cho TweetDeck, Twitter, và Facebook, và TweetDeck có thể không còn được coi là một ứng dụng SaaS thành công nữa.
4. Phác thảo cấu trúc chung trước khi thiết kế
Một phác thảo cấu trúc chung (wireframe) đơn giản chỉ là một sự hình dung dựa trên khái niệm về một trạng thái cụ thể của giao diện người dùng của một chương trình phần mềm theo quan điểm chức năng, như hiển thị trong Hình 4. Lưu ý rằng không có thiết kế ấn tượng nào. Mục đích là để tránh bị phân tâm bởi các phần tử thiết kế sao cho có thể duy trì sự tập trung vào chức năng nghiệp vụ. Một khi đã thiết lập các chức năng nghiệp vụ của ứng dụng, nhóm thiết kế có thể có ở đó; nhưng phần mềm phải chỉ rõ chức năng trước khi nó có thể trông đẹp mắt.
Hình 4. Phác thảo cấu trúc chung đưa ra hình dung dựa trên khái niệm về một giao diện người dùng 
Khía cạnh này ràng buộc rất nhiều với UXD, yếu tố đầu tiên của SaaS thành công. Sự khác biệt là để thành công với SaaS, UXD phải là một phần của toàn bộ vòng đời phát triển phần mềm từ ý tưởng đến sản xuất. Khi nói đến việc phác thảo cấu trúc chung, tôi luôn thấy hai sai lầm làm cho SaaS không đạt được:
- Nhóm làm việc nhảy quá nhanh sang thiết kế, và làm cho chủ đề thiết kế của ứng dụng đột nhiên trở thành một phần của quá trình phác thảo cấu trúc chung, vì các bên liên quan muốn nhìn thấy một cái gì đó trông đẹp mắt thay vì chức năng.
- Các trạng thái chính của ứng dụng đang mất dần khỏi bộ sưu tập phác thảo cấu trúc chung (có nghĩa là, chỉ phác thảo cấu trúc chung các phần của ứng dụng).
Thật thú vị, điều thứ hai của hai lý do trên hầu như bất lợi với một dự án SaaS. Điều hấp dẫn nhất về các phác thảo cấu trúc chung là bạn có thể dựa vào chúng để trưng ra các khoảng trống về nhận thức các yêu cầu sản phẩm. Người ta hiểu chúng để trưng rõ các thiếu sót thiết kế kiến trúc cốt lõi trước khi bắt đầu quá trình phát triển. Với ý nghĩ đó, không khó để tưởng tượng ra rằng việc đảm bảo cho quá trình phác thảo cấu trúc chung hoàn thành có thể tiết kiệm cho doanh nghiệp rất nhiều về thời gian và tài nguyên.
Một bộ phác thảo cấu trúc chung đã hoàn thành cũng có thể chứa hơn 100 tài liệu. Mỗi phác thảo cấu trúc chung nên được kết hợp tối thiểu với một mô tả có một hay hai trang để giúp các bên liên quan hiểu những gì họ đang thấy khi xem lại các phác thảo cấu trúc chung. Hãy nhớ rằng các phác thảo cấu trúc chung này sẽ cần phải được sửa lại trước khi các bên liên quan ngừng nói về chúng. Tốt hơn nên nhận biết các sự khác biệt trong quá trình phác thảo cấu trúc chung hơn sau khi đã mã hóa chức năng.
Lưu ý: Sau khi quá trình thiết kế diễn ra, bộ các tài liệu hoàn chỉnh, lúc này định nghĩa các giao diện người dùng, thường được gọi là sách ảnh.
5. Cung cấp SaaS với một cơ sở hạ tầng đám mây
Lúc đầu, giả thiết rằng cơ sở hạ tầng mạng có thể tạo ra hoặc phá vỡ SaaS có thể dường như là quá dễ dàng. Tuy nhiên, hầu hết các ứng dụng SaaS trên Web đang chạy trên phần cứng không đủ được gắn với một cơ sở hạ tầng không thể điều chỉnh được theo yêu cầu. Là các nhà phát triển, chúng tôi có quyền truy cập vào các hệ thống đám mây tự điều chỉnh thường được gọi là Cơ sở hạ tầng là dịch vụ (IaaS), nhưng việc chấp nhận công nghệ cao hơn này là sự chậm hiểu đáng kinh ngạc.
Sự chậm hiểu này có thể được cho chủ yếu là do thiếu kiến thức về chủ đề này. Ví dụ, Đám mây điện toán co giãn của của Amazon (Amazon EC2 -Amazon Elastic Compute Cloud) có khả năng tạo ra các khoản tiết kiệm lớn cho các doanh nghiệp đang chạy các ứng dụng SaaS, nhưng sự thiếu kiến thức chung về cơ sở hạ tầng của Các dịch vụ Web của Amazon (AWS-Amazon Web Services) làm cho nhiều doanh nghiệp quay về các hệ thống di sản bởi vì đó là những gì họ biết. Tuy nhiên, sự gia tăng liên tục về băng thông có sẵn của các ISP như là một sự đảm bảo rằng bất kỳ các ứng dụng SaaS thành công nào cũng sẽ đòi hỏi hiệu năng mạng cao cấp hơn về việc mở rộng tài nguyên tự động theo yêu cầu.
6. Tạo ra tài liệu thiết kế hoàn chỉnh trước khi bắt đầu mã hóa
Phần mềm làm việc giống như cách các doanh nghiệp làm, và một đặc điểm chính của các công ty SaaS thành công là tôn trọng đáng kể đối với giai đoạn lập kế hoạch của quá trình phát triển. Tài liệu thiết kế chất lượng cao dùng như một bản đồ đường đi cho những người chịu trách nhiệm về thực hiện thiết kế và có khả năng tăng tốc độ mã hóa phần mềm lên đáng kể. Đó là lý do tại sao các ứng dụng SaaS thành công thường là các dự án thực hiện đúng hạn và không quá ngân sách.
Khi các ứng dụng SaaS thực hiện quá hạn và chi vượt ngân sách, đó là do sự trao đổi thông tin về các nguyên lý thiết kế kiến trúc cho dự án rất kém. Để duy trì tính nhất quán mã xuyên suốt một ứng dụng SaaS lớn, điều quan trọng là thiết lập một bộ các mẫu thiết kế và các quy ước hoàn chỉnh và trao đổi thông tin có hiệu quả trong toàn bộ nhóm phát triển. Một cách tuyệt vời để trao đổi thông tin về các nguyên lý như vậy là nhờ sử dụng vỏ não thị giác.
Sử dụng vỏ não thị giác
Một số lượng đáng kinh ngạc về các nghiên cứu lâm sàng về tư duy và học tập của con người được tiến hành trong vòng 100 năm qua cho thấy rằng con người học nhanh hơn khi có nhiều hơn một trong năm giác quan được tham gia vào quá trình học tập. Sự tham gia của thị giác ngoài thính giác làm cho người học có khả năng nhớ vấn đề học gần đến bảy lần. Không có gì lạ, trong trường hợp đó, các tín hiệu hình ảnh như các biểu đồ và các đồ thị dòng công việc rất hiệu quả khi nó đi kèm với tài liệu phần mềm kỹ thuật.
Như Hình 5 cho thấy, kiến trúc phần mềm và các biểu đồ kiến trúc cực nhỏ có ích cho việc thiết lập và truyền thông một nền tảng với một ứng dụng khách RIA và cung cấp cho các nhóm phát triển một phác thảo để làm theo khi thiết lập mã. Các biểu đồ này cũng thiết lập một tập các hướng dẫn và các kỳ vọng của một quan điểm cấu trúc.
Hình 5. Khung nhìn cao cấp, vẽ phóng về các mẫu thiết kế cấu trúc của một chương trình
Các biểu đồ dòng công việc cũng đặc biệt có ích để truyền đạt một quá trình hoặc một loạt các sự kiện. Trong nhiều trường hợp, bạn có thể càng sáng tạo thì các biểu đồ dòng công việc trở nên càng hiệu quả. Hình 6 thể hiện cách thực hiện sáng tạo trong một biểu đồ dòng công việc được sử dụng để đưa ra sự mô tả trực quan về Khung công tác Swiz với Flex (Swiz Framework for Flex) nguồn mở thực hiện Phép nghịch đảo điều khiển (IoC - Inversion of Control), phép nội quan đối tượng, và phép nội xạ phụ thuộc.
Hình 6. Biểu đồ dòng công việc của Khung công tác Swiz với Flex nguồn mở
Nếu bạn đã từng hỗ trợ, đã lưu trữ thông tin, hoặc nếu không thì đã được tham gia vào việc tạo một bằng sáng chế phương pháp, thì biểu đồ trong Hình 7 trông khá quen thuộc. Nó đặc biệt có ích để hiển thị một quá trình hoặc phương pháp ở đó có nhiều khả năng. Một ví dụ hay về điều này là một quá trình liên quan đến một số các hàm, một số trong đó bao gồm một hoặc nhiều điều kiện, ví dụ như các câu lệnh if - else (nếu-khác) và switch(chuyển nhánh). Các biểu đồ mô tả chức năng vô cùng tiện dụng để phác thảo các quy trình nghiệp vụ kỹ thuật cũng như phần mềm. Ví dụ, kiểu biểu đồ này sẽ là tối ưu cho việc phác thảo quá trình cam kết mã với kho lưu trữ kiểm soát mã nguồn tập trung của công ty.
Hình 7. Biểu đồ mô tả chức năng, được sử dụng để duyệt một quá trình hoặc phương pháp có điều kiện
7. Suy ngẫm về các bài thử nghiệm đơn vị
Nói chung, những người có triển vọng thành công về SaaS luôn có các ứng dụng khá lớn do nhiều người xây dựng. Khi nói đến các ứng dụng lớn và việc thử nghiệm đơn vị, thì dữ liệu là nhất quán: Các dự án, thực hiện các bài thử nghiệm đơn vị sau, sẽ thất bại thảm hại. Với cách giải quyết trước, các nhà phát triển SaaS thành công viết các bài thử nghiệm đơn vị và thậm chí chạy chúng trước khi họ viết mã. Ví dụ, nếu tôi được giao nhiệm vụ viết một lớp có tên là ServiceController, tôi sẽ không bắt đầu bằng cách mã hóa lớp này. Thay vào đó, tôi sẽ viết lớp chạy tất cả các trường hợp thử nghiệm đơn vị dựa vào các phương thức trong lớp đó. Sau đó, thậm chí tôi tiến lên một bước nữa và chạy các trường hợp thử nghiệm, mặc dù tôi biết chúng sẽ thất bại bởi vì tôi đã chưa thực sự viết bất kỳ mã nào cho nó.
Mục đích của bài tập này là để loại trừ khả năng thực sự có lỗi trong các bài thử nghiệm đơn vị của bạn để có thể làm cho chúng luôn được thông qua. Dù là bất thường khi nó xảy ra, nhưng rất dễ dàng vô tình tạo ra lỗi này. Với điều kiện là tất cả các bài thử nghiệm đơn vị đều thất bại, tôi biết rằng mình đã sẵn sàng để bắt đầu viết mã thực tế. Khi tôi đã hoàn thành viết lớp mới này, rồi tôi sẽ chạy lại bài thử nghiệm đơn vị. Miễn là tất cả các trường hợp thử nghiệm đều vượt qua, tôi thêm lớp của bài thử nghiệm đơn vị mới vào thư viện tự động hóa thử nghiệm đơn vị của tôi, chạy trên mọi quá trình xây dựng. Nói cách khác, toàn bộ thư viện thử nghiệm đơn vị mà tôi tạo cho một ứng dụng sẽ trở thành một phần của quá trình xây dựng của tôi. Trong thực tế, ngay cả trước khi tôi bắt đầu xây dựng dự án, tất cả các bài thử nghiệm đơn vị đều được chạy để đảm bảo rằng tính toàn vẹn của mã ứng dụng đã không vô tình bị xâm phạm.
Trong thế giới lập trình, tôi chỉ thấy một vài nhà phát triển thường xuyên áp dụng quá trình này. Tuy nhiên, họ là một trong số những cá nhân được tôn trọng, có uy tín, và được trả lương cao trong ngành công nghiệp. Nếu bạn đang tìm kiếm một con đường tăng lương hoặc thăng tiến nhanh chóng, hãy suy ngẫm bài thử nghiệm đơn vị.
8. Giải quyết các việc lớn, chứ không phải các việc bé
Khả năng thắt cổ chai hiệu năng với các ứng dụng SaaS lớn hơn nhiều so với các ứng dụng khách "nặng" chạy từ máy tính để bàn. Ngay cả những lập trình viên kỳ cựu cũng sẽ thừa nhận rằng khi nói đến các ứng dụng SaaS, đôi khi rất khó dự đoán được các thắt cổ chai hiệu năng do có quá nhiều các thay đổi có liên quan. Sự khác biệt giữa các ứng dụng SaaS thành công và các ứng dụng SaaS thất bại là cách mà nhóm phát triển đáp ứng với số lần truy cập hiệu năng bất lợi trong quá trình thử nghiệm và lược tả tải.
Nói chung, chỉ có hai kiểu tối ưu hóa hiệu năng: các kiểu thực hiện một tác động đáng kể đến hiệu năng và các kiểu dường như không có bất kỳ kết quả đáng chú ý nào. Hiếm khi có bất cứ điều gì ở giữa. Một ẩn dụ thường được sử dụng trong lĩnh vực này là các việc lớn và các việc bé. Thường thường, các nhà phát triển dành phần lớn thời gian được phân bổ để nâng cao hiệu năng, giải quyết các việc bé còn hơn là giải quyết các vấn đề to lớn vượt quá khả năng hoạt động của bộ vi xử lý hoặc bộ nhớ của máy tính trong khi các ứng dụng đang chạy. Điều quan trọng cần loại bỏ ở đây là, với tư cách là một lập trình viên, bạn không thể thấy việc lớn khi bạn quá bận rộn nhìn vào các việc nhỏ.
Cách dễ nhất để tránh bị phân tâm bởi các việc nhỏ là lược tả các ứng dụng của bạn. Việc lược tả là một phần quan trọng của dự án SaaS thành công bởi vì nó mang lại cho bạn cơ hội để tối ưu hóa cách ứng dụng của bạn sử dụng tài nguyên hệ thống, như thể hiện trong Hình 8. Khi bạn lược tả một ứng dụng, bạn có thể thấy chính xác các đoạn ứng dụng nào đang chiếm nhiều tài nguyên nhất và thực hiện các mẫu thiết kế cho hiệu năng tăng lên. Ví dụ, bạn có thể thấy việc thực hiện phân nhóm đối tượng với các ủy quyền (proxy) là cần thiết nếu bạn tìm thấy nhiều bản cài đặt lại đối tượng mà không có việc thu gom rác thải cần thiết, do việc thu gom rác liên tục chiếm dụng bộ nhớ nhiều hơn miễn là bạn phải rời khỏi ứng dụng đang chạy.
Hình 8. Lược tả ứng dụng trong Eclipse
9. Tìm hiểu từ các dự án SaaS thành công khác
Cách đơn giản nhất học được từ các dự án SaaS thành công khác là bắt đầu bằng cách chọn một chương trình SaaS mà bạn đã sử dụng. Sau đó, tìm ra hai hoặc ba đối thủ cạnh tranh về phần mềm mà bạn đã chọn và đưa chúng ra thử, viết ra những điều cụ thể thu hút được sự chú ý của bạn và liên quan đến lý do bạn thích hoặc không thích những ứng dụng tương ứng.
Thật hiếm có được một ứng dụng có thể thu hút sự chú ý của tôi về khả năng dễ sử dụng và hiệu năng, vì thế khi nó xảy ra, tôi đảm bảo cần có thời gian để tìm hiểu lý do vì sao tôi thường tìm hiểu điều gì từ nó. Một ứng dụng quản lý nhiệm vụ đã thu hút sự chú ý của tôi gần đây, chủ yếu là do tôi tìm thấy thể loại các ứng dụng này chứ không phải vì không hiểu rõ. Tuy nhiên, mức độ dễ sử dụng có liên quan đến ứng dụng SaaS cụ thể này đã rất ấn tượng.
Tôi đã dành khoảng hai giờ để chuyển hướng ứng dụng này, thử nghiệm các hạn chế của nó và đánh giá khả năng tiếp cận của vô số tính năng của nó. Tôi thích các ứng dụng có một số lượng các tính năng được dựng sẵn khác thường, nhưng tôi hy vọng chúng vẫn còn khá nhẹ. Vì lý do này, tôi nhận xét về thiết kế giao diện người dùng. Nếu giao diện này không được thiết lập tốt, thì một ứng dụng có nhiều tính năng sẽ trở thành một tình huống sử dụng đáng sợ, bởi vì không thể tìm thấy những thứ bạn đang chờ mất nửa thời gian. Đánh giá của tôi về ứng dụng SaaS cụ thể này đưa tôi đến kết luận rằng ứng dụng này có tổ chức giao diện người dùng độc nhất và không theo quy tắc khi so sánh với các ứng dụng quản lý nhiệm vụ khác mà tôi đã cài đặt, cho phép tôi thích làm việc với nó.
10. Xây dựng các nguyên mẫu có thể sử dụng
Một nguyên mẫu có còn là một nguyên mẫu không nếu một mã tương tự được sử dụng để xây dựng nó cũng được sử dụng để tạo ra sản phẩm cuối cùng?
Câu trả lời cho câu hỏi này là đúng như vậy. Trong việc phát triển phần mềm, khách hàng thường muốn nhìn thấy bằng chứng về khái niệm trước khi đầu tư vào việc phát triển thực tế. Một nguyên mẫu không có gì hơn một bằng chứng về khái niệm. Các nhà phát triển SaaS thông minh tận dụng thời gian mà họ được cung cấp để tạo các nguyên mẫu. Hãy xem xét có thể làm xong bao nhiêu nguyên mẫu trong thời gian này:
- Thiết kế và bố trí nền tảng kiến trúc.
- Tạo lược đồ cơ sở dữ liệu SaaS bằng cách xây dựng một XML DTD tùy chỉnh, và sử dụng XML làm nguồn dữ liệu của nguyên mẫu. (Lược đồ có thể được nhập khẩu sau vào máy cơ sở dữ liệu và được chuyển đổi thành lược đồ thực tế trong một vài phút).
- Tạo gói cấu tạo của ứng dụng đủ kích thước, giao diện, cấu trúc lớp, thậm chí nếu các tệp không hơn gì nhiều so với khai báo tên lớp và giao diện thì thực hiện từ đầu.
Có một số lợi thế với cách tiếp cận này, nhưng có hai lợi thế là chìa khóa giúp SaaS thành công: Bạn có một khởi đầu sớm vào đúng thời điểm để xây dựng sản phẩm thực tế, và các mẫu thiết kế đối lập và các kiến trúc được thiết kế kém sẽ luôn hiển thị các khuôn mặt xấu xí của chúng khi nguyên mẫu được xây dựng trên đỉnh của chúng. Sau đó có thể thực hiện các thay đổi cần thiết trước khi việc phát triển sản phẩm thực tế bắt đầu.
Kết luận
Điều quan trọng là nhận ra rằng thế giới phát triển phần mềm tiến triển nhanh đến mức các yếu tố chính cho sự phát triển SaaS thành công cuối cùng sẽ thay đổi — có thể sớm còn hơn là muộn. Bí quyết là đẩy nhanh tốc độ quá trình tiến hóa và vị trí của chính bạn để vượt qua khúc rẽ ấy.
Tài nguyên
Học tập
Lấy sản phẩm và công nghệ