Bây giờ mọi công ty đều là công ty phần mềm, những cuộc thảo luận gần đây với những người xung quanh tôi (bao gồm cả những người không làm trong lĩnh vực kinh doanh phần mềm) đã khiến tôi khám phá lại tình trạng tồi tệ của việc cung cấp phần mềm ở nhiều nơi.

Bài viết này sẽ chia sẻ một số suy nghĩ của tôi về điều đó, cũng như để tôi trình bày một số lời khuyên cấp cao không mang tính kết luận mà tôi tin rằng có thể tạo thành một nền tảng vững chắc xung quanh đó các tổ chức có vấn đề như vậy có thể được nối lại thành các tổ chức phần mềm thực tế.

Lưu ý rằng khi tôi viết về các tổ chức và doanh nghiệp, do đó, họ sẽ không phải là các công ty công nghệ thuần túy, chẳng hạn như Meta, Google, Spotify, v.v. - mà là phần đuôi dài của các tổ chức (tức là các công ty kế thừa được nâng cao về CNTT), những người không may đã phải thích ứng với phần mềm là một phần của đầu ra và sản phẩm của họ.

Tôi đang viết cái này từ đâu

Một số bối cảnh đầu tiên. Tôi có kinh nghiệm và học hỏi từ một số “thế giới”, cả hai hiện đang là Trưởng nhóm Tiêu chuẩn Kỹ thuật tại Polestar , là nhà sản xuất nguồn mở , là người đam mê đọc công nghệ nói chung và là người sáng lập một công ty khởi nghiệp công nghệ hoàn toàn mới . Cuối cùng, cùng với một đồng nghiệp cũ của tôi, tôi cũng đang tích cực lên kế hoạch thiết lập một dịch vụ CTO phân đoạn miễn phí tại địa phương dành cho các tổ chức trẻ định hướng giá trị.

Tôi bắt đầu viết mã HTML và CSS từ năm 1997, đã khám phá khá nhiều lĩnh vực kể từ đó và trong khi trải qua rất nhiều chuyến tham quan và đường vòng trong cuộc sống, sự nghiệp chuyên nghiệp nghiêm ngặt của tôi bắt đầu vào năm 2016. Vị trí đầu tiên đã là một vị trí phức tạp, lộn xộn và tôi' Tôi thích có những vị trí mà tôi phải cân bằng giữa cứng và mềm, lên xuống từ cấp độ C đến các nhà phát triển khác. Tôi đã điều hành hai doanh nghiệp nhỏ trong lĩnh vực thiết kế và công nghệ, có lẽ không quá thành công, nhưng tôi có kinh nghiệm về tất cả những gì nó đòi hỏi. Kinh nghiệm của tôi với khách hàng đi từ những công ty siêu nhỏ đến những công ty lớn nhất ở Thụy Điển và từ hàng tiêu dùng hàng ngày đến những dịch vụ cực kỳ đặc biệt. Tôi đã may mắn và rất vui khi được giúp đổi mới và tạo nền tảng cho cách phân phối phần mềm có thể hoặc ít nhất nên hoạt động trong nhiều tổ chức, với các nhu cầu khác nhau và kỹ năng chuyên sâu về công nghệ trên nhiều lĩnh vực. Tóm lại, đó là rất nhiều câu bắt đầu bằng “Tôi…”.

OK, vậy tại sao tôi viết ở trên? Đặc biệt là vì tôi muốn hoàn toàn minh bạch rằng những gì tôi sẽ tấn công đến từ việc đã trải qua nỗi đau và thường là “sự không tự nhiên” của phần mềm ở nhiều tổ chức - nó dường như không phù hợp ở hầu hết các nơi! Có rất nhiều thứ để đọc — đủ để chiếm hết tuổi thọ của bạn và hơn thế nữa — nếu bạn muốn tìm hiểu các ý tưởng, khái niệm và triết lý về phần mềm, ngay cả trước khi bạn chuyển sang lĩnh vực kinh doanh, cách vận hành các công ty khởi nghiệp, cách tạo MVP , cách tiếp cận phần mềm chất lượng, v.v. Công bằng mà nói - không ai trong chúng ta có thời gian để tiếp thu hết và sẽ không phải là cách quản lý thời gian tốt nếu chúng ta không cắt giảm nguồn cảm hứng và tiếp nhận ý tưởng mới ở một mức độ nào đó.

Vì vậy, với cách kể chuyện này, tôi sẽ viết về ba điều cụ thể:

• Rằng chúng tôi gặp sự cố với phần mềm trong các tổ chức không phải phần mềm.
• Tại sao bản thân các nhà phát triển không thể biến tổ chức của bạn thành một doanh nghiệp phần mềm.
• Một số thay đổi thực tế, trong cuộc sống thực có thể trông như thế nào để tạo lại nền tảng xung quanh.

Công nghệ phần mềm, từ góc độ quỹ đạo

Chúng tôi là một con tàu vũ trụ của người ngoài hành tinh bay lơ lửng trên Trái đất, nhìn xuống tất cả những tổ chức Wannabe (tức là CNTT).

