Newsgroup: it.lavoro.informatica
Titolo: 5 modi per fallire...

Ciao a tutti,
vi segnalo il seguente articolo di Joel Spolsky apparso su Inc. Magazine.
Lo reputo decisamente interessante, specialmente la parte sulle 40 ore 
(ma anche quella sui trichechi non è male). L'articolo lo trovate qui: 
http://www.inc.com/magazine/20071101/how-hard-could-it-be-five-easy-ways-to-fail.html?partner=fogcreek
Lo incollo comunque di seguito per chi non volesse seguire il link.
Ciao,
Giulio
- - - -
*How Hard Could It Be?: Five Easy Ways to Fail*
Nothing like a weak team or an unrealistic schedule to start a project 
off right
By: Joel Spolsky
A huge number of technology projects go wrong. This is news to no one. 
Whether you run a software company with a number of ongoing development 
efforts or you have a nontech company that hires consultants here and 
there to provide systems integration, chances are you've bumped up 
against this problem. Delays, blown budgets, and outright failures are 
so common in the software world, in fact, that it's hardly newsworthy 
when a project is years late and millions over budget.
In 2003, for example, I flew out to Los Angeles for one of those 
conferences that Microsoft (NASDAQ:MSFT) occasionally puts on for 
software developers. At the event, Microsoft made a lot of exciting 
announcements about some of the revolutionary new features coming out 
soon in the next version of Windows. Looking back at my notes, I see 
that one of the important new features was something called WinFS. I'll 
spare you the boring details, but basically WinFS proposed to combine 
the file system features of your operating system (storing files and 
folders on a hard drive) with database features (where you store 
individual data records for easy search and retrieval) into one big 
unholy file-and-database mishmash.
This was quite an ambitious undertaking. WinFS was in technical terms 
approximately the equivalent of rearranging the nation's transportation 
system to accommodate flying cars. Yes, it would put airlines out of 
business, and yes, every garage would need to be widened a bit to 
accommodate cars with wings, but hey, we oughta be able to deliver this 
in a year or so. Two years, tops.
Three years passed. A manager at Microsoft named Quentin Clark announced 
on his blog that WinFS simply could not be delivered on time, and that 
it was holding up the launch of Microsoft's latest operating system. So 
it was going to be delayed and shipped, maybe, as a feature in a future 
database--meaning that it was not going to combine the database and the 
file system, which was the only thing that made it interesting. So how 
can you tell when one of your technology projects is destined to be 
another WinFS? Here's my five-step guide to ensure software failure:
Mistake No. 1: Start with a mediocre team of developers.
Designing software is hard, and unfortunately, a lot of the people who 
call themselves programmers can't really do it. But even though a bad 
team of developers tends to be the No. 1 cause of software project 
failures, you'd never know it from reading official postmortems. In all 
fields, from software to logistics to customer service, people are too 
nice to talk about their co-workers' lack of competence. You'll never 
hear anyone say "the team was just not smart enough or talented enough 
to pull this off." Why hurt their feelings? The simple fact is that if 
the people on a given project team aren't very good at what they do, 
they're going to come into work every day and yet--behold!--the software 
won't get created. And don't worry too much about HR standing in your 
way of hiring a bunch of duds. In most cases, I assure you they will do 
nothing to prevent you from hiring untalented people.
Mistake No. 2: Set weekly milestones.
Say you're remodeling your kitchen. That guy you hired to do the work 
has done a lot of kitchens before, and can estimate the cost of the job 
without having detailed blueprints. But software developers are building 
things that they've never built before. If they had, they'd just sell 
you another copy of the CD-ROM. So rough estimates are impossible. They 
need to draw up detailed plans before they start writing code. Whether 
you're the customer or the developers' manager, your job is to make sure 
they come up with that blueprint. When you ask developers for one, 
however, many of them will respond by creating a schedule that breaks 
pieces of the process into weeks. This may seem perfectly reasonable, 
but it's not. If you let a software team submit a schedule with big 
chunky estimates of time (by big I mean more than two days of work), you 
can be almost certain that they're not considering every detail that 
needs to be implemented, and those details will add up to a huge delay.
Mistake No. 3: Negotiate the deadline.
What's worse than accepting a schedule that breaks down a software 
project by the week? Demanding that a team commit to completing its work 
much sooner than forecast. In my experience, most developers are 
optimists and will take your cue and engage in split-the-difference 
bargaining. You'll have a nice, agreed-upon schedule that you'll never 
stick to.
Think of it in these terms: Mama walruses deliver their calves at the 
end of a 15- to 16-month pregnancy. You might ask the mother to commit 
to 15 months and she might say, "No problem!" Or you might say, "Fifteen 
months? Are you crazy? We need this in eight months!" Of course, 
haggling like this can't possibly make things happen any faster, and 
even if you get the walrus to agree to an eight-month timetable, I'll 
let you in on a little secret: It'll never happen. You can have a 
schedule that says 11 months, but you'll still ship in 15 months, 
because that is how long it takes to make a baby walrus. Sixteen, sometimes.
Mistake No. 4: Divide tasks equitably.
Here's a great way to torpedo any project. Make a list of all the work 
people have to do, and then reassign things to different people to 
balance the project. If Mary has too much work, give some of her tasks 
to John. This sounds completely sensible, so you won't be challenged.
But I promise you, in the long run it's sure to cause problems. That's 
because when one developer steps in to replace another, it's reasonable 
to assume that the new one will work at about one-tenth the speed. 
John's going to have to spend untold hours figuring out all the things 
that Mary already knows about her area of code. And John can't fix 
Mary's bugs as fast as Mary can because Mary knows where all the hidden 
traps are.
Mistake No. 5: Work till midnight.
Let's say a project should take six months at 40 hours a week to 
complete. If you told everybody to work 60 hours a week, you could 
finish the development in four months flat. The software team might even 
embrace this challenge because it will make them look like heroes ("How 
great is that Walrus team? They're here every weekend!"). This should 
work, right? Guess again. There's a whole body of literature 
establishing that working more hours doesn't produce software any 
faster. Edward Yourdon, the software entrepreneur and author, dubbed 
this kind of project the "death march."
Software development takes immense intellectual effort. Even the best 
programmers can rarely sustain that level of effort for more than a few 
hours a day. Beyond that, they need to rest their brains a bit, which is 
why they always seem to be surfing the Internet or playing games when 
you barge in on them.
Compelling them to spend even more hours sitting in front of a computer 
won't really translate into more output--or if it does, it will be the 
wrong kind of output. When their brains are completely fried, software 
developers are almost certainly going to do more damage than good, 
writing unusable code and introducing bugs galore. And if you do ban the 
Internet and multiplayer games to force them to keep writing code past 
their natural bedtimes, well, they'll probably start quitting on you. 
Running a death march is not the only way to make a project late and a 
budget buster. But it is a surefire way to do so.
If these are all the ways you can go wrong, how can you ensure that a 
project actually goes right? First, you have to hire superstars. At Fog 
Creek, we tend to review about 400 candidates for every full-time hire, 
because the best developers can be 10 times as productive as the merely 
excellent developers.
Second, demand fine-grained time estimates from the developers. Yes, 
it's difficult for developers to predict how long it will take to build 
a new application. That's why they need to create a reliable blueprint 
before every project.
Once you have that schedule in hand, don't try to push up the deadline. 
If the project can't be completed in what you consider to be a 
reasonable amount of time, the answer is not to negotiate a 
better-sounding schedule. The answer is to get more resources, move back 
your ship date, or remove features.
As a project gets going, you'll at times be tempted to reassign work. 
But reassign it with care. It takes a long time for new developers to 
get up to speed on someone else's code. I think it's good to rotate 
developers through different jobs so that you don't have any 
irreplaceable individuals, but I do this cautiously and build an extra 
three weeks into the schedule for the incoming developer who's learning 
the new code, and an extra week for the outgoing developer who is 
teaching the code to the new person.
Finally, encourage your staff to work a sane 40 hours per week. 
Seriously. Except for occasional, very short bursts of activity to meet 
a deadline, we at Fog Creek work eight-hour days. In the technology 
world, it's better to view a big project as a marathon, and not a sprint.
Joel Spolsky is the co-founder and CEO of Fog Creek Software in New York 
City and the host of the popular Joel on Software blog.

 Ciao a tutti,
la enron fallisce !
la parmalat no !
felice_pago
.
--------------------------------
Inviato via 
http://arianna.libero.it/usenet/

 (ma anche quella sui trichechi non è male). L'articolo lo trovate qui: 
[SNIP]
Forse negli stati uniti sara' vero quello che scrive il tizio, ma in
Italia (e direi anche in Europa) le cose funzionano diversamente: il primo
 progetto al quale io ho lavorato che sia fallito (e per ora unico
progetto al quale
ho lavorato che sia fallito) e' stato quello dello scorso anno e non
e' fallito per alcuno dei problemi indicati in tale articolo. E' fallito
semplicemente perche' la multinazionale per rivendere quello che aveva
fatto ha partecipato ad una gara in Grecia classificandosi settima su
nove partecipanti alla gara => la fornitura allo stato greco per 
il sistema di lettura a distanza dei contatori elettrici se la e'
aggiudicata
un' altra azienda => il progetto non e' proseguito.
Tra l'altro forse i motivi riportati possono essere veri quando si
lavora a progetti che richiedono 10 sviluppatori per un anno o piu' (e
il progetto per lettura a distanza dei contatori magari rientrava in
questo ambito [solo che eravamo meno di 10 ed avevamo meno di 1 anno] ),
ma la maggior parte dei progetti a cui si lavora attualmente hanno durata
talmente limitata nel tempo e un numero di persone che ci lavorano
talmente 
basso che non direi che i punti indicati siano cosi' significativi
Ciao,
Marco.
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 basso che non direi che i punti indicati siano cosi' significativi
direi di no, soprattutto in Europa dove progetti che durano anni (ma
parlerei di programmi in questo caso) e team che facilmente superano le 20
persone sono all'odrine del giorno se non nelle start-up di sicuro
nell'ambito bancario, assicurativo e via dicendo.
Ciao
Luigi


 (ma anche quella sui trichechi non è male).
