Làm cách nào tôi có thể thuyết phục một thành viên trong nhóm sử dụng khung web? [đóng cửa]


10

Câu hỏi là đây và chi tiết như sau: có bất cứ điều gì tôi có thể nói / đưa lên, với tư cách là một lập trình viên, để đưa anh ấy đến bên tôi không?

Tôi rất thích nghe những tranh luận hợp lệ cho cả hai bên về vấn đề này, nhưng chủ yếu là những gợi ý về cách nói chuyện với anh ấy.


Tình huống của tôi là thế này: Tôi đang làm việc trong một dự án nhóm trong khóa học văn bằng của mình, xây dựng một trang web cỡ vừa làm nguyên mẫu cho trường đại học. Tất cả đều được coi là bình đẳng trong nhóm và không có ai được chỉ định lãnh đạo nên câu trả lời cho vấn đề này không thể là "kéo hạng".

Tất cả đều bằng nhau, tuy nhiên có một khoảng cách lớn về kiến ​​thức giữa các thành viên. Thành viên trong nhóm nghi vấn và tôi đều là những nhà phát triển có khả năng, mặc dù anh ta không có kinh nghiệm trong ngành. Ba thành viên khác ít có khả năng hơn và hai người đã từ chối phát triển hoàn toàn. Cả ba đều từ chối bình luận về tình huống này do thiếu kiến ​​thức.

Với tư cách là một nhóm, chúng tôi sẽ quyết định sử dụng công nghệ nào trong việc triển khai trang web; cụ thể, có nên sử dụng khung PHP (Code Igniter) hay không.

Tôi đang tranh luận ủng hộ, trích dẫn:

  1. Không phát minh lại bánh xe
  2. Cơ sở mã được viết và kiểm tra tốt để làm việc từ
  3. Bắt đầu đi (thời hạn gần hơn chúng ta muốn)
  4. Tốc độ phát triển
  5. Mẫu thiết kế âm thanh và có thể bảo trì và thực hành tốt

Anh ta đang tranh luận về việc làm theo cách mà anh ta đã từng:

  • Viết bespoke, chức năng một lần vào tệp "thư viện" như khi anh ta cần chúng
    • Các chức năng truy cập dữ liệu và hiển thị dữ liệu đó trên trang, nhận / cài đặt đến và từ phiên và nhận / đăng dữ liệu, v.v.
  • Có 1 tệp trên mỗi trang (dẫn đến không có sự phân tách mối quan tâm giữa kiểm soát, trình bày và dữ liệu)

Lý do của anh ta chống lại việc sử dụng là khuôn khổ chủ yếu dựa trên anh ta không thể nhìn thấy điểm: anh ta có thể làm tất cả những điều đó rồi. Khung không thay đổi điều đó, nó chỉ làm cho nó khó hơn vì anh ta phải học khung; anh ta không muốn sử dụng mã mà anh ta đã viết.

Ông cũng đã nói rằng "không quan trọng chất lượng của cơ sở mã, vì dự án chỉ là một nguyên mẫu và sẽ không bao giờ được duy trì". Đối với tôi, đó không phảilý do để viết mã không thể nhầm lẫn.

Tôi có thể thấy lý do tại sao anh ta đưa ra những lập luận đó, nhưng tôi có vấn đề với "sự thiếu quan tâm đến khả năng bảo trì" của anh ta và "sự coi thường thiết kế tốt" của anh ta, hoặc thậm chí tách rời các mối quan tâm. Tuy nhiên, tôi nghi ngờ anh ta chưa bao giờ nghiên cứu các mẫu thiết kế, vì vậy tôi không biết hiệu quả của việc chứng minh tại sao phương pháp của anh ta có thể chứng minh được là không thể hiểu được.

