Tôi có thể hiểu áp lực lịch trình. Bạn muốn làm hài lòng người dùng của mình, vì họ là huyết mạch của công ty. Tuy nhiên, cũng đúng là một số thay đổi nhất định sẽ giúp mọi thứ dễ dàng hơn. Thật không may, quản lý trong tổ chức của tôi có một sự phản kháng theo bản năng đối với những thay đổi như vậy và sự kháng cự này mạnh đến mức nó cản trở những cải tiến dài hạn.

Ví dụ: Apple gần đây đã giới thiệu Đếm tham chiếu tự động cho các chương trình iOS. Đây là một cải tiến lớn so với các cuộc gọi giữ / phát hành thủ công mà trước đây phải sử dụng. Mã dễ viết hơn và dễ bảo trì hơn. Sự thay đổi chính nó có khả năng tạo ra một số sự cố. Nhưng một khi chúng được xử lý, số vụ tai nạn kỳ lạ ngẫu nhiên có thể sẽ giảm.

Gần đây tôi đã đề cập với sếp của mình rằng tôi muốn chuyển sang đếm tham chiếu tự động. Phản ứng của anh ấy là anh ấy muốn tập trung vào những cải tiến có thể nhìn thấy. Có khả năng là phản ứng này lần lượt được thúc đẩy bởi áp lực mà anh ta đang nhận được từ phía trên anh ta - và có lẽ ngay từ CEO.

Có rất nhiều ví dụ tương tự. Chủ đề chung là một cái gì đó cần phải được sửa chữa nhưng chi phí ngắn hạn của việc sửa chữa lớn hơn lợi ích ngắn hạn, trong đó "ngắn hạn" được định nghĩa là "trong vài tuần tới."

Tôi nên xử lý tình huống như thế nào?

EDIT: Cảm ơn bạn đã phản hồi. Hãy tiếp tục đến. Bởi vì nó có liên quan đến tình huống của tôi, tôi nên nói rõ rằng người quản lý và CEO của tôi đều là lập trình viên - mặc dù bây giờ CEO có thể đã quên mất điều này là như thế nào. Rõ ràng phía lập trình viên của họ đã bị áp đảo bởi các áp lực khác.

Bạn đang thực sự nói về nợ kỹ thuật. Có lẽ một phép ẩn dụ sẽ giúp các nhà quản lý của bạn. Tôi thường so sánh ảnh hưởng của nợ kỹ thuật trong phần mềm với nấu ăn trong bếp bẩn. Nếu bồn rửa và quầy và bếp được chất đầy bát đĩa bẩn và có rác trên sàn nhà, sẽ mất nhiều thời gian hơn để làm một bữa ăn. Tuy nhiên, cách nhanh nhất để chuẩn bị bữa ăn tiếp theo là làm việc xung quanh mớ hỗn độn. Làm sạch nhà bếp, và giữ cho nó sạch sẽ, sẽ trì hoãn bữa ăn tiếp theo, nhưng sẽ cải thiện việc cung cấp tất cả các bữa ăn tiếp theo. Và cũng giống như người đói trong phòng ăn không thể nhìn thấy nhà bếp bừa bộn và không hiểu tại sao bạn muốn dọn dẹp trước khi bắt đầu nấu ăn, quản lý của bạn không thể thấy sự lộn xộn trong mã. Bạn cần phải cho họ thấy sự lộn xộn, hoặc cho thấy các vấn đề chất lượng và sự chậm trễ gây ra bởi sự lộn xộn.

Có lẽ bạn cũng có thể nói về các nhiệm vụ khẩn cấp và các nhiệm vụ quan trọng. Khi các nhiệm vụ quan trọng không được thực hiện, thì các nhiệm vụ khẩn cấp sẽ mất nhiều thời gian hơn và tốn kém hơn.

Bạn đã vấp phải điều gì đó khiến các lập trình viên gặp khó khăn ở mọi nơi tại một số điểm trong sự nghiệp của họ: mã này cần phải được cấu trúc lại, có những vấn đề về kiến ​​trúc ở đó, mô-đun này đang trở nên không thể hiểu được, v.v. bạn đang bị thúc đẩy tập trung vào công việc chỉ mang lại lợi ích trực tiếp có thể nhìn thấy .

Đó là Iceberg Secret cổ điển một lần nữa. Bí mật liên quan đến thực tế là giống như một tảng băng chìm 90% dưới nước, do đó, phần lớn của bất kỳ dự án phát triển nào : 90% công việc sẽ hoàn toàn vô hình với người dùng cuối. Mã đó sẽ có tác động đến người dùng cuối nhưng ban quản lý gặp khó khăn trong việc giải thích lý do tại sao bạn mất sáu giờ để cấu trúc lại các cuộc gọi duy trì / phát hành và tham chiếu tự động khi họ không thể thấy bất kỳ sự khác biệt nào và mọi thứ đều hoạt động tốt.

