Jaki jest najlepszy sposób, aby umożliwić klientowi udział w projekcie?

12

Budujemy CRM dla klienta. Teraz, gdy pierwsza duża faza została zakończona, a druga została uzgodniona, klient chciałby podjąć pewne prace, wprowadzając drobne zmiany w schemacie bazy danych i procesach biznesowych w pierwszej fazie, podczas gdy tworzymy drugą .

Nie jestem zdecydowany, czy to w ogóle jest praktyczne, ale zakładając, że tak, chciałbym uzyskać pewne wskazówki, w oparciu o które można podjąć środki, aby to w ogóle wykonalne. Oto co mam do tej pory:

  • Do tej pory klient głównie widział projekt z punktu widzenia użytkownika; najwyraźniej powinno odbyć się dwuczęściowe seminarium, w którym przedstawimy go wewnętrznym działaniom:

    • po pierwsze, pokazując istniejący schemat bazy danych i, na przykład, rozszerzając go,
    • następnie pokazując przykładowy kod i pisząc nowy proces biznesowy w celu ulepszenia schematu.
  • Kod obecnie znajduje się w wewnętrznym repozytorium Subversion. Chociaż moglibyśmy skonfigurować publiczny lub jeden w jego sieci (do którego możemy VPN), uważam, że system rozproszony działałby lepiej. Wydaje mi się, że jestem jedynym, który tak się czuje, więc mogłem skorzystać z dobrych, przekonujących argumentów.
  • Nie jestem pewien, jak nakazać / upewnić się, że kod działający w środowisku produkcyjnym został zatwierdzony. Wygląda na to, że „x dokonał krytycznej, nieudokumentowanej zmiany tuż przed wyjazdem na wakacje; teraz próbujesz znaleźć ten błąd, który występował od czasu, gdy„ katastrofy są nieuniknione. Idealnie byłoby, gdyby wszystkie zmiany przed wdrożeniem:

    • być udokumentowane w systemie śledzenia problemów,
    • występują najpierw w oddzielnym środowisku testowym, oraz
    • muszą przejść zautomatyzowane testy.

    Niestety, wątpię w dyscyplinę, aby jakikolwiek z nich zwyciężył.

Załóżmy, że architektura wtyczki lub osobny projekt nie są wykonalnymi opcjami, ponieważ 1) ten pierwszy nie istnieje, i 2) ten drugi nie pozwoliłby klientowi patrzeć i być może modyfikować istniejącego kodu, co, jak sądzę, zrobiłby nalegać na.

Sören Kuklau
źródło
2
Powiedz im, że potrzebujesz ich do odgrywania roli grzyba. Trzymaj je w ciemności i karm je im.
capdragon
@capdragon Zgadzam się (podobnie jak Mark Whalberg z The Departed )
Chani
1
Czy rozważałeś prawne aspekty takiego porozumienia? Kto jest odpowiedzialny za utrzymanie zmodyfikowanego kodu klienta? Kto jest właścicielem praw autorskich do kodu wyprodukowanego przez ciebie i przez klienta, czy kiedykolwiek chciałbyś sprzedać system lub jego części innemu klientowi?
Jaydee
Tak; zajmowane są aspekty prawne. Prawa autorskie nie są istotne (a raczej nie są problemami specyficznymi dla tego projektu), ponieważ są to kody specyficzne dla klientów, więc i tak są ich właścicielami.
Sören Kuklau

Odpowiedzi:

2

To będzie najmniej ulubiona odpowiedź - ale i tak jest!


Jest to ryzykowne (tak jak pozwolenie nowicjuszowi na prowadzenie nowego samochodu) - ale nie jest to zły pomysł.

Zrozum, dlaczego chcą to zrobić: nie chodzi o to, że mają wolne zasoby, chodzi tylko o to, by poczuć się pod kontrolą.

