ΕΕΛ/ΛΑΚ - Λίστες Ταχυδρομείου

Re: με αφορμή τη ΔΕΗ: Ηθική , Διαγωνισμοί Δημοσίου , ΕΛ/ΛΑΚ

  • Subject: Re: με αφορμή τη ΔΕΗ: Ηθική , Διαγωνισμοί Δημοσίου , ΕΛ/ΛΑΚ
  • From: Konstantinos Margaritis <markos [ at ] codex [ dot ] gr>
  • Date: Mon, 5 Jul 2010 00:35:51 +0300
On Sunday 04 July 2010 20:58:19 Christos Ricudis wrote:
> , Dimitrios A Adamos wrote:
> > Και πάλι, δε βλέπω τι ανατρέπει το βασικό ισχυρισμό του Χρήστου;
> >
> > Αν οι υποψήφιοι ανάδοχοι είχαν αποφασίσει εξ αρχής να "κατέβουν" με
> > λύσεις open-source... τι λέτε να φωτογράφιζε η προκήρυξη (έστω με τον
> > ίδιο πρόχειρο τρόπο);
> 
> Παρα πολυ ενδιαφερον ερωτημα.
> 
> Και να το κανω λιγο πιο ενδιαφερον: Αραγε οι ευαισθησιες μας περι
> ανταγωνισμου και ελευθεριας και και και, θα ηταν ακριβως οι ιδιες εαν
> βλεπαμε ενα διαγωνισμο του οποιου οι τεχνικες προδιαγραφες απαιτουν
> RDBMS με υποστηριξη InnoDB tables και 64-bit λειτουργικο συστημα με
> εγγενη υποστηριξη virtualization, security compartmentation και
> high-availability clustering?

Προσωπική Εμπειρία: όχι. Συμμετείχα σε ακριβώς ένα τέτοιο έργο που _απαιτούσε_ 
το APLAWS (χείριστο, όσο δε φαντάζεστε, IMHO το χειρότερο έργο open source που 
έχω δουλέψει, κάντε ένα google να δείτε, απλά ήταν open source). Τελικά είδανε 
το φως και επιλέχτηκε άλλη λύση -επίσης πολύ μέτρια αλλά τουλάχιστον καλύτερη 
από την πρώτη. Αλλά ναι γίνεται, και όχι η αντίδραση δεν υπήρχε. Ο κάθε 
υποψήφιος ανάδοχος δεν θα κοιτάξει ΤΙ απαιτείται και αν είναι ελ/λακ ή όχι, θα 
κοιτάξει αν μπορεί να το παρέχει και αν όχι αν ξέρει κάποιον που μπορεί -ώστε 
να τον πάρει ως υπεργολάβο. Φυσικά ο υπεργολάβος αναλαμβάνει να καλύψει τις 
ανύπαρκτες προδιαγραφές με μαγικά, όπως και να ολοκληρώσει ένα έργο στο 
προδιαγεγραμμένο χρόνο με καθημερινές αλλαγές προδιαγραφών, 40 σελίδες bug 
reports για αλλαγή γραμματοσειρών και χρωμάτων χωρίς να τελειώσει το 
functionality testing και χωρίς καν να μπει σε πιλοτική λειτουργία το έργο. 
Φυσικά, πάμπολλες αλλαγές στη βάση, 2-3 φορές στο ίδιο αντικείμενο, μια one-
to-many relation να γίνεται many-to-many relation, και να επιμένουν ότι έτσι 
είναι το σωστό, ασχέτως αν για τον υπεργολάβο αυτό σημαίνει αλλαγή του  schema 
και κάπου 1000 γραμμές επιπλέον κώδικα (τουλάχιστον), με υλοποίηση σε 4-5 
μέρες, με κερασάκι στη τούρτα να παραδέχονται εκ των υστέρων -μετά την 
παρουσίαση- ότι τελικά σωστό ήταν το αρχικό one-to-many relation γιατί δεν 
είχαν καταλάβει ακριβώς πως λειτουργούν τα έντυπα των Τεχνικών Δελτίων, κλπ. 
Θα μπορούσα να συνεχίσω επ' άπειρον...

Κώστας

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