Dưới đây là một số sự thật bạn có thể mang theo bên mình về vấn đề này.

• Quản lý, trừ khi chính họ là lập trình viên , sẽ không hiểu Bí mật Iceberg.
• Đây là một vấn đề của sự thiếu hiểu biết, không có ác ý. Giám đốc điều hành muốn có một sản phẩm tốt - anh ta không hiểu mọi thứ đi vào một sản phẩm tốt.
• Giám đốc điều hành (và ông chủ trực tiếp của bạn) không ngu ngốc - nghiên cứu và chuẩn bị một số sự kiện và một số dữ liệu cụ thể về lý do tại sao bạn nên dành thời gian cho việc này và các vấn đề khác của Iceberg.

Đừng quên - bạn là một người đàn ông của công ty (hoặc phụ nữ). Không phải là một người đàn ông mã. Bạn đang phát triển sản phẩm này cho một công ty có quyền lợi về thành công hay thất bại của nó - các dự án và đề xuất dự án của bạn sẽ phản ánh điều này. Thể hiện niềm đam mê của bạn đối với công ty và sản phẩm, thể hiện kiến ​​thức của bạn và chứng minh với sếp và CEO của bạn rằng họ nên tin tưởng bạn khi bạn đến với họ và nói rằng Cần gì đó làm việc. Chỉ cho họ cách nó sẽ đóng góp vào điểm mấu chốt - cho dù bằng cách thêm giá trị cho sản phẩm (nhiều người mua bản sao hơn) hoặc bằng cách tiết kiệm thời gian xuống đường (ít khách hàng tức giận hơn khi sản phẩm của bạn thất bại).

Bạn không.

Tôi thấy câu hỏi này và tất cả các câu hỏi giống như một chút ngõ cụt. Bạn không thể "thuyết phục" mọi người. Nếu họ chưa nhận thức được những điều như thế này hoặc điều tra nó, rất có thể họ sẽ không lật lại. Và không có lượng dữ liệu sẽ thuyết phục họ bằng cách khác. Thay đổi phải đến từ bên trong. Bạn có thể dẫn một con ngựa xuống nước nhưng bạn không thể bắt nó uống.

Tôi nói nướng những thay đổi mong muốn của bạn vào các ước tính kỹ thuật tiếp theo của bạn. Hãy như, hey, chúng tôi "phải" nâng cấp lên khuôn khổ mới này được Apple giới thiệu. Đừng để không sử dụng ARC trên lộ trình của bạn. Không có lựa chọn nào; di chuyển đến ARC là cách duy nhất.

Tôi đã trả lời một câu hỏi tương tự ở đây trước đây để điều này có thể được coi là một bản sao. Về cơ bản, bạn sẽ không nhận được tín hiệu để thực hiện "nỗ lực tái cấu trúc". Cách bạn làm cho mã sạch hơn là tuân theo quy tắc trinh sát của cậu bé: luôn để lại mã sạch hơn khi bạn rời khỏi mã hơn khi bạn đến.

Giống như trả hết nợ thực sự có vẻ như là một nhiệm vụ không thể vượt qua (hoặc dọn dẹp một ngôi nhà bừa bộn). Bí quyết là làm cho nó tốt hơn từng mảnh cho đến khi bạn bắt đầu thấy "đảo sạch". Khi bạn có động lực đáng kể, các nhà phát triển khác trong nhóm sẽ bắt đầu nhận thấy và cuối cùng đóng góp cho nhiệm vụ.

Tôi khuyên bạn nên đọc Bộ giải mã sạch của "Chú" Bob Martin. Viết mã tốt là một phần công việc của bạn. Bạn không xin phép làm công việc của bạn, bạn chỉ cần làm điều đó.

Cũng như các câu hỏi khác có tính chất này, bạn cần cung cấp những con số mà ban quản lý sẽ hiểu. Các con số cho thấy sẽ tiết kiệm được bao nhiêu thời gian bằng cách thực hiện các cải tiến này, có bao nhiêu "sự cố kỳ lạ ngẫu nhiên" sẽ xảy ra, v.v.

Bạn cũng có thể cố gắng thực hiện những cải tiến này vào thời gian riêng của mình (tức là ngoài giờ làm việc) và sau đó hiển thị lợi ích cho quản lý sau đó. Tôi sẽ chỉ làm điều này khi rõ ràng rằng quản lý không hiểu những gì bạn đang cố gắng truyền đạt và / hoặc họ không muốn phân bổ thời gian để bạn thậm chí thử nó.

