Quy trình SDLC cho Citizen Developer: Khung làm việc để xây dựng công cụ nội bộ bằng AI

@businessbarista
TIẾNG ANH4 ngày trước · 17 thg 7, 2026
110K
155
15
10
546

TL;DR

Alex Lieberman giới thiệu khung làm việc sáu giai đoạn để quản lý quá trình phát triển phần mềm bằng AI bởi nhân sự không chuyên về kỹ thuật, đảm bảo tính quản trị thông qua các rào cản tự động.

Giới thiệu về Citizen Developer SDLC của Tenex, một vòng đời sáu giai đoạn giúp đưa những gì nhân viên không chuyên kỹ thuật xây dựng bằng AI từ nguyên mẫu cá nhân lên môi trường sản xuất có quản trị mà toàn bộ công ty có thể dựa vào.

Bởi Alex Lieberman (@businessbarista), Arman Hezarkhani (@ArmanHezarkhani, Suchi Patel, và Ashwin Kadaru (@AshwinKadaru

Một khuôn khổ của Tenex.co.

Tổng Quan

Citizen SDLC là một vòng đời sáu giai đoạn (ý tưởng, cửa trước, phân loại, cấp phát, xây dựng, vận hành và thay đổi) giúp đưa phần mềm do nhân viên không chuyên kỹ thuật xây dựng bằng AI từ nguyên mẫu cá nhân lên môi trường sản xuất có quản trị. Một nguyên tắc xuyên suốt mọi giai đoạn: AI làm phần việc nặng nhọc, mã xác định thiết lập các rào chắn, và con người xử lý các ngoại lệ. Nó ra đời bởi vì AI đã giảm chi phí viết mã xuống gần như bằng không và chuyển điểm nghẽn về phía hạ nguồn, đó là đảm bảo những gì được xây dựng là hợp lý và duy trì quản trị cho một đội tàu phần mềm đang ngày càng lớn khi nó đã hoạt động.

Một trong những khách hàng của chúng tôi là một công ty đầu tư. Một thành viên trong nhóm vận hành danh mục đầu tư của họ, một người chưa bao giờ viết một dòng mã nào, đã xây dựng bảng điều khiển mà cả nhóm của cô ấy hiện đang sử dụng hàng ngày. Nó theo dõi công việc tạo giá trị trên vài chục công ty trong danh mục đầu tư. Cô ấy đã xây dựng nó bằng cách ra lệnh cho Claude, lặp đi lặp lại trong khoảng hai tháng. Mọi dòng mã đều do AI viết.

Và nó rất tốt. Các góc nhìn đúng đắn, quy trình làm việc phù hợp với cách nhóm thực sự vận hành, và việc áp dụng diễn ra ngay lập tức. Cô ấy đã phác thảo sản phẩm chính xác trước khi bất kỳ kỹ sư nào tham gia.

Đó không phải là may mắn. Trong nhiều thập kỷ, người hiểu vấn đề kinh doanh hầu như không bao giờ là người có thể xây dựng phần mềm để khắc phục nó. Thu hẹp khoảng cách đó là một nỗ lực phi thường: một giám đốc sản phẩm để biến vấn đề của cô ấy thành một bản đặc tả kỹ thuật, các kỹ sư để dịch bản đặc tả đó thành mã, và một suất trong hàng chờ phía sau mọi thứ khác trên lộ trình sản phẩm. Nhiều tháng trôi qua giữa ý tưởng và công cụ, và những gì cuối cùng được đưa ra là sự diễn giải của người khác về những gì cô ấy muốn nói.

Khoảng cách đó vừa sụp đổ. Sức mạnh xây dựng đã chuyển đến những người thực sự hiểu quy trình, biết dữ liệu có nghĩa là gì và sống trong quy trình làm việc mỗi ngày. Cô ấy đã xây dựng đúng thứ ngay lần thử đầu tiên bởi vì cô ấy là nguồn gốc. Không ai đứng giữa để diễn giải cho cô ấy, hoặc để hiểu sai một chút. Đó là lời hứa về phát triển công dân, và cô ấy đã thực hiện được nó.

Sau đó chúng tôi nhìn vào bên dưới mui xe.

Toàn bộ ứng dụng là một tệp HTML. 540 KB. Khoảng 5.300 dòng. Bộ dữ liệu chính nằm bên trong nó như một khối dữ liệu 80 KB trên một dòng duy nhất. Khi tệp cần cập nhật, AI đã gắn thêm các hàm vá lỗi để ghi đè các giá trị mỗi khi ứng dụng tải. Lưu công việc của bạn có nghĩa là ứng dụng tự ghi lại HTML của chính nó, tự tải xuống máy tính xách tay của bạn và bạn tải nó lên lại một ổ đĩa dùng chung như một phiên bản mới. Nếu hai người chỉnh sửa cùng lúc, ai lưu sau sẽ thắng, và các chỉnh sửa của người kia biến mất.

Một ngày nọ, một hàm lưu đã đi tìm một điểm đánh dấu trong tệp, không tìm thấy nó và vẫn ghi lại những gì nó có. Toàn bộ ứng dụng 540 KB bị cắt ngắn còn 7 byte. Trong một lần ghi âm thầm duy nhất, bảng điều khiển mà nhóm cô ấy dựa vào hàng ngày đã không còn tồn tại, và không có gì trong cách nó được xây dựng được thiết kế để bắt lỗi nó, ngăn chặn nó hoặc khôi phục nó.

Hầu hết các nhà lãnh đạo nghe câu chuyện đó và kết luận rằng phát triển công dân là một trách nhiệm pháp lý cần phải dừng lại. Chúng tôi nghĩ đó là bài học sai lầm, và các công ty hành động theo nó sẽ thua cuộc. Bài học đúng đắn: cô ấy đã làm công việc của mình một cách xuất sắc. Không ai xây dựng con đường để phần mềm vận chuyển trên đó.

Điểm nghẽn đã chuyển chỗ

Trong nhiều thập kỷ, xây dựng phần mềm là phần đắt đỏ. Nó chậm chạp, khan hiếm và tốn kém, và toàn bộ vòng đời phát triển phần mềm đã phát triển để bảo vệ nó. Đặc tả kỹ thuật, ticket, sprint, đánh giá mã: mọi nghi thức trong SDLC truyền thống tồn tại bởi vì việc viết mã là điểm nghẽn.

AI đã giảm giai đoạn đó xuống gần như bằng không, và điểm nghẽn đã chuyển chỗ. Khi bất kỳ ai cũng có thể xây dựng một ứng dụng hoạt động trong một buổi chiều, công việc đắt đỏ không còn là việc xây dựng nữa. Đó là những gì đến sau: đảm bảo những gì được xây dựng là hợp lý và an toàn, và duy trì quản trị cho một đội tàu các ứng dụng đang ngày càng lớn khi chúng đã hoạt động.

Alex Lieberman - inline image

GIF

Và việc xây dựng không hề chậm lại, tạo ra hai vấn đề cần được giải quyết:

Đầu tiên, chất lượng bên dưới mui xe. Một tác nhân được nhắc từ một trang trống bởi một người không phải kỹ sư sẽ hội tụ về phần mềm 'hacky' hoạt động hôm nay và không thể bảo trì mãi mãi. Tệp 540 KB không phải là ngoại lệ; nó là đầu ra mặc định của việc xây dựng mà không có đường ray.

Thứ hai, sự lan rộng. Mọi nhóm đều muốn ứng dụng riêng của mình, và không có nhóm CNTT trung tâm nào có thể tự tay xây dựng và vận hành hàng tá ứng dụng. Nếu không có rào chắn, mỗi ứng dụng sẽ được xây dựng trên bất kỳ ngăn xếp nào mà người xây dựng hoặc mô hình lấy ra: một cơ sở dữ liệu khác, một lược đồ xác thực khác, các bí mật được cất giấu bất cứ nơi nào chúng rơi xuống. Thay vào đó, hãy chặn các yêu cầu và chúng không dừng lại, chúng chỉ chuyển ra ngoài sổ sách. Dù bằng cách nào, bạn cũng kế thừa không chỉ một đội tàu ứng dụng mà còn cả mớ hỗn độn cơ sở hạ tầng bên dưới chúng, và không có thứ gì trong số đó mà IT có thể bảo mật, hỗ trợ hoặc giải thích một cách hợp lý.

Vì vậy, câu hỏi thực sự mà mọi công ty sắp phải đối mặt: làm thế nào để bạn cho phép nhân viên không chuyên kỹ thuật gửi phần mềm nội bộ thực sự mà không kế thừa đội tàu đó?

Ba câu trả lời mặc định đều thất bại:

1) Khóa chặt nó lại. Các yêu cầu xếp hàng, sự kiên nhẫn cạn kiệt và các ứng dụng ngầm vẫn được xây dựng. Bây giờ bạn không thể thấy bất kỳ thứ gì trong số đó. Bạn không thể quản trị những gì bạn không thể thấy.

2) Thả nổi. Hướng những người không phải kỹ sư tới các công cụ AI mà không có cấu trúc và ăn mừng các bản demo. Đây là cách bạn có được tệp 540 KB. Và bạn không thể đánh giá để thoát khỏi nó sau khi sự việc đã xảy ra. Vào thời điểm một khối đá nguyên khối xuất hiện trong quá trình đánh giá mã, nó đã là một khối đá nguyên khối. Nó phải được ngăn chặn ngay từ điểm xuất phát.

