Tư duy của nhà phát triển trong các dự án tăng trưởng

Việc nắm vững nhiều công nghệ và biết cách xây dựng các dịch vụ phức tạp, có tải trọng cao hóa ra là chưa đủ khi bạn là nhà phát triển trong một dự án khởi nghiệp hoặc đang phát triển. Trong sự nghiệp của mình, tôi đã tham gia vào nhiều dự án đang phát triển và tạo ra hai công ty khởi nghiệp từ đầu. Trong bài viết này, tôi sẽ chia sẻ kinh nghiệm của mình về những gì cần tập trung vào trong quá trình phát triển và tại sao chủ nghĩa cầu toàn lại làm hỏng ngay cả những ý tưởng tốt nhất.

Công cụ là phương tiện, không phải mục đích

Đối với mọi nhà phát triển, việc khởi động một dự án một mình đã là một thách thức lớn. Điều rất tự nhiên là bạn cảm thấy rằng mình cần phải làm mọi việc một cách hoàn hảo. Tôi phải mất một thời gian mới nhận ra rằng mong muốn theo chủ nghĩa hoàn hảo thường phản ánh nỗi sợ hãi rằng đồng nghiệp sẽ đánh giá tôi vì có thêm 'bản in' hoặc không sử dụng khuôn mẫu hoặc công cụ; và thế là: máy chủ sản xuất sẽ sụp đổ, khách hàng sẽ phàn nàn, tôi sẽ bị sa thải và thế giới sẽ đi đến hồi kết.

Bất kỳ công cụ, mẫu hoặc ngôn ngữ lập trình nào cũng chỉ là công cụ , không phải mục tiêu. Câu hỏi thường xuyên hơn: Tại sao tôi cần điều này ngay bây giờ? Nó sẽ cung cấp những gì? Những số liệu nào nó sẽ cải thiện? Ví dụ: tại sao bây giờ lại cấu hình một kẻ nói dối? Tại sao phải tùy chỉnh CI/CD ngay bây giờ? Nếu bạn đang triển khai 10 lần một ngày, bạn có thể cần nó. Nếu bạn triển khai một bản phát hành mỗi tuần hoặc một tháng một lần thì rất có thể bạn sẽ không triển khai. Nếu việc tùy chỉnh CI/CD sẽ tốn nhiều thời gian nhưng không tăng tốc độ phát triển hoặc mang lại giá trị cho dự án và khách hàng thì có nên triển khai ngay bây giờ không?

Trong một dự án thú cưng, việc thử một cái gì đó mới là điều hợp lý: cải tiến không ngừng cấu trúc của kho lưu trữ và mã, thử nghiệm các mẫu, v.v. Trong trường hợp này, các công cụ chúng tôi triển khai là mục tiêu . Mục tiêu chính của một dự án sản xuất là mang lại giá trị cho khách hàng. Khách hàng sẽ không bao giờ biết rằng chúng tôi sử dụng dấu ngoặc kép thay vì dấu ngoặc đơn và dấu ngoặc đơn và không có mã cứng.

Việc tái cấu trúc chỉ cần thiết khi nó sẽ tăng tốc độ và hiệu suất phát triển, giảm lỗi hoặc bỏ chặn các tồn đọng.

Cam kết về chất lượng nên theo đuổi mục tiêu của sản phẩm chứ không phải mong muốn theo chủ nghĩa hoàn hảo của bạn. Vì vậy, điều quan trọng cần nhớ là: nhà phát triển trong một dự án đang phát triển không bao giờ là người cầu toàn.

Giá trị doanh nghiệp được ưu tiên hàng đầu

Đối với một nhà phát triển trong một dự án đang phát triển, điều cần thiết là phải hiểu giá trị kinh doanh. Khi bạn đã quen với việc là một nhà phát triển thường xuyên chỉ viết mã theo các thông số kỹ thuật có sẵn, thì ban đầu việc này có thể gặp khó khăn.

Khi sản phẩm vừa ra đời, giá trị mang lại cho người dùng chưa được chứng minh, nhưng giá trị cần chứng minh đã tồn tại trong tâm trí các bên liên quan. Ở giai đoạn này, bạn có thể mắc sai lầm khi làm quá tải cơ sở mã bằng logic không cần thiết. Ví dụ, bạn cần viết một trình xử lý đơn hàng. Bạn tạo một bảng với các đơn hàng trong cơ sở dữ liệu và một bảng thứ hai với các loại đơn hàng, mặc dù chỉ có một loại.

