Przeskocz nawigację

Negocjacje projektu to twardy orzech do zgryzienia, niby można napić się piwka z producentem od wydawcy, niby można sobie pożartować, ale tak czy siak każdy zbiera sobie asy do rękawa, by je w odpowiednim momencie pokazać. Moim zdaniem odpowiednie podejście do tego tematu ma wiążący wpływ na jakość i zakończenie danego projektu. Co zrobisz gdy wydawca cały czas prosi się o jakieś ficzery? Co zrobisz gdy wydawca będzie chciał inną postać główną 2 dni przed Goldem? Co zrobisz gdy wydawca 2 tygodnie po Becie nie dostarcza feedbacku, a za 2 tygodnie masz oddać RC? Co zrobisz gdy wydawca dostarcza Ci feedback którego nie da się zrozumieć, ani nie można podjąć działań by coś naprawić? (np. „nie podoba mi się ten level 13”) Co zrobisz gdy licensor spóźnia się z feedbackiem a za 2 dni musisz oddać RC?

To jest tylko 1% pytań jakie można zadać. Wpływ wydawcy na tworzenie gry jest ogromny, osoby, które nie mają jeszcze doświadczenia, myślą sobie coś w stylu „Mam tak zajebisty team, zrobimy zajebistą grę” – gówno prawda 🙂 Postaram się opisać z leksza jak ja przygotowuje się do negocjacji i w jaki sposób do tego podchodzę, ponoć mi to wychodzi więc podzielę się troszkę.

Jak przygotować się do negocjacji z wydawcą w trakcie wykonywania projektu:
– Jeśli nie brałeś udziału w negocjacjach kontraktu projektu, dowiedz się od swojego szefa jakie daty zostały wprowadzone, tak byś wiedział ile czasu wydawca ma na dostarczenie feedbacku, do kogo uderzać gdy ma się jakieś pytanie
– Poznaj cały główny team po drugiej stronie, wydawca może Ci dać Producenta z którym będziesz się kontaktował, ale warto mieć bezpośredni kontakt do designera i programisty ze strony wydawcy.
– Dowiedz się jakie ficzery zostały zaakceptowane, stwórz listę ficzerów, które będą zakresem projektu (jeśli taka lista nie została wykonana)
– Przed startem projektu zrewiduj checkliste milestone’ów, możliwe, że czai się tam mina.
– Dokładnie dowiedz się jak ma przechodzić process developingu gry dla tego wydawcy. (jakie milestone’y, co musi być w technologii)
– Też napisze: dokładnie zanalizuj plan, tak byś wiedział ile czasu jest na ‚zachcianki wydawcy’.