Co musisz zrobić, to:

  1. Edukuj swojego klienta - oprogramowanie to coś więcej niż kod. Jeśli chcą wziąć udział, pozwól im najpierw przejrzeć aspekty architektoniczne, projekty i tak dalej. Zadaj im pytania i pokaż im implikacje dokonanych wcześniej wyborów.

  2. Powinieneś zawsze wracać z opcjami za / przeciw w podejściach (i dobrze dokumentować te spotkania), ale powinieneś pozwolić im podjąć pewne decyzje. Przynajmniej zaczną doceniać, że niewiele wiedzą - lub przejmą na siebie odpowiedzialność.

  3. Możesz stworzyć oddzielną przestrzeń - na przykład gałęzie, aby musiały być w stanie kodować cokolwiek chcą - rzeczy powinny być należycie przetestowane przed zatwierdzeniem lub scaleniem.

Chociaż wiem, że mogą się zdarzyć komplikacje, każdy problem jest szansą. Jeśli wszystko pójdzie dobrze, twój klient doceni wewnętrzne problemy i zyska większe zaufanie, ponieważ wie (jak), że wykonałeś dobrą robotę!

PS: Aby dać ci wgląd - jestem z Indii; i znam wiele sklepów IT, w których kierownictwo tak naprawdę nie ma pojęcia. Zwykle nie mają nic przeciwko (nawet czują się szczęśliwi), że klient wkłada dodatkowe zasoby, aby upewnić się, że projekt nie pójdzie na śmietnik! To działa świetnie dla nich; wszyscy mają jeden sposób myślenia „Cokolwiek powiesz, proszę pana!”. Nie ma to na celu poniżenia mojego rodaka - ale pokazanie, że wspólny rozwój nie jest taki zły pomysł. W końcu wielu guru zarządzania przedstawia „ podejście prosumenta ” do problemów biznesowych.

Dipan Mehta
źródło
+1 dobra odpowiedź w oparciu o osobiste doświadczenia, tak jak chciał PO.
Sardathrion - przeciwko nadużyciom SE
13

Ojej… Masz dobry pomysł, ale widziałem, jak niechlujne może się to okazać, i obie strony cierpią znacznie. Obecnie utrzymuję taką aplikację.

Dowiedzieć się prawdziwe powody dlaczego klient uzna to za konieczne, aby przyczynić się bezpośrednio do projektu. Czy to dlatego, że chcą teraz, aby projekt był wykonywany szybciej, niż można go realistycznie zrealizować? Czy chcą już zmian, ale boją się ponieść dodatkowe koszty związane z wprowadzaniem zmian specyfikacji lub żądaniem dodatkowych funkcji? Czy w ich organizacji toczy się walka polityczna, w której wewnętrzne zasoby programistyczne chcą większej kontroli i wkładu w projekt lub gdy szukają intensywnej pracy dla wewnętrznych programistów? (ten ostatni trafił dla mnie blisko domu)

Znajdź ich prawdziwe motywacje i odpowiedz na nie, jeśli to możliwe. Fakt, że nawet sugerują, że jest to ogromny znak ostrzegawczy, że kłopoty nadchodzą na drodze. Postaraj się złagodzić ich prawdziwe obawy, zanim zgodzisz się na coś takiego, ponieważ bardziej niż prawdopodobne jest to, że będą silnie kontrolować projekt i wycofają cię, lub spowodują ogromny chaos i nieudany projekt.

EDYCJA: Niestety ten statek popłynął dla ciebie, ale nie rozpaczaj jeszcze. Są jeszcze rzeczy, które możesz zrobić, aby znacznie zminimalizować ból, który nadejdzie. Bez względu na wszystko, upewnij się absolutnie, że jest to JEDEN I TYLKO JEDEN KIEROWNIK PROJEKTU I WŁAŚCICIEL PRODUKTU oraz że ta osoba jest powiązana z Twoją organizacją / firmą. Ta osoba musi mieć zdolność do planowania sprintu, dołączania lub usuwania historii użytkowników i przypisywania zadań do zasobów w Twojej firmie, a także w firmie klienta. Cokolwiek się stanie, upewnij się, że zasoby programistyczne w Twojej firmie nie działają osobno od zasobów klientów, a co ważniejsze, NIEpozwól programistom w Twojej firmie zgłaszać się do kierowników projektów lub właścicieli produktów! Będą albo w pełni korzystać z bezpłatnej pracy nieobjętej umową, albo wyrzucą cię z własnego projektu. To jest pewność.

