Czy analiza powinna być niezależna od technologii? [Zamknięte]

Wczoraj pokłóciłem się z jednym z moich kolegów. On (analityk biznesowy, wcześniej programista) uważa, że ​​powinien być świadomy technologii zastosowanej do wdrożenia systemu, aby mógł podejmować lepsze decyzje projektowe. Moim zdaniem (jestem programistą), analiza nie powinna być w żaden sposób powiązana z technologią i uważam, że dobry analityk może zrobić świetny projekt bez martwienia się o szczegóły implementacji.

Czy mam rację tak myśleć? Czy istnieją powody, dla których analityk biznesowy musiałby znać technologię zastosowaną do wdrożenia systemu?

EDYCJA: Uważam, że użyłem niewłaściwego terminu, mówiąc business analyst. Może miałem na myśli architekta lub analityka systemowego. Nie jestem przyzwyczajony do tych warunków. Miałem na myśli coś takiego jak architekt lub analityk systemowy, jeśli wolisz.

Dziękujemy wszystkim za wspaniałe odpowiedzi! Nie jestem jeszcze zbyt doświadczony i cieszę się, że otworzyłeś mi oczy na to.

Z pewnością istnieją sytuacje, w których analityk biznesowy ma sens, aby zrozumieć technologię przynajmniej na tyle dobrze, aby zrozumieć, gdzie warto zapytać użytkownika biznesowego o ważność danej funkcji. Na przykład, jeśli firma jest przyzwyczajona do zachowania grubej aplikacji klienckiej, podczas gdy nowa aplikacja będzie oparta na sieci, prawdopodobne jest, że będzie wiele „wymagań”, które byłyby błahe dla grubego klienta, ale stosunkowo trudne z aplikacją internetową. Jeśli analityk biznesowy rozumie, czy prośba firmy będzie trywialna dla zespołu programistów, czy też będzie wymagała 20 godzin pracy nad AJAX,

W przypadku każdego projektu istnieje prawdopodobnie duża liczba zestawów wymagań, które w rzeczywistości zaspokoją biznes, dokonując różnego rodzaju kompromisów. Im więcej wiedzy analityk biznesowy ma na temat dokonywanych kompromisów, tym większe prawdopodobieństwo, że dostarczy zestaw wymagań, które maksymalizują korzyści dla firmy przy jednoczesnym minimalizowaniu kosztów.

Pracując po obu stronach tego numeru, muszę zgodzić się z analitykiem. Widziałem niektóre spektakularnie słabe projekty wynikające z niezrozumienia możliwości tej technologii. W niektórych przypadkach było to wynikiem przyjęcia szumu marketingowego za prawdę. Ogólnie problem polega na generowaniu specyfikacji, które nie pasują do możliwości technicznych.

Analityk powinien określić, co należy zrobić, kiedy i przez kogo. Powinni wiedzieć, dlaczego tak się dzieje. Priorytet rozwoju powinien być bardziej zależny od przyczyny niż od innych czynników. Zespół projektowy i programistyczny musi poradzić sobie z How. Aby opracować opłacalne systemy, analitycy muszą określić, co należy zrobić w sposób, który nie przesuwa granic dostępnych technologii.

Przekraczanie granic może podnieść koszty na wiele sposobów, ale w niektórych przypadkach może przynieść znaczny zwrot. Niektóre czynniki kosztowe to:

• Konieczne może być przeprowadzenie eksperymentów w celu opracowania działającego rozwiązania;
• Konieczne może być pozyskanie nowych pracowników lub konsultantów o specjalistycznej wiedzy;
• Konieczne może być szkolenie w zakresie nowej technologii;
• Rozwój jest zwykle wolniejszy, a odsetek błędów wyższy; i
• Dodatkowe wysiłki mogą opóźnić prostsze rozwiązania, które mają bardziej bezpośrednią wartość.

Jeśli technologia, która zostanie zastosowana, jest znana, analitycy powinni wziąć to pod uwagę przy tworzeniu projektu. Różne technologie działają inaczej, a projekt, który nie uwzględnia tych różnic, będzie miał problemy.

Jednak analitycy biznesowi nie powinni przejmować się używaną technologią, ich zadaniem jest zebranie reguł biznesowych i uczynienie ich zrozumiałymi dla zespołu technicznego. Analitycy systemów / architekci / projektanci lub jakakolwiek inna nazwa, jaką mogą otrzymać, powinni znać stosowane technologie i projektować wokół nich, ponieważ to oni powinni projektować, a nie analitycy biznesowi.

Uważam, że między tymi dwoma kierunkami myślenia istnieje pewna bardziej realistyczna kwestia. Chociaż projekt wysokiego poziomu może być najlepszy, gdy jest utrzymywany bez względu na technologię, należy wziąć pod uwagę znane rzeczywiste ograniczenia i wymagania, które należy uwzględnić w projekcie. Na jakim poziomie jest ten projekt? Czy masz wystarczające wymagania? Jak elastyczne jest środowisko? Czy zarządzanie jest inwestowane w konkretny kierunek techniczny?

