Ratowanie firm

0

Guten tag,

Kilka razy natknąłem się na "zajmowanie się ratowaniem firm", ale czym właściwie jest to całe ratowanie firm jeżeli chodzi o IT? albo właściwie jak to wygląda w praktyce jeżeli chodzi o np. reklamę, pozyskiwanie klientów?

bo działanie to chyba po prostu coś z tego:

  • przepisanie kodu czegoś

  • zmiana infrastruktury(soft)/narzędzi IT

  • poprawa procesów

  • benchmarking/profiling/pentesting

czy nie?

3

Mysle, ze to raczej cala kwestia pozyskiwania klientow, zmiana polityki firmy w sprawie jakosci produktu, zmiana skladu zrspolu (redukcje albo zatrudnienie nowych ludzi itd).

Zwykle to nie slaby kod jest przyczyna slabej kondycji firmy ale jej oderwanie od klienta i jego potrzeb albo nie dostateczna promocja.

0

Czesto - nie wyrabiaja sie w odpowiednim czasie, żeby oddac projekt lub czas developmentu za bardzo sie wydluzyl. Zła organizacja pracy.

I wtedy przychodzi ktos, caly na bialo.

4

Dawno sie nie udzielałem na forum, ale miałem niedawno taka sytuacje przy zmianie pracodawcy.

Poprzednia firma, mega dużo sie nauczyłem, bardzo fajny dział IT, ale zarząd zamknięty w schematach z poprzednich lat, „bo tak sie kiedyś robilo”, zero albo bardzo mało nowości, branie projektów supportowych bez wstępnych audytów, bo przecież kasa jest kasa. Teraz przez pol roku zostali tak mocno w tyle ze bedzie im cieżko odbić sie, mimo ze maja jeszcze kasę i projekty, ale juz sa na krzywej spadkowej :)

Nowa firma, techniczny PM, nastawieni bardzo na nowości, wszystkie nowe bajery, zgodnie z dobrymi praktykami, widać ze naprawdę im zależy, słuchają programistów i biorą pod uwagę ich zdanie.

Wg mnie to nakreślenie wizji przed menadżerów, trzymanie sie jej, ale i przyznawanie sie do bledow jest bardzo ważne i jest przyczyna albo sukcesu albo porażki. Ratowanie firm powinno zaczynać sie od „głowy” ;)

1

przepisanie kodu czegoś
zmiana infrastruktury(soft)/narzędzi IT

To raczej tylko podniesie koszty i pogrąży firmę jeszcze mocniej :D

poprawa procesów

dość ogólne :D

benchmarking/profiling/pentesting

jw. to też raczej dodatkowe koszty

A teraz z takich prawdziwych działań, szczególnie w IT:

  • Wyobraź sobie że masz jakiś produkt i siedzi nad nim mocny team developerów i klepią nowe ficzery non stop. Tylko że przychody nie rosną, klientów jest tylu ilu było. Więc czy te ficzery są konieczne? Taki team 15 developerów 20k to jest 300k miesięcznie. To jest spora inwestycja i musi się zwracać. Może w takim razie lepiej przesunąć ich do innych projektów albo zwolnić?
  • Niektóre projekty osiągają swój kres i z fazy developmentu muszą przejść w maintenance. Trochę jw, nie zawsze jest sens klepać nowe rzeczy i mocno coś rozwijać. Czasem trzeba po prostu to ustabilizować i świadczyć support, a do tego trzeba ci np. 2 ludzi a nie 20.
  • Niektóre projekty ciągną firmę na dno, ale w ogólnofirmowym widoku tego nie zobaczysz, bo inne projekty przynoszą zyski.

W IT, szczególnie z managementem wywodzącym się też z IT, jest często tak że liczy się produkt i inżynieria, a to nie wystarczy żeby odnieść sukces. Fajnie by było jakby wystarczyło "zrobić dobry produkt i się sprzeda", ale w prawdziwym życiu to zwykle mrzonka.
I potem wjeżdża taki Papa Giovanni który w nosie ma inżynierie i produkty, za to ma excela z przychodami i kosztami... :)

