Các nền kinh tế sai lầm tồi tệ nhất trong phát triển phần mềm là gì? [đóng cửa]

126

Các nền kinh tế sai lầm tồi tệ nhất (đó là cách tiết kiệm tiền mà cuối cùng chi phí nhiều hơn so với tiết kiệm) phổ biến trong ngành công nghiệp phần mềm và làm thế nào để bạn chống lại chúng?

programming-practices project-management

— Jon Hopkins
nguồn

2

:( Tôi đã thấy rất nhiều trong số này quá thường xuyên.

— Tony

3

lập trình viên

— quan.stackexchange.com/questions/18585/ từ

@Casey: Nó có một chút liên quan, nhưng không hoàn toàn. Liên kết bạn đã giao dịch trực tiếp với tiền, trong khi câu trả lời trong câu hỏi này ở đây cũng liên quan đến tiền và niềm tin. Ví dụ, hãy xem câu trả lời của tôi: lập trình

— Gan

Bạn vừa ghé thăm công ty của tôi .. đừng

— bận

1

@Mark - Nghe có vẻ là một câu hỏi hay, đi cho nó. Một vài chi tiết cụ thể có thể là tốt mặc dù.

— Jon Hopkins

182

Nợ kỹ thuật

tức là "Chỉ cần làm nhanh thôi, chúng ta sẽ tái cấu trúc sau". Thứ nhất bởi vì tôi chưa thấy ai đó tham gia vào hành vi này thực sự tái cấu trúc sau này. Thứ hai bởi vì làm mọi thứ một cách nhanh chóng, thay vì cách tốt làm cho việc thêm các tính năng trong tương lai hoặc giải quyết các lỗi trong tương lai khó khăn hơn để bạn mất thời gian trong thời gian dài.

Đáng buồn thay, nhiều người vẫn nghĩ rằng nó tiết kiệm chu kỳ nhà phát triển để họ làm điều gì đó nhanh chóng. Tôi đoán nó có thể, nhưng tôi chưa thấy nó trong thực tế.

— yêu cầu
nguồn

2

Tôi không thể đếm số lần tôi đã thấy các nhà phát triển dừng quản lý (2 đến 3) trong một ngày sau đó một chuyên gia triển khai để khắc phục sự cố (và thực hiện việc này nhiều lần trong vòng đời của sản phẩm) thay vì chi tiêu 2- 4 ngày để làm điều đó đúng. Câu trả lời chính xác.

— DevSolo

4

Nếu thời gian để sửa chữa có thể đo lường bằng đô la, ví dụ sửa lỗi hệ thống giao dịch cổ phiếu, thì quyết định quản lý sẽ nghiêng về chi phí giảm. Tôi đã thấy rằng đề xuất "vá nó ngay bây giờ để duy trì hoạt động trong khi chúng tôi xác định cách khắc phục chính xác để đảm bảo điều này không bao giờ xảy ra nữa" thỏa mãn tính cấp bách do chi phí và cũng có kết quả đúng, nhưng đôi khi bạn phải đấu tranh vì điều này .

— JBRWilkinson

9

Chúng tôi đã nhận được tất cả các mã với các bình luận như "Đây là một bản hack, thay thế sau bản demo", đó là cơ sở để thực hiện từ 3 đến 5 năm nay. Thậm chí không ai còn nhớ rằng nó đã được thực hiện vào thời điểm này, vì vậy không ai tìm thấy nó cho đến khi ai đó (tôi) đang sửa lỗi và chạy ngang qua nó. Không cần phải nói, bài học về đối tượng này đã dạy tôi rất tốt để làm điều đó ngay lần đầu tiên nếu tôi có thể làm như vậy.

— CodexArcanum

22

Và thành thật mà nói, tôi liên tục bị sốc bởi số lần nó thậm chí không tiết kiệm thời gian ngắn!

— Peter ALLenWebb

6

@Jorg - Hả? "Nợ kỹ thuật và nợ thiết kế là đồng nghĩa, ẩn dụ thần kinh đề cập đến hậu quả cuối cùng của kiến trúc phần mềm slapdash và phát triển phần mềm vội vàng." vi.wikipedia.org/wiki/Technical_debt Đây chính xác là những gì tôi đang đề cập đến. Một tiêu đề cụ thể hơn có lẽ là "Nợ kỹ thuật phát sinh mà không có ý định trả lại", nhưng, nhiều người trong tình huống này nói với họ rằng họ thực sự có ý định trả nợ (nhưng không), và tôi muốn có một tiêu đề mạnh mẽ để đưa vào chữ đậm ở phía trên. "Nợ kỹ thuật" dường như là một bản tóm tắt đủ tốt.

— Inaimathi

163

Thuê 2 nhà phát triển giá rẻ thay vì 1 thực sự tuyệt vời. (với cùng giá)

— người dùng2567
nguồn

9

Điều này ít nhất dường như có một cơ sở trong thực tế; Hãy nhớ rằng những người không có kỹ thuật không thể nói ai là nhà phát triển tuyệt vời (vì vậy họ rất có thể chỉ trả gấp đôi số tiền cho một kẻ ngốc, tư vấn một cách ngẫu nhiên so với một siêu sao thực tế).

— Inaimathi

112

Hay buồn thay, chỉ cần thuê 1 người giá rẻ ...

— DevSolo

4

... hoặc thuê một đạo sư trong đó hai người giả sẽ làm 1,5 trong số những gì guru làm cho 1,0 lương của guru: /

— bobah

14

Bạn không nhận được 75% của một bậc thầy từ một hình nộm , và bất kỳ lập trình viên thực sự giỏi nào cũng sẽ làm những gì cần thiết mà không bị hợm hĩnh về điều đó.

— Peter Boughton

8

Các lập trình viên 10 hoặc 100 lần là rất đáng đồng tiền bát gạo; họ chỉ được trả 1,5 có thể gấp đôi. Như Michael Lopp (Rands in Repose) nói, nếu bạn chỉ thuê một trong số này trong toàn bộ sự nghiệp của mình, thì đó là một chiến thắng ròng.

— Tim Williscroft

85

Ví dụ của tôi sẽ trái ngược hoàn toàn với ví dụ của NimChimpsky , cụ thể là:

Cố gắng phát triển một thứ gì đó trong nhà có thể mua được ngoài giá.

Thông thường điều này xảy ra do không thực sự kiểm tra thị trường để xem liệu một cái gì đó đã tồn tại sẽ giải quyết vấn đề. Điều này có thể được kết hợp bởi các nhà phát triển, những người thích "lặn" mã hóa trước khi thực hiện bất kỳ nghiên cứu nào và bởi các nhà quản lý dự án, những người không thành công trong thời gian đó = tiền.

Một trong những ví dụ phổ biến nhất tôi từng thấy trong lĩnh vực của mình, phát triển web, là các công ty đang cố gắng phát triển và hệ thống CMS nội bộ. Những thứ này luôn luôn bắt đầu nhỏ, nhưng sẽ sớm bị phình to và mất kiểm soát khi các tính năng được củng cố, trong khi mọi lúc có rất nhiều sản phẩm và khung miễn phí phù hợp hơn nhiều.

— Dan Diplo
nguồn

17

Chỉ vì nó có thể, không có nghĩa là nó phải như vậy. Một CMS cơ bản, vâng, tại sao lại phát minh lại bánh xe. Nhưng khi bạn bắt đầu nói về các hệ thống quy mô lớn và mô hình hóa các quy trình kinh doanh phức tạp - tại sao phải thử và lắp một chốt tròn trong một lỗ vuông? Đặc biệt là nếu bạn có các nhà phát triển và kỹ năng hiện có.

— NimChimpsky

9

@NimChimpsky - Tôi nghĩ có những ví dụ hợp lệ của cả hai. Tôi chắc chắn đã thấy mọi người phá vỡ quy trình kinh doanh của mình và mất đi những lợi thế mà họ có bằng cách cố gắng đưa chúng ra khỏi phần mềm, nhưng tôi cũng thấy các nhà phát triển bị mắc hội chứng "không được phát minh ở đây" mà họ có thể tải xuống vì nó là thú vị hơn đối với họ.

— Jon Hopkins

3

@NimChimpsky Nếu thông số kỹ thuật yêu cầu phát triển theo yêu cầu, thì điều đó cũng ổn - nó giữ chúng ta trong công việc :) Vấn đề xảy ra khi mọi người trước tiên không kiểm tra xem có thứ gì đã được phát triển phù hợp với dự luật và lao thẳng vào phát triển hay không. Một nghiên cứu nhỏ có thể đi một chặng đường dài!