Czy nie ma parametrów operacyjnych, które poprowadzą Cię w określonym kierunku? Czy masz szeroki wachlarz zasobów, które są w stanie zaimplementować rozwiązanie w dowolnym stosie technologii? Czy występują problemy z interoperacyjnością wymagające dostępu do innych systemów?

Odpowiedzi na te pytania są potrzebne, aby można było ostatecznie stwierdzić, czy technologia powinna być częścią równania, czy też projekt powinien kierować wyborem technologii.

Biorąc pod uwagę brak ograniczeń i będąc projektem na wysokim poziomie, mogę zgodzić się z twoim zdaniem, że projekt jest naprawdę agnostyczny. Jednak przez ponad 20 lat mojego doświadczenia rzadko znajdowałem się w sytuacji, w której nie było żadnych ograniczeń, które ograniczałyby mój wybór - i które kierowały mój projekt ku konkretnym technologiom lub rodzinom technologii.

Interfejs użytkownika idealny byłby gdzie użytkownik uważa myśl, i to, co chcieli zrobić to po prostu zrobić. Wszystko to jest ograniczone przez ograniczenia technologiczne, którymi dysponujemy, więc BA musi oczywiście zrozumieć, w jakim kontekście może zaprojektować system.

Różne technologie mogą mieć bardzo różne struktury kosztów i wydajności w celu rozwiązania danego problemu. Koszty te mogą obejmować takie rzeczy, jak koszty wynajmu w okolicy, koszty energii i chłodzenia dla konkretnych systemów, istniejący kod i istniejące możliwości ponownego wykorzystania sprzętu itp. Itd. Tak, być może więc można zignorować te ograniczenia i szczegóły dotyczące konkretnych technologii jeśli pracuje się nad projektem, w którym koszt i wydajność nie są tak ważne, jak inne względy (takie jak bezpieczeństwo lotnicze, kontrola elektrowni jądrowych, implanty medyczne itp.). Jednak w większości sytuacji biznesowych zarząd może dbać o strukturę kosztów potencjalnych rozwiązań w porównaniu z korzyściami z wdrożenia systemu.

Analityk biznesowy powinien wiedzieć, jaką aplikację opracowujemy, np. * Aplikacja internetowa / Aplikacja konsolowa / Aplikacja mobilna / Aplikacja raportująca itp. * , Aby mogła lepiej wymyślić fajny zestaw funkcji dla aplikacji lub odepchnąć użytkownika na niemożliwe oczekiwania, takie jak zagnieżdżanie i upuszczanie trzeciego poziomu (np.).

On / ona nie musi wiedzieć, która technologia, taka jak Java / C # / Python / SQL itp.

Sam proces analizy musi być całkowicie niezależny od technologii. Badając klienta i jego potrzeby, musisz to zrobić z całkowicie otwartym umysłem. Drugą stroną medalu jest jednak to, że analityk jest często proszony o przedstawienie zaleceń i może być również zobowiązany do obsługi architektury systemu. Jest to zupełnie inny aspekt roli, w której kluczowe jest szersze zrozumienie dostępnych technologii, ponieważ może to ogromnie zmienić dla klienta nie tylko pod względem możliwości uruchomienia projektu, ale także pod względem długoterminowych potrzeb klienta i trwałości samego projektu.

Chociaż prawdą jest, że większa część oprogramowania do projektowania jest zasadniczo taka sama, niezależnie od zastosowanej technologii, zawsze istnieją obszary, w których wybór technologii będzie zależał od projektu. Wybór platformy może wpłynąć na wybór języka i interfejsu API, a dostępność wiedzy specjalistycznej, wsparcia, a nawet kosztów będzie miała również wpływ na dokonane wybory. Tak więc z jednej perspektywy część twojego stanowiska jest uzasadniona tym, że faktyczna analiza powinna być przeprowadzona bez wpływu jakiejkolwiek konkretnej technologii, jednak użycie analizy do ustalenia projektu zawsze będzie wymagało szerszej wiedzy technologicznej, aby analityk mógł wydać zalecenia co pozwoli na zastosowanie projektów mających na celu zaspokojenie potrzeb klienta.

Każda technologia ma ograniczenia i ograniczenia, dlatego analityk ma pewien sens, biorąc pod uwagę te ograniczenia. Z drugiej strony analityk, który dobrze zna .net, ale nie widział Java od końca lat dziewięćdziesiątych, najprawdopodobniej zaprojektuje rozwiązanie .net - używając terminologii .net i wzorców projektowych - nawet jeśli Java (lub RoR itp.) lepiej by pasowało do problemu. Później stosunkowo trudno jest wdrożyć taki projekt w innej technologii.

Dlatego uważam, że analityk powinien być agnostyczny, gdy technologia nie została jeszcze wybrana, ale ma doświadczenie w tych przypadkach, w których wybór już został dokonany.