Tôi muốn thực hiện dự án này, nhưng tôi không muốn thực hiện nó mà không quan tâm đến mọi thứ tôi đã học được trong nhiều năm. Như tôi đã nói trước đây, không có khả năng kéo xếp hạng ở đây, các thành viên khác trong nhóm cũng không sẵn sàng tham gia. Tôi có nên lùi lại và làm mọi thứ theo cách của mình không? Có phải anh ấy quá cứng đầu và thiếu kinh nghiệm để biết rõ hơn? Hay tôi là người cứng đầu ở đây?

TL; DR Thành viên nhóm thiếu kinh nghiệm đang bướng bỉnh, làm thế nào tôi có thể chiến thắng anh ta?


2
Rất khó để tìm câu hỏi thực tế trong bài đăng trên blog của bạn :) Vui lòng xem lại theo cách nhấn mạnh các đối số kỹ thuật mà cả hai bạn đưa ra. Mặc dù chúng tôi thực sự không thể nói cho bạn biết cách nói chuyện với một người mà chúng tôi không biết, chúng tôi có thể giúp bạn tiếp cận tình huống từ quan điểm của lập trình viên. Dường như có một câu hỏi hay về tạo mẫu tiến hóa trong đó, nhưng tôi không thể chắc chắn ...
yannis

4
Các phần của điều này có lẽ sẽ phù hợp hơn cho: area51.stackexchange.com/proposeals/30887/prof Profession
Karlson

3
he doesn't want to use code he hasn't personally written.Anh ta nên vứt bỏ hệ điều hành, IDE, điện thoại, đèn giao thông, v.v.
StuperUser

4
@AndyBursh I want to know exactly how everything workslà một đối số hợp lệ khi học, được phát minh lại bánh xe là thực sự chấp nhận được. Có lẽ, chỉ có thể, bạn có thể đọc nó như một tiếng kêu cứu và không bướng bỉnh.
yannis

4
since the project is only a prototype and will never be maintained Lời cuối cùng :) Tôi ước tôi có một đô la mỗi khi tôi đưa ra giả định này và phát hiện ra rằng sự thiếu kiên nhẫn và lòng tham ngắn hạn của những người cao hơn đã quyết định rằng nguyên mẫu là sản phẩm bây giờ.
maple_shaft

Câu trả lời:


20

Bạn sẽ không thể nói chuyện với anh ấy. Nó được gọi là hiệu ứng Dunning-Kruger . Anh ta quá thờ ơ để biết những gì anh ta không biết, và quá sợ mất những gì anh ta coi là một lợi thế.

Khi bạn không thể đạt được sự đồng thuận, thay vào đó bạn phải đạt được sự thỏa hiệp. Có lẽ bạn có thể chia nhỏ công việc để nhu cầu tìm hiểu khuôn khổ của anh ấy là tối thiểu. Có thể bạn có một số loại "thiết kế tắt" trong đó mỗi bạn thực hiện theo cách của bạn trong một vài tuần và sau đó nhóm bầu chọn cái nào là tốt nhất. Có lẽ bạn có thể liên quan đến giáo sư tài trợ của bạn hoặc bất cứ ai là khách hàng trong việc giải quyết cà vạt.


3
+1 vì điều này đôi khi xảy ra trong thế giới thực. Tôi đã từng làm những công việc mà tôi không thể đồng ý với một nhà phát triển khác về cách tiếp cận tốt nhất. Vì vậy, cả hai chúng tôi đã tìm ra một POC và sau đó kiểm tra ưu và nhược điểm của từng loại. 9 trong số 10 lần chúng tôi kết thúc việc áp dụng một giải pháp là sự kết hợp giữa hai POC và mọi người đã học được điều gì đó từ quy trình này.
Timothy Baldridge

1
+1 để giảng dạy về Dunning-Kruger! Mọi người cần biết về nó ..
Stephen Gross

