6 giờ và 6 tháng: Làm thế nào để lập trình app nhanh hơn?

84

So với web thì việc xác định thời gian mobile apps được đưa ra thị trường dường như khó khăn hơn. Vấn đề chính là dành 6 tháng hoặc nhiều hơn nữa để xây dựng app v1.0 là quá dài và quá tốn thời gian, đặc biệt là khi bạn muốn đạt mục tiêu về lợi nhuận/ thị trường. Andrew Chen đã viết về những vấn đề của anh trong khoảng thời gian 6 tháng lập trình vào năm 2012 và David Smith – 1 nhân viên cũ của SavvyApps gần đây đã chứng minh được cách để app ra mắt trong 6 tiếng.

Tất nhiên, những apps mà chúng ta được công ty thuê không thể hoàn thành trong 6 tiếng nhưng tại Savvy Apps, chúng tôi vẫn luôn tiếp cách để lập trình apps nhanh hơn vì chính những mối quan ngại tương tự như những mối quan ngại của Andrew. Ví dụ, gần đây chúng tôi đã ra mắt 1 podcasting app cho Cato Institute trong 3 tháng. Phiên bản gốc của Agenda hoàn thành trong khoảng 1 tháng. Thậm chí 1 số app phức tạp hơn còn tốn thời gian chưa tới 6 tháng. Bài viết sau sẽ chia sẻ những kinh nghiệm để bạn thực hiện được điều này 🙂

Nổi giận với thời gian ra mắt app

Hãy ghi nhớ ngày mà bạn tung app lên app store. Thường xuyên trao đổi với các thành viên để nhắc nhở nhau không được bỏ lỡ ngày này trong bất kì tình huống nào. Sau đó, bạn chỉ cần tính ngược thời gian lại và bắt đầu làm việc.

Nếu bạn và team của bạn có thể hiểu được tầm quan trọng của ngày này, bạn sẽ trở nên siêng năng hơn trong việc thấu hiểu nỗ lực đã bỏ ra để hoàn thành nhiệm vụ. Mọi người có quyền lên tiếng về các tính năng có thể ảnh hưởng đến thời gian hoặc khi chuyển sang 1 phiên bản cập nhật trong tương lai.

IDE Academy Contact Friends
IDE Academy Contact Friends

Sử dụng các wireframes để giảm các vòng đời phát triển

Thay đổi 1 mockup luôn tốn ít chi phí hơn và nhanh hơn việc viết lại code. Đó là lý do tại sao chúng ta bắt đầu quy trình với wireframes có độ chính xác thấp và lặp lại chúng 1 cách rộng rãi trước khi viết bất kì dòng code UI quan trọng nào. Không thiếu các công cụ mà dev có thể sử dụng nhưng chúng tôi vẫn thường dùng Balsamiq Mockups để hỗ trợ các wireframes có độ chính xác thấp.

Tuy hơi bất thường nhưng cách thức này sẽ giảm thời gian lập trình app. Bằng cách tiếp nhận nhiều phản hồi, bạn sẽ hạn chế được trường hợp phải viết lại hàm hoặc tính năng sau đó. Dành ra 1 ít thời để hoạch định trải nghiệm người dùng chắc chắn sẽ giúp mỗi giờ phút lập trình hiệu quả hơn.

Bắt đầu với 1 platform duy nhất và form factor (hệ số định dạng)

Như tôi đã đề cập, lập trình iOS apps sẽ nhanh hơn và bắt đầu với 1 form factor duy nhất cũng nhanh hơn, đặc biệt là iPhone.

Một lý do khác để bắt đầu với 1 platform duy nhất và form factor liên quan đến các phản hồi, góp ý và quá trình học hỏi. Bất kì app mới nào cũng phải trải qua những thay đổi lớn. Wireframes sẽ giảm bớt nhưng nhiều khả năng không loại bỏ được nhu cầu tạo nên những thay đổi ở mức độ code. Tương tự như những phản hồi góp ý trong giai đoạn beta testing, hãy cố gắng áp dụng chúng ở nhiều nền tảng và form factors sẽ tăng thời gian lập trình theo cấp số nhân.

