Vượt qua một dự án phần mềm - Giải quyết xung đột [đã đóng]


11

Tôi đã được giao nhiệm vụ quản lý một dự án được thuê ngoài cho một số nhà phát triển Ucraina.

Công ty đã thuê họ thông qua Elance với mức giá cố định . Vào thời điểm đó, ông chủ của tôi đã để tôi một mình xử lý chúng và hoàn thành công việc. Tôi đã tạo ra một đặc điểm kỹ thuật chi tiết của điều hoàn chỉnh cần phải được thực hiện.

Dự án liên quan đến việc xử lý những thứ như XMPP, RabbitMQ và Cơ sở dữ liệu. Trong cuộc họp đầu tiên của tôi với họ (luôn IM) tôi đã giải thích cặn kẽ những gì họ cần làm. Họ dường như hiểu điều đó - và họ rất tự tin rằng nó sẽ được thực hiện dễ dàng.

Càng xa càng tốt. Nhưng sau một tuần, khi chúng tôi gặp lại nhau, họ đầy những hiểu lầm về những gì cần phải làm. Khi tôi hỏi một trong những nhà phát triển rằng anh ta có biết XMPP không, anh ta nói rằng lần đầu tiên anh ta làm việc với nó. Trong cuộc họp đầu tiên của chúng tôi, tôi đã đề cập rất cụ thể về sự phức tạp của dự án và các công nghệ liên quan. Thêm vào đó, tôi đã nhiều lần yêu cầu họ viết một đặc tả chức năng chính xác CÁCH họ sẽ làm điều đó. Nhưng họ nói KHÔNG, và khăng khăng rằng họ thà viết mã. Tôi nói OK.

Dự án hoàn thành sau 3 tuần và họ đã giao những gì cần thiết. Lúc đó tôi bắt đầu xem lại mã. Phần lớn mọi thứ đều ổn, nhưng có một số vấn đề quan trọng:

  • họ mã hóa cứng một số thứ cần tách ra thành tệp cấu hình
  • có nhiều tập tin cấu hình mà tôi cần được hợp nhất trong một
  • họ đã viết hoàn toàn KHÔNG có tài liệu
  • một số thay đổi nhỏ khác

Tôi yêu cầu họ thực hiện những thay đổi này (trừ tài liệu) - Và, chúng tôi đã có một cuộc tranh luận.

Họ nói, vì giá đã được ấn định, tôi đã không công bằng khi yêu cầu họ thực hiện bất kỳ thay đổi nào sau khi họ hoàn thành mã làm việc. Rằng họ đã làm việc trong một khoảng thời gian không hợp lý cho dự án và bây giờ việc yêu cầu bất cứ điều gì là hoàn toàn sai lầm.

Cuối cùng bây giờ họ đã thực hiện các thay đổi, và dự án đã kết thúc. Nhưng nó để lại một số câu hỏi trong tâm trí tôi ...

  • Họ đã làm những gì cần thiết nhưng tôi cần nó được thực hiện đúng , và do đó những thay đổi. tôi thực sự không công bằng?

  • Tại sao tôi đồng ý cho phép họ viết mã mà không có đặc tả chức năng?

  • Tại sao tôi không chắc chắn rằng họ hiểu mọi thứ lần đầu tiên?

Có ai tìm thấy chính họ ở cùng một vị trí? Bạn có nghĩ rằng có một cách tốt hơn để quản lý các dự án thuê ngoài?

- CẬP NHẬT -

