Τεχνικές προδιαγραφές εκσυγχρονισμού αερισμού στο ερευνητικό ίδρυμα. Τεχνικές προδιαγραφές για τον εκσυγχρονισμό του αερισμού στην ερευνητική εγκατάσταση Τεχνικές προδιαγραφές για την τροποποίηση του διακομιστή αποθήκευσης

Πολλοί άνθρωποι αντιμετωπίζουν το γεγονός ότι είναι αρκετά δύσκολο να εξηγήσουμε σύντομα και ξεκάθαρα τι θέλουμε Καθημερινή ζωή. Και όταν πρέπει να αναθέσετε σε έναν ειδικό να γράψει ένα πρόγραμμα για έναν οργανισμό ή μεμονωμένο επιχειρηματία, λαμβάνοντας υπόψη τα χαρακτηριστικά και τις δικές σας επιθυμίες για λειτουργικότητα, μπορείτε να κολλήσετε εντελώς.


Ποιος πρέπει να γράψει τις τεχνικές προδιαγραφές;


Φυσικά, οι τεχνικές προδιαγραφές πρέπει να παρέχονται από τον πελάτη, αφού σίγουρα γνωρίζει τις ανάγκες και τις δυνατότητές του. Αλλά, όπως δείχνει η πρακτική, η συντριπτική πλειοψηφία των πελατών δεν είναι ικανοί στο 1C. Αυτός είναι ο λόγος για τον οποίο ο ίδιος ο ανάδοχος συχνά αναγκάζεται να εμβαθύνει στις ανάγκες του πελάτη, να καταλάβει ποιο τελικό προϊόν χρειάζεται και, κατά συνέπεια, να τα βάλει όλα αυτά γραπτώς στον προγραμματιστή.


Γιατί χρειάζεται η τεχνική προδιαγραφή;


Σε ιδανική κατάσταση, με τη μία ή την άλλη τροποποίηση προϊόν λογισμικούΤο 1C απαιτεί τεχνικές προδιαγραφές. Πρώτα απ 'όλα, πρέπει να διευκρινιστούν τα καθήκοντα, οι προθεσμίες και ο τρόπος εκτέλεσης.

Αυτό είναι ένα σημαντικό έγγραφο, διότι εάν προκύψουν αμφιλεγόμενα ζητήματα, η αρμόδια ανάπτυξη τεχνικών προδιαγραφών θα αποτελέσει το σημείο εκκίνησης των διαπραγματεύσεων.

Το αν θα συντάξει μια τεχνική προδιαγραφή ή όχι είναι κάτι που αποφασίζει ο καθένας μόνος του, αλλά σίγουρα δεν θα είναι περιττό: θα απλοποιήσει την επικοινωνία με τον πελάτη και θα δώσει στην εργασία έναν επιχειρηματικό και συγκεκριμένο χαρακτήρα.



Ας περιγράψουμε μια λίστα με τα πιο σημαντικά σημεία που πρέπει να περιλαμβάνονται στις τεχνικές προδιαγραφές:

1. Στόχος/Στόχος. Διατυπώστε τι πρέπει να εφαρμοστεί στο τέλος.

2. Περιγραφή. Περιγράψτε συνοπτικά το περιεχόμενο των σχεδιαζόμενων βελτιώσεων.

3. Τρόπος υλοποίησης. Περιγράψτε λεπτομερώς τις μεθόδους με τις οποίες πρέπει να επιτευχθεί ο στόχος. Όλα τα χαρακτηριστικά της εργασίας πρέπει να είναι γραμμένα στη γλώσσα του προγραμματιστή: μητρώα, κατάλογοι (δημιουργήστε τα ή επεξεργαστείτε τα). σχεδιασμός διεπαφής κ.λπ. Για όσους δεν είναι εξοικειωμένοι και έχουν ακούσει μόνο κάτι για μια συγκεκριμένη γλώσσα προγραμματισμού, σας συμβουλεύουμε να μην κάνετε άσκοπες προσπάθειες να «μιλήσετε» σε μια τεχνική γλώσσα. Επειδή μια περιγραφή ιδανικά είναι μια ξερή δήλωση που εξαλείφει την ασάφεια και την πιθανότητα να προκύψουν περιττές ερωτήσεις. Επιπλέον, αυτή η παράγραφος μπορεί να περιλαμβάνει ένα παράδειγμα του τρόπου με τον οποίο παρόμοιος προγραμματισμός έχει ήδη πραγματοποιηθεί κάπου.

4. Αξιολόγηση απόδοσης. Αυτό το σημείο είναι πολύ σημαντικό - πρέπει να περιγράψει το κόστος εργασίας.

Δύο ακόμα σημαντικά σημεία: υπάρχουν εγκεκριμένα πρότυπα για τη σύνταξη τεχνικών προδιαγραφών - GOST. Σήμερα χρησιμοποιούνται σπάνια, αλλά ορισμένοι πελάτες μπορεί να ζητήσουν να τα χρησιμοποιήσουν με τον παλιομοδίτικο τρόπο.

Και δεύτερον, όταν παραδοθεί το έργο, μπορεί να προκύψει κάτι τέτοιο - «αλλά κάπως σας ζητήσαμε να κάνετε αυτό και αυτό και μετά...». Υπάρχει πιθανότητα να πρέπει να αρχίσετε να κάνετε τα πάντα από την αρχή.

Επομένως, επαναλαμβάνουμε ότι μια καλογραμμένη τεχνική προδιαγραφή θα είναι χρήσιμη τόσο για τον πελάτη όσο και για τον ανάδοχο.


Παράδειγμα τεχνικών προδιαγραφών για προγραμματιστή



Τεχνικές προδιαγραφές 1C για οριστικοποίηση εξωτερικής επεξεργασίας


Στόχος
Είναι απαραίτητο να διαμορφώσετε τη μεταφόρτωση δεδομένων από το 1C στον αυτοματοποιημένο χώρο εργασίας της τράπεζας.


Περιγραφή

Σε σχέση με τη μετάβαση του οργανισμού στη διαμόρφωση 1C "Μισθοί και προσωπικό ενός κυβερνητικού ιδρύματος", είναι απαραίτητο να αναπτυχθούν άλλες λύσεις επεξεργασίας που θα παρέχουν παρόμοια λειτουργικότητα στη νέα διαμόρφωση.

Η μεταφόρτωση δεδομένων θα πρέπει να βασίζεται στα έγγραφα «Αίτηση για άνοιγμα Προσωπικών Λογαριασμών Εργαζομένων» και «Δήλωση Καταβολής Μισθών στην Τράπεζα».


Αρχικά στοιχεία

Υπάρχουσα επεξεργασία για τη διαμόρφωση 1C "Μισθός ενός δημοσιονομικού ιδρύματος", η οποία ανεβάζει δεδομένα από το έγγραφο "Αίτηση για άνοιγμα προσωπικών λογαριασμών εργαζομένων" και άλλους καταλόγους και εγγράφεται στο αρχείο DBF για ανταλλαγή δεδομένων με τον αυτοματοποιημένο χώρο εργασίας της τράπεζας του καθιερωμένου προτύπου .

Επεξεργασία μεταφορτώσεων δεδομένων στα πεδία TAB_N, NAME, SERNUM, PASSCODE, PDAT, PWHR, BIRTHDAY, POSTINDEX, COUNTRY, CITY, STREET, REGION, BUILDING, CORP, FLAT, BPLACE, CITIZEN τις αντίστοιχες πληροφορίες από τη διαμόρφωση 1C που εισήχθη προηγουμένως, το καθορισμένο παραστατικό και άλλους λογιστικούς πίνακες. Ανεβαίνουν ο αριθμός προσωπικού, το πλήρες όνομα του υπαλλήλου, τα στοιχεία του διαβατηρίου και της διεύθυνσής του, τα γενέθλια και η υπηκοότητα.


Μέθοδος υλοποίησης

Αυτές θα είναι εξωτερικές αναφορές και επεξεργασία με χρήση του μηχανισμού επέκτασης, εάν οι τρέχουσες παράμετροι συμβατότητας βάσης δεδομένων και οι δυνατότητες της πλατφόρμας το επιτρέπουν. Όταν αλλάζετε τη διαμόρφωση της βάσης δεδομένων, θα πρέπει να δημιουργήσετε: καταλόγους, έγγραφα, μητρώα.


Αξιολόγηση απόδοσης

Π Απαιτούνται 5 εργάσιμες ημέρες εργασίας προγραμματιστή.

Εάν περάσετε από ξένους ιστότοπους με το αίτημα "έγγραφο απαιτήσεων προϊόντος", μπορείτε να βρείτε δημιουργικά και πειστικά άρθρα σχετικά με το γεγονός ότι οι τεχνικές προδιαγραφές (TOR, PRD) είναι νεκρές. Πρέπει να συμφωνήσουμε εν μέρει με αυτό - κατά την ανάπτυξη ενός προϊόντος από την αρχή, η δημιουργία πρωτοτύπων φαίνεται πολύ πιο ενδιαφέρουσα και αποτελεσματική από τους όγκους σημειώσεων πελατών, οι οποίες μερικές φορές είναι πολύ αντιεπαγγελματικές. Ωστόσο, αν μιλάμε για οριστικοποίηση του βασικού συστήματος, τότε τα πράγματα παίρνουν εντελώς διαφορετική τροπή. Είμαστε αντιμέτωποι τόσο με τροποποιήσεις όσο και με προσαρμοσμένη ανάπτυξη, οπότε η τεχνική προδιαγραφή είναι σκύλος-φάγος, αν ο σεφ δεν μας λέει ψέματα. Σε γενικές γραμμές, σήμερα μιλάμε για εκείνες τις κλασικές τεχνικές εργασίες που είναι γραμμένες για την οριστικοποίηση των αγορασμένων και εγκατεστημένων λογισμικό. Εν ολίγοις, για οδυνηρά πράγματα.

Όψεις αλληλεπίδρασης

Πριν αρχίσουμε να αναλύουμε τη διαδικασία δημιουργίας μιας τεχνικής προδιαγραφής, ας μιλήσουμε για το τετράγωνο στο οποίο βρίσκονται ο ανάδοχος και ο πελάτης κατά την έναρξη του έργου.


Απαιτήσεις- την επιθυμητή συμπεριφορά του συστήματος, που περιγράφεται από τον πελάτη ή τον κάτοχο της διαδικασίας, προς υλοποίηση. Κατά κανόνα, οι απαιτήσεις διαμορφώνονται με βάση την εργασιακή εμπειρία και την κατανόηση της σωστής συμπεριφοράς του προγράμματος. Αυτές είναι βασικές πληροφορίες για τον προγραμματιστή (προμηθευτή), ωστόσο, είναι στο στάδιο της συλλογής απαιτήσεων που προκύπτει ο μεγαλύτερος αριθμός συγκρούσεων, σφαλμάτων, περιττών αιτημάτων κ.λπ.

Πόροι- άνθρωποι, μηχανές, εξοπλισμός, περιβάλλον ανάπτυξης, χρόνος και χρήμα που πρέπει να χρησιμοποιηθούν στη διαδικασία υλοποίησης των απαιτήσεων. Οι πόροι απαιτούν σαφή σχεδιασμό και αξιολόγηση στο στάδιο της έγκρισης των τεχνικών προδιαγραφών. Η σωστή ιεράρχηση των προτεραιοτήτων από την πλευρά του πελάτη και η κατανομή των πόρων εργασίας από την πλευρά του πωλητή επιτρέπει σε κάποιον να αποφύγει τις χαμένες προθεσμίες και να ελαχιστοποιήσει άλλους κινδύνους.

Δυνατότητες- εν ολίγοις, αυτό μπορεί πραγματικά να κάνει ο πωλητής (εκτελεστής). Ας δούμε το παράδειγμα του RegionSoft CRM μας. Ο πελάτης αγοράζει το σύστημα και συντάσσει μια τεχνική προδιαγραφή για τροποποίηση: είναι απαραίτητο να δημιουργηθεί ενοποίηση με τον ιστότοπο και να συνδεθούν συμβάντα στο CRM με τον αριθμό παραγγελίας του ηλεκτρονικού καταστήματος. Αυτή είναι μια ρεαλιστική απαίτηση, έχουμε τους πόρους και την ικανότητα να το κάνουμε. Πρέπει επίσης να αναπτύξετε και να επισυνάψετε ένα CMS, ένα σύστημα διαχείρισης περιεχομένου ιστότοπου, στο CRM. Θεωρητικά, μπορούμε να το κάνουμε αυτό, αλλά δεν έχουμε την ευκαιρία να το κάνουμε φθηνά και ο πελάτης δεν έχει τη δυνατότητα να μας πληρώσει αρκετά ώστε να διαθέσουμε ανθρώπινους και χρόνους πόρους για την εργασία. Ως αποτέλεσμα, ο πελάτης αρνείται αυτήν την απαίτηση - και δεν χρειάζεται πραγματικά ένα CMS, όλα είναι καλά. Αλλά για την «απληστία» του ΤΚ αργότερα.

Περιορισμοί- ένα σύνολο εμποδίων που καθιστούν δύσκολη ή αδύνατη την εκτέλεση εργασιών από τις τεχνικές προδιαγραφές: προϋπολογισμός, στοίβα τεχνολογίας, προβλήματα αδειοδότησης, νομοθετικές απαγορεύσεις, διαμορφώσεις υλικού κ.λπ.

Έτσι, και οι τέσσερις ουσίες είναι στενά αλληλένδετες και καθορίζουν την επιτυχία του έργου στο σύνολό του. Ας δούμε κάθε στοιχείο και ας προσπαθήσουμε να επισημάνουμε τα κρίσιμα σημεία που πρέπει να ληφθούν υπόψη κατά την επεξεργασία των τεχνικών προδιαγραφών.

Συλλογή και ανάλυση απαιτήσεων

Αυτή είναι μια πολύ σημαντική εσωτερική εταιρική διαδικασία, κατά την οποία γίνεται σαφές τι θέλουν οι πιθανοί χρήστες από το πρόγραμμα (εφεξής θα λάβουμε το CRM, αλλά οι μέθοδοι λειτουργούν και με άλλους τύπους λογισμικού). Εάν επικοινωνήσετε με έναν μεγάλο προμηθευτή όπως η SAP ή έναν ενοποιητή συστήματος, τότε με μεγάλη πιθανότητα θα σας προσφερθεί να χρησιμοποιήσετε τις υπηρεσίες ενός συμβούλου επιχειρήσεων (γνωστός και ως personal manager, γνωστός και ως διαχειριστής λογαριασμού, γνωστός και ως "τώρα ο αντιπρόσωπός σας στο Εταιρία"). Στην πραγματικότητα, στις περισσότερες περιπτώσεις, αυτός είναι ένας συνηθισμένος καλά εκπαιδευμένος πωλητής που έχει δύο καθήκοντα: να αυξήσει το κόστος του έργου και να μην σας αφήσει να κολλήσετε.