3) Đánh giá mọi thứ. Đặt một sự phê duyệt của con người cho mọi thay đổi. Nhóm IT của bạn tinh gọn, khối lượng xây dựng đang bùng nổ, và bây giờ mọi lần triển khai đều phải chờ lịch của người đánh giá. Đánh giá hoặc là giết chết việc áp dụng hoặc bị đóng dấu cao su. Cả hai kết quả đều phản tác dụng.

Vì vậy, câu trả lời không phải là một tài liệu chính sách khác mà là một vòng đời: một SDLC thực sự, được thiết kế cho những người sẽ không bao giờ tự gọi mình là nhà phát triển, với các rào chắn được xây dựng trong nền tảng thay vì được viết trong một bản ghi nhớ. Một con đường đưa một bản dựng từ ý tưởng ngôn ngữ đơn giản đầu tiên đến tất cả các giai đoạn sản xuất có quản trị mà không bao giờ yêu cầu người xây dựng trở thành một kỹ sư. Người đó cung cấp ý định; nền tảng cung cấp kỷ luật.

Một nguyên tắc xuyên suốt mọi giai đoạn của nó: AI làm phần việc nặng nhọc, mã xác định thiết lập các rào chắn, và con người xử lý các ngoại lệ. AI soạn thảo, phân loại và viết. Mã quyết định những gì được phép. Con người chỉ được sử dụng khi thực sự cần phán đoán. Hãy giữ sự phân chia đó; nó là thứ làm cho toàn bộ mọi thứ có thể mở rộng quy mô.

