Technologia to przyszłość, ale jak się tego nauczyć? Rozmowa z programistami to dobry początek

Wygląda na to, że marketerzy, którzy chcą poznać True Digital (tajemnice serwerów, API, SDK i inne artefakty oprogramowania) nie mają innego sposobu, jak zaprzyjaźnić się z programistami . Chociaż nie ma tu skrótów – trzeba budować i utrzymywać relację – przygotowałem kilka wskazówek , jak położyć podwaliny pod więź z inżynierami oprogramowania.

A jeśli jesteście przyjaciółmi, wasz zestaw umiejętności technicznych wzrośnie dziesięciokrotnie, zanim się zorientujecie.

Środowisko naturalne deweloperów

Na pierwszy rzut oka inżynierowie wydają się specyficzni. Taki, który rzekomo wymaga specjalnego traktowania, niektórzy twierdzą nawet, że jest zrzędliwy. Z całego serca nie zgadzam się z tym twierdzeniem. Nie jestem magistrem socjologii ani psychologii, ale coś o tym wiem. Kiedyś byłem inżynierem oprogramowania i też założyłem czapkę marketera. Co więcej, dzisiaj żyję sprzedając platformę oprogramowania, która pomaga marketerom i programistom zakopać topór.

Czego więc nauczyłem się o ułatwianiu interakcji marketer-dev? Z punktu widzenia marketera chodzi o zrozumienie naturalnego środowiska deweloperów — niezbadanych terytorium dla osób rozpoczynających karierę.

Dlatego skompilowałem mapę rutyn i pragnień programistów i mam nadzieję, że pomoże ci to poruszać się po nich, ostatecznie prowadząc do kwitnącego związku.

To nie jest takie proste, jak się wydaje. Jak przyznają deweloperzy, mają reputację tego, że mówią „nie”, dyskutują o pedantycznych szczegółach i myślą, że wiemy, jak wykonywać pracę każdego lepiej niż oni. Ale jeśli dobrze to zrobisz, programiści staną się Twoim głównym źródłem wiedzy — jak możemy się nauczyć od Kate, w jej opowieści o marketingu cyfrowym, który został menedżerem produktu IT.

Zacznijmy więc od rozwiązania jednej z najpopularniejszych przeszkód na drodze do zaprzyjaźnienia się z programistami.

Dlaczego programiści często są w złym humorze?

Przyczyna zrzędliwej reputacji deweloperów wymaga dłuższego wyjaśnienia. Jeśli chcecie to szczegółowo zrozumieć, powinniście przeczytać długą wersję Nicholasa (sprawdźcie tylko, ilu deweloperów zgodziło się z jego twierdzeniem w sekcji komentarzy). Jeśli brakuje Ci czasu, postaram się podsumować to zjawisko w 8 punktach:

1. Deweloperzy to tłumacze Twoich pomysłów na rzeczywistość . Sprawiają, że to działa. Sprawiają, że działa szybko. Sprawiają, że jest solidny i niezawodny dla użytkowników. Inżynierowie oprogramowania są olejem gospodarki cyfrowej.
2. I są za to dobrze opłacani, unikalna umiejętność łączenia kreatywności i logicznego myślenia.
3. Ale często są traktowani przez inne działy jak twórcy reprodukcyjni, a nie twórcy.
4. Nazywanie ich budowniczymi jest niesprawiedliwe. Pozostając w metaforze budownictwa, deweloperzy są w rzeczywistości architektami, a nie budowniczymi. Ich zadaniem nie jest fizyczne podnoszenie budynku (lub budynków), ale zbieranie wymagań . Wymagania w postaci kodu.
5. Teraz wyobraźmy sobie fazę projektowania czegoś tak złożonego, jak Sydney Opera czy katowicki Spodek, ale z niewielką różnicą — interesariusze mogą zmienić prawie wszystko, gdy budynek jest długo w budowie. Mimo to deweloperzy wciąż mogą zapewnić, że budynek będzie użytkowany i nie zawali się.
   