— Dan Diplo

6

Tại sao phải phát minh lại bánh xe? Bởi vì bạn là một kỹ sư bánh xe. Hoặc bởi vì bánh xe của bạn tốt hơn bánh xe của chàng trai tiếp theo. Hoặc bởi vì bánh xe không phù hợp. Xem: phần lớnmaths.net / 2010/03 / Từ

— Derek

2

Nơi tôi làm việc gần như mọi thứ đều có thể được mua OTS - và gần như mọi thứ được phát minh lại trong nhà bởi vì theo Fearless Leaders (tm) "môi trường của chúng tôi rất phức tạp đến nỗi không có gì trên thị trường có thể xử lý được". Pfeh! Nhưng những gì hey - nó trả các hóa đơn. Chúng tôi đã nói với ngày hôm qua rằng một thành phần chính của phần mềm của chúng tôi sẽ được viết lại vào năm tới - VỚI MỘT GIAO DIỆN HÌNH ẢNH! Ôi trời ơi! Tôi là tất cả a-twitter ... (<pheh!>)

— Bob Jarvis

73

Không có tài nguyên dành riêng cho quản lý dự án

Tôi đã trải nghiệm nhiều lần khi một vài lập trình viên được ký hợp đồng và một người đã có một công việc đòi hỏi khắt khe nên đã quản lý dự án, nhưng thực tế là quá bận rộn với các nhiệm vụ khác nên dự án không bao giờ thực sự có được động lực. Các lập trình viên đã tạo ra "nguyên mẫu" và các thứ, nhưng không có người dẫn, phần lớn trong số họ đang chạy trong vòng tròn để trông bận rộn.

Thiết bị xấu cho lập trình viên mới

Tôi đã từng trải nghiệm một công ty trong đó chính sách là "lập trình viên mới phải làm việc trên một PC thực sự cũ với màn hình nhỏ cho đến khi họ chứng minh rằng họ xứng đáng". Không có gì ngạc nhiên khi một chính sách như vậy gây ra một lựa chọn tiêu cực đã loại bỏ những người tốt, những người luôn có lựa chọn làm việc trong một môi trường lành mạnh hơn.

— người dùng281377
nguồn

19

+1. Không cung cấp thiết bị tốt cho nhân viên của bạn đã "chắc chắn thất bại" được viết trên đó.

— Terence Ponce

3

+1. Nhưng lưu ý những điều sau: ở nhiều công ty, ngân sách phần cứng nằm trong cơ sở hạ tầng và tách biệt với ngân sách phát triển. Người quản lý cơ sở hạ tầng sẽ không đánh vào ngân sách của mình để giúp giảm bớt ngân sách của người quản lý phát triển. Tôi đã thấy chính trị khó chịu này chơi nhiều lần.

— Fil

3

Làm thế nào về thiết bị xấu cho TẤT CẢ lập trình viên? Chủ cũ của tôi đã trả cho chúng tôi tiền lương ở Thung lũng Silicon để viết mã trên máy tính để bàn đã tầm thường năm năm trước. Vì thời hạn cuối cùng, họ đã sa thải một nửa nhân viên một năm trước và phần lớn số còn lại vào tháng 7 - nhưng chàng trai, họ đã tiết kiệm tiền cho thiết bị!

— Bob Murphy

1

Kaz: Mỗi nhà phát triển nên có một máy thích hợp. Nếu mua phần cứng mới có nghĩa là PC của nhà phát triển mới tốt hơn một chút so với các nhà phát triển khác, thì trong trường hợp xấu nhất bạn có máy trao đổi nếu họ là loại người có kích cỡ tinh ranh. Người bình thường chỉ đơn giản là không quan tâm miễn là họ có phương trình cho phép họ làm việc hiệu quả. Tại nơi tôi đang làm việc, tôi đã có một PC mới hơn (có thể nhanh hơn) so với người đã thuê tôi. Những người đến sau tôi thậm chí còn mới hơn, có thể là PC nhanh hơn. Đoán xem cái gì? Không ai quan tâm, bởi vì tất cả các máy của chúng tôi đều đủ nhanh.

— dùng281377

3