Είναι εδώ μια ώρα και δεν έχει αγγίξει ούτε τον λευκό πίνακα. Δεν είναι πραγματικός αναλυτής συστημάτων

Κανείς δεν γνωρίζει την εταιρεία σας καλύτερα από εσάς και τους υπαλλήλους σας. Αυτό σημαίνει ότι η συλλογή και η ανάλυση απαιτήσεων είναι αποκλειστικά δική σας δουλειά, στην οποία ο πωλητής μπορεί να βοηθήσει και να καθοδηγήσει, αλλά σε καμία περίπτωση να μην παρέμβει στη διαδικασία. Ρωτήστε τον προγραμματιστή για τέτοιες υλοποιήσεις, μάθετε τι να αναζητήσετε και ξεκινήστε. Παρεμπιπτόντως, ένας καλός βοηθός μπορεί να είναι ο υπάλληλος σας που γνωρίζει καλά το εξειδικευμένο θέμα και έχει μια πρόχειρη ιδέα για την αρχιτεκτονική του λογισμικού και είναι εξοικειωμένος με τη διαδικασία ανάπτυξης - μπορεί να ενεργεί ως αναλυτής και εσωτερικός ειδικός, επιβλέποντας το διαδικασία δημιουργίας τεχνικών προδιαγραφών και επικοινωνίας με τον πωλητή.

Υπάρχουν πολύ απλό κύκλωμασυλλογή απαιτήσεων.

  1. Δημιουργήστε μια ομάδα εργασίας από διευθυντές και έμπειρους ειδικούς από τμήματα που θα χρησιμοποιούν το CRM. Πείτε μας για τη λύση που σκοπεύετε να επιλέξετε, παρέχετε πρόσβαση στην έκδοση επίδειξης.
  2. Τα μέλη της ομάδας εργασίας θα πρέπει να μεταφέρουν πληροφορίες στους εργαζόμενους και να ζητούν τις προτάσεις τους νέο πρόγραμμασε εντελώς ελεύθερη μορφή. Εάν κάποιος από τους υπαλλήλους δεν έχει συναντήσει ποτέ τέτοιο λογισμικό και δεν είναι έτοιμος να μιλήσει για μελλοντική χρήση, πρέπει να του ζητήσετε να περιγράψει τις περιοδικές εργασίες του· αυτή είναι μια καθολική προσέγγιση.
  3. Στη συνέχεια, κάθε τμήμα προσδιορίζει τι δεν διαθέτει ή δεν μετράει το CRM και συγκεντρώνει τις πληροφορίες.
  4. Η ομάδα εργασίας αναλύει τις συλλεγόμενες απαιτήσεις, ελέγχει και εξαλείφει τις διασταυρώσεις. Για παράδειγμα, συχνά το τμήμα πωλήσεων και το τμήμα μάρκετινγκ παραγγέλνουν την ίδια αναφορά, αλλά οι απαιτήσεις μπορεί να έχουν διαφορετικά ονόματα για πεδία και οντότητες, αν και τα δεδομένα πίσω από αυτά είναι τα ίδια. Κατά συνέπεια, πρέπει να φτάσουμε σε μια ενιαία μορφή.
  5. Η ομάδα εργασίας δημιουργεί μια λίστα απαιτήσεων και θέτει προτεραιότητες. Σε αυτό το στάδιο, μπορείτε να εμπλέξετε τον πωλητή, καθώς αυτός είναι υπεύθυνος για τους πόρους. Για παράδειγμα, μπορείτε να ζητήσετε να δημιουργήσετε μια προσαρμοσμένη αναφορά για το RegionSoft CRM ή μπορείτε να παραγγείλετε ενοποίηση με τον ιστότοπο. Πρόκειται για εργασίες με τελείως διαφορετικές προθεσμίες· εδώ η προτεραιότητα είναι πολύ σημαντική.
Αφού συγκεντρωθούν, αναλυθούν και συμφωνηθούν οι απαιτήσεις με τους υπαλλήλους και τη διοίκηση, μπορείτε να αρχίσετε να δημιουργείτε μια τεχνική προδιαγραφή. Μπορείτε να ζητήσετε από τον πωλητή τη φόρμα ή να τη δημιουργήσετε μόνοι σας - σε κάθε περίπτωση, υπάρχουν αρκετοί σιδερένιοι κανόνες, η τήρηση των οποίων θα γλιτώσει από πονοκεφάλους εσάς και τον προμηθευτή σας CRM.

Ανατομία τεχνικής προδιαγραφής

Αν μιλάμε για τη διαδικασία δημιουργίας μιας τεχνικής προδιαγραφής, υπάρχουν πολλά στάδια. Το διαδοχικό πέρασμά τους οδηγεί τον πελάτη στην επιθυμητή βελτίωση. Εδώ είναι.

  • Εντοπισμός - καθορισμός απαιτήσεων, εύρεση προβλημάτων που πρέπει να επιλυθούν.
  • Ανάλυση - ανάλυση απαιτήσεων, εντοπισμός βασικών αναγκών, γενίκευση.
  • Προσαρμογή - αξιολόγηση απαιτήσεων στο πλαίσιο των δυνατοτήτων CRM και των υφιστάμενων επιχειρηματικών διαδικασιών.
  • Τεκμηρίωση - επίσημη και Λεπτομερής περιγραφήαπαιτήσεις, έγκριση τεχνικών προδιαγραφών.
  • Επικοινωνία με τον προμηθευτή (προγραμματιστή) - επαναληπτική αλληλεπίδραση με τον προμηθευτή σχετικά με βελτιώσεις σύμφωνα με τις καταρτισμένες τεχνικές προδιαγραφές.
  • Η υλοποίηση είναι δουλειά του πωλητή για τη δημιουργία της απαραίτητης λειτουργικότητας. Είναι καλύτερα εάν ο πωλητής είναι συνεχώς σε επαφή με τον πελάτη - με αυτόν τον τρόπο το τελικό προϊόν θα αντιστοιχεί περισσότερο στο όραμα του πελάτη.
  • Δοκιμή - έλεγχος της λειτουργικότητας από τους υπαλλήλους του πωλητή, τους εσωτερικούς ειδικούς του πελάτη και τους τελικούς χρήστες προκειμένου να διαπιστωθεί η συμμόρφωση με τις τροποποιήσεις και τις τεχνικές προδιαγραφές και η λειτουργικότητα του συστήματος με τις αλλαγές.
Γενικά, μια τεχνική προδιαγραφή μπορεί να δημιουργηθεί με βάση τις απαιτήσεις πολλών επιπέδων, τα οποία μπορεί να τέμνονται και να συνεργάζονται στη δημιουργία του έργου ή να μην αλληλεπιδρούν καθόλου.

Επιχειρηματικό επίπεδο- το πιο παγκόσμιο επίπεδο στο οποίο επιλύονται σύνθετες εργασίες και εργασίες προτεραιότητας. Αυτό το επίπεδο περιλαμβάνει ενοποίηση, βελτιώσεις και μοντελοποίηση επιχειρηματικών διαδικασιών, ανάπτυξη νέων λειτουργικών ενοτήτων. Κατά κανόνα, πρόκειται για μια ανάπτυξη έντασης πόρων, με σοβαρές διαβουλεύσεις και κλείσιμο Δουλεύοντας μαζίμε τον πελάτη. Για παράδειγμα, κάποτε στο RegionSoft CRM τέτοιες προσαρμοσμένες τροποποιήσεις ήταν η λογιστική αποθήκης, η ταμειακή μηχανή και η παραγωγή. Σταδιακά, οι αλλαγές συμπεριλήφθηκαν στην κυκλοφορία και αργότερα κατέστησαν δυνατή τη δημιουργία ενός νέου προϊόντος για καταστήματα χονδρικής, λιανικής και υπεραγορές - RegionSoft Retail.

Επίπεδο χρήστη ή ομάδας χρηστών.Σε αυτό το επίπεδο, υλοποιούνται εργασίες για τη βελτίωση της υπάρχουσας διεπαφής. Για παράδειγμα, ένας χρήστης μπορεί να θέλει ένα παράθυρο με τον αριθμό και την κατάσταση της τελευταίας παραγγελίας να εμφανίζεται όταν τοποθετείται το δείκτη του ποντικιού πάνω από έναν πελάτη ή μια προσαρμοσμένη αναφορά με μια ειδική ομαδοποίηση δεδομένων. Οι βελτιώσεις σε αυτό το επίπεδο απαιτούν λιγότερο χρόνο, αλλά μπορεί να υπάρχουν πολλές από αυτές - για παράδειγμα, αρκετές απαιτήσεις από το μάρκετινγκ, τα logistics και τεχνική υποστήριξη.

Επίπεδο λειτουργικότητας.Συχνά είναι δύσκολο να το διαχωριστεί από το προηγούμενο· εδώ λειτουργεί ένα επίσημο κριτήριο - η βελτίωση δεν είναι στο επίπεδο της εμφάνισης κάτι στη διεπαφή, αλλά στο επίπεδο της οριστικοποίησης της λογικής του συστήματος. Αυτό μπορεί να περιλαμβάνει απαιτήσεις για διάφορα είδη ικανοτήτων ταξινόμησης, ενοποίησης συνομιλίας και τηλεφωνίας.

Επίπεδο εξυπηρέτησης- στην πραγματικότητα, οι απαιτήσεις αυτού του επιπέδου θα πρέπει να είναι οι πρώτες που θα συμπεριληφθούν σε νέες εκδόσεις με διορθώσεις. Αυτές είναι εργασίες που σχετίζονται με την ταχύτητα απόκρισης του συστήματος, τη λειτουργία υπό υψηλό φορτίο και την ασφάλεια. ΣΕ ιδανικόΟ προμηθευτής δεν πρέπει να έχει τέτοιες τροποποιήσεις - το εταιρικό λογισμικό δεν πρέπει να επιβραδύνει, να χάνει δεδομένα, να συμπτύσσει φόρμες και να διανέμει δικαιώματα πρόσβασης του ίδιου επιπέδου. Αλλά εάν εμφανιστεί μια απαίτηση και δεν σχετίζεται με την προσωπική παράνοια του πελάτη ή τα προβλήματα στο πλάι σκεύη, εξαρτήματα, αξίζει να του δώσετε ιδιαίτερη προσοχή.

Επίπεδο τεχνολογίας- τελευταίο στη λίστα, αλλά μπροστά από τους υπόλοιπους σε σημασία και πολυπλοκότητα. Αυτές θα μπορούσαν να είναι απαιτήσεις πελατών που σχετίζονται με την πλατφόρμα, λειτουργικό σύστημαή συσκευές. Για παράδειγμα, ένα αίτημα για δημιουργία για MacOS. Θα είναι υπέροχο εάν τέτοιες απαιτήσεις εξελιχθούν σταδιακά σε εκδόσεις, αλλά είναι επιτακτική ανάγκη να υπάρχουν διορθώσεις για αυτές. Από αιτήματα πελατών σε αυτό το επίπεδο δημιουργήσαμε το RegionSoft CRM για MacOS και προσθέσαμε απομακρυσμένη πρόσβασηχρησιμοποιώντας την τεχνολογία TRM ως προσωρινή λύση σε ένα σπάνιο αλλά υπάρχον αίτημα για έκδοση για φορητές συσκευές.

Η ανατομία μιας τεχνικής προδιαγραφής είναι απλή, τουλάχιστον σε σκελετική μορφή. Υποχρεωτικά μέρη της τεχνικής προδιαγραφής βοηθούν τον πελάτη να εστιάσει στο πρόβλημα και να διατυπώσει σωστά την εργασία και τον ανάδοχο να καταλάβει τι θέλει από αυτόν. Παρεμπιπτόντως, για την κατανόηση. Φυσικά, στην αρχή της ανάρτησης είπαμε λίγο ψέματα, αρνούμενοι τους συμβούλους επιχειρήσεων ως τάξη. Το θέμα είναι το εξής: κάθε προμηθευτής εργάζεται στην αγορά για αρκετά χρόνια (δεν μιλάμε για CRM μιας ημέρας), ή ακόμα και δεκαετίες, πράγμα που σημαίνει ότι έχει ένα σύνολο υποθέσεων σχεδόν σε κάθε κλάδο. Αντίστοιχα, οι μηχανικοί, οι προγραμματιστές και οι πωλητές είναι εξοικειωμένοι με τις ιδιαιτερότητες της εφαρμογής σε κάθε τύπο εταιρείας. Αλλά και πάλι, είναι σημαντικό να εστιάσετε συγκεκριμένα στην επιχείρησή σας.

Για ποιόν?Σε αυτήν την ενότητα, πρέπει να περιγράψετε ποιος θα είναι ο τελικός χρήστης της βελτίωσης, ποιες εργασίες σχεδιάζεται να επιλυθούν και με ποια συχνότητα.

Επιτρέψτε μου να σας δώσω ένα παράδειγμα. Μια εταιρεία εφάρμοζε CRM και υποτίθεται ότι εργαζόταν σε μια αρκετά μεγάλη σειρά δεδομένων (αρκετές δεκάδες εκατομμύρια εγγραφές το μήνα, αρκετές εκατοντάδες χιλιάδες εγγραφές την ημέρα). Ο επικεφαλής του τμήματος πωλήσεων ζήτησε μια αναφορά σχετικά με τη μεταφόρτωση αυτών των αρχείων σε «καθημερινή» συχνότητα. Όπως ήταν φυσικό, μια τέτοια αναφορά, με εκατοντάδες χρήστες να εργάζονται ταυτόχρονα, φόρτωσε το σύστημα - βρέθηκαν λύσεις για τη βελτιστοποίηση της διαδικασίας. Ήδη κατά τη διάρκεια της εργασίας, αποδείχθηκε ότι ο πωλητής το είχε παίξει με ασφάλεια και χρειαζόταν την αναφορά μόνο στο τέλος του μήνα και στη συνέχεια θα μπορούσε να εκτελεστεί σύμφωνα με ένα πρόγραμμα τη νύχτα. Περιττό να πούμε ότι χάθηκαν χρόνο και χρήμα.