6. Ale gdzie są prawdziwi budowniczowie? Są w pełni zautomatyzowane . Deweloperzy byli na tyle sprytni, że tworzyli narzędzia, takie jak kompilatory, serwery do ciągłego wdrażania lub serwery w chmurze, które sprawiają, że proces budowy jest szybki i bardziej przewidywalny.
7. Jeśli kiedykolwiek zastanawiałeś się, dlaczego deweloperzy nie mogą oszacować, ile czasu zajmie etap budowy, teraz widzisz, że tak naprawdę pytasz o etap architektoniczny. Pytanie, ile czasu zajmie napisanie oprogramowania, jest jak powiedzenie wykonawcy budowlanemu, ile czasu zajmie zaprojektowanie każdego szczegółu bloku miejskiego, w tym zebranie wszystkich wymagań.
8. A sama część budowy jest łatwa . Po spisaniu wymagań można je oszacować z drugą dokładnością.

Tak więc tworzenie oprogramowania to w rzeczywistości badania pod przykrywką inżynierii

Nigdy nie powinieneś patrzeć na programistów jak na gotujących na krótkie zamówienie w branży. Jak to ujął Nicolas: „ inżynierowie oprogramowania nie zajmują się kodowaniem, ponieważ chcą, aby ktoś im powiedział, co mają robić, angażują się w to, ponieważ odkryli, że mogą stworzyć coś użytecznego. Każdy inżynier oprogramowania zakochał się w kodowaniu, ponieważ wcześnie stworzyła mały, użyteczny program i wpadła w jego zapał. ”

Kiedy już to zrozumiesz i zmienisz swoje podejście do programistów, jesteś na dobrej drodze, aby być przez nich lubianym.

Ale dogadywanie się z programistami to nie tylko sposób myślenia. Jest coś bardziej praktycznego, co możesz zrobić, aby zdobyć prawdziwego przyjaciela programisty.

Posłuchaj i pozwól im wysyłać

Świadomość, że programiści wpływają na życie ludzi, jest najpotężniejszym bodźcem dla programistów. Niezależnie od tego, czy jest to wewnętrzny skrypt pomagający zespołom marketingowym osiągnąć ich cele, czy też rozbudowany back-end obsługujący miliardy transakcji każdego dnia, to kod działający „na produkcji” sprawia, że ​​programiści codziennie przychodzą do biura.

Deweloperzy kochają ciężką pracę . Mogą godzinami siedzieć przed klawiaturą, rozwiązując problemy innych ludzi — zwłaszcza jeśli czasu na zadanie, które oszacowali, się kończy (a kurczę… nie doceniają , ale to już coś na osobny artykuł).

To, czego nie mogą znieść, to dyrektywy dotyczące zmian z wiatrem, a nie żeglugi .

Deweloperzy nie wysyłają, gdy zostaną przerwane. Jak mówi Nicholas, dzieje się tak, gdy:

• Prośba nadchodzi z opóźnieniem w fazie rozwoju i nie ma wystarczająco dużo czasu, aby ją zmieścić przed upływem terminu.
• Żądanie unieważnia jedno lub więcej założeń, które zostały przyjęte na początku procesu, aby uruchomić projekt.
• Żądanie jest odwróceniem poprzednich wymagań .
• W przeciwnym razie żądanie zwiększa ilość pracy , którą należy wykonać przed upływem terminu.

Mając to na uwadze, oto, co możesz zrobić, aby zapewnić bezproblemową wysyłkę:

• Wczesne zrozumienie ograniczeń inżynieryjnych.
• Spełnij swoje wymagania (te pierwsze dwa to coś, czego chcemy Cię nauczyć tutaj w 200 OK).
• Bardzo ściśle współpracuj z inżynierem.
• Pomóż im zrozumieć , jak ostateczny jest projekt na danym etapie — przyznaj, gdy nie jesteś czegoś pewien i chcesz coś przetestować.
• Bądź miły — (nie tylko w tym przypadku) ludzie często o tym zapominają, a analiza rozpoczęta przez Google wykazała, że ​​jest to klucz do dobrej pracy zespołowej.

Podsumowując, programiści nie marudną bez powodu. Nie chodzi o to, że nienawidzą ciężkiej pracy lub długich godzin; nienawidzą, kiedy to się nie opłaca (i nie mówię tutaj o pieniądzach). Więc kiedy pozwalasz im wykonywać swoją pracę , stają się mniej zrzędliwe i stają się bardziej pomocne.