Chúc may mắn!

Trình bày một trường hợp kinh doanh

Có nhiều lý do tại sao các khuyến nghị kỹ sư thường bị bỏ qua. Cách tốt nhất để giải quyết gần như tất cả các lý do là trình bày trường hợp kinh doanh về lý do tại sao nó nên được thực hiện. Phân tích chi phí / lợi ích cổ điển. Điều này không chỉ tạo ra một cuộc tranh luận hấp dẫn mà còn mang đến cho sếp của bạn một thứ gì đó để đưa lên cấp trên của họ.

• Chi phí trả trước là gì?
• Chi phí liên tục là gì?
• Tiền tiết kiệm / thời gian dự kiến ​​là gì và chúng đến từ đâu?
• Sẽ mất bao lâu trước khi chúng ta thấy ROI?

Khi thực hiện một trường hợp kinh doanh, bạn phải luôn sao lưu đối số của mình bằng dữ liệu.

• Bao nhiêu thời gian phát triển hiện đang dành để xử lý các vấn đề này sẽ loại bỏ hoặc giảm thiểu?
• Có bao nhiêu khiếu nại của người dùng mà bạn nhận được liên quan đến các vấn đề này sẽ loại bỏ hoặc giảm thiểu?
• Nó sẽ có những lợi ích nào khác?

Sắp xếp các số và làm cho nó một phương trình thô, nhưng đơn giản. Nó sẽ tốn X để làm và nó sẽ có lợi cho công ty Y.

Lưu ý: Đừng ngạc nhiên nếu việc thực hiện một ý tưởng tốt về mặt học thuật là rất tốn kém.

Đây là một loại thay đổi rơi vào loại tái cấu trúc. Cách tiếp cận Agile sẽ là bạn nên kết hợp thời gian tái cấu trúc AMPLE vào mỗi câu chuyện mà bạn ước tính và đây chính xác là lý do. Ngoài các kỹ sư, không ai sẽ hiểu lý do tại sao bạn muốn làm điều này và điều đó không sao, đó không phải là công việc CỦA HỌ để xác định cách viết mã chính xác, đó là của bạn.

Vì vậy, lần tới khi bạn có một khối lượng công việc phải làm, hãy chắc chắn rằng những thay đổi này là một phần của nó. Nếu bạn đang cung cấp các ước tính, hãy chắc chắn thêm 30% vào ước tính của bạn để tái cấu trúc, nếu bạn không cung cấp các ước tính thì chỉ cần thực hiện tái cấu trúc như một phần công việc của bạn.

Nó có thể làm cho bạn chậm hơn - à không, đó không phải là cách để nhìn nó, cách để nhìn nó là vận tốc hiện tại của bạn chỉ là ảo ảnh, về cơ bản là một lời nói dối mà bạn đang vượt qua chuỗi, bạn thực sự nên là một chậm hơn một chút vì công việc này mà bạn biết cần phải hoàn thành.

Bạn có thể có thể xây nhà nhanh hơn nếu bạn không sử dụng bê tông làm nền móng - và chúng sẽ có vẻ tốt cho khách hàng nhưng - tốt - Ngay cả khi khách hàng không thấy cần nền móng, nhà xây dựng cần (Đây thực sự là một sự song hành thú vị bởi vì hóa ra các nhà xây dựng không phải lúc nào cũng làm những gì họ biết họ nên làm nên chúng ta cần phải thông qua luật để buộc họ - không có luật nào điều chỉnh việc phát triển phần mềm mặc dù chúng ta phải đối mặt như vậy quyết định và thường đưa ra những sai lầm ...)

Bạn đề cập rằng bạn đủ may mắn rằng người quản lý và CEO của bạn đều là lập trình viên. Vì vậy, họ có thể làm hiểu những gì nợ kỹ thuật.

Bạn nên xử lý tình huống bằng cách cố gắng giải quyết tình huống dựa trên sự thật, điều đó có nghĩa là có khả năng thực sự là bạn sẽ không thực hiện các cải tiến kỹ thuật mà bạn muốn (sự thật có thể gây khó chịu theo cách đó).

Công việc của bạn là đảm bảo họ hiểu các chi phí và lợi ích của việc thanh toán bất kỳ khoản nợ kỹ thuật cụ thể nào mà bạn phải chịu. Công việc của họ là quyết định xem việc sử dụng tài nguyên tốt nhất là trả hết hay làm việc khác.

Cũng giống như những người không liên quan đến mã có thể thấy được lợi ích của việc cải thiện công cụ "ẩn", các lập trình viên khó có thể thấy lợi ích của việc thay đổi mã hiển thị khi lợi ích tích lũy cho các lĩnh vực của doanh nghiệp " ẩn "từ các nhà phát triển.