Khi phần cứng không đủ, tôi biến nó thành một điểm để cho quản lý biết, thông thường bằng cách thực hiện các công việc hữu ích như cắt móng chân hoặc đọc giấy trong quá trình biên dịch dài. Tôi nhận được máy chậm cũ? Chắc chắn, không có thăm dò. Oh, bạn đã có một sửa lỗi vội vàng và tôi đã phải xây dựng? Chắc chắn rồi, Mr-Manager-bwana-sahib-dude - hẹn gặp lại sau 90 phút! (Có lần người quản lý hỏi tôi đã làm gì cả ngày - Tôi nói với anh ấy "Xây dựng lại ứng dụng. Bốn lần". Mất 10 giờ ". Máy mới xuất hiện không lâu sau ... :-)

— Bob Jarvis

71

Chúng ta có thể tiết kiệm tiền bằng cách lập trình viên tăng gấp đôi là người thử nghiệm / người viết kỹ thuật

Nếu bạn đang trả lương cho lập trình viên cho công việc của người thử nghiệm / nhà văn kỹ thuật, thì bạn đang lãng phí tiền và có khả năng nhận được công việc chất lượng thấp hơn so với người đã cống hiến sự nghiệp của họ cho nhiệm vụ đó. Ngoài ra, khi một lập trình viên chống lại việc kiểm tra thời hạn chặt chẽ và tài liệu rất có khả năng bị bỏ hoặc thực hiện nửa ass để đáp ứng nó.

BTW: Các nhà phát triển LUÔN LUÔN chống lại thời hạn chặt chẽ.

— JohnFx
nguồn

12

Những người thông minh có thể làm bất cứ điều gì ngụy biện tốt.

— Jon Hopkins

3

Tôi đã thực hiện nhập dữ liệu, mặc dù tôi chắc chắn sẽ không hạ giá cho nó. Họ muốn ai đó nhanh và chính xác cho một số mục nhập dữ liệu quan trọng và họ không ngại trả ít nhất ba lần tốc độ nhập dữ liệu. Sự lựa chọn của họ.

— David Thornley

1

Tôi tranh luận rằng đó là công việc lập trình viên để kiểm tra mã của họ, nhưng tôi không chắc đó có phải là những gì bạn đang đề cập đến không.

— Ben Lakey

3

Các lập trình viên nên kiểm tra mã riêng của họ, không loại trừ việc có những người kiểm thử chuyên dụng là những chuyên gia phá vỡ phần mềm.

— JohnFx

1

Đồng ý về văn bản kỹ thuật, không đồng ý về thử nghiệm. Kiểm tra là một phần tự nhiên của việc viết phần mềm tốt. Viết kỹ thuật chỉ là quá nhiều thay đổi từ mã hóa. Tôi thấy tôi cần thay đổi nhiều bánh răng để chuyển từ viết mã sang viết kỹ thuật và cảm giác như việc sử dụng thời gian của tôi rất kém.

— Adam Brussel

63

Nghiên cứu / Đọc / Viết mã không liên quan đến phát triển sản phẩm là một sự lãng phí tài nguyên.

Một số lập trình viên và thậm chí các nhà quản lý tin vào điều đó. Thông thường, họ chỉ làm lập trình dựa trên kiến thức trong đầu, và nghiên cứu và tìm kiếm câu trả lời khi họ gặp vấn đề. Họ không liên tục nâng cao kiến thức của mình một cách chủ động. Ý kiến của tôi, chúng ta nên luôn luôn cập nhật và kiến thức chúng ta thu thập sẽ hữu ích cho chúng ta trong việc giải quyết các vấn đề hiện tại và tương lai. Tất nhiên, bạn phải phân bổ thời gian của bạn một cách khôn ngoan để làm như vậy.

Điều này cũng tương tự như câu trả lời của Dan . Một số nhà quản lý chỉ muốn các nhà phát triển nhanh chóng lao vào và phát triển sản phẩm theo yêu cầu mà không cần nghiên cứu về các sản phẩm hiện có trên thị trường.

— Gan
nguồn

3

Tôi ước tôi có thể nâng cao điều này hơn một lần.

— MAK

1

Hãy viết một thư viện GUI. Hãy xây dựng một bộ công cụ nhắn tin. Nếu bạn không BÁN phần mềm, thì đó chỉ là một phần của một thứ lớn hơn, vì trời chỉ cần sử dụng triển khai của người khác. Điểm an toàn khi sử dụng giải pháp nguồn mở, bạn luôn có thể sửa chữa và hỗ trợ nó nếu bạn phải. Nếu bạn có tiền để mua các giải pháp có nguồn bao gồm, nhưng hãy coi chừng chất lượng kém của các thành phần phần mềm thương mại. Các nhà cung cấp hiếm khi bán cho bạn thành phần này hai lần để bạn có thể thất vọng khi bạn sở hữu nó (Tôi biết rằng tôi đã từng làm việc ở đây đã bị cắn bởi điều này trước đây)

— Tim Williscroft

58

Trong nhiều trường hợp, chi phí bù đắp nhiều tiền hơn. Trong công ty của tôi, rất khó để có được các vị trí nhân viên mới, chúng tôi bị đẩy mạnh ra bên ngoài. Nó cũng khó để có được các nhà thầu tại chỗ; có tỷ lệ 3: 1 ngoài khơi so với trên bờ mà họ phải duy trì. Do đó, nhiều đội chỉ thuê một tá ngoài khơi và hầu như không sử dụng chúng, chỉ để họ có thể có được 4 nhà thầu tại chỗ.

— Jeremy
nguồn

18

+1. Kinh nghiệm của tôi với việc giảm giá là nó chắc chắn sẽ tiêu tốn một khoản tiền lớn hơn nhiều so với việc tiết kiệm.

— Adam Crossland

2

+1, nhưng ngoài khơi có thể hoạt động nếu được sử dụng đúng cách

3

+1. Chúng tôi dường như nhận được các nhà phát triển ngoài khơi khác nhau cho mỗi dự án mới, có nghĩa là các nhà phát triển trên bờ dành phần lớn thời gian của họ để dạy cho các nhà phát triển ngoài khơi mới mô hình miền kinh doanh và kỹ thuật ngoài việc cung cấp hỗ trợ kỹ thuật. Kết thúc dự án và họ đã đi đâu đó và chúng tôi bắt đầu lại với các nhà phát triển 'giá rẻ' tiếp theo.

— Chris Knight

8

nhiều đội chỉ thuê một tá ngoài khơi và hầu như không sử dụng chúng, chỉ để họ có thể nhận được 4 nhà thầu tại chỗ. Ồ

— poolie

1

Và quên mất rằng ý chí của chính nó sẽ kéo dài thời hạn. Chúng tôi có QA ở nước ngoài và có thể mất 3-4 ngày để yêu thích lại thứ gì đó mà hai người trong cùng một văn phòng có thể giải quyết trong vòng một giờ do chênh lệch thời gian.

— HLGEM

50

Vòng phản hồi dài!

Nó xảy ra với tất cả mọi người: bạn xây dựng một cái gì đó mà bạn nghĩ là tuyệt vời, và hóa ra bạn đã sai. Đó không phải là vấn đề. Vấn đề là bạn mất bao lâu để xây dựng trước khi phát hiện ra rằng bạn nên dừng lại.

Ở cấp độ cao, bạn thấy vấn đề này với chu kỳ phát hành dài. Nếu bạn xây dựng trong một năm mà không có phản hồi, bạn sẽ đánh bạc cả năm. Bạn càng phát hành thường xuyên, các canh bạc của bạn càng nhỏ và bạn càng giỏi đánh bạc.

Nhưng nó cũng xảy ra ở mức thấp nhất. Là một nhà phát triển, tôi thực sự thích đánh giá mã thường xuyên (hoặc, tốt hơn, lập trình cặp) vì nó giới hạn thời gian tôi có thể tiếp tục làm điều gì đó ngớ ngẩn trước khi ai đó nói, "Này, có một cách đơn giản hơn!" Vì lý do tương tự, tôi thích các bài kiểm tra đơn vị của mình chạy nhanh và thường xuyên, vì vậy tôi có thể bắt và diệt bọ trước khi chúng phát triển.

Khi bạn bắt đầu nhận thấy tầm quan trọng của các vòng phản hồi ngắn, bạn sẽ thấy nó ở khắp mọi nơi. Ví dụ, khái niệm quân sự của vòng lặp Aluminium .

— William Pietri
nguồn

6

+1. Ngoài ra: vòng phản hồi càng dài, bạn càng ít nhớ về nhiệm vụ. Cuối cùng, bạn cần phải làm quen lại với toàn bộ cơ sở mã một lần nữa.

— Joseph Tanenbaum

Làm thế nào là một nền kinh tế sai lầm? Tiết kiệm dự định là gì?

— Chris Pitman

Mục đích là để tiết kiệm thời gian "lãng phí" vào những việc bạn làm mỗi vòng lặp. Ví dụ: Xây dựng, thử nghiệm, phát hành, chú ý đến người dùng. Dù sao đó cũng là cái cớ. Tôi nghĩ rằng nó thực sự bắt nguồn từ việc tránh sự khó chịu.

— William Pietri

Đây là lý do tại sao bắt buộc các nhà phê bình và cặp bạn bè phải khiêm tốn và tôn trọng người viết mã càng nhiều càng tốt. Một người đánh giá rắc rối đối xử với người viết mã kém và bạn có thể đảm bảo vòng phản hồi sẽ phát triển rất nhiều.

— Jonathan Neufeld

47

Không phải giai thoại của riêng tôi, nhưng tôi đã từng nghe về một cửa hàng ngừng cung cấp cà phê miễn phí cho các nhà phát triển của nó, nói với họ rằng bất cứ khi nào họ muốn lấy cà phê, họ có thể tự do đi bộ đến quán cà phê gần nhất (khoảng mười phút chuyến đi mỗi cách) và mua một số.

Khá nhiều định nghĩa về nền kinh tế sai lầm.

— EricBoersma
nguồn

4

Điều đó khá đặc biệt. So sánh và đối chiếu với một số ngân hàng thương mại ở London, người đã có một Starbucks được trợ cấp được xây dựng trong tòa nhà để loại bỏ thời gian cần thiết để đi ra ngoài và lấy cà phê.

— Jon Hopkins

48

Tôi không đồng ý rằng đây tự động là một nền kinh tế sai lầm - 10 phút không khí trong lành khi đi ra ngoài để mua cà phê sẽ giúp oxy cho nhân viên và cải thiện sự tập trung của họ và sự tương tác xã hội (mặc dù có giới hạn) sẽ làm giảm trầm cảm, đặc biệt là vào mùa đông. Những nhân viên sẽ không uống cà phê vì nó không miễn phí, có thể sẽ về nhà đúng giờ, ngủ nhiều hơn và có sức khỏe tốt hơn do giảm lượng caffeine.

— JBRWilkinson

6

-1, đi bộ 20 phút là hoàn hảo để giải phóng tâm trí của bạn và có được một góc nhìn mới mẻ về vấn đề.

— Malfist

23

@Malfist: Theo tôi hiểu, đó không chỉ là 20 phút đi bộ, mà còn là 15 phút chờ đợi để thực sự có được cà phê làm gián đoạn công việc. Nghỉ 45 phút tại bất kỳ thời điểm nào trong ngày là khá nhiều sẽ phá hủy năng suất trong hơn một tiếng rưỡi. Tất cả để tiết kiệm 100 đô la một tháng cho cà phê.

— EricBoersma

8

20 + 15 = 35 [sáu ký tự nữa]

— Malfist

47

Cung cấp máy trạm một màn hình vì màn hình thứ hai quá đắt . Ngay cả khi nó chỉ giúp bạn tiết kiệm một giờ làm việc mỗi năm, một màn hình thứ hai vẫn là một khoản đầu tư tốt. Tôi biết chắc chắn rằng tôi đã tiết kiệm cho tôi rất nhiều giờ làm việc.

Thiết lập nhiều màn hình có thể làm cho hầu hết mọi tác vụ hiệu quả hơn, không chỉ các tác vụ phát triển. Ba màn hình thậm chí còn tốt hơn hai, nhưng hiệu ứng trở nên kém rõ rệt hơn với mỗi màn hình phụ.

Thiết lập nhiều màn hình:

giảm chi phí chuyển đổi cửa sổ
cho phép bạn để mắt đến những thứ đang chạy trong nền (thư, biên dịch, v.v.).
cho bạn cảm giác tự do. Nó giống như ở trong tâm nhĩ so với ở trong một cái chổi.
Vân vân...

— Arjen Kruithof
nguồn

2

Đã đối mặt chính xác vấn đề đó một lần. Đã viết một bức thư cho một trong những CEO của chúng tôi tính toán rõ ràng rằng với hiệu suất tăng 5%, tôi sẽ tiết kiệm được một khoản tiền đáng giá cho người theo dõi trong khoảng nửa tháng so với thu nhập ròng của tôi. Tính toán này khá nhiều sắt ... nhưng ... tôi đoán là bạn đã biết kết thúc của câu chuyện :)