Một số sự thật mà các công cụ của chúng tôi đã thu thập được cùng với những phản ánh của Nhà khoa học người ngoài hành tinh chính của chúng tôi:

• Tech (đặc biệt là Big Tech) chủ yếu là sử dụng quá mức . Mục đích dường như, hơi cay độc, không phải là bắt mọi người làm việc, mà là loại bỏ họ khỏi sản lượng sản xuất của người khác.
• Điều này trở thành hệ quả tự nhiên của việc làm cho nhiều công việc cùng một lúc trở nên khả thi hơn . Mỉa mai nhưng là sự thật, vì bây giờ bạn có hai tấm séc lương cho việc không làm gì nhiều gấp đôi.
• Ở quy mô công ty, như Victor Ronin viết, “ bạn có thể sa thải 80% kỹ sư phần mềm, và công ty sẽ tồn tại ”. Không có gì lạ khi không có ai làm việc ngay từ đầu hoặc tổ chức CNTT điển hình có xu hướng sa lầy ngay cả khi họ đã cố gắng.
• Kinh nghiệm làm việc cá nhân cho thấy rõ ràng rằng “lạm phát chức danh” là nghiêm trọng (ít nhất là ở Thụy Điển, nhưng nó dường như là một hiện tượng toàn cầu ) - Tôi không thể chứng minh điều này nhưng nếu bạn đã từng (hoặc giúp đỡ) tuyển dụng hoặc tuyển dụng bạn rất có thể đã thấy điều này. Trên thực tế, mọi người muốn có nhiều tiền hơn cho lao động đôi khi kém chất lượng hơn .
• Trên toàn quốc, ở Thụy Điển, mức độ của các ứng viên đủ điều kiện trong các chương trình định hướng CNTT/CS đã giảm trong một thời gian. Mặc dù vậy, có vẻ như một số chương trình giáo dục nghề nghiệp phi lý thuyết đã thu hút được một số ứng viên. Do đó, thị trường dường như không tăng theo thời gian — nó đang bị thu hẹp lại , ít nhất là về những người có trình độ cao nhất.
• Chúng ta có thể khái quát hóa và nói rằng “trước đây dễ dàng hơn”, vì CNTT là trung tâm chi phí và về cơ bản ở nhiều công ty phải bán giấy phép bán hàng tự động cho phần mềm thương mại (do người khác xây dựng) và đảm bảo máy in và email của bạn hoạt động. Bây giờ, hơi tiếc là mọi công ty đều là công ty phần mềm . Trên thực tế, điều này không đạt được hiệu quả cao vì nó đòi hỏi phải tái cấu trúc và suy nghĩ lại - rất có thể là điều khó khăn nhất đối với những người bình thường.
• CNTT được quản lý quá mức và không đủ tiêu chuẩn một cách đáng thất vọng. Rất có thể có một câu chuyện dài (hoặc nhiều câu chuyện trong số đó) làm cơ sở cho tuyên bố đó, nhưng rõ ràng là CNTT đang thu hút rất nhiều tài năng và ý tưởng không đủ tiêu chuẩn, thường (nhưng không chỉ) ở các bộ phận quản lý (sai). Các vai trò của người quản lý dường như đang bùng nổ khỏi các dây leo của cây phân cấp lớn, trong khi có ít đầu ra (tốt) hơn để thực sự quản lý ngay từ đầu. Chúng ta cần phải có thứ gì đó đặt sản phẩm (và tất nhiên là con người!) lên hàng đầu, chứ không phải các ý tưởng quản lý hoặc quản lý sản phẩm “mở rộng quy mô” được lưu trữ sẵn trên giá vốn không hiệu quả .
• Suy nghĩ về sản phẩm, suy nghĩ về bên và những người hình chữ T rất khó để có được. Chúng ta nên đảm bảo rằng chúng ta có các cơ chế giúp nhân viên của chúng ta có những kỹ năng như vậy mạnh mẽ hơn, trong quá trình hòa nhập hàng ngày cũng như trong quá trình đào tạo thường xuyên và dự kiến . Nhưng chúng ta không nên nhận những thứ thiếu tất cả những thứ đó ngay từ đầu.
• Quy trình không phải là kẻ thù, trái ngược với điều mà những người quá khích nhanh nhẹn muốn bạn tin tưởng. Quy trình là tuyệt vời nếu nó giúp nhân viên làm việc hiệu quả và hạnh phúc một cách có ý nghĩa trong khi vẫn duy trì đầu ra ở mức cạnh tranh, cả về mặt chức năng và chức năng chéo. Vấn đề là các tổ chức truyền thống không điều chỉnh các quy trình xung quanh nhịp độ phân phối phần mềm cao hơn nhiều.
• Điều gì dường như đang chiếm thời gian của các kỹ sư phần mềm ở nhiều nơi? Nó dường như xoay quanh những mối quan tâm tích hợp tương đối khiêm tốn, tự động hóa quy trình và bảo trì hệ thống. Gần giống như một thợ sửa ống nước kỹ thuật số … thú vị…