Chúng tôi gọi nó là Citizen SDLC. Sáu giai đoạn, mỗi giai đoạn đều được quản trị.

Alex Lieberman - inline image

Giai đoạn 1

Ý tưởng

Một người mô tả ứng dụng bằng ngôn ngữ đơn giản, với sự trợ giúp của AI: nó làm gì, ai sử dụng nó, nó chạm vào dữ liệu nào, ai sở hữu nó. Mất vài phút và đọc như một bản ghi nhớ. Nó cũng đóng vai trò là bản tóm tắt mà mọi thứ ở hạ nguồn dựa vào. Đây là bước đi đầu tiên của mô hình vận hành: AI làm công việc biến một bài nói lan man thành một tạo tác có cấu trúc.

Đây là những gì nó trông như thế nào trong thực tế. Ai đó trong bộ phận tài chính quỹ gõ: "Tôi muốn một trình theo dõi cho các thông báo gọi vốn. Hiện tại nó là một bảng tính tôi cập nhật bằng tay và gửi email xung quanh vào mỗi thứ Sáu." AI hỏi những gì một nhà phân tích tiếp nhận sẽ hỏi. Ai khác cần xem nó? Mười hai người trong bộ phận tài chính quỹ & IR. Dữ liệu hiện đang sống ở đâu? Một bảng tính trong Box, và chỉ đọc là đủ. Ai sở hữu nó khi bạn đi vắng? Người quản lý của cô ấy. Bài nói lan man đã trở thành một bản tóm tắt: mục đích, người dùng, nguồn dữ liệu, mức độ truy cập, chủ sở hữu, thậm chí là dự đoán đầu tiên về hình dạng của ứng dụng. Một PRD, trên thực tế, được viết bởi một người chưa bao giờ nghe đến thuật ngữ PRD.