wałek klonowy
źródło
Pierwsze dwa powody są prawdopodobnie natychmiastowe, ale prawdopodobnie niezmienne; oczywiście gromadzenie wniosków o zmianę, przekazywanie ich nam, płacenie za nie, przeprowadzanie testów wewnętrznych, a następnie samodzielne testowanie, wiąże się z dodatkowymi kosztami. Martwię się, że statek mógł już wypłynąć, dlatego bardziej szukam sposobów na złagodzenie problemu, stąd moje pytanie.
Sören Kuklau,
@ SörenKuklau Przykro mi, że przegrałeś już tę bitwę. Mam zamiar edytować swoją odpowiedź i podać alternatywę.
wałek klonowy
Zgadzam się, wystarczy, aby klient mógł zapłacić . W rzeczywistości naliczaj je dodatkowo za zwiększenie udziału z ich strony!
Chani
6

Z prawnego punktu widzenia pytasz w zasadzie „Jak najlepiej jeździć na osiołku z zasłoniętymi oczami przez pole minowe?”

Z perspektywy programistycznej poprosiłbym o więcej informacji - czy to, o co prosi klient, może zostać zaimplementowane przy użyciu systemu EAV zdefiniowanego przez użytkownika lub za pomocą haków, które można dodać do systemu? Idealnie chciałbym zachować kod klienta tak osobny, jak to możliwe z różnych powodów.

Jonathan Rich
źródło
10
What's the best way to ride a donkey blindfolded through a mine field?Myślę, że odpowiedź brzmi „pijany !!”
FrustratedWithFormsDesigner
„Z prawnego punktu widzenia pytasz w zasadzie:„ Jak najlepiej jeździć na osiołku z zasłoniętymi oczami przez pole minowe? ”.„ Pytanie o odpowiedzialność / winę / potencjalne problemy prawne jest rzeczywiście interesujące i ważne, ale nie dotyczy tutaj. Ładna metafora. :) Jeśli chodzi o architekturę wtyczek lub oddzielny projekt, zobacz moją edycję; nie są realistycznymi perspektywami.
Sören Kuklau,
Jeśli tak jest, co jest nie tak ze sprzedażą klientowi licencji źródłowej do CRM z SLA?
Jonathan Rich
Klient jest prawnie uprawniony do kodu. Nie o to tu chodzi; współpracuje nad tym.
Sören Kuklau,
1
Jeśli klient jest prawnie uprawniony do kodu, najlepszym rozwiązaniem jest oczywiście traktowanie kodu jako własnego, skonfigurowanie kontroli wersji na serwerze i naliczanie opłat za konserwację co godzinę.
Jonathan Rich
3

Ktoś, kto zwykle jest tutaj w roli klienta, który się tu wkrada. Szczerze mówiąc, nie miałbym tego problemu, ponieważ gdyby zaszedł tak daleko, byłbyś w mojej kontroli źródła, używając mojej konfiguracji CI i mojej kontroli jakości do testowania rzeczy. Taki układ może być dość trudny do skonfigurowania - dostaję wiele od konsultantów, zwłaszcza gdy zaczynam działać. Wydaje się, że proces przeszkadza w naliczaniu godzin.

Myślę, że twoja perspektywa jest dość wypaczona. Po pierwsze, pamiętaj, że nie jest to twoja baza kodu, ale nasza baza kodów. Po drugie, w większości przypadków sklep IT po stronie klienta ma znacznie większą motywację, aby upewnić się, że ten produkt działa zgodnie z przeznaczeniem i jest łatwy w utrzymaniu, zarządzaniu i wsparciu w przyszłości. Nurkowanie z powrotem w celu naprawienia błędów nie jest dla nas więcej rozliczalnych godzin, w przeciwieństwie do większości konsultantów. Co więcej, budowanie rzeczy, które mają być łatwo konfigurowalne i zawodzą w przewidywalny sposób, są znacznie ważniejsze, gdy posiadasz stronę operacyjną monety. Możesz po prostu skończyć z projektem wyższej jakości, ponieważ część personelu programistycznego nie jest ograniczona godzinami rozliczanymi.