Για τι?Αιτιολόγηση της ανάγκης βελτίωσης και της θέσης της στην επιχειρηματική διαδικασία. Αυτό το σημείο είναι πιο απαραίτητο για τον ίδιο τον πελάτη, αλλά είναι επίσης χρήσιμο για τον πωλητή να γνωρίζει ποιες άλλες διαδικασίες θα επηρεαστούν. Μερικές φορές αυτό βοηθά να βρεθεί μια εναλλακτική λύση.

Τι πρέπει να κάνει;Το πιο ενημερωτικό μπλοκ - περιγράφει τις απαιτήσεις και τις προσδοκίες από το σύστημα. Και εδώ συμβαίνουν τα ίδια τα μαργαριτάρια, τα θαύματα και οι συγκρούσεις που είναι σωστό να σταλούν στο bashorg, και που, λοιπόν, κάνουν τη ζωή πολύ δύσκολη. Υπάρχει μόνο ένας λόγος - ο χρήστης δεν ξέρει τι θέλει, τι πρέπει να γίνει. Υπάρχει ένας άλλος μικρός δευτερεύων λόγος - ο χρήστης δεν μπορεί να διατυπώσει απαιτήσεις. Και εδώ, το καθήκον του προγραμματιστή (ομάδα εργασίας, αναλυτής, εάν υπάρχει) είναι να βοηθήσει στη σωστή διατύπωση της ανάγκης, να επιλέξει μια κατάλληλη απαίτηση και να προσαρμόσει την εργασία στο πλαίσιο λειτουργίας του συστήματος. Στο ίδιο μπλοκ πρέπει να αναφέρετε το αναμενόμενο αποτέλεσμα.

Παράμετροι προδιαγραφών- προθεσμίες, στάδια υλοποίησης, ευθύνη από όλα τα μέρη, απαραίτητες επαφές κ.λπ. Στην πραγματικότητα, αυτό είναι ένα σύνολο σημαντικών τυπικών πραγμάτων που καθιστούν το έγγραφο τεχνική προδιαγραφή. Οι όροι αναφοράς πρέπει να συμφωνηθούν και να υπογραφούν από τα μέρη προκειμένου να αποφευχθούν πολυάριθμες αλλαγές κατά την ανάπτυξη (θα συνεχίσουν να συμβαίνουν, αλλά σε μικρότερο βαθμό).

Ιδανικά, η τεχνική προδιαγραφή συντάσσεται με την ενεργή συμμετοχή του πωλητή και το αποτέλεσμά της είναι περίπου η ακόλουθη δομή:
  1. Περιγραφή της απαίτησης κάθε μηχανισμού και κάθε λειτουργικότητας
  2. Περιγραφή της υλοποίησης αυτής της λειτουργικότητας
  3. Κόστος εργασίας για κάθε στάδιο ξεχωριστά
  4. Το συνολικό κόστος εργασίας για αυτήν την τεχνική προδιαγραφή
  5. Χρονικά πλαίσια για την ολοκλήρωση των εργασιών, κατανεμημένα κατά στάδια και ένδειξη προτεραιότητας
  6. Περιγραφή των συνθηκών εγκατάστασης και δοκιμή τροποποιήσεων
  7. Επιφυλάξεις σχετικά με τον εξαντλητικό χαρακτήρα των όρων αναφοράς και άλλες προϋποθέσεις

10 κανόνες γραμμένοι στα δάκρυα ενός προγραμματιστή

Οι όροι αναφοράς για την αναθεώρηση πρέπει να είναι οι τεχνικές προδιαγραφές για την αναθεώρηση, και όχι μια περιγραφή 300 σελίδων του CRM που χρειάζεται ο πελάτης. Πριν συντάξετε τις απαιτήσεις, θα πρέπει να εξοικειωθείτε προσεκτικά με τη διεπαφή συστήματος, τις δυνατότητές της και την τεκμηρίωση - πιθανότατα, τα περισσότερα από τα «θέλω» περιλαμβάνονται ήδη στο βασικό πακέτο. Το δεύτερο βήμα που θα συνιστούσα είναι να δώσετε προσοχή στα ενσωματωμένα εργαλεία τροποποίησης (σχεδιαστές αναφορών, διαμορφωτές κ.λπ.) - ίσως ένας προγραμματιστής πλήρους απασχόλησης μπορεί να κάνει τις απαραίτητες αλλαγές (πολλές εταιρείες τις έχουν).

Οι τεχνικές προδιαγραφές δεν πρέπει να είναι άπληστες.Συχνά μια επιχείρηση υπερεκτιμά τις δυνατότητές της ή θέλει να πάρει «τα πάντα ταυτόχρονα». Αυτή η προσέγγιση δεν δικαιολογείται ούτε από οικονομική ούτε από επιχειρηματική άποψη. Ένας προμηθευτής, κατά κανόνα, δεν υπάρχει εδώ και μερικές εβδομάδες (στην περίπτωση του RegionSoft - 15 χρόνια) και μπορείτε να επικοινωνήσετε μαζί του μετά από κάποιο χρονικό διάστημα, όταν καταλάβετε πραγματικά τι λείπει στο CRM.

Ένα εντυπωσιακό παράδειγμα πλεονασμού κυριολεκτικά από χθες: ένας πελάτης αγόρασε ένα ERP από έναν γνωστό Ρωσική εταιρεία, πιστεύοντας ότι αφού η λογιστική λειτουργεί, τότε το ERP αυτού του προμηθευτή θα είναι καλό. Το ERP αποδείχθηκε όχι μόνο όχι πολύ καλό από μόνο του, αλλά και πολύ ακατάλληλο για την επιχείρηση. Αλλά το RegionSoft CRM με λογιστική αποθήκηςκαι κατάλληλο για παραγωγή. Υπάρχει μια λύση: ξεχάστε το ERP, κλάψτε, ενσωματώστε τη λογιστική 1C με το νέο CRM και απολαύστε την βολική εφαρμογή. Αλλά είναι κρίμα για τα πεταμένα λεφτά! Και ο πελάτης απαιτεί την ενσωμάτωση του CRM με το ERP. Δεν το κάναμε αυτό, αλλά γιατί τόση σπατάλη, γιατί δύο σχετικά παρόμοια συστήματα;

Οι όροι αναφοράς πρέπει να είναι ρεαλιστικοί και εφικτός- τόσο όσον αφορά τις απαιτήσεις όσο και τις προθεσμίες. Εδώ είναι σημαντικό να ακούσετε τη γνώμη του πωλητή, καθώς ξέρει ακριβώς πόσος χρόνος θα δαπανηθεί για αυτό ή εκείνο το έργο. Πιστέψτε με, δεν είναι ωφέλιμο για έναν προγραμματιστή να χάνει χρόνο και να αυξάνει τις προθεσμίες - είναι ωφέλιμο για αυτόν να ολοκληρώσει όσο το δυνατόν περισσότερα έργα και να το κάνει καλά, για να μην υποστεί πλήγμα στη φήμη του. Όσον αφορά τον ρεαλισμό, είναι εύκολο να αποφύγετε αιτήματα για αναβάθμιση του CRM στο επίπεδο ενός συστήματος διαχείρισης επιπτώσεων: θα πρέπει να συμπεριλάβετε στις απαιτήσεις αυτό που πραγματικά χρειάζεται για αυτή τη στιγμήκαι στο άμεσο μέλλον.

Για παράδειγμα, το RegionSoft CRM είναι ένα πρόγραμμα επιτραπέζιου υπολογιστή, δεν έχουμε πρόγραμμα-πελάτη προγράμματος περιήγησης. Το να μας ζητάμε να δημιουργήσουμε μια διαδικτυακή εφαρμογή για μια εταιρεία είναι άσκοπο, πρόκειται για μια σημαντική εξέλιξη, βρίσκεται σε εξέλιξη και δεν είναι πιθανή ανάπτυξη για μία εταιρεία. Όχι, φυσικά, όλα έχουν το τίμημά τους, αλλά και πάλι - στη γενική περίπτωση, η απαίτηση είναι αδύνατο να εκπληρωθεί.

Αυτό δεν πρέπει να συγχέεται με την κατάσταση όταν μιλάμε για προσαρμοσμένη ανάπτυξη και η ιδέα και η λογική της εφαρμογής έχει αλλάξει ριζικά· στην πραγματικότητα, χορηγείται η δημιουργία νέου λογισμικού «για τον εαυτό σας». Αλλά αυτό είναι μια άλλη ιστορία.

Οι όροι αναφοράς πρέπει να είναι λεπτομερείς.Είναι απαραίτητο να αναφερθούν όλες οι σημαντικές λεπτομέρειες του μελλοντικού έργου: από τη συχνότητα χρήσης του προγράμματος έως τις επιθυμίες για τη διεπαφή. Όσο πιο λεπτομερείς είναι οι απαιτήσεις, τόσο πιο εύκολη και γρήγορη θα είναι η υλοποίηση και η δοκιμή. Αξίζει ιδιαίτερα να δώσετε προσοχή στη λεπτομέρεια εάν εργάζεστε σε έναν συγκεκριμένο κλάδο (ιατρική, ασφάλιση, τράπεζες) - μια λεπτομερής παρουσίαση των αποχρώσεων της αλληλεπίδρασης μεταξύ της επιχείρησης και του προγράμματος θα διασφαλίσει ότι ο πωλητής κατανοεί την εργασία και προσαρμόζει γρήγορα το σύστημα σε η εταιρεία σας.

Φροντίστε να δώσετε προσοχή στις μορφές αριθμών, τα ονόματα πεδίων, την παρουσία ή την απουσία αναπτυσσόμενων λιστών, τη συμπεριφορά των κουμπιών και των υποδείξεων και τους τύπους δεδομένων. Εάν ο πελάτης χρησιμοποιεί τους δικούς του τύπους, οι οποίοι πρέπει να περιλαμβάνονται στη λογική της λειτουργίας του CRM ( για παράδειγμα, υπολογισμός μπόνους αντιπροσώπου), αυτοί οι τύποι πρέπει να γράφονται με πλήρη επεξήγηση των ονομασιών και της λογικής υπολογισμού τους.


Ναι, το εταιρικό λογισμικό μοιάζει κάπως έτσι και υπάρχουν πολλές σημαντικές λεπτομέρειες σε αυτό

Οι τεχνικές προδιαγραφές πρέπει να είναι σαφείς και ακριβείς.Αόριστες διατυπώσεις, επιλογές υλοποίησης, ασαφείς απαιτήσεις - όλα αυτά είναι μια πορεία προς ένα αδιέξοδο. Συμβαίνει ένας πελάτης, από καλή πρόθεση, να γράφει στην τεχνική προδιαγραφή αρκετές επιλογές για τη συμπεριφορά του συστήματος, κλειστές αλλά όχι ισοδύναμες. Σε αυτή την περίπτωση, είναι σίγουρος ότι βοηθάει, προτρέποντας τον προγραμματιστή, αλλά στην πραγματικότητα, ο δρόμος προς την κόλαση είναι στρωμένος με καλές προθέσεις, ο προγραμματιστής πρέπει να καταλάβει τι ακριβώς χρειάζεται και θα επιλέξει πώς να το κάνει μόνος του, με βάση σχετικά με τα χαρακτηριστικά του συστήματος και τη στοίβα των χρησιμοποιούμενων τεχνολογιών.


Φέτος μπορείς να κάνεις ξανά μια ευχή. Απλώς μην το ξοδεύετε σε κάτι που ούτε εγώ δεν μπορώ να εκπληρώσω, όπως σαφείς επιχειρηματικές απαιτήσεις!

