Getting Real

Copyright by 37Signals
The smarter, faster, easier way to build a successful web application

Tôi chọn quyển sách này là quyển đầu tiên để viết review bởi đối với tôi, nó quan trọng, nó (quyển sách) góp phần làm thay đổi tư duy, cách tiếp cận với việc viết phần mềm, và với sự nghiệp của tôi.

Getting Real là tên gọi của cuốn sách, với ý nghĩa đơn giản: hiện thực hóa sản phẩm phần mềm, ở đây là Web application. Riêng với tên gọi thôi đã thấy rằng những người viết ra quyển sách này rất hiểu tâm trạng của các lập trình viên, những người làm production.

Getting Real được viết bởi 37Signals. Đây là công ty đã “phát minh” ra Ruby on Rails từ ngôn ngữ lập trình Ruby đã có từ lâu, mở ra 1 mô hình phát triển sản phẩm mới, và từ 2006 đến nay rất “hot” ở Mỹ. Kèm theo đó là những cái niệm ORM (Object Relation Mapping) như Active Record. Đi kèm với 37Signals (viết liền nhé 😀 ) là các sản phẩm rất nổi tiếng và có hàng ngàn công ty trên thế giới sử dụng như BaseCamp (phần mềm quản lý dự án), HighRise (quản lý contact).v.v… Bên cạnh đó, 37Signals cũng là hình mẫu điển hình cho việc kinh doanh phần mềm theo mô hình SaaS (Software as a Service) và cloud computing ngày nay. Ngoài ra, Getting Real cũng là điển hình cho Agile development cũng như Lean UX, Lean start-up.

Nói về công ty và nhóm tác giả vậy đủ rồi, giờ thì quay lại với cuốn sách này. Cuốn sách chỉ khoảng 180 trang và được viết ngắn gọn, với lối kể chuyện mạch lạc, đi từ thiết kế sản phẩm, cho tới hỗ trợ, tương tác với người dùng giúp cho độc giả dễ dàng nắm bắt và hiểu thông tin mà sách truyền đạt. Sách có 16 chương nhưng lại chia nhỏ thành 171 topics (chủ đề), xuyên suốt đó là qui trình build sản phẩm (web app), test sản phẩm, support người dùng, promote sản phẩm, lập trình, thiết kế giao diện, qui trình làm việc, lựa chọn tính năng và điều chỉnh.

Có lẽ khi viết ra cuốn sách này, sau khi đã thành công với các sản phẩm SaaS (nêu trên), 37Signals muốn kể lại câu truyện thành công của họ, cách họ áp dụng Lean, Agile /Scrum như thế nào, làm việc nhóm ra sao để qua đó 1 công ty với số lượng nhân viên dưới 20 người (vào thời điểm ra mắt cuốn sách) đã mang lại doanh số ~400 triệu USD (nghĩa là kiếm hơn 1 triệu USD/ ngày). Và với mong muốn tạo ra sự thay đổi trong giới làm phần mềm web app, họ miễn phí quyển sách này. (bạn có thể download free tại đây).

Về quan điểm cá nhân, đối với nội dung cuốn sách, tôi thích và thực sự học được những thứ hay ho như sau:

