Январь 2019 — Заметка №6

В рамках антимонопольного кейса против Microsoft в 2000 году часть внутренних документов стала доступна публике. Один из этих документов — вот этот постмортем разработки первой версии MS Word для Windows: http://antitrust.slated.org/www.iowaconsumercase.org/011607/8000/PX08875.pdf

У MS уже был Word для Mac и они решили сделать версию для Windows. Разработка первой версии заняла 5 лет (c 1984 до 1989) и проект был признан провальным. Пост-мортем посвящен размышлениям, что же пошло не так.

Сам документ достаточно тяжело читать (плохой скан) и я его рекомендую только тем, кто действительно любит почитать чужие пост-мортемы. Выделить же хочу несколько цитат:

This would have worked out quite well had it not been for the excessive demands of the then Director of Applications Development, Jeff Harbors. Jeff continually hounded Ford for better schedules and more results. He treated the development schedule as a contract between the deve1opment team and himself and he really let us know when we did not live up to our end of the bargin. To make the situation worse, he questioned every estimate made on the schedule, resulting in a tighter schedule that could not be meet.

…

During a development team meeting in early March Jeff made perhaps his biggest mistake when he got up and told us that the Opus team was the worst team in Applications Development. This, combined with the long project duration, the continual pressure of being behind schedule, and the upsets in leadership, contributed to destroy the team’s spirit. This lack of spirit or team synergy is evident right up through the time when we finally did ship. The team became apathetic and burnt out.

…

The methods of scheduling used were fatally flawed. A schedule should be considered a tool used to predict a ship date, it should not be considered a contract by development. Because there was so much pressure to meet the schedule, development got into a mode which Chris Mason refers to as “infinite defects”. Developers get credit every time they can check a feature off, so they are more inclined to mark off their current feature and go on even though it really is not done. There was a prevailing attitude of the “testers will find it” when thinking about potential bugs in code being developed. In many cases they did find it, and that is what caused our stabilization phase to grow from the expected 3 months (which is a pretty random number anyway), to 13 months. Because every task was cut to the bare minimum, performance work that should have been done was neglected until the very end of the project, reducing what we could do in a reasonable amount of time.

…

The idea that a schedule is God leads to infinite defects, as explained above. Also, the belief that a schedule must be ambitious so that the development team will work hard is severely misguided.

Весь мой опыт говорит о том, что проекты без заданной цели и дедлайна проваливаются. Они “закисают”, застаиваются и начинают бесконечно тянуться. Обратная сторона — если на больших проектах давить сроки, воспринимать их как “контракт” и никогда не сдвигать, то есть шанс, что сделают полный отстой и проект также не будет завершен.

Где граница, которая отделяет дедлайн как полезную штуку для проекта от дедлайна как штуки, которая убивает проект? Сжатые сроки как способ создать здоровый стресс (когда мало времени мы все как правило становимся весьма креативными) и сжатые сроки как нереалистичные границы, которые всех демотивируют? Я не знаю и об этом точно стоит подумать.

Но две вещи я думаю уже стоит обозначить.

●↑