Jeśli chodzi o to, jak sprawić, by działało, DCVS jest zdecydowanie właściwą drogą, jeśli można to zrobić. Wybór czegoś neutralnego (bitbucket, github) może pomóc. Posiadanie CI na miejscu jest również darem niebios - trudniej jest wydostać się z bicza, gdy wszyscy wiedzą, że z ostatniego bicia wyszedł z bicza. Jeśli możesz zmusić rzeczy do wdrożenia za pośrednictwem CI - co zwykle musimy wymusić na dostawcach - możesz naprawdę upewnić się, że wszystkie zmiany zostały zatwierdzone. Jeśli chodzi o trening, czy zastanawiałeś się nad parowaniem z klientem przez kilka dni? To może być dobry sposób na ustanowienie bocznych więzi, których potrzebujesz. Ogólnie rzecz biorąc, najlepszym rozwiązaniem jest przekonanie wszystkich, że należą do tej samej drużyny. Ponieważ są w tej samej drużynie.

Wyatt Barnett
źródło
3

Wydaje się, że jest to kwestia zarządzania, ponieważ jest to kwestia techniczna. Miałem do czynienia z takimi sytuacjami zarówno w firmach konsultingowych, jak i programistycznych. Z ogólnego „Jaką wartość klient wydostanie z oprogramowania?” oraz „Ile wysiłku będę potrzebować, aby utrzymać go w postprodukcji?” to jest dla ciebie dobra sytuacja. Wielu klientów nalega na zaangażowanie swoich pracowników. To zajmie jednak dużo pracy.

Począwszy od celu, będziesz potrzebować dobrego Oświadczenia o pracy . Spowoduje to wyświetlenie listy haczyków i celów. Role i obowiązki matryca jest mniejsza legalistyczna dokument, który opisuje, kto jest właścicielem każdego elementu, który jest zaangażowany, a kto po prostu musi zostać poinformowany. Oba zakładają, że masz dobrze zdefiniowaną strukturę podziału pracy, która zawiera na niskim poziomie (wystarczająco niskim, aby oszacować), jakie jest każde zadanie.

Pod względem tworzenia jest to zwykle odwrotna kolejność: Zakres (który wyraźnie już masz) -> WBS (który możesz mieć) -> Matryca ról i obowiązków -> SOW.

Gdy masz już jasno zdefiniowane prawo własności, czas zarządzać kodem i środowiskami. Jestem dość niezależny od narzędzi do zarządzania kodami. Powiem tylko, że niezbędne jest dokonanie przeglądu kodu dla wszystkiego, co zostało zrobione przez kogoś spoza zespołu podstawowego. Jeśli narzędzie, którego używasz, oznacza to tym lepiej. Chcesz uniknąć sytuacji, w której ktoś zaciska coś, co stoi w sprzeczności z wcześniejszymi decyzjami architektonicznymi. Koncepcja 4 oczu (2 dodatkowe oczy oceniające wszystko) to najważniejsza taktyczna decyzja, jaką możesz podjąć.

Środowiska są również bolesne w zarządzaniu. Zazwyczaj zdarzały mi się sytuacje, w których „wykonujemy pracę nad naszym środowiskiem, kiedy to robimy, trafia do ciebie” i zarówno sprzedawca, jak i klient walczą. Twoja sytuacja wydaje się bardziej złożona. Radzę spróbować znaleźć sposób, aby mogli pracować w twoim środowisku, dopóki projekt nie zostanie ukończony. Jeśli znajdziesz sposób na przeszkolenie klienta w zarządzaniu środowiskiem (nie zakładaj, że jest w tym dobry), tym lepiej.

