Temat: projektowanie a programowanie...
Zgadzam się z Wami wszystkimi.
Inżynier nie powinien wtrącać się w to, co wymyślił analityk i przerabiać mu analizy po swojemu. W końcu to analityk ma kontakt z klientem, ma najszerszy pogląd na zagadnienie i zna dobre praktyki projektowania elastycznych systemów informacyjnych. Na tej podstawie wypracował koncepcję, którą chce, aby mu zrealizować. To oczywiste. Ale pod następującymi warunkami:
a) gdy to, co wymyślił analityk nie jest "branżowym idiotyzmem". Inżynier też może być świetnym branżowcem i wtedy wręcz powinien zgłosić oczywiste wady projektu z branżowego punktu widzenia. Dotyczy to zarówno poprawności i sensowności procesu, kwestii prawnych z nim związanych, "dobrych praktyk" w branży i rzeczywistego ich w niej stosowania. A ponieważ firmuje produkt także swoim nazwiskiem, może nie chcieć, by figurowało przy jakiejś "kupie".
b) gdy to, co wymyślił analityk jest implementowalne w rozsądny (szerokie znaczenie, np. czy dostępny jest szeroki wybór bibliotek realizujących dane zadanie) sposób w technologii, w jakiej pracuje się w danej firmie i w odniesieniu do harmonogramów i mocy produkcyjnych. Być może można z czegoś zrezygnować lub pójść nieco inną drogą, by dojść do kompromisu
c) gdy to, co wymyślił analityk da się zintegrować z istniejącymi rozwiązaniami w rozsądnym czasie. Być może nieznaczna ingerencja w proces pozwoli lepiej dopasować potrzeby do rzeczywistości.
d) gdy to, co wymyślił analityk nie grozi znaczącymi problemami w razie awarii systemu, wąskimi gardłami, czy lukami bezpieczeństwa. Spotkałem się u dwóch analityków z kompletnym brakiem zrozumienia zasad asynchronicznej komunikacji między systemami i "kolejki komunikacji" były dla nich kompletną abstrakcją. Najlepiej, jak by wszystko było synchroniczne, bo tak prościej, nie trzeba pamiętać żadnych identyfikatorów, priorytetów, sprawdzać kolejek, "udziwniać" (jak to oni powiedzieli) zagadnienia. A że system wisi na oczekiwanie "ACK", bo zawiesiła się procedura po drugiej stronie... who cares :D Inny przykład: synchronizowane są bazy danych w kilku lokalizacjach klienta. Wymaga to postawienia w nich serwerów. Rosną koszty, a analityk jest naciskany przez handlowców, by ich nie generować. Ten, zamiast upewnić się jakie dane są wymieniane, zastanowić nad "częściową synchronizacją" i "repozytoriami dostępnej wiedzy", wymyśla doraźnie rozwiązanie, gdzie jest jeden centralny serwer i placówki łączą się do niego po tunelu, widząc go jak w intranecie. Wszyscy są zadowoleni - koszty spadły z N serwerów (grube dziesiątki kpln) do jednego. Co jednak, gdy padnie gdziekolwiek połączenie internetowe? "Och, przejdziemy rezerwowo na 3G". Rzecz w tym, że ilość transmitowanych danych jest rzędu MB/sek, a czasy odpowiedzi mają być krótkie, natomiast sieć z trudem "wskakuje" na UMTS, nie mówiąc o HSDPA/HSUPA, a podczas burzy zrywa co chwila połączenie. No... o tym to on nie pomyślał, bo przecież komórka wszędzie łapie zasięg, to i internet powinien być dostępny. Takich przykładów znam wiele.
e) analityk nie próbuje wtrącać się w architekturę techniczną i stosowane wzorce projektowo-architektoniczne, zwłaszcza przy systemach rozproszonych, jeśli ich nie rozumie. Jeśli je rozumie, to jest świetnym partnerem do dyskusji i współpraca analityk-inżynier będzie szczególnie owocna. Ale nie spotkałem wielu takich osób. Raczej byli to inżynierowie "przestawieni" na analityków, a tylko raz spotkałem analityka "nieinformatycznego", który miał do tego głowę.
Musimy pamiętać, że w informatyce bardzo wielu z nas pełniło, w różnych momentach kariery zawodowej, różne obowiązki - od zaciskania "erjotów" na kablach sieciowych i "kładzenia" sieci, przez stawianie serwerów różnego rodzaju (www, mail, ftp), administrację siecią, pisanie oprogramowania, wyjazdy do klientów (analiza), projektowanie rozwiązań od strony architektury i technologii po testowanie i wdrażanie. A to oznacza, że część ludzi "po IT" ma doświadczenie także branżowe i będzie wchodzić w konflikt z analitykami, którzy z kolei rzadziej (wedle moich obserwacji, ale to tylko obserwacje cząstkowe) mają doświadczenie IT.
PS: aaa, już rozumiem, gdzie dysonans :) Inżynier to NIE "coder". Programiści są faktycznie na końcu procesu i raczej trudno, by wchodzili w analizę, chyba, że wyłapią przy okazji jakiś niuans, który umknął wszystkim innym. Ale ilu programistów rozmawia z analitykami? Zwykle jest albo inżynier, albo chociaż kierownik tychże. I inżynier nie może po prostu "łyknąć" projektu bez chwili refleksji, czy wszystko, co tam zapisano, ma sens. W końcu to na niego potem spadnie naprawianie wszystkiego od strony młotka i gwoździa. A kiedy powstaną wylewki, trudno będzie położyć ogrzewanie podłogowe ;)
PS: no i pamiętajmy, że nie każdy jest Wami, tj. analitykami z doświadczeniem w wielu projektach. Często są to osoby, które dopiero przyuczają się do zawodu. Wy zaś, m.in. Ty Jarku czy Maćku (pewnie śledzisz wątek :) ) zjedliście na tym zęby i gdy coś oddacie produkcji, to ta będzie mogła faktycznie tylko siąść i... budować :) Rzeczywistość bywa mniej kolorowa.
Adrian Olszewski edytował(a) ten post dnia 04.06.11 o godzinie 14:57
пропозиції роботи
