Proste rozwiązanie: rób kopie zapasowe, zwłaszcza jeśli ktoś inny może pracować nad Twoimi materiałami. To powinien być bardzo drobny problem. Weź odpowiedzialność za swoją przyszłą pracę.

Większość ludzi albo popełniła podobny błąd, albo wie o nim. Rzecz w tym, żeby się z tego uczyć. Nawet tak późno w mojej karierze skradziono mi laptopa, na którym znajdowały się jedyne kopie z około 2 lat badań. Na szczęście był to tylko osobisty projekt, ale w końcu mógł stać się lukratywny.

Nie ma sensu w oskarżeniach; najlepiej jest zająć się problemem proaktywnie i upewnić się, że to się nie powtórzy.

Winę za to ponoszą wszystkie trzy osoby: OP za brak kopii zapasowej; kolega za brak kopii zapasowej przed wprowadzeniem zmian; i jedyną osobą, która naprawdę powinna wiedzieć lepiej, ponieważ to on jest ochroniarzem: informatykiem, który nie może odzyskać pliku. Gdzie są jego kopie zapasowe serwerów?
Pracownicy popełniają takie błędy, to się zdarza. Ale mogę przywrócić pliki, które zostały usunięte 5 lat temu dla moich klientów, ponieważ ich pliki są regularnie archiwizowane i archiwizowane.

Jeśli chodzi o konfrontację z kolegą, dałem mu znać, ale ja nie zrobiłby z tego nic wielkiego ani nie próbowałby obarczać go całą winą. Powiedziałbym to w konstruktywny sposób, który mógłby mi pomóc. „Zastąpiłeś plik szablonem, czy zrobiłeś kopię pliku? Było w tym mnóstwo pracy, której nie chcę powtarzać”.

Wypadki się zdarzają. Nawet jeśli możemy wdrożyć procesy, zawsze będzie miejsce na błąd ludzki.

Aby odpowiedzieć na to pytanie, powinieneś porozmawiać z gościem, który wprowadził zmiany i powiedzieć, co się stało. Jeśli zapyta Cię, dlaczego nie zachowałeś kopii zapasowej swojego ostatniego skryptu, masz pełne prawo do zadania w zamian tego samego pytania. Wygląda na to, że oboje założyliście, że ten drugi ma kopię zapasową i nie pytaliście. Ostatecznie wina leży po stronie was obojga.

Oczywiście, jeśli powoduje to więcej niż małe opóźnienie w projekcie, należy zgłosić to kierownikowi projektu (jeśli dotyczy). Tuszowanie problemów (własnych lub innych) może stworzyć więcej problemów niż rozwiązać.

Zdarzyło się to mojemu koledze. Najpierw wysłał wiadomość e-mail, w której napisał: „Przez przypadek nadpisałeś moje zmiany, co spowodowało wiele problemów. Zachowaj ostrożność w przyszłości”. Drugi raz, wkrótce po wysłaniu e-maila "Nadpisałeś moje zmiany po raz drugi. Jeśli nie zgadzasz się z moimi zmianami, skontaktuj się ze mną pilnie, ponieważ mocno wierzę, że te zmiany są potrzebne. Jeśli stało się to przez przypadek, nie rób tego" zrób to ponownie ”. CC'd do swojego i menadżera drugiego gościa.

(To było z systemem kontroli źródła, w którym nie powinno się to zdarzyć przez przypadek, ale tylko wtedy, gdy zmiany wprowadzone przez inne osoby zostały celowo nadpisane. Zmiana mojego kolegi naprawiła rzadki, ale nieco krytyczny błąd, i myślał, że naprawił to tylko ze względu na skargi dotyczące powrotu błędu. Dwa razy.).

Fakt, że ktoś kopiuje i wkleja szablon do Twojej pracy, stwarza prawdziwy problem, sugeruje, że konfiguracja Twojego komputera jest zła. Jeśli nie ma automatycznego tworzenia kopii zapasowych plików, problem leży po stronie działu IT i dział IT powinien zmienić swoje zasady.

Proste oprogramowanie, takie jak Dropbox, wykonuje automatyczne tworzenie kopii zapasowych plików.

Wygląda na to, że Twoja organizacja ma poważne problemy. Pracowałem w miejscach, w których zbyt uproszczone zasady IT (takie jak zakaz instalowania czegokolwiek) aktywnie uniemożliwiały mi wykonywanie mojej pracy jako programisty.

Jest tutaj kilka opcji, w kolejności według potrzeb:

• Naciskaj na zmiany organizacyjne
• Naciskaj na zmiany dla swojego zespołu lub dla siebie
• Zachowaj ręczne kopie zapasowe
• Łam zasady
• Odejdź