— Raffael

39

Phần cứng rẻ nhất được trao cho một nhà tư vấn khi nhà tư vấn có giá hơn 150 $ / giờ .

Đặt nó trong viễn cảnh một phần cứng tốt hơn ít nhất có thể làm cho công việc hiệu quả hơn 30 phút mỗi ngày. Điều đó sẽ cho 30 phút * 20 ngày làm việc mỗi tháng = 600 phút / tháng = 10 giờ / tháng> nhiều hơn công việc 1 ngày = 10 giờ * 150 $ / giờ = 1500 $

Bây giờ, một nhà tư vấn sẽ làm việc hiệu quả hơn nếu anh ấy / cô ấy có một máy tính $ 1500? Nó sẽ làm cho các nhà tư vấn ít bị kích thích?

Bây giờ vấn đề dường như là có hai ngân sách, một cho tư vấn và một cho phần cứng PC.

— Amir Rezaei
nguồn

8

Là một chuyên gia tư vấn, tôi đã ở đó, làm điều đó và có chiếc áo phông. (Tuy nhiên, chỉ nhận được $ 80 / giờ.) Nhưng này, đó là một lý do tôi thích hợp đồng hàng giờ. Không giống như một vị trí lương, nếu một khách hàng tư vấn chọn lãng phí thời gian của tôi và tôi phải làm thêm để bù đắp cho nó, đó là nhiều tiền hơn trong túi của tôi.