• Be willing to say no to your customers. Điều này có nghĩa là không đáp ứng ngay lập tức các yêu cầu sửa đổi đến từ người dùng / khách hàng. Tại sao? bởi những yêu cầu này không phải lúc nào cũng đúng. Ví dụ như người dùng yêu cầu Text Editor phải cho phép điều chỉnh format của font chữ, màu chữ… với mục đích gây chú ý. Nhưng giải pháp đôi khi rất đơn giản như VIẾT HOA TOÀN BỘ THẾ NÀY hoặc thêm các ký tự đặc biệt gây chú ý dưới dạng: @@@@@ Thế này có gây chú ý chưa ku? <==== ###
• Done is done, và Build Less. Khái niệm này thuần túy của Lean, ai làm qua cũng hiểu rồi :). Phần mềm ban đầu cứ xây dựng những tính năng cơ bản, giải quyết v.đề lớn nhất cho người dùng, những thứ khác có thể bổ sung theo thời gian. Khi lượng người dùng yêu cầu 1 tính năng nhiều lần và nhiều người claim về nó, đó là lúc bạn cần bổ sung tính năng đó.
• Alone Time, Meetings Are Toxic. Quan điểm này thực sự rất cần thiết cho các công ty phần mềm. Việc họp hành quá nhiều gây mất tập trung và thời gian (cũng là tiền) của các cấp nhân viên. Alone time ở đây theo 37Signals là 1 tuần dành ra 1 ngày (ví dụ như thứ 4 hàng tuần) cho phép mỗi nhân viên của họ được Alone, nghĩa là không bị làm phiền bởi bất cứ điều gì, họ tự làm cái họ cần. Điều này có lẽ nhiều người đã trải nghiệm, ví dụ như đi làm sáng thứ 7 hoặc Chủ nhật thường làm được nhiều việc nhất, có khi giải quyết công việc bằng khối lượng cả tuần.
• Interface first, và Three State Solution. Luôn thiết kế giao diện xong xuôi, hiểu các flow tương tác giữa người dùng và ứng dụng (human interaction) rồi mới lập trình. Bên cạnh đó, một bản vẽ giao diện (UI) cần thể hiện được 03 giai đoạn: regular (lúc hiển thị dữ liệu bình thường), blank (lúc không có dữ liệu) và error (khi xảy ra lỗi). 37Signals đặc biệt chú trọng blank slate, bởi các nhân viên graphic design thường đưa ra bản vẽ có đầy đủ dữ liệu giả lập, nhưng với người dùng, khi vừa đăng ký 1 blog mới, 1 album ảnh mới… tất cả là empty vì chưa có dữ liệu. Bỏ qua giao diện blank slate là 1 lỗi lớn thường gặp, và rất dễ gây confuse với người dùng.
• Open doors for Code. Phần này ngày nay được các công ty áp dụng triệt để. Nghĩa là 1 sản phẩm làm ra cần tương tác với các sản phẩm khác, cho phép các bên thứ ba (không phải người dùng) tham gia phát triển. 1 sản phẩm cần có API, Coding guidelines, RSS, XML data export, v.v…
• Manage debt. Trong nhiều tài liệu phát triển phần mềm, người ta còn gọi đây là technical debt. Cái này bạn nào làm lập trình viên rồi thì hiểu ngay 😀 hihi. Lúc coding, thiết kế kiến trúc, có rất nhiều người chọn giải pháp “tạm bợ”, hoặc “làm tạm cho chạy đã, rồi tối ưu hóa sau”… tất cả những điều này (kể cả Tây Tàu gì cũng mắc phải) chính là món nợ của bạn sau này. Đến khi sản phẩm running rồi, go live và tệ hơn là có người dùng rồi, lúc đó mới chỉnh sửa lại architect, sửa lại code thì “cost” cho “debt” của bạn sẽ tốn hơn nhiều lần. Nói nôm na là debt thì có interest rate theo thời gian là đúng thôi keke.
• Sau cùng, Feel the pain, Zero training và Better, not Beta. 2 khái niệm đầu tiên là mô tả quá trình hỗ trợ khách hàng (user support). Feel the pain, nghĩa là bạn cần support trực tiếp người dùng, đừng thuê các công ty call center 1 cách máy móc. Hãy hỗ trợ người dùng và hiểu cái khó khăn, bực dọc, thậm chí là khổ sở của họ khi dùng sản phẩm của bạn. Zero training, nghĩa là hãy thiết kế ứng dụng cũng như giao diện sao cho đơn giản, (less is more) dễ dùng và user có thể thao tác được ngay mà không cần đọc bản user manual. Và cuối cùng, khi ra mắt sản phẩm (web app, mobile app), hãy chắc chắn rằng nó chạy tốt, được test cẩn thận và đừng có khái niệm Beta trong đầu. Bởi Beta, theo 37Signals thì chẳng khác gì bạn tuyên bố: bọn em chạy thử thôi nhé, còn lỗi đấy, đừng kêu ca gì 😀

Còn rất nhiều điểm thú vị ở cuốn sách này, 6-7 năm sau ngày phát hành (tính đến thời điểm hiện tại là năm 2013), những bài học này vẫn còn rất mới và hữu dụng. Hàng ngày, các start-up, các công ty phần mềm, lập trình viên hay UX designer vẫn mắc phải các lỗi nêu trên. Cá nhân tôi, highly recommend anh em nào muốn thực sự làm product, lean start-up thì nên đọc quyển này 😛

Đây là 1 quyển sách đáng đọc, và đáng để đọc đi đọc lại nhiều lần với những ai làm start-up, software engineer, và đặc biệt là những người làm UX, Lean and Agile.