Odkąd zatrudniliśmy kilku wykonawców, jednym z pytań, które zadają inni, jest:
oJak to jest przejść od samodzielnej pracy nad projektami do pracy nad projektami w zespole?
Lub prościej, jak to jest mieć kontrahentów? Krótka odpowiedź brzmi, że kopię to, ponieważ daje pewne korzyści:
- musimy mieć ostry podział pracy,
- biznes może podjąć się większej liczby projektów,
- jesteśmy w stanie współpracować przy różnych rzeczach (czego brakuje mi w samotnym lataniu),
- i więcej.
Drugą stroną tego jest jednak to, że czuję, że muszę się nauczyć, jak to jest od nowa założyć firmę.
Jak zacząć od czystej karty.
To w żadnym wypadku nie jest złe. Jest odwrotnie. Ale kiedy odchodzisz od samodzielnej pracy nad projektami i rozwijania konfiguracji, następuje okres dostosowania.
Ciągle tego doświadczam i przepracowuję. Wymaga to zarówno rozmów z zespołem, jak i odrobiny introspekcji, aby ustalić, czy to, co robisz, jest nadal odpowiednie do sposobu, w jaki pracujesz, czy też należy to dostosować.
Komunikacja zespołowa
Oczywiście ten konkretny temat jest obszerny i ja – wraz z wieloma z Was – mógłbym mówić o różnych rzeczach związanych z prowadzeniem biznesu.
Ale na dzień dzisiejszy chcę opowiedzieć tylko o roli, jaką w dostarczaniu rozwiązań innym odgrywa komunikacja zespołowa, a nie narzędzia programistyczne.
Twoje narzędzia mają znaczenie (ale nie tak bardzo)
Na przykład pracowałem w miejscu, w którym przynoszą ci maszynę z określonym zestawem narzędzi i mówią: „Tego używamy do tworzenia naszych projektów".
Jasne, wymaga to nauczenia się, ale części mnie podobało się to, ponieważ usuwa ból głowy związany z zastanawianiem się, czego użyć. Uniemożliwiło mi to również samodzielne podejmowanie tych decyzji.
Z drugiej strony utrudniło to również wprowadzenie nowego narzędzia, ponieważ zakłóciłoby to przepływ pracy całego działu. Kiedy jednak jesteś małym zespołem, trochę łatwiej jest się dostosować.
Visual Studio Code stał się moim ulubionym IDE.
Po pierwsze, pracując dla siebie, prawdopodobnie masz swojego ulubionego:
- IDZIE
- system kontroli źródła,
- budować narzędzia,
- narzędzia wdrożeniowe,
- środowisko hostingowe,
- i tak dalej.
Kiedy jednak włączasz innych do miksu, przynosisz dokładnie te same rzeczy, z wyjątkiem tego, że jest to na ich warunkach. Teraz masz za zadanie określić, czy powinieneś trzymać się tego, co masz, ocenić to, co oni mają, sprawić, by zaadoptowali twoje narzędzia, zaadoptowali swoje narzędzia, połączyć je ze sobą lub zacząć od nowa.
Nie jest to trywialny sposób, zwłaszcza gdy pracujecie ze sobą nad rozwiązaniem rozwiązania dla klienta. Mogłabym napisać o tym znacznie więcej. I nie zrozumcie mnie źle: myślę, że jest to temat, który należy omówić i jest to coś, co uważam za ważne.
Ale jest coś, co stoi ponad tym wszystkim, czego nigdy nie należy lekceważyć, a jest to proces komunikacji zespołowej.
Komunikacja ma znaczenie (i liczy się więcej)
Nie mówię o upewnianiu się, że każdego dnia sprawdzasz nastroje ludzi (choć to ważne), i nie mówię o czacie w tekście, na Slacku lub na IRCu tylko ze względu na to, abyś czuł się produktywny.
Komunikacja zespołowa to coś więcej niż Slack.
Mówię o pełnym komunikowaniu wymagań.
Przykład: powiedzmy, że rozmawiam z klientem, akceptuję umowę, a potem jestem gotowy, aby iść naprzód. Wiem czego chcą, jakie są projekty i jak coś powinno działać. Potem przyprowadzam kolegę z drużyny i mówię „Hej, zaczynajmy”.
Problem tutaj jest jasny, prawda? On/ona nie ma pojęcia, o co nam chodzi.
I nie ma znaczenia, jak bardzo nakreślisz kroki w swoim narzędziu do zarządzania projektami lub porozmawiasz o tym, jak coś powinno działać.
Co więcej, możesz mieć najbardziej elegancką i najbardziej wydajną konfigurację oprzyrządowania, ale jeśli Twój zespół nie ma jasności co do wymagań projektu, nic z tego nie ma znaczenia.
Kiedy zdecydujesz się zatrudnić kogoś do pomocy przy projektach i kiedy zdecydujesz się rozpocząć współpracę nad rozwiązaniem, przedstaw dyskusję o narzędziach i wymaganiach pierwszej dyskusji.
Nie można tego zaniżać.
Jeśli znasz wymagania, a twój kolega z zespołu nie lub jeśli wymagania nie są jasno przekazane z tego czy innego powodu, właściwe rozwiązanie nie zostanie dostarczone. A to oczywiście jest kosztowne.
Co więcej, jeśli w końcu myślisz, że masz te same pomysły na myśli i wdrażasz coś zupełnie innego, to masz inny zestaw problemów, z którymi musisz sobie poradzić.
Jeśli chodzi o mój biznes, to przede wszystkim zajmuję się budowaniem relacji z ludźmi, z którymi pracuję zarówno w moim zespole, jak iz którymi nas zatrudniamy.
Ale jeśli wewnętrzne dyskusje na temat rozwiązań, nad którymi pracujemy, nie są na tej samej stronie, nic innego nie ma znaczenia – nie twoje narzędzia, nie to, co wysyłasz, nie jak szybko to wysyłasz, a nie czy to po prostu zostanie wykonane.
Więcej w przyszłości
Tak więc w przyszłym poście podzielę się kilkoma pomysłami z dotychczasowych osobistych doświadczeń – zarówno błędami, jak i wygranymi – w nadziei, że będziesz w stanie uniknąć wszystkiego, z czym możesz się zmierzyć, gdy zdecydujesz się na rozwój swojego zespołu.
Nie zrozum mnie źle: to fantastyczna rzecz do zrobienia (i uwielbiam to), ale wymaga dostosowania na poziomach, na które nie byłem do końca przygotowany.
W międzyczasie, jeśli masz coś do dodania do tego posta, możesz to zrobić w komentarzach. Zawsze chętnie słyszę, jak freelancerzy i ci, którzy również pracują na własny rachunek lub zarządzają zespołami, radzą sobie z tym konkretnym tematem.