Alex Lieberman - inline image

GIF

Chưa có gì tồn tại. Không có mã, không có quyền truy cập, không có cơ sở hạ tầng. Điều đó có chủ đích: công ty hình thành ý kiến về ứng dụng trước khi ứng dụng tồn tại, thay vì sáu tháng sau khi nó đã chịu tải.

Giai đoạn 2

Cửa trước

Mọi yêu cầu đều đi qua một cửa trước có cấu trúc duy nhất, và cùng một thao tác nộp tệp sẽ thả nó trực tiếp vào quy trình phân loại. Bản tóm tắt là yêu cầu, ticket mà IT nhìn thấy, hồ sơ vĩnh viễn và một mục trong danh mục mà mọi người có thể tìm kiếm, tất cả cùng một lúc. Không có yêu cầu ở hành lang, không có đặc ân, không có đường ống ngầm. Bạn không thể quản trị những gì bạn không thể thấy, và bạn không thể chia sẻ những gì bạn không thể tìm thấy. Cửa trước làm cho cả hai điều đó trở nên đúng đắn ngay từ ngày đầu tiên.

Đây là giai đoạn giết chết đường ống ngầm. Một bản dựng bỏ qua cửa trước vẫn có thể tồn tại như một nguyên mẫu trên máy tính xách tay, nhưng nó sẽ ở lại đó. Mọi thứ biến một nguyên mẫu thành phần mềm mà một nhóm có thể dựa vào đều nằm ở hạ nguồn của giai đoạn này: bộ nhớ thực, đăng nhập của công ty, đường ống triển khai, một nơi nào đó để thực sự chạy. Không có thứ gì trong số đó đến được với một bản dựng chưa từng đi qua. Bạn có thể đi vòng quanh cửa trước; bạn chỉ không thể vượt quá nguyên mẫu nếu bạn làm vậy.

Giai đoạn 3

Phân loại

AI phân loại yêu cầu theo hai trục. Hình dạng: đó là loại ứng dụng gì? Một cuộc kiểm toán ngược về những gì nhân viên thực sự xây dựng hầu như luôn thu gọn thành một danh sách ngắn: trình tạo tạo tác, tự động hóa quy trình làm việc, ứng dụng CRUD và bảng điều khiển tương tác. Đặt tên cho hình dạng cho bạn biết kiến trúc nó cần, và nó trao cho giai đoạn tiếp theo con đường trải nhựa để đóng dấu. Bán kính tác động: bản dựng này có thể gây ra bao nhiêu thiệt hại nếu nó đi sai hướng? Chúng tôi chấm điểm đó trên bốn khía cạnh:

  • Phạm vi tiếp cận & khả năng: nó có thể chạm vào những gì, và nó có thể ghi hay chỉ đọc?
  • Khả năng đảo ngược & tự chủ: có con người trong vòng lặp không, và hành động có thể được hoàn tác không?
  • Mức độ tiếp xúc: ai nhìn thấy đầu ra, và nó đi xa đến đâu bên ngoài công ty?
  • Độ nhạy cảm của dữ liệu: dữ liệu nó tương tác nhạy cảm đến mức nào?

