Tim Lister - đồng tác giả sách
- "Nhân tố con người. Các dự án và nhóm thành công" (cuốn sách gốc có tên là "Peopleware")
- "Điệu nhảy với những chú gấu: Quản lý rủi ro trong các dự án phần mềm"
- “Adrenaline điên cuồng và bị biến đổi bởi các khuôn mẫu. Mô hình hành vi của các nhóm dự án"
Tất cả những cuốn sách này đều là kinh điển trong lĩnh vực của họ và được viết cùng với các đồng nghiệp trong . Ở Nga, đồng nghiệp của anh ấy nổi tiếng nhất - и , người cũng đã viết nhiều tác phẩm nổi tiếng.
Tim có 40 năm kinh nghiệm trong lĩnh vực phát triển phần mềm; vào năm 1975 (không ai trong số những người viết bài habrapost này sinh năm nay), Tim đã là phó chủ tịch điều hành của Yourdon Inc. Hiện nay ông dành thời gian tư vấn, giảng dạy và viết lách, thỉnh thoảng đến thăm hội thảo trên khắp thế giới.
Chúng tôi đã thực hiện một cuộc phỏng vấn với Tim Lister, đặc biệt là về Habr. Anh ấy sẽ khai mạc hội nghị DevOops 2019 và chúng tôi có rất nhiều câu hỏi về sách và hơn thế nữa. Cuộc phỏng vấn được thực hiện bởi Mikhail Druzhinin và Oleg Chirukhin từ ủy ban chương trình hội nghị.
Michael: Bạn có thể nói vài lời về công việc hiện tại của bạn được không?
Tim: Tôi là người đứng đầu Hiệp hội Hệ thống Đại Tây Dương. Có sáu người chúng tôi trong Guild, chúng tôi tự gọi mình là hiệu trưởng. Ba ở Hoa Kỳ và ba ở Châu Âu - đó là lý do tại sao Guild được gọi là Atlantic. Chúng ta đã ở bên nhau nhiều năm đến mức bạn không thể đếm được. Tất cả chúng ta đều có những đặc sản của mình. Tôi đã làm việc với khách hàng trong hơn một thập kỷ qua. Các dự án của tôi không chỉ bao gồm quản lý mà còn bao gồm việc thiết lập các yêu cầu, lập kế hoạch và đánh giá dự án. Có vẻ như những dự án khởi đầu kém thường kết thúc kém. Vì vậy, cần đảm bảo rằng mọi hoạt động đều được cân nhắc và phối hợp thực sự tốt, ý tưởng của những người sáng tạo được kết hợp với nhau. Thật đáng để suy nghĩ về những gì bạn đang làm và tại sao. Những chiến lược nào cần sử dụng để hoàn thành dự án.
Tôi đã tư vấn cho khách hàng theo nhiều cách khác nhau trong nhiều năm. Một ví dụ thú vị là một công ty chế tạo robot để phẫu thuật đầu gối và hông. Bác sĩ phẫu thuật không hoạt động hoàn toàn độc lập mà sử dụng robot. Thành thật mà nói, an toàn ở đây là quan trọng. Nhưng khi bạn cố gắng thảo luận về các yêu cầu với những người đang tập trung giải quyết vấn đề... Nghe thì có vẻ lạ, nhưng ở Mỹ thì có. (Cục Quản lý Dược Liên bang), cơ quan cấp phép cho các sản phẩm như robot này. Trước khi bán bất cứ thứ gì và sử dụng nó cho người sống, bạn cần phải có giấy phép. Một trong những điều kiện là bạn phải đưa ra yêu cầu của mình, bài test là gì, bạn test như thế nào, kết quả test ra sao. Nếu bạn thay đổi các yêu cầu, thì bạn cần phải thực hiện lại toàn bộ quá trình thử nghiệm khổng lồ này. Khách hàng của chúng tôi đã cố gắng đưa thiết kế trực quan của ứng dụng vào yêu cầu của họ. Họ đã có ảnh chụp màn hình trực tiếp như một phần của yêu cầu. Chúng tôi phải lôi chúng ra và giải thích rằng phần lớn các chương trình này không biết gì về đầu gối và hông, tất cả những thứ này với máy ảnh, v.v. Chúng ta cần viết lại các tài liệu yêu cầu để chúng không bao giờ thay đổi, trừ khi một số điều kiện cơ bản thực sự quan trọng thay đổi. Nếu thiết kế trực quan không nằm trong yêu cầu thì việc cập nhật sản phẩm sẽ nhanh hơn rất nhiều. Công việc của chúng tôi là tìm những yếu tố liên quan đến các hoạt động ở đầu gối, hông, lưng, kéo chúng ra thành các tài liệu riêng biệt và nói rằng đây sẽ là những yêu cầu cơ bản. Chúng ta hãy lập một nhóm yêu cầu riêng biệt về hoạt động của đầu gối. Điều này sẽ cho phép chúng tôi xây dựng một bộ yêu cầu ổn định hơn. Chúng ta sẽ nói về toàn bộ dòng sản phẩm chứ không phải về các robot cụ thể.
Rất nhiều công việc đã được thực hiện, nhưng họ vẫn đến những nơi mà trước đây họ đã trải qua hàng tuần, hàng tháng để thử nghiệm lặp đi lặp lại mà không có ý nghĩa hoặc cần thiết, bởi vì các yêu cầu của họ được mô tả trên giấy không trùng với yêu cầu thực tế mà hệ thống được xây dựng. FDA lần nào cũng nói với họ: yêu cầu của bạn đã thay đổi, bây giờ bạn cần kiểm tra lại mọi thứ từ đầu. Việc kiểm tra lại toàn bộ toàn bộ sản phẩm đang giết chết doanh nghiệp.
Vì vậy, có những nhiệm vụ tuyệt vời như vậy khi bạn thấy mình đang bắt đầu một điều gì đó thú vị và ngay những hành động đầu tiên đã đặt ra các quy tắc tiếp theo của trò chơi. Nếu bạn chắc chắn rằng hoạt động ban đầu này bắt đầu hoạt động tốt từ cả quan điểm quản lý và kỹ thuật, bạn sẽ có cơ hội đạt được một dự án tuyệt vời. Nhưng nếu phần này đi chệch hướng và sai sót ở đâu đó, nếu bạn không thể tìm thấy những thỏa thuận cơ bản... không, không phải là dự án của bạn nhất thiết sẽ thất bại. Nhưng bạn sẽ không còn có thể nói: “Chúng tôi đã làm rất tốt, chúng tôi đã làm mọi thứ thực sự hiệu quả”. Đây là những điều tôi làm khi giao tiếp với khách hàng.
Michael: Nghĩa là, bạn khởi động các dự án, thực hiện một số hoạt động khởi động và kiểm tra xem đường ray có đi đúng hướng không?
Tim: Chúng tôi cũng có ý tưởng về cách ghép tất cả các mảnh ghép lại với nhau: chúng tôi cần những kỹ năng gì, khi nào chúng cần chính xác, cốt lõi của nhóm trông như thế nào và những điều cơ bản khác. Chúng ta có cần nhân viên toàn thời gian hay chúng ta có thể thuê người bán thời gian? Lập kế hoạch, quản lý. Những câu hỏi như: Điều gì là quan trọng nhất đối với dự án cụ thể này? Làm thế nào để đạt được điều này? Chúng ta biết gì về sản phẩm hoặc dự án này, rủi ro là gì và những điều chưa biết nằm ở đâu, chúng ta sẽ giải quyết tất cả những điều này như thế nào? Tất nhiên, tại thời điểm này ai đó bắt đầu hét lên "Còn Agile thì sao?!" Được rồi, tất cả các bạn đều linh hoạt, nhưng vậy thì sao? Chính xác thì dự án trông như thế nào, bạn sẽ thực hiện nó như thế nào cho phù hợp với dự án? Bạn không thể chỉ nói rằng “cách tiếp cận của chúng tôi áp dụng cho mọi thứ, chúng tôi là nhóm Scrum!” Đây là điều vô nghĩa và vô nghĩa. Tiếp theo bạn sẽ đi đâu, tại sao nó lại hiệu quả, vấn đề là ở đâu? Tôi dạy khách hàng của mình suy nghĩ về tất cả những câu hỏi này.
19 năm linh hoạt
Michael: Trong Agile, mọi người thường cố gắng không xác định trước bất cứ điều gì mà đưa ra quyết định càng muộn càng tốt, nói rằng: chúng ta quá lớn, tôi sẽ không nghĩ đến kiến trúc tổng thể. Thay vào đó, tôi sẽ không nghĩ về nhiều thứ khác, tôi sẽ cung cấp thứ gì đó phù hợp cho khách hàng ngay bây giờ.
Tim: Tôi nghĩ rằng các phương pháp linh hoạt, bắt đầu bằng vào năm 2001, đã mở rộng tầm mắt của ngành. Nhưng mặt khác, không có gì là hoàn hảo. Tôi hoàn toàn ủng hộ sự phát triển lặp đi lặp lại. Việc lặp lại có rất nhiều ý nghĩa trong hầu hết các dự án. Nhưng câu hỏi bạn cần suy nghĩ là: sản phẩm một khi đã ra mắt và sử dụng thì thời hạn sử dụng được bao lâu? Đây có phải là sản phẩm sẽ tồn tại được sáu tháng trước khi được thay thế bằng sản phẩm khác không? Hay đây là một sản phẩm sẽ có tác dụng trong nhiều năm? Tất nhiên, tôi sẽ không nêu tên, nhưng... Ở New York và cộng đồng tài chính ở đây, những hệ thống cơ bản nhất đều rất cũ. Thật đáng kinh ngạc. Bạn nhìn chúng và nghĩ, giá như bạn có thể quay ngược thời gian, về năm 1994, và nói với các nhà phát triển: “Tôi đến từ tương lai, từ năm 2019. Chỉ cần phát triển hệ thống này miễn là bạn cần. Làm cho nó có thể mở rộng, hãy nghĩ về kiến trúc. Sau đó nó sẽ được cải thiện trong hơn XNUMX năm. Nếu bạn trì hoãn sự phát triển lâu hơn một chút, thì trong kế hoạch tổng thể của mọi việc sẽ không có ai chú ý đến! Khi bạn ước tính mọi thứ trong thời gian dài, bạn cần xem xét tổng chi phí sẽ là bao nhiêu. Đôi khi kiến trúc được thiết kế tốt thực sự có giá trị, còn đôi khi thì không. Chúng ta cần nhìn xung quanh và tự hỏi: liệu chúng ta có đang ở trong tình huống phù hợp để đưa ra quyết định như vậy không?
Vì vậy, một ý tưởng như “Chúng tôi hướng tới sự nhanh nhẹn, chính khách hàng sẽ cho chúng tôi biết những gì họ muốn nhận” - thật là ngây thơ. Khách hàng thậm chí còn không biết mình muốn gì và càng không biết mình có thể nhận được gì. Một số người sẽ bắt đầu trích dẫn những ví dụ lịch sử để tranh luận, tôi đã thấy điều này rồi. Nhưng những người có trình độ kỹ thuật cao thường không nói như vậy. Họ nói: “Đã là năm 2019, đây là những cơ hội mà chúng ta có và chúng ta hoàn toàn có thể thay đổi cách nhìn nhận những điều này!” Thay vì bắt chước các giải pháp hiện có, làm cho chúng đẹp hơn và chải chuốt hơn một chút, đôi khi bạn cần phải ra ngoài và nói: “Hãy sáng tạo lại hoàn toàn những gì chúng ta đang cố gắng làm ở đây!”
Và tôi không nghĩ hầu hết khách hàng có thể nghĩ về vấn đề theo cách đó. Họ chỉ nhìn thấy những gì họ đã có, thế thôi. Sau đó, họ đưa ra những yêu cầu như “hãy làm việc này đơn giản hơn một chút” hoặc bất cứ điều gì họ thường nói. Nhưng chúng tôi không phải là bồi bàn hay hầu bàn, vì vậy chúng tôi có thể nhận đơn đặt hàng cho dù nó có ngu ngốc đến đâu và sau đó nướng nó trong bếp. Chúng tôi là người hướng dẫn của họ. Chúng ta phải mở rộng tầm mắt và nói: này, chúng ta có những cơ hội mới ở đây! Bạn có nhận ra rằng chúng tôi thực sự có thể thay đổi cách thực hiện phần này trong hoạt động kinh doanh của bạn không? Một trong những vấn đề với Agile là nó loại bỏ nhận thức về đâu là cơ hội, đâu là vấn đề, chúng ta thậm chí cần phải làm gì, những công nghệ hiện có nào phù hợp nhất cho tình huống cụ thể này.
Có lẽ tôi đang quá hoài nghi ở đây: có rất nhiều điều tuyệt vời đang diễn ra trong cộng đồng Agile. Nhưng tôi gặp vấn đề với thực tế là thay vì xác định một dự án, mọi người lại bắt đầu bỏ cuộc. Tôi muốn hỏi ở đây - chúng ta đang làm gì, chúng ta sẽ làm điều đó như thế nào? Và bằng cách nào đó, thật kỳ diệu, hóa ra khách hàng luôn biết rõ hơn bất kỳ ai. Nhưng khách hàng chỉ biết rõ nhất khi anh ta chọn từ những thứ đã được ai đó xây dựng. Nếu tôi muốn mua một chiếc ô tô và biết được quy mô ngân sách gia đình mình thì tôi sẽ nhanh chóng chọn được một chiếc ô tô phù hợp với phong cách sống của mình. Ở đây tôi biết mọi thứ rõ hơn bất cứ ai! Nhưng xin lưu ý rằng ai đó đã chế tạo những chiếc ô tô này. Tôi không biết làm thế nào để phát minh ra một chiếc ô tô mới, tôi không phải là chuyên gia. Khi chúng tôi tạo ra các sản phẩm tùy chỉnh hoặc đặc biệt, tiếng nói của khách hàng phải được tính đến, nhưng đây không còn là tiếng nói duy nhất.
Oleg: Bạn đã đề cập đến Tuyên ngôn Agile. Chúng ta có cần cập nhật hoặc sửa đổi nó bằng cách nào đó có tính đến cách hiểu hiện đại về vấn đề này không?
Tim: Tôi sẽ không chạm vào anh ấy. Tôi nghĩ đó là một tài liệu lịch sử tuyệt vời. Ý tôi là, anh ấy chính là anh ấy. Anh ấy vừa tròn 19 tuổi, anh ấy đã già nhưng ở thời đại của mình anh ấy đã làm nên một cuộc cách mạng. Điều anh ấy làm tốt là gây ra phản ứng và mọi người bắt đầu xì xào về anh ấy. Rất có thể bạn chưa làm việc trong ngành vào năm 2001, nhưng khi đó mọi người đều làm việc theo quy trình. Viện Kỹ thuật phần mềm, năm cấp độ của mô hình hoàn thiện phần mềm (CMMI). Tôi không biết liệu những truyền thuyết xa xưa như vậy có cho bạn biết điều gì không, nhưng đó là một bước đột phá. Lúc đầu, mọi người tin rằng nếu các quy trình được thiết lập chính xác thì các vấn đề sẽ tự biến mất. Và sau đó Tuyên ngôn xuất hiện và nói: “Không, không, không - chúng tôi sẽ dựa trên con người chứ không phải quy trình.” Chúng tôi là bậc thầy về phát triển phần mềm. Chúng tôi hiểu rằng quá trình lý tưởng là một ảo ảnh; nó không xảy ra. Có quá nhiều đặc điểm riêng trong các dự án, ý tưởng về một quy trình hoàn hảo duy nhất cho tất cả các dự án không có ý nghĩa gì. Các vấn đề quá phức tạp để có thể khẳng định rằng chỉ có một giải pháp duy nhất cho mọi thứ (xin chào, niết bàn).
Tôi không nghĩ đến tương lai, nhưng tôi sẽ nói rằng mọi người hiện đã bắt đầu suy nghĩ nhiều hơn về các dự án. Tôi nghĩ Tuyên ngôn Agile rất hay trong việc nhảy ra và nói: “Này! Bạn đang ở trên một con tàu và chính bạn đang lái con tàu này. Bạn sẽ phải đưa ra quyết định - chúng tôi sẽ không đề xuất một công thức chung cho mọi tình huống. Bạn là thủy thủ đoàn của con tàu, và nếu đủ giỏi, bạn có thể tìm ra đường đến đích. Đã có những con tàu khác đi trước bạn và sẽ có những con tàu khác sau bạn, nhưng, theo một nghĩa nào đó, hành trình của bạn là duy nhất.” Một cái gì đó như thế! Đó là một cách suy nghĩ. Đối với tôi, không có gì mới dưới ánh mặt trời, mọi người đã đi thuyền trước đây và sẽ đi thuyền trở lại, nhưng đối với bạn đây là cuộc hành trình chính của bạn và tôi sẽ không cho bạn biết chính xác điều gì sẽ xảy ra với bạn. Bạn phải có kỹ năng phối hợp làm việc theo nhóm và nếu bạn thực sự có chúng, mọi việc sẽ diễn ra suôn sẻ và bạn sẽ đạt được điều mình mong muốn.
Phần mềm con người: 30 năm sau
Oleg: Peopleware có phải là một cuộc cách mạng giống như Tuyên ngôn không?
Tim: Peopleware... Tom và tôi đã viết cuốn sách này, nhưng chúng tôi không nghĩ nó sẽ xảy ra như thế này. Bằng cách nào đó nó đã gây được tiếng vang với rất nhiều ý tưởng của mọi người. Đây là cuốn sách đầu tiên nói rằng: phát triển phần mềm là một hoạt động đòi hỏi nhiều nhân lực. Bất chấp bản chất kỹ thuật của chúng tôi, chúng tôi cũng là một cộng đồng gồm những người xây dựng một cái gì đó lớn lao, thậm chí khổng lồ, rất phức tạp. Không ai có thể một mình tạo ra những thứ như vậy phải không? Vì vậy ý tưởng về “đội” trở nên rất quan trọng. Và không chỉ từ quan điểm quản lý, mà còn dành cho những người kỹ thuật đã cùng nhau giải quyết những vấn đề sâu sắc thực sự phức tạp với hàng loạt ẩn số. Đối với cá nhân tôi, đây là một bài kiểm tra lớn về trí thông minh trong suốt sự nghiệp của tôi. Và ở đây bạn cần có khả năng nói: vâng, vấn đề này vượt quá mức tôi có thể tự mình giải quyết, nhưng cùng nhau chúng ta có thể tìm ra một giải pháp tao nhã mà chúng ta có thể tự hào. Và tôi nghĩ ý tưởng này đã gây được tiếng vang lớn nhất. Ý tưởng cho rằng chúng ta làm việc một phần thời gian cho riêng mình, một phần thời gian là thành viên của nhóm và thường quyết định do nhóm đưa ra. Giải quyết vấn đề nhóm đã nhanh chóng trở thành một tính năng quan trọng của các dự án phức tạp.
Mặc dù thực tế là Tim đã đưa ra rất nhiều bài nói chuyện nhưng rất ít trong số đó được đăng lên YouTube. Bạn có thể xem báo cáo “Sự trở lại của Peopleware” từ năm 2007. Tất nhiên, chất lượng còn nhiều điều chưa được mong đợi.
Michael: Có điều gì đã thay đổi trong 30 năm qua kể từ khi cuốn sách được xuất bản?
Tim: Bạn có thể nhìn nhận điều này từ nhiều góc độ khác nhau. Nói về mặt xã hội học... ngày xửa ngày xưa, vào thời kỳ đơn giản hơn, bạn và nhóm của mình ngồi trong cùng một văn phòng. Hai bạn có thể thân thiết mỗi ngày, cùng nhau uống cà phê và bàn bạc công việc. Điều thực sự đã thay đổi là giờ đây các nhóm có thể được phân bổ theo địa lý, ở các quốc gia và múi giờ khác nhau, nhưng họ vẫn đang giải quyết cùng một vấn đề và điều này tạo thêm một lớp phức tạp hoàn toàn mới. Điều này nghe có vẻ cổ điển, nhưng không có gì giống như giao tiếp mặt đối mặt khi tất cả các bạn ở cùng nhau, làm việc cùng nhau và bạn có thể đến gặp một đồng nghiệp và nói, hãy nhìn xem tôi đã khám phá ra điều gì, bạn thích điều này như thế nào? Các cuộc trò chuyện trực tiếp mang lại một cách nhanh chóng để chuyển sang giao tiếp không chính thức và tôi nghĩ những người đam mê sự linh hoạt cũng nên thích nó. Và tôi cũng lo lắng vì trên thực tế, thế giới hóa ra rất nhỏ bé, và giờ đây tất cả đều được bao phủ bởi các đội phân tán và tất cả đều rất phức tạp.
Tất cả chúng ta đều sống trong DevOps
Michael: Ngay cả theo quan điểm của ban chương trình hội nghị, chúng tôi có người ở California, New York, Châu Âu, Nga... chưa có ai ở Singapore. Sự khác biệt về địa lý là khá lớn và mọi người thậm chí còn bắt đầu tản ra nhiều hơn. Nếu chúng ta đang nói về sự phát triển, bạn có thể cho chúng tôi biết thêm về devops và việc phá bỏ rào cản giữa các nhóm không? Có quan niệm cho rằng mọi người đều đang ngồi trong hầm trú ẩn của mình và bây giờ các hầm trú ẩn đang sụp đổ, bạn nghĩ sao về sự tương tự này?
Tim: Đối với tôi, có vẻ như trong bối cảnh những đột phá công nghệ gần đây, devops có tầm quan trọng rất lớn. Trước đây, bạn có các nhóm nhà phát triển và quản trị viên, họ làm việc, làm việc, làm việc và đến một lúc nào đó, một thứ xuất hiện mà bạn có thể đến gặp quản trị viên và đưa nó vào sản xuất. Và ở đây cuộc trò chuyện về boongke bắt đầu, bởi vì quản trị viên ít nhất là đồng minh chứ không phải kẻ thù, nhưng bạn chỉ nói chuyện với họ khi mọi thứ đã sẵn sàng đi vào sản xuất. Bạn có đến gặp họ và nói điều gì đó: hãy nhìn xem chúng tôi có ứng dụng gì, nhưng bạn có thể triển khai ứng dụng này không? Và bây giờ toàn bộ khái niệm giao hàng đã thay đổi theo hướng tốt hơn. Ý tôi là, có ý tưởng rằng bạn có thể vượt qua những thay đổi một cách nhanh chóng. Chúng tôi có thể cập nhật sản phẩm một cách nhanh chóng. Tôi luôn mỉm cười khi Firefox trên máy tính xách tay của tôi bật lên và nói, này, chúng tôi đã cập nhật Firefox của bạn ở chế độ nền và ngay khi bạn có thời gian, vui lòng nhấp vào đây và chúng tôi sẽ cung cấp cho bạn bản phát hành mới nhất. Và tôi đã nói, "Ồ đúng rồi, em yêu!" Trong khi tôi đang ngủ, họ đang làm việc để cung cấp cho tôi một bản phát hành mới ngay trên máy tính của tôi. Điều này thật tuyệt vời, không thể tin được.
Nhưng khó khăn ở đây: bạn có tính năng này khi cập nhật phần mềm, nhưng việc tích hợp mọi người lại khó khăn hơn nhiều. Điều tôi muốn nói tại bài phát biểu quan trọng của DevOops là chúng tôi hiện có nhiều người chơi hơn bao giờ hết. Nếu bạn chỉ nghĩ về tất cả mọi người tham gia vào chỉ một đội…. Bạn coi đó là một nhóm và nó không chỉ là một nhóm lập trình viên. Đây là những người thử nghiệm, người quản lý dự án và nhiều người khác. Và mọi người đều có quan điểm riêng của họ về thế giới. Người quản lý sản phẩm hoàn toàn khác với người quản lý dự án. Quản trị viên có nhiệm vụ riêng của họ. Việc phối hợp tất cả những người tham gia để tiếp tục nhận thức được những gì đang xảy ra và không phát điên trở thành một vấn đề khá khó khăn. Cần tách biệt nhiệm vụ của nhóm và nhiệm vụ áp dụng cho mọi người. Đây là một nhiệm vụ rất khó khăn. Mặt khác, tôi nghĩ mọi chuyện đã tốt hơn nhiều so với nhiều năm trước. Đây chính xác là con đường mà mọi người trưởng thành và học cách cư xử đúng mực. Khi bạn thực hiện tích hợp, bạn hiểu rằng không nên có sự phát triển ngầm, để vào giây phút cuối cùng, phần mềm không bò ra ngoài như một chiếc jack-in-the-box: giống như, hãy nhìn những gì chúng tôi đã làm ở đây! Ý tưởng là bạn sẽ có thể thực hiện tích hợp và phát triển, và cuối cùng, bạn sẽ triển khai một cách gọn gàng và lặp đi lặp lại. Tất cả điều này có ý nghĩa rất lớn đối với tôi. Điều này giúp bạn có thể tạo ra nhiều giá trị hơn cho người dùng hệ thống và cho khách hàng của bạn.
Michael: Toàn bộ ý tưởng của devops là mang đến những phát triển có ý nghĩa càng sớm càng tốt. Tôi thấy rằng thế giới đã bắt đầu ngày càng tăng tốc. Làm thế nào để thích ứng với sự tăng tốc như vậy? Mười năm trước điều này không tồn tại!
Tim: Tất nhiên, mọi người đều muốn ngày càng có nhiều chức năng hơn. Không cần phải di chuyển, chỉ cần chồng thêm lên. Đôi khi bạn thậm chí phải giảm tốc độ để bản cập nhật gia tăng tiếp theo mang lại điều gì đó hữu ích - và điều đó hoàn toàn bình thường.
Ý tưởng rằng bạn cần phải chạy, chạy, chạy không phải là điều tốt nhất. Chắc hẳn không ai muốn sống cuộc sống của mình như vậy. Tôi muốn nhịp độ giao hàng tạo nên nhịp điệu riêng của dự án. Nếu bạn chỉ tạo ra một dòng những điều nhỏ nhặt, tương đối vô nghĩa thì tất cả sẽ chẳng có ý nghĩa gì cả. Thay vì cố gắng tung ra mọi thứ càng sớm càng tốt, điều đáng thảo luận với các nhà phát triển chính cũng như người quản lý sản phẩm và dự án là chiến lược. Điều này thậm chí có ý nghĩa?
Mẫu và phản mẫu
Oleg: Bạn thường nói về các khuôn mẫu và phản khuôn mẫu, và đây là sự khác biệt giữa sự sống và cái chết của các dự án. Và bây giờ, tín đồ tràn vào cuộc sống của chúng ta. Liệu nó có bất kỳ mẫu và phản mẫu riêng nào có thể giết chết dự án ngay tại chỗ không?
Tim: Các khuôn mẫu và phản khuôn mẫu luôn xảy ra. Chút chuyện cần nói. À, có một thứ mà chúng ta gọi là "những thứ sáng bóng". Mọi người thực sự rất thích công nghệ mới. Họ chỉ đơn giản là bị mê hoặc bởi sự tỏa sáng của mọi thứ trông thật ngầu và phong cách, và họ ngừng đặt câu hỏi: điều đó có cần thiết không? Chúng ta sẽ đạt được điều gì? Thứ này có đáng tin cậy không, có ý nghĩa gì không? Có thể nói, tôi thường thấy mọi người đang ở đỉnh cao của công nghệ. Họ bị thôi miên bởi những gì đang xảy ra trên thế giới. Nhưng nếu bạn xem xét kỹ hơn những điều hữu ích mà họ làm, thường thì đơn giản là chẳng có gì hữu ích cả!
Chúng tôi vừa bàn bạc với các đồng chí rằng năm nay là năm kỷ niệm 1969 năm con người đặt chân lên mặt trăng. Đó là vào năm 1969. Công nghệ giúp mọi người đạt được điều đó thậm chí không phải là công nghệ của năm 1960 mà là của năm 62 hoặc XNUMX, bởi vì NASA chỉ muốn sử dụng những gì có bằng chứng rõ ràng về độ tin cậy. Và vì vậy bạn nhìn vào nó và hiểu - vâng, và chúng đúng! Bây giờ, không, không, nhưng bạn gặp vấn đề với công nghệ đơn giản chỉ vì mọi thứ bị đẩy quá mạnh, bị bán đi từ mọi kẽ hở. Mọi người từ khắp mọi nơi đang hét lên: "Nhìn kìa, thật là một thứ mới nhất, thứ đẹp nhất trên thế giới, hoàn toàn phù hợp với tất cả mọi người!" Chà, thế thôi... thường thì tất cả những thứ này hóa ra chỉ là mồi nhử, và sau đó tất cả phải vứt đi. Có lẽ tất cả là do tôi đã già và nhìn những điều như vậy với rất nhiều hoài nghi, khi mọi người chạy ra và nói rằng họ đã tìm ra Cách duy nhất, đúng đắn nhất để tạo ra những công nghệ tốt nhất. Vào lúc này, một giọng nói thức dậy trong tôi rằng: “Thật là một mớ hỗn độn!”
Michael: Thật vậy, chúng ta đã thường xuyên nghe nói về viên đạn bạc tiếp theo chưa?
Tim: Chính xác, và đây là quá trình bình thường! Ví dụ... có vẻ như điều này đã trở thành trò đùa trên khắp thế giới, nhưng ở đây mọi người thường nói về công nghệ blockchain. Và chúng thực sự có ý nghĩa trong những tình huống nhất định! Khi bạn thực sự cần bằng chứng đáng tin cậy về các sự kiện, rằng hệ thống hoạt động và không ai lừa dối chúng tôi, khi bạn gặp vấn đề về bảo mật và tất cả những thứ đó trộn lẫn với nhau - blockchain sẽ có ý nghĩa. Nhưng khi người ta nói rằng Blockchain bây giờ sẽ quét khắp thế giới, quét sạch mọi thứ trên đường đi của nó? Mơ nhiều hơn! Đây là một công nghệ rất tốn kém và phức tạp. Về mặt kỹ thuật phức tạp và tốn thời gian. Bao gồm thuần túy về mặt thuật toán, mỗi khi bạn cần tính toán lại toán học, với những thay đổi nhỏ nhất... và đây là một ý tưởng tuyệt vời - nhưng chỉ dành cho một số trường hợp nhất định. Cả cuộc đời và sự nghiệp của tôi đều hướng về điều này: những ý tưởng thú vị trong những tình huống rất cụ thể. Điều rất quan trọng là phải hiểu chính xác tình huống của bạn là gì.
Michael: Vâng, câu hỏi chính về cuộc sống, vũ trụ và mọi thứ: liệu công nghệ hoặc cách tiếp cận này có phù hợp với hoàn cảnh của bạn hay không?
Tim: Câu hỏi này có thể đã được thảo luận với nhóm công nghệ. Thậm chí có thể mang đến một số nhà tư vấn. Hãy xem dự án và hiểu - liệu bây giờ chúng ta có làm điều gì đó đúng đắn và hữu ích, tốt hơn trước không? Có thể nó sẽ phù hợp, có thể nó sẽ không. Nhưng quan trọng nhất, đừng đưa ra quyết định như vậy một cách mặc định, đơn giản chỉ vì ai đó đã buột miệng nói: “Chúng tôi rất cần một blockchain! Tôi vừa đọc về anh ấy trên một tạp chí trên máy bay!” Nghiêm túc? Nó thậm chí không buồn cười.
“Kỹ sư devops” huyền thoại
Oleg: Bây giờ mọi người đang triển khai devops. Ai đó đọc về devops trên Internet và ngày mai một vị trí tuyển dụng khác sẽ xuất hiện trên một trang tuyển dụng. "kỹ sư devops". Ở đây tôi muốn thu hút sự chú ý của bạn: bạn có nghĩ thuật ngữ “kỹ sư devops” này có quyền sống không? Có ý kiến cho rằng devops là một nền văn hóa và có điều gì đó không bổ sung ở đây.
Tim: Tam tạm. Sau đó hãy để họ ngay lập tức đưa ra một số lời giải thích về thuật ngữ này. Một cái gì đó để làm cho nó độc đáo. Cho đến khi họ chứng minh được rằng có sự kết hợp độc đáo giữa các kỹ năng đằng sau một vị trí tuyển dụng như thế này, tôi sẽ không mua nó! Ý tôi là, chúng ta có một chức danh công việc, “kỹ sư phát triển”, một chức danh thú vị, vâng, tiếp theo là gì? Chức danh công việc nói chung là một điều rất thú vị. Hãy nói “nhà phát triển” – nó là gì? Các tổ chức khác nhau có nghĩa là những thứ hoàn toàn khác nhau. Ở một số công ty, các lập trình viên chất lượng cao viết các bài kiểm tra có ý nghĩa hơn các bài kiểm tra được viết bởi những người kiểm tra chuyên nghiệp đặc biệt ở các công ty khác. Vậy thì sao, bây giờ họ là lập trình viên hay người thử nghiệm?
Đúng, chúng ta có chức danh công việc, nhưng nếu bạn đặt câu hỏi đủ lâu thì cuối cùng chúng ta đều là những người giải quyết vấn đề. Chúng tôi là những người tìm kiếm giải pháp, một số có một số kỹ năng kỹ thuật và một số có những kỹ năng khác. Nếu bạn sống trong một môi trường mà DevOps đã thâm nhập, bạn đang tham gia vào việc tích hợp phát triển và quản trị và hoạt động này có một số mục đích khá quan trọng. Nhưng nếu bạn được hỏi chính xác bạn làm gì và chịu trách nhiệm về điều gì, thì hóa ra mọi người đã làm tất cả những việc này từ xa xưa. “Tôi chịu trách nhiệm về kiến trúc”, “Tôi chịu trách nhiệm về cơ sở dữ liệu”, v.v., bất kể điều gì, bạn thấy đấy - tất cả những điều này đều có trước “devops”.
Khi ai đó nói với tôi chức danh công việc của họ, tôi thực sự không lắng nghe nhiều. Tốt hơn là để anh ấy nói cho bạn biết anh ấy thực sự phải chịu trách nhiệm gì, điều này sẽ cho phép chúng tôi hiểu vấn đề tốt hơn nhiều. Ví dụ yêu thích của tôi là khi một người tự nhận mình là “người quản lý dự án”. Cái gì? Nó chẳng có ý nghĩa gì cả, tôi vẫn không biết bạn làm gì. Người quản lý dự án có thể là một nhà phát triển, trưởng nhóm bốn người, viết mã, thực hiện công việc, người đã trở thành trưởng nhóm, người mà chính mọi người nhận ra nhau là người lãnh đạo. Ngoài ra, người quản lý dự án có thể là người quản lý quản lý sáu trăm người trong một dự án, quản lý những người quản lý khác, chịu trách nhiệm lập lịch trình và lập kế hoạch ngân sách, chỉ vậy thôi. Đây là hai thế giới hoàn toàn khác nhau! Nhưng chức danh công việc của họ nghe có vẻ giống nhau.
Hãy xoay chuyển vấn đề này theo cách khác một chút. Bạn giỏi việc gì, có nhiều kinh nghiệm, có năng khiếu về lĩnh vực nào? Bạn sẽ chịu trách nhiệm về điều gì vì bạn nghĩ mình có thể xử lý được nhiệm vụ? Và ở đây ai đó sẽ ngay lập tức phủ nhận: không, không, không, tôi không muốn xử lý tài nguyên dự án chút nào, đó không phải việc của tôi, tôi là dân kỹ thuật và tôi hiểu khả năng sử dụng và giao diện người dùng, tôi không muốn quản lý quân đội của mọi người, tốt nhất hãy để tôi đi làm.
Và nhân tiện, tôi rất ủng hộ cách tiếp cận trong đó kiểu phân tách các kỹ năng này hoạt động hiệu quả. Nơi các kỹ thuật viên có thể phát triển sự nghiệp của mình theo ý muốn. Tuy nhiên, tôi vẫn thấy các tổ chức mà dân công nghệ phàn nàn: Tôi sẽ phải vào quản lý dự án vì đó là con đường duy nhất ở công ty này. Đôi khi điều này dẫn đến kết quả khủng khiếp. Những kỹ thuật viên giỏi nhất hoàn toàn không phải là những nhà quản lý giỏi và những nhà quản lý giỏi nhất không thể xử lý được công nghệ. Hãy thành thật về điều này.
Tôi thấy rất nhiều nhu cầu về điều này bây giờ. Nếu bạn là một tín đồ công nghệ, công ty của bạn có thể giúp bạn, nhưng dù thế nào đi nữa, bạn thực sự cần phải tìm ra con đường sự nghiệp của riêng mình vì công nghệ luôn thay đổi và bạn cần phải đổi mới bản thân cùng với nó! Chỉ trong hai mươi năm, công nghệ có thể thay đổi ít nhất năm lần. Công nghệ là một điều kỳ lạ...
"Chuyên gia về mọi thứ"
Michael: Làm sao con người có thể đối phó được với tốc độ thay đổi công nghệ như vậy? Sự phức tạp của chúng ngày càng tăng, số lượng của chúng ngày càng tăng, tổng lượng giao tiếp giữa mọi người cũng ngày càng tăng, và hóa ra bạn không thể trở thành “chuyên gia trong mọi thứ”.
Tim: Phải! Nếu bạn làm việc trong lĩnh vực công nghệ, vâng, bạn chắc chắn cần phải chọn một cái gì đó cụ thể và nghiên cứu kỹ về nó. Một số công nghệ mà tổ chức của bạn thấy hữu ích (và có lẽ sẽ thực sự hữu ích). Và nếu bạn không còn quan tâm đến nó nữa - tôi sẽ không bao giờ tin rằng mình sẽ nói điều này - à, có lẽ bạn nên chuyển sang một tổ chức nào đó khác, nơi công nghệ thú vị hơn hoặc thuận tiện hơn để nghiên cứu.
Nhưng nói chung, vâng, bạn đúng. Công nghệ đang phát triển theo mọi hướng cùng một lúc; không ai có thể nói “Tôi là chuyên gia công nghệ về tất cả các công nghệ hiện có”. Mặt khác, có những người bọt biển tiếp thu kiến thức công nghệ theo đúng nghĩa đen và phát cuồng vì nó. Tôi đã từng gặp một vài người như vậy, họ thở và sống theo đúng nghĩa đen, nói chuyện với họ rất hữu ích và thú vị. Họ không chỉ nghiên cứu những gì đang xảy ra bên trong tổ chức mà nói chung, họ nói về nó, họ còn là những nhà công nghệ thực sự tuyệt vời, họ rất có ý thức và có mục đích. Họ chỉ cố gắng bám trụ trên đỉnh sóng, bất kể công việc chính của họ là gì, bởi niềm đam mê của họ là sự chuyển động của Công nghệ, thúc đẩy công nghệ. Nếu bạn bất ngờ gặp một người như vậy, bạn nên đi ăn trưa với anh ấy và thảo luận nhiều điều thú vị khác nhau trong bữa trưa. Tôi nghĩ tổ chức nào cũng cần ít nhất một vài người như vậy.
Rủi ro và sự không chắc chắn
Michael: Các kỹ sư danh dự, vâng. Hãy đề cập đến quản lý rủi ro khi chúng ta có thời gian. Chúng tôi bắt đầu cuộc phỏng vấn này bằng cuộc thảo luận về phần mềm y tế, nơi sai sót có thể dẫn đến hậu quả nghiêm trọng. Sau đó, chúng tôi nói về Chương trình Mặt Trăng, nơi mà nếu xảy ra sai sót thì cái giá phải trả là hàng triệu đô la và có thể có nhiều mạng sống của con người. Nhưng bây giờ tôi thấy chuyển động ngược lại trong ngành, mọi người không nghĩ đến rủi ro, không cố gắng dự đoán chúng, thậm chí không quan sát chúng.
Oleg: Di chuyển nhanh chóng và phá vỡ mọi thứ!
Michael: Đúng vậy, hãy di chuyển nhanh, đập vỡ mọi thứ, càng ngày càng nhiều thứ, cho đến khi bạn chết vì thứ gì đó. Theo quan điểm của bạn, nhà phát triển trung bình nên tiếp cận việc học quản lý rủi ro như thế nào bây giờ?
Tim: Chúng ta hãy vạch ra ranh giới giữa hai điều: rủi ro và sự không chắc chắn. Đây là những điều khác nhau. Sự không chắc chắn xảy ra khi bạn không có đủ dữ liệu tại bất kỳ thời điểm nào để đi đến câu trả lời dứt khoát. Ví dụ, ở giai đoạn đầu của một dự án, nếu ai đó hỏi bạn “khi nào bạn sẽ hoàn thành công việc”, nếu bạn là một người khá trung thực, bạn sẽ nói “Tôi không biết”. Bạn chỉ không biết, và điều đó không sao cả. Bạn chưa nghiên cứu vấn đề và chưa quen với nhóm, bạn chưa biết kỹ năng của họ, v.v. Đây là sự không chắc chắn.
Rủi ro phát sinh khi các vấn đề tiềm ẩn đã được xác định. Loại chuyện này có thể xảy ra, xác suất của nó lớn hơn 0, nhưng nhỏ hơn một trăm phần trăm, ở khoảng giữa. Vì nó, bất cứ điều gì cũng có thể xảy ra, từ sự chậm trễ và công việc không cần thiết, thậm chí có thể dẫn đến hậu quả nghiêm trọng cho dự án. Kết quả, khi bạn nói - các bạn, hãy gấp ô và rời khỏi bãi biển, chúng ta sẽ không bao giờ hoàn thành nó, mọi chuyện đã kết thúc. Chúng tôi đã giả định rằng thứ này sẽ hoạt động, nhưng nó không hoạt động chút nào, đã đến lúc phải dừng lại. Đây là những tình huống.
Thông thường, vấn đề được giải quyết dễ dàng nhất khi chúng đã xuất hiện, khi vấn đề đang xảy ra ngay lúc này. Nhưng khi một vấn đề xảy ra trước mắt bạn, bạn không phải đang thực hiện quản lý rủi ro mà đang giải quyết vấn đề, quản lý khủng hoảng. Nếu bạn là nhà phát triển hoặc người quản lý chính, chắc hẳn bạn đang tự hỏi điều gì có thể xảy ra dẫn đến sự chậm trễ, lãng phí thời gian, chi phí không cần thiết hoặc sự sụp đổ của toàn bộ dự án? Điều gì sẽ khiến chúng ta dừng lại và bắt đầu lại? Khi tất cả những thứ này hoạt động, chúng ta sẽ làm gì với chúng? Có một câu trả lời đơn giản có giá trị trong hầu hết các tình huống: đừng trốn tránh rủi ro, hãy giải quyết chúng. Hãy xem bạn có thể giải quyết một tình huống rủi ro như thế nào, biến nó thành con số không, biến nó từ một vấn đề thành một vấn đề khác. Thay vì nói: được rồi, chúng ta sẽ giải quyết vấn đề khi chúng phát sinh.
Sự không chắc chắn và rủi ro nên được đặt lên hàng đầu trong mọi việc bạn giải quyết. Bạn có thể lập kế hoạch dự án, xem xét trước một số rủi ro quan trọng nhất định và nói: chúng ta cần giải quyết vấn đề này ngay bây giờ, bởi vì nếu bất kỳ điều nào trong số này xảy ra sai sót thì sẽ không còn vấn đề gì nữa. Bạn không nên lo lắng về vẻ đẹp của chiếc khăn trải bàn trên bàn nếu không rõ liệu bạn có thể nấu bữa tối hay không. Trước tiên, bạn cần xác định tất cả các rủi ro khi chuẩn bị một bữa tối ngon miệng, giải quyết chúng và chỉ sau đó mới nghĩ đến tất cả những thứ khác không gây ra mối đe dọa thực sự.
Một lần nữa, điều gì làm cho dự án của bạn trở nên độc đáo? Hãy xem điều gì có thể khiến dự án của chúng ta đi chệch hướng. Chúng ta có thể làm gì để giảm thiểu khả năng xảy ra điều này? Thông thường, bạn không thể vô hiệu hóa chúng 100% và tuyên bố với lương tâm trong sáng: “Vậy là xong, đây không còn là vấn đề nữa, rủi ro đã được giải quyết!” Đối với tôi đây là dấu hiệu của hành vi của người lớn. Đây là sự khác biệt giữa một đứa trẻ và một người lớn - trẻ em nghĩ rằng chúng bất tử, không có gì có thể sai sót, mọi thứ sẽ ổn thôi! Đồng thời, người lớn quan sát cách trẻ ba tuổi nhảy trên sân chơi, quan sát chuyển động bằng mắt và tự nhủ: “ooh-ooh, ooh-ooh.” Tôi đứng gần đó và sẵn sàng đỡ khi đứa trẻ ngã.
Mặt khác, lý do khiến tôi rất thích công việc kinh doanh này là vì nó có nhiều rủi ro. Chúng ta làm nhiều việc và những việc đó đều có rủi ro. Họ yêu cầu một cách tiếp cận của người lớn. Chỉ nhiệt tình thôi sẽ không giải quyết được vấn đề của bạn!
Tư duy kỹ thuật trưởng thành
Michael: Ví dụ với trẻ em là tốt. Nếu tôi là một kỹ sư bình thường thì tôi vui lòng được làm một đứa trẻ. Nhưng làm thế nào để bạn hướng tới suy nghĩ trưởng thành hơn?
Tim: Một trong những ý tưởng có hiệu quả như nhau đối với người mới bắt đầu hoặc nhà phát triển đã thành danh là khái niệm về bối cảnh. Những gì chúng ta đang làm, những gì chúng ta sẽ đạt được. Điều gì thực sự quan trọng trong dự án này? Không quan trọng bạn là ai trong dự án này, dù bạn là thực tập sinh hay kiến trúc sư trưởng, mọi người đều cần có bối cảnh. Chúng ta cần khiến mọi người suy nghĩ ở quy mô lớn hơn công việc của chính họ. “Tôi làm ra tác phẩm của mình và miễn là tác phẩm của tôi thành công là tôi hạnh phúc.” Không và không nữa. Việc nhắc nhở mọi người về bối cảnh nơi họ làm việc luôn có giá trị (không thô lỗ!) Điều mà tất cả chúng ta đang cố gắng cùng nhau đạt được. Những ý tưởng rằng bạn có thể là một đứa trẻ miễn là mọi thứ đều ổn với phần dự án của bạn - làm ơn, đừng làm vậy. Nếu chúng ta vượt qua vạch đích, chúng ta sẽ chỉ vượt qua nó cùng nhau. Bạn không đơn độc, tất cả chúng ta đều ở bên nhau. Nếu tất cả mọi người trong dự án, cả già lẫn trẻ, bắt đầu nói về điều gì thực sự quan trọng đối với dự án, tại sao công ty lại đầu tư tiền vào những gì mà tất cả chúng ta đang cố gắng đạt được... hầu hết họ sẽ cảm thấy tốt hơn nhiều vì họ sẽ thấy công việc của họ tương quan như thế nào với công việc của những người khác. Một mặt, tôi hiểu phần mà cá nhân tôi chịu trách nhiệm. Nhưng để hoàn thành công việc chúng tôi cũng cần tất cả những người khác. Và nếu bạn thực sự nghĩ rằng mình đã hoàn thành, chúng tôi luôn có việc phải làm trong dự án!
Oleg: Nói một cách tương đối, nếu bạn làm việc theo Kanban, khi bạn gặp phải nút thắt của một số thử nghiệm, bạn có thể bỏ công việc bạn đang làm ở đó (ví dụ: lập trình) và đi giúp đỡ những người thử nghiệm.
Tim: Chính xác. Tôi nghĩ những kỹ thuật viên giỏi nhất, nếu bạn nhìn kỹ, họ là những người quản lý của chính họ. Làm thế nào tôi có thể hình thành điều này ...
Oleg: Cuộc sống của bạn là dự án của bạn, mà bạn quản lý.
Tim: Chính xác! Ý tôi là, bạn chịu trách nhiệm, bạn hiểu vấn đề và bạn tiếp xúc với mọi người khi bạn thấy rằng những quyết định của mình có thể ảnh hưởng đến công việc của họ, những điều tương tự. Đó không phải là việc bạn chỉ ngồi vào bàn làm việc, làm công việc của mình và thậm chí không nhận ra điều gì đang diễn ra xung quanh mình. Không không không. Nhân tiện, một trong những điều tốt nhất về Agile là họ đề xuất các giai đoạn chạy nước rút ngắn, bởi vì bằng cách này, trạng thái công việc của tất cả những người tham gia có thể được quan sát rõ ràng, họ có thể cùng nhau nhìn thấy tất cả. Chúng tôi nói về nhau mỗi ngày.
Làm thế nào để tham gia quản lý rủi ro
Oleg: Có cấu trúc kiến thức chính thức nào trong lĩnh vực này không? Ví dụ: tôi là một nhà phát triển Java và muốn hiểu về quản lý rủi ro mà không cần phải trở thành một người quản lý dự án thực sự bằng giáo dục. Có lẽ tôi sẽ đọc cuốn "Một dự án phần mềm tốn bao nhiêu tiền" của McConnell trước, sau đó là gì? Những bước đầu tiên là gì?
Tim: Đầu tiên là bắt đầu giao tiếp với mọi người trong dự án. Điều này mang lại sự cải thiện ngay lập tức trong văn hóa giao tiếp với đồng nghiệp. Chúng ta cần bắt đầu bằng cách mở mọi thứ theo mặc định, thay vì ẩn nó. Hãy nói: đây là những điều khiến tôi khó chịu, đây là những điều khiến tôi mất ngủ vào ban đêm, hôm nay tôi thức dậy vào ban đêm và nghĩ: Chúa ơi, tôi cần phải suy nghĩ về điều này! Những người khác có thấy điều tương tự không? Với tư cách là một nhóm, chúng ta có nên giải quyết những vấn đề tiềm ẩn này không? Bạn cần có khả năng hỗ trợ một cuộc thảo luận về các chủ đề này. Không có công thức chuẩn bị trước nào để chúng tôi làm việc. Vấn đề không phải là làm bánh mì kẹp thịt mà là về con người. “Làm bánh mì kẹp phô mai, bán bánh mì kẹp phô mai” hoàn toàn không phải là việc của chúng tôi và đó là lý do tại sao tôi rất yêu thích công việc này. Tôi thích khi mọi thứ mà các nhà quản lý từng làm giờ đây đều trở thành tài sản của đội.
Oleg: Bạn đã nói trong sách và trong các cuộc phỏng vấn về việc mọi người quan tâm đến hạnh phúc hơn là những con số trên biểu đồ như thế nào. Mặt khác, khi bạn nói với nhóm: chúng tôi đang chuyển sang devops và bây giờ lập trình viên phải liên tục giao tiếp, điều này có thể nằm ngoài vùng an toàn của anh ấy. Và tại thời điểm này, có thể nói là anh ta vô cùng bất hạnh. Phải làm gì trong tình huống này?
Tim: Tôi không chắc chắn chính xác phải làm gì. Nếu một nhà phát triển quá cô lập, họ sẽ không hiểu tại sao công việc lại được thực hiện ngay từ đầu, họ chỉ nhìn vào phần công việc của mình và họ cần đi sâu vào cái mà tôi gọi là "bối cảnh". Anh ta cần tìm ra cách mọi thứ được kết nối với nhau. Và tất nhiên, ý tôi không phải là những bài thuyết trình trang trọng hay bất cứ điều gì tương tự. Tôi đang nói về thực tế là bạn cần trao đổi với đồng nghiệp về toàn bộ công việc chứ không chỉ về phần công việc mà bạn chịu trách nhiệm. Đây là nơi bạn có thể bắt đầu thảo luận về các ý tưởng, thỏa thuận chung để công việc của các bạn ăn khớp với nhau và cách cùng nhau giải quyết một vấn đề chung.
Để giúp họ thích nghi, họ thường muốn cử kỹ thuật viên đi đào tạo và thảo luận về việc đào tạo. Một người bạn của tôi thích nói rằng việc huấn luyện là dành cho chó. Có đào tạo cho mọi người. Một trong những điều tốt nhất khi học với tư cách là một nhà phát triển là tương tác với các đồng nghiệp của bạn. Nếu ai đó thực sự giỏi một việc gì đó, bạn nên xem họ làm việc hoặc nói chuyện với họ về công việc của họ hay điều gì đó. Một số Kent Beck thông thường liên tục nói về lập trình cực đoan. Thật buồn cười vì XP là một ý tưởng đơn giản nhưng lại gây ra rất nhiều vấn đề. Đối với một số người, làm XP giống như bị buộc phải cởi trần trước mặt bạn bè. Họ sẽ thấy những gì tôi đang làm! Họ là đồng nghiệp của tôi, họ không chỉ nhìn thấy mà còn hiểu! Kinh khủng! Một số người bắt đầu lo lắng nghiêm trọng. Nhưng khi bạn nhận ra rằng đây là cách học tốt nhất thì mọi thứ sẽ thay đổi. Bạn làm việc chặt chẽ với mọi người và một số người hiểu chủ đề này tốt hơn bạn nhiều.
Michael: Nhưng tất cả những điều này buộc bạn phải bước ra khỏi vùng an toàn của mình. Là một kỹ sư, bạn phải thoát ra khỏi vùng an toàn của mình và giao tiếp. Là người giải quyết vấn đề, bạn phải liên tục đặt mình vào thế yếu và suy nghĩ xem điều gì có thể xảy ra. Loại công việc này vốn được thiết kế để gây phiền toái. Bạn có ý thức đặt mình vào những tình huống căng thẳng. Thông thường mọi người chạy trốn khỏi họ, mọi người thích trở thành những đứa trẻ hạnh phúc.
Tim: Làm được gì, bạn có thể bước ra và nói thẳng: “Mọi chuyện đều ổn, tôi có thể xử lý được! Tôi không phải là người duy nhất cảm thấy khó chịu. Hãy cùng nhau thảo luận về những điều khó chịu khác nhau với tư cách là một đội! Đây là những vấn đề chung của chúng ta, chúng ta phải giải quyết chúng, bạn biết không? Tôi nghĩ các nhà phát triển thiên tài có phong cách riêng giống như voi ma mút, họ biến mất. Và tầm quan trọng của chúng là rất hạn chế. Nếu bạn không thể giao tiếp thì bạn không thể tham gia tốt. Vì vậy, chỉ cần nói chuyện. Hãy trung thực và cởi mở. Tôi rất xin lỗi vì điều này gây khó chịu cho ai đó. Bạn có thể tưởng tượng, nhiều năm trước đã có một nghiên cứu cho thấy nỗi sợ hãi chính ở Hoa Kỳ không phải là cái chết, mà hãy đoán xem? Sợ nói trước đám đông! Điều này có nghĩa là ở đâu đó có những người thà chết còn hơn nói lời khen thành tiếng. Và tôi nghĩ bạn chỉ cần có một số kỹ năng cơ bản là đủ, tùy thuộc vào việc bạn làm. Kỹ năng nói, kỹ năng viết - nhưng chỉ ở mức thực sự cần thiết trong công việc của bạn. Nếu bạn làm nhà phân tích nhưng không thể đọc, viết và nói, thì thật không may, bạn sẽ không liên quan gì đến các dự án của tôi!
Cái giá của truyền thông
Oleg: Việc tuyển dụng những nhân viên hướng ngoại như vậy có tốn kém hơn không vì nhiều lý do? Rốt cuộc, họ liên tục trò chuyện thay vì làm việc!
Tim: Ý tôi là cốt lõi của nhóm chứ không chỉ tất cả mọi người. Nếu bạn có một người thực sự giỏi trong việc điều chỉnh cơ sở dữ liệu, yêu thích điều chỉnh cơ sở dữ liệu và sẽ tiếp tục điều chỉnh cơ sở dữ liệu của bạn trong suốt quãng đời còn lại của anh ấy và thế là xong, thật tuyệt, hãy tiếp tục như vậy. Nhưng tôi đang nói về những người muốn sống trong chính dự án đó. Cốt lõi của nhóm, nhằm phát triển dự án. Những người này thực sự cần liên tục liên lạc với nhau. Và đặc biệt là khi bắt đầu dự án, khi bạn thảo luận về những rủi ro, cách thức để đạt được các mục tiêu toàn cầu và những thứ tương tự.
Michael: Điều này áp dụng cho tất cả mọi người tham gia vào dự án, bất kể chuyên môn, kỹ năng hoặc cách làm việc. Tất cả các bạn đều quan tâm đến sự thành công của dự án.
Tim: Có, bạn cảm thấy rằng mình đã đủ đắm chìm vào dự án, rằng nhiệm vụ của bạn là giúp dự án thành hiện thực. Cho dù bạn là lập trình viên, nhà phân tích, nhà thiết kế giao diện hay bất kỳ ai. Đây là lý do tôi đến làm việc mỗi sáng và đây là những gì chúng tôi làm. Chúng tôi chịu trách nhiệm về tất cả những người này, bất kể kỹ năng của họ. Đây là một nhóm người đang trò chuyện với người lớn.
Oleg: Trên thực tế, khi nói về những nhân viên nói nhiều, tôi đã cố gắng mô phỏng sự phản đối của mọi người, đặc biệt là các nhà quản lý, những người được yêu cầu chuyển sang làm người sùng đạo, với tầm nhìn hoàn toàn mới này về thế giới. Và bạn, với tư cách là nhà tư vấn, nên nhận thức rõ những phản đối này hơn tôi, với tư cách là một nhà phát triển! Chia sẻ điều nhà quản lý lo lắng nhất?
Tim: Người quản lý? Ừm. Thông thường, các nhà quản lý phải chịu áp lực từ các vấn đề, phải đối mặt với nhu cầu khẩn trương giải phóng một thứ gì đó và giao hàng, v.v. Họ quan sát cách chúng tôi liên tục thảo luận và tranh luận về điều gì đó, và họ thấy nó như thế này: cuộc trò chuyện, cuộc trò chuyện, cuộc trò chuyện... Còn cuộc trò chuyện nào nữa? Trở về với công việc! Bởi vì đối với họ, việc nói chuyện không giống như một công việc. Bạn không viết mã, không kiểm tra phần mềm, dường như không làm gì cả - tại sao không cử bạn đi làm điều gì đó? Rốt cuộc, việc giao hàng đã được thực hiện trong một tháng!
Michael: Đi viết một số mã!
Tim: Đối với tôi, có vẻ như họ không lo lắng về công việc mà lo lắng về việc thiếu tầm nhìn về sự tiến bộ. Để có vẻ như chúng tôi đang tiến gần hơn đến thành công, họ cần thấy chúng tôi nhấn các nút trên bàn phím. Suốt ngày từ sáng đến tối. Đây là vấn đề số một.
Oleg: Misha, bạn đang nghĩ về điều gì đó.
Michael: Xin lỗi, tôi đang mải suy nghĩ và chợt nhớ lại. Tất cả điều này làm tôi nhớ đến một cuộc biểu tình thú vị xảy ra ngày hôm qua... Có quá nhiều cuộc biểu tình ngày hôm qua... Và tất cả đều nghe rất quen thuộc!
Cuộc sống không lương
Tim: Nhân tiện, không nhất thiết phải tổ chức các “cuộc mít tinh” để giao tiếp. Ý tôi là, những cuộc thảo luận hữu ích nhất giữa các nhà phát triển diễn ra khi họ chỉ nói chuyện với nhau. Bạn bước vào buổi sáng với một tách cà phê và có năm người tụ tập và thảo luận sôi nổi về điều gì đó mang tính kỹ thuật. Đối với tôi, nếu tôi là người quản lý dự án này, tốt hơn hết tôi chỉ nên mỉm cười và đi đâu đó về công việc kinh doanh của mình, để họ thảo luận. Họ đã tham gia nhiều nhất có thể. Đây là một dấu hiệu tốt.
Oleg: Nhân tiện, trong cuốn sách của bạn có rất nhiều ghi chú về điều gì tốt và điều gì xấu. Bạn có sử dụng bất kỳ trong số họ cho mình? Nói một cách tương đối, bây giờ bạn có một công ty và một công ty được cấu trúc theo một cách rất không chính thống...
Tim: Không chính thống, nhưng thiết bị này hoàn toàn phù hợp với chúng tôi. Chúng tôi đã biết nhau từ lâu. Chúng tôi tin tưởng lẫn nhau, chúng tôi đã tin tưởng nhau rất nhiều trước khi trở thành đối tác. Và ví dụ, chúng tôi không có lương. Chúng tôi chỉ làm việc, và chẳng hạn, nếu tôi kiếm được tiền từ khách hàng của mình thì tất cả số tiền đó sẽ thuộc về tôi. Sau đó, chúng tôi trả phí thành viên cho tổ chức và số tiền này đủ để hỗ trợ chính công ty. Thêm vào đó, tất cả chúng ta đều chuyên về những thứ khác nhau. Ví dụ, tôi làm việc với các kế toán viên, điền tờ khai thuế, làm mọi việc hành chính cho công ty và không ai trả tiền cho tôi về việc đó. James và Tom làm việc trên trang web của chúng tôi và cũng không ai trả tiền cho họ. Miễn là bạn trả phí, sẽ không có ai nghĩ đến việc nói cho bạn biết bạn cần làm gì. Ví dụ, Tom bây giờ làm việc ít hơn nhiều so với trước đây. Bây giờ anh ấy có những sở thích khác; anh ấy làm một số việc không phải cho Hiệp hội. Nhưng miễn là anh ta vẫn trả phí, sẽ không có ai đến gặp anh ta và nói, "Này, Tom, đi làm đi!" Rất dễ dàng để đối phó với đồng nghiệp khi giữa bạn không có tiền. Và bây giờ mối quan hệ của chúng tôi là một trong những ý tưởng cơ bản liên quan đến các chuyên ngành khác nhau. Nó hoạt động và nó hoạt động rất tốt.
Lời khuyên tốt nhất
Michael: Quay lại với “lời khuyên tốt nhất”, bạn có nói đi nói lại điều gì với khách hàng của mình không? Có một ý tưởng về 80/20 và một số lời khuyên có lẽ được lặp lại thường xuyên hơn.
Tim: Tôi đã từng nghĩ rằng nếu bạn viết một cuốn sách như Waltzing with Bears, nó sẽ thay đổi tiến trình lịch sử và mọi người sẽ dừng lại, nhưng... Chà, nhìn này, các công ty thường giả vờ rằng mọi thứ với họ đều ổn. Ngay khi có điều gì tồi tệ xảy ra, đó là một cú sốc và bất ngờ đối với họ. “Hãy nhìn xem, chúng tôi đã thử nghiệm hệ thống và nó không vượt qua bất kỳ cuộc kiểm tra hệ thống nào, và đây lại là ba tháng làm việc đột xuất, sao chuyện này có thể xảy ra? Ai biết? Điều gì có thể xảy ra? Nghiêm túc mà nói, bạn có tin điều này không?
Tôi đang cố gắng giải thích rằng bạn không nên quá tức giận về tình hình hiện tại. Chúng ta cần phải nói ra, thực sự hiểu điều gì có thể đã xảy ra và làm cách nào để ngăn chặn những điều như vậy xảy ra trong tương lai. Nếu một vấn đề xuất hiện, chúng ta sẽ giải quyết nó như thế nào, chúng ta sẽ giải quyết nó như thế nào?
Đối với tôi, tất cả điều này có vẻ đáng sợ. Mọi người giải quyết những vấn đề phức tạp, khó chịu và tiếp tục giả vờ rằng nếu họ chỉ cầu mong điều tốt nhất và hy vọng điều tốt nhất thì điều “tốt nhất” sẽ thực sự xảy ra. Không, nó không hoạt động theo cách đó.
Thực hành quản lý rủi ro!
Michael: Theo bạn, có bao nhiêu tổ chức tham gia quản lý rủi ro?
Tim: Điều khiến tôi tức giận là mọi người chỉ cần viết ra những rủi ro, nhìn vào danh sách kết quả và bắt đầu làm việc. Thực chất, việc xác định rủi ro đối với họ chính là quản lý rủi ro. Nhưng đối với tôi đây có vẻ là một lý do để hỏi: được rồi, có một danh sách, chính xác thì bạn sẽ thay đổi điều gì? Bạn cần thay đổi trình tự hành động tiêu chuẩn của mình có tính đến những rủi ro này. Nếu có phần khó khăn nhất của công việc, bạn cần phải giải quyết nó và chỉ sau đó mới chuyển sang phần đơn giản hơn. Trong những lần chạy nước rút đầu tiên, hãy bắt đầu giải quyết những vấn đề phức tạp. Điều này đã giống như quản lý rủi ro. Nhưng thông thường mọi người không thể nói họ đã thay đổi những gì sau khi tổng hợp danh sách rủi ro.
Michael: Chưa hết, có bao nhiêu công ty trong số này tham gia vào quản lý rủi ro, 5%?
Tim: Thật không may, tôi ghét phải nói điều này, nhưng đây là một phần rất không đáng kể. Nhưng nhiều hơn năm, bởi vì có những dự án thực sự lớn và đơn giản là chúng không thể tồn tại nếu ít nhất chúng không làm được điều gì đó. Hãy nói rằng tôi sẽ rất ngạc nhiên nếu nó ít nhất là 25%. Các dự án nhỏ thường trả lời những câu hỏi như thế này: nếu vấn đề ảnh hưởng đến chúng tôi thì chúng tôi sẽ giải quyết nó. Sau đó, họ gặp rắc rối thành công và tham gia vào việc quản lý vấn đề và quản lý khủng hoảng. Khi bạn cố gắng giải quyết một vấn đề nhưng vấn đề đó không được giải quyết, chào mừng bạn đến với quản lý khủng hoảng.
Vâng, tôi thường nghe nói “chúng ta sẽ giải quyết vấn đề khi chúng phát sinh”. Chắc chắn chúng ta sẽ làm vậy? Liệu chúng ta có thực sự quyết định được không?
Oleg: Bạn có thể làm điều đó một cách ngây thơ và chỉ cần viết các bất biến quan trọng vào điều lệ dự án, và nếu các bất biến đó bị hỏng, chỉ cần khởi động lại dự án. Hóa ra rất piembucky.
Michael: Đúng, tôi chợt nhận ra rằng khi rủi ro xuất hiện, dự án chỉ đơn giản là được xác định lại. Tốt lắm, chơi lô tô, vấn đề đã được giải quyết, đừng lo lắng nữa!
Tim: Hãy nhấn nút đặt lại! Không, nó không hoạt động theo cách đó.
Bài phát biểu tại DevOops 2019
Michael: Chúng ta đến câu hỏi cuối cùng của cuộc phỏng vấn này. Bạn sắp đến với DevOops tiếp theo với một bài phát biểu quan trọng, bạn có thể vén bức màn bí mật về những gì bạn định kể không?
Tim: Hiện tại, sáu người trong số họ đang viết sách về văn hóa làm việc, những quy tắc bất thành văn của các tổ chức. Văn hóa được quyết định bởi những giá trị cốt lõi của tổ chức. Thông thường mọi người không để ý đến điều này, nhưng đã làm việc trong lĩnh vực tư vấn nhiều năm nên chúng tôi đã quen với việc nhận thấy điều đó. Bạn bước vào một công ty và theo đúng nghĩa đen, chỉ sau vài phút, bạn bắt đầu cảm nhận được điều gì đang xảy ra. Chúng tôi gọi đây là "hương vị". Đôi khi mùi hương này thực sự rất dễ chịu, và đôi khi nó lại rất tệ. Mọi thứ rất khác nhau đối với các tổ chức khác nhau.
Michael: Tôi cũng đã làm việc trong lĩnh vực tư vấn nhiều năm và hiểu rõ bạn đang nói về điều gì.
Tim: Thực ra, một trong những điều đáng nói ở bài phát biểu chính là không phải mọi việc đều do công ty quyết định. Bạn và nhóm của bạn, với tư cách là một cộng đồng, có văn hóa nhóm của riêng bạn. Đây có thể là toàn bộ công ty, hoặc một bộ phận riêng biệt, một nhóm riêng biệt. Nhưng trước khi bạn nói, đây là điều chúng tôi tin tưởng, đây là điều quan trọng... Bạn không thể thay đổi văn hóa trước khi hiểu được các giá trị và niềm tin đằng sau những hành động cụ thể. Hành vi thì dễ quan sát nhưng việc tìm kiếm niềm tin thì khó. DevOps chỉ là một ví dụ tuyệt vời về việc mọi thứ ngày càng trở nên phức tạp hơn. Các tương tác chỉ trở nên phức tạp hơn, chúng không hề trở nên rõ ràng hay rõ ràng hơn chút nào, vì vậy bạn nên suy nghĩ về những gì bạn tin tưởng và những gì mọi người xung quanh im lặng.
Nếu bạn muốn đạt được kết quả nhanh chóng, đây là một chủ đề hay dành cho bạn: bạn đã thấy những công ty nào mà không ai nói “Tôi không biết” chưa? Có những nơi bạn tra tấn một người theo đúng nghĩa đen cho đến khi anh ta thừa nhận rằng mình không biết điều gì đó. Mọi người đều biết mọi thứ, mọi người đều là những người uyên bác đáng kinh ngạc. Bạn tiếp cận bất kỳ người nào và anh ta phải trả lời ngay câu hỏi. Thay vì nói “Tôi không biết”. Hoan hô, họ đã thuê rất nhiều nhà uyên bác! Và trong một số nền văn hóa, nói chung là rất nguy hiểm khi nói “Tôi không biết”; nó có thể bị coi là dấu hiệu của sự yếu đuối. Cũng có những tổ chức mà ngược lại, mọi người đều có thể nói “Tôi không biết”. Ở đó, điều đó hoàn toàn hợp pháp và nếu ai đó bắt đầu nói nhảm khi trả lời một câu hỏi, việc trả lời: "Bạn không biết mình đang nói về điều gì, phải không?" và biến tất cả thành trò đùa.
Lý tưởng nhất là bạn muốn có một công việc mà bạn có thể luôn cảm thấy hạnh phúc. Sẽ không dễ dàng, không phải ngày nào cũng nắng đẹp, đôi khi bạn cần phải làm việc chăm chỉ, nhưng khi bắt đầu kiểm kê thì bạn sẽ nhận ra: ồ, đây thực sự là một nơi tuyệt vời, tôi cảm thấy rất tốt khi làm việc ở đây, cả về mặt tình cảm và trí tuệ. Và có những công ty mà bạn đến với tư cách là nhà tư vấn và ngay lập tức nhận ra rằng bạn không thể chịu đựng được trong ba tháng và sẽ bỏ chạy trong nỗi kinh hoàng. Đây là điều tôi muốn nói đến trong báo cáo.
Tim Lister sẽ đến với bài phát biểu quan trọng tới hội nghị DevOops 2019 sẽ diễn ra vào ngày 29-30 tháng 2019 năm XNUMX tại St. Petersburg. Bạn có thể mua vé . Chúng tôi đang chờ đợi bạn tại DevOops!
Nguồn: www.habr.com