Οι τεχνικές προδιαγραφές πρέπει να είναι γραμμένες σε ανθρώπινη γλώσσα.Και αυτό είναι σημαντικό, όχι, ΣΗΜΑΝΤΙΚΟ. Θα επισημάνω δύο περιπτώσεις όπου τα γλωσσικά προβλήματα οδηγούν σε καθυστερήσεις στην υλοποίηση του έργου.

  1. Ο πελάτης προσπαθεί να επιδείξει τον τεχνικό του γραμματισμό και φτιάχνει κατασκευές όπως: «εφαρμόστε ένα παράθυρο με μια υπόδειξη στο σώμα του ημερολογίου με την ικανότητα να αντιδρά σε συμβάντα κλήσης...» αντί για «θα πρέπει να εμφανιστεί ένα παράθυρο στο ημερολόγιο στο οποίο μπορείτε να επισημάνετε την εργασία ως ολοκληρωμένη." Εάν εσείς ή ο εσωτερικός σας ειδικός δεν έχετε τις δεξιότητες να γράφετε τεχνικά κείμενα, μην κάνετε Google - γράφετε με συνηθισμένες λέξεις, τους καταλαβαίνουμε.

    Οι όροι αναφοράς δεν πρέπει να αποτελούν βιβλίο παραπόνων.Πρέπει να λύσετε το πρόβλημα, όχι να το περιγράψετε, δίνοντας προσοχή στις γραμματοσειρές και ξεχνώντας να περιγράψετε τις απαιτήσεις. Η τεχνική προδιαγραφή πρέπει να περιέχει όχι μόνο το ίδιο το πρόβλημα, αλλά και τη λύση του σε επίπεδο κατανόησης - τότε ο προγραμματιστής θα το λύσει σε επίπεδο κώδικα. Συγκρίνω «Το τμήμα πωλήσεων δεν σχεδιάζει καλά, χάνει νούμερα, παλεύουμε εδώ και ένα χρόνο»Και «Είναι απαραίτητο να δημιουργηθεί μια αναφορά που θα αποθηκεύει τις αξίες των προγραμματισμένων και πραγματικών πωλήσεων μηνιαίως, κατανεμημένες ανά ομάδες προϊόντων».

    Οι όροι αναφοράς πρέπει να μπορούν να κοιτάζουν στο μέλλον.Λοιπόν, όχι ακριβώς αυτό, αλλά οι άνθρωποι πίσω από αυτό. Εάν είναι γνωστό ότι σύντομα θα υπάρξουν αλλαγές στις επιχειρηματικές διαδικασίες, αυτό πρέπει να ληφθεί υπόψη για να μην πληρωθούν δύο φορές για τροποποιήσεις.

    Οι όροι αναφοράς δεν πρέπει να είναι γραφειοκρατικοί.Εάν έχετε συντάξει ποτέ αυτό το έγγραφο, πιθανώς νιώσατε πόσο δύσκολο είναι να αποφύγετε τον πειρασμό να γλιστρήσετε στη γραφειοκρατία, να προσθέσετε εισαγωγικές λέξεις, αυστηρές φράσεις και να περιγράψετε κάθε σημείο ως άρθρο του Ποινικού Κώδικα (κατά προτίμηση με τιμωρία για όλους για παράβαση ). Οι γραφειοκρατικές διατυπώσεις συγκαλύπτουν μια ελλιπή κατανόηση των σκοπών δημιουργίας τεχνικών προδιαγραφών. Η ευθύνη του πωλητή καθορίζεται στη σύμβαση και ο προϋπολογισμός αναγράφεται επίσης εκεί. Δεν πρέπει να μεταφέρετε αυτά τα σημεία στις τεχνικές προδιαγραφές.

    Οι όροι αναφοράς πρέπει να είναι τεχνικές προδιαγραφές.Ακούγεται παράδοξο, αλλά συχνά αντί για τεχνικές προδιαγραφές διαβάζουμε επιστολές, παράπονα, συμβόλαια, νέες οδηγίες για CRM ή πρακτικά μιας συνάντησης. Φυσικά, είναι αδύνατο να εργαστεί κανείς σύμφωνα με ένα τέτοιο έγγραφο. Για να παραμείνετε στην κορυφή της μορφής και του περιεχομένου, χρησιμοποιήστε ένα παλιό κόλπο: δείτε τον όρο λέξη προς λέξη. Τεχνικό σημαίνει ότι υπαγορεύει τροποποίηση, τεχνολογία και στοχεύει στην επίλυση ενός προβλήματος με την αλλαγή του λογισμικού. Αυτό είναι που πρέπει να μιλήσουμε στο πλαίσιο του λογισμικού. Μια εργασία σημαίνει να θέτεις μια ερώτηση, ένα πρόβλημα, χωρίς συμβουλές, συμβουλές ή προκαταρκτικές αξιολογήσεις. Απλά μια δήλωση του προβλήματος.

    Τελείωσαν οι εντολές, τώρα η επίπληξη

    Εκτός από τους αναφερόμενους κανόνες, υπάρχουν μερικά ακόμη πράγματα για τα οποία αξίζει να μιλήσουμε. Μιλάμε για στόχους, σχέδια και προσδοκίες - όλα εκείνα τα στοιχεία που κάνουν το έργο επιτυχημένο και τη σχέση μεταξύ πωλητή και πελάτη σχεδόν φιλική.

    Οι τεχνικές προδιαγραφές πρέπει να γραφτούν γρήγορα, ακόμα κι αν αντιμετωπίζετε το καθήκον της αυτοματοποίησης των διαδικασιών φορέας κινητής τηλεφωνίαςή μια μεγάλη υπεραγορά. Αυτό οφείλεται στο γεγονός ότι οι τεχνολογίες αναπτύσσονται με τεράστια ταχύτητα και ακόμη και το σύστημα που εφαρμόζετε μπορεί να επιβιώσει από μια σημαντική έκδοση (ή μερικές φορές δύο) σε έξι μήνες ή ένα χρόνο και να λάβει νέα λειτουργικότητα. Ίσως χρειαστεί να επανεξετάσετε την ανάγκη για τροποποιήσεις και να ξεκινήσετε ξανά τη διαδικασία.


    Τελικά βρήκε τον χρόνο να ολοκληρώσει την τεχνική εργασία. Αλλά, δυστυχώς, δεν υπάρχουν προγραμματιστές που να το εφαρμόσουν.

    Ο πελάτης δεν γνωρίζει τη στοίβα και τους τεχνικούς περιορισμούς.Και δεν πρέπει να ξέρει - αυτό είναι το καθήκον του πωλητή, είναι αυτός που αξιολογεί την εργασία μετά την κατάρτιση των τεχνικών προδιαγραφών. Ο πελάτης δεν πρέπει να εμβαθύνει στην τεχνολογία και να ρωτά σε κάθε κόμμα εάν ο πωλητής μπορεί να κάνει αυτό ή εκείνο το πράγμα. Συντάξτε μια ολοκληρωμένη τεχνική προδιαγραφή και ο προγραμματιστής θα επιλέξει μια κατάλληλη αρχιτεκτονική - συχνά ακόμη καλύτερη από ό, τι νομίζετε.

    Αξιολογήστε τον προϋπολογισμό σας και αποφύγετε δυσάρεστες εκπλήξεις- σχεδόν κοινή εργασία νούμερο ένα. Δεν πρέπει να πιέζετε τον πωλητή και να του ζητάτε μια κατά προσέγγιση αξιολόγηση της δουλειάς (καλά, τουλάχιστον κατά προσέγγιση, απροσδόκητα, με το μάτι, αλλά όπως συμβαίνει με άλλους, λοιπόν, σε έργα αυτού του τύπου, αλλά από εμπειρία, λοιπόν, εντός του περιθώριο σφάλματος). Η πλήρης αξιολόγηση του προϋπολογισμού είναι δυνατή μόνο μετά από ανάγνωση, ανάλυση και τελική έγκριση των όρων εντολής. Εάν ο προγραμματιστής σας ενεργεί διαφορετικά, ετοιμαστείτε για το γεγονός ότι η αναθεώρηση θα κοστίσει τουλάχιστον το διπλάσιο.

    Με βάση την αντικειμενική ανάγκη για αλλαγές και επεκτάσεις- Έγραψα παραπάνω ότι ο προγραμματιστής δεν εξαφανίζεται και είναι έτοιμος να κάνει αλλαγές και προσθήκες σύμφωνα με τις απαιτήσεις σας ανά πάσα στιγμή. Επομένως, μην προσπαθήσετε να δημιουργήσετε το CRM/ERP των ονείρων σας αμέσως, μην απαιτήσετε από τον πωλητή ένα κουμπί "Όλα λειτουργούν όσο πίνω καφέ" - εργαστείτε στο σύστημα, εντοπίστε τα κρίσιμα σχόλια για εσάς και αρχίστε να συλλέγετε απαιτήσεις και να σχεδιάζετε τις τεχνικές προδιαγραφές.

    Μπορείτε να γράφετε ατελείωτα για τεχνικές εργασίες· αυτό είναι ένας πραγματικός γεννήτρια όχι μόνο μιμιδίων και παραμυθιών, αλλά και πονοκεφάλων. Μπορείτε να μιλήσετε για προτεραιότητες και κανόνες σχεδιασμού, για GOST 1989, που κάνει τις τεχνικές προδιαγραφές απάνθρωπες, για πρότυπα IEEE, που είναι λίγο καλύτερα, για πρωτότυπα και τεχνικές προδιαγραφές που τις συμπληρώνουν. Αλλά στο τέλος θα ήθελα να περιοριστώ σε έναν, τον πιο σημαντικό κανόνα: μια τεχνική προδιαγραφή δεν είναι κανόνας δικαίου, ούτε GOST ούτε δόγμα, επομένως, αν μπορείτε να το βελτιώσετε, βελτιώστε το, αν μπορείτε να απλοποιήσετε Απλοποιήστε το, αν μπορείτε να το κάνετε με χάρη και για να αρέσει σε όλους, κάντε το. Είμαι σίγουρος ότι μετά από αυτό, κανείς δεν θα χώσει τη μύτη του στις τεχνικές προδιαγραφές και θα πει ότι δεν είναι γραμμένο εκεί. Ή σχεδόν κανένας.

    Όλο τον Δεκέμβριο προσφέρουμε εκπτώσεις στο RegionSoft CRM και σε όλο το δικό μας λογισμικό. Από 1 Δεκεμβρίου έως 15 Δεκεμβρίου - 15% και αυστηροί όροι για δόσεις και ενοικιάσεις. Δεν έχουμε -70% και -90%, γιατί κρατάμε οικονομικά δικαιολογημένη την τιμή για τις άδειες και δεν την βγάζουμε από το μπλε.

    Λοιπόν, εάν χρειάζεστε ένα σύστημα CRM (με ή χωρίς τροποποίηση), τότε μεταβείτε στο η ιστοσελίδα μας, υπάρχουν πολλά για το CRM, τα πλεονεκτήματά του και άλλο εταιρικό λογισμικό.

    Και ναι, πάντα αναζητούμε συνεργάτες που είναι έτοιμοι να πουλήσουν CRM και άλλα προϊόντα, να τροποποιήσουν και να πουλήσουν CRM, να πουλήσουν λογισμικό και να εκπαιδεύσουν χρήστες. Η κατανομή του εισοδήματος είναι δίκαιη και ωφέλιμη για τον σύντροφο. Θα σας δείξουμε, θα σας πούμε, θα σας μάθουμε. Γράφω σε [email προστατευμένο]

    Διαφάνειες, διαφάνειες. Τα κόμικς λαμβάνονται από το http://www.modernanalyst.com/ και το Pinterest. Αν υπάρχει καλύτερη μετάφραση, θα χαρούμε να την συμπεριλάβουμε στην ανάρτηση.

Συχνά επισυνάπτω πρωτότυπα σελίδων, έτσι ώστε ο πελάτης να καταλάβει πώς θα μοιάζει ο ιστότοπός του. Στη συνέχεια, συντάσσω μια ξεχωριστή εργασία για τον σχεδιαστή διάταξης - με τεχνικές λεπτομέρειες και επεξηγήσεις που θα βοηθήσουν στη δουλειά του.

Όσο πιο περίπλοκη είναι η εργασία, τόσο πιο λεπτομερής θα πρέπει να είναι η τεχνική προδιαγραφή. Όταν συμμετείχα σε μεγάλα έργα, είδα τους όρους αναφοράς που ήταν 30 σελίδες.

Guram Sipki, ιδρυτής του ψηφιακού στούντιο Udix Media

Πρώτα απ 'όλα, ο πελάτης χρειάζεται τεχνικές προδιαγραφές - για να καταλάβει πώς θα είναι η ιστοσελίδα του και σε τι θα δαπανηθούν τα χρήματα. Αν γίνει κάτι λάθος, μπορεί να ανατρέξει στις τεχνικές προδιαγραφές και να ζητήσει να γίνει εκ νέου.

Η τεχνική προδιαγραφή συντάσσεται από τον διαχειριστή έργου αφού επικοινωνήσει με τον πελάτη και συζητήσει την εργασία με τον σχεδιαστή.

Οι μεγάλοι πελάτες συχνά ζητούν πολύ λεπτομερείς τεχνικές προδιαγραφές, οι οποίες περιγράφουν κάθε κουμπί. Στις μικρές εταιρείες, αντίθετα, δεν αρέσουν τα προσεγμένα έγγραφα 100 σελίδων.

Ένα παράδειγμα τεχνικής εργασίας για τη βελτίωση της ιστοσελίδας

Γενικές πληροφορίες

Όνομα του αυτοματοποιημένου συστήματος

"AS Sbyt"

Πελάτης

Εκτελεστής διαθήκης

Βάση για την εργασία

Προγραμματισμένες ημερομηνίες για την έναρξη και τη λήξη των εργασιών για τη δημιουργία του συστήματος

Έναρξη εργασιών: 01.09.2010

Ολοκλήρωση εργασιών: 31/12/2010

Σκοπός και στόχοι δημιουργίας του συστήματος

Σκοπός του συστήματος

Υπό ανάπτυξη αυτοματοποιημένο σύστημαέχει σχεδιαστεί για να αυτοματοποιεί τις διαδικασίες πωλήσεων της επιχείρησης..

Στόχοι δημιουργίας του συστήματος

Στόχοι δημιουργίας αυτοματοποιημένου συστήματος

Οι στόχοι της ανάπτυξης του "AS Sbyt" είναι:

  1. 3. Χαρακτηριστικά του αντικειμένου αυτοματισμού

3.1 Επιχειρηματικές διαδικασίες

3.1. 1 Επιχειρηματική διαδικασία «Σύμβαση συμφωνίας»

Θα γίνει η ασπίδα σας· σε αυτό το έγγραφο, εάν συμβεί κάτι, θα μπορείτε να δείξετε το δάχτυλό σας σε έναν αδίστακτο προγραμματιστή και να απαιτήσετε να συμμορφωθεί ο ιστότοπός σας με αυτό.

Τεχνικό έργο(εν συντομία, "TOR") είναι ένα έγγραφο που αντικατοπτρίζει τις απαιτήσεις για τον μελλοντικό σας ιστότοπο με όσο το δυνατόν περισσότερες λεπτομέρειες και ξεκάθαρα.

Η ιστοσελίδα δημιουργείται ακριβώς με βάση τις τεχνικές προδιαγραφές. Όσο πιο λεπτομερής και ξεκάθαρη είναι, τόσο περισσότερο ο νέος σας ιστότοπος θα ανταποκρίνεται στις προσδοκίες σας.

Οι όροι αναφοράς για τη δημιουργία ιστοσελίδας - ως νόμος, δεν πρέπει να επιτρέπουν ερμηνείες και αποκλίσεις.

Ο προγραμματιστής κάνει ό,τι δεν καθορίζεται στις τεχνικές προδιαγραφές κατά την κρίση του.

· Οδηγός διαχειριστή.

· Οδηγός Διαχείρισης Περιεχομένου.

· Οδηγός εγκατάστασης;

· Οδηγός Προγραμματιστή.

2.20. Οργάνωση και διεξαγωγή εκπαίδευσης για ειδικούς της Ερευνητικής Επιτροπής υπό την Εισαγγελία της Ρωσικής Ομοσπονδίας

Ισχύουν οι ακόλουθες απαιτήσεις εκπαίδευσης:

· Ο ανάδοχος οφείλει να πραγματοποιήσει εκπαίδευση υπαλλήλων της Ανακριτικής Επιτροπής στην Εισαγγελία Ρωσική Ομοσπονδίαπου αποτελείται από όχι περισσότερα από 10 άτομα.

· Η εκπαίδευση πρέπει να διεξάγεται στα ρωσικά.

· Οι χώροι εκπαίδευσης παρέχονται από τον Πελάτη.

· Ο τόπος και ο χρόνος εκπαίδευσης πρέπει να συμφωνηθούν με τον Πελάτη.

Η εκπαίδευση πρέπει να διεξάγεται σε όλες τις λειτουργίες του Συστήματος.

Ως μέρος της εκπαίδευσης, είναι απαραίτητο να πραγματοποιηθεί το περιεχόμενο πληροφοριών μιας πιλοτικής τοποθεσίας του Δακτυλίου Τοποθεσιών της Ερευνητικής Επιτροπής υπό την Εισαγγελία της Ρωσικής Ομοσπονδίας.


3.

Δείγματα τεχνικών προδιαγραφών για τη βελτίωση της ιστοσελίδας

Σπουδαίος