Thật tuyệt nếu quản lý của bạn có thể giải thích cho bạn lý do tại sao các tính năng hiển thị đáng giá hơn thời gian của bạn hơn là trả nợ kỹ thuật, nhưng thực sự, đó không phải là công việc của bạn để đưa ra quyết định. Vì vậy, giải thích cho bạn không làm được gì nhiều cho việc kinh doanh ngoại trừ giữ cho bạn hạnh phúc. Và theo một cách nào đó, khăng khăng họ làm như vậy là không tin tưởng họ làm công việc của họ. Nếu bạn không thích nó khi họ quản lý bạn thì bạn nên hiểu.

Vì vậy, miễn là bạn giữ cho họ biết về tình trạng của tất cả các khoản nợ kỹ thuật và các chi phí và lợi ích của việc bỏ qua nó so với trả hết, bạn đã hoàn thành công việc của mình. Trừ khi bạn thực sự không tin tưởng quản lý để làm việc của họ, trong trường hợp đó, bạn có một vấn đề lớn hơn nhiều sẽ là một câu hỏi hoàn toàn khác để giải quyết.

Có thể đây không phải là một câu trả lời, nhưng một phản hồi dựa trên những sai lầm tôi đã mắc phải. Cũng là một sự bất đồng với một số triết lý tôi đọc ở đây.

• Đừng tin vào điều mà lập trình viên biết rõ nhất.
• Hãy trung thực. Yếu tố lại khi bạn đi cùng nhưng không nói dối và ước tính cho mục đích riêng của bạn.
• Bạn không sở hữu mã. Đừng đảm nhận công việc không được lãnh đạo chấp thuận.
• Bạn có thể đúng về một cái gì đó; bạn có thể sai ... nhưng bạn nên làm những gì bạn được trả tiền để làm.

Nhưng chắc chắn làm theo lời khuyên tuyệt vời cho việc cải thiện mọi thứ.

Bạn rõ ràng làm việc cho một ông chủ tóc nhọn (PHB). Anh ấy không lập trình nữa, nếu có, và nếu anh ấy làm thì có lẽ anh ấy không thực sự tốt (mặc dù anh ấy thích bỏ đi những cụm từ như "const đúng" và "lỗi phân khúc" để các chàng trai biết rằng anh ấy đã giành được sọc của mình ) - đó là cách anh ấy đã chọn ra để quản lý.

CEO (người thực tế có Mohawk) thích PHB vì PHB cung cấp các tính năng . Mỗi lần chạy nước rút, anh tự hào thể hiện một hộp đánh dấu mới (hơi sai lệch, có nhãn mơ hồ), biểu tượng lấp lánh (chưa hoạt động trong bất kỳ môi trường nào ngoài màu 8 bit so với Citrix) và một hình thức (có sự cố ngẫu nhiên do điều kiện cuộc đua trong biến thể xml bespoke dựa trên C đã triển khai cơ sở dữ liệu cục bộ mà không ai trong nhóm nhà phát triển dám chạm vào vì nó được viết bởi một trong những người bảo vệ cũ truyền thuyết 10 năm trước và thực hiện MỌI THỨ với các macro có 5 tên chữ cái, cho dù họ cần 5 chữ cái hay không phải).

Các lập trình viên thực sự làm "bit công việc" (bạn biết rằng bit đó xảy ra, bất tiện sau khi tất cả các công việc thực sự như vẽ vòng tròn trên bảng trắng, la hét và ăn Battenburgs đã hoàn thành) biết rằng trong một hệ thống lành mạnh , công việc vừa mới thực hiện 10 chàng trai 10 ngày để lao ra khỏi khu rừng rậm không xác định, có lẽ sẽ lên tới một hoặc hai ngày, kể cả thử nghiệm. Nhưng để có được hệ thống từ nơi mà nó lành mạnh có thể mất 6 tháng làm việc thực sự khó khăn, với rất ít cách thức thưởng bên ngoài rõ ràng.

PHB biết rằng trong 6 tháng, bằng cách móc hoặc bằng kẻ gian, anh ta có thể nhận được ba mươi hoặc bốn mươi tính năng mới vào ứng dụng mà nhân viên bán hàng (phải là pháp sư đưa ra những gì họ thực sự bán) có thể được sử dụng để cám dỗ mua hàng và nâng cấp mới .

Tuy nhiên, để cung cấp cho PHB các khoản phí của mình: nếu không có các hộp đánh dấu và hình thức bán hàng có thể bị đình trệ hoặc suy giảm, một đối thủ cạnh tranh có thể giành được thị phần, và điều đó có thể tồi tệ hơn so với giải pháp thay thế.