— Bob Murphy

2

Không xúc phạm, nhưng nếu tôi trả 150 đô la / giờ cho một nhà tư vấn, tốt hơn hết là anh ấy có máy tính của riêng mình.

— Steven Evers

8

@SnOrfus: Điều đó thường không hoạt động trong môi trường doanh nghiệp, nơi có sự kiểm soát chặt chẽ các PC được phép trên miền. Bạn phải cung cấp cho họ phần cứng.

— HardCode

1

@HardCode - Yea, tôi cho là vậy. Tôi có thể nhìn thấy điểm bây giờ.

— Steven Evers

3

@HardCode Trong một dự án gần đây, thay vì thêm chúng tôi (nhà thầu) vào mạng công ty nội bộ của họ, họ đã cách ly chúng tôi với đường DSL riêng của chúng tôi. Một đường DSL chuyên dụng cho 3 nhà phát triển @ $ 40 một tháng là một thay đổi lớn và giúp chúng tôi dễ dàng đẩy các bản cập nhật từ xa mà không khiến nhân viên CNTT rơi vào hoảng loạn. Ngoài ra, nếu PC sản xuất chạy mã của chúng tôi bị nhiễm và gặp sự cố, đó sẽ tự động là lỗi của chúng tôi vì chúng tôi chịu trách nhiệm về bảo mật thông tin liên lạc và máy tính xách tay cá nhân của chúng tôi. Bạn có thể nói thắng-thắng-thắng.

— Evan Plaice

38

Tháng làm việc tiết kiệm ngày lập kế hoạch

(Không đầu tư đủ thời gian vào kế hoạch)

— nông nô
nguồn

21

Trong trường học có một câu nói rằng một vài tuần trong phòng thí nghiệm có thể giúp bạn tiết kiệm một giờ thời gian thư viện.

— David Thornley

7

Vâng Khi tôi đang tham gia một lớp phòng thí nghiệm đại học nơi chúng tôi xác định được các hóa chất không xác định, prof nói với chúng tôi "một giờ trong thư viện sẽ giúp bạn tiết kiệm bốn trong phòng thí nghiệm". Tôi đã nghiêm túc với anh ấy, và thật vui khi được vào phòng thí nghiệm một giờ mỗi tuần và nhận được những cái nhìn khó chịu từ những người tiền sử đã dành mười hai giờ một tuần để làm các xét nghiệm amin trên các hợp chất rõ ràng không phải là amin. Và khi tôi dạy cùng một phòng thí nghiệm vài năm sau đó, tôi đã cho các sinh viên lời khuyên tương tự, và cũng như rất ít người thực sự nhận nó.

— Bob Murphy

3

Nếu bạn không lập kế hoạch, bạn có kế hoạch thất bại

27

Phổ biến nhất tôi nghi ngờ là các nhà quản lý chỉ đơn giản là không cung cấp cho các nhà phát triển các công cụ họ cần để thực hiện công việc của họ một cách hiệu quả.

Về cơ bản, điểm 9 trong bài kiểm tra Joel .

— giàu có
nguồn

2

Tôi đã tham gia vào các dự án mà họ sẽ khiến chúng tôi lãng phí một hoặc hai tuần thay vì mua, ví dụ, một thư viện với giá 300 đô la với công việc đã hoàn thành - và tốt hơn (chúng tôi không phải là "nhà phát triển kiểm soát" nơi tôi làm việc.) Hoặc chọn một số công cụ phần mềm "bởi vì nó được tạo bởi" công ty này hoặc "công ty" đó thay vì tìm kiếm nếu có những lựa chọn thay thế tốt hơn, sau đó biến cuộc sống của chúng ta thành địa ngục trong nhiều năm.

— MetalMikester

Tôi đã chạy vào đó một mình. Lý do PM / khách hàng là chúng tôi không có mục ngân sách để mua đồ cho khách hàng (thay đổi liên hệ là một con chó cái) nên chúng tôi sẽ phải phát minh lại bánh xe (một lần nữa).

— Ken Henderson

24

Thật không may, "ném (đủ) cơ thể vào vấn đề" vẫn có thể được sử dụng ở một số nơi. Luật của Brook không phản đối điều này từ Tháng huyền thoại , mặc dù một số yêu cầu kinh nghiệm để học bài học này. Nói chung, đây không phải là thứ nằm trong khả năng của tôi vì ban lãnh đạo có thể tin vào tuyên bố sai lầm về việc thêm người và không phải trả giá cho việc đó.

— Vua JB
nguồn

2

+1. Ôi Chúa ơi. Điều này hiện đang xảy ra ở quy mô hoành tráng trong một dự án lớn nơi tôi làm việc.

— Bàn Bobby

3