Uwagi dla osób negocjujących z wydawcą projekt w trakcie realizacji:
– Nigdy, ale to nigdy nie bądź wulgarny. Mówiąc coś takiego: „Nie zrobimy tego, nie ma opcji” robisz wokół siebie złą aurę. Bądź miły, zawsze, nawet jak dostajesz zjebe.
– Konkretnie tłumacz problem i sposób realizacji
– Zawsze powiadamiaj wydawcę o napotkanych problemach w projekcie i sposobie na ich naprawę. Uwzględnij w raporcie czas trwania naprawy.
– Nie gódź się szybko na jakieś feature needs od wydawcy. 3 razy się zgodzisz i wydawca będzie wiedział, że nie masz jaj i będziesz robił wszystko o co prosi, wykorzysta to by mieć w projekcie jak najwięcej ficzerów, a Ty już będziesz się martwił jak je mu dostarczyć.
– Każde słowo jest wiążące, nie obiecuj czegoś, czego nie jesteś w stanie zrobić.
– Każdą małą pierdółkę (ficzer) o którą prosi wydawca i która robisz zapisuj sobie./
– Pamiętaj o zasadzie coś za coś, to naprawdę działa. Zamiast mówić wydawcy „nie mamy czasu na to”, lepiej powiedzieć, że nie mamy czasu by to zrealizować, ale zamiast tego możemy zrobić to, co też będzie fajne. (A to jest już w feature requestach i jest znacznie mniej skomplikowane)
– Konkretnie pisz raporty tak by wydawca wiedział z kim ma do czynienia.
– Na samym początku zdobądź zaufanie wydawcy, poprzez profesjonalne podejście i zrobienie wszystkiego na czas, z konkretną jakością, dzięki temu później będzie Ci łatwiej go przekonać by porzucił parę pomysłów.
– Zawsze konsultuj features needs z teamem.
– Gdy wydawca prosi Cię o spory ficzer, nie dawaj mu odpowiedzi od razu, skonsultuj to z teamem, poproś programistów o napisanie ile czasu zajmie dodanie takiego ficzera i jakie dodatkowe problemy mogą wyniknąć z takiej funkcjonalności. Tak samo pytaj się grafików/muzyków/etc ile czasu zajmie im przygotowanie czegoś. Skonsultuj to z wydawcą, rozsądny wydawca będzie wiedział kiedy powiedzieć ‚nie’, bez zaglądania w ficzer listę z kontraktu.
– Dobrze tłumacz wydawcy co jest w danym buildzie, co ma raportować, a czego nie.
– Od pierwszego builda proś wydawcę o feedback. Tak byś już na początku dostosowywał projekt pod jego ‚wizję’. Unikniesz wtedy miliona poprawek na końcu.
– Gdy się z czymś nie wyrobisz poinformuj o tym wydawcę dużo wcześniej, tak by można było negocjować uaktualniony plan.
– Często aktualizuj plan, tak by wydawca wiedział gdzie jesteśmy.
– Daj dostęp wydawcy do bugtrackera
– Daj dostęp wydawcy do programu zarządzającego produkcją.
– Informuj wydawcę o QA projektu.
– Gdy Wydawca robi koło, czyli chce byśmy coś zmienili -> zmieniamy -> później znów chce by było tak jak dawniej nie bój się go zjebać, powiedz mu ile czasu straciliśmy i ile czasu mieli byśmy więcej na polishing projektu.
– Gdy wydawca dostarcza Ci feedback w którym 90% to rzeczy typu „Level 13 mi się nie podoba”, nie wkurwiaj się, tylko wrzuć całość do jakiegoś XLSa i zadaj pytania tak by wydawca mógł się bardziej określić.
– Gdy wydawca dostarcza Ci feedback w którym 90% to rzeczy, których się zrobić nie da, znaczy to, że nie ma pojęcia co jest w kontrakcie, na jakim etapie jest projekt, albo nie dawał Ci feedbacku wcześniej. Uświadomić go wtedy trzeba na co jest już za późno i dlaczego.
– Wysyłaj ‚tygodniówki’ wydawcy, tak by wiedział ile czasu kto poświęca na co w tygodniu, będzie wiedział czy jest czas na dodanie czegoś nowego.
– Staraj się budować referencje do których możesz szybko dotrzeć. Np. Wydawca prosi Cię o dodanie jednej postaci. Widząc log próśb wydawcy wiesz, że prosił o to miesiąc temu i zaakceptowaliśmy, że tej postaci nie robimy – temat się kończy. Widząc ilość pracy grafików wiesz już, że nie jesteś w stanie tego zrobić. Widząc ilość pracy animatorów i ich poprawek wiesz, czy można taką postać wykonać. Ważne byś był w stanie szybko wydawcy powiedzieć z czym się dana mniejsza prośba wiąże.
– Pamiętaj na co się godziłeś z wydawcą a na co nie. Bardzo często mam tak, że wydawca co jakiś czas prosi o tą samą rzecz, która na początku wykluczyliśmy. Czasami potrzeba też wydawcy pokazać miejsce w którym razem wykluczyliśmy ten ficzer. Mając takiego asa wydawca już gówno Ci zrobi.
– Ja w każdej rozmowie mam nastawienie „zanalizuje i zobaczę”, chociaż wiem, że czegoś nie da rady zrobić.
– Gdy wydawcy zależy na jakimś ficzerze, a nie możemy go zrobić, dogłębnie tłumaczę mu dlaczego tego nie możemy zrobić. Przykładowo jak nie ma czasu na zrobienie tego, motywuje się tym, że projekt będzie dopieszczony, tym, że nie będziemy wprowadzać takich zmian, które zmniejszą czas polishingu, etc etc. Wydawca często po analizie tego co mówie dochodzi do wniosku, że mam rację i że gra już teraz wygląda zajebiście, a będzie wyglądała jeszcze lepiej, więc po co to psuć…
– Jak chcesz feedback od wydawcy dobrze napisz do czego feedback oczekujesz i jak powinien być dostarczony
– Zbieraj  feedback od wydawcy do wszystkiego (HUD, Menu, AI, animacje, grafika, dany ficzer, dana minigra) nawet gdy te rzeczy są WIP. Czasami jednak warto pokazać dopiero gotową część gry, zależy od wydawcy, można to wywnioskować ze sposobu dostarczenia feedbacku. Gdy wydawca mówi Ci, że coś nie wygląda dobrze, ale jest to alpha, jest rozsądny i wie, że zostanie to naprawione, a jak Ci mówi „to wygląda do dupy, zredesignujcie to” – znaczy tyle, że więcej WIPa masz nie pokazywać 😉
– Konsultuj każdego milestone’a dogłębnie z wydawcą, tak byś sam wiedział dokładnie czego od Ciebie oczekują. Czasami checklista jest pobieżnie rozpisana i warto się dopytać.
– Codziennie rozmawiaj z wydawcą, nawet o pogodzie.
– Chwal wydawcę jak znajdzie fajny ficzer, albo znajdzie jakiś błąd. Chyba każdy lubi jak się go chwali nie? Wydawca też człowiek.
– Ja conf calle prowadzę przez skype’a (chat) by mieć archiwum, często jak się rozmawia przez telefon coś może wylecieć, no i nie będziesz miał zabezpieczenia jak się na coś nie zgodziłeś a wydawca to zaakceptował. Proponuje na początku dogadać możliwość tworzenia conf – chatów, zamiast rozmowy telefonicznej.
– Informuj wydawcę o ważnych nadchodzących wydarzeniach: np. testing gry przez osoby z poza firmy
– Gdy masz dobrego designera/lead programmera daj im bezpośredni kontakt do designera/programmera ze strony wydawcy, ominiesz wielu problemów komunikacyjnych, a w związku z tym projekt może będzie lepszy.
– Informuj wydawcę o problemach technicznych silnika którego używacie. Poinformuj go ile czasu trzeba na naprawienie tego i do kogo się odezwać by przyśpieszyć naprawienie.
– Informuj wydawcę o wszystkich problemach w teamie: np. choroba, urlop (to też problem 😛 ) tak by wydawca o takich rzeczach wiedział i zdawał sobie sprawę z tego, że developer to też człowiek tak samo jak wydawca.