Cảm ơn tất cả các ý kiến ​​- sau khi phản ánh toàn bộ kinh nghiệm, tôi có thể kết luận ...

  • Mặc dù tôi không mơ hồ về các thông số kỹ thuật từ phía tôi, tôi chắc chắn đã không làm cho chúng trở nên sắt như đề xuất. Vì vậy, việc bỏ đi là: luôn luôn cụ thể nhất có thể - đọc thông số kỹ thuật của bạn từ quan điểm của họ và xem nếu bạn bỏ lỡ điều gì. Lặp lại ít nhất ba lần.

  • Chỉ cần xác định những gì mã nên làm nó là không đủ. Bạn phải xác định mã được cho là trông như thế nào. Cấu trúc thư mục sẽ là gì; thậm chí tên tập tin nếu có thể. Điều này sẽ cứu bạn khỏi nhiều phiền toái sau này. Chỉ định nghiêm ngặt các nguyên tắc mã hóa, quy ước đặt tên biến, định dạng tài liệu nội bộ, v.v ... Hãy xem họ tuân thủ các nguyên tắc đó và nếu không, hãy hét lên.

  • Yêu cầu một đặc tả chức năng từ phía họ - nhấn mạnh rằng nó được viết trước bất kỳ mã nào. Điều này sẽ nhận được rất nhiều nhầm lẫn và hiểu lầm ra khỏi đường đi.

  • Xem lại mã khi nó đang được phát triển để bạn xác định sự bất thường trước đó và sửa chúng. Nói chuyện với họ ít nhất một lần mỗi ngày.

  • Cuối cùng, hãy cố gắng thực hiện một mối quan hệ tốt với họ. Làm cho họ cảm thấy rằng bạn đánh giá cao công việc của họ. Đừng đẩy chúng quá mức để phù hợp với hướng dẫn của bạn - thay vào đó hãy yêu cầu họ làm như vậy và nói với họ rằng điều đó sẽ giúp duy trì mã dễ dàng hơn cho bạn một khi họ hoàn thành dự án.


1
Tôi chưa bao giờ thấy một dự án ngoài khơi đi tốt như vậy. Tôi nghĩ rằng tôi đang ở trong một câu chuyện chiến tranh khi tôi bắt đầu đọc nó.
smp7d

Câu trả lời:


13

Trước hết, đây không phải là vấn đề của việc bảo vệ, đó là vấn đề quản lý nhà cung cấp

Vâng, bạn đã thực hiện ALOT của những sai lầm ...

Họ đã làm những gì cần thiết nhưng tôi cần nó được thực hiện đúng, và do đó những thay đổi. tôi thực sự không công bằng?

Vâng, thật công bằng, Nếu bạn muốn nó được thực hiện theo một cách nhất định, bạn nên nói rằng trước khi giá được thỏa thuận, để họ có thể trả giá phù hợp.

Tại sao tôi đồng ý cho phép họ viết mã mà không có đặc tả chức năng? Bởi vì bạn không muốn TRẢ TIỀN cho thông số kỹ thuật! Tài liệu tốn thời gian và tốn kém, họ có nên làm miễn phí không?

Tại sao tôi không chắc chắn rằng họ hiểu mọi thứ lần đầu tiên?

Họ đã hiểu. Nhưng trong cuộc họp nắm tay của bạn SAU hợp đồng đã được ký kết (và giá cố định đã đồng ý) là khi bạn BỎ QUA NÓ! Vì vậy, cần phải cắt giảm chi phí (giờ) khi mọi thứ họ có thể .. Về cơ bản chỉ bằng cách tổ chức một cuộc họp một tuần, không đưa ra bất kỳ tùy chọn gây nhiễu nào.

Dưới đây là cách thực hiện điều này vào lần tới, trong hai giai đoạn

Giai đoạn 1: Yêu cầu họ Tập hợp các yêu cầu, thực hiện phân tích hệ thống và viết Thiết kế kỹ thuật và \ hoặc Thông số chức năng (Hoặc tự viết). Đồng ý về giá cho Giai đoạn này. Hãy chắc chắn để giải thích không có cam kết về phía bạn để cung cấp cho họ giai đoạn phát triển. Hãy chắc chắn bao gồm thời gian cho cuộc họp trong giá.

Giai đoạn 2: Yêu cầu họ đặt giá thầu được phát triển dựa trên thông số kỹ thuật mà họ (và bạn) có, và thực sự biết nỗ lực có liên quan. Một lần nữa hãy chắc chắn bao gồm thời gian cho các cuộc họp trong giá. Bởi vì để bao gồm một ngân sách tùy chọn nhỏ cho những thay đổi.


Chỉnh sửa: Tôi muốn thêm một điểm bổ sung .. Nhà cung cấp cũng có lỗi ở đây, một phần của công việc là quá giúp hướng dẫn bạn với quản lý dự án và cho bạn biết nơi nào sẽ xảy ra trong quá trình ngắn.