Tôi làm việc với một loạt các nhà lãnh đạo dự án, quản lý, vv, tất cả đều có chứng nhận quản lý dự án oh-so-tuyệt vời của họ (bất cứ điều gì heck nó được gọi là) và KHÔNG một trong số họ đã nghe nói về The Mythical Man-Month trước khi tôi giới thiệu họ với nó Sheesh!

— Bob Jarvis

2

Tôi đã nghe một câu nói hay về điều này một lần: 9 phụ nữ không thể sinh con trong một tháng

— Richard

@Richard Tôi đã sử dụng nó trong một cuộc họp. đã cho tôi niềm vui to lớn!

— Tjaart

21

Các cuộc họp hàng ngày :

(meeting duration in hours) x (Y team members) x (average salary per hour) = ...

— Zzz
nguồn

9

Có cuộc họp chỉ vì cuộc họp ...

— Gan

5

Chương trình nghị sự cho ngày hôm nay: Điều gì sẽ có trong chương trình nghị sự cho cuộc họp ngày mai?

— Đánh dấu C

9

Cuộc họp hàng ngày là tốt nếu những điều này là ngắn; Các cuộc họp độc lập kéo dài 3 phút theo phong cách Scrum không lãng phí nhiều thời gian mà vẫn giúp mọi người biết về sự phát triển của mọi người khác. Các cuộc họp dài với nhiều người tham gia không quan tâm là độc hại, mặc dù.

— 9000

3

@Mark C - Nghe có vẻ như một trò đùa, nhưng tôi thực sự đã được mời tham dự các cuộc họp để lên kế hoạch cho chương trình nghị sự của ngày tiếp theo ...

— Gavin Coates

@Gavin Coates đó là một thực tế và tình huống ... :)

— Zzz

20

Mua phần mềm thay vì phát triển nội bộ.

Tôi có kinh nghiệm về các hệ thống quản lý quy mô ngẫu nhiên, tập trung vào cả Phòng thí nghiệm nhân sự và sinh học.

Một giải pháp giảm giá có giá 50 - 100 nghìn bảng Anh và cần phát triển và tùy biến hơn nữa để đáp ứng các yêu cầu kinh doanh.

Giải pháp phát triển nội bộ mất (<6) tháng để phát triển, với các dự án khác đang được thực hiện song song và sử dụng một nhà phát triển đã được sử dụng.

Tôi đã đi từ khu vực công nơi chúng tôi đã phát triển và vận hành LIMS (hệ thống quản lý thông tin phòng thí nghiệm), đến một dược phẩm quốc tế lớn nơi việc triển khai một giải pháp giảm giá đã mất hơn một năm và chưa hoàn tất.

(6 tháng của một nhà phát triển đã được thuê làm việc song song với các dự án khác. Vì vậy, ~ 10k. Và điều đó không bao gồm chi phí hỗ trợ liên quan đến giải pháp giảm giá). Điểm chính là hệ thống phát triển nội bộ đã thực sự được sử dụng! Vì vậy, sau đó bạn có lợi ích chi phí gia tăng liên quan đến điều đó, mà tôi không thể tính toán được.

Tôi đồng ý cho các trang web cơ bản, vv, tại sao phải phát triển trang web của riêng bạn. Nhưng đối với bất kỳ hệ thống phức tạp lớn nào và nếu bạn đã có kỹ năng về nhà, tôi sẽ tự mình xây dựng nó .

— NimChimpsky
nguồn

26

Tôi cá là có một loạt các ví dụ ngược lại.

— Jon Hopkins

13

Để mua hoặc phát triển đi xuống đúng người làm siêng năng. Đơn giản như thế. Nghĩ trước khi hành động. (+1)

— DevSolo

4

@DevSolo: tại chỗ. Quyết định xây dựng hoặc mua phải được hỗ trợ bởi phân tích lợi ích chi phí, thay vì thái độ 'không được phát minh ở đây' hoặc 'Tôi yêu phần mềm của XXX'.

— JBRWilkinson

9

Nếu bạn định đưa ra tuyên bố về việc xây dựng so với mua, thì đó là: thích mua giải pháp cho các vấn đề không phải là một phần của năng lực cốt lõi của công ty bạn. Đó không phải lúc nào cũng là câu trả lời đúng, nhưng đó là một vị trí mặc định hợp lý và đáng tin cậy như một lời nói sáo rỗng. Tuy nhiên, để nói rằng việc mua phần mềm sẵn có là một nền kinh tế sai lầm, thậm chí không phải là một lời nói sáo rỗng hữu ích. Tôi cảm thấy nỗi đau của bạn đối với các giải pháp 'E' (nghĩa là 'Doanh nghiệp', nhưng thực sự có nghĩa là 'Đắt tiền '). Nhưng sự hiện diện của các lựa chọn xấu không có nghĩa là không có lựa chọn tốt ngoài kia.

— evadeflow

2

Tôi nghĩ rằng vấn đề là mua và sau đó vẫn cần phát triển và tùy chỉnh hơn nữa , chi phí cho một chút tùy chỉnh trên một hệ thống lớn mang lại thường có thể nhiều hơn sau đó viết hệ thống nhỏ của riêng bạn mà chỉ cần làm những gì bạn muốn. Vì vậy, hãy mua nếu bạn có thể làm việc theo cách mà hệ thống bạn đang mua mong bạn làm việc, nhưng mua & tùy chỉnh có thể mang lại điều tồi tệ hơn cho cả hai bên!

— Ian

15

Mua các sản phẩm đắt tiền khi các lựa chọn thay thế nguồn mở tốt hơn và miễn phí.

Có bao nhiêu công ty sử dụng git? Có bao nhiêu công ty sử dụng một số kiểm soát phiên bản enterprisey crappy?

— đã
nguồn

1

Erm, điều này có thể được coi là "nền kinh tế sai lầm tồi tệ nhất"? Hoặc có lẽ bạn cần phải giải thích nhiều hơn ...?

— Gan

3

Tôi không chắc chắn rằng tôi hoàn toàn đồng ý với ví dụ về kiểm soát nguồn, ít nhất là. Git được thiết kế đặc biệt để giải quyết các vấn đề về nguồn mở: Nhiều nhà phát triển, ít kiểm soát trung tâm, nhiều chi nhánh, v.v ... Phần mềm "enterprisey" hoạt động theo một giả định khác nhau: Nhu cầu quản lý nhiều loại sản phẩm trong một doanh nghiệp, bảo mật, quy trình làm việc, v.v.