— Người dùng “denton-scratch”https://news.ycombinator.com/item?id=33961785

• Thật may mắn cho những tâm hồn quản lý kém cỏi đó là có một số loại câu trả lời cho kịch bản thợ sửa ống nước kỹ thuật số đó: Không mã/mã thấp là một cách tiếp cận đã đi trước ở chỗ nó nhận ra rằng không có đủ kỹ sư phần mềm có năng lực, kể cả trong quá trình đào tạo hoặc trên thị trường. Có một số sản phẩm tuyệt vời như Zapier , Autocode , AppSheet , AirTable , Webflow , Retool và Carrd . Chết tiệt, levels.fyi đã mở rộng quy mô cho hàng triệu người dùng chỉ với Google Trang tính làm công cụ phụ trợ của họ …
• …nhưng nó vẫn chưa chín muồi cho tất cả các lĩnh vực kinh doanh và nó vẫn đòi hỏi phần nào tư duy kỹ thuật để hoạt động hiệu quả . Vì vậy, chúng tôi dường như vẫn cần những kỹ sư/nhà phát triển đó sử dụng công cụ “không có mã”, khi ban quản lý và những người còn lại kinh hoàng bởi thực tế là nó vẫn phải làm với phần mềm.

Tốc độ đổi mới trong lĩnh vực phần mềm và phát triển hiện đang rất nhanh. Tôi viết tuyên bố đó như một phần lời xin lỗi và một phần bức thư tình để giải quyết mức độ dễ dàng và “dân chủ hóa” của công nghệ đối với các công ty và tổ chức, bất kể sự trưởng thành về kỹ thuật hay năng lực của họ. Xin lỗi vì trong thực tế của tôi, thực sự rất khó để đưa các công ty lớn gặt hái những lợi ích trong thời đại của chúng ta , và bức thư tình như tôi biết và trân trọng tác động mà các nhà phát triển và doanh nhân có thể có, nếu được đặt trong bối cảnh của tổ chức “đúng đắn”.

Đối với một công ty mới thành lập, điều này chưa bao giờ đúng như ngày nay khi có rất nhiều công cụ hoạt động tốt, UX'ed có thể tạo ra các trải nghiệm và ứng dụng mà cách đây không lâu, chỉ là nơi chuyển giao của các bậc thầy. của bí ẩn.

Có vẻ như nó vẫn chưa đi sâu vào nhiều tổ chức mà họ cần xác định (và phân tầng tương ứng) nếu họ là một tổ chức có cải tiến CNTT hoặc nếu họ là một công ty phần mềm với tư duy xây dựng sản phẩm vòng lặp nhanh. phần mềm phía trước và trung tâm của các hoạt động. Sự sùng bái hàng hóa xung quanh phần mềmvà việc mọi người nghĩ việc trở thành một người quan trọng như thế nào có nghĩa là chúng tôi đã mời những con sói và lang băm vào tổ chức có tầm nhìn vĩ đại. Tầm nhìn vĩ đại với các nhà lãnh đạo thiếu kinh nghiệm và lo lắng, trong các tổ chức không phải lúc nào cũng có thể hoàn thành các tòa lâu đài cao ngất trên bầu trời, với các giới hạn và ràng buộc cố hữu hoặc thâm căn cố đế có thể khiến cho việc tái cấu trúc về cơ bản là không thể đối với phần mềm, thay vì ô tô, vận chuyển, vòng bi , các sản phẩm y tế hoặc những gì bạn có…

Sự khao khát của chúng ta để phù hợp với thời đại rõ ràng, trong nhiều trường hợp, đã dẫn đến việc ra quyết định sai lầm và điều kiện hoạt động kém khiến không thể cung cấp phần mềm chất lượng cao, ổn định và an toàn… Là một công ty không phải phần mềm cũng tốt ! Là một người đặt ra là tồi tệ hơn nhiều.

R nhắc nhở: Sống sót là không bắt buộc . Ai đó sẽ luôn phải đóng vai dodo .

Điểm khác biệt chính giữa tổ chức truyền thống và tổ chức phần mềm là phần mềm chính là sản phẩm . Tât nhiên. Nói như vậy, có thể giả định rằng chúng ta cũng đã đi đến một số hiểu biết:

• Phần mềm cực kỳ linh hoạt (có thể thay đổi, có thể thích ứng);
• Tốc độ thay đổi trong phần mềm cao hơn đáng kể so với trong thế giới vật chất;
• Cạnh tranh trong lĩnh vực phần mềm theo mặc định là toàn cầu và cực kỳ đối kháng về bản chất;
• Phần mềm liên tục được cải tiến, nó không phải là một sản phẩm có thể chuyển giao được với ngày đóng dấu trên đó.

Vấn đề là — chắc chắn — ở đâu đó, vào lúc nào đó, vận may của bạn sẽ cạn kiệt nếu bạn không thể cải thiện tình hình này. Đối thủ cạnh tranh chính của bạn không đến từ các đối thủ kế thừa nổi tiếng, đã được vạch ra của bạn - nó đến từ một số anh chàng hoặc cô gái viết cáo phó của bạn bằng mã trong tài khoản cho thuê lại của họ ở một số quốc gia hoàn toàn khác. Và bạn sẽ không thấy nó đến trước khi quá muộn.

