Offshoring projektu oprogramowania - rozwiązywanie konfliktów [zamknięte]

Miałem za zadanie zarządzać projektem zleconym niektórym ukraińskim programistom.

Firma zatrudniła ich za pośrednictwem Elance po stałej cenie . W tym momencie mój szef zostawił mnie w spokoju, aby sobie z nimi poradzić i wykonać pracę. Stworzyłem szczegółową specyfikację kompletnej rzeczy, którą trzeba było zrobić.

Projekt obejmował radzenie sobie z takimi rzeczami jak XMPP, RabbitMQ i baza danych. Podczas pierwszego spotkania z nimi (zawsze IM) dokładnie wyjaśniłem, co powinni zrobić. Wydawało się, że to rozumieją - i byli bardzo pewni, że da się to łatwo zrobić.

Na razie w porządku. Ale po tygodniu, kiedy się ponownie spotkaliśmy, byli pełni nieporozumień na temat tego, co należy zrobić. Kiedy zapytałem jednego z programistów, czy znał XMPP, powiedział, że po raz pierwszy z nim pracuje. Na naszym pierwszym spotkaniu bardzo konkretnie wspomniałem o złożoności projektu i zastosowanych technologiach. Ponadto wielokrotnie prosiłem ich o napisanie funkcjonalnej specyfikacji dokładnie, w JAKI sposób by to zrobili. Ale powiedzieli „NIE” i nalegali, aby woleli napisać kod. Powiedziałem ok.

Projekt zakończył się po 3 tygodniach i dostarczył to, co było potrzebne. W tym momencie zacząłem przeglądać kod. W większości było to w porządku, ale pojawiają się pewne ważne problemy:

• na stałe zakodowali niektóre rzeczy, które należało rozdzielić na plik konfiguracyjny
• było wiele plików konfiguracyjnych, które musiałem skonsolidować w jednym
• napisali absolutnie NIE dokumentację
• kilka innych drobnych zmian

Poprosiłem ich o wprowadzenie tych zmian (z wyjątkiem dokumentacji) - I mieliśmy kłótnię.

Powiedzieli, że ponieważ cena została ustalona, ​​niesprawiedliwie prosiłem ich o wprowadzenie jakichkolwiek zmian po ukończeniu działającego kodu. Że pracowali nad projektem nieracjonalnie dużo czasu, a teraz całkowicie błędnie było prosić o cokolwiek.

Wreszcie wprowadzili zmiany i projekt się zakończył. Ale pozostawia mi kilka pytań ...

• Zrobili, co było potrzebne, ale ja potrzebowałem tego właściwie , i stąd zmiany. czy naprawdę byłem niesprawiedliwy?

• Dlaczego wyraziłem zgodę na kodowanie bez specyfikacji funkcjonalnej?

• Dlaczego nie upewniłem się, że wszystko zrozumieli za pierwszym razem?

Czy ktoś znajduje się w tej samej pozycji? Czy uważasz, że istnieje lepszy sposób zarządzania projektami zleconymi na zewnątrz?

-- AKTUALIZACJA --

Dzięki za wszystkie opinie - po zastanowieniu się nad całym doświadczeniem mogę stwierdzić ...

• Chociaż z mojej strony nie byłem niejasny w specyfikacjach, z pewnością nie zmusiłem ich do ironii, jak sugerowano. Tak więc na wynos jest: zawsze bądź jak najbardziej szczegółowy - czytaj swoje specyfikacje również z ich perspektywy i zobacz, czy coś przegapiłeś. Powtórz to co najmniej trzy razy.

• Samo określenie, co powinien zrobić kod, to za mało. Musisz określić, jak powinien wyglądać kod. Jaka będzie struktura katalogów; nawet nazwy plików, jeśli to możliwe. Pozwoli ci to zaoszczędzić wiele czasu później. Ściśle określ wytyczne kodowania, zmienne konwencje nazewnictwa, wewnętrzny format dokumentacji itp. Upewnij się, że przestrzegają tych wytycznych, a jeśli nie, krzycz.

• Zażądaj od nich specyfikacji funkcjonalnej - nalegaj, aby była napisana przed jakimkolwiek kodem. To spowoduje wiele nieporozumień i nieporozumień.

• Przejrzyj kod w trakcie jego opracowywania, aby wcześniej zidentyfikować anomalie i je poprawić. Porozmawiaj z nimi przynajmniej raz na dwa dni.

• Na koniec spróbuj nawiązać z nimi dobry kontakt. Spraw, by poczuli, że doceniasz ich pracę. Nie popychaj ich przesadnie, aby pasowały do ​​twoich wytycznych - zamiast tego poproś o to i powiedz im, że znacznie ułatwi ci to utrzymanie kodu po zakończeniu projektu.

Po pierwsze, nie jest to kwestia offshoringu, to kwestia zarządzania dostawcami

Tak, popełniłeś DUŻO błędów…

