пропозиції роботи
Wypowiedzi
-
Jarosław K.:
Pominął Pan bardzo ważny aspekt. Sekretarka musi poświęcić "x" czasu na przepisywanie, co się przekłada na określony koszt roboczo-godzin.
W tym czasie sekretarka nie może wykonywać zadań, które do niej należą np. obsługa potencjalnych klientów. Rozwiązanie sprawia, że sekretarka jest bardziej obciążona (np. może to skutkować tym, że będzie mniej miła dla klientów - potencjalna strata)
Przypomnę warunki sytuacji: asystentka nie uczestniczy w procesie
sprzedaży, nie obsługuje klientów. Ujmując to inaczej: asystentka ma 'wolne moce przerobowe'.
Wypracowane w ten sposób "oszczędności" są czysto teoretyczne, firma nic nie zaoszczędzi, a straci. To że asystentka będzie miała mniej pracy nie oznacza przecież, że jej wynagrodzenie spadnie.
Rozwiązanie będzie rentowne kiedy:
- asystentka nie będzie się wyrabiała i będzie trzeba zatrudnić
drugą do pomocy w przepisywaniu danych,
- asystentka zaoszczędzony czas poświęci na generowanie przychodu
firmy
- itp.Jakub Mendys edytował(a) ten post dnia 29.10.09 o godzinie 14:52 -
Jarek Żeliński:
łatwiej będzie pomoc gdy powiesz jakie zadania u siebie chcesz wesprzeć a nie czego oczekujesz - osobiście naciskam klientow na pytanie "jak szybko przewieźć dzisięć ryz papieru", bo pytanie "kto ma tani samochod" zaowocuje samochodem, pierwsze zaś pytanie może skończyc sie poradą: mam do zaoferowania fajny elektryczny wózek, który takze moge wyporzyczac jeśli nie bedzie on stale obciążony praca na 100%.
Ja do tego pytania dodaję jeszcze "jaki to będzie miało wpływ na Twoją firmę?"
Czy jeśli spełnione zostaną Twoje oczekiwania to czy:
- zwiększysz przerób (dochód ze sprzedaży)?
- obniżysz koszty operacyjne?
- zmniejszysz inwestycje?
Podam przykład: znajoma skarży się, że w jej firmie sekretarka musi ręcznie przepisywać informacje o urlopach z jednego systemu do drugiego. Raziło ją to i chciała to zmienić (czytaj mieś program który ten proces zautomatyzuje). Jak tu wyglądają odpowiedzi na powyższe pytania zakładając, że praca zostanie zautomatyzowana?
- sprzedaż bez zmian (asystenta nie uczestniczy w sprzedaży),
- większe koszty operacyjne (asystentka będzie kosztować tyle samo, ale dojdą koszty utrzymania/amortyzacji rozwiązania),
- i do tego trzeba zainwestować czas i pieniądze żeby rozwiązanie wdrożyć.
Rentowność tego rozwiązania jest < 0. W tym scenariuszu dla firmy lepiej, żeby dane były przepisywane ręcznie!
W przykładzie celowo pomijam inne potencjalne rozwiązania. -
Korzystałem z Togethera (jeszcze Togethersofta, a potem Borlanda), System Architecta (Telelogic), Enterprise Architecta (Sparx Systems) i bawiłem się Rational Rose (IBM).
Dziś jestem posiadaczem licencji Enterprise Architecta i jestem z narzędzia bardzo zadowolony. Łatwość i szybkość obsługi, brak "dziwnych" ograniczeń i możliwość generowania w szerokim zakresie rozbudowanej dokumentacji (tworzonej przez skrypty VB w Wordzie przy użyciu API, bo ta wbudowana jest słabiutka). Do tego bardzo przystępna cena. Słaby punkt to wspomniany generator raportów i praca grupowa. To drugie jeszcze w wersji 7.1 potraktowana po macoszemu (żeby nie powiedzieć "byle jak"). Wersji 7.5 nie miałem pod tym kątem okazji sprawdzić.
Podobne wrażenia miałem tylko z Togetherem ale tylko tym sprzed 7-10 lat kiedy wytyczał standardy, był jeszcze prosty, a Borland nie zdążył go zepsuć.
System Architect - bardzo toporny, powolny i ciężki. Trudno mi się na nim pracowało.
Rational Rose tylko obwąchiwałem i to dość dawno temu i podobnie jak w przypadku System Architecta daleki jestem od zachwytu (choć Rose ma o niebo lepszy GUI). Osobiście i generalnie rozwiązania IBM ze względu na swoją złożoność i stopień komplikacji mi nie leżą - może i doświadczony użytkownik może tam zrobić cuda, ale mam wrażenie że żeby zrobić proste rzeczy też trzeba być ekspertem (osobiście do dziś nie mogę się oswoić nawet z LotusNotes ;-) )
Visual Paradigm nie widziałem choć czytając zachwyty Jarka mam nadzieję, że kiedyś będę miał okazję. Na przeszkodzie stoi moje zadowolenie z EA, które skutecznie zniechęca do dalszych poszukiwań ;-)Jakub Mendys edytował(a) ten post dnia 27.10.09 o godzinie 19:15 -
W przypadkach złożonych takich jak wspomniana obsługa faktur do problemu można podejść też tak (wychodząc poza UML):
1. Uprawnienia zdefiniować na poziomie definicji reguł biznesowych (Business Rules). Tu można skupić się tylko na tym aspekcie, a same reguły ładnie pogrupować.
2. W przypadkach użycia, w warunkach lub w treści scenariusza utworzyć odpowiednie powiązania wstawiając tekst "... zgodnie z BRxxx..." gdzie BRxxx to odniesienie do nadrzędnej reguły lub nawet polityki uprawnień.
Co o tym sądzicie?
Niezależnie od wszystkiego (opisu UCów, BR itd) w mojej specyfikacji w rozdziale "Wymagania poza funkcjonalne" znajdują się stosowne sekcje "Bezpieczeństwo" i "Autentykacja i autoryzacja" podsumowujące/opisujące temat na "odpowiednim poziomie" szczegółowości. -
Moja propozycja:
1a. Zidentyfikować role biznesowych w systemie, przy czym każdy z użytkowników może pełnić więcej niż jedną rolę. Każda tak wyodrębniona rola biznesowa to aktor.
1b. Zdefiniować relację aktorów (ról) z wykorzystaniem dziedziczenia (zgadzam się, że to dość sztywne więc do stosowania w ograniczonym zakresie)
2. Przypisać UCy do aktorów (ról) - ze względu na pkt. 1 powiązanie najczęściej wychodzi 1-1. W razie potrzeby dla UCa określam dodatkowe warunki (constraints).
3. Zdefiniować rozłączne grupy ról biznesowych, które zostaną zaimplementowane jako role systemowe (t.j. role do których użytkownik będzie przypisywany). -
Ankieta dla potencjalnych turystów jest ... słaba.
Pierwsze pytanie "Łotwa jest dla Pana/Pani krajem:" odpowiadam "nieznanym", a następnie dostaję serię pytań np: "Z czym kojarzy się Łotwa?", "Pana/Pani informacje o Łotwie pochodzą z" itd.
Przykro mi, ale nie dotrwałem do końca ankiety.
Co więcej obawiam się, że przez niedopracowane ankiety będę miał coraz mniej ochoty na wypełnianie kolejnych.
Proszę Panią i innych ankietujących o okazanie więcej staranności i tym samym szacunku dla ankietowanych. Nie niszczcie i nie zniechęcajcie do tej formy badań. -
Mateusz Dymek:
Anita A.:
prowadziłam szkolenie i osoba mnie zatrudniająca, na moją prośbę o wystawienie rekomendacji, powiedziała - proszę przesłać wzór a my podpiszemy się... ehhhh...
proszę więc o pomoc - naiwnie może, ale gdzie znaleźć wzór?
W dniu [data] Pani Anita Agnieszka prowadziła dla firmy [ich nazwa]* szkolenia z zakresu [nazwa szkolenia] polegające na [elementy, np prezentacja, demonstracja]*. Z powierzonego zadania wywiązała się w sposób rzetelny i profesjonalny [wymieniać wszystkie cechy, którymi chcesz się chwalić na rynku, tj: "z poczuciem humoru", "w ciekawy sposób", "ze stripteasem" (rzadki, ale jakże wyróżniający sposób!)].
Polecamy Panią Anitę Agnieszkę jako osobę kompetentną do prowadzenia szkoleń
[Firma, podłużna pieczątka, odcisk palca prezesa, ślady po kawie w rogu]
* opcja
Struktura generalnie taka - zaczynasz od tego, co robiłaś dla firmy (zakres obowiązków), potem w jaki sposób (wraz z cechami wyjątkowymi), następnie kończysz na poleceniu.
Dokładnie tak jak pisze Mateusz. Dodatkowo możesz dopisać (przed poleceniem) co Twój kontrahent zyskał dzięki Tobie. -
Jarek Żeliński:
Pominięcie jednego z powyższych czynników i masz: aplikację z której nikt nie korzysta,
czyli nie spełnia wymagań
aplikację z której korzysta się w sposób niewłaściwy,
czyli nie spełnia wymagań
aplikację z której nie da się korzystać itd.
czyli nie spełnia wymagań
Jeśli do wymagań podchodzić tak jak to opisałeś (i tak jak się powinno podchodzić) to zgoda: "nie spełnia wymagań".
Niejednokrotnie jednak widziałem "wymagania" które pomijały dwa ostatnie elementy, aplikacje które spełniały wszystkie takie "wymagania" i... praktycznie nadawały się do kosza.
Każda funkcja (niezależnie) działa poprawnie, ale ubranie tego wszystkiego post-factum w procedury dla ludzi było karkołomnym przedsięwzięciem. Efekt:
- aplikacja działa? działa!
- wymagania spełnione? spełnione!
- zapłacone? zapłacone!
a biedny końcowy użytkownik musi się męczyć, bo aplikacja bardziej mu w pracy przeszkadza niż pomaga. -
Przemek Wiśniewski:
Ha, i jeszcze jedna ciekawostka. Przez system rozumiemy nie tylko system komputerowy. Np: kiedy wdrazamy jakis "system"/projekt/program to w rezultacie moze to prowadzic do stworzenia/kupienia oprogramowania, kupienia urzadzen wspierajacych proces biznesowy (np: czytnik kodow kreskowych, drukarek, samochodow), nakladow na promocje, przeszkolenia pracownikow wykonujacych zadania w danych procesach itp itd.. To tak uprzedzajac pytanie czy analityk jest tylko od oprogramowania.
System komputerowy to też nie tylko samo oprogramowanie. System komputerowy to trzy elementy:
- oprogramowanie dla komputera,
- procedury użycia oprogramowania dla ludzi,
- ludzie którzy wykonują procedury na oprogramowaniu.
Pominięcie jednego z powyższych czynników i masz: aplikację z której nikt nie korzysta, aplikację z której korzysta się w sposób niewłaściwy, aplikację z której nie da się korzystać itd. Zadaniem analityka jest ogarnięcie całości.Jakub Mendys edytował(a) ten post dnia 15.09.09 o godzinie 15:08 -
1. kompletność modelu - tak twierdzi około 57 % osób związanych z wytwarzaniem oprogramowania;
2. termin przeglądu/inspekcji modelu - tak twierdzą pozostali.
A kiedy model jest kompletny? Jeśli dobrze Cię rozumiem Przerzucasz odpowiedź na pytanie "kiedy architektura jest skończona?" na pytanie "kiedy model jest skończony?". Wybacz, ale moim zdaniem niewiele to wnosi. Czy możesz rozwinąć swoją myśl?
Nie rozumiem też, dlaczego piszesz "mowa jest o projektach UML-owych". dlaczego kryteria ograniczasz tylko do tej jednej szczególnej notacji? -
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Programiści
-
Architektura jest modelem i jak każdy model przedstawia rzeczywistość z wybranego punktu widzenia w określonym celu. By określony cel był spełniony model sięga odpowiedniego poziomu dokładności. Tak więc, to zależy...
W Twoim pytaniu celem ma być rozpoczęcie prac programistycznych. Powiem więc, że poziom szczegółowości opisu architektury to taki, który pozwala programistom rozpocząć kodowanie. :-)
To znów zależy... :-) Od doświadczenia programistów, wielkości zespołu, stopnia komplikacji rozwiązania.
Możesz podejść do tego od drugiej strony i zastanowić się jaki skutek będzie miało NIE opisanie architektury na poziomie niższym niż masz ją opisaną obecnie. Jeśli odpowiedź jest "żaden" albo "znikomy" architekturę możesz uznać za skończoną.Jakub Mendys edytował(a) ten post dnia 14.09.09 o godzinie 14:36 -
Jeśli interesuje Cię żeglarstwo to warto pamiętać, że już od jakiegoś czasu PZŻ stracił monopol na kursy żeglarskie.
Patent PZŻ nie jest wymagany do prowadzenia mniejszych jachtów, a umiejętności żeglarskie wraz z potwierdzeniem ich posiadania (potrzebnym do czarteru łodzi) można zdobyć na innych niż PZŻ kursach realizowanych na przykład w ramach międzynarodowej licencji VDWS. Takie kursy zorientowane na zdobywaniu praktycznej wiedzy to, w porównaniu z kursem PZŻtu, znaczna oszczędność czasu i pieniędzy. -
Pomiędzy HC15 a HC16 jest dość spora różnica.
HC15 jest fajny do nauki, do przejażdżek z rodziną itp co nie znaczy, że nie można się nim pobawić. Można. Ale w regatach nie masz co szukać.
Na HC16 teściowej raczej nie zabierzesz, za to śmiga to znacznie lepiej no i scena regatowa jest dość spora.
Podsumowując HC15 dla rekreacji, HC16 dla sportu.
Pozdrawiam,
Kuba
PS Może Cię zainteresuje Otwarty Weekend z Katamaranami 12-13 września 2009 (więcej na http://www.hobieclass.pl/) -
Zleceń na wykonanie:
* ewidencji, projektów lub optymalizacji procesów biznesowych,
* analizy organizacji pod kątem wsparcia jej działań rozwiązaniami IT,
* definicji celów / dowodu koncepcji / stadium wykonalności inicjatyw IT,
* identyfikacji i opracowania wymagań biznesowych,
* specyfikacji rozwiązań,
* weryfikacji prototypów, bieżącego nadzoru nad realizacją projektów,
* planów testów systemowych i akceptacyjnych,
* wdrożenia systemów (przygotowanie migracji / szkolenia użytkowników),
* dokumentacji architektury funkcjonalnej/procesów/danych
i tym podobnych rozumianych jako szeroka analiza biznesowa lub systemowa. -
W celu wykrycia sprawcy proponuję popytać u siebie i u konkurencji o wasze dane - oczywiście w bardzo delikatny i wyważony sposób. W przypadkach o których wiem, znalezienie winowajcy tym sposobem nie nastręczało problemów.
Świat jest znacznie mniejszy niż się wydaje, a ludzie zazwyczaj mówią więcej niż by chcieli.
Powodzenia! -
A co ja mam zrobić, że tak laicko zapytam, żeby móc wziąć udział w treningach (jeśli oczywiście wiesz :-))) innych niż laser bahia :-))) i następnie regularnie brać udział w regatach.... przy czym chodzi mi o jakies bardziej zaawansowane pływanie.. Ja się bardzo chętnie przyczepię jako majtek/załogant :-))))))))) do jakiejś trenującej ekipy...
Albo kupić własny sprzęt i dołączyć do istniejącej trenującej grupy albo znaleźć sobie kogoś kto ma sprzęt i szuka załogi. A potem jeździć, jeździć i jeździć na treningi i regaty.
Biorąc pod uwagę powyższe pływanie na Laserze wygląda bardzo atrakcyjnie: nie musisz martwić się o sprzęt, także tym że inni mają lepszy, a załogę myślę, że bez problemu dobierzesz sobie na miejscu. -
jak było na łódkach ? w Warszawie wiało...
Na Zegrzu wiało 3-4 w porywach do 6. Można było pośmigać. Relacji z treningu laserów nie zdam bo weekend przesiedziałem siedziałem na hobie catach.
Na kolejny trening wybieram się dopiero 19go. Treningi w przeddzień regat są tradycyjnie prowadzone przez byłych/obecnych zawodników/instruktorów żeglarstwa regatowego.Jakub Mendys edytował(a) ten post dnia 07.09.09 o godzinie 10:14
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