Một tổ chức tập trung vào phần mềm phục vụ, điều chỉnh và tối ưu hóa cho các sự kiện như vậy - bằng chức năng chéo, bằng cách có các vòng lặp ngắn trong chu kỳ phát triển sản phẩm, bằng cách hiểu phần còn lại của bối cảnh kỹ thuật số (từ luật pháp đến mẫu người dùng, v.v. ) và có người dùng với tư cách là một bên liên quan, không phải là một túi tiền trừu tượng, vô tri được giấu khỏi tầm mắt. Một công ty phần mềm không được bảo vệ khỏi thực tế, thị trường hay bất cứ thứ gì khác - nhưng họ thích nghi bằng cách để khách hàng của mình ở gần, một dạng Oracle của Delphi hơi không đáng tin cậy.

Các nhà phát triển sẽ không cứu một tổ chức tồi

Tôi được biết đến là người hay tranh cãi, vì vậy tôi sẽ tiếp tục và loại bỏ suy nghĩ quỷ quái đó ngay lập tức, để chúng ta có thể giải nén điều này cùng nhau… Có lẽ bạn không nên thuê bất kỳ (thêm) nhà phát triển nào nữa, bởi vì :

1. Bạn không thể khoán việc kinh doanh và “biết trước kế hoạch” cho các kỹ sư . Không phải vì chúng dở, mà vì đó là một nhạc cụ khác trong dàn nhạc lớn. Cho rằng doanh nghiệp của bạn không ăn sâu vào quá trình phát triển, thì đó không phải là nơi bạn sẽ tìm thấy những người thúc đẩy kinh doanh. Bắt đầu bằng cách thiết lập kế hoạch và tầm nhìn cho tổ chức của bạn và sản phẩm (có thể). Tuy nhiên, hãy mời các nhà phát triển!
2. Bí ẩn và phép thuật xung quanh các nhà phát triển chỉ cần chết đi . Các nhà phát triển không phải là siêu anh hùng, họ cũng không phải là loại 10x huyền thoại . Giá trị cuối cùng trong việc tạo ra bất cứ thứ gì — trong bối cảnh kinh doanh — là nó hỗ trợ giá trị mà khách hàng của bạn cảm nhận được. Các nhà phát triển không phải là những người lý tưởng để hiểu đầy đủ giá trị đó là gì. Sự phát triển thường được thúc đẩy một cách phản ứng và sau khi thực tế , điều này trực tiếp chuyển thành mã chỉ là thước đo sản xuất hơn là thước đo giá trị . Nếu đây là những gì bạn đang làm, thì không, nhiều nhà phát triển hơn không phải là cách đúng đắn để kinh doanh.
3. Có thể bạn đang tin tưởng rằng việc biến phần mềm đó thành một thứ gì đó hữu hình (bao gồm tất cả các quy trình phi kỹ thuật số, v.v.) sẽ hoạt động tốt trong hệ thống phân cấp kế thừa của bạn . Kinh nghiệm nói rằng điều này hiếm khi xảy ra và LinkedIn đầy rẫy những kẻ không nói sự thật. Hoặc khi bạn đọc một chiến thắng là “chiến thắng khó khăn” (tức là chiến thắng Pyrrhic ), hãy tự hỏi bản thân xem bạn có muốn tìm hiểu xem điều đó thực sự có ý nghĩa gì trong thực tế không. Nhiều khi nó có thể chuyển thành một dự án hoàn toàn bị đánh bại bởi tiếp thị, thiết kế, phát triển, kinh doanh và quản lý, những người có những ý tưởng hoàn toàn trái ngược nhau về cách tiến hành và nội dung của nó. Ngoài ra, một tổ chức lớn sẽ mất thời gian để biến các gói công việc từ ý tưởng thành hiện thực, vì vậy điều này sẽ chỉ xảy ra một lần trong một lần trăng xanh. Và phần còn lại của thế giới có lẽ đã bắt đầu hoạt động khi ánh sáng ban ngày chiếu vào dự án có hình dạng gánh nặng đó. Trừ khi phần mềm được thiết kế và xây dựng dưới dạng một lát cắt dọc bao gồm tất cả những người và quy trình cần thiết, nếu không thì nó gần như chắc chắn sẽ thất bại hoặc hoạt động kém do chi phí và nỗ lực liên quan.

Tôi biết nó có thể nhức nhối, nhưng tôi thực sự đang cố gắng trở thành bạn của bạn ở đây.

Tổ chức lớn? Có lẽ là những vấn đề lớn. Nếu con người là vấn đề, giải pháp là gì? Về mặt logic, câu trả lời là Ít người trong số họ hơn và chất lượng tốt hơn . Do đó, số lượng nhân viên là một cách thực sự tồi tệ và quy mô có lẽ không quan trọng như bạn nghĩ. Thay vào đó, hãy nhắm đến số lượng nhỏ hơn các nhà phát triển có năng lực và trình độ cao tham gia vào một tổ chức coi trọng tính minh bạch và tương tác giữa các chức năng.

