Jak mam opisać proces uczenia się kodu innej osoby? (W sytuacji fakturowania.) [Zamknięte]

Edycja: Justin Cave dobrze stwierdził, że ten rodzaj komunikacji powinien być na pierwszym miejscu w moich cytatach / szacunkach. W takim przypadku nadal jestem zainteresowany tym, jakiego języka używają ludzie, aby opisać działania związane z „uczeniem się kodu”. Zwłaszcza dla firmy, która wcześniej nie miała do czynienia z kontrahentami oprogramowania. Zakończ edycję

Mam umowę na aktualizację oprogramowania wewnętrznego dla dużej firmy. Firma zażądała wielu dodatków do funkcji i kilku poprawek błędów. To moja pierwsza praca w stylu freelancera.

Najpierw musiałem zapoznać się z działaniem aplikacji - nauczyłem się jej, jakbym był użytkownikiem.

Następnie musiałem nauczyć się, jak działa oprogramowanie. Zacząłem od ogólnych koncepcji, a następnie zawęziłem się do niezbędnych szczegółów, zanim zacząłem pracować nad każdą poprawką i funkcją.

Przynajmniej na początku projektu zajęło mi dużo więcej czasu, aby nauczyć się istniejącego kodu niż napisać dodatkowe funkcje.

Jak mogę opisać proces uczenia się istniejącego kodu na fakturze? (Ta część firmy zwykle zajmuje się własnymi sprawami, więc nie ma dużego doświadczenia w kontaktach z kontrahentami oprogramowania, takimi jak ja, i obawiam się, że nie rozumieją kosztów uczenia się czyjegoś kodu). Nie chcę po prostu poświęcać czasu nauki na faktyczną aktualizację funkcji, ponieważ w niektórych przypadkach mogłoby to wyglądać na „proste zadanie”, jakby zajęło mi to zbyt wiele czasu. Chcę podzielić fakturę na odpowiednie etapy i poinformować, że pobieram duży koszt nauki kodu innego użytkownika, zanim będę mógł dodać własny kod.

Czy istnieje standardowy sposób opisywania tego rodzaju czynności podczas fakturowania za pracę?

Zafakturowałbym takie zadania, jak „Przejrzyj istniejącą funkcjonalność” i / lub „Przejrzyj istniejący kod”. W zależności od złożoności nowych funkcji dodam zadanie „Zaprojektuj xxx”, które obejmuje czas poświęcony na rozszyfrowanie punktów integracji w istniejącym kodzie.

Myślę, że dobrym pomysłem jest wyjaśnienie klientowi, że przyspieszenie nowego konsultanta wiąże się z dodatkowymi kosztami - i jeśli będą zadowoleni z rezultatu, dalsza praca z tym samym konsultantem prawdopodobnie ich uratuje. pieniądze.

Diagnoza problemu.

To znany termin, jeśli kiedykolwiek naprawisz auto lub pójdziesz do lekarza, diagnoza jest powszechnym terminem na określenie, co jest nie tak. Jest również dokładny, musisz przejść pod maską i zobaczyć, jak wszystko jest połączone, aby dowiedzieć się, co nie działa. To naprawdę jest podobne do pracy na silniku bez instrukcji, a firma poszła i stworzyła silnik bez patrzenia na inny silnik wcześniej (więc jest to prawdopodobnie wyjątkowy).

Długotrwały lub dziwnie sformułowany element zamówienia otrzyma więcej pytań, których tak naprawdę nie chcesz. „Diagnoza problemu” to mniej lub bardziej powszechnie rozumiana koncepcja.

Nic na fakturze dla klienta nie powinno być dla niego zaskoczeniem. Biorąc to pod uwagę, mam nadzieję, że już ustaliłeś z klientem oczekiwania, że ​​znaczna część twojego czasu początkowo byłaby poświęcona na zapoznanie się z aplikacją zarówno z perspektywy użytkownika, jak i programisty. Oszacowano, że dla pierwszych kilku funkcji podano, że zawierały one sporo czasu na zapoznanie się z kodem.