2
Bạn quên giai đoạn 3 và giai đoạn 4: ??? lợi nhuận :-)
Ramhound

3
Làm thế nào bạn có thể yêu cầu một thực thể bên ngoài để viết thông số chức năng của bạn? Các đặc tả chức năng là các yêu cầu của chính dự án mà bạn muốn chúng làm việc. Nếu không, bạn đang cho họ tiền và nói với họ, "Giải quyết vấn đề, ... Tôi không biết, tìm hiểu xem phần mềm nên làm gì, tôi không thể bị làm phiền."
maple_shaft

1
@maple_Shaft Điểm hay, Thu thập yêu cầu là một phần của Giai đoạn 1. Tôi sẽ cập nhật câu trả lời của mình.
Morons

1
-1 cho câu chuyện giáo điều về thác nước lỗi thời

3
@JarrodRoberson Tôi không phải là fan boy của bất kỳ phương pháp cụ thể nào. Mỗi cái đều có giá trị, nhưng nói rằng họ thất bại đơn giản vì họ không sử dụng Agile là sai.
Morons

17

Tôi cần nó được thực hiện đúng

Sau đó, không thuê ngoài nó, hoặc nếu bạn làm thì hãy chắc chắn rằng họ làm việc trong nhóm dự án của bạn và rằng bạn tham gia vào các đánh giá mã tại thời điểm đó.

Dự án hoàn thành sau 3 tuần và họ đã giao những gì cần thiết. Lúc đó tôi bắt đầu xem lại mã.

Một lần nữa, bạn nên xem lại mã trong dự án, không phải sau đó.

Họ nói, vì giá đã được ấn định, tôi đã không công bằng khi yêu cầu họ thực hiện bất kỳ thay đổi nào sau khi họ hoàn thành mã làm việc.

Bạn đã trả cho họ giá cố định cho mã làm việc. Giáo sư. Đó không phải là lỗi của họ, là của bạn. Trả tiền cho thời gian của họ để tham gia chạy nước rút mà bạn kiểm soát và bạn sẽ không gặp phải vấn đề này. Bạn nên trả tiền cho họ theo thời gian và chấp nhận các câu chuyện của người dùng, không phải cho mã.

Trong cuộc họp đầu tiên của tôi với họ (luôn IM) tôi đã giải thích cặn kẽ những gì họ cần làm. Họ dường như hiểu điều đó - và họ rất tự tin rằng nó sẽ được thực hiện dễ dàng.

Khi làm việc với một dự án hoàn toàn thuê ngoài, bạn cần chắc chắn rằng các thông số kỹ thuật của bạn là sắt. Nếu bạn phải giải thích bất cứ điều gì mất nhiều thời gian hơn một vài câu, thì thông số của bạn không hoàn thành. Đây là lý do tại sao họ đi lang thang từ spec.

Khi tôi hỏi một trong những nhà phát triển rằng anh ta có biết XMPP không, anh ta nói rằng lần đầu tiên anh ta làm việc với nó.

Điều này là phổ biến khi gia công cho các quốc gia có chi phí thấp phổ biến cho các nhà phát triển để vượt quá sơ yếu lý lịch và kỹ năng của họ chỉ để đạt được công việc. Họ thường không lo lắng về khả năng của mình cho đến khi họ hạ cánh nó, vì nhiều người trong số họ chỉ tiếp tục xây dựng để đạt được hợp đồng thực sự trả mức lương đủ sống.

Tại sao tôi đồng ý cho phép họ viết mã mà không có đặc tả chức năng?

Chỉ có bạn mới có thể tự trả lời câu hỏi này, nhưng hãy xem nó như một kinh nghiệm học tập cho lần sau.


2
Tôi không đồng ý với "Nếu bạn muốn nó được thực hiện đúng cách, đừng tìm nguồn đó".
Morons