Tăng trưởng bùng nổ trong những gì một nhà phát triển có năng lực có thể làm với các dịch vụ công nghệ hiện đại

Những cải tiến trong công nghệ có nghĩa là những cá nhân có năng lực có thể tạo ra nhiều hơn đáng kể so với những nhà phát triển thiếu kỹ năng tiên tiến . Từ các dịch vụ riêng lẻ đến đám mây công cộng, có vô số câu chuyện về các công ty hoạt động dựa trên công việc của chỉ 1–5 nhà phát triển, phần lớn nhờ vào mô hình không có máy chủ và những người đi trước của nó.

Đối với các công ty nặng về công nghệ hơn, tôi đang thấy (và đã thấy) cách một hoặc một số ít nhà phát triển có thể tạo ra những thứ không thể làm được nếu không thuê những người giỏi nhất mà thị trường phải cung cấp và trả bằng nội tạng của bạn. Một phần không nhỏ của điều này đến từ cuộc chạy đua vũ trang giữa các ông lớn, mà còn do các công ty công nghệ khác, thường chuyên về lĩnh vực của họ, đang đổ dầu vào lửa. Với tư cách là “người tiêu dùng” của các dịch vụ, chúng tôi rõ ràng là người chiến thắng. Không tận dụng đà phát triển sẽ nhanh chóng khiến tổ chức của bạn bị tụt lại phía sau.

Khi nào thì bạn hoàn toàn không nên tuyển dụng các nhà phát triển?

Nếu bạn là một doanh nghiệp nhỏ hoặc trong bối cảnh không bị ảnh hưởng sâu sắc bởi kỹ thuật số. Tôi đang nghĩ đến các nhà hàng và những thứ tương tự. Nếu tỷ suất lợi nhuận quá thấp và bạn có đủ ý tưởng về các yêu cầu kinh doanh của mình, thì bạn có thể được phục vụ tốt hơn bởi thứ gì đó như Carrd, Webflow, Retool hoặc thứ gì đó ít mã/không định hướng mã và không ai có thể đổ lỗi cho bạn về điều đó nó, miễn là bạn có một chút sở trường để suy nghĩ về các thuật ngữ có lập trình. Bạn sẽ không phải là người đầu tiên hoặc duy nhất thúc đẩy kinh doanh thành công với các công cụ thân thiện với người dùng và sẵn có trên thị trường này.

Cung cấp phần mềm tốt hơn bây giờ

Chúng tôi đã thấy rằng vấn đề thực sự trong các tổ chức CNTT ít liên quan đến công nghệ mà liên quan nhiều hơn đến con người và quy trình. Do đó, trong khi một số điều dưới đây sẽ là về công nghệ , thì khá nhiều điều không phải vậy.

Không gay gắt, nhưng đó cũng là lý do đủ để bạn tự hỏi: “Nếu tôi không thể giúp tác động hoặc thay đổi những khía cạnh đó, thì khả năng thực tế là công ty của tôi có thể cung cấp phần mềm tốt là bao nhiêu?”. Tôi muốn đặt cược thấp. Xin lỗi, không xin lỗi.

Chúng ta hãy đi đến đó.

Quan tâm đến khách hàng/người dùng

Đây chắc chắn là số 1 trong danh sách của bạn.

Tôi chưa bao giờ làm việc tại một công ty (không, không bao giờ; không phải hôm nay, không phải trước đây) mà công ty thực sự quan tâm đến khách hàng hoặc người dùng. Đừng như vậy.

Nếu không có quan điểm của khách hàng, cuối cùng, bạn sẽ làm hỏng tất cả mọi thứ. Đó là sự thật.

Việc tổ chức sản phẩm của bạn không có liên hệ trực tiếp với người dùng (khi thích hợp) là một sự thụt lùi ngoài sự ngu ngốc. Đảm bảo nó có khả năng như vậy!

đạo đức

Đọc những điều sau đây, bất kể vị trí của bạn:

• Forsgren, Humble và Kim's Accelerate: Khoa học về phần mềm tinh gọn và DevOps: Xây dựng và nhân rộng các tổ chức công nghệ hiệu suất cao
• Nghề thủ công trong sạch của Robert C. Martin : Kỷ luật, Tiêu chuẩn và Đạo đức
• Kỹ thuật phần mềm hiện đại của Dave Farley : Làm những gì hiệu quả để xây dựng phần mềm tốt hơn nhanh hơn

Chúng ta nghe nhiều về việc trao quyền, chẳng hạn như trao quyền cho các nhóm với các trách nhiệm theo chiều dọc trong vai trò DevOps, nhưng tự do đi kèm với trách nhiệm — cả từ phần còn lại của tổ chức đối với các nhóm kỹ thuật. DevOps sẽ không hoạt động trong một nhà máy sản xuất tính năng . Trên một lưu ý liên quan, hãy đọc Nhóm sản phẩm so với tính năng .