Bah Thật quá dễ dàng để trích dẫn Dunning-Kruger khi bạn không đồng ý với ai đó - quá dễ để gọi họ là ngu ngốc. Có thể đồng đội tin rằng các khung làm việc vi phạm tinh thần của nhiệm vụ, có thể anh ta muốn giải quyết, tận mắt, các vấn đề mà một khung giải quyết, có thể anh ta muốn tránh cuộc tranh luận về CodeIgniter, Cake, Symfony ... anh là một thằng ngốc
Corbin ngày

1
@Corbin, Dunning-Kruger không phải là thiếu thông minh, đó là về sự thiếu kinh nghiệm. Hai điều rất khác nhau. Tôi đồng ý lý do của bạn có thể hợp lệ, nhưng OP cho biết đó không phải là những lý lẽ mà anh ta đang đưa ra. Thay vào đó, anh ta "không nhìn thấy điểm" của việc sử dụng các khung công tác vì anh ta có thể viết một cái gì đó tốt như chính mình từ đầu trong một khoảng thời gian ngắn hơn. Một người thiếu kinh nghiệm đánh giá quá cao năng lực của chính mình so với một giải pháp mà anh ta thừa nhận hầu như không biết gì về nó là một ví dụ trong sách giáo khoa của Dunning-Kruger. Những người như vậy không thể được "nói chuyện" một cái gì đó, họ phải được hiển thị.
Karl Bielefeldt

7

Một lập luận có lợi cho bạn là khả năng sử dụng lại kiến ​​thức. Tất cả các thành viên trong nhóm, những người học một khuôn khổ nổi tiếng và được sử dụng rộng rãi (như CodeIgniter) sẽ có thể sử dụng lại kiến ​​thức của họ trong dự án tiếp theo. Trong khi kiến ​​thức về một haphazard, "thư viện" độc quyền không thể tái sử dụng. Điều này có thể cộng hưởng tốt với các thành viên khác trong nhóm, vì họ có thể thích có được một số kiến ​​thức hữu ích, có thể sử dụng lại trong dự án này.

Một lập luận khác có thể là một phép đo cụ thể về chi phí phát triển / bảo trì. Tôi tưởng tượng rằng một nhà phát triển thành thạo CodeIgniter có thể phát triển nhanh hơn so với đồng nghiệp của bạn tự viết tất cả các chức năng độc quyền đó. Điều này có thể được chứng minh bằng cách cả bạn và anh ấy xây dựng một trang web giống hệt nhau - bạn với CodeIgniter, anh ấy theo cách riêng của mình - và đo thời gian để hoàn thành. Sau đó thực hiện một bộ sửa đổi / tiện ích mở rộng cho các trang, một lần nữa đo thời gian để hoàn thành. Tất nhiên, đặc điểm kỹ thuật nên được chuẩn bị bởi một người độc lập với cả hai bạn, để chiến đấu trên mặt đất trung lập.

Một cái khác - như bạn đã đề cập - là chất lượng mã. Khi các trang web đã sẵn sàng, hãy chạy cùng một bộ kiểm tra chấp nhận trên mỗi trang và so sánh mật độ lỗi.

Tất nhiên, khi bạn chịu áp lực thời gian, có thể không có khả năng dừng lại và thực hiện các phép đo như vậy. Vì vậy, bạn có thể muốn một giải pháp nhanh chóng để tiến thoái lưỡng nan này. Hãy thử thuyết phục các thành viên khác trong nhóm (ví dụ bằng cách họ đọc câu trả lời sắp tới cho bài đăng của bạn tại đây :-), để tạo áp lực nhóm lên anh ấy. Cuối cùng, nếu anh ta thực sự không thể bị thuyết phục, bạn có thể muốn cắt dự án thành hai phần, một phần cho anh ta và - lý tưởng - một phần cho phần còn lại của nhóm, sử dụng CodeIgniter. Tập trung vào việc làm phần của riêng bạn với khả năng tốt nhất của bạn và để anh ấy làm bất cứ điều gì anh ấy muốn. Kết quả có thể sẽ nói cho chính họ.