Giả sử bạn làm điều này vì các bên liên quan khẳng định rằng một ngày nào đó logic này có thể cần thiết. Trong thực tế, nó có thể không bao giờ cần thiết. Đừng sinh ra những thực thể không cần thiết nếu hiện tại chúng không có giá trị gì và quan trọng hơn là đừng lãng phí thời gian và tiền bạc kinh doanh vào việc đó.

Một câu hỏi hợp lý có thể được đặt ra: "Tôi có định tranh luận với các bên liên quan không?" Vâng, đôi khi bạn sẽ làm được. Các bên liên quan mong đợi phân tích chi tiết. Đặc điểm cụ thể của các dự án đang phát triển thường là thiếu nguồn lực, vì vậy các nhà phát triển phải có kỹ năng phân tích. Bạn cần liên tục xác nhận giá trị của các tính năng của sản phẩm, vì khả năng tồn tại của nó thực sự phụ thuộc vào nó.

Nếu bạn dàn trải mỏng, doanh nghiệp sẽ cạn kiệt tài nguyên và bạn sẽ phải lưu trữ kho lưu trữ.

Đặt nhiều câu hỏi: "Tại sao phải triển khai tính năng này ngay bây giờ? Chúng ta có nên giải quyết vấn đề này ngay bây giờ không? Vấn đề này có tồn tại không?" Nó hoàn toàn giống như mô tả ở trên với công nghệ. Việc có thể đặt những câu hỏi phù hợp sẽ thể hiện tính chuyên nghiệp của bạn. Bạn chỉ cần dành thời gian và nguồn lực kinh doanh của mình cho những thứ thực sự mang lại giá trị cho khách hàng.

Hackathons là một ví dụ tuyệt vời cho thấy sự hiểu biết về giá trị doanh nghiệp ảnh hưởng đến kết quả như thế nào. Trong một thời gian giới hạn, phải đưa ra một giải pháp không lý tưởng nhưng khả thi cho một vấn đề được xác định rõ ràng. Khi các nhà phát triển lấy cảm hứng từ dự án và hiểu rõ ràng lý do tại sao họ làm điều đó, kết quả sẽ xuất hiện tốt đẹp ngay cả sau 2 ngày.

Kế hoạch phụ thuộc vào rủi ro

Hãy tưởng tượng một trò chơi chiến lược: bạn có một người thợ rừng và một người tuyển dụng. Mục tiêu là tạo ra một chiến binh. Đầu tiên, người thợ rừng phải thu thập gỗ và xây dựng doanh trại, nơi người tuyển mộ có thể học huấn luyện quân sự. Để khai thác gỗ, người thợ rừng cần đến khu rừng thông qua một phần chưa được khám phá trên bản đồ. Đánh giá từ bản đồ, có thể đến khu rừng trong một ngày thi đấu, việc đốn củi sẽ mất khoảng nửa ngày và việc xây dựng doanh trại sẽ mất một tuần. Vì vậy, doanh trại sẽ xuất hiện trong khoảng mười ngày nữa.

Người tiều phu mất gần một ngày mới vào được rừng nhưng bỗng nhiên bị dòng sông chặn đường. Mục tiêu thay đổi: chúng ta phải xây một con đập, một cây cầu hoặc một chiếc thuyền để sang bờ bên kia, hoặc có thể tốt hơn là tìm kiếm những khu rừng ở nơi khác. Đánh giá sớm dẫn đến thất bại trong chiến lược. Nếu người trinh sát khám phá phần chưa được khám phá của bản đồ trước thì rủi ro này có thể tránh được.

Nhà phát triển có kinh nghiệm nhận ra những rủi ro không rõ ràng đối với các bên liên quan: tích hợp với các dịch vụ của bên thứ ba, sự phức tạp của việc mở rộng cơ sở mã, v.v. Bạn có trách nhiệm đánh giá rủi ro và cảnh báo về chúng. Thông thường, các bên liên quan không nhận thức được những rủi ro này nhưng chúng ảnh hưởng đến việc đánh giá, điều này rất quan trọng đối với họ.

Một nhiệm vụ ví dụ: tích hợp dịch vụ của bạn với dịch vụ thanh toán. Trước hết, hãy thiết lập dịch vụ thanh toán, có quyền truy cập và điều tra xem mọi thứ có thể xảy ra sai sót ở đâu. Trước khi tích hợp, hãy hiểu cách tích hợp. Sẽ tốt hơn nếu dành một ngày để nghiên cứu hơn là sau hai hoặc ba tuần phát triển rằng tính năng này không thể hoàn thành đúng thời hạn hoặc quá trình tích hợp không thành công do dịch vụ thanh toán đã thay đổi điều khoản hoặc vô hiệu hóa hỗ trợ cho tính năng cần thiết .

Sau khi tìm ra các rủi ro, bạn cần lập kế hoạch công việc và đưa ra ước tính thời gian cho nhiệm vụ. Đây là khuôn khổ tôi sử dụng:

• Viết kịch bản hoặc trực quan hóa chúng trên bảng: ví dụ: người dùng nhấp vào nút và tài liệu sẽ được tải xuống. Chọn cách tiếp cận mà bạn hiểu.

• Phân tích cách hoạt động của tập lệnh từ quan điểm kỹ thuật hơn. Càng nhiều lựa chọn thì càng tốt. Tôi đánh giá các phương án và chọn giải pháp có khả năng mở rộng với rủi ro được giảm thiểu để giải quyết vấn đề nhanh nhất.

• Chia các kịch bản thành các phần logic cần được mã hóa.

• Ước tính từng phần theo ngày, sau đó nhân với hệ số 1,11. Đây là hệ số ma thuật của cá nhân tôi, tức là sinh nhật của tôi vào ngày 11 tháng 10. Tất nhiên, đây chỉ là một trò đùa (hoặc không). Lời khuyên của tôi là hãy cộng thêm vài ngày hoặc thậm chí vài tuần vào quá trình ước tính, tùy thuộc vào phạm vi dự án. Mặc dù chúng ta cố gắng thấy trước càng nhiều rủi ro càng tốt nhưng có một số rủi ro không thể lường trước được. Tốt nhất là hoàn thành công việc sớm hơn là không thành công.

  
  

  Đừng ngại đưa ra ước tính lớn hơn: khi một bên liên quan hỏi, "Bạn không thể làm điều đó nhanh hơn được sao?" đừng chỉ trả lời "Không", mà hãy giải thích lý do tại sao. Kể về những rủi ro, trình bày các tình huống và đưa ra ví dụ. Các bên liên quan cần hiểu rằng bạn đã phân tích vấn đề chứ không chỉ đánh giá nó một cách ngẫu nhiên.

Khía cạnh quan trọng: trạng thái tinh thần của bạn cũng là một rủi ro. Lên kế hoạch cho kỳ nghỉ của bạn và theo dõi sức khỏe tinh thần của bạn để luôn có động lực và không bị kiệt sức: đó là trách nhiệm của bạn.

MVP không phải là tàu vũ trụ

Câu hỏi "Làm thế nào để tạo MVP?" đã làm phiền tôi trong suốt sự nghiệp của tôi. Nghe có vẻ đơn giản - Sản phẩm khả thi tối thiểu.

định nghĩa Wikipedia:

Sản phẩm khả thi tối thiểu (MVP) là phiên bản của sản phẩm có đủ tính năng để những khách hàng đầu tiên có thể sử dụng được, những người sau đó có thể cung cấp phản hồi để phát triển sản phẩm trong tương lai.

Tôi thường quan sát thấy rằng khi bạn cần xây dựng một MVP, đôi khi việc đó giống như việc chế tạo một con tàu vũ trụ tốn một lượng thời gian lớn đến mức nực cười. Mục tiêu chính ở giai đoạn MVP là nhận được phản hồi nhanh chóng từ khách hàng và dựa trên phản hồi này, thống nhất với các bên liên quan về việc chúng ta 'đi thẳng' hay 'rẽ phải'. Cách tốt nhất để thu thập phản hồi là số liệu. Thật tuyệt nếu họ thành công mà không có họ, nhưng nếu không, ít nhất bạn cũng biết tại sao.

Tôi sẽ kể cho bạn nghe về MVP đầu tiên của tôi. Tôi đã tìm thấy nhiều công cụ và khung: UML, Mẫu thiết kế, Lộ trình, Điểm câu chuyện, Đặc tả yêu cầu hệ thống, ADR, kiểm tra giao diện người dùng, v.v. Tôi quyết định sử dụng tất cả những thứ này vì những khuôn khổ này được sử dụng trong các công ty lớn và tôi đã nghe nói về chúng tại các hội nghị, bài giảng và YouTube.