Tính trước các ước lượng sai

Ước lượng. Chúng ta thích chúng. Chúng ta ghét chúng. Hầu hết chúng ta đều ghét chúng. Nhưng chúng ta cầ chúng. Sẽ không có timeline nào cả nếu không có các dự đoán và đây là điều mà bạn có lẽ chưa từng nghĩ đến: users không quan tâm đến việc nó tốn thời gian bao lâu. Họ chỉ cần app làm đúng những gì nó phải làm mà không khiến họ phải bận tâm nhiều.

Tương tự, khi bạn đang tiến hành giai đoạn beta và 1 chủ đề chung từ các testers là họ vẫn không biết làm thế nào để sử dụng “tính năng X, bạn có thể tốn thêm 20-30% cho ngày ra mắt. Đây có thể không phỉa là vấn đề, trừ trường hợp bạn xây dựng 5 tính năng khác trong v1.0 và bạn vẫn chưa bắt đầu những tính năng khó nhất.

IDE Academy Chat
IDE Academy Chat

Câu trả lời cho vấn đề này là không nhồi nhét quá nhiều các dự đoán vào timeline. Thay vào đó bạn cần biết rằng các ước đoán sẽ bị sai. Sau đó, cắt giảm các tính năng được hoạch định ngay từ đầu dành cho phiên bản ra mắt đầu tiên, song song với việc giữ lại ngày ra mắt v1.0. Phương pháp này cho phép bạn trau dồi và cải thiện những điểm làm nên sự khác biệt chính của app. Thẳng tay loại bỏ các tính năng trước khi lập trình sẽ giảm đi rất nhiều vòng đời lập trình, đặc biệt là đối với tính năng khó ra mắt ở phiên bản v1.0

Giải quyết các thách thức lập trình sớm hơn

Nhận diện những phần khó nhất trong 1 app, nghiên cứu sâu và sau đó giải quyết chúng nhanh chóng. Có vài lý do chính đáng đằng sau việc tạo bước đà và củng cố nền tảng của 1 codebase. Ngược lại, có rất ít lý do hợp lý để tiếp tục trì hoãn các nhiệm vụ vì chúng sẽ ngày càng trở nên khó khăn hơn hoặc thách thức hơn. Cố gắng giải quyết chúng có thể khiến bạn lỡ ngày ra mắt app nhưng chắc chắn sẽ ra đời 1 app điên rồ hơn, khó tin hơn.

Ở đây, vai trò của các product managers trở nên quan trọng hơn. Nếu họ thường xuyên tương tác với các thành viên trong team lập trình và thường có những ước đoán cho tất cả các nhiệm vụ lập trình, thì họ nên ưu tiên 1 vài loại tính năng trong quy trình để giảm thiểu các phần apps có nguy cơ cao.

Sử dụng 1 đơn vị cung cấp Backend-as-a-Service

Hãy để ý đến các công cụ như Parse, Firebase, CloudKit, hoặc Kinvey. Rất nhiều khách hàng của chúng ta đang chạy trên 2 công cụ đầu tiên. Những đơn vị cung cấp Backend-as-a-Service providers (BaaS) sẽ giảm chi phí lập trình backend và chạy các servers. Chúng sẽ tự động scale khi app phát triển dần lên, hỗ trợ các login từ mạng xã hội, từ đó có được các tài khoản người dùng, hỗ trợ tin nhắn đẩy và cung cấp dashboard phân tích dữ liệu mạnh mẽ (tùy thuộc vào đơn vị cung cấp).

handoff-featured

Nhờ có các đơn vị cung cấp này, bạn có thể tập trung vào việc tạo khác biệt cho app. Ví dụ, viết push server riêng của bạn sẽ không thực hiện được điều đó. Nếu bạn đang nhắm tới sở hữu 10 triệu hoặc hàng trăm triệu users thì bạn nhất định phải có đủ ngân sách hoặc tìm kiếm đủ vốn, sau đó đầu từ vào cơ sở hạ tầng riêng rồi chuyển dữ liệu vào cơ sở đó.

Nguồn: ADG Vietnam via SavvyApps