Kết luận mà tôi đã đưa ra là cách duy nhất thoát khỏi vũng lầy là làm việc trong một công ty mới thành lập, với một vài người chia sẻ tầm nhìn của bạn về cách phần mềm nên được thực hiện và sau đó kiên định tuân theo triết lý đó (Tôi Tôi vẫn đang làm việc ở đó!)

Có một chi phí ẩn khác không được đề cập trong các câu trả lời khác. Cụ thể là các kỹ sư giỏi có xu hướng rời đi trong loại môi trường được mô tả. Cuối cùng, bất cứ ai có tham vọng hoặc khả năng tái cấu trúc đã rời khỏi công ty, và sau đó mọi thứ sẽ diễn ra theo chiều hướng rất xấu, có thể là không thể trộn lẫn. Thật không may, bạn không thể nói với người quản lý của mình điều này mà không gặp phải sự kiêu ngạo ("Tôi là một trong những lập trình viên giỏi nhất của bạn") và một người khó tính ("Tôi sẽ rời đi nếu bạn không làm những gì tôi muốn"). Tuy nhiên, hãy nhớ đề cập đến nó trong cuộc phỏng vấn xuất cảnh của bạn, để đảm bảo bạn không bị tình trạng thuê lại.

Bạn vừa đúng vừa sai, đó là lý do tại sao những vấn đề đó tồn tại lâu dài và tạo ra cảm giác khó khăn.

Những lý do tại sao được nêu rõ ở trên: quản lý nghĩ bằng tiền; hoặc thậm chí cụ thể hơn: doanh thu. Đối với họ một cái gì đó có chi phí nhưng không có khả năng hiển thị trực tiếp cho khách hàng sẽ không thêm doanh thu nên đó là một kế hoạch tồi.

Tầm nhìn của bạn cũng đúng: nó sẽ tốt cho khách hàng nhưng về lâu dài. Hành động của bạn có thể tạo ra doanh thu thậm chí còn lớn hơn trong tương lai so với các kế hoạch ngắn hạn.

Bạn không phải là người quản lý, bạn không phải là người trực tiếp chịu trách nhiệm về doanh thu (tất nhiên tôi giả sử). Vì vậy, bạn đang trộn lẫn (đó là cảm giác của quản lý) với các vấn đề của họ và bạn không tập trung vào công việc của mình: tiếp tục mở rộng phần mềm.

Tất cả các từ khó, rõ ràng nhưng đó là cách mà hầu hết các vấn đề phát sinh, do lỗi giao tiếp. Cả hai bạn đều muốn điều tương tự nhưng các quyết định ngắn hạn của bạn được đưa ra khác nhau. Tất cả vì nhà phát triển có một triển vọng khác so với người quản lý.

Làm thế nào để bạn giải quyết vấn đề này? Bạn giao tiếp và hiểu nhau khá tốt về một số vấn đề. Đó sẽ là trọng tâm của sự tham gia và sự hài lòng của khách hàng rất có thể.

Để giải quyết vấn đề này theo phương pháp chứng minh ổn định và trong tương lai, hãy đồng ý về một số điều: đo lường chi phí sửa lỗi trong mã cũ. Đo thời gian cần thiết để làm việc với phần mềm cũ và cách thức hoạt động với cơ sở mã mới.

Để chứng minh điều này bạn có thể làm ví dụ điều này khá đơn giản: phân nhánh phần mềm trong phiên bản của bạn. Đầu tiên làm những gì quản lý muốn, vì vậy hãy tạo ra tính năng đó. Bạn làm điều này nhưng thỏa thuận là bạn có thời gian để thể hiện cách khác nhau. Sau đó, làm điều tương tự trong nhánh mới nhưng trước tiên hãy khắc phục các vấn đề bạn muốn thoát khỏi. Rồi cũng phát triển giải pháp.

Bây giờ bạn có cùng một giải pháp nhưng hoàn toàn phát triển khác nhau. Tạo một trường hợp từ nó, đặt các giải pháp cạnh nhau bao gồm một số thông tin quản lý như tính ổn định, số lượng mã cần thiết và chính mã.

Bây giờ hãy cùng nhau uống cà phê và bắt đầu xem xét, không tranh luận ai đúng nhưng điều gì sẽ là ảnh hưởng của cả hai hướng cho công ty. Điều đó sẽ tạo ra một cuộc họp thực sự hữu ích và không phải là một cuộc thảo luận tồi tệ hơn bởi vì điều đó sẽ không tạo ra bầu không khí mà cả hai bạn sẽ cần. Điều đó sẽ không làm cho sản phẩm của bạn tốt hơn.