— Peter ALLenWebb

1

@Gan: Họ nghĩ rằng sử dụng nguồn mở là nền kinh tế sai lầm, nhưng họ có tất cả ngược lại.

— hasen

3

Tôi là người đóng góp cho X11 và Gnome và khá thành thạo trong việc sử dụng git và quản trị máy chủ gitosis. Tuy nhiên, mùa hè này tôi đã chuyển công việc tư vấn của mình từ git sang máy chủ Perforce trả tiền cá nhân vì nó tự động thực hiện rất nhiều việc mà bạn phải thực hiện thủ công với git. Vì tôi được trả tiền để cung cấp mã và không vướng bận với kiểm soát phiên bản, sử dụng và trả tiền cho "kiểm soát phiên bản enterprisey crappy" hiệu quả hơn nhiều so với sử dụng git.

— Bob Murphy

7

Nguồn mở so với các sản phẩm thương mại thực sự là một cơ sở "theo từng trường hợp" theo kinh nghiệm của tôi.

— MetalMikester

14

Sử dụng các ngôn ngữ "đơn giản" mà không có nhiều biểu cảm

Vâng, việc tìm lập trình viên để duy trì mã dễ dàng hơn, nhưng việc tìm lập trình viên giỏi , những người không học được từ thông dụng mới nhất sẽ khiến họ được thuê dễ dàng hơn. Vâng, nó làm cho mã bit riêng lẻ dễ hiểu hơn, nhưng nó cũng làm cho nó cứng như 2x4 và tăng khối lượng mã cần phải hiểu. Vâng, nó được hỗ trợ bởi một tập đoàn lớn, nhưng cho biết tập đoàn lớn đổi mới chậm và quan liêu.

— fax
nguồn

4

@burnt_hand: Về cơ bản, tôi đề cập đến sự ác cảm rủi ro quá mức của ban quản lý về mặt lựa chọn ngôn ngữ.

— dsimcha

1

+1: Chỉ cần tiếp tục sử dụng C vì "chúng tôi có những kỹ năng đó và học một số ngôn ngữ mới lạ như Python / Perl / PHP sẽ tăng thêm rủi ro". Nghe nó nhiều hơn một lần. Điều đó có nghĩa là nhóm quá ngu ngốc để học một ngôn ngữ mới?

— S.Lott

1

@ S.Lott Đại lý tuyển dụng nghĩ rằng bạn là vậy!, Nhưng đó là một câu chuyện khác

— burnt_hand

2

tức là các công ty gắn bó với Java và C # và quá ngại chạm vào python hoặc ruby vì chúng không phải là "tiêu chuẩn công nghiệp", điều này khiến tôi nhớ đến: paulgraham.com/avg.html

— hasen

1

@hansen: Bài tiểu luận của Paul Graham là một phần cảm hứng cho tôi viết bài này. Cảm hứng khác của tôi là công việc phát triển các thư viện (bao gồm thư viện chuẩn) cho ngôn ngữ lập trình D.

— dsimcha

13

Quản lý dự án xấu / trưởng nhóm.

Vì một người bất tài có quyền hủy hoại công việc của một nhóm người. Cuối cùng, dự án sẽ làm tốt hơn nhiều nếu không có các quyết định quản lý cấp cao (dự án / nhóm trưởng).

Quyết định "Chỉ cần làm nhanh thôi, chúng ta sẽ tái cấu trúc sau".

— Amir Rezaei
nguồn

4

Tôi đồng ý rằng có những người quản lý tồi, nhưng "dự án sẽ làm tốt hơn nhiều nếu không có các quyết định quản lý cấp trên"? Nói chung đây là những người đang tài trợ cho dự án. Điều này nghe có vẻ giống như các nhà phát triển mà tôi đã gặp, những người nghĩ rằng việc hiểu công nghệ quan trọng hơn hiểu doanh nghiệp và quên đi khách hàng thực sự là ai.

— Jon Hopkins

2

@Jon Hopkins Với quản lý cấp trên tôi không giới thiệu khách hàng. Vấn đề là "những người quản lý dự án tồi" là những người mắc lỗi sau những sai lầm và chống lại một nhóm người. Bạn nghĩ ai quyết định "Cứ làm nhanh đi, chúng ta sẽ tái cấu trúc sau". Đọc câu trả lời với tỷ lệ cao nhất!

— Amir Rezaei

ah, rõ ràng hơn. Tôi xóa -1 của tôi.

— Jon Hopkins

Tôi đã nhận thấy một xu hướng đáng lo ngại của các nhà quản lý dự án hoàn nguyên thời gian và chi phí so với chất lượng. Tôi chắc chắn tôi không phải là người duy nhất. Các PM muốn sử dụng biểu đồ tam giác với Chi phí / Chất lượng / Thời gian trên đó nhưng Chất lượng luôn được khởi động trước. Thật đáng buồn, và thể chế hóa và buộc các số liệu của quản lý dự án (PMI) về một thứ phức tạp như phần mềm dường như chỉ làm cho mọi thứ tồi tệ hơn.

— Bernard Dy

1

@Bernard - thời gian và chi phí có thể đo lường được. Chất lượng? Không nhiều lắm. Buồn nhưng IMO đúng ...

— Bob Jarvis

12

Thiếu yêu cầu người dùng

Một bước quan trọng và khó khăn trong việc thiết kế một sản phẩm phần mềm là xác định những gì khách hàng thực sự muốn nó làm.

Tin hay không đôi khi phần này bị thiếu hoặc đã lỗi thời. Những gì nó nói về chi phí là người ta tạo ra các chức năng mà người dùng cuối không bao giờ yêu cầu.

— Amir Rezaei
nguồn

Tôi nghĩ rằng điều này nên ở đầu!

— Roopesh Shenoy

8

Năng suất có giá trị hơn sáng tạo

Sáng tạo rất khó để đo lường nói chung, và hầu hết thường không thể quan sát, không bao giờ quan tâm đến đo lường, khi nói đến phát triển phần mềm. Năng suất, mặt khác, có thể được đo lường (thường là kém), và có thể được quan sát.

