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

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.

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.

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ść.

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.

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.

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!

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.