Przygotowanie do tworzenia stron internetowych i cały proces projektowy


9

Pracuję jako samotny programista w projektach internetowych (front i back-end) - ukończyłem kilka projektów, więc jestem całkiem nowy, przeczytałem i wypróbowałem kilka podejść i osiągnąłem sposób o nich. Pytanie i mój opis są dość długie, więc proszę o cierpliwość.

To, czego szukam, to:
1. Przygotowanie / planowanie, które zwykle powinno być wykonane przed rozpoczęciem programowania, gdy dokładnie wiesz, co należy zbudować.
2. Z własnego doświadczenia proszę o opinie / sugestie na temat procesu, który aktualnie obserwuję.

Klienci, z którymi pracuję, są na ogół startupami i mają ograniczone budżety, więc nie mogę ich obciążać za godzinę (myślę, że tak duże firmy zwykle rozliczają swoich klientów [za roboczogodzinę] za projekty deweloperskie) i muszą pracować z ustalonym budżetem.

Oto proces, który aktualnie śledzę:
1. Oceń zakres projektu i spróbuj zrozumieć, co starają się osiągnąć na kilku spotkaniach.
2. Daj im szorstką figurę z cytatem, który ogólnie opisuje, czego oczekują od projektu, staram się sprecyzować funkcje, ale nie poświęcam temu zbyt wiele czasu, ponieważ znam klient może po prostu pytać o oferty, a nie konwertować.
3. Postępuję zgodnie z sugestią Jeffa Atwooda dotyczącą płatności i pracy:

15% płatności - z góry przed rozpoczęciem jakiejkolwiek pracy Na
tym etapie wykonywana jest makieta HTML końcowej strony internetowej, schemat blokowy (z YEd ) opisujący stronę tak szczegółowo, jak to możliwe, oraz dokument, który wymienia inne funkcje, których nie ma na schemacie blokowym . Odbywa się to poprzez zapoznanie się ze wszystkimi szczegółami projektu i sfinalizowanie bitów, które będą pasować i rzeczy, które są zbyt pracochłonne do wdrożenia za ustaloną cenę. Ponieważ szczegóły nie zostały wcześniej omówione, ich części stanowią mniej więcej negocjacje dotyczące tego, co faktycznie otrzymają. Ponieważ jest to projekt o ustalonym budżecie, muszą być ustalone wymagania, w przeciwnym razie moja cena będzie spadać w miarę dodawania kolejnych funkcji.
Finalizowana jest także kolorystyka, szkielet i projekt PSD.

35% płatności - Rozpocznij rozwój
Projekt jest naprawiony, rozpocznij rozwój. Hostuję witrynę na moim serwerze, na której klient może uzyskać dostęp do interfejsu, ale nie ma dostępu do żadnego kodu.

30% płatności - przenieś kod na serwer klienta / podaj klientowi szczegóły dostępu do serwera
Uruchom witrynę.

Płatność 20% - kilka tygodni po uruchomieniu witryny, po usunięciu wszystkich błędów.


Pytania:
1. Kiedy dokładnie wiesz, co zamierzasz zbudować, jakie planowanie zrobiłbyś przed rozpoczęciem kodowania?

2. Z twojego doświadczenia, jakie części całego procesu zrobiłbyś inaczej?


Niestety wielu klientów nigdy nie dochodzi do tego, by wiedzieć dokładnie, co chcą, abyś zbudował. Najlepszym podejściem, jakie znalazłem, jest wykonanie makiet niektórych ważnych stron, a następnie usiąść i zacząć opowiadać historie użytkowników. Celowo popełniam niektóre historie w sposób oczywisty niewłaściwy, zmuszając klienta do powiedzenia: „Nie, chcę, żeby działało w ten sposób ...” To ostatecznie prowadzi nas do czegoś zbliżającego się do specyfikacji projektu, ale niezmiennie zmienia się później. Westchnienie.
Peter Rowell,

@Peter, celowe wprowadzanie fałszywych historii użytkowników może czasem obrócić cię przeciw i spowodować, że klient straci zaufanie do ciebie. Tę technikę należy stosować ostrożnie.
wałek klonowy

@maple_shaft: Zdaję sobie z tego sprawę. Kiedy mówię „oczywiście źle”, mam na myśli tak rażąco Bogusa®, że zwykle mam więcej niż kilka chichotów. Zapewnienie pełnego zainwestowania klienta w jego stronę internetową (wizja / czas / pieniądze) ma kluczowe znaczenie dla udanego projektu. To szokujące (przynajmniej dla mnie), jak wiele osób uważa, że ​​nowa strona jest czymś, co mogą wymyślić ręcznie i będzie się magicznie pojawiać.
Peter Rowell,