Nhưng đây là quy tắc làm cho điều này đáng tin cậy: AI tư vấn. Mã quyết định. Mô hình đọc bản tóm tắt và phân loại nó; sau đó mã chính sách do IT viết sẽ kiểm tra từng phân loại dựa trên các quy tắc. Hãy xem nó hoạt động trên trình theo dõi gọi vốn. Hình dạng: bảng điều khiển tương tác. Bán kính tác động: dữ liệu quỹ nội bộ, mười hai người dùng nội bộ, chỉ đọc, con người trong vòng lặp, không trùng lặp với các ứng dụng hiện có. Mọi khía cạnh đều nằm trong các ngưỡng đã được phê duyệt, vì vậy nó được phê duyệt và không có con người nào tranh luận về nó.

Bây giờ thay đổi một sự thật. Giả sử trình theo dõi cũng cần dữ liệu cam kết LP. Bản tóm tắt có thể thuyết phục đến đâu tùy thích; một thay đổi duy nhất đó đẩy khía cạnh độ nhạy cảm của dữ liệu vượt quá ngưỡng mà IT đặt ra, và yêu cầu được chuyển đến một người. Không có cuộc gọi phán đoán nào xảy ra ở giữa. Một quy tắc hoặc là khớp hoặc là không.

Ba lối ra:

  1. Đã phê duyệt. Bán kính tác động nằm trong mọi ngưỡng, bản tóm tắt đầy đủ, độ tin cậy cao. Tại khách hàng của chúng tôi, khoảng 9/10 yêu cầu được giải quyết theo cách này, tự động.
  2. Tái sử dụng. Nó trùng lặp với một ứng dụng đã tồn tại, vì vậy người yêu cầu được chuyển hướng đến chủ sở hữu ứng dụng đó thay vì xây dựng một bản sao. Các bản sao được hợp nhất, không nhân lên.
  3. Được chuyển lên. Một khía cạnh vượt quá ngưỡng của nó, hoặc độ tin cậy thấp. Một người từ IT & Bảo mật nhận được toàn bộ yêu cầu làm bối cảnh.
Alex Lieberman - inline image

GIF

Yêu cầu thứ mười, cái khác thường, vẫn đáp xuống bàn làm việc của một người với bản tóm tắt đầy đủ đính kèm. Chín yêu cầu kia không bao giờ cần điều đó.

Giai đoạn 4

Cấp phát

Đây là động thái cho phép IT nói đồng ý với số lượng lớn: cấp phát không phải là IT mất kiểm soát đối với những gì được gửi đi mà là sự kiểm soát của IT được chuyển lên thượng nguồn. Thay vì đánh giá mọi ứng dụng sau khi thực tế, IT tác giả con đường trải nhựa một lần và mọi ứng dụng đều được sinh ra trên đó. Một người phê duyệt, và nền tảng đóng dấu ứng dụng từ con đường cho hình dạng của nó: một kho lưu trữ, đăng nhập công ty, một danh tính triển khai, một môi trường riêng tư và cơ sở dữ liệu riêng của nó, tất cả được định nghĩa là cơ sở hạ tầng dưới dạng mã mà IT sở hữu và quản lý phiên bản. Được cấp phát trong vài phút.

Đây là khoảnh khắc duy nhất quyền lực nâng cao được chạy và một con người ở phía trước nó. Mọi ứng dụng đều được sinh ra cô lập, được quản trị và kiểm toán: môi trường có tường bao riêng, không có địa chỉ công cộng, không có bí mật đám mây được lưu trữ, một dấu vết kiểm toán chỉ nối thêm từ ngày zero. Công việc bảo mật đã xảy ra một lần, trên con đường. Không có ứng dụng nào phải lặp lại nó.

Bởi vì con đường được tác giả theo từng hình dạng, sự phê duyệt của con người là một tư thế mặc định, không phải là một khoản thuế vĩnh viễn. Các hình dạng mới lạ và các bản dựng có bán kính tác động cao vẫn giữ cổng người cho tốt. Nhưng một khi con đường của một hình dạng đã chứng tỏ được bản thân qua đủ các bản dựng, các yêu cầu có bán kính tác động thấp trên con đường đó có thể được cấp phát tự động. Đó là cùng một logic "dành phán đoán của con người cho phần đuôi" được áp dụng sớm hơn một giai đoạn: ban đầu bạn chuyển nhiều hơn cho một người và khi các mẫu hình được giữ vững, ranh giới sẽ chuyển dịch về phía tự động hóa.