1
@Morons Quyền của bạn tất nhiên, đó là một điều lười biếng để nói. Tôi chỉ mặc định cho khung suy nghĩ đó bởi vì các công ty bị thu hút nhiều nhất bởi triển vọng của các bên ngoài là những người thiếu kỷ luật nhất để làm điều đó một cách chính xác. Nếu họ giải quyết vấn đề nội bộ của họ đến nơi họ có thể làm điều đó một cách chính xác, thì có lẽ họ sẽ ít có nhu cầu thậm chí ra nước ngoài ngay từ đầu.
maple_shaft

3
Nó sẽ nói "Nếu bạn muốn nó được thực hiện đúng cách, đừng mong đợi chất lượng từ người trả giá thấp nhất" , một người bạn là một nhiếp ảnh gia tự do nói "Khách hàng rẻ nhất, có những cuộc

1
Tôi cũng không đồng ý với tuyên bố đó, bạn có thể có cùng một vấn đề với các nhóm nội bộ hoặc cửa hàng phát triển địa phương.

7

Công ty đã thuê họ thông qua Elance với mức giá cố định. Vào thời điểm đó, ông chủ của tôi đã để tôi một mình xử lý chúng và hoàn thành công việc. Tôi đã tạo ra một đặc điểm kỹ thuật chi tiết của điều hoàn chỉnh cần phải được thực hiện.

Vì vậy, hai bạn lần đầu tiên thực hiện một hợp đồng và sau đó họ cho phép bạn viết một thông số, và họ chấp nhận thông số đó để trở thành một phần của hợp đồng của bạn? Nếu đó là như vậy, thì đó không phải là lỗi của bạn, đó là lỗi của nhà thầu của bạn. Bạn có thể dễ dàng viết một thông số kỹ thuật cho họ 3 tháng làm việc thay vì 3 tuần - tất cả đều có cùng một mức giá.

Phần lớn mọi thứ đều ổn, nhưng có một số vấn đề quan trọng:

  • họ mã hóa cứng một số thứ cần tách ra thành tệp cấu hình
  • có nhiều tập tin cấu hình mà tôi cần được hợp nhất trong một
  • họ đã viết hoàn toàn KHÔNG có tài liệu
  • một số thay đổi nhỏ khác

Những điều này là một phần của thông số kỹ thuật của bạn? Nếu họ là, đó là lỗi của họ. Nếu không, nó là của bạn. Nếu nó không thực sự rõ ràng nếu những điều này được chứa trong thông số kỹ thuật, thì đó cũng là lỗi của bạn, vì bạn đã viết tài liệu. Hãy cố gắng viết một thông số tốt hơn vào lần tới.


3

Tôi đã làm một bài thuyết trình trước đây về offshoring. Nó được gọi là "Gia công toàn cầu, 10 mẹo để trao quyền cho doanh nghiệp của bạn". Dưới đây là tóm tắt của 10 lời khuyên (điều này đến từ tối đa 400 dự án thuê ngoài):

Một sự lựa chọn

  1. Tránh các nhà thầu thấp nhất và cao nhất . Điều này là hiển nhiên, bạn không muốn chấp nhận rủi ro với các nhà thầu thấp hơn và các nhà thầu cao nhất có xu hướng ít giá trị (giá trị / giá) hơn so với trung bình.

  2. Kiểm tra xếp hạng (hoặc tài liệu tham khảo) . Tôi luôn kiểm tra tài liệu tham khảo và xếp hạng.

  3. Ưu tiên động lực . Với giá bằng nhau, tôi chọn giá thầu đã được thúc đẩy. Ví dụ, có nhà thầu nói về dự án của bạn đúng là một dấu hiệu rất tốt.

B. Giám sát

  1. Bảo vệ tài sản trí tuệ của bạn . Đây là một trong những sai lầm lớn nhất. Thường được xử lý bởi nền tảng bạn sử dụng (chẳng hạn như vworker hoặc elance).

  2. Từ chối khung tùy chỉnh . Hoặc bạn có nguy cơ bị ràng buộc với nó, hoặc cụ thể hơn là nhà phát triển đã viết nó;)

  3. Áp đặt tiêu chuẩn . Liên quan đến mẹo trước. Sử dụng tiêu chuẩn làm tăng giá trị của mã nguồn của bạn vì có thể hiểu được bởi một số lượng lớn hơn các nhà phát triển.

  4. Xem lại sớm, xem xét thường xuyên . Hầu hết các vấn đề có thể được "điều chỉnh" nếu bạn xem lại mã nguồn sau tuần đầu tiên hoặc công việc.