Nếu bạn có đánh giá mã, hãy tạo một vé kỹ thuật cho biết mã cần được cải thiện bằng cách sử dụng ARC và gán cho người quản lý.

Thuyết phục anh ta. Giải thích cho anh ta một số ví dụ nhỏ về các cải tiến kỹ thuật tương tự mà bạn đã làm và lợi ích của nó đối với các dự án.

Bạn phải bán những thay đổi đó theo cách duy nhất mà quản lý sẵn sàng mua:

Tìm một tính năng hướng tới người dùng để thuyết phục rằng quản lý chỉ cần có nó, nhưng sẽ không thể thực hiện được nếu không có một số cải tiến cấp thấp trong mã.

Đó là công việc của sếp bạn để đảm bảo công ty tập trung phát triển vào việc cung cấp những gì khách hàng coi là giá trị gia tăng. Có hai yếu tố có thể thay đổi nhận thức này:

1. Mất bao lâu để cung cấp theo yêu cầu của khách hàng?
2. Bạn có giao hàng khi bạn nói bạn sẽ?

Hầu hết bạn muốn nói rằng sẽ mất 6 tuần và giao hàng trong 5 hơn là bạn sẽ giao hàng trong 3 nhưng mất 4.

Có một cơ sở mã hiện tại dễ quản lý và nâng cao hơn cho phép bạn cung cấp nhanh hơn và tăng khả năng dự đoán. Nếu bạn dành quá nhiều thời gian cho việc sửa lỗi, bạn có ít tài nguyên hơn để thêm các tính năng mới. Đánh giá số lượng tài nguyên đã chi cho việc sửa mã và mức độ chính xác của bạn đối với các quảng cáo tính năng. Đây là một cách để xác định xem mã hiện tại của bạn (theo triết lý của sếp) có tốn kém quá nhiều không.

Hãy để tôi nói cho bạn biết về một cơ hội trị giá 2 tỷ đô la gần như đã trượt qua tay chúng tôi vì quán tính quản lý.

Một số người trong chúng ta có quan điểm lắng nghe tiếng nói của khách hàng, nghĩa là hiểu những gì anh ta muốn. Không phải lúc nào anh ta cũng yêu cầu, nhưng nếu bạn ở trong một vị trí để có những cuộc trò chuyện với khách hàng của mình, cuối cùng bạn cũng hiểu được những gì anh ta muốn. (Sau đó, anh ấy có thể bắt đầu yêu cầu nó một cách rõ ràng.)

Điều đó đang được nói, điều quan trọng là phải hiểu ai nên có cuộc trò chuyện đó với khách hàng. Bạn thường có những người phát triển kinh doanh cùng với một số nhà thiết kế chính làm việc này. Nếu bạn có bất kỳ sự cạnh tranh nào, bạn có thể mong đợi rằng khách hàng cũng có cuộc trò chuyện này với họ.

Đồng thời, điều quan trọng là các nhà phát triển luôn cập nhật trong lĩnh vực của họ, bởi vì sẽ có sự cạnh tranh sẽ đánh bại bạn nếu bạn không.

Trong tình huống của chúng tôi, chúng tôi đã có một khách hàng hiện tại và một sản phẩm có hiệu quả dựa trên công nghệ cũ và khách hàng cần nâng cấp nhanh chóng. Điều họ thực sự cần là một sản phẩm thay thế hoàn toàn, nhưng suy nghĩ tại công ty chúng tôi là điều này sẽ ngay lập tức buộc chúng tôi vào vị thế cạnh tranh, trong khi sửa đổi sản phẩm hiện tại cho phép khách hàng của chúng tôi tiếp tục với chúng tôi mà không cần phải cạnh tranh về mặt pháp lý. Quản lý của chúng tôi nghĩ rằng họ sở hữu thị trường này. Vấn đề là họ không thể theo kịp các yêu cầu nâng cấp, vì cấu trúc sản phẩm hiện tại không đủ linh hoạt để nâng cấp.

Khách hàng trở nên thiếu kiên nhẫn và bắt đầu có cuộc trò chuyện với các nguồn cạnh tranh. Chúng tôi đã mất "quyền sở hữu" thị trường đó và doanh thu vài tỷ đô la. Tuy nhiên, một khi thị trường buộc chúng tôi vào vị thế cạnh tranh, ban lãnh đạo không còn lựa chọn nào khác ngoài việc ra khỏi doanh nghiệp hoặc cạnh tranh. (Hầu hết những người bị chặn đường cuối cùng đã bị sa thải.) Chúng tôi đã cạnh tranh và có thể lấy lại doanh nghiệp bằng sợi chỉ mỏng nhất.

Lúc đầu tôi đã nói rằng cơ hội này suýt trượt qua tay chúng tôi. Chúng tôi đã lấy lại doanh nghiệp, cho doanh thu tôi đã đề cập. Nếu chúng tôi đã sẵn sàng hơn để thích nghi với mối quan tâm của khách hàng ngay từ đầu, sẽ không có bất kỳ sự cạnh tranh thực sự nào.

Sự mang đi mà tôi đang cung cấp là thế này: Luôn cố gắng giữ vị trí dẫn đầu trong khả năng cá nhân của bạn. Luôn phát triển một sản phẩm linh hoạt và có thể được điều chỉnh nhanh chóng với những gì khách hàng của bạn cần. Nếu bạn làm việc quá lâu cho một công ty không nghĩ như thế này, bạn sẽ khô héo và động lực cá nhân của bạn sẽ giảm đi. Tôi đã thấy nó xảy ra.

Khi bạn có một ý tưởng để cải thiện sản phẩm của mình vì bất kỳ lý do gì, hãy tự hỏi mình những câu hỏi sau: - Đây có phải là điều tôi nghĩ khách hàng muốn? Tôi có thể xác nhận suy nghĩ của tôi về việc phát triển sản phẩm chống lại tiếng nói của khách hàng không? Là công ty của tôi ở một vị trí để giải quyết nhu cầu của khách hàng? Nếu vậy thì thế nào? - Sau đó, bạn nên có một vị trí để đưa ra một trường hợp thuyết phục liên quan đến các đề xuất phát triển sản phẩm của bạn.

Ngôn ngữ chung của kinh doanh trên tất cả các lĩnh vực và ngành công nghiệp là tiền. Vấn đề mà bạn đang mô tả không phải là vấn đề lập trình: đó là vấn đề kinh doanh. Nếu bạn muốn nhận được phản hồi thích hợp cho một đề xuất kinh doanh, bạn cần đóng khung nó bằng ngôn ngữ kinh doanh. Điều này có nghĩa là bạn phải có khả năng trình bày một kế hoạch dự án thay thế bao gồm tất cả các chi phí và lợi ích.

Bạn cần tìm hiểu về những thứ như chi phí cơ hội, ROI (lợi tức đầu tư) và NPV (giá trị hiện tại ròng). Bạn không cần MBA để làm điều này, nhưng bạn cần truy cập vào dữ liệu có thể không có sẵn cho bạn, chẳng hạn như chi phí nhân lực, chi phí trên không và tiềm năng cho doanh thu. Nếu bạn có thể đưa ra một lập luận rõ ràng rằng một đường dẫn sẽ cung cấp nhiều giá trị hơn một đường dẫn khác bằng cách sử dụng các số cứng, bạn sẽ nhận được sự chú ý đầy đủ từ ban quản lý.

Khi tôi là một nhà phát triển mới hơn trong một nhóm rất nhỏ, tôi đã thực hiện rất nhiều loại cải tiến này trong thời gian rảnh. Tôi đã thích nó; Tôi sẽ đăng nhập và thử các kỹ thuật mới thú vị khi ngồi trong phòng khách với vợ tôi vào ban đêm. Khi tôi trở thành một nhà phát triển cao cấp hơn và sau đó là quản lý của một nhóm lớn hơn, thời gian rảnh của tôi biến mất. Chúng tôi đã làm việc thêm giờ chỉ để hoàn thành các tính năng và sửa lỗi quan trọng. Thật khó để biện minh cho việc dành thời gian của bất cứ ai cho công việc dọn phòng thông thường đó, mặc dù tất cả chúng ta đều biết nó quan trọng như thế nào.

Sếp của bạn không cần một lời giải thích về tầm quan trọng của nó, để giảm chi phí bảo trì, giảm chi phí tăng trưởng trong tương lai, giữ cho một nhóm phát triển tài năng tham gia, v.v. Nếu họ làm vậy, bạn có vấn đề lớn. Những gì họ có thể cần, tuy nhiên, là một kế hoạch. Bởi vì ngay bây giờ tôi đoán rằng họ có tất cả các loại kế hoạch, lịch trình, lộ trình, lời hứa và áp lực về phía "thêm chức năng", đang cạnh tranh chống lại những suy nghĩ mong muốn và yêu cầu kết thúc mở từ nhóm nhà phát triển.