Tôi thích ý tưởng về một bài kiểm tra tốc độ để chứng minh điều đó. Những loại thử nghiệm chấp nhận chúng ta có thể chạy? Tôi chắc chắn sẽ đề xuất điều này, nhưng tôi không chắc nó sẽ phù hợp với anh ấy (hoặc nhóm) vì tất cả chúng ta đều có thời hạn khác để quản lý, và tôi nghi ngờ bất kỳ ai cũng đặc biệt muốn viết thông số hoặc "lãng phí thời gian" (như Tôi chắc chắn rằng nó sẽ được đặt) vào điều này.
Andy Hunt

1
Khoa học, nó hoạt động: xkcd.com/54
StuperUser

5

Tôi cảm thấy bạn cần phải tham gia vào 3 đồng đội khác. Cả hai bạn cần trình bày lập luận của bạn cho họ và giải thích mọi thứ cho họ để họ hiểu. Vào cuối ngày, họ cũng sẽ phải làm việc với cơ sở mã này. Và nếu tất cả đều bằng nhau, thì họ nên nói một chút về những gì họ muốn làm việc với.

Tôi nghĩ rằng một cách tiếp cận tốt sẽ dành cho mỗi bạn để phác thảo lợi ích của các giải pháp tương ứng của bạn và cho các thành viên khác trong nhóm biết lý do tại sao bạn cảm thấy đó là cách tốt nhất để đi. Sau đó để họ quyết định. Có 3 trong số đó vì vậy nó sẽ là bộ ngắt kết nối.

Một điều mà bạn sẽ muốn chỉ ra là nếu đây là dự án Sr của bạn và các thành viên khác trong nhóm không có kinh nghiệm nào khác, dự án này cần phản ánh công việc họ có thể làm cho các nhà tuyển dụng tiềm năng. Nếu bạn làm đúng thì đó có thể là một điểm tốt trong một cuộc phỏng vấn. Tôi biết tôi yêu cầu sinh viên mới để phác thảo dự án cao cấp của họ, và cách nó được thiết kế và phát triển.

Nếu họ đi theo cách tiếp cận của người kia, bạn sẽ phải mút nó. Nhưng đừng từ bỏ hy vọng. Hãy đưa ra một thiết kế tốt để sự hỗn loạn mà anh ấy viết sẽ không ảnh hưởng đến mọi thứ. Nếu bạn có thời gian, hãy dọn dẹp một số mã và cấu trúc lại một số nội dung của anh ấy và cho anh ấy thấy rằng anh ấy không phải phát minh lại bánh xe mỗi lần.


Thành thật, tôi đã không nghĩ về điều này phản ánh với những người khác trong nhóm. Tôi chắc chắn sẽ chỉ ra điều đó.
Andy Hunt

1

Tôi cảm thấy đại học giống như một hộp cát. Hầu hết những thứ bạn làm ở đó không được sử dụng trong triển khai. Vì vậy, nó cho phép bạn tự do hơn nhiều để thử nghiệm và ra khỏi vùng thoải mái của bạn. Khám phá những thứ mới bởi vì thất bại sẽ không có quá nhiều ảnh hưởng. Cũng trong tình huống của bạn, các thành viên trong nhóm của bạn có thêm lợi thế là có người có kiến ​​thức trước giúp đỡ họ.

Đối với thành viên nhóm có kinh nghiệm khác, anh ta không cần phải học đại học nếu anh ta không muốn học bất cứ điều gì mới. Đây là một cơ hội tốt để tìm hiểu một cái gì đó mới và thêm nó vào hộp công cụ của mình.

Và đối với các thành viên trong nhóm thiếu kinh nghiệm, cơ hội được tuyển dụng / làm việc tốt hơn của họ sẽ tăng lên với một khung như CodeIgniter trong sơ yếu lý lịch của họ (thực sự là kiến ​​thức để chứng minh điều đó trong sơ yếu lý lịch của họ).

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.