C. Chiến lược

  1. Nhà cung cấp thử nghiệm với các dự án nhỏ . Trước khi tôi cung cấp một dự án lớn cho một nhà cung cấp, tôi đã thử nghiệm nó với một hoặc hai dự án nhỏ hơn.

  2. Chấp nhận nhiều nhà thầu để giảm rủi ro . Đối với dự án quan trọng, tôi chọn hai hoặc ba nhà thầu sau đó tôi thực hiện tốt nhất. Làm việc tốt nhất với các dự án nhỏ (dưới $ 5000).

  3. Lắp ráp linh kiện . Một chiến lược khác là thuê ngoài các thành phần mà bạn lắp ráp sau này. Một lợi thế là bạn có thể dễ dàng chuyển đổi giữa các nhà cung cấp và không ai thực sự có quyền truy cập vào toàn bộ (giảm rủi ro sở hữu trí tuệ).


1

Tôi hoàn toàn đồng ý với câu trả lời của maple_shaft.

Bạn đã chấp nhận mã và tôi giả sử đã viết séc, sau đó xem lại mã, bạn sắp xếp mọi thứ ngược lại.

Tại sao tôi đồng ý cho phép họ viết mã mà không có đặc tả chức năng?

Bởi vì bạn đã không viết nó vào hợp đồng. Vì bạn muốn công việc được thực hiện, bạn đã chấp nhận lý do của họ, mặc dù đó là điều khiến bạn gặp rắc rối.

Tại sao tôi không chắc chắn rằng họ hiểu mọi thứ lần đầu tiên?

Bạn nên cung cấp cho họ một thiết kế mà bạn cảm thấy sẽ làm việc. Sau đó, nó sẽ không thực sự quan trọng nếu họ không hiểu đầy đủ. Tôi có nghĩa là bạn đã không trả tiền cho họ để làm điều đó vì vậy ai sẽ làm điều đó? Làm thế nào mã này sẽ được duy trì mà không có bất kỳ tài liệu và thiết kế cụ thể. Câu trả lời có thể sẽ không có .

Họ nói, vì giá đã được ấn định, tôi đã không công bằng khi yêu cầu họ thực hiện bất kỳ thay đổi nào sau khi họ hoàn thành mã làm việc.

Bạn thật may mắn khi họ thực hiện những thay đổi bạn muốn. Họ có thể nói: may mắn khó khăn

Có ai tìm thấy chính họ ở cùng một vị trí? Bạn có nghĩ rằng có một cách tốt hơn để quản lý các dự án thuê ngoài?

Tất nhiên những người khác ở vị trí của bạn nếu không, toàn bộ ngành công nghiệp "thuê ngoài" sẽ không bị tổn thương, nhiều công ty bắt đầu nhận ra rằng phải trả tiền (hoặc chờ đợi) để làm điều đó đắt hơn 3 và 4 lần sau đó thực hiện ngay .

Ít nhất bằng cách tự làm, bạn có thể kiểm tra trạng thái của dự án hàng ngày. Nếu bạn đứng đằng sau có những điều bạn có thể làm để kiểm soát thiệt hại, ít nhất là trên lý thuyết.


1
companies are starting to realize having to pay ... to do it 3 and 4 times is more expensive then doing it right once.Nó còn hơn thế nữa, tôi chỉ nghĩ rằng giai đoạn trăng mật của ngành công nghiệp với sự phát triển phần mềm bên ngoài sắp kết thúc và nhiều công ty bắt đầu nhận ra rằng đó không phải là con bê vàng mà họ nghĩ nó sẽ ( hoặc được nói là nó sẽ được tư vấn ). Hầu hết các quản lý hút và họ không biết tại sao, vì vậy họ tìm kiếm viên đạn bạc để giải quyết tất cả các vấn đề của họ. Gia công là tuyệt vời nếu bạn làm đúng, nhưng hầu hết không có loại kỷ luật đó.
maple_shaft
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.