Jasne ustalenie zasad na początku projektu znacząco ogranicza ryzyko organizacyjne i przyspiesza realizację prac.
Komunikacja
W projektach technicznych kluczowa jest precyzja oraz możliwość odtworzenia ustaleń.
Dlatego:
- preferuję komunikację pisemną w systemie śledzenia zadań (np. Jira) lub w mailu,
- kwestie ustalone ustnie powinny być podsumowane w formie pisemnej,
- sprawy pilne mogą być zgłaszane przez WhatsApp,
- do spotkań online wykorzystuję Google Meet, Zoom lub Microsoft Teams.
Komunikacja w systemie zadań zapewnia przejrzystość, historię decyzji oraz minimalizuje ryzyko nieporozumień.
Formalne podstawy współpracy
Standardowy model współpracy obejmuje:
- Umowę o zachowaniu poufności (NDA) – jeśli jest wymagana.
- Umowę ramową o świadczenie usług, zawierającą:
- model rozliczeń godzinowych,
- ograniczenie odpowiedzialności do wysokości wynagrodzenia,
- wyłączenie odpowiedzialności za utracone korzyści.
- Zlecenie mailowe lub w systemie zadań określające zakres prac.
- Fakturę wystawianą na podstawie raportu godzin (zwykle miesięcznie), z terminem płatności 14 dni.
Środowisko pracy
Pracuję w środowisku Linux (Ubuntu). Nie realizuję projektów wymagających pracy w środowisku Windows jako podstawowej platformie developerskiej. Takie ograniczenie pozwala mi utrzymać wysoką efektywność i spójność środowiska pracy.
Wymagane dostępy do analizy projektu
Aby skutecznie przeprowadzić analizę kodu lub zdiagnozować problem, potrzebne są:
- podpisana umowa NDA (jeśli wymagane),
- dostęp VPN umożliwiający połączenie z niezbędnymi zasobami (z systemu Linux),
- dostęp do repozytorium kodu źródłowego (preferowane GitHub/GitLab/Bitbucket),
- dostęp do obrazów Docker (jeśli nie są publiczne),
- dostęp do środowiska testowego lub – w uzasadnionych przypadkach – kontrolowany dostęp do produkcji,
- dokumentacja umożliwiająca lokalne uruchomienie aplikacji.
W pierwszej kolejności preferuję pracę na środowisku testowym lub kopii środowiska produkcyjnego.
Wymagane dostępy do wdrożeń
W przypadku realizacji zmian wymagających instalacji nowej wersji aplikacji potrzebne są dodatkowo:
- dokumentacja procesu budowania i instalacji,
- dostęp do narzędzi CI/CD,
- w przypadku braku automatyzacji – dostęp do skryptów instalacyjnych oraz kontrolowany dostęp do infrastruktury (np. Kubernetes lub serwery aplikacyjne).
Jeżeli projekt nie posiada automatyzacji wdrożeń, możliwe jest jej zaprojektowanie i wdrożenie jako osobne zadanie.
Zakres odpowiedzialności
Nie przejmuję odpowiedzialności za całość działania systemu ani decyzje biznesowe podejmowane na podstawie rekomendacji, chyba że zostanie to odrębnie uzgodnione w umowie.