Przykład:
Wydawca: Cześć, tak ostatnio sobie pomyślałem, że fajnie byłoby mieć jakiś fany postprocess w naszej grze, co o tym myślisz, wysłałem Ci listę postprocessów jakie chciałbym zobaczyć?
Producer: Cześć, świetny pomysł!
Wydawca: to kiedy mógłbym taki zobaczyć w grze?
Producer: porozmawiam z ludźmi, zorientuję się ile trzeba wykonać pracy i za chwilkę się do Ciebie odezwę.

Szybkie rozwiązywanie takich kwestii też jest ważne, wydawca czekając tydzień na Twoją odpowiedź, może pomyśleć, że temat jest już wdrożony w życie. Nie mówiąc o tym, że po prostu wydawcy się nie olewa.

Producer: Cześć, rozmawiałem z ludźmi, implementacja wszystkich postprocessów zajmie 2 tygodnie, zaznaczyłem Ci na liście, które z tych efektów będą kłopotliwe i które mogą sprawić sporo problemów z optymalizacją. Zaznaczyłem Ci też, które postprocesy możemy zrobić i na kiedy. Zanalizuj dokument i daj mi znać co o tym myślisz 🙂
Wydawca: Czemu nie możecie ich wszystkich wykonać?
Producent:  Głównie ze względu na czas, jak widzisz zostało nam 4 tygodnie do końca projektu, zaczęliśmy wprowadzać tą zmianę o która prosił Wasz designer, potrzebujemy jeszcze tydzień czasu by ją skończyć. Będziemy mieli trudne 3 tygodnie poprawiania błędów i testowania, tak jak pisałem w mailu jesteśmy w stanie zrobić te postprocessy, które zaznaczyłem, tak czy siak nie powinniśmy ich robić, ze względu na brak czasu, ale razem stwierdziliśmy, że te efekty będą miały wpływ na odbiór, więc parę z nich zrobimy i naprawimy wszystkie problemy z optymalizacją.
Wydawca: OK, co nie zmienia faktu, że było by fajnie je wszystkie wprowadzić.
Producent: no co racja to racja, zrobimy tak: wprowadzimy te postprocesy, które zaznaczyłem, wprowadzimy poprawkę od Waszego designera, stestujemy grę i ponaprawiamy błędy, a jak starczy nam czasu doimplementujemy resztę postprocesów, co Ty na to?