Do đó, các nhà phát triển có thể (viết nhiều dòng mã hơn | viết mã nhanh hơn | đọc thuộc lòng công nghệ nhanh hơn để trả lời các câu hỏi mất nhiều thời gian hơn để viết mã, nhưng tạo ra một sản phẩm đáng tin cậy hơn

— quả việt quất
nguồn

6

Tất cả dưới đây có thể xấu khi sử dụng hoặc không sử dụng không đúng cách

phần mềm bên ngoài vs kênh
Tuân thủ ISO 9001 (nền kinh tế - giảm thiểu rủi ro mất MSS nếu chất lượng sản phẩm giảm)
phát triển / gia công QA
thủ tục phát triển / xây dựng / phát hành / hỗ trợ

— bobah
nguồn

ISO 9001 là một "nền kinh tế" (sai) như thế nào?

— Andrew Grimm

@Andrew Grimm - việc tuân thủ đảm bảo mức chất lượng nhất định giúp giảm thiểu rủi ro do chất lượng kém (ví dụ mất MSS) nên nền kinh tế tiềm năng là rõ ràng. Đối với các bộ phận nhỏ, điều này có thể không phù hợp vì tổn thất trên không cao hơn những người có nguy cơ tiềm ẩn

— bobah

1

@Andrew - theo kinh nghiệm của tôi, nó phụ thuộc vào những gì bạn muốn nó. Nếu bạn muốn nó tăng chất lượng, có lẽ đó là một nền kinh tế sai lầm vì nó có xu hướng đắt đỏ và có thể không phù hợp với phần mềm. Nếu bạn muốn nó như một thứ tiếp thị hoặc bởi vì nó chỉ được mong đợi trong ngành của bạn, thì đó có khả năng là một ý tưởng tốt.

— Jon Hopkins

5

@Andrew Grimm - Điều "duy nhất" mà ISO 9001 đảm bảo là phù hợp, chất lượng lặp lại. Nó không đảm bảo chất lượng "cao". Tuy nhiên, nếu trình độ ISO 9001 là những gì được yêu cầu trong không gian thị trường mà công ty muốn tham gia thì điều đó là bắt buộc.

— Vatine

1

@Vatine: Những gì ISO 9001 đảm bảo là quy trình nhất quán, có thể lặp lại. Trong một số lĩnh vực, nơi các quy trình nhất quán mang lại chất lượng phù hợp, đó là điều quan trọng. Nó không đảm bảo chất lượng cao, nhưng nếu khách hàng thấy điều gì đó bạn đã làm tốt và biết rằng bạn được chứng nhận ISO 9001, họ sẽ tự tin về chất lượng tương tự.

— David Thornley

4

Có quá nhiều người quản lý giao hàng không có hóa đơn.

Vài năm trước, trong công ty của chúng tôi, chúng tôi đã có một vài dự án ngân sách lớn đang diễn ra và tuyển dụng đang ở đỉnh cao. Vào thời điểm đó, công ty chúng tôi đã thuê quá nhiều người quản lý giao hàng (Nhiều người trong số họ không phải là IT!) Và rất ít lập trình viên / người kiểm thử. Tỷ lệ giữa người quản lý và lập trình viên theo nghĩa đen là 1: 2. Sau đó, sau khi hoàn thành các dự án đó, chúng tôi đã có một tình huống mà chúng tôi có nhiều người quản lý (một số trong số họ là những người chậm chạp thực sự) ngồi trên băng ghế dự bị không làm gì cả. Chúng tôi đã có một chu trình thẩm định trong đó mọi người đều được tăng / ít tiền (Ngay cả chúng tôi, những lập trình viên chăm chỉ, thở dài) để công ty không phải sa thải bất cứ ai! May mắn thay, công ty đã nhận ra tình huống này và đã thực hiện QUYỀN trong quý đầu tiên của năm nay!

— manan camera
nguồn

3

Tối ưu hóa trước khi định hình (còn gọi là tối ưu hóa sớm).

Đã rất nhiều lần tôi thấy ai đó tiếp cận một giải pháp thông minh, điều đó không cần thiết làm phức tạp việc bảo trì và dễ đọc với lý do là nó nhanh hơn. Đương nhiên, mã không được đánh dấu băng ghế dự bị (thậm chí không có điểm chuẩn vi mô), do đó, mã này nhanh chóng trở nên "nhanh hơn dựa trên lập luận thuyết phục hơn" đối với một phần mã có khả năng không ảnh hưởng đến hiệu suất chung của toàn bộ ứng dụng nhiều.

Như vậy, đó là một nền kinh tế rất sai lầm, và loại nền kinh tế sai lầm đôi khi vướng víu ngay cả những thuận lợi dày dạn.

— Edwin Buck
nguồn

3

Giới hạn hoặc không có truy cập internet

Bởi vì rõ ràng nhân viên của bạn sẽ sử dụng internet để chơi các trò chơi trên facebook không quá nghiên cứu câu trả lời cho các câu hỏi kỹ thuật trên Stackoverflow.

Trong thực tế, internet là một công cụ tăng năng suất rất lớn và trong khi có thể thích hợp sử dụng một số loại bộ lọc trang web cho các trang web thực sự tinh ranh thì có gì đó sai nếu nó chặn tệp readme của studio trực quan hoặc chặn các trang quản trị cục bộ của telford vì lý do "du lịch tình dục"

— jk.
nguồn

2

Làm cho các nhà phát triển của bạn sử dụng màn hình 15 inch và PC có thông số kỹ thuật thấp vì đây là tiêu chuẩn của công ty.

Màn hình có kích thước hợp lý là giá rẻ, nhanh chóng để cài đặt và làm cho các lập trình viên làm việc hiệu quả hơn cũng như làm cho các lập trình viên của bạn nghĩ rằng bạn quan tâm đến họ.

— Ian
nguồn

2

Quá nhiều Cử nhân Quản trị Kinh doanh (hoặc tương tự), được sắp xếp theo thứ bậc, cố gắng áp dụng những gì họ nghĩ về quản lý hiện đại: Làm phiền mọi người với "KPI", "SLA" và những gì không, yêu cầu "báo cáo" (không có, tất nhiên, quan tâm đến cơ sở hạ tầng để tạo ra chúng), để các lập trình viên lãng phí thời gian để điền vào các bảng EXCEL ưa thích, báo cáo Q4 và những gì không và sao chép từ một công cụ quản lý mới tuyệt vời này và dán vào một công cụ khác (dường như đó là quy tắc các công cụ này không bao giờ được tích hợp cũng như không thể tích hợp với nhau) và tham dự các cuộc họp nơi trình bày các báo cáo và số liệu (và mọi người đều cảm thấy tội lỗi vì đã không hoàn thành điều này hoặc KPI đó).

— Ingo
nguồn