Co to jest DesignOps? Dlaczego Twój zespół tego potrzebuje? W jaki sposób DesignOps może pomóc zespołowi projektującemu / programistycznemu osiągnąć sukces? W tym artykule udzielono odpowiedzi na te pytania, a także przedstawiono przydatne wskazówki dotyczące rozpoczęcia wdrażania tej nowej koncepcji w zespole programistów.
We współczesnym świecie szybkość rozwoju zespołu często określa żywotność produktu. Jednocześnie najważniejszy jest jeden kluczowy i najbardziej problematyczny: projekt.
Projektowanie często staje się wąskim gardłem i znacząco wpływa na cały proces rozwoju, bez względu na wielkość zespołu. Czasami nadludzkie wysiłki od kierownika projektu pomagają w kierowaniu procesem projektowania, ale gdy tylko wzrasta obciążenie pracą, musisz skalować swój zespół.
Jak często widziałeś:
Jeśli któryś lub wszystkie z nich brzmią znajomo, to najwyższy czas wdrożyć DesOps (operacje projektowe).
Termin DesOps lub DesignOps jest repliką tego terminu DevOps która jest praktyką inżynierii oprogramowania, która ma na celu ujednolicenie procesów rozwojowych w celu zwiększenia wydajności. Podobnie jak specjaliści DevOps, specjaliści DesOps to doświadczeni projektanci z umiejętnościami zarządzania, którzy rozumieją proces projektowania w szerszym kontekście rozwoju produktu.
Chociaż nie wszyscy mamy termin "DesOps" w naszym tytule, wielu starszych projektantów jest już odpowiedzialnych za tę samą rolę. Od tworzenia procesów projektowania, przez rozwijanie systemów projektowania, po tworzenie strategii i zarządzanie zespołami projektowymi, DesOps jest coraz bardziej pożądaną rolą.
Najważniejsze jest to, że takie podejście jest skalowalne i odpowiednie nawet w zespołach z jednym projektantem. Jak rozpocząć wdrażanie DesOps?
Projektanci muszą wiedzieć, kiedy ich praca jest kompletna i gotowa do przekazania zespołowi programistów. Na przykład projektanci potrzebują jasnego zrozumienia, które stany muszą być wyświetlane na każdym ekranie, a które zasoby będą wymagane, aby zespół programistów zbudował te zasoby.
Może się wydawać, że to obszar, który projektanci powinni z natury zrozumieć. Jest to jednak jeden z najczęstszych punktów tarcia w projekcie i nie należy go lekceważyć. Jeśli jasno określisz to, co jest wymagane, zredukujesz konflikty i upewnisz się, że wszyscy rozumieją swoje obowiązki.
Korzyści z tego są następujące: pozwala na utrzymanie stałego tempa rozwoju; redukuje całkowity czas rozwoju; zmniejsza liczbę dyskusji niezbędnych między projektantami, programistami i potencjalnymi klientami.
W ostatnim punkcie zastanawialiśmy się, co projektant powinien przekazać programistom. Chodzi o to, jaką formę powinien wykorzystać projektant, aby przekazać makiety projektu, dopracowany projekt, prototypy, tablice nastrojów - co projektant musi dostarczyć, aby skutecznie przekazać swoje intencje w formacie zrozumiałym dla programistów.
Istnieje wiele opcji, takich jak Zeplin lub InVision ale jedną z najczęstszych skarg deweloperów jest to, że te formaty nie zapewniają wszystkiego, czego potrzebują (np. eksportowane zasoby). Zazwyczaj dzieje się tak, ponieważ projektanci nie wyeksportowali swoich projektów prawidłowo. Wyjaśniając projektantom, czego mają się spodziewać, mogą łatwo przekazać odpowiednie aktywa.
Powinieneś stworzyć wewnętrzny dokument, który będzie zawierał konkretne wymagania techniczne dotyczące zasobów, narzędzi do projektowania, współpracy z programistami i innymi członkami zespołu; wreszcie, ten dokument powinien jasno określać, kiedy i jak należy dostarczyć projekty.
Zestaw rozwiązań projektowych i inżynierskich, a także przewodniki dotyczące ich wdrożenia, zapewnią szereg korzyści: integralność produktu; prostsze i szybsze wprowadzanie nowych członków zespołu; bardziej wydajna praca zarówno projektantów, jak i programistów (ponieważ mogą komunikować się w jednym języku zdefiniowanym przez system projektowania).
Korzyści z tego obejmują: poprawę ogólnej jakości pracy; zmniejsza "zwis" podczas skalowania zespołu; zwiększa szybkość zarówno projektowania, jak i rozwoju.
Wszyscy lubimy fajne nowe narzędzia, ale skuteczny zespół pracuje z jednolitym zestawem narzędzi, a zapewnienie tej jedności jest Twoim obowiązkiem.
Wszystkie narzędzia powinny być aktualne, ale jeśli aktualizacja zostanie pominięta z jakiegokolwiek powodu, wszyscy powinni ją pominąć.
Korzyści z tego obejmują: większe zaangażowanie zespołu; zwiększona szybkość projektowania i rozwoju; ulepszona współpraca zespołowa.
Programiści mają więcej szczęścia w zakresie tego zadania, ponieważ kontrola wersji dla kodu to dojrzała branża z wieloma opcjami. Trudno jest stworzyć podobne podejście dla projektantów, ponieważ procesy są tak różnorodne, ale w ubiegłym roku narzędzia takie jak Abstrakcyjny , Kaktus , i Roślina są coraz bardziej popularne. Możesz nawet mieć wielu projektantów pracujących nad jednym układem z czymś podobnym Figma .
Korzyści z tego są następujące: poprawa komunikacji; uproszczone skalowanie zespołu; szybkie projektowanie procesów, ponieważ wielu projektantów może wydajnie pracować nad jednym projektem.
Aby opisać wszystkie funkcje związane z projektami, spróbuj użyć "dokumentacji wizualnej" zamiast pisać specyfikacje techniczne. W większości przypadków deweloper może mieć interaktywny prototyp, aby zrozumieć podstawową logikę i znaleźć odpowiedzi na większość pytań.
Korzyści z tego to: skrócony czas pisania specyfikacji technicznej; zmniejsza skalę pracy dla twórców technicznych; programiści poświęcają mniej czasu na czytanie dokumentacji i więcej czasu na pisanie kodu; projektanci są bardziej produktywni; przyspieszone tempo rozwoju.
Nie ma absolutnie żadnego miejsca na projektowanie w wielu popularnych metodologii tworzenia oprogramowania; niezależnie od tego, jakiego procesu rozwoju używasz, znajdź miejsce dla projektantów.
Korzyści z tego są: zjednoczony zespół o ulepszonej komunikacji; zwiększona szybkość rozwoju; ograniczenie przeróbek i przestój programisty.
Powinieneś stale wykazywać wzrost ilościowych i jakościowych wskaźników dzięki wprowadzonym zmianom, zarówno dla członków zespołu, jak i top-managementu. Bez tego zespół niechętnie się zmieni, a najwyższe kierownictwo nie będzie w stanie zrozumieć, gdzie i dlaczego wydawane są dodatkowe zasoby. Ciągłe gromadzenie i prezentacja pozytywnych wyników po wprowadzeniu zmian pomoże uzyskać wiarygodność i niezbędne uprawnienia do dalszych zmian w obiegu pracy w zespole.
Korzyści obejmują: zwiększoną motywację i silniejszy zespół; ułatwianie nowych zasad i praktyk; wsparcie dla przyszłych innowacji.
Termin "DesOps" jest całkiem nowy i dopiero zaczyna nabierać znaczenia; first DesOps conference pierwsza konferencja DesOps odbyło się tylko w listopadzie, w Nowym Jorku.
Na razie po prostu nazwałbym to kulturą, która ma na celu rozwój i ułatwienie solidnych procesów projektowania. Ale uważam, że w niedalekiej przyszłości będziemy mieć to jako oddzielną rolę projektową w każdym zespole ds. Produktu. Uważam jednak, że możemy już bezpiecznie mówić o znaczeniu wprowadzenia tych praktyk, aby poprawić efektywność obiegu prac projektowych i ogólnie rozwoju produktu.