Alex Lieberman - inline image

Và con đường mang theo một thứ khác quan trọng không kém cơ sở hạ tầng: sổ tay quy tắc AI. Kho lưu trữ được kế thừa trao cho tác nhân viết mã một bộ hướng dẫn trong mỗi phiên làm việc, mã hóa các phản mẫu hình học được từ các thất bại thực tế. Không nhúng các khối dữ liệu lớn hơn 1 KB. Không thêm các hàm ghi đè dữ liệu khi ứng dụng tải. Đây là cách chất lượng bên dưới mui xe được giải quyết mà không yêu cầu người xây dựng biết một thực hành tốt nhất nào: con đường buộc tác nhân phải tuân theo chúng. Mọi quy tắc trong số đó là một vết sẹo với một câu chuyện đằng sau nó (bạn đã đọc một trong số chúng).

Giai đoạn 5

Xây dựng

Người xây dựng nhắc tác nhân viết mã của họ (Claude Code, Codex, v.v.) bên trong một không gian làm việc đám mây có kiểm soát, không bao giờ trên máy tính xách tay của chính họ. Một tác nhân đầu cuối trên máy tính xách tay kế thừa mọi thứ ngồi ở đó: thư, ổ đĩa đồng bộ, cookie trình duyệt, thông tin đăng nhập được lưu trong bộ nhớ đệm. Trong không gian làm việc, tác nhân nhìn thấy dự án. Không có gì khác.

Mọi thứ mà một kỹ sư thường mang theo đều được mang bởi các đường ray: tại khách hàng của chúng tôi, 35 rào chắn trong bốn lớp mà người xây dựng không thể tắt.

Alex Lieberman - inline image

Lớp hợp nhất bao gồm các kiểm tra độ trôi dạt được xây dựng có mục đích cho mã do AI tạo ra: ngân sách kích thước tệp, không có dữ liệu nội tuyến quá khổ, tuân thủ nhật ký kiểm toán. Xanh hoặc nó không hợp nhất. Khi một kiểm tra thất bại, người xây dựng yêu cầu tác nhân sửa nó và đẩy lại.

Con người không đánh giá các thay đổi thông thường. Các kiểm tra là sự đánh giá. Các thay đổi thông thường di chuyển với tốc độ của CI, không phải với tốc độ lịch của người đánh giá. Những gì đến được với con người là phần đuôi hệ quả, được phát hiện một cách máy móc: các thay đổi lược đồ phá hủy, các phụ thuộc mới, các thay đổi đối với các ràng buộc của chính tác nhân, bất cứ thứ gì chạm vào cơ sở hạ tầng. Những thứ đó chờ một người. Không có gì khác. Và khi một cái gì đó mới thoát ra dù sao đi nữa, cách khắc phục là một kiểm tra tự động mới, không phải nhiều sự đánh giá của con người hơn. Hệ thống trở nên chặt chẽ hơn bằng cách mã hóa các bài học, không phải bằng cách thêm các cuộc họp.

Hãy nhớ bảng điều khiển từ phần mở đầu. Hai trong số các kiểm tra độ trôi dạt đó sẽ đã kích hoạt trên nó trong tuần đầu tiên. Khối dữ liệu một dòng 80 KB sẽ đã làm CI thất bại ngay trên lần commit đầu tiên của nó, nhiều tháng trước khi bất kỳ chế độ thất bại nào trở nên cứng nhắc.

Giai đoạn 6

Vận hành & Thay đổi