Mục tiêu số 2 của bạn là tăng hiệu quả của tổ chức bằng các vòng lặp ngắn hơn từ ý tưởng đến thực hiện. Điều này bị cản trở bởi các nhóm hoặc cấu trúc lớn, các thủ tục cứng nhắc không tạo thêm giá trị và không tin tưởng vào các nhóm nhỏ hơn để thực hiện công việc của họ một cách tự chủ. Vòng lặp này càng ngắn và dữ dội thì càng tốt.

Có một tầm nhìn rõ ràng và được truyền đạt về sản phẩm, dịch vụ của bạn hoặc bất cứ điều gì tổ chức của bạn đang làm . Làm rõ những gì mọi người có thể làm để đạt được điều đó. “Doanh số bán hàng cao hơn” không được coi là tầm nhìn hay hướng dẫn của người lớn, nhưng nó chắc chắn là tốt trong bối cảnh phim hoạt hình Scrooge McDuck.

Tính minh bạch trong các mục tiêu, quyền sở hữu thực sự và quyền ra quyết định: Nếu không có tầm nhìn, định hướng và quyền sở hữu, bạn có thể có tất cả các DevOps mà bạn có thể bắt tay vào làm, nhưng nó sẽ chẳng là gì cả . Có một cổ phần và trách nhiệm cụ thể, có ý nghĩa trong sản phẩm làm tăng sự hài lòng trong công việc, ý thức về mục đích và nhiều yếu tố khác . Trong thế giới đang phát triển, đây sẽ là một thứ gì đó giống như DevOps được bôi trơn kỹ càng, hoạt động tốt hơn trong các nhóm nhỏ hơn với phạm vi chặt chẽ hơn, rõ ràng hơn .

Không xây dựng, hỗ trợ, đầu tư hoặc tài trợ cho lớp quản lý . Mọi người cần phải có cổ phần trong sản phẩm. Quản lý thường không cắt giảm yêu cầu đó.

Có một khái niệm rõ ràng về trách nhiệm giải trình và trách nhiệm làm việc như thế nào . Mặc dù ở nhiều quốc gia, việc hà khắc với người lao động là điều bình thường, nhưng ở những quốc gia như Thụy Điển, thực tế lại ngược lại — có thể cực kỳ khó để tạo áp lực rõ ràng khi kỳ vọng không được đáp ứng. Đừng coi tôi là kẻ thống trị hay người điều khiển nhiệm vụ ở đây, nhưng nếu bạn lật kịch bản và lấy cảm hứng từ bất kỳ cuốn sách tâm lý học đa dạng nào có sẵn hoặc những phát hiện từ DORA , chẳng hạn, bạn sẽ thấy rằng đầu tư cao và cẩn thận là hậu quả tự nhiên của một nhóm hoạt động tốt chỉ làm công việc hàng ngày của họ. Nghịch lý thay - bằng cách minh bạch, rõ ràng và làm việc cùng nhau (chứ không phải chỉ với tư cách cá nhân, tức là chống lại nhau) - bạn sẽ tạo điều kiện cho các nhóm có hiệu suất caonơi trách nhiệm giải trình có xu hướng đến một cách tự động.

Hãy tham gia và đầu tư vào công việc. Cho phép làm việc từ xa . Mọi người sẽ không gian lận nếu họ được lựa chọn kỹ lưỡng, tận tâm và tự hào về công việc của mình.

Đầu tiên: Niềm tin, kỳ vọng và mục tiêu cao… tiếp theo là trao quyền.

Thuê đúng người

Nhận một vài nhà phát triển, nhưng rất nhiệt tình, có kinh nghiệm trong việc thực hiện các dự án của riêng họ (hoặc của các công ty khác) trên đám mây . Giao cho những kỹ sư mới này nhiệm vụ bắt đầu là di chuyển hoặc tái tạo nền tảng cho một số ứng dụng cũ mà bạn có thể có. Sẽ không mất quá nhiều thời gian trước khi bạn có thể bắt đầu sử dụng các điều khoản rút lui đó cho bất kỳ nhân viên nào không ngang tầm.

Đừng thuê những người trên LinkedIn với chức danh không rõ ràng hoặc chức danh mẫu giáo như “Diễn giả chính” hoặc “Người có tầm nhìn”.

Không thuê các nhà phát triển “số lượng lớn”/”số lượng lớn”, bất kể quy mô công ty của bạn.

Đừng thuê bất cứ ai qua cà phê. Hãy để họ được kiểm tra ở tất cả các cấp độ : Năng lực kỹ thuật, tư duy sản phẩm, kỹ năng giải quyết vấn đề bên ngoài, trí tuệ cảm xúc, công việc đã được chứng minh trước đó và mục tiêu rõ ràng của họ. Cả hai bạn đạt được gì khi làm việc cùng nhau? (không phải “cho bạn”!) Hãy để họ gặp gỡ các nhóm và làm việc cùng nhau trong một hoặc hai giờ trước khi bạn bóp cò và cam kết.

Đừng điều hành một trường học. Đầu tư vào những người có năng lực nền tảng vững chắc hoặc gánh chịu hậu quả . Sự chậm trễ về ý tưởng có lẽ là một trong những lý do chính khiến các nhóm và tổ chức không bao giờ trở nên “tuyệt vời”. Ví dụ: việc giảng dạy về tích hợp liên tục trong một tổ chức vào năm 2023 không giúp tổ chức thành công — chúng ta nên mong đợi những kiến ​​thức đó như một năng lực cốt lõi cơ bản. Điều tương tự cũng xảy ra với các tổ chức đổi mới, ở đâu cũng vậy, nhưng tính mới của các khái niệm hoàn toàn cao hơn. Nói tóm lại - hãy xây dựng một tổ chức từ những người đã có uy tín lâu năm trên cơ sở nền tảng cho các hoạt động của bạn, nếu không tổ chức đó chắc chắn sẽ bị tiêu diệt.

Giữ cho nó nhanh nhẹn và tinh gọn

Xem nếu điều này cộng hưởng với bạn đầu tiên:

Dù sao thì… Có thể bạn không thực sự biết về Agile , nhưng bạn có thể có nhiều ý kiến ​​về nó. Mọi người dường như có! Đối với một số tổ chức lại, tôi khuyên bạn nên sử dụng Clean Agile: Back to Basics của Robert C. Martin hoặc ít nhất là video dưới đây, trong đó anh ấy trình bày về lịch sử của Agile và để điều đó xảy ra trước tiên.

Lập kế hoạch? Hãy tiếp tục và sử dụng thứ gì đó như dự án GitHub ; bất cứ điều gì là gần với mã. Tránh Jira và quản lý vì lợi ích quản lý xảy ra bên ngoài công cụ kiếm tiền thực tế - mã.

Mở rộng quy mô? Agile không có nghĩa là mở rộng quy mô — bạn cần giải quyết vấn đề và làm cho vấn đề trở nên hữu hình hơn. Agile không phải là câu trả lời cho mọi thứ, nhưng nếu bạn tìm đến một số tài liệu cốt lõi và vứt bỏ bất kỳ thứ SAFe nào bạn có trong giá sách, thì ít nhất bạn sẽ có một khởi đầu thực sự. Ngoài ra, hãy kiểm tra bài thuyết trình của Gojko Adzic về Descaling Agile . Descale tổ chức của bạn nếu cần thiết.

Đừng mua vào một khuôn khổ . Bắt đầu từ con số không theo đúng nghĩa đen: Không hội họp, không nghi lễ, không bất cứ điều gì. Sau đó thêm một vài rắc khi cần thiết. Tránh các buổi lễ không bổ sung gì — ví dụ: có thể tổ chức một cuộc trò chuyện ngắn trong 10 phút vào buổi sáng để sắp xếp một ngày theo thứ tự (hoặc vào cuối ngày!). Loại bỏ các chuyên gia tư vấn SAFe nếu bạn không may gặp phải họ. Ngoài ra, hãy xem xét các mô hình hoạt động có ý nghĩa hơn trong môi trường chuyển động nhanh, chẳng hạn như Cấu trúc liên kết nhóm .

Có những cuộc họp “không phải là cuộc họp” . Các cuộc họp cần phải hướng đến kết quả, và do đó chỉ nên thực hiện một trong những điều sau đây, ngoài ra không nên làm gì khác:

• Quyết định hoặc lên kế hoạch : Chúng tôi cũng cần thực hiện một số hoạt động meta nhất định. Miễn là chúng có thể thực hiện được và mọi người đều có ngữ cảnh thì việc có những thứ này là xứng đáng. Nhưng hãy cảnh giác với các cuộc họp lập kế hoạch kém! :)
• Công việc : Đúng! Công việc. Thiết lập một khối làm việc theo cặp/đám đông không bị gián đoạn trong vài giờ là một cách tuyệt vời để sử dụng “cuộc họp không phải là cuộc họp”.
• Học hỏi hoặc chia sẻ : Học tập đồng đẳng, nhóm năng lực, hồi tưởng…
• Giao tiếp xã hội : Chém gió, gặp gỡ đồng nghiệp mới, giúp mọi người tìm đường…

Không tin tưởng tôi? Hãy xem bài thuyết trình của Dave Farley về Agile và Kanban.

Mặc dù có một số mô hình với các biến thể ở trên, nhưng một số yếu tố quyết định nên loại bỏ tất cả những thứ không cần thiết.

liên tục cung cấp

“Việc phân phối liên tục cải thiện cả hiệu suất và chất lượng phân phối, đồng thời giúp cải thiện văn hóa và giảm tình trạng kiệt sức cũng như khó khăn khi triển khai.”

– Tăng tốc: Khoa học về phần mềm tinh gọn và DevOps: Xây dựng và nhân rộng các tổ chức công nghệ hiệu suất cao

Liên tục cung cấp phần mềm. Mô hình “ khả thi tối thiểu ” cho điều đó yêu cầu:

• Phát triển dựa trên thân cây
• Công việc tích hợp vào thân cây ở mức tối thiểu hàng ngày
• Công việc đã được kiểm tra tự động trước khi hợp nhất với thân cây
• Công việc được kiểm tra tự động với công việc khác khi hợp nhất
• Tất cả tính năng hoạt động dừng khi bản dựng có màu đỏ
• Công việc mới không phá vỡ công việc được giao

Và vâng, hãy sử dụng phát triển dựa trên thân cây : Đó là chiến lược phân nhánh dễ dàng nhất trong tất cả, được liên kết trực tiếp với việc phân phối liên tục và tránh những ý kiến ​​vô nghĩa xung quanh việc phân nhánh. Nếu bạn nghĩ rằng bạn cần phân nhánh phức tạp, thì vấn đề không phải là công nghệ, mà là cách bạn đặt ra tình huống. Hợp nhất địa ngục không phải là một vấn đề thực tế khi tích hợp liên tục.

Đừng thực hiện các yêu cầu kéo trừ khi có ý nghĩa logic — thay vào đó hãy thực hiện ghép nối hoặc di chuyển, bất cứ khi nào có thể. Đánh giá không đồng bộ phá vỡ quy trình và được xây dựng dựa trên sự ngờ vực. Đảm bảo mọi người làm việc cùng nhau và xây dựng những điều phù hợp.

Sử dụng nền tảng CI/CD tốt, linh hoạt có sẵn như GitHub, GitLab, Harness hoặc Azure DevOps. Đừng chạy thiết lập Jenkins của riêng bạn hoặc phát minh lại bánh xe cụ thể này. Tôi thực sự không thể nghĩ ra bất cứ điều gì vô ích hơn để dành thời gian xây dựng của bạn.

Hãy lặp đi lặp lại. Xây dựng một cái gì đó mà bạn cung cấp theo một số cách hoặc hình thức ngày hôm nay. Hy vọng nhiều lần hôm nay, nhiều lần ngày mai.

Sử dụng một môi trường sản xuất duy nhất và chỉ những môi trường thử nghiệm tạm thời, tồn tại trong thời gian ngắn (nếu bạn cần chúng!). Đừng làm mọi thứ trở nên quá phức tạp giống như bạn đã học chúng trong công việc trước đây của mình.

Sử dụng công nghệ serverless làm mặc định và cũng là mặc định cho các tùy chọn SaaS — không đầu tư quá mức vào những gì sẵn có và rẻ. Sẽ an toàn hơn, rẻ hơn và dễ dàng hơn nếu bạn có những người hiểu biết về đám mây. Quá nhiều người không và sẽ phàn nàn rằng không có máy chủ là tệ. Đừng tin tưởng họ. Thay vào đó, hãy nhờ những người biết về đám mây.

Sử dụng các nút chuyển đổi tính năng khi bạn bắt đầu cần tách biệt các bộ tính năng, chẳng hạn như các tính năng chưa hoàn thành, nhóm người dùng, người thử nghiệm bản beta… Như Charity Majors đã viết, “ Triển khai là cách sai để thay đổi trải nghiệm người dùng ”.

Chất lượng

Luận điểm của tôi là thế này, nếu một cách tiếp cận kỹ thuật để phát triển phần mềm không giúp chúng tôi tạo ra phần mềm tốt hơn nhanh hơn, thì điều đó là sai và không đủ tiêu chuẩn là “Kỹ thuật”.

— Weblog của Dave Farley, Công nghệ phần mềm hiện đại là gì?

Viết bài kiểm tra, tất cả chúng — tập trung vào bài kiểm tra đơn vị và bài kiểm tra tích hợp. Không có bảo hiểm 100% vào ngày đầu tiên cũng không sao, nhưng đừng để khoản nợ đó kéo dài quá nhiều ngày.

Đừng thuê kỹ sư QA, người thử nghiệm hoặc bất kỳ thứ gì tương tự. Yêu cầu các kỹ sư của bạn có thể định lượng chất lượng của họ bằng các bài kiểm tra và đảm bảo rằng họ có thời gian để làm việc đó.

Học cách sử dụng đám mây công cộng. Đừng thuê bất kỳ ai không có kinh nghiệm về đám mây.

Đặt nhiệm vụ cho mọi khoản nợ kỹ thuật cuối cùng.

Đừng quên các yêu cầu về pháp lý, bảo mật và các chức năng chéo khác. Họ sẽ giúp thông báo SDLC của bạn hoặc tiêu chí nội bộ tối thiểu để định nghĩa hoàn thành.

kết thúc

Nỗ lực của tôi ở đây, dù vô ích hay không, là đã thẳng thắn nhất có thể về những vấn đề mà bạn, với tư cách là một tổ chức truyền thống tận dụng “CNTT”, gặp phải khi bạn cố gắng trở thành một công ty tập trung vào phần mềm hơn. Không có cách nào là từ cuối cùng được nói hoặc viết, nhưng tôi hy vọng rằng bạn có ý tưởng về nơi tôi khuyên bạn nên thực hiện một số thay đổi, chúng trông như thế nào và một số khác biệt về văn hóa giữa một tổ chức CNTT và một phần mềm thực sự việc kinh doanh.