Zrobili, co było potrzebne, ale ja potrzebowałem tego właściwie, i stąd zmiany. czy naprawdę byłem niesprawiedliwy?

Tak, to jest sprawiedliwe. Jeśli chcesz, aby zrobiono to w określony sposób, powinieneś był to powiedzieć przed uzgodnieniem ceny, aby mogli odpowiednio licytować.

Dlaczego wyraziłem zgodę na kodowanie bez specyfikacji funkcjonalnej? Ponieważ nie chcesz płacić za specyfikację! Dokumentacja jest czasochłonna i kosztowna, czy powinni to zrobić za darmo?

Dlaczego nie upewniłem się, że wszystko zrozumieli za pierwszym razem?

Oni zrozumieli. Ale na twoim pierwszym spotkaniu PO podpisaniu umowy (i ustalonej stałej cenie) jest to, kiedy WYPŁACALIŚCIE JE! Konieczne jest więc ograniczenie kosztów (godzin) tam, gdzie każdy mógł… Zasadniczo poprzez organizowanie tylko jednego spotkania w tygodniu, bez podawania opcji konfuzji.

Oto jak to zrobić następnym razem… W dwóch fazach…

Faza 1: poproś ich o zebranie wymagań, wykonanie analizy systemów i napisanie projektu technicznego i / lub specyfikacji funkcjonalnej (lub napisz to sam). Uzgodnij cenę tej fazy. Wyjaśnij, że z twojej strony nie ma zobowiązania, aby zapewnić im fazę rozwoju. Pamiętaj o uwzględnieniu czasu na spotkanie w cenie.

Faza 2: Poproś ich, aby licytują opracowane na podstawie specyfikacji teraz, gdy oni (i ty) mają, i naprawdę wiedzą, że włożony jest wysiłek. Ponownie pamiętaj o uwzględnieniu czasu na spotkania w cenie. Ponieważ należy uwzględnić niewielki opcjonalny budżet na zmiany.

Edycja: Chcę dodać dodatkowy punkt. Również tutaj wina jest winna, część tamtejszego zadania jest zbyt pomocna w prowadzeniu cię przez zarządzanie projektem i daję znać, gdzie brakuje tego procesu.

Potrzebowałem tego poprawnie

Nie należy go zlecać na zewnątrz, a jeśli tak, upewnij się, że działają one w zespole projektowym i że w tym czasie uczestniczysz w przeglądach kodu.

Projekt zakończył się po 3 tygodniach i dostarczył to, co było potrzebne. W tym momencie zacząłem przeglądać kod.

Ponownie powinieneś przejrzeć kod podczas projektu, a nie później.

Powiedzieli, że ponieważ cena została ustalona, ​​niesprawiedliwie prosiłem ich o wprowadzenie jakichkolwiek zmian po ukończeniu działającego kodu.

Zapłaciłeś im stałą cenę za działający kod. Ups To nie ich wina, tylko twoja. Płać za czas na udział w kontrolowanych przez siebie sprintach, a nie napotkasz tego problemu. Powinieneś zapłacić im za czas i zaakceptowane historie użytkowników, a nie za kod.

Podczas pierwszego spotkania z nimi (zawsze IM) dokładnie wyjaśniłem, co powinni zrobić. Wydawało się, że to rozumieją - i byli bardzo pewni, że da się to łatwo zrobić.

W przypadku projektu całkowicie zleconego na zewnątrz musisz upewnić się, że Twoje specyfikacje są żelazne. Jeśli musisz wyjaśnić coś, co trwa dłużej niż kilka zdań, specyfikacja nie jest kompletna. Właśnie dlatego skręcili ze specyfikacji.

Kiedy zapytałem jednego z programistów, czy znał XMPP, powiedział, że po raz pierwszy z nim pracuje.

Często zleca się outsourcing do popularnych tanich krajów offshoringowych, aby programiści przepompowali swoje CV i umiejętności, by po prostu znaleźć pracę. Często nie martwią się o swoje umiejętności, dopóki go nie wylądują, ponieważ wielu z nich po prostu wznawia budowę, aby wylądować na koncercie, który faktycznie płaci wygodną pensję.

Dlaczego wyraziłem zgodę na kodowanie bez specyfikacji funkcjonalnej?

Tylko Ty możesz sam na to odpowiedzieć, ale weź to jako doświadczenie uczenia się na następny raz.

Firma zatrudniła ich za pośrednictwem Elance po stałej cenie. W tym momencie mój szef zostawił mnie w spokoju, aby sobie z nimi poradzić i wykonać pracę. Stworzyłem szczegółową specyfikację kompletnej rzeczy, którą trzeba było zrobić.

Więc najpierw zawarliście umowę, a potem pozwolili wam napisać specyfikację i zaakceptowali tę specyfikację, aby stać się częścią waszej umowy? Jeśli tak było, to nie twoja wina, to wina twojego kontrahenta. Mógłbyś łatwo napisać specyfikację, dającą im 3 miesiące pracy zamiast 3 tygodni - wszystko w tej samej cenie.

