Wycena projektu IT bez specyfikacji to jak wycena remontu mieszkania bez rzutu i listy prac. Możliwa, ale obarczona dużym marginesem błędu. Specyfikacja nie musi być dokumentem na sto stron, ale musi odpowiadać na właściwe pytania.
Co specyfikacja powinna zawierać
- Cel projektu - co ten system ma robić i dla kogo. Nie "portal firmowy", tylko "system do zarządzania zgłoszeniami serwisowymi dla techników w terenie".
- Role użytkowników - kto będzie korzystać z systemu i co każda rola powinna móc robić.
- Wymagania funkcjonalne - lista konkretnych funkcji. Każda funkcja opisana przez co wchodzi, co wychodzi i kto to robi.
- Wymagania niefunkcjonalne - wydajność, bezpieczeństwo, dostępność, integracje z innymi systemami.
- Istniejące systemy - z czym nowy system musi się integrować i przez jakie interfejsy.
User stories zamiast listy funkcji
User story to opis funkcji z perspektywy użytkownika: jako technik w terenie chcę widzieć listę swoich otwartych zgłoszeń, żeby wiedzieć co mam do zrobienia tego dnia. Takie sformułowanie jest łatwiejsze do wyceny niż abstrakcyjna "lista zgłoszeń".
Makiety i wireframy
Nawet szkicowe makiety ekranów pokazują jak wyobrażasz sobie interfejs. Figma, Balsamiq lub nawet odręczne szkice zmniejszają ryzyko nieporozumień. Programista, który widzi makietę, lepiej rozumie zakres pracy i może precyzyjniej oszacować czas.
Czego nie warto opisywać
Technologia implementacji to zazwyczaj decyzja wykonawcy, nie klienta. Określanie technologii bez technicznego uzasadnienia ogranicza wykonawcę i może zwiększać koszt bez powodu. Lepiej opisać wymagania niefunkcjonalne i zostawić dobór technologii specjalistom.
Specyfikacja a zmiany w trakcie projektu
Specyfikacja jest podstawą wyceny, nie umową na wieczność. Zmiany zakresu w trakcie projektu są normalne, ale każda powinna być dokumentowana i wiązać się z aktualizacją harmonogramu. Nagromadzone "małe zmiany" to jedna z głównych przyczyn konfliktów między klientem a wykonawcą.