Zgadzam się również z makietami, żadna ilość pisanego tekstu nie sprawi, że klient zrozumie, co otrzyma (większość nie może tego zrozumieć lub chce to zrozumieć) - makieta wyjaśni klientowi, a także trochę dokumentacji (spec) + umowa lub coś, co mówi: „Dostaniesz to wszystko, a dokładnie to, nic więcej” pomaga. Wydaje mi się, że podczas opracowywania może istnieć pewna elastyczność, aby zmieniać różne elementy, ale jeśli pojawi się coś, co okaże się więcej pracy, niż się spodziewałeś, uważam, że należy wyciągnąć drwiny i dokumenty techniczne, a dodatkowa praca oznacza również dodatkowe koszty.
DMin

Odpowiedzi:


10

Świetne punkty do dyskusji!

Aby się zakwalifikować - pracuję w BIG projektach internetowych w branży obronnej. Generalnie mamy zespół 10-40 osób wspierających jednego klienta, projekty z ostatnich lat, a klient ma zarówno pieniądze, jak i wysokie wymagania. Tak więc przebieg może się różnić - nie chcesz przesadzać!

1 Kiedy dokładnie wiesz, co zamierzasz zbudować, jakie planowałbyś przed rozpoczęciem kodowania?

To jest po sekcji 15%, na początku 35%, prawda?

  • Wybierz docelowy serwer WWW i język
  • Zdecyduj się na przechowywanie danych - XML, baza danych, która baza danych?
  • Zdecyduj się na główne interfejsy API - trwałość danych, GUI, rejestrowanie, wstrzykiwanie zależności itp.
  • Wybierz mechanizmy logowania - mając na uwadze ryzyko i informacje, które próbujesz chronić. Może zawierać mechanizmy płatności.
  • Zaplanuj architekturę wysokiego poziomu i konwencje nazewnictwa
  • Wybierz kolejność wprowadzania funkcji, abyś dobrze wiedział, od czego zacząć
  • Zdecyduj się na strategię testową i, jeśli ma to zastosowanie, przygotuj strukturę automatycznego testowania
  • Skonfiguruj system CM

2 Z twojego doświadczenia, jakie części całego procesu zrobiłbyś inaczej?

Nie przesadziłbym z planem. Swoje prace związane z planowaniem skoncentrowałem na wykonywaniu zadań - takich jak środowisko kompilacji, serwer, platforma testowa, CM - i poświęcałem tylko niewielką ilość czasu na planowanie architektury, wybieranie narzędzi i podejmowanie decyzji, od czego zacząć. Wydaje mi się, że bez względu na wszystko, amorficzny etap planowania zawsze wymaga dużo więcej czasu na wędrówkę po pustyni bezradności, niż powinien.

Jeśli masz do czynienia ze stałymi opłatami i klientami, którzy nie stawiają wymagań technicznych (takich jak jakiego języka lub interfejsów API używasz), planowałbym w 1 pozycji, która jest technicznie zawsze dla ciebie atrakcyjna. Tylko 1, a resztę pozostaw bez zmian. Myślę, że przy każdym projekcie chcesz poszerzyć swoje umiejętności, ale nie chcesz być tak szalony, że nie pracujesz w niczym, co dobrze znasz lub rozumiesz.


2

Moją największą radą dla ciebie jest bycie bardzo ostrożnym przy ustalaniu ceny za ustaloną cenę. Jeśli nie zrozumiesz dobrze wymagań przed rozpoczęciem pracy, może się zdarzyć jedna z dwóch rzeczy.

  1. Szacunki dotyczące zakresu okazały się być niepełne i tracisz koszulę.
  2. Klient nie zna lub nie może znać całego zakresu, zanim zaczniesz, co spowoduje, że będzie niezadowolony z efektu końcowego.

Dla ciebie numer 2 to lepsza sytuacja, ponieważ jeśli podpiszą się co do zakresu, a następnie zmienią zdanie później, możesz renegocjować więcej pieniędzy. Po prostu upewnij się, że rozumiesz zakres przed oszacowaniem i że oni rozumieją zakres i to, co dostarczysz.

Upewnij się, że podpisali się na lunecie! Firmy, które nalegają na ustalenie ceny i odmawiają wypisania się z zakresu, są ZŁYMI KLIENTAMI i nie chcesz przez to tracić czasu. Zawsze przegrasz.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.