Innym przypadkiem "ratunku" jest problem z dotrzymaniem terminów i karami umownymi, ale wtedy zamiast pana z Excelem zaprasza się jakiegoś czarodzieja jak Jarek, żeby "za 3 miesiące działało".

2

Albo np. zamiast zatrudniać 5 specjalistów z kraju X, zatrudniasz 5 developerów z kraju Y, bo są o 50-80% tańsi. Dzięki czemu na papierze pokazujesz zarządowi oszczędność, inkasujesz premię, a gdy po pół roku malowania trawy na zielono, wreszcie okaże się, że projekt pada, bo nowi właściwie niczego nie zrobili, gdyż tak w sumie to nawet nie znają technologii ani biznesu, a w ogóle to całe życie byli rolnikami, to Ciebie już tam przecież dawno nie ma.

0

Ratowanie firm to mi się kojarzy z tym, że jeśli mała firma zostanie wykupiona przez większą. Albo jeśli inwestor zgodzi się dołożyć kasy.

Ew. pivot, czyli, że firma robi jedną rzecz, a okazuje się, że klienci tego nie chcą, więc zaczyna robić zupełnie inne produkty, inne usługi.

No i bankructwo - też czasem "ratuje się" firmy w ten sposób, jak już nic innego nie można zrobić.

przepisanie kodu czegoś

To chyba musiałaby być firma, która opiera swoją bytność na jednym tylko projekcie, żeby coś takiego mogło "uratować firmę", i ten projekt musiałby być w miarę mały (bo jak projekt jest duży to zwykle nie opłaca się przepisywać, przynajmniej nie w całości). Mnie to akurat wkurza, bo jako programista mam ciągoty do wyrzucania legacy kodu i przepisywania od nowa na czysto. Tylko, że często się to nie opłaca z perspektywy biznesowej.

2

przepisanie kodu czegoś

To chyba musiałaby być firma, która opiera swoją bytność na jednym tylko projekcie, żeby coś takiego mogło "uratować firmę", i ten projekt musiałby być w miarę mały (bo jak projekt jest duży to zwykle nie opłaca się przepisywać, przynajmniej nie w całości). Mnie to akurat wkurza, bo jako programista mam ciągoty do wyrzucania legacy kodu i przepisywania od nowa na czysto. Tylko, że często się to nie opłaca z perspektywy biznesowej.

Z tym przepisywanie kodu to jest dziwnie. Z jednej strony Uncle Bob w Czystym Kodzie przytacza wiele przykładów firm które dokonały samoubicia, bo zaczęły przepisywać projekt zupełnie od początku. Z drugiej Uncle Bob wielokrotnie pisze, że refactoring i redesign jest potrzebny. Z trzeciej strony mamy przykład Allegro, firmy która przepisała cały swój kod i to przeżyła.

2

mamy przykład Allegro, firmy która przepisała cały swój kod i to przeżyła.

Tylko Allegro nie wymagało ratowania, a przepisanie systemu zrobili w ramach rozwoju. To był długotrwały, dobrze zaplanowany proces modernizacji, a nie robiony ad-hoc plan naprawczy. Totalnie nie powinniśmy tego podawać jako przykładu w kontekście ratowania firmy.

0

Co do przepisania vs refactoringu i redesignu:
Przepisując zwykle przepisujesz całość i mało kiedy się to udaje.
Refactoring i redesign robisz na bieżąco pracując z systemem.

Także nie jest to ze sobą sprzeczne, bo to są dwa różne podejścia.

3

Ratowanie firmy to raczej kwestia zarządzania a nie poprawiania kodu. Gówniany kod (czy raczej produkt) nie bierze się sam z siebie, tylko piszą go ludzie, którym brak kompetencji, motywacji albo elementarnej odpowiedzialności za produkty swojej pracy, ewentualnie dostają jakieś wymagania z d...y, jakaś osoba, która powinna podejmować decyzje ich nie podejmuje, albo blokuje zmiany. Podsumowując problemy z rzeczami technicznymi są z moich obserwacji raczej objawem niż przyczyną choroby.

1 użytkowników online, w tym zalogowanych: 0, gości: 1