Sáu tháng sau, trình theo dõi gọi vốn vẫn đang chạy, và đây là lúc vòng đời phát huy giá trị của nó. Ai đó trong IR đặt câu hỏi về thời hạn chuyển tiền trên thông báo tháng Ba. Dấu vết kiểm toán trả lời trong ba mươi giây: ai đã thay đổi trường, khi nào và nó đã nói gì trước đó, được ghi lại trong cùng một giao dịch với chính chỉnh sửa. Không ai xây dựng lại sự thật từ một chuỗi email. Khi người xây dựng chuyển nhóm, quyền sở hữu được chuyển cho một người kế nhiệm được chỉ định thay vì tan biến thành một cái nhún vai. Và nếu cô ấy rời công ty hoàn toàn, thông tin đăng nhập của cô ấy chết và mọi cánh cửa nó mở ra đều đóng lại cùng một lúc. Bao gồm cả trình theo dõi. Yêu cầu tính năng của quý tiếp theo đi trên cùng một đường ray như lần commit đầu tiên.

Quản trị chạy trên tín hiệu, không phải kiểm toán hàng năm. Các số liệu sử dụng của trình theo dõi cho thấy hai nhóm khác đang dựa vào nó, vì vậy nó được thăng cấp và đầu tư. Bảng điều khiển tiền tệ không ai mở từ tháng Tư được lưu trữ, không bị bỏ mặc trong menu. Không ai than khóc nó. Quyền sở hữu được chỉ định vào ngày đầu tiên, vì vậy không có gì tồn tại lâu hơn người xây dựng của nó mà không có chủ. Tài liệu được tái tạo khi ứng dụng phát triển, vì vậy nó không bao giờ lỗi thời. Một ứng dụng không được sử dụng là một thất bại, không phải là một chiến tích. Mục tiêu không bao giờ là số lượng ứng dụng: đó là một danh mục sống động mà nhân viên của bạn thực sự tin tưởng, thay vì một nghĩa địa của phần mềm bị lãng quên.

Khi danh mục phát triển từ mười ứng dụng lên hai trăm, một nhóm trung tâm không còn có thể để mắt đến tất cả, và sự giám sát phải đẩy ra ngoài cho các nhóm sở hữu các ứng dụng. Khi nào và bao xa để liên bang hóa điều đó là một phán đoán và nó thay đổi khi danh mục phát triển. Quản trị ở đây là một tư thế bạn tiếp tục điều chỉnh, không phải là một biện pháp kiểm soát bạn đặt một lần.

Quy tắc giữ toàn bộ mọi thứ lại với nhau

Có một yếu tố kích hoạt mà chúng tôi dạy mọi khách hàng, bởi vì nó trả lời 90% các câu hỏi "cái này có cần toàn bộ quy trình không?": quy tắc người tiêu dùng thứ hai. Nó hoạt động bởi vì đó là khoảnh khắc hồ sơ rủi ro thay đổi.

Ai đó xây dựng phân tích cho chính họ, trên máy tính xách tay của riêng họ, với quyền truy cập dữ liệu giới hạn? Bán kính tác động thấp, quản trị nhẹ. Biểu đồ, bản ghi nhớ và tập lệnh họ chạy cho chính họ không cần một đường ống triển khai. Nhưng khoảnh khắc người thứ hai muốn sử dụng đầu ra trực tiếp, thay vì yêu cầu tác giả làm mới? Bán kính tác động nhảy vọt: phạm vi tiếp cận nhiều hơn, dữ liệu đi xa hơn, người khác tin tưởng nó là đúng. Bây giờ nó là phần mềm và nó tốt nghiệp lên toàn bộ vòng đời, một cách có chủ đích, như một sự kiện rõ ràng. Cùng nguồn dữ liệu, cùng danh tính, con đường mới.

Một quy tắc đó là lý do tại sao quy trình không làm chết người. Hầu hết các bản dựng không bao giờ vượt qua ranh giới. Những cái vượt qua chính xác là những cái đáng để có nghi thức.

Những gì chúng tôi thành thật về