Κατά τη διαδικασία υλοποίησης, ο Ανάδοχος πρέπει να παρέχει βοήθεια στον Πελάτη εντός του πλαισίου του Προγράμματος Υλοποίησης.

6.1.11. Σε περίπτωση κακής προετοιμασίας του προσωπικού του Πελάτη για υλοποίηση και ανάγκης πρόσθετης βοήθειας από τον Ανάδοχο για την επιτυχή υλοποίηση του λογισμικού, πρέπει να συνταχθεί πρόσθετο πρωτόκολλο για συμφωνία επί συμβατικών τιμών παροχής πληροφοριών και συμβουλευτικών εργασιών.

6.2 Η διαδικασία για περαιτέρω υποστήριξη εργασιών AS “SALES”.


Αφού τεθεί σε λειτουργία το λογισμικό, μπορούν να πραγματοποιηθούν πρόσθετες τροποποιήσεις και επιθυμίες του Πελάτη σύμφωνα με τις τεχνικές προδιαγραφές που έχουν συμφωνηθεί με τον Πελάτη.

Ο ΠΠ πρέπει να αναφέρει την πολυπλοκότητα και το κόστος της εργασίας για την εφαρμογή πρόσθετων απαιτήσεων.

6.2.2. Ο Ανάδοχος αναλαμβάνει να διατηρεί τηλεφωνική γραμμή για υποστήριξη λογισμικού.

Όψεις αλληλεπίδρασης Πριν αρχίσουμε να αναλύουμε τη διαδικασία δημιουργίας μιας τεχνικής προδιαγραφής, ας μιλήσουμε για το τετράγωνο στο οποίο βρίσκονται ο ανάδοχος και ο πελάτης κατά την έναρξη του έργου. Απαιτήσεις- την επιθυμητή συμπεριφορά του συστήματος, που περιγράφεται από τον πελάτη ή τον κάτοχο της διαδικασίας, προς υλοποίηση. Κατά κανόνα, οι απαιτήσεις διαμορφώνονται με βάση την εργασιακή εμπειρία και την κατανόηση της σωστής συμπεριφοράς του προγράμματος.

Αυτές είναι βασικές πληροφορίες για τον προγραμματιστή (προμηθευτή), ωστόσο, είναι στο στάδιο της συλλογής απαιτήσεων που προκύπτει ο μεγαλύτερος αριθμός συγκρούσεων, σφαλμάτων, περιττών αιτημάτων κ.λπ.

Πόροι- άνθρωποι, μηχανές, εξοπλισμός, περιβάλλον ανάπτυξης, χρόνος και χρήμα που πρέπει να χρησιμοποιηθούν στη διαδικασία υλοποίησης των απαιτήσεων. Οι πόροι απαιτούν σαφή σχεδιασμό και αξιολόγηση στο στάδιο της έγκρισης των τεχνικών προδιαγραφών.

Αυτό μπορεί να περιλαμβάνει απαιτήσεις για διάφορα είδη ικανοτήτων ταξινόμησης, ενοποίησης συνομιλίας και τηλεφωνίας.

Επίπεδο εξυπηρέτησης- στην πραγματικότητα, οι απαιτήσεις αυτού του επιπέδου θα πρέπει να είναι οι πρώτες που θα συμπεριληφθούν σε νέες εκδόσεις με διορθώσεις. Αυτές είναι εργασίες που σχετίζονται με την ταχύτητα απόκρισης του συστήματος, τη λειτουργία υπό υψηλό φορτίο και την ασφάλεια.

Προσοχή

Στην ιδανική περίπτωση, ο προμηθευτής δεν θα πρέπει να έχει τέτοιες τροποποιήσεις - το εταιρικό λογισμικό δεν θα πρέπει να επιβραδύνει, να χάνει δεδομένα, να συμπτύσσει φόρμες και να διανέμει δικαιώματα πρόσβασης του ίδιου επιπέδου. Αλλά εάν εμφανιστεί μια απαίτηση και δεν σχετίζεται με την προσωπική παράνοια του πελάτη ή προβλήματα από την πλευρά του υλικού, αξίζει να δώσουμε μεγαλύτερη προσοχή σε αυτήν.

Επίπεδο τεχνολογίας- τελευταίο στη λίστα, αλλά μπροστά από τους υπόλοιπους σε σημασία και πολυπλοκότητα.


Αυτές μπορεί να είναι απαιτήσεις πελατών που σχετίζονται με την πλατφόρμα, το λειτουργικό σύστημα ή τις συσκευές. Για παράδειγμα, ένα αίτημα για δημιουργία για MacOS.

Microsoft World ή Microsoft Excel.

Προσωπικά, χρησιμοποιούμε ειδικά προϊόντα λογισμικού κατά την ανάπτυξη μιας σελίδας προορισμού.

Με τη βοήθειά τους, μπορείτε γρήγορα και εύκολα να δημιουργήσετε έργα ακόμη και για πολύπλοκους ιστότοπους - για παράδειγμα, Balsamiq. Ωστόσο, το πώς φτιάχνουμε ολόκληρο το πρωτότυπο έχει ήδη περιγραφεί στο άρθρο.

Με θέμα: Προτυποποίηση ιστοσελίδων: δημιουργία, εργαλεία και προγράμματα.

Ο σχεδιασμός πριν από το έργο μπορεί να γίνει από κοινού με τον προγραμματιστή ή να μεταφερθεί πλήρως στους ώμους του.
Το κύριο πράγμα είναι, μην ξεχνάτε, τότε συμφωνείται και υπογράφεται και από τα δύο μέρη.

LIFE HACKS FOR DRAFTING TOR

Αυτά τα σημεία ισχύουν εξίσου τόσο για τη συμπλήρωση του φυλλαδίου όσο και για τη σύνταξη τεχνικών προδιαγραφών.

Και σε αυτά θα σας πω μικρά κόλπα για το πώς να συντάξετε τεχνικές προδιαγραφές για έναν ιστότοπο και να κάνετε πιο εύκολη την ήδη δύσκολη ζωή ενός επιχειρηματία:

1.

Βεβαιωθείτε ότι ο πελάτης και ο ερμηνευτής καταλαβαίνουν ο ένας τον άλλον σωστά.»

Οι όροι αναφοράς δεν πρέπει να περιέχουν ποιοτικά επίθετα: όμορφο, αξιόπιστο, μοντέρνο. Δεν μπορούν να γίνουν ξεκάθαρα κατανοητές. Ο καθένας έχει τις δικές του αντιλήψεις για την ομορφιά και τον μοντερνισμό.

Κοίτα. Κάποιος θεώρησε ότι αυτό το σχέδιο ήταν όμορφο και το επέτρεψε να χρησιμοποιηθεί στον ιστότοπό του:

Το ίδιο συμβαίνει με ασαφείς διατυπώσεις που δεν σημαίνουν τίποτα από μόνες τους:

  • Ο πελάτης πρέπει να αρέσει στον ιστότοπο.Κι αν έχει κακή διάθεση;
  • Ο ιστότοπος πρέπει να είναι βολικός.Τι σημαίνει? Βολικό για τι;
  • Ο χώρος πρέπει να αντέχει βαριά φορτία. 10 χιλιάδες επισκέπτες; Ή 10 εκατομμύρια;
  • Υψηλής ποιότητας περιεχόμενο ειδικών.Λοιπόν, καταλαβαίνεις την ιδέα.

Ελέγξτε για ασάφειες στο κείμενο. Αν υπάρχει, ξαναγράψτε το.

Αποφασίσατε να παραγγείλετε έναν ιστότοπο (γνωστός και ως σελίδα προορισμού); Όπως δείχνει η πρακτική, δεν είναι τόσο απλό. Εκατοντάδες πελάτες, έχοντας δει τον ολοκληρωμένο ιστότοπό τους, ανακαλύπτουν ότι δεν τους ταιριάζει: ο σχεδιασμός είναι λάθος, η διάταξη είναι κουτσή, τα κείμενα είναι λάθος, έχουν προστεθεί ένα σωρό περιττές λειτουργίες.

Για να αποφύγετε τέτοιες συνέπειες, χρειάζεστε τεχνικές προδιαγραφές για την ανάπτυξη ιστοσελίδων.

ΤΟ ΧΡΕΙΑΖΟΜΑΙ;!

Δεν έχει σημασία ποιος θα διευθύνει τον ιστότοπο - εσείς οι ίδιοι, ο συγγενής σας, ελεύθεροι επαγγελματίες με μέτρια αμοιβή, μια εξειδικευμένη εταιρεία για ένα τεράστιο χρηματικό ποσό...

Πρέπει να υπάρχουν τεχνικές προδιαγραφές για τον ιστότοπο.

Για παράδειγμα, μπορείτε να ζητήσετε να δημιουργήσετε μια προσαρμοσμένη αναφορά για το RegionSoft CRM ή μπορείτε να παραγγείλετε ενοποίηση με τον ιστότοπο. Πρόκειται για εργασίες με τελείως διαφορετικές προθεσμίες· η προτεραιότητα είναι πολύ σημαντική εδώ. Αφού συγκεντρωθούν, αναλυθούν και συμφωνηθούν οι απαιτήσεις με τους υπαλλήλους και τη διοίκηση, μπορείτε να ξεκινήσετε να δημιουργείτε μια τεχνική προδιαγραφή.
Μπορείτε να ζητήσετε από τον πωλητή τη φόρμα ή να τη δημιουργήσετε μόνοι σας - σε κάθε περίπτωση, υπάρχουν αρκετοί σιδερένιοι κανόνες, η τήρηση των οποίων θα γλιτώσει από πονοκεφάλους εσάς και τον προμηθευτή σας CRM.

Ανατομία τεχνικής προδιαγραφής

Αν μιλάμε για τη διαδικασία δημιουργίας μιας τεχνικής προδιαγραφής, υπάρχουν πολλά στάδια. Το διαδοχικό πέρασμά τους οδηγεί τον πελάτη στην επιθυμητή βελτίωση.
Εδώ είναι.

Εδώ είναι σημαντικό να ακούσετε τη γνώμη του πωλητή, καθώς ξέρει ακριβώς πόσος χρόνος θα δαπανηθεί για αυτό ή εκείνο το έργο. Πιστέψτε με, δεν είναι ωφέλιμο για έναν προγραμματιστή να χάνει χρόνο και να αυξάνει τις προθεσμίες - είναι ωφέλιμο για αυτόν να ολοκληρώσει όσο το δυνατόν περισσότερα έργα και να το κάνει καλά, για να μην υποστεί πλήγμα στη φήμη του.

Όσον αφορά τον ρεαλισμό, η αποφυγή αιτημάτων για αναβάθμιση του CRM στο επίπεδο ενός συστήματος διαχείρισης επιταχυντών είναι απλή: θα πρέπει να συμπεριλάβετε στις απαιτήσεις ό,τι πραγματικά χρειάζεται αυτή τη στιγμή και στο άμεσο μέλλον.

Για παράδειγμα, το RegionSoft CRM είναι ένα πρόγραμμα επιτραπέζιου υπολογιστή, δεν έχουμε πρόγραμμα-πελάτη προγράμματος περιήγησης. Το να μας ζητάμε να δημιουργήσουμε μια διαδικτυακή εφαρμογή για μια εταιρεία είναι άσκοπο, πρόκειται για μια σημαντική εξέλιξη, βρίσκεται σε εξέλιξη και δεν είναι πιθανή ανάπτυξη για μία εταιρεία.

Πλήρη και σύντομα ονόματα του πληροφοριακού συστήματος

Το πλήρες όνομα του συστήματος είναι ο επίσημος ιστότοπος της Ερευνητικής Επιτροπής που υπάγεται στην Εισαγγελία της Ρωσικής Ομοσπονδίας.

Το σύντομο όνομα του συστήματος είναι "SKP Site", "System", "Site".

1.2. Το όνομα του πελάτη του συστήματος και τα στοιχεία του

Όνομα: Ερευνητική Επιτροπή υπό την Εισαγγελία της Ρωσικής Ομοσπονδίας

Τοποθεσία:

Πληροφορίες

Μόσχα, λωρίδα Tekhnicheskiy, κτίριο 2

Πραγματική διεύθυνση: Α

Υπεύθυνος επικοινωνίας με τον πελάτη:

Τηλέφωνο: (4, (4;

Διεύθυνση ηλεκτρονικού ταχυδρομείου

1.3. Κατάλογος εγγράφων βάσει των οποίων δημιουργείται το Σύστημα

Κρατική σύμβαση αριθ.________________ ημερομηνίας ___ ___________ 2010

1.4.


Προγραμματισμένες ημερομηνίες για την έναρξη και την ολοκλήρωση των εργασιών για τη δημιουργία του Συστήματος

Καθορίζεται σύμφωνα με τη Συμφωνία.

2. Απαιτήσεις συστήματος

2.1.

ημερομηνία πληρωμής

Αριθμός πληρωμής

Αριθμός πληρωμής στο σύστημα πληρωμών

Ποσό πληρωμής

  1. Επιλέξτε γραμμές αρχείων μεταφοράς δεδομένων
  2. Ξεκινήστε να περιηγείστε στις γραμμές του αρχείου μεταφοράς δεδομένων
  3. Διαβάστε τη γραμμή αρχείου μεταφοράς δεδομένων
  4. Λάβετε τον κωδικό σύμβασης από τη γραμμή αρχείου μεταφοράς δεδομένων
  5. Βρείτε το αντίστοιχο στοιχείο ανά κωδικό στον κατάλογο "Συμφωνίες αντισυμβαλλομένου", εάν το στοιχείο δεν βρεθεί, εμφανίστε το μήνυμα "Δεν βρέθηκε συμφωνία με τον κωδικό..."
  6. Εάν βρεθεί το στοιχείο, τότε προσθέστε μια γραμμή στον πίνακα τιμών, όπου: "Συμφωνία" - το στοιχείο που βρέθηκε, "Ημερομηνία" - "Δεδομένα_πλατφόρμα", "Αριθμός πληρωμής" - "Nomer_plat", "Ποσό" - "Summa_plat"
  7. Αφού λάβετε την τελευταία γραμμή του αρχείου μεταφοράς δεδομένων, τερματίστε τον κύκλο
  8. Για κάθε γραμμή του πίνακα τιμών, δημιουργήστε ένα παραστατικό «Εντολή πληρωμής για λήψη χρημάτων».

Όταν συμπληρώνετε μια σύντομη περιγραφή ή συντάσσετε όρους αναφοράς για έναν σχεδιασμό ιστότοπου, μην αφήνετε κενά σε αυτήν.

Πρέπει να καταλάβετε ότι "Κατά την κρίση του προγραμματιστή" σημαίνει "κάνω ό,τι θέλω" ή "Ό,τι δεν προσδιορίζεται γίνεται κατά την κρίση του ερμηνευτή". Και πιστέψτε με, αυτό δεν είναι απλώς ένα κενό, αλλά ένα ολόκληρο παράθυρο στην Ευρώπη για τον προγραμματιστή.

Και φυσικά, αυτό δεν συμβαίνει πάντα.

Εάν συναντήσετε έναν ικανό ειδικό, τότε δεν χρειάζεται να ανησυχείτε για το αποτέλεσμα.

Αλλά εδώ προκύπτει ένα άλλο πρόβλημα: μπορεί πραγματικά να το κάνει σωστά, αλλά δεν θα σας αρέσει καθαρά υποκειμενικά. Και όλα θα είναι όπως στο αστείο που είναι γνωστό σε πολλούς προγραμματιστές:

ΣΥΝΤΟΜΗ ΣΧΕΤΙΚΑ ΜΕ ΤΑ ΚΥΡΙΑ ΠΡΑΓΜΑΤΑ

Σίγουρα δεν θα μετανιώσετε για το χρόνο που αφιερώσατε για τη σύνταξη και τη συμφωνία σχετικά με τους όρους αναφοράς για τη δημιουργία ενός ιστότοπου ή μιας σελίδας προορισμού.

Εξάλλου, αυτό είναι το καλύτερο εργαλείο σας για την παρακολούθηση και την επίλυση διαφωνιών που προκύπτουν στη διαδικασία.

Όταν κάνετε κλικ σε μια συγκεκριμένη περιοχή, θα πρέπει να μεταβεί σε μια σελίδα με μια περιγραφή κειμένου αυτής της περιοχής.

· Αποκλεισμός "Blog of the Chairman"- θα πρέπει να είναι μια λίστα με τα τρία πιο πρόσφατα θέματα που δημιουργήθηκαν στο ιστολόγιο με τη μορφή του τίτλου του θέματος και της ημερομηνίας δημοσίευσής του. Το όνομα του θέματος θα είναι ένας σύνδεσμος στον οποίο, όταν κάνετε κλικ, θα σας μεταφέρει σε μια σελίδα ιστολογίου που περιγράφει αυτό το θέμα. Αυτό το μπλοκ θα πρέπει επίσης να περιέχει ένα βίντεο που μπορεί να αναπαραχθεί χωρίς να φύγει αρχική σελίδα. Το βίντεο θα πρέπει να έχει έναν σύνδεσμο "Σχόλια", ο οποίος αντιπροσωπεύει τον αριθμό των σχολίων στη δεδομένη εικόνα βίντεο. Ο σύνδεσμος "Σχόλια" θα πρέπει να οδηγεί σε μια σελίδα ιστολογίου με σχόλια για το βίντεο που υποβλήθηκε.

Το υποσέλιδο πρέπει να περιέχει ένα πλαίσιο αναζήτησης, πληροφορίες πνευματικών δικαιωμάτων κ.λπ.

2.3.

Σύντομοςείναι ένα ερωτηματολόγιο με ερωτήσεις σχετικά με το περιεχόμενο, το σχεδιασμό, τεχνικές δυνατότητεςΟ μελλοντικός σας ιστότοπος.

Φυσικά, μια λεπτομερής αναφορά υπογεγραμμένη και από τα δύο μέρη μπορεί να αντικαταστήσει τους όρους εντολής.

Σε τελική ανάλυση, αυτό είναι πρακτικά το ίδιο πράγμα, η μόνη διαφορά είναι ότι η σύντομη είναι το όραμά σας και η τεχνική προδιαγραφή είναι το τελικό έγγραφο που βασίζεται στο δικό σας σύντομο και στα σχόλια του ίδιου του προγραμματιστή.

Εάν ορισμένα σημεία προκαλούν δυσκολίες, τότε μη διστάσετε να κάνετε ερωτήσεις στον προγραμματιστή όπως "Τι σημαίνει αυτό;", "Πώς θα επηρεάσει αυτό τη λειτουργία του ιστότοπού μου;", καθώς δεν καταλαβαίνουν όλοι οι προγραμματιστές το ίδιο πράγμα με εσάς.

Είτε στη στήλη " Επιπλέον πληροφορίες«Βεβαιωθείτε ότι έχετε δηλώσει όλες τις επιθυμίες σας που δεν συμπεριλήφθηκαν στις απαντήσεις στις ερωτήσεις.

Εάν λείπει αυτή η στήλη, απλώς προσθέστε τις στο τέλος της σύντομης περιγραφής.

VK, Google, Facebook.

3.2.2 V ΠΡΟΣΩΠΙΚΟΣ ΛΟΓΑΡΙΑΣΜΟΣστην ενότητα παραγγελίες, προσθέστε ένα πεδίο για να προσθέσετε έναν κωδικό προσφοράς.

3.2.3 Αντί για τη σελίδα που λαμβάνει ο χρήστης μετά από αίτημα ανάκτησης κωδικού πρόσβασης (όπως name.com/bitrix/admin/index.php?change_password=yes&lang=ru&USER_CHECKWORD=), δημιουργήστε μια σελίδα (όπως name.com/login/forgot /change_password=yes&lang =ru&USER_CHECKWORD=), το οποίο θα εμφανίζει το περιεχόμενο του ιστότοπου, θα έχει το πεδίο "Email κατά την εγγραφή", μια γραμμή ελέγχου, έναν νέο κωδικό πρόσβασης, επιβεβαίωση κωδικού πρόσβασης και ένα κουμπί αποστολής δεδομένων.

3.2.4 Κατά την προσθήκη ειδών στο καλάθι, θα πρέπει να εμφανίζεται ένα μήνυμα που να υποδεικνύει ότι το προϊόν έχει προστεθεί στο καλάθι.

3.2.5 Προσθέστε μια έξοδο μηνύματος που υποδεικνύει ότι ο κωδικός πρόσβασης δεν ταιριάζει με τις παραμέτρους ασφαλείας κατά την εγγραφή νέου χρήστη.

ΑυτοματοποιημένοΣύστημα ΠΩΛΗΣΕΩΝ.Τεχνικό έργοΣε φύλλα Ισχύει από «__» ____________ 2010

"_" ______________ 2010

Σταδιακά, οι αλλαγές συμπεριλήφθηκαν στην κυκλοφορία και αργότερα κατέστησαν δυνατή τη δημιουργία ενός νέου προϊόντος για καταστήματα χονδρικής, λιανικής και υπεραγορές - RegionSoft Retail.

Επίπεδο χρήστη ή ομάδας χρηστών.Σε αυτό το επίπεδο, υλοποιούνται εργασίες για τη βελτίωση της υπάρχουσας διεπαφής. Για παράδειγμα, ένας χρήστης μπορεί να θέλει ένα παράθυρο με τον αριθμό και την κατάσταση της τελευταίας παραγγελίας να εμφανίζεται όταν τοποθετείται το δείκτη του ποντικιού πάνω από έναν πελάτη ή μια προσαρμοσμένη αναφορά με μια ειδική ομαδοποίηση δεδομένων.

Η επανεξέταση σε αυτό το επίπεδο απαιτεί λιγότερο χρόνο, αλλά μπορεί να υπάρχουν πολλά από αυτά - για παράδειγμα, αρκετές απαιτήσεις από τα τμήματα μάρκετινγκ, logistics και τεχνικής υποστήριξης.

Επίπεδο λειτουργικότητας.Συχνά είναι δύσκολο να το διαχωριστεί από το προηγούμενο· εδώ λειτουργεί ένα επίσημο κριτήριο - η βελτίωση δεν είναι στο επίπεδο της εμφάνισης κάτι στη διεπαφή, αλλά στο επίπεδο της οριστικοποίησης της λογικής του συστήματος.

Αν γράφει χυλός, ίσως πρέπει να τρέξεις και να μην κοιτάς πίσω.

  • Ασφαλιστείτε για την ανεντιμότητα του ερμηνευτή.Όταν ο ιστότοπος είναι έτοιμος, μπορεί να ελεγχθεί σύμφωνα με τις τεχνικές προδιαγραφές. Υπάρχουν ασυνέπειες; Ο προγραμματιστής είναι υποχρεωμένος να τα διορθώσει. Εάν συνεργάζεστε επίσημα και έχετε συνάψει συμφωνία, μπορείτε να το αναγκάσετε ακόμη και μέσω των δικαστηρίων.
  • Απλοποιήστε την αντικατάσταση των καλλιτεχνών.Εάν ο πελάτης και ο προγραμματιστής μάλωναν και τράπηκαν σε φυγή, η δημιουργία του ιστότοπου μπορεί να πάρει πολύ χρόνο. Όταν υπάρχει μια λεπτομερής τεχνική προδιαγραφή, μπορεί να μεταφερθεί σε μια νέα ομάδα - θα εμπλακούν στη δουλειά πολλές φορές πιο γρήγορα.
  • Μάθετε το κόστος ανάπτυξης ενός σύνθετου προϊόντος.Είναι αδύνατο να εκτιμηθεί άμεσα ο ακριβής χρόνος και το κόστος ανάπτυξης μιας πολύπλοκης υπηρεσίας Ιστού. Πρώτα πρέπει να καταλάβετε πώς θα λειτουργεί η υπηρεσία και ποιες λειτουργίες θα έχει.

Υπάρχει πρόσβαση root, οι δικές σας διευθύνσεις IP, θύρες, κανόνες φιλτραρίσματος και πίνακες δρομολόγησης.

Το Google PageSpeed ​​Insights είναι δωρεάν υπηρεσίασυστάσεις για ιστότοπους για την επιτάχυνση της εμφάνισης σελίδων στο πρόγραμμα περιήγησης του χρήστη (https://developers.google.com/speed/pagespeed/insights/).

Η βελτιστοποίηση μηχανών αναζήτησης (ή SEO) είναι ένα σύνολο μέτρων για εσωτερική και εξωτερική βελτιστοποίηση για την αύξηση της θέσης του ιστότοπου στα αποτελέσματα των μηχανών αναζήτησης για συγκεκριμένα αιτήματα χρηστών.

Η βελτιστοποίηση εξωτερικού ιστότοπου είναι η εγγραφή ενός ιστότοπου σε μηχανές αναζήτησης, προαγωγή σε στα κοινωνικά δίκτυα, δημιουργία συνδέσμων προσελκύοντας συνδέσμους από άλλους πόρους στον προωθούμενο ιστότοπο, διαφήμιση banner, διαφήμιση με βάση τα συμφραζόμενα.

Η εσωτερική βελτιστοποίηση ιστότοπου είναι η βελτιστοποίηση κειμένου, διευθύνσεων URL, επεξεργασία της δομής του ιστότοπου, σύνδεση, έλεγχος απαντήσεων διακομιστή.

Διαθέσιμα υλικά Σύνδεσμοι προς τους αγαπημένους σας ιστότοπους, καθώς και φυλλάδια, περιοδικά, φωτογραφίες - οτιδήποτε, ή ίσως έχετε ένα έτοιμο βιβλίο επωνυμίας. Επισυνάπτεται ως ξεχωριστό αρχείο. Ελάχιστη ανάλυση και συσκευές οθόνης Σε αυτήν την παράγραφο, υποδείξτε από ποιες συσκευές σκοπεύετε να προβάλετε τον ιστότοπο - υπολογιστές, φορητοί υπολογιστές, smartphone... Οθόνες υπολογιστών από 19 έως 27 ίντσες. Φορητοί υπολογιστές από 15,6 έως 17,3 ίντσες. Smartphone από 3,5 έως 6 ίντσες. Ταμπλέτες από 7 έως 12 ίντσες Χρειάζομαι έκδοση για κινητά? Ναι ΛΕΙΤΟΥΡΓΙΚΕΣ ΑΠΑΙΤΗΣΕΙΣ Κατά προσέγγιση σύνολο μονάδων (για χρήστες) Αυτή η ενότητα πρέπει να περιλαμβάνει όλα τα λειτουργικότητα, που θέλετε να δείτε στον ιστότοπο.

Αυτό θα μπορούσε να είναι ένα καλάθι αγορών, φίλτρα καταλόγου με βάση διάφορες παραμέτρους, η δυνατότητα να κάνετε μια ηλεκτρονική παραγγελία, να αφήσετε ένα αίτημα για πίσω κλήση, εγγραφείτε στο ενημερωτικό δελτίο και οποιεσδήποτε άλλες επιλογές Φίλτρα καταλόγου ανά τιμή, αλφαβητικά, ανά κατασκευαστή.
CruRtcJ9b: S »xvzhb╟▌╤└u╟j_ ■ e╘dj» j ■ ╛eхhjus (gtt┬pb╟▌╤└u╟╛#╜┘al+ka kQ3┴I ~ ~##┐╜╙ ┐█ ┐╜╙ ┐╜╙ ┐╜╙ ┐╜╙ ┐╜╙ ts╜IWA▓BOь└vOZb╟▌╤└u╟╛#╜┘al+KaXG[ b:ьVzhb╟▌╤└u╟╛#╜┘al+KaXG╟╜┘╟╜Vzh ┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜│ts&V█7┬m3aqNYJy╕°Vzhb╟▌╤└u╌╛#╜└┘Al+Ka ╛ #╜┘al+KaXG[ b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG[b:bVzhb╟▌╤└u╟╛#╜┘al+KaXG╬Fy╖XB ≈≈K&ОQТе╦▒'%[н╓≥Lκ"[Ц(b╖~ы╚б╖~ы╚b╖~ы╚b╖~ы╚b╖~ы╚b╖~у╚б╖~у ╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚b╖~y╚bD'═\┘*NλkZ ⌡ ©Tw╦|╒T⌠ZZA╙┼r≤⌠ьЧ≈D7i$╔≥ И∙?БjЛ?Ч╜∙╤SQ≥╒°еNFх═с┬├6ыСыl╪╪╡ ┬ 7┴+iSo(╦°rБ╒┴■E4SCg┬╨ z╖ ┘╤m°с÷Уm╦Wыmdр'%R^&╔gt╖yхDA]zт╪L╝i▌▀s_E+H OlM²K%j ┼╖`СsА≈K▐ф²Yч▐Hd╟Fг╬lн∙╥е#⌡и<ТC▐╡И&d╨JГ!─Sj║·K,s┼#m ╓⌡JГн IOLЬ©h?ОeН╡▐┌ъHЙmwд$©aЗ$ёу°Н≤gт.bZ┐}Э1црn▄т≈фГ?TA<э:р▓T<кГ║2ic╖▀Иqf⌠Pсс▀32нЫ╘▌n-«÷0i╦▓Q:⌠^%5#⌡Н⌡│ вЬ└%N╙Оtб}8яца╨з≤[╖┐╕■╡╒4╞▄G√≥оЖNa╡vсM╔)9╘д≈ib╕╝■ i├{≈²5╨∙∙╣ф╒▓Цz²┌Ф╤I√HaО2┬б=└Б╦F∙P»гЙz&╔Р3{ ёS÷_н_g7⌡г$Н╜чk┐(ЗQэH▓З╨?.

Πάβελ Μολιάνοφ

Θυμάστε τον νόμο του Μέρφι; Αν μπορείς να παρεξηγηθείς, σίγουρα θα παρεξηγηθείς. Αυτό ισχύει όχι μόνο στην επικοινωνία μεταξύ των ανθρώπων, αλλά και στη δημιουργία ιστοσελίδων. Ο πελάτης ήθελε ένα δεύτερο Facebook, αλλά απέκτησε ένα φόρουμ για νέους εκτροφείς σκύλων. Ο προγραμματιστής δεν μάντεψε τι ήθελε ο πελάτης - έχασε το χρόνο του.

Σε αυτόν τον οδηγό θα σας πω τι και γιατί πρέπει να γράψετε στους όρους αναφοράς. Ταυτόχρονα, θα σας δείξω πώς να μην γράφετε για να μην μετατραπεί η δημιουργία τεχνικών προδιαγραφών σε χαμένο χρόνο.

Το άρθρο θα είναι χρήσιμο:

  • Για όλους όσους συμμετέχουν στη δημιουργία ιστοσελίδων: προγραμματιστές, σχεδιαστές, σχεδιαστές διάταξης.
  • Υπεύθυνοι έργου.
  • Διευθυντές ψηφιακών στούντιο.
  • Επιχειρηματίες που σχεδιάζουν να παραγγείλουν την ανάπτυξη ιστοσελίδων.

Για να κάνω το υλικό χρήσιμο, συνέλεξα σχόλια από αρκετούς προγραμματιστές, σχεδιαστές, διαχειριστές έργων και ιδιοκτήτες ψηφιακών στούντιο. Πρόσθεσα τα πιο πολύτιμα στο τέλος του άρθρου. Πάμε να μάθουμε.

Τι είναι η τεχνική προδιαγραφή και γιατί χρειάζεται;

Η τεχνική προδιαγραφή είναι ένα έγγραφο που καθορίζει τις απαιτήσεις για τον ιστότοπο. Όσο πιο σαφείς και λεπτομερείς είναι αυτές οι απαιτήσεις, τόσο καλύτερα όλοι οι συμμετέχοντες στη διαδικασία κατανοούν πώς θα έπρεπε να είναι. Αυτό σημαίνει ότι αυξάνεται η πιθανότητα να μείνουν όλοι ικανοποιημένοι με το αποτέλεσμα.

Ο κύριος στόχος της τεχνικής προδιαγραφής είναι να διασφαλίσει ότι ο πελάτης και ο ανάδοχος κατανοούν σωστά ο ένας τον άλλον.

Υπάρχουν πολλά οφέλη από τις τεχνικές προδιαγραφές. Είναι διαφορετικό για κάθε πλευρά.

Οφέλη για τον πελάτη:

  • Καταλάβετε για τι πληρώνει χρήματα και πώς θα είναι ο ιστότοπος.Μπορείτε να δείτε αμέσως τη δομή, να καταλάβετε τι θα λειτουργήσει και πώς. Μάθετε αν όλα σας ταιριάζουν. Εάν όχι, δεν είναι πρόβλημα να το αλλάξετε πριν ξεκινήσει η ανάπτυξη.
  • Δείτε την ικανότητα του ερμηνευτή.Εάν οι όροι αναφοράς είναι σαφείς και ακριβείς, η εμπιστοσύνη στον προγραμματιστή αυξάνεται. Αν γράφει χυλός, ίσως πρέπει να τρέξεις και να μην κοιτάς πίσω.
  • Ασφαλιστείτε για την ανεντιμότητα του ερμηνευτή.Όταν ο ιστότοπος είναι έτοιμος, μπορεί να ελεγχθεί σύμφωνα με τις τεχνικές προδιαγραφές. Υπάρχουν ασυνέπειες; Ο προγραμματιστής είναι υποχρεωμένος να τα διορθώσει. Εάν συνεργάζεστε επίσημα και έχετε συνάψει συμφωνία, μπορείτε να το αναγκάσετε ακόμη και μέσω των δικαστηρίων.
  • Απλοποιήστε την αντικατάσταση των καλλιτεχνών.Εάν ο πελάτης και ο προγραμματιστής μάλωναν και τράπηκαν σε φυγή, η δημιουργία του ιστότοπου μπορεί να πάρει πολύ χρόνο. Όταν υπάρχει μια λεπτομερής τεχνική προδιαγραφή, μπορεί να μεταφερθεί σε μια νέα ομάδα - θα εμπλακούν στη δουλειά πολλές φορές πιο γρήγορα.
  • Μάθετε το κόστος ανάπτυξης ενός σύνθετου προϊόντος.Είναι αδύνατο να εκτιμηθεί άμεσα ο ακριβής χρόνος και το κόστος ανάπτυξης μιας πολύπλοκης υπηρεσίας Ιστού. Πρώτα πρέπει να καταλάβετε πώς θα λειτουργεί η υπηρεσία και ποιες λειτουργίες θα έχει. Για αυτό πρέπει να προετοιμάσετε τις τεχνικές προδιαγραφές.

Οφέλη για τον ερμηνευτή:

  • Κατανοήστε τι θέλει ο πελάτης.Στον πελάτη γίνονται δεκάδες ερωτήσεις, παρουσιάζονται παραδείγματα και προσφέρονται λύσεις. Στη συνέχεια, καταγράφουν τα πάντα σε ένα μόνο έγγραφο και συμφωνούν σε αυτό. Αν όλα είναι εντάξει - ρε, καταλάβατε καλά.
  • Ασφαλιστείτε έναντι των ξαφνικών επιθυμιών του πελάτη.Μερικές φορές συναντάτε πελάτες που θέλουν να αλλάξουν την εργασία στα μισά του δρόμου. Εάν έχετε συμφωνήσει και υπογράψει τους όρους εντολής, δεν το φοβάστε. Αν συμβεί κάτι, ακόμη και το γήπεδο θα είναι με το μέρος σας.
  • Δείξτε την ικανότητά σας.Μια καλά προετοιμασμένη τεχνική προδιαγραφή θα δείξει στον πελάτη την τεχνογνωσία των προγραμματιστών. Εάν η εταιρεία αμφέβαλλε αν θα σας εμπιστευόταν την ανάπτυξη ιστοτόπων, οι αμφιβολίες πιθανότατα θα διαλυθούν.
  • Για να κερδίσετε χρήματα.Ορισμένα στούντιο και προγραμματιστές προσφέρουν την προετοιμασία τεχνικών προδιαγραφών ως ξεχωριστή υπηρεσία.
  • Διευκόλυνση και επιτάχυνση της διαδικασίας ανάπτυξης. Μια καλή τεχνική προδιαγραφή υποδεικνύει τη δομή του ιστότοπου, τις απαραίτητες λειτουργίες και στοιχεία σε κάθε σελίδα. Όταν όλες οι απαιτήσεις είναι ήδη μπροστά στα μάτια σας, το μόνο που μένει είναι να σχεδιάσετε και να γράψετε τον κώδικα.

Τώρα ας δούμε πώς να δημιουργήσουμε μια καλή τεχνική προδιαγραφή που εκτελεί όλες αυτές τις λειτουργίες.

Οι όροι εντολής συντάσσονται από τον ερμηνευτή

Γενικά, ο καθένας μπορεί να συντάξει τεχνικές προδιαγραφές. "Χρειαζόμαστε έναν ιστότοπο επαγγελματικής κάρτας για μια οδοντιατρική κλινική" - αυτό είναι ήδη μια τεχνική εργασία. Θα εκπληρώσει όμως τις λειτουργίες του; Μετά βίας.

Μια καλή τεχνική προδιαγραφή προετοιμάζεται πάντα από τον εκτελεστή: έναν διαχειριστή έργου ή έναν προγραμματιστή. Προφανώς, ένας προγραμματιστής Ιστού καταλαβαίνει περισσότερα σχετικά με τη δημιουργία ιστοσελίδων παρά ο ιδιοκτήτης μιας καφετέριας ή μιας οδοντιατρικής κλινικής. Επομένως, θα πρέπει να περιγράψει το έργο.

Αυτό δεν σημαίνει ότι ο πελάτης εξαφανίζεται και εμφανίζεται στο τέλος να γράφει: «Zbs, εγκρίνω». Θα πρέπει επίσης να συμμετέχει στη διαδικασία:

Φυσικά, ο πελάτης μπορεί να σχεδιάσει τη δική του εκδοχή των τεχνικών προδιαγραφών. Ίσως αυτό να επιταχύνει τη διαδικασία δημιουργίας των τελικών τεχνικών προδιαγραφών. Ή ίσως το αποτέλεσμα θα είναι σκουπίδια που θα πεταχτούν κρυφά στα σκουπίδια.

Γράψε καθαρά και με ακρίβεια

Αυτή η συμβουλή απορρέει από τον κύριο στόχο των όρων αναφοράς - «Βεβαιωθείτε ότι ο πελάτης και ο ανάδοχος κατανοούν σωστά ο ένας τον άλλον».

Οι όροι αναφοράς δεν πρέπει να περιέχουν ποιοτικά επίθετα: όμορφο, αξιόπιστο, μοντέρνο. Δεν μπορούν να γίνουν ξεκάθαρα κατανοητές. Ο καθένας έχει τις δικές του αντιλήψεις για την ομορφιά και τον μοντερνισμό.

Κοίτα. Κάποιος θεώρησε ότι αυτό το σχέδιο ήταν όμορφο και το επέτρεψε να χρησιμοποιηθεί στον ιστότοπό του:


Το ίδιο συμβαίνει με ασαφείς διατυπώσεις που δεν σημαίνουν τίποτα από μόνες τους:

  • Ο πελάτης πρέπει να αρέσει στον ιστότοπο.Κι αν έχει κακή διάθεση;
  • Ο ιστότοπος πρέπει να είναι βολικός.Τι σημαίνει? Βολικό για τι;
  • Ο χώρος πρέπει να αντέχει βαριά φορτία. 10 χιλιάδες επισκέπτες; Ή 10 εκατομμύρια;
  • Υψηλής ποιότητας περιεχόμενο ειδικών.Λοιπόν, καταλαβαίνεις την ιδέα.

Ελέγξτε για ασάφειες στο κείμενο. Αν υπάρχει, ξαναγράψτε το. Η διατύπωσή σας πρέπει να είναι σαφής και ακριβής:

  • Ο ιστότοπος πρέπει να φορτώσει γρήγορα → Οποιαδήποτε σελίδα στον ιστότοπο πρέπει να έχει περισσότερους από 80 πόντους στο Google PageSpeed ​​Insights.
  • Βαριά φορτία → 50 χιλιάδες επισκέπτες ταυτόχρονα.
  • Η κύρια σελίδα εμφανίζει μια λίστα άρθρων Η κύρια σελίδα εμφανίζει μια λίστα με τα τελευταία 6 δημοσιευμένα άρθρα.
  • Μινιμαλιστική φιλική προς το χρήστη διεπαφή συνδρομής → πεδίο "Αφήστε το e-mail σας" και κουμπί "Εγγραφή" → *σχεδιασμένο σκίτσο*.

Τακτοποιήσαμε τη διατύπωση, ας περάσουμε στη δομή.

Δώστε γενικές πληροφορίες

Όλα τα μέλη της ομάδας πρέπει να κατανοούν σωστά τι κάνει η εταιρεία και ποιο είναι το κοινό στο οποίο απευθύνεται. Για να μην μπερδευτεί κανείς, είναι καλύτερο να το γράψετε στην αρχή των όρων εντολής.

Αξίζει επίσης να υποδείξετε τον σκοπό του ιστότοπου και να περιγράψετε τη λειτουργικότητά του με λίγα λόγια - για να μην καταλήξετε σε ένα ηλεκτρονικό κατάστημα αντί για ένα ιστολόγιο.

Εξηγήστε τους δύσκολους όρους

Ο πρώτος κανόνας των όρων αναφοράς είναι ότι πρέπει να είναι κατανοητός σε όλους για τους οποίους προορίζεται. Εάν πρόκειται να χρησιμοποιήσετε όρους που ο πελάτης σας, ο ιδιοκτήτης ενός καταστήματος παιδικών παιχνιδιών, μπορεί να μην καταλαβαίνει, φροντίστε να τους εξηγήσετε. Σε καθαρή γλώσσα, όχι copy-paste από τη Wikipedia.


Περιγράψτε τα εργαλεία και τις απαιτήσεις φιλοξενίας

Φανταστείτε ότι ξοδέψατε 2 μήνες για να δημιουργήσετε έναν υπέροχο ιστότοπο. Κάθε στάδιο συντονίστηκε με τον πελάτη - ήταν ενθουσιασμένος. Και τώρα ήρθε η ώρα να παραδώσουμε το έργο. Εμφανίζετε τον πίνακα διαχείρισης και ο πελάτης φωνάζει: «Τι είναι αυτό; Modex;! Νόμιζα ότι θα το έκανες στο WordPress!»

Για να αποφύγετε τέτοια προβλήματα, περιγράψτε τα εργαλεία, τους κινητήρες και τις βιβλιοθήκες που χρησιμοποιούνται. Ταυτόχρονα, αναφέρετε τις απαιτήσεις φιλοξενίας σας. Ποτέ δεν ξέρεις, θα το κάνεις σε PHP - και ο πελάτης έχει διακομιστή στο .NET.

Καταγράψτε τις απαιτήσεις για τη λειτουργία του ιστότοπου

Ο ιστότοπος πρέπει να λειτουργεί σε όλα τα τρέχοντα προγράμματα περιήγησης και σε όλους τους τύπους συσκευών. Ναι, αυτό είναι προφανές για κάθε προγραμματιστή και κάθε πελάτη. Αλλά είναι καλύτερο να γράψετε για να προστατεύσετε τον πελάτη από κακή πίστη.


Γράψε εδώ τις απαιτήσεις για ταχύτητα φόρτωσης ιστότοπου, αντίσταση φορτίου, προστασία από επιθέσεις χάκερ και παρόμοια.

Καθορίστε τη δομή του ιστότοπου

Πριν ξεκινήσετε να σχεδιάζετε το σχέδιο και τη διάταξη, πρέπει να συμφωνήσετε για τη δομή του ιστότοπου με τον πελάτη.

Μιλήστε με τον πελάτη και μάθετε τι χρειάζεται. Συγκεντρώστε προγραμματιστές, ειδικούς SEO, εμπόρους μάρκετινγκ, αρχισυντάκτη - και αποφασίστε ποιες σελίδες χρειάζονται στον ιστότοπο. Σκεφτείτε πώς θα συνδεθούν μεταξύ τους, από ποια μπορείτε να μεταβείτε.

Μπορείτε να εμφανίσετε τη δομή με μια λίστα, μπορείτε να σχεδιάσετε ένα μπλοκ διάγραμμα. Οπως επιθυμείς.


Αυτό είναι ένα από τα πιο σημαντικά στάδια της εργασίας στον ιστότοπο. Η δομή είναι το θεμέλιο. Εάν δεν είναι επιτυχής, ο ιστότοπος θα αποδειχθεί στρεβλός.

Εξηγήστε τι θα υπάρχει σε κάθε σελίδα

Ο πελάτης πρέπει να καταλάβει γιατί χρειάζεται κάθε σελίδα και ποια στοιχεία θα υπάρχουν σε αυτήν. Υπάρχουν δύο τρόποι για να το δείξετε αυτό.

Πρωτότυπο- έναν πιο οπτικό και ξεκάθαρο τρόπο. Ο ανάδοχος σχεδιάζει σκίτσα κάθε σελίδας και τα επισυνάπτει στους όρους αναφοράς. Ο πελάτης βλέπει πώς θα είναι η διεπαφή του μελλοντικού του ιστότοπου και λέει τι του αρέσει και τι πρέπει να αλλάξει.


Αριθμός στοιχείων- μια χαλαρή εναλλακτική λύση στο πρωτότυπο. Απλώς γράψτε τι μπλοκ πρέπει να υπάρχουν στη σελίδα και τι κάνουν.


Περιγράψτε τα σενάρια χρήσης του ιστότοπου

Εάν δημιουργείτε κάποιο είδος μη τυπικής διεπαφής, δεν αρκεί μόνο η εμφάνιση της δομής και των μικρογραφιών της σελίδας. Είναι σημαντικό ολόκληρη η ομάδα εκτέλεσης και ο πελάτης να κατανοήσουν πώς θα χρησιμοποιήσουν οι επισκέπτες τον ιστότοπο. Τα σενάρια είναι υπέροχα για αυτό. Το διάγραμμα του σεναρίου είναι πολύ απλό:

  • Ενέργεια χρήστη.
  • Απόκριση ιστότοπου.
  • Αποτέλεσμα.


Φυσικά, εάν φτιάχνετε μια τυπική επαγγελματική κάρτα ή σελίδα προορισμού, δεν χρειάζεται να γράψετε σενάρια. Αλλά αν υπάρχουν κάποιες διαδραστικές υπηρεσίες στον ιστότοπο, είναι πολύ επιθυμητό.

Διαβάστε περισσότερα για τις περιπτώσεις χρήσης στη Wikipedia.

Προσδιορίστε ποιος είναι υπεύθυνος για το περιεχόμενο

Ορισμένοι προγραμματιστές δημιουργούν αμέσως έναν ιστότοπο με περιεχόμενο. Άλλοι τοποθετούν ψάρια. Άλλοι πάλι μπορούν να γράφουν κείμενα, αλλά με επιπλέον χρέωση. Συμφωνήστε σε αυτό στην ακτή και σημειώστε στους όρους αναφοράς τι περιεχόμενο πρέπει να προετοιμάσετε.


Είναι αρκετά δύσκολο να βρεθούν αντικειμενικά κριτήρια για την αξιολόγηση της ποιότητας των κειμένων. Είναι καλύτερα να μην γράψετε τίποτα άλλο εκτός από «Υψηλής ποιότητας, ενδιαφέρον και πωλητικό περιεχόμενο που είναι χρήσιμο για το κοινό-στόχο». Είναι σκουπίδια, κανείς δεν τα χρειάζεται.

Είναι χρήσιμο να προσδιορίσετε ότι όλο το περιεχόμενο πρέπει να είναι μοναδικό. Μια άλλη προστασία για τον πελάτη από αδίστακτους ερμηνευτές.

Περιγράψτε το σχέδιο (αν μπορείτε)

Όπως και με το κείμενο, είναι δύσκολο να βρεθούν αντικειμενικά κριτήρια για την αξιολόγηση του σχεδιασμού της ιστοσελίδας. Εάν εσείς και ο πελάτης έχετε συμφωνήσει σε έναν συνδυασμό χρωμάτων, σημειώστε τον. Εάν έχει ένα βιβλίο επωνυμίας στο οποίο αναφέρονται οι γραμματοσειρές, υποδείξτε τις επίσης.

Δεν χρειάζεται να γράφουμε για όμορφο και μοντέρνο design. Δεν σημαίνει τίποτα, δεν έχει δύναμη και γενικά ουφ.


Αντί για συμπέρασμα: η δομή των όρων αναφοράς

Η δομή των τεχνικών προδιαγραφών θα είναι διαφορετική για διαφορετικές εργασίες. Είναι ανόητο να κάνεις τις ίδιες τεχνικές προδιαγραφές για ένα νέο κοινωνικό δίκτυο και μια σελίδα προορισμού για τη χονδρική πώληση καρότων. Αλλά γενικά χρειάζεστε αυτές τις ενότητες:

  • Πληροφορίες για την εταιρεία και το κοινό-στόχο, τους στόχους και τους στόχους του ιστότοπου.
  • Ένα γλωσσάρι όρων που μπορεί να μην είναι σαφές στον πελάτη.
  • Τεχνικές απαιτήσεις για τη διάταξη και τη λειτουργία του ιστότοπου.
  • Περιγραφή των τεχνολογιών που χρησιμοποιούνται και λίστα απαιτήσεων φιλοξενίας.
  • Λεπτομερής δομή του ιστότοπου.
  • Πρωτότυπα σελίδων ή περιγραφές στοιχείων που πρέπει να υπάρχουν σε αυτές.
  • Σενάρια για χρήση μη τυπικής διεπαφής (προαιρετικό).
  • Λίστα περιεχομένου που δημιουργεί ο προγραμματιστής.
  • Απαιτήσεις σχεδιασμού (προαιρετικό).
  • Κανόνες για τη σύνταξη Προδιαγραφών Απαιτήσεων Λογισμικού. Το SRS είναι το επόμενο βήμα στην εξέλιξη των τεχνικών προδιαγραφών. Απαιτείται για μεγάλα και πολύπλοκα έργα.
  • Πρότυπα και πρότυπα τεχνικών προδιαγραφών για ανάπτυξη λογισμικού. Περιγραφές διαφόρων GOST και μεθοδολογίες για τη δημιουργία τεχνικών προδιαγραφών.

Αυτό είναι το τέλος του μέρους που έγραψα. Αλλά υπάρχει ένα άλλο - σχόλια από ειδικούς που βοήθησαν στη δημιουργία του οδηγού. Διαβάστε το, έχει και ενδιαφέρον.

Σχόλια προγραμματιστή

Μίλησα με αρκετούς προγραμματιστές για να μάθω πώς δημιουργούν τεχνικές προδιαγραφές. Τους περνάω το μικρόφωνο.

Πρώτα απ 'όλα, ο πελάτης χρειάζεται τεχνικές προδιαγραφές - για να καταλάβει πώς θα είναι η ιστοσελίδα του και σε τι θα δαπανηθούν τα χρήματα. Αν γίνει κάτι λάθος, μπορεί να ανατρέξει στις τεχνικές προδιαγραφές και να ζητήσει να γίνει εκ νέου.

Η τεχνική προδιαγραφή συντάσσεται από τον διαχειριστή έργου αφού επικοινωνήσει με τον πελάτη και συζητήσει την εργασία με τον σχεδιαστή.

Οι μεγάλοι πελάτες συχνά ζητούν πολύ λεπτομερείς τεχνικές προδιαγραφές, οι οποίες περιγράφουν κάθε κουμπί. Στις μικρές εταιρείες, αντίθετα, δεν αρέσουν τα προσεγμένα έγγραφα 100 σελίδων. Είναι μια μεγάλη ανάγνωση και είναι εύκολο να χάσετε κάτι σημαντικό. Πιο συχνά κάνουμε συνοπτικές τεχνικές προδιαγραφές 10–15 σελίδων.

Δηλώνουμε:

  • Πληροφορίες για την εταιρεία και τον σκοπό του ιστότοπου.
  • Απαιτήσεις για σχέδιο, χρωματικό σχέδιο.
  • Τεχνολογίες και CMS που χρησιμοποιούνται.
  • Ποιος παράγει το περιεχόμενο - εμείς ή ο πελάτης.
  • Η δομή του ιστότοπου σε κάθε σελίδα.
  • Περιγραφές κάθε σελίδας. Δεν φτιάχνουμε πρωτότυπα, αλλά καθορίζουμε ποια στοιχεία πρέπει να υπάρχουν στη σελίδα και πώς θα λειτουργούν.

Οι 2 τελευταίες ενότητες είναι οι πιο σημαντικές. Είναι αυτοί που παρέχουν μια κατανόηση για το πώς θα είναι ο ιστότοπος και πώς θα λειτουργεί.

Ένα πολύ σημαντικό σημείο - δεν μπορείτε απλώς να δώσετε τους όρους αναφοράς στους προγραμματιστές και να ελπίζετε ότι θα κάνουν τα πάντα καλά. Οι τεχνικές προδιαγραφές είναι μια λίστα απαιτήσεων για τον ιστότοπο· δεν μπορούν να αντικαταστήσουν την επικοινωνία. Είναι σημαντικό να βεβαιωθείτε ότι κάθε μέλος της ομάδας κατανοεί τον γενικό στόχο και ότι δεν εκτελεί απλώς εργασίες εν κινήσει. Εάν κάτι είναι ασαφές, είναι απαραίτητο να εξηγήσετε, να συζητήσετε και να δώσετε λεπτομερή σχόλια.

Στη ζωή, συμβαίνει συχνά ο άνθρωπος να μην μπορεί να εξηγήσει τι θέλει, ακόμα και σε καθημερινά πράγματα. Όταν πρόκειται να εξηγήσετε τα «θέλω» σας σε έναν προγραμματιστή, ένα άτομο απλώς πέφτει σε λήθαργο.

Στην ιδανική περίπτωση, οι τεχνικές προδιαγραφές θα πρέπει να συντάσσονται από τον πελάτη - μόνο αυτός ξέρει τι χρειάζεται. Αλλά στην πράξη, λόγω της χαμηλής ικανότητας του πελάτη στον τομέα 1C, αυτό πρέπει συχνά να γίνει από τον ανάδοχο. Ο πελάτης εκφράζει προφορικά τις ανάγκες του και ο προγραμματιστής (σύμβουλος) τις θέτει γραπτώς.

Γιατί χρειάζεστε τεχνικές προδιαγραφές;

Οποιαδήποτε, ιδανικά, θα πρέπει να συνοδεύεται από τεχνικές προδιαγραφές. Αυτό είναι, πρώτον, ένας σαφής ορισμός της αποστολής, των προθεσμιών και της μεθόδου υλοποίησης. Δεύτερον, πρόκειται για ένα έγγραφο με τη βοήθεια του οποίου επιλύονται όλα τα αμφιλεγόμενα ζητήματα στο μέλλον. Το αν θα γράψω τεχνικές προδιαγραφές ή όχι είναι, φυσικά, δική σας δουλειά· προσωπικά, οι τεχνικές προδιαγραφές διευκολύνουν την εργασία μου και την επικοινωνία με τον πελάτη.

Λάβετε 267 μαθήματα βίντεο στο 1C δωρεάν:

Τι πρέπει να περιέχουν οι όροι αναφοράς;

Εκείνοι. η εργασία πρέπει να περιέχει:

  • στόχος— το πρόβλημα που θα λύσουμε με την εφαρμογή αυτής της προδιαγραφής·
  • περιγραφή— περίληψη των επερχόμενων βελτιώσεων·
  • μέθοδος υλοποίησης— λεπτομερής περιγραφή των μεθόδων για την επίλυση του στόχου. Σε αυτό το σημείο, είναι απαραίτητο να περιγράψουμε όλες τις αποχρώσεις της εργασίας στη γλώσσα του προγραμματιστή: τι είδους εργασίες δημιουργούμε/επεξεργαζόμαστε, πώς πρέπει να μοιάζει η διεπαφή κ.λπ. Εάν δεν μιλάτε "γλώσσα προγραμματιστή", αλλά "έχετε ακούσει κάτι", είναι καλύτερα να μην προσπαθήσετε να γράψετε σε μια τεχνική γλώσσα - αποδεικνύεται ότι είναι αρκετά διασκεδαστικό. Η περιγραφή πρέπει να είναι ξεκάθαρη και να μην προκαλεί ερωτήματα. Μπορεί επίσης να περιέχει ένα παράδειγμα εφαρμογής παρόμοιας λύσης σε άλλη περιοχή.
  • αξιολόγηση της απόδοσης- ένα πολύ σημαντικό σημείο, μια περιγραφή του κόστους εργασίας.

Υπάρχουν επίσης κρατικά πρότυπα για τη σύνταξη τεχνικών προδιαγραφών - GOST. Στην πράξη, χρησιμοποιούνται σπάνια, αλλά μερικές φορές ο πελάτης επιμένει σε αυτό.

Από την εμπειρία, κατά την παράδοση εργασίας, πολύ συχνά προκύπτουν καταστάσεις όπως «σας είπαμε τότε...», που δεν είναι πολύ ευχάριστο και συχνά πρέπει να επαναλάβετε ολόκληρη την εργασία. Επομένως, μια καλογραμμένη τεχνική προδιαγραφή κάνει τη ζωή πολύ πιο εύκολη και για τα δύο μέρη.

Παραδείγματα και δείγματα τεχνικών προδιαγραφών για το 1C

Μια μικρή επιλογή που βρήκα δωρεάν διαθέσιμη στο Διαδίκτυο. Ξεκινώντας από τα πιο απλά και προσιτά έως αρκετά πολύπλοκα έγγραφα.




Μπλουζα