Abbiamo fatto gli errori 3, 4 e 5. Ora siamo nella... :-(((
M.

 nell'ambito bancario, assicurativo e via dicendo.
Sono ambiti in cui non ho praticamente lavorato (anche se negli ultimi
mesi lavoro in un ambito prevalentemente bancario ma mi occupo di un
"filone minoritario" all'interno dell'azienda [ovvero sempre
telecomunicazioni] ). Ho lavorato prevalentemente in ambito
telecomunicazioni o in ambiti universitari (e quindi a progetti che
somigliavano in qualche modo a progetti di ricerca o comunque erano
finanziati dall' Unione Europea).
E in tali ambiti i progetti a lungo termine sono un miraggio( forse , anzi
penso sicuramente, in ambito universitario qualche progetto ad ampio
raggio esiste ancora ma al solito sara' finanziato con fondi UE o comunque
sara' un progetto di ricerca o simili). 
Ciao,
Marco.


 cose che dice sono generalmente accettate.
Ok pero' sintetizziamo l'articolo:
1)Un progetto parte bene se alla base ci lavorano persone valide
2)Inutile richiedere tempi precisi per lo sviluppo di un progetto enorme
saranno necessariamente o sovrastimati o sottostimati
3)Forzare gli sviluppatori a creare stime che intrinsecamente saranno piu'
corte della realta' (uno sviluppatore giustamente si concentra sulla sua
parte come tutti gli altri, il pm dovrebbe avere la visione d'insieme e
non semplicemente scaricare la responsabilita' dei tempi sulle varie parti)
4)Non pensare che tutti gli sviluppatori sono uguali, ognuno hai i suoi
tempi, e i developer non sono tutti uguali e intercambiabili come pupazzi
-occorre a tutti un periodo di assestamente per riprendere il lavoro di un
altro
5)Far lavorare le persone ad orari assurdi li stanca e li demotiva e non
li rende affatto piu' produttivi.
Ora, sicuramente non sono gli unici fattori che fanno crollare un progetto
ma ditemi se avete qualche argomento contrario sul fatto che questi sono
senza dubbio fattori negativi per il successo. Non stara' dicendo cose
nuove ma ogni tanto e' bene fermarsi e riflettere sui motivi per cui la
maggior parte dei progetti ict vanno a finire male.


 maggior parte dei progetti ict vanno a finire male.
Nella mia esperienza decennale solo 1 progetto e' finito male (piu' un
altro paio di cui ho sentito parlare ma che non conosco in dettaglio per
cui
non so esattamente "perche'" siano finiti male). 
E i motivi per cui tale progetto e' finito male li ho indicati negli
altri post.
Ciao,
Marco