Không có nền tảng nào làm cho những người xây dựng lần đầu viết mã hoàn hảo. Chúng tôi không tuyên bố làm vậy. Các lớp tồn tại để một sai lầm là một sự bất tiện bên trong một ranh giới nhỏ, không phải là một sự cố trên toàn công ty. Mỗi lớp bao gồm chính xác những gì lớp bên trên nó không thể:

Alex Lieberman - inline image

Và kiểm toán ngăn chặn không có gì, nhưng nó làm cho mọi sự cố trở nên ngắn gọn, có thể giải thích và có thể quy kết. Đó là sự khác biệt giữa một buổi chiều tồi tệ và một quý tồi tệ.

Phát triển công dân không nhằm mục đích thay thế kỹ thuật chuyên nghiệp. Các hệ thống ghi chép trong các quy trình được quản lý, bất cứ thứ gì hướng tới khách hàng hoặc nhà đầu tư, các ứng dụng được xây dựng cho người dùng bên ngoài, bất cứ thứ gì mà thời gian chết mang theo một hình phạt tài chính: những thứ đó vẫn thuộc về kỹ thuật và cửa trước sẽ chuyển hướng chúng đến đó ngay từ ngày đầu tiên. Những gì nó thay thế là điểm nghẽn. Nó dân chủ hóa phần đuôi dài của các công cụ nội bộ không bao giờ đáng giá một dự án kỹ thuật chính thức và vận chuyển chúng với tốc độ mà hàng chờ lộ trình sản phẩm không bao giờ có thể cung cấp. Một khuôn khổ không có ranh giới là một khẩu hiệu; cái này biết nó không dành cho cái gì.

Những gì thực sự thay đổi

Tại công ty đầu tư, ứng dụng đầu tiên đi qua nền tảng là ứng dụng đã thúc đẩy nó: bảng điều khiển từ câu chuyện mở đầu, được làm lại trên các đường ray. Cùng màn hình. Cùng người xây dựng. Bây giờ có bộ nhớ thực, đăng nhập công ty và lịch sử của mọi chỉnh sửa. Nó không bao giờ có thể tự cắt ngắn còn 7 byte nữa, bởi vì lớp mã đã gây ra điều đó không thể hợp nhất.

Khoảng 9/10 yêu cầu đã được giải quyết tự động và tỷ lệ đó chỉ tăng lên. Hầu hết những gì người xây dựng không chuyên kỹ thuật tạo ra có bán kính tác động thấp về bản chất. Các công cụ nội bộ, chủ yếu là đọc, đối tượng nhỏ. Khi con đường của mỗi hình dạng chứng tỏ được bản thân, nhiều bản dựng trong số đó trở nên an toàn để cấp phát và triển khai mà không cần con người trong vòng lặp nào cả. Sự chú ý của con người tiếp tục tập trung vào phần đuôi hệ quả và thưa dần ở mọi nơi khác.

Đồng ý mất vài phút hôm nay và nó có xu hướng trở nên tức thời, bởi vì từ chối được xây dựng trong đó.

Mọi công ty sắp có hàng trăm người xây dựng. Hầu hết các công ty vẫn đang quyết định xem nên sợ hãi hay hào hứng về điều đó. Những công ty chiến thắng sẽ không phải là những công ty có nhiều người xây dựng nhất. Họ sẽ là những công ty có những con đường tốt nhất.

Lưu một chạm

Đọc sâu bài viết viral bằng AI trong YouMind

Lưu nguồn, đặt câu hỏi tập trung, tóm tắt lập luận và biến một bài viết viral thành các ghi chú có thể tái sử dụng trong một không gian làm việc AI duy nhất.

Khám phá YouMind
Dành cho nhà sáng tạo

Biến Markdown của bạn thành bài viết 𝕏 gọn gàng

Khi bạn đăng bài viết dài của riêng mình, việc định dạng hình ảnh, bảng và khối mã cho 𝕏 rất mệt mỏi. YouMind biến cả bản nháp Markdown thành một bài viết 𝕏 gọn gàng, sẵn sàng để đăng.

Thử Markdown sang 𝕏

Thêm pattern để giải mã

Bài viết viral gần đây

Khám phá thêm bài viết viral