To idealny czas na współpracę z menedżerem w celu napisania propozycji procesu biznesowego umożliwiającego przejście na kontrolę wersji. Nawet jeśli zajmie to rok, rozpocznij proces, ponieważ rok mija szybciej, niż myślisz.

Prawdopodobnie możesz również uzyskać pozwolenie od swojego bezpośredniego przełożonego dla swojego zespołu (lub siebie) na użycie kontroli wersji, która nie wymaga instalacji . W szczególności istnieją wersje Git, które nie wymagają instalowania żadnych plików. Git dla Windows Portable („wersja z pendrive'em”) jest dostępny na stronie pobierania Git dla Windows.

Jeśli jest to konieczne, możesz również zachować ręczne kopie zapasowe. Zmieniając plik, można sprawdzić datę i godzinę ostatniej modyfikacji przed jego otwarciem, skopiować plik i dołączyć tę część na końcu. Zatem plik a.txt jest kopiowany do pliku a.txt.201610131211 przed zmianą a.txt. To trochę lepsze niż brak kontroli wersji.

Kiedyś byłem młody i lekkomyślny i bardziej interesowało mnie wykonanie pracy niż przestrzeganie zasad. W rezultacie, pracując w nieoptymalnych warunkach, szukałem luk. Poprosiłem przyjazny personel sieciowy, aby zainstalował podwójną partycję systemu Linux na moim komputerze, a następnie zainstalowałem narzędzia sieciowe potrzebne do debugowania wywołań protokołów. W dzisiejszych czasach możesz uciec z pendrive'em Liveboot z Linuksem. Nie polecam łamania zasad, chyba że nie masz innego wyjścia.

Jeśli żadna z tych inicjatyw nie zadziała, spróbuj znaleźć pracę w firmie, która nie jest szalona.

Widzę dwa problemy: w jaki sposób można zapobiec podobnym błędom w przyszłości i jak można zminimalizować szkody wynikające z tego błędu. Powiedzenie starszemu koledze, aby nie popełniał ponownie tego samego błędu, może wydawać się oczywistym rozwiązaniem, ale w rzeczywistości nie pomoże to w żadnym z tych problemów i nie powstrzyma nikogo przed nadpisaniem Twojej pracy.

Wiesz już, że prawdziwym rozwiązaniem jest użycie kontroli źródła, ale nie jesteś bezpośrednio w stanie tego dokonać. Możesz wyjaśnić swojemu kierownikowi, że stało się tak, ponieważ nie używasz kontroli źródła i to samo może się powtórzyć, jeśli kontrola źródła nie zostanie zaimplementowana. Jasne, że jest to wina narzędzi i procesów firmy, a nie Ciebie lub Twojego starszego kolegi. Pracujesz w dużej firmie, więc prawdopodobnie masz kierownika projektu. Będą utrzymywać listę zagrożeń projektowych, a brak kontroli źródła powinien znajdować się na tej liście.

Poświęcenie dodatkowych godzin może przynieść Ci kilka dodatkowych punktów ze swoim menedżerem, ale wielu menedżerów nawet tego nie zauważy . Z drugiej strony, jeśli nie poświęcisz dodatkowych godzin, a tym samym nie dotrzymasz terminu, Twój menedżer może użyć Cię jako kozła ofiarnego lub może użyć tego jako przykładu, aby podkreślić potrzebę kontroli źródła. Zdziwiłbyś się, jak szybko coś może się wydarzyć, gdy chcą tego właściwi ludzie, nawet w wysoce zbiurokratyzowanych firmach.

Krótko mówiąc: przekonaj swojego menedżera, że ​​wprowadzenie kontroli źródła powinno być priorytetem.

Rozwiązanie jest naprawdę proste: nie pozwól współpracownikom manipulować komputerem, prosząc o pomoc. Pokaż im swoją konfigurację, wyjaśnij, czego próbowałeś, a następnie zapytaj, co możesz spróbować dalej. Jeśli to podejście nie jest praktyczne, przygotuj dla nich jakieś środowisko piaskownicy do gry . Właściwie bez kontroli źródła należy zawsze pracować na kopii, a nigdy na rzeczywistych danych. Co jeśli twój edytor się zawiesi? Co się stanie, jeśli przypadkowo wprowadzisz zmianę, której nie można cofnąć? Jasne, twój kolega był niezdarny, ale czy zdawał sobie sprawę, że jest o jedno kliknięcie od zniszczenia kilku dni twojej pracy? Nie sądzę.

Obwinianie go za to, co się stało i eskalacja problemu, może przynieść tylko jedno - Twoi koledzy unikną pomocy w przyszłości. Spędzanie czasu na cudzych problemach jest wystarczająco złe, ale obwinianie za niezdarne działanie konfiguracji, którą widzą po raz pierwszy, jest po prostu demotywujące.