Dành riêng cho người quản lý dự án (và những người mơ ước trở thành ông chủ).
Viết hàng tấn mã đã khó, nhưng quản lý con người còn khó hơn! Vì vậy, bạn chỉ cần cuốn sách này để học cách làm cả hai điều đó.
Có thể kết hợp những câu chuyện hài hước và những bài học nghiêm túc? Michael Lopp (còn được gọi trong giới hạn hẹp là Rands) đã thành công. Bạn sẽ tìm thấy những câu chuyện hư cấu về những con người hư cấu với những trải nghiệm vô cùng bổ ích (mặc dù là hư cấu). Đây là cách Rands chia sẻ những kinh nghiệm đa dạng, đôi khi kỳ lạ của mình có được qua nhiều năm làm việc tại các tập đoàn CNTT lớn: Apple, Pinterest, Palantir, Netscape, Symantec, v.v.
Bạn có phải là người quản lý dự án? Hoặc muốn hiểu ông chủ chết tiệt của bạn làm gì cả ngày? Rands sẽ dạy bạn cách sống sót trong Thế giới độc hại của những con gà tây bị thổi phồng và phát triển trong cơn điên loạn chung của những người khoa trương rối loạn chức năng. Trong cộng đồng kỳ lạ của những kẻ điên cuồng này thậm chí còn có những sinh vật xa lạ - những người quản lý, thông qua một nghi thức tổ chức thần bí, đã giành được quyền lực đối với các kế hoạch, suy nghĩ và tài khoản ngân hàng của nhiều người.
Cuốn sách này không giống bất kỳ bản thảo lãnh đạo hay quản lý nào. Michael Lopp không giấu giếm gì cả, anh ấy chỉ kể như thế thôi (có lẽ không phải chuyện nào cũng nên công khai đâu :P). Nhưng chỉ bằng cách này, bạn mới hiểu được cách sống sót với một ông chủ như vậy, cách quản lý những kẻ lập dị và mọt sách cũng như cách đưa “dự án chết tiệt đó” đến một kết thúc có hậu!
Trích đoạn. Tâm lý kỹ thuật
Suy nghĩ về: Bạn có nên tiếp tục viết mã không?
Cuốn sách về các quy tắc dành cho nhà quản lý của Rands chứa một danh sách rất ngắn về những “việc phải làm” trong quản lý hiện đại. Tính ngắn gọn của danh sách này bắt nguồn từ thực tế rằng khái niệm “phải” là một loại tuyệt đối, và khi nói đến con người thì có rất ít khái niệm tuyệt đối. Một phương pháp quản lý thành công đối với một nhân viên sẽ là một thảm họa thực sự đối với một nhân viên khác. Suy nghĩ này là mục đầu tiên trong danh sách “phải làm” của người quản lý:
Luôn linh hoạt!
Nghĩ rằng bạn đã biết tất cả mọi thứ là một ý tưởng rất tồi tệ. Trong tình huống mà thực tế bất biến duy nhất là thế giới không ngừng thay đổi, thì sự linh hoạt sẽ trở thành vị trí đúng đắn duy nhất.
Nghịch lý thay, mục thứ hai trong danh sách lại cứng nhắc một cách đáng ngạc nhiên. Tuy nhiên, đây là điểm mà cá nhân tôi thích nhất vì tôi tin rằng nó giúp tạo nền tảng cho sự phát triển về mặt quản lý. Đoạn này viết:
Dừng viết mã!
Về lý thuyết, nếu muốn trở thành người quản lý, bạn phải học cách tin tưởng những người làm việc cho mình và giao toàn bộ mã hóa cho họ. Lời khuyên này thường khó tiếp thu, đặc biệt đối với những nhà quản lý mới vào nghề. Có lẽ một trong những lý do khiến họ trở thành nhà quản lý là vì năng suất phát triển của họ và khi có sự cố xảy ra, phản ứng đầu tiên của họ là quay trở lại với những kỹ năng mà họ hoàn toàn tin tưởng, đó là khả năng viết mã.
Khi tôi thấy một người quản lý mới “chìm” viết mã, tôi nói với anh ta: “Chúng tôi biết rằng bạn có thể viết mã. Câu hỏi là: bạn có thể lãnh đạo không? Bạn không còn chịu trách nhiệm cho một mình mình nữa, bạn chịu trách nhiệm cho cả tập thể; và tôi muốn đảm bảo rằng bạn có thể yêu cầu nhóm của mình tự giải quyết vấn đề mà không cần phải tự viết mã. Công việc của bạn là tìm ra cách mở rộng quy mô bản thân. Tôi không muốn bạn chỉ là một, tôi muốn có nhiều người giống bạn ”.
Lời khuyên tốt, phải không? Tỉ lệ. Sự quản lý. Trách nhiệm. Những từ thông dụng phổ biến như vậy. Thật đáng tiếc là lời khuyên đó đã sai.
Không đúng?
Vâng. Lời khuyên là sai lầm! Không hoàn toàn sai, nhưng sai đến mức tôi phải gọi điện cho một số đồng nghiệp cũ và xin lỗi: “Bạn có nhớ câu nói yêu thích của tôi về việc bạn nên ngừng viết mã như thế nào không? Nó sai! Có... Bắt đầu lập trình lại. Bắt đầu với Python và Ruby. Vâng tôi rất nghiêm túc! Sự nghiệp của bạn phụ thuộc vào nó!
Khi tôi bắt đầu sự nghiệp với tư cách là nhà phát triển phần mềm tại Borland, tôi đã làm việc trong nhóm Paradox Windows, một nhóm rất lớn. Chỉ riêng có 13 nhà phát triển ứng dụng. Nếu bạn thêm những người từ các nhóm khác, những người cũng thường xuyên làm việc trên các công nghệ chính cho dự án này, chẳng hạn như công cụ cơ sở dữ liệu cốt lõi và các dịch vụ ứng dụng cốt lõi, thì bạn sẽ có 50 kỹ sư trực tiếp tham gia vào việc phát triển sản phẩm này.
Không có nhóm nào khác mà tôi từng làm việc có quy mô gần như vậy. Trên thực tế, mỗi năm trôi qua, số người trong nhóm tôi làm việc đang giảm dần. Chuyện gì đang xảy ra vậy? Có phải các nhà phát triển của chúng ta đang ngày càng thông minh hơn không? Không, chúng tôi chỉ đang chia sẻ gánh nặng thôi.
Các nhà phát triển đã làm gì trong 20 năm qua? Trong thời gian này, chúng tôi đã viết rất nhiều mã. Biển mã! Chúng tôi đã viết nhiều mã đến mức chúng tôi quyết định sẽ là một ý tưởng hay nếu đơn giản hóa mọi thứ và chuyển sang sử dụng nguồn mở.
May mắn thay, nhờ có Internet, quá trình này giờ đây đã trở nên đơn giản nhất có thể. Nếu bạn là nhà phát triển phần mềm, bạn có thể kiểm tra ngay bây giờ! Tìm kiếm tên của bạn trên Google hoặc Github và bạn sẽ thấy đoạn mã mà bạn đã quên từ lâu nhưng bất kỳ ai cũng có thể tìm thấy. Đáng sợ phải không? Bạn không biết rằng mã đó tồn tại mãi mãi sao? Vâng, anh ấy sống mãi mãi.
Mã này tồn tại mãi mãi. Và mã tốt không chỉ tồn tại mãi mãi mà còn phát triển bởi vì những người coi trọng nó luôn đảm bảo rằng nó luôn mới. Đống mã chất lượng cao, được bảo trì tốt này giúp giảm quy mô nhóm kỹ thuật trung bình vì nó cho phép chúng tôi tập trung vào mã hiện có thay vì viết mã mới và hoàn thành công việc với ít người hơn và trong khung thời gian ngắn hơn.
Dòng lý luận này nghe có vẻ chán nản, nhưng ý tưởng là tất cả chúng ta chỉ là một nhóm các máy tự động tích hợp sử dụng băng keo để kết nối các phần khác nhau của những thứ hiện có với nhau để tạo ra một phiên bản hơi khác của cùng một thứ. Đây là lối suy nghĩ kinh điển của các giám đốc điều hành cấp cao yêu thích gia công phần mềm. “Bất cứ ai biết cách sử dụng Google và có băng dính đều có thể làm được việc này! Vậy tại sao chúng ta lại phải trả nhiều tiền cho máy móc của mình?”
Chúng tôi trả cho những người quản lý này số tiền rất lớn, nhưng họ lại nghĩ những điều vô nghĩa như vậy. Một lần nữa, điểm mấu chốt của tôi là có rất nhiều nhà phát triển tài giỏi và làm việc rất chăm chỉ trên hành tinh của chúng ta; họ thực sự xuất sắc và siêng năng, mặc dù họ chưa từng dành một phút nào ngồi trong các trường đại học được công nhận. Ồ vâng, bây giờ ngày càng có nhiều người như vậy!
Tôi không khuyên bạn nên bắt đầu lo lắng về vị trí của mình chỉ vì một số đồng đội xuất sắc được cho là đang săn lùng nó. Tôi khuyên bạn nên bắt đầu lo lắng về điều đó vì sự phát triển của phát triển phần mềm có thể đang diễn ra nhanh hơn bạn. Bạn đã làm việc được mười năm, năm trong số đó là người quản lý, và bạn nghĩ: “Tôi đã biết phần mềm được phát triển như thế nào.” Vâng, bạn biết đấy. Tạm biệt…
Hãy ngừng viết mã, nhưng...
Nếu bạn làm theo lời khuyên ban đầu của tôi và ngừng viết mã, bạn cũng sẽ tự nguyện ngừng tham gia vào quá trình sáng tạo. Chính vì lý do này mà tôi không tích cực sử dụng outsourcing. Automata không tạo ra, họ sản xuất. Các quy trình được thiết kế tốt sẽ tiết kiệm được rất nhiều tiền nhưng chúng không mang lại điều gì mới mẻ cho thế giới của chúng ta.
Nếu bạn có một nhóm nhỏ làm rất nhiều việc với số tiền ít, thì đối với tôi, ý tưởng ngừng viết mã có vẻ là một quyết định tồi tệ trong sự nghiệp. Ngay cả ở những công ty quái vật với vô số quy định, quy trình và chính sách, bạn không có quyền quên cách tự mình phát triển phần mềm. Và sự phát triển phần mềm luôn thay đổi. Nó đang thay đổi ngay bây giờ. Dưới chân bạn! Ngay lúc này!
Bạn có sự phản đối. Hiểu. Hãy lắng nghe.
“Rands, tôi đang trên đường tới ghế giám đốc! Nếu tôi cứ viết mã, sẽ không ai tin rằng tôi có thể trưởng thành.”
Tôi muốn hỏi bạn điều này: kể từ khi bạn ngồi vào chiếc ghế “Tôi sắp trở thành CEO!”, bạn có nhận thấy rằng bối cảnh phát triển phần mềm đang thay đổi, ngay cả trong công ty của bạn không? Nếu câu trả lời của bạn là có thì tôi sẽ hỏi bạn một câu hỏi khác: chính xác thì nó đang thay đổi như thế nào và bạn sẽ làm gì với những thay đổi này? Nếu bạn trả lời “không” cho câu hỏi đầu tiên của tôi, thì bạn cần phải chuyển sang một chiếc ghế khác, bởi vì (tôi cá là!) lĩnh vực phát triển phần mềm đang thay đổi ngay lúc này. Làm sao bạn có thể phát triển nếu bạn dần dần quên mất cách phát triển phần mềm?
Lời khuyên của tôi là đừng cam kết triển khai hàng loạt tính năng cho sản phẩm tiếp theo của bạn. Bạn cần liên tục thực hiện các bước để luôn cập nhật cách nhóm của bạn xây dựng phần mềm. Bạn có thể làm điều này với tư cách là giám đốc và phó chủ tịch. Thứ gì khác?
“Ồ, Rands! Nhưng phải có ai đó làm trọng tài! Ai đó phải nhìn thấy bức tranh lớn. Nếu tôi viết mã, tôi sẽ mất đi quan điểm.”
Bạn vẫn phải là trọng tài, bạn vẫn phải phát sóng các quyết định và bạn vẫn phải đi bộ quanh tòa nhà bốn lần vào mỗi sáng thứ Hai cùng với một trong các kỹ sư của bạn để nghe câu nói hàng tuần "Tất cả chúng ta đều phải chịu số phận" trong suốt 30 phút. phút. ! Nhưng ngoài tất cả những điều đó, bạn phải duy trì tư duy kỹ thuật và bạn không cần phải là lập trình viên toàn thời gian để làm điều đó.
Lời khuyên của tôi để duy trì tư duy kỹ thuật:
- Sử dụng môi trường phát triển. Điều này có nghĩa là bạn phải làm quen với các công cụ của nhóm mình, bao gồm hệ thống xây dựng mã, kiểm soát phiên bản và ngôn ngữ lập trình. Kết quả là bạn sẽ trở nên thông thạo ngôn ngữ mà nhóm của bạn sử dụng khi nói về việc phát triển sản phẩm. Điều này cũng sẽ cho phép bạn tiếp tục sử dụng trình soạn thảo văn bản yêu thích của mình, trình soạn thảo này đang hoạt động hoàn hảo.
- Bạn phải có khả năng vẽ sơ đồ kiến trúc chi tiết mô tả sản phẩm của mình trên bất kỳ bề mặt nào vào bất kỳ lúc nào. Bây giờ ý tôi không phải là phiên bản đơn giản hóa với ba ô và hai mũi tên. Bạn phải biết sơ đồ chi tiết của sản phẩm. Điều khó khăn nhất. Không chỉ là một sơ đồ dễ thương mà còn là một sơ đồ khó giải thích. Nó phải là một bản đồ phù hợp để hiểu đầy đủ về sản phẩm. Nó liên tục thay đổi và bạn phải luôn biết tại sao lại xảy ra những thay đổi nhất định.
- Đảm nhận việc thực hiện một trong các chức năng. Tôi thực sự nhăn mặt khi viết điều này vì điểm này có rất nhiều mối nguy hiểm tiềm ẩn, nhưng tôi thực sự không chắc chắn rằng bạn có thể đạt được điểm số 1 và điểm số 2 mà không cam kết triển khai ít nhất một tính năng. Bằng cách tự mình triển khai một trong các tính năng, bạn không chỉ tích cực tham gia vào quá trình phát triển mà còn cho phép bạn chuyển đổi định kỳ từ vai trò “Người quản lý phụ trách mọi việc” sang vai trò “Người phụ trách triển khai một tính năng”. của các chức năng.” Thái độ khiêm tốn và khiêm tốn này sẽ nhắc nhở bạn về tầm quan trọng của những quyết định nhỏ.
- Tôi vẫn còn run rẩy khắp người. Có vẻ như ai đó đã hét vào mặt tôi: "Người quản lý đã tự mình thực hiện chức năng ?!" (Và tôi đồng ý với anh ấy!) Vâng, bạn vẫn là người quản lý, có nghĩa là đó chỉ là một chức năng nhỏ nào đó thôi, được chứ? Vâng, bạn vẫn còn nhiều việc phải làm. Nếu bạn không thể đảm nhận việc triển khai chức năng thì tôi có một số lời khuyên dành cho bạn: sửa một số lỗi. Trong trường hợp này, bạn sẽ không cảm nhận được niềm vui sáng tạo, nhưng bạn sẽ hiểu được cách tạo ra sản phẩm, điều đó có nghĩa là bạn sẽ không bao giờ bị bỏ việc.
- Viết bài kiểm tra đơn vị. Tôi vẫn làm việc này vào cuối chu kỳ sản xuất khi mọi người bắt đầu phát điên. Hãy coi nó như một danh sách kiểm tra sức khỏe cho sản phẩm của bạn. Làm điều này thường xuyên.
Phản đối nữa à?
“Rands, nếu tôi viết mã, tôi sẽ khiến nhóm của mình bối rối. Họ sẽ không biết tôi là ai – người quản lý hay nhà phát triển.”
Được rồi.
Vâng, tôi nói, "Được rồi!" Tôi rất vui vì bạn nghĩ rằng bạn có thể khiến nhóm của mình bối rối chỉ bằng cách bơi trong ao của nhà phát triển. Thật đơn giản: ranh giới giữa các vai trò khác nhau trong phát triển phần mềm hiện rất mờ nhạt. Những người làm giao diện người dùng thực hiện những gì có thể gọi rộng rãi là lập trình JavaScript và CSS. Các nhà phát triển đang ngày càng tìm hiểu nhiều hơn về thiết kế trải nghiệm người dùng. Mọi người giao tiếp với nhau và tìm hiểu về các lỗi, về hành vi trộm cắp mã của người khác, cũng như về thực tế là không có lý do chính đáng nào để người quản lý không tham gia vào hoạt động trao đổi thông tin chéo, toàn cầu, khổng lồ này.
Ngoài ra, bạn có muốn trở thành thành viên của một nhóm bao gồm các thành phần dễ dàng thay thế không? Điều này không chỉ giúp nhóm của bạn nhanh nhẹn hơn mà còn mang lại cho mỗi thành viên trong nhóm cơ hội nhìn nhận sản phẩm và công ty từ nhiều góc độ khác nhau. Làm thế nào bạn có thể tôn trọng Frank, người điềm tĩnh phụ trách các bản dựng, hơn là sau khi nhìn thấy sự sang trọng đơn giản trong các kịch bản bản dựng của anh ấy?
Tôi không muốn nhóm của bạn trở nên bối rối và hỗn loạn. Ngược lại, tôi muốn nhóm của bạn giao tiếp hiệu quả hơn. Tôi tin rằng nếu bạn tham gia vào việc tạo ra sản phẩm và phát triển các tính năng, bạn sẽ gần gũi hơn với nhóm của mình. Và quan trọng hơn, bạn sẽ tiến gần hơn đến những thay đổi liên tục trong quá trình phát triển phần mềm trong tổ chức của mình.
Không ngừng phát triển
Một đồng nghiệp của tôi ở Borland đã từng tấn công tôi bằng lời nói vì gọi cô ấy là “lập trình viên”.
“Rands, lập trình viên là một cỗ máy không có trí óc! Con khỉ! Người lập trình không làm bất cứ điều gì quan trọng ngoại trừ việc viết những dòng mã nhàm chán vô dụng. Tôi không phải là lập trình viên, tôi là nhà phát triển phần mềm!”
Cô ấy đã đúng, cô ấy sẽ ghét lời khuyên ban đầu của tôi dành cho các CEO mới: “Hãy ngừng viết mã!” Không phải vì tôi gợi ý rằng họ là lập trình viên, mà hơn thế nữa bởi vì tôi chủ động gợi ý rằng họ bắt đầu bỏ qua một trong những phần quan trọng nhất trong công việc của mình: phát triển phần mềm.
Vì vậy, tôi đã cập nhật lời khuyên của mình. Nếu bạn muốn trở thành một nhà lãnh đạo giỏi, bạn có thể ngừng viết mã, nhưng...
Được linh hoạt. Hãy nhớ ý nghĩa của việc trở thành một kỹ sư và không ngừng phát triển phần mềm.
Thông tin về các Tác giả
Michael Lopp là một nhà phát triển phần mềm kỳ cựu vẫn chưa rời Thung lũng Silicon. Trong 20 năm qua, Michael đã làm việc cho nhiều công ty đổi mới, bao gồm Apple, Netscape, Symantec, Borland, Palantir, Pinterest, đồng thời cũng tham gia vào một công ty khởi nghiệp đang dần chìm vào quên lãng.
Ngoài công việc, Michael điều hành một blog nổi tiếng về công nghệ và quản lý dưới bút danh Rands, nơi anh thảo luận các ý tưởng trong lĩnh vực quản lý với độc giả, bày tỏ mối quan ngại về nhu cầu thường xuyên theo dõi nhịp đập của mình và giải thích rằng, bất chấp những phần thưởng hậu hĩnh cho việc tạo ra một sản phẩm, thành công của bạn chỉ có được nhờ vào nhóm của bạn. Blog có thể được tìm thấy ở đây .
Michael sống cùng gia đình ở Redwood, California. Anh ấy luôn dành thời gian để đạp xe leo núi, chơi khúc côn cầu và uống rượu vang đỏ, vì sức khỏe quan trọng hơn sự bận rộn.
» Thông tin chi tiết về cuốn sách có thể tìm thấy tại
»
»
Đối với Khabrozhiteley giảm giá 20% khi sử dụng phiếu giảm giá - Quản lý con người
Sau khi thanh toán cho phiên bản giấy của cuốn sách, phiên bản điện tử của cuốn sách sẽ được gửi qua e-mail.
PS: 7% giá sách sẽ dành cho việc dịch sách máy tính mới, danh sách sách bàn giao cho nhà in .
Nguồn: www.habr.com