See section 4.6.5 and section 6.6 for more on this.
5.
We never know how long testing will take
(Aka
we don??™t know how many bugs are in the release
).
There are ways of finding out. See Chapter 18. Did you warn them how many there??™d be or how
long it would take? Did they want to know? Did the testers find bugs? Were they testing every day,
or was there extensive downtime as development tried to get a release to work? Were there enough
testers? Did you make your schedules unrealistically short? Did the testers agree to it? See section
4.6.5 in Chapter 4.
This is your problem. Deal with it by getting an estimate both of the number of bugs to be
found and the length of time it will take to find them. Look at section 18.10.
6.
It??™s too academic
(alternatively,
we??™re not NASA
)
.
It??™s true that some academic ideas don??™t scale to
industrial use, but the real reason is
they
don??™t (want to) understand either what you??™re proposing
to do or what will happen if you don??™t. (This argument is also the managerial equivalent of the
???
real men don??™t eat quiche???
argument in that such a manager believes himself/herself to be practical
and thus non-academic.) Don??™t expect senior management to repeat that line of defense to
customers or investors.
Bankruptcy is quite academic while it happens to someone else. Answer this by saying that
everything you are doing is industry-standard (privately ensure that any academic approaches
you might use are proven first).
Pages:
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85