Kilka innych zastrzeżeń ...

  1. Nie zakładaj, że klient ma taką samą wydajność jak twój zespół. (Dostaniesz niespodzianki w górę od wiedzy o domenach, w dół niespodzianki dotyczące prędkości specyficznej dla twojego oprogramowania).

  2. Nie zakładaj, że klient zna Twoją metodologię.

  3. Nie zakładaj, że klient podziela pracę Twojego zespołu. (Widziałem niespodzianki zarówno w górę, jak i w dół).

  4. Spędź dużo czasu na szkoleniu i kolokacji.

  5. Każda godzina spędzona na uczeniu klienta rozwiązywania problemów pozwoli zaoszczędzić wiele dni w przyszłości.

  6. Wykorzystaj klienta do pracy za jego wewnętrzną organizacją i znajdź ekspertów w zakresie treści i pytań dotyczących domeny.

  7. Wykorzystaj klienta do sprzedaży szkolenia jego organizacji.

  8. Domyślnie zaangażowanie klientów w proces rozwoju zmusi cię do myślenia jak profesjonalna firma usługowa. David Maister napisał najlepszą książkę na ten temat. Nawet jeśli tylko 20% jest dla Ciebie istotne, warto je przeczytać.

Pomimo tych wszystkich zastrzeżeń, w tym klienci w twoich zespołach mogą zdziałać cuda, aby przybliżyć cię do kupujących. Klienci ci będą najprawdopodobniej przyszłymi referencjami. Powodzenia w jak najlepszym wykorzystaniu tej sytuacji!

MathAttack
źródło
1
Zgadzam się, ale jeśli chodzi o jeden z problemów technicznych, każda organizacja posiadająca własne repozytorium i zestaw narzędzi jest w porządku, ale jeśli jest to droga, którą podążasz, zadeklarowanie źródła „głównego” ma kluczowe znaczenie: twoje, ich lub osobno utrzymany „wspólny mistrz”. Bez „mistrza” zdolność do integracji i częściowego przywracania nie będzie, jak podejrzewa OP, problematyczna. Pojedyncze repozytorium „wzorcowe” uprościłoby testy mapowania i defekty z powrotem do pojedynczej wersji źródłowej, zamiast podwójnego mapowania najpierw do wersji wzorcowej, a następnie do każdej niezależnej „lokalnej” kopii.
JustinC,
1
Mogą istnieć polityczne lub ekonomiczne powody, dla których którakolwiek ze stron waha się porzucić kontrolę lub przyznać dostęp, ale jeśli celem jest wspólna praca, jednocześnie żadna ze stron nie będzie skuteczna bez uprzedniej negocjacji w sprawie kontroli. Na przykład. kto jest odpowiedzialny za kapitana i go nadzoruje, w jaki sposób rozstrzygane są spory o kapitana i jak przeniesiesz kontrolę z mistrza z powrotem na klienta (jeśli jako firma zlecająca utrzymujesz i kontrolujesz kapitana).
JustinC
@JustinC - słyszę cię. Jeden z moich projektów ma połowę etatu, czyli synchronizacja dwóch repozytoriów defektów.
MathAttack,
0

Twój klient powinien zdecydowanie zapoznać się z tym, jak wszystko jest skonfigurowane, powinien być wymagany do wypisania się w pierwszej fazie. Powinieneś naciskać na pozwolenie swojemu klientowi na edycję czegokolwiek bezpośrednio, powinien on wypełnić prośbę o zmianę, która zostanie wprowadzona do systemu śledzenia problemów i będzie traktowana priorytetowo z resztą pracy. Od Ciebie i Twojego klienta zależy decyzja, które wnioski wykraczają poza zakres umowy. Sposób, w jaki to się dzieje, powinien zostać opracowany w ramach przepływu pracy / dokumentu zarządzania zmianami. Jeśli takiego nie ma, zdecydowanie sugeruję, aby go utworzyć i poprosić klienta, aby zgodził się, że jest to proces, za pomocą którego może on zmieniać rzeczy i wprowadzać je pisanie. W przeciwnym razie niewiele możesz zrobić poza modlitwą, że nic nie pójdzie źle.

Ryathal
źródło