Gdy tu wydawca się nie godzi trzeba już zacząć inaczej mówić:
Producent: Niestety naprawdę nie mamy czasu by je wszystkie zaimplementować. Zgodziliśmy się na poprawkę Waszego designera, choć dobrze wszyscy wiemy, że taka poprawka na tym etapie nie powinna być wprowadzana. Zgodziłem się byśmy zaimplementowali parę z postprocesów o których mówiłeś, choć i tak miałeś sporo czasu by nam o tym powiedzieć wcześniej. Nie mogę spełnić Twojej prośby, albowiem wiem, że nie zdążymy ze wszystkim i przez to projekt, jego jakość może ucierpieć, a tego byśmy nie chcieli.

Gdy wydawca dalej chce je zrobić:
Producent: Nie wiem dlaczego aż tak bardzo zależy Ci na tych postprocesach, jak chcesz możemy zrezygnować z poprawki Twojego designera, ale wtedy gra straci na grywalności. Moim zdaniem lepiej jest skupić się na tej poprawce i konkretnym spolishowaniu gry. Nie możemy sobie teraz pozwolić na implementacje czegoś co zajmie 2 tygodnie czasu z istniejącym ryzykiem powstania błędów w optymalizacji. Gdy takie błędy się pojawią może być trudno oddać projekt na czas.

Gdy wydawca dalej chce je robić, powinieneś dalej wałkować ten temat aż do skutku. Powiedzenie w stylu „sorry, ale nie ma tego w kontrakcie, nie mówiłeś o tym na początku projektu” zostaw sobie na koniec. Często jest tak, że wydawcy już się źle robi od takiego pierdolenia i chce skończyć temat po 3h gadania 🙂

Na ten temat, można by pisać i pisać, mam nadzieję, że przynajmniej troszkę komuś pomogłem.

Reklamy

Skomentuj

Wprowadź swoje dane lub kliknij jedną z tych ikon, aby się zalogować:

Logo WordPress.com

Komentujesz korzystając z konta WordPress.com. Wyloguj /  Zmień )

Zdjęcie na Google+

Komentujesz korzystając z konta Google+. Wyloguj /  Zmień )

Zdjęcie z Twittera

Komentujesz korzystając z konta Twitter. Wyloguj /  Zmień )

Zdjęcie na Facebooku

Komentujesz korzystając z konta Facebook. Wyloguj /  Zmień )

Connecting to %s

%d blogerów lubi to: