Tôi bắt gặp một liên kết đến Chọn công nghệ nhàm chán của Dan McKinley thông qua một trong các kênh Slack cộng đồng của tôi. Nó khiến tôi suy nghĩ về mối liên hệ giữa: độ phức tạp và nợ công nghệ, năng suất và tốc độ của nhà phát triển, văn hóa kỹ thuật và quá trình ra quyết định. Cuối cùng, tôi đi đến kết luận rằng văn hóa ra quyết định - cách thức đưa ra quyết định - có ảnh hưởng rất lớn đến năng suất lâu dài của tổ chức kỹ thuật.

Đầu tiên, một số điểm nổi bật từ Boring Technology. Ba mục quan trọng cộng hưởng với tôi:

1. Chi phí bảo trì dài hạn của một công nghệ chi phối tổng chi phí và vượt xa lợi ích vận tốc ngắn hạn.

Chúng ta có xu hướng tập trung vào những lợi ích của công nghệ mới mà không phải lúc nào cũng thừa nhận đầy đủ chi phí bảo trì liên tục — chi phí này thường chiếm ưu thế trong thời gian dài.

Cách chúng ta cư xử thực sự phụ thuộc vào những gì bạn tin tưởng về thuật ngữ nào thống trị phương trình này trong thế giới thực.

Nếu công nghệ thực sự tốn kém để vận hành, thì chi phí chiếm ưu thế. Nếu công nghệ thực sự tạo ra sự khác biệt lớn trong mức độ dễ dàng trong công việc của bạn, thì lợi ích sẽ chiếm ưu thế.

#48

2. Mọi người (thường) rất cố chấp trong việc lựa chọn cơ sở dữ liệu…

Tôi được đưa vào danh sách những người rất kiên định đó, nhưng hơn thế nữa vì những lý do liên quan đến thực tế là tôi hiểu rõ cần bao nhiêu thời gian và công sức để xây dựng kiến ​​thức chuyên môn cần thiết để thực sự hiểu một RDBMS hoặc công nghệ lưu trữ dữ liệu cụ thể.

Theo kinh nghiệm của tôi, bánh xe nổ ra là ở đây. Mọi người mất bình tĩnh và bắt đầu đánh trống lập trình viên đa ngôn ngữ của họ. Có điều gì đó về ý tưởng thêm một cơ sở dữ liệu mới khiến mọi người xông vào Bastille, nói rằng "bạn không thể ngăn chúng tôi sử dụng công cụ tốt nhất cho công việc, anh bạn."

Và khi mọi người khuất phục trước bản năng này, họ tự nhủ rằng họ đang trao cho các nhà phát triển sự tự do. Và chắc chắn, đó là tự do, nhưng đó là một định nghĩa rất hạn hẹp về tự do là gì. #36

Vấn đề ở đây là quan điểm và khái niệm về tự do và/hoặc sự hài lòng có thể thống trị câu chuyện về sự lựa chọn công nghệ nếu không có một quy trình vững chắc để đưa ra quyết định.

3. Cuối cùng, mục tiêu của chúng tôi trong việc xây dựng và duy trì sản phẩm (hệ thống) là hỗ trợ kết quả kinh doanh thành công. Không phải để xây dựng công nghệ ưa thích.

Quay trở lại trải nghiệm khởi động SaaS đầu tiên của tôi — chúng tôi đã xây dựng Eloqua trên công nghệ nhàm chán — Visual Basic (không đùa đâu, đó là năm 2000), SQL Server, IIS.

Trong vài năm đầu tiên đó, tôi đã xây dựng một vài công cụ nhàm chán (bạn đoán nó — cũng trong Visual Basic) để tự động triển khai và thực hiện giám sát điểm cuối cơ bản. (Đó là đám mây tiền công cộng, mọi người!). Mục tiêu chính của tôi là tiết kiệm thời gian và giảm lỗi trong quá trình triển khai — chúng tôi có một nhóm rất tinh gọn và những công cụ này đã cải thiện đáng kể hiệu quả của chúng tôi.

Vào năm 2008, tám năm sau vòng đời của công ty, nhóm “Hoạt động sản xuất” chín người của tôi đã hỗ trợ chuyên môn về trung tâm dữ liệu, tất cả phần cứng và cơ sở hạ tầng, mạng và cơ sở dữ liệu. Hàng ngày, chúng tôi thấy hàng chục triệu giao dịch. Trong quý 4 năm 2008, chúng tôi đã duy trì 99,998% thời gian hoạt động và chúng tôi đã làm như vậy đồng thời giảm chi phí, trên nền tảng công nghệ thực sự nhàm chán này.

Rõ ràng là ngăn xếp nhàm chán này tại Eloqua sẽ trông khác rất nhiều nếu chúng tôi xây dựng nó bằng những công nghệ có sẵn trong vòng 5 đến 10 năm qua. Và, sẽ có những lợi ích đáng kể mà chúng ta có thể thấy với một số công nghệ cụ thể. Nhưng với các công nghệ hiện có, việc dễ dàng tạo ra một dịch vụ được quản lý mới phải được cân nhắc với tổng chi phí sở hữu lâu dài.

Vì thế:

Bạn nên có một quy trình để thêm công nghệ vào ngăn xếp của mình liên quan đến việc nói chuyện với những người khác. #86

Làm cách nào để bạn đưa ra các quyết định này ở quy mô hơn 20 nhóm?

Tại FreshBooks, chúng tôi đã dành nhiều thời gian để giải quyết các câu hỏi này và cuối cùng hướng tới việc mang lại sự rõ ràng và thực chất cho quá trình ra quyết định bằng cách sử dụng:

• Tài liệu kỹ thuật để ghi lại rõ ràng các thông tin và quy trình quan trọng, thay đổi chậm, quan trọng đối với tổ chức
• Khung ra quyết định để giúp các nhóm hiểu những quyết định nào có thể được đưa ra ở cấp độ nhóm so với cấp độ tổ chức và tìm tài liệu ở đâu
• Tech Radar nội bộ mô tả các công cụ, công nghệ nên và không nên áp dụng
• Quy trình Yêu cầu Nhận xét (RFC) cho một khuôn khổ để đánh giá và đề xuất các phương pháp hoặc công nghệ mới
• Bản ghi Quyết định Kiến trúc (ADR) để ghi lại các quyết định

Gần đây tôi đã quyết định chuyển từ FreshBooks, nhưng tôi hy vọng rằng những cách tiếp cận tập thể này sẽ dẫn đến những quyết định bền vững, giảm độ phức tạp và tăng năng suất. ( Mọi người của FreshBooks - hãy trung thực với tôi và cho tôi biết nó diễn ra như thế nào… )

Trở lại Eloqua. Chúng tôi đã đưa ra những lựa chọn công nghệ nhàm chán không cần thiết cho phần lớn lịch sử của công ty. Chúng tôi đã tạo ra một danh mục mới - Tiếp thị tự động hóa - nhưng có một nền văn hóa được coi là (và có lẽ là) kém đổi mới kỹ thuật. Chúng tôi không có quy trình ra quyết định mạnh mẽ, nhưng các quyết định của chúng tôi bị ảnh hưởng nặng nề bởi nhu cầu hỗ trợ luồng doanh thu B2B của doanh nghiệp.

Cuối cùng, chúng tôi đã bán Eloqua và ngăn xếp công nghệ nhàm chán của nó cho Oracle với giá gần 900 triệu USD. Tôi khá chắc chắn rằng doanh thu định kỳ và tốc độ tăng trưởng doanh thu là mối quan tâm chính của họ trong thương vụ này… và những lựa chọn công nghệ nhàm chán của chúng tôi chỉ đơn giản là vượt qua quá trình thẩm định.