Mục đích của dịch vụ là lưu trữ dữ liệu về các lần chạy thử nghiệm. Tôi đã lập lộ trình trong một năm, vẽ kiến trúc chi tiết trong UML , dành nhiều thời gian để chọn khung cho phần phụ trợ, thiết lập hệ thống kiểm tra và ghi nhật ký vào Sentry, đồng thời tính toán tải cho nhiều người dùng thay vì 10 người dùng như mong đợi. -15. Tôi muốn thực hiện dự án hoàn hảo.

Phiên bản đầu tiên mất 6 tháng để hoàn thành. Bạn có thể xem tất cả các lần khởi chạy, biểu đồ và báo cáo tải xuống, nhưng đã xảy ra sự cố với việc thu thập dữ liệu. Hai ba lần một tuần lại xuất hiện một báo cáo hỏng khiến dịch vụ không thể sử dụng được nhưng tôi vẫn ngoan cố làm theo kế hoạch.

Trong vài năm tiếp theo, tôi có nhiều dự án khác nhau và cố gắng khởi động công ty khởi nghiệp của mình. Tôi đã học về tiếp thị, bán hàng và nỗi đau của khách hàng. Trải nghiệm này đã thay đổi suy nghĩ của tôi và cho phép tôi phát triển các phương pháp tiếp cận mà tôi chia sẻ trong bài viết này. Tôi sẽ mô tả một nhiệm vụ gần đây để chứng minh chúng hoạt động thực tế như thế nào.

Tôi cần tăng tốc phương thức API, điều này khiến người dùng khó chịu vì sự chậm chạp của nó. Kế hoạch là chuyển nó sang một dịch vụ riêng biệt khỏi dịch vụ nguyên khối, nơi gặp khó khăn do phải tích hợp nhiều với các dịch vụ nội bộ và cấu trúc dữ liệu. Dự án này chỉ mang tính thử nghiệm - không ai biết liệu có khả năng tăng tốc hay không.

Tất nhiên, tôi có thể tiếp tục đề xuất viết lại mọi thứ và làm cho nó hoàn hảo. Tôi bắt đầu bằng việc nghiên cứu các dịch vụ nguyên khối và nội bộ, đồng thời điều tra các rủi ro của việc tích hợp. Sau đó, tôi tạo một chiến lược bằng cách sử dụng sơ đồ đơn giản trong Miro, chia mọi thứ thành các lần lặp lại và chỉ sau đó mới bắt đầu làm việc.

Đôi khi, có những vấn đề về tích hợp mà các bên liên quan là người đầu tiên biết. Trước hết, chúng tôi đã giải quyết chúng. Đúng, vẫn còn nợ kỹ thuật trong dự án: linters, các bài kiểm tra chưa hoàn chỉnh, các lược đồ cũ trong cơ sở dữ liệu - nhưng vấn đề của khách hàng đã được giải quyết.

Tất cả các lần lặp lại đều đạt mục tiêu và ở lần thử thứ 4, chúng tôi đã đạt được 100%. Sẽ mất 10 lần lặp lại để viết lại mọi thứ từ đầu, nhưng ngay cả trong thời gian ngắn hơn, chúng tôi đã có được một dịch vụ có thể mở rộng để giải quyết được vấn đề. Câu hỏi duy nhất là cách tiếp cận.

Codex của một nhà phát triển trong một dự án đang phát triển

• Hãy từ bỏ chủ nghĩa hoàn hảo. Mặc dù thế giới có đầy đủ các công nghệ có thể giải quyết vấn đề nhưng bạn không cần phải biết mọi thứ để biến các dự án trở nên hữu ích cho mọi người.

• Sử dụng các giải pháp làm sẵn nếu có thể.

• Giá trị doanh nghiệp được đặt lên hàng đầu. Người dùng không đến vì một sản phẩm, họ đến để tìm giải pháp cho vấn đề của họ.

• Đánh giá rủi ro ngay từ đầu và truyền đạt chúng cho các bên liên quan một cách rõ ràng.

• Lập kế hoạch ngắn hạn. Nếu nhiệm vụ đã tồn đọng trong hai năm, rất có thể người dùng không cần đến nó.

• Thu thập phản hồi và số liệu theo mọi cách có thể. Số liệu là một cách đáng tin cậy để tìm điểm tăng trưởng.

• Các giải pháp có thể mở rộng có thể đạt được ngay cả khi các mẫu kỹ thuật "đúng" không được sử dụng ngay từ đầu.