Jeśli już wcześniej ustaliłeś z klientem, że większość czasu na wstępnej fakturze zostanie poświęcona na zapoznanie się z aplikacją, nie powinno to mieć większego znaczenia, jak dokładnie umieścisz ją na fakturze. Podaj prognozy i określ oczekiwania w dowolnym języku, którego użyłeś. Jeśli tylko próbujesz to teraz przekazać, masz problem.

Jako freelancer prawdopodobnie nazwałbym to raczej „przyswajaniem wiedzy” w ogólnym znaczeniu. I byłoby to uwzględnione we wszelkich szacunkach przedstawionych początkowo klientowi.

Może ci to nie pomóc, ale w celach informacyjnych sugeruję, aby uczynić to bardziej aktywnym zadaniem w przyszłości. Na przykład zafakturuj klientowi czas poświęcony na przeglądanie i dodawanie komentarzy do nieskomentowanego kodu, dodawanie testów jednostkowych do nieprzetestowanego kodu itp. Są to przykłady zadań, które dodają co najmniej niewielkiej wartości, jednocześnie ułatwiając zrozumienie podstawy kodu .

Nawet jeśli nie ma dużej różnicy między czytaniem a czytaniem podczas dokumentowania, twój klient prawdopodobnie będzie miał małe preferencje psychologiczne dla tych bardziej „aktywnych” zadań. I możesz dowiedzieć się więcej, dokumentując kod innej osoby niż po prostu czytając go. (Z pewnością tak będzie, jeśli napiszesz testy na ich kodzie).

Jeśli to zrobisz, możesz uzyskać pozycję na fakturze z napisem „Asymilacja wiedzy i testowanie / dokumentacja starszego kodu”.

Edycja: W twojej opisanej sytuacji prawdopodobnie zjadłbym koszt tej aktywności. Nie mogę rozmawiać z twoimi finansami i nie zamierzam zakładać, ale kiedy zaczynasz, przykładam większą wagę do gromadzenia referencji i zadowolonych klientów niż kilka godzin fakturowania. Jeśli oznacza to efektywnie niższą stawkę na początku, może być dobrą inwestycją. Spożywanie długofalowych godzin na dłuższą metę jest prawdopodobnie niewielką ceną dla zadowolonego klienta, który uważa, że ​​dostał sprawiedliwego wstrząsu.

Naprawianie błędu: analiza przyczyny źródłowej.

Nowa funkcja: analiza, projektowanie, integracja i testowanie.

Przedstawiamy nowe błędy: bezpieczeństwo pracy. :)

Z klientem, który lubi rozumieć, jak to działa i słucha mnie rozmarzonymi oczami, wybrałbym coś prostego Codebase Familiarization. Wyjaśniłbym mu już, w jaki strumień bólu mnie wprawia, i jaką korzyść z tego, że przyszedł do mnie po dalsze ulepszenia.

Z innym typem klienta ... (to samo traktowanie, ale najwyraźniej nie słucha ani jednego słowa, które mówię ) Wybrałbym coś w stylu:

• Planning Phase

• Intervention Planning

  (Właściwie użyłbym tego, ale napisałbym to po włosku, w którym brzmi to znacznie lepiej)

• Więc może ... Solution Planning

DiagnosisCzęść Problem Diagnosissugestii podoba mi się anon, ale Problemto nie brzmi dla mnie dobrze. Może być otwarty na łagodną, ​​stronniczą, ignorancką i powierzchowną krytykę ... która może pozostawić zły gust.

Wiesz, wszyscy chcą rzucić strzałką zewnętrznemu konsultantowi i tak robią. (... jakby nie był wystarczająco dobry, aby zrozumieć źródło problemu podczas rozmowy z nimi, i musiał zafakturować swoją bezradność, albo bóg wie co)

Mój mechanik wysyła mi rachunek „Wymień olej, iskrę plus, sprawdź filtry, obroty opon. Napraw grzechotkę silnika, test drogowy .....

Części (wyszczególnione),

Praca x @ $ r / godzina = z)

On nie rozkłada pracy, ty też nie powinieneś. Rachunek za całkowitą liczbę godzin i opisz, co zrobiłeś.