W większości było to w porządku, ale pojawiają się pewne ważne problemy:

• na stałe zakodowali niektóre rzeczy, które należało rozdzielić na plik konfiguracyjny
• było wiele plików konfiguracyjnych, które musiałem skonsolidować w jednym
• napisali absolutnie NIE dokumentację
• kilka innych drobnych zmian

Czy te rzeczy były częścią twojej specyfikacji? Jeśli tak, to ich wina. Jeśli nie, to jest twoje. Jeśli nie było tak naprawdę jasne, czy te rzeczy są zawarte w specyfikacji, to również twoja wina, ponieważ napisałeś dokument. Spróbuj napisać lepszą specyfikację następnym razem.

Niedawno zrobiłem prezentację na temat offshoringu. Nazwano go „Global Outsourcing, 10 wskazówek, które wzmocnią Twój biznes”. Oto podsumowanie 10 wskazówek (pochodzi z maksymalnie 400 projektów zleconych na zewnątrz):

Wybór

1. Unikaj najniższych i najwyższych cen ofertowych . Jest to po prostu oczywiste, że nie chcesz podejmować ryzyka z niższymi licytującymi, a licytujący z wyższą ceną są zwykle mniej wartościowi (wartość / cena) niż mediana.

2. Sprawdź oceny (lub referencje) . Zawsze sprawdzam referencje i oceny.

3. Priorytet motywacji . Przy tej samej cenie wybieram motywowaną ofertę. Na przykład mówienie przez licytanta o twoim projekcie jest bardzo dobrym znakiem.

B. Nadzór

1. Chroń swoją własność intelektualną . To jeden z największych błędów. Zwykle obsługiwany przez platformę, z której korzystasz (np. Vworker lub elance).

2. Odrzuć niestandardowe ramy . Albo ryzykujesz, że będziesz z nim związany, a ściślej z programistą, który go napisał;)

3. Nakładaj standardy . Powiązane z poprzednią wskazówką. Korzystanie ze standardu zwiększa wartość kodu źródłowego, ponieważ jest on zrozumiały dla większej liczby programistów.

4. Przejrzyj wcześnie, często sprawdzaj . Większość problemów można „skorygować”, jeśli przejrzysz kod źródłowy po pierwszym tygodniu lub pracy.

C. Strategia

1. Test dostawców z małymi projektami . Zanim oddaję duży projekt dostawcy, testuję go z jednym lub dwoma mniejszymi projektami.

2. Zaakceptuj wielu oferentów, aby zmniejszyć ryzyko . W przypadku projektu krytycznego wybieram dwóch lub trzech oferentów, a następnie wybieram najlepszą implementację. Działa najlepiej z małymi projektami (poniżej 5000 USD).

3. Złóż komponenty . Inną strategią jest outsourcing komponentów, które montujesz później. Jedną z zalet jest to, że możesz łatwo przełączać się między dostawcami i nikt tak naprawdę nie ma dostępu do całości (zmniejsza ryzyko związane z własnością intelektualną).

Całkowicie zgadzam się z odpowiedzią maple_shaft.

Zaakceptowałeś kod i zakładam, że napisałeś czek, a potem przejrzałeś kod, jakbyś zrobił wszystko wstecz.

Dlaczego wyraziłem zgodę na kodowanie bez specyfikacji funkcjonalnej?

Ponieważ nie zapisałeś tego w umowie. Ponieważ chciałeś, aby praca została wykonana, zaakceptowałeś ich powody, nawet jeśli to właśnie sprawiło ci kłopoty.

Dlaczego nie upewniłem się, że wszystko zrozumieli za pierwszym razem?

Powinieneś dostarczyć im projekt, który Twoim zdaniem działałby. To nie miałoby znaczenia, gdyby nie w pełni zrozumieli. Mam na myśli, że nie zapłaciłeś im za to, więc kto to zrobi? Jak ten kod będzie utrzymywany bez dokumentacji i specyfikacji projektowych. Odpowiedź prawdopodobnie nie będzie .

Powiedzieli, że ponieważ cena została ustalona, ​​niesprawiedliwie prosiłem ich o wprowadzenie jakichkolwiek zmian po ukończeniu działającego kodu.

Masz szczęście, że dokonali żądanych zmian. Mogliby powiedzieć: pech

Czy ktoś znajduje się w tej samej pozycji? Czy uważasz, że istnieje lepszy sposób zarządzania projektami zleconymi na zewnątrz?

Oczywiście inni ludzie są w twojej sytuacji inaczej, cała branża „outsourcingu” nie zaszkodziłaby, wiele firm zaczyna zdawać sobie sprawę, że płacenie (lub czekanie), aby to zrobić 3 i 4 razy jest droższe niż robienie tego dobrze raz .

Przynajmniej robiąc to samodzielnie, możesz codziennie sprawdzać status projektu. Jeśli jesteś z tyłu, są rzeczy, które możesz zrobić, aby kontrolować obrażenia, przynajmniej w teorii.