Một điều bạn có thể thử là lập một kế hoạch tài liệu. Xem nếu bạn có thể buộc nó vào bản phát hành, hoặc để thoát tiêu chí cho chức năng mới. Yêu cầu "dành chút thời gian để làm lại việc đếm tham chiếu" có thể khó khăn cho sếp của bạn chấp thuận, nhưng việc lên lịch cho khối thời gian 5 ngày 4 tuần kể từ bây giờ có thể dễ dàng hơn. Về cơ bản, tuy nhiên, bạn thấy rằng các tính năng mới được lên kế hoạch và lên lịch, cố gắng bắt chước điều đó hoặc tiêm một phần "dưới vỏ bọc" vào đó.

Bắt đầu nhỏ bằng cách yêu cầu 5% thời gian phân bổ cho loại công cụ đó, sau đó dần dần xây dựng các ưu tiên lộ trình công nghệ của riêng bạn và tiếp tục khắc phục trường hợp kinh doanh, ROI, mức độ rủi ro, v.v. Chẳng mấy chốc bạn thậm chí sẽ nếm trải những thách thức của sếp, vì bạn sẽ nhanh chóng tìm thấy nhiều ý tưởng tuyệt vời hơn bạn có thời gian để thực hiện.

Chúc may mắn!

Đây là lý do tại sao yêu cầu đếm tham chiếu tự động của bạn bị từ chối:

1. Đó không phải là một sự cải tiến . Một khi bạn có bất cứ điều gì lớn hơn thế giới xin chào, mọi thay đổi sẽ đi sai hướng. Không có số lượng tái cấu trúc nào sẽ thay đổi thực tế rằng nếu bạn cần thay đổi, nó sẽ luôn đi sai hướng. Bí quyết là để biết khi nào những thay đổi của bạn đủ quan trọng để nó vẫn có giá trị rủi ro gây ra vấn đề mới. Quản lý của bạn đã nói rõ ràng rằng nếu người dùng cuối có thể nhìn thấy nó, điều đó không đáng để mạo hiểm.
2. Tham chiếu đếm là tính năng hoàn toàn điên rồ. Bạn đã thấy một số công ty nổi tiếng lớn hiện có thực hiện một số tính năng và ngay lập tức nghĩ rằng bạn cần tính năng tương tự. Chà, rất có thể codebase của bạn hoàn toàn khác với những gì apple đang sử dụng. Có lẽ việc đếm tham chiếu sẽ không hiệu quả, hoặc nó chỉ lãng phí thời gian. Bạn nên tìm một cách khác mà không yêu cầu trải rộng các tham chiếu đếm nguyên thủy ở mọi nơi trong mã của bạn. Có lẽ kế hoạch giới thiệu của bạn yêu cầu hàng ngàn sửa đổi trong cơ sở mã, hầu hết những thay đổi đó là không cần thiết. Chỉ lãng phí thời gian và tiền bạc.
3. Bạn đang giải quyết vấn đề sai. Quản lý thường biết loại vấn đề nào có trong hệ thống. Một số vấn đề rò rỉ bộ nhớ không liên quan mà giải pháp đếm ngược đang giải quyết không phải là một trong số đó. Tập trung vào các vấn đề thực sự chứ không phải một số vấn đề tưởng tượng với cách máy tính xử lý bộ nhớ.
4. Phải mất quá nhiều thời gian để thực hiện nó Apple là công ty lớn hơn một chút so với nhóm không đáng kể của bạn với một vài lập trình viên và một số nhà quản lý. Họ có thể làm những thay đổi lớn chỉ bằng cách trả giá. Nếu phải mất vài triệu để thực hiện một cái gì đó, thì đó là đậu phộng. Nếu các công ty nhỏ cố gắng làm điều tương tự, họ sẽ hết tiền nhanh chóng. Phát triển phần mềm đã rất tốn kém; thêm các chi phí không cần thiết sẽ không giúp được một chút. Một tính năng không liên quan như quản lý bộ nhớ sẽ mở ra lũ lụt: sau khi họ phê duyệt nó, một nửa lập trình viên của bạn muốn "cải tiến" của riêng họ được thực hiện. Đó là câu chuyện không bao giờ thay thế và công ty có thể đang làm một cái gì đó hữu ích thay thế.

Dưới đây là một số bước bạn có thể sử dụng để xử lý sự cố:

1. Bỏ tính năng
2. Tìm hiểu vấn đề thực sự là gì
3. Bắt đầu làm một cái gì đó hữu ích
4. Lập kế hoạch cẩn thận về cách bạn sử dụng thời gian của bạn
5. Tìm hiểu làm thế nào cải thiện của bạn mang lại tiền
6. Chỉ chọn các tính năng mang lại nhiều tiền nhất
7. Nhận ra rằng khía cạnh lập trình của phát triển phần mềm chỉ là một phần nhỏ trong toàn bộ hệ thống - những cải tiến đối với nó sẽ không bao giờ có giá trị thời gian