Czy na własne potrzeby używacie jakiejś metodyki szacowania oprogramowania (w szczególności RoR)?
Chodzi mi o wstępne przybliżenie czasu realizacji projektu (czyli moich kosztów) w tym takie rzeczy jak kodowanie, testowanie, administrowanie, kontakty z użytkownikiem itp. Myślę o uproszczeniach typu: czas realizacji = liczba modeli x współczynnik + … + … + …
Pozdrawiam
Artur
Tylko jeśli klient potrafi przedstawić zamkniętą i dopracowaną w detalach specyfikację. Z czym jeszcze się nie spotkałem, zazwyczaj w nie więcej niż kwadrans wykazywałem klientowi że tak naprawdę nie ma wizji ani pojęcia jak jego aplikacja ma działać – więc nie da się tego wycenić.
Dlatego nie projektu a pojedynczych, ściśle opisanych ficzerów, oraz nie “wycena” a “estymacja”.
Nie ma czegoś takiego, od lat ludzie szukają i nie znajdują. Powstają całe metodyki które maja za zadanie sobie z tym radzić. Całe modele biznesowe. Ludzie robią z tego doktoraty. To jest tak jakbyś przyszedł do architekta i powiedział: potrzeba mi systemu wyceny budynku na zasadzie czas realizacji = liczba kibli + liczba ścian + … + …
Ja stosuje inny system - przy kazdym projekcie probuje ustalic jaka WARTOSC dla klienta bedzie miec dana aplikacja. I to jest podstawa do szacunkow; kluczem jest jak najlepsze zapoznanie sie z tym co robi, co robi jego konkurencja, jak duzy jest to rynek itp. Zamiast obliczac wlasne koszty i dodawac ustalony markup na poziomie X%, lepiej spojrzec na to z jego strony - ile moze zaplacic tak, by nadal stanowilo to dla niego dlugoterminowy zysk (badz prawdopodobny dodatni wzrost z inwestycji)
Z ksiazek do estymacji polecam “Agile estimation and planning” (Mike Cohn) i “Software Estimation: Demystifying the Black Art” (Steve McConnell, autor ‘Code Complete’ i ‘Rapid Development’, ktore tez polecam ale z innych powodow) - ale jak to slusznie Tomash zauwaza, to jak optymalizacja na horyzoncie nieskonczonym z niewiadoma liczba zmiennych. Bardziej od obliczania matematycznych modeli sprawdza sie tu wyczucie osoby/firmy, jej potrzeb i sytuacji
pozdrawiam
Marek
Co jeśli wydaje Ci się, że długoterminowo ten konkretny projekt nie wypali i wartość jego będzie 0 a klient i tak chce Ciebie i chce Ci zapłacić ok stawkę? W sumie nie jest to win-win (wg. naszych szacunków bo zawsze szalony pomysł klienta może wypalić), więc brać czy nie brać 
Oszacować własne koszty (czyli dokonać estymacji projektu) musisz dokonać tak czy owak.
A skad wiesz/mozesz przypuszczac, ze/czy dany projekt czy pomysl nie wypali? To czy wypali czy nie w glownej mierze zalezy od tego, jaka prace wykona osoba, ktora prace zleca i nie jest to zwiazane (albo malo) z technologicznym aspektem wykonania. Wiec zakladam, ze on wykona rownie dobra robote, co ja Ale jesli projekt trwa np. 5 miesiecy i w 3cim miesiacu widze, ze para idzie w gwizdek, to swiadomie zwalniam tempo i probuje zasugerowac w ktora strone skierowac sily/srodki. Nie wierze w tzw. ‘dojenie’ klienta, bo efekt koncowy bedzie taki, ze byc moze zaplaci, ale bedzie niezadowolony (i nie wroci / nie poleci ) - ale na poczatku mozna i trzeba zalozyc, ze sie uda - bo niby czemu nie?
Masz racje - chodzilo mi o to, ze cena nie musi byc (i nie powinna - z wolnorynkowego punktu widzenia) zwykla funkcja kosztow.
Nic nie mogę wiedzieć na pewno, opieram się tylko na swojej logice i doświadczeniu.
@mark
Dzięki za pomysły na książki. Drugą mam ale trochę za ciężka dla małych projektów. Na pierwszą zapoluję, szczególnie po tym jak przeczytałem kilka prezentacji autora na stronie: http://www.mountaingoatsoftware.com/presentations/index-all?page=1
Pozdrawiam
Artur