Witam
Niedawno miała miejsce pewna sytuacja kiedy to klient wprowadził poprawki do projektu technicznego polegające na zmianie nazw komponentów. w 90% przypadków zmiana była kierowana czysto subiektywną oceną. Stało się to w czasie gdy projekt jako taki był w 80% zakończony, a owe zmiany wprowadziły wiele zamieszania.
Jestem ciekaw jakie jest wasze zdanie, wasze doświadczenia. Czy to dobry pomysł aby pozwolić klientowi wpływać na kształt kodu źródłowego?
pzdr
Zależy kim jest klient. Jeśli klient jest końcowym użytkownikiem systemu (np. dostaje GUI + jakieś aplikacje webowe), to najlepiej trzymać go jak najdalej kodu źródłowego. Gość, który się miesza w techniczne aspekty projektu, zwykle nie mając pojęcia o co chodzi, to tragedia.
Natomiast jeśli klientem jest inna firma, dla której robimy biblioteki / wystawiamy jakiś interfejs, to czasem dobrze jest się spotkać i obgadać również niskopoziomowe sprawy typu: jak to jest/będzie zaimplementowane. Choć i tak ważniejsze jest dobre dospecyfikowanie interfejsów. Natomiast pozwolenie na "mieszanie sobie w kodzie" to już zbyt daleko posunięta poufałość.
Hmm, z drugiej strony... Ostatnio pracujemy z taką jedną firmą (my jesteśmy klientem), która ma problemy z dostarczeniem systemu działającego wg założeń. Stop, źle. Ma problemy z dostarczeniem systemu działającego w ogóle. Zwykle przy trzeciej poprawce, 2 miesiące po terminie udaje im się dostaczyć coś używalnego, choć bardzo dalekiego od specyfikacji, na którą się sami zgodzili. I aż się prosi, żeby wziąć ten ich kod i w nim namieszać [diabel]. Albo lepiej przepisać od nowa.
Jeszcze inna sprawa to audyty. Klient może chcieć mieć pewność, czy np. aplikacja, którą kupił jest bezpieczna. Wtedy specjalistyczna ffirma powinna mieć wgląd w kody źródłowe, ale nie po to by tam mieszać, tylko by zasugerować odpowiednie poprawki.
Żadna zewnętrzna firma pod żadnym pozorem nie ma prawa dotykać kodu źródłowego. Zależnie od warunków może (lub nie) mieć prawo do wglądu, oceny, konsultacji czy nawet żądania zmian, ale to twórca jest za kod odpowiedzialny.
A co by było, gdyby zmiana wprowadzona przez klienta (apostrof dodany przez przypadek w zapytaniu SQL) spowodowała błędy w aplikacji? To nie klient będzie odpowiadał za konsekwencje (że skasowało zawartość całego repozytorium dokumentów sklepu - przypadek z życia wzięty; dobrze, że był backup), tylko twórca aplikacji, bo to jego program to zrobił.
Ty ponosisz odpowiedzialność, tylko Ty zmieniaj kod. Proste.
Ideałem jest sytuacja, kiedy najpierw powstaje specyfikacja, która oddaje całkowicie oczekiwania klienta, więc nie ma już potrzeby, żeby interesował go potem kod, o ile się zachowuje zgodnie ze specyfikacją...
Ideałem byłoby ponadto, żeby – do czasu ostatecznego odbioru klient w ogóle nie wiedział nawet o tym, że jest jakiś kod, który można modyfikować. Po odbiorze zaś dostaje źródła niech sobie robi co chce, pamietając o tym, że nie udzielimy mu jakiegokolwiek wsparcia jeżeli sam sobie coś w programie pozmieniał lub najął do tego kogoś innego...
Rzeczywistośc jednak nie jest idealna... :/
Witam
Dzięki za odpowiedzi. Cała sytuacja wygląda tak ,że pracujemy z działem IT innej firmy. Z jednej strony rozumiem ich podejście gdyż kupują całkowity produkt , a nie tylko funkcjonalność i jest jasne ,że np. w przypadku zmiany dostawcy rozwiązań będzie im zależało aby kod jak najłatwiej i najszybciej (czyli najtaniej) dało się zastosować. Ale z drugiej strony sposób kodowania stanowi bezpośrednie narzędzie wykonawców i opiera się często na pewnych standardach i praktykach istniejących w firmie. Znaczny procent uwag naszego klienta opierał się (oczywiście w moim przekonaniu) na zupełnie subiektywnym podejściu do lepszego czy gorszego rozwiązania. Byłem ciekaw jak to wygląda w przypadku reszty świata : ), dlatego dzięki za wypowiedzi.
Ps. Oczywiście wymagania klienta czyli specyfikacja funkcjonalna to zupełnie inna bajka.