Mam do zrobienia sklep dla wujka firmy (bez projektu graficznego). Jeśli chodzi o funkcjonalność to ma być mniej więcej coś takiego http://www.buildingsuppliesrus.co.uk/, http://www.pustaki24.pl/.
Generalnie maja być dwie kategorie produktów. Pierwsza z nich to produkty, które można kupić przez sklep (dodanie do koszyka, podanie danych wysyłki, sposób płatności itd), np: http://www.pustaki24.pl/?pustaki-konstrukcyjne . Natomiast druga kategoria produktów ma charakter informacyjny - opis produktu i link do kontaktu w sprawie ceny, dodatkowych informacji, np. coś w tym stylu http://www.pustaki24.pl/?plyty-gladkie-i-lupane.
Jeśli chodzi o proces kupowania, to ma być bez rejestracji użytkownika, tak jak jest na pustaki24.pl. Klient wybiera produkty, przechodzi do formularzu, wybiera sposób płatności (integracja z PayPal, Payu) i otrzymuje na maila potwierdzenie.
Myślę również nad tym rownież czy jest sens, aby użyć Spree. Czy pisać od pieca w ROR?
Nie programuję zawodowo, programowanie to moje pasja. Na pewno zajmie mi to o wiele więcej czasu niż zawodowy programista, również nie mam takiego doświadczenia. Związku z tym nie mam pojęcia na jaką orientacyjną kwotę wycenić ten projekt. Byłbym bardzo wdzięczny za wszelkie wskazówki.
Eee, ja bym powiedział, że ilość godzin spędzonych * stawka za godzinę. Pamiętam z dawnych czasów, jak jeszcze się w takie rzeczy bawiłem że takie projekty lubią się rozwlekać i co więcej, mało kto rozumie (prócz programistów) dlaczego… A poszedł bym w kierunku spree.
Jak każde A jesli w dodatku projekt wypali, to horyzont przesuwa sie w strone nieskonczonosci (albo dalekiej skonczonosci).
Obserwuję trend na rynku tzw. projektow polegajacy na przechodzenie z modelu fixed-price na per-hour. Jesli sie da, wyceniajmy to w ten sposob + oszacowanie godzin (a najlepiej ich rozklad prawdopodobienstwa, w koncu szacowanie to szacowanie). Albo: wersja 1.0 w tyle i tyle godzin a potem zobaczymy co dalej
A propos szacowania - w ksiazce “The Clean Coder: A Code of Conduct for Professional Programmers” jest pare fajnych mysli na ten temat.
W krótkim podsumowaniu (choć warto przeczytać całość, np. przykład z wycenionym na 5h projektem backupu serwera pocztowego, który okazał się bardziej skomplikowany):
Zbyt niskie wyceny czasu trwania projektu biorą się z dwóch rzeczy
jesteśmy zbyt pewni we własne możliwości
nie jesteśmy w stanie przeprowadzić rzetelnej wyceny nie wiedząc jakie zmiany i problemy napotkamy, a to będziemy wiedzieć dopiero pisząc kod
Więc warto klientowi mocno podkreślać, że czas może ulec wydłużeniu w przypadku nieprzewizianych problemów, co może się wiązać z dodatkowymi kosztami.
A jesli w dodatku projekt wypali, to horyzont przesuwa sie w strone nieskonczonosci (albo dalekiej skonczonosci).