Оценка - не угадайка

Оценка  -  не угадайка

   КРИТИЧНО ДЛЯ БИЗНЕСА  

Когда мы, разработчики программного обеспечения, устраиваем неразбериху, мы на полпути не останавливаемся  -  мы это делаем капитально. Возьмите, например, оценки. Обычное превышение оценок  -  это не пятьдесят и даже не сто процентов. Если мы срываем сроки, то уж сразу на 189 процентов. Ничего себе?!

А почему? Тому есть две простые причины: во-первых, то, для чего мы строим оценки, имеет очень мало общего с тем, что строим на самом деле, и, во-вторых, оценки мы строим по-глупому. И как бы там ни было, но мы обречены еще до начала создания прототипа. Сценарий вам известен: руководство запрашивает оценки длительности и стоимости. Вы оцениваете наилучшим образом, зная при этом, что можете и ошибиться. Но финансирование нужно, и отпугивать руководство тоже не хочется. Хуже всего здесь то, что к такому процессу все быстро привыкают. Мы отлично уживаемся с нереалистичными оценками  -  мы даже уже не принимаем их всерьез. А в массе мы все больше и больше сживаемся с тем, что в подавляющем большинстве выпуск коммерческих программ задерживается на годы и годы. И мы распускаемся и принимаем это правило для собственных разработок. И очень потом удивляемся, когда руководство приглашает работников со стороны для выполнения наших обязанностей. А все начинается с того, что руководство требует от нас оценок раньше, чем мы сами поймем, что, собственно, мы строим. Пока высшее и среднее руководство не будет готово воспринять реальность, а она требует некоторого периода неопределенности, мы не сможем выполнять проекты вовремя. На самом деле проект нужно разделить на две части. Первая фаза  -  двух-трехнедельный период тесного сотрудничества с пользователями для выяснения их требований, создания предварительных прототипов и вывода предварительных оценок. Вторая фаза включает от шести до восьми недель создания формальных прототипов, в течение которых предварительные оценки можно корректировать в пределах пятнадцати процентов в ту или другую сторону. Потом требуется около десяти недель на воплощение проекта и окончательное тестирование.

Работа с программным обеспечением всегда будет хаотическим процессом. Но если вы будете продолжать преследовать свою цель, вы никогда не внедрите систему. И потому придется выпускать продукт версиями. При необходимости можно поменять местами некоторые еще не воплощенные в код возможности версии 1 и вдруг оказавшиеся срочно необходимыми возможности, запланированные для версии 2. Это помогает предотвратить расползание области действия системы или приложения.

Лично я не люблю заниматься проектами, длящимися более шести месяцев. Если надо построить большую систему, разбейте ее на подсистемы, отнимающие по шесть месяцев. А потом назначьте одного или сколько нужно людей системными интеграторами для увязывания этих подсистем в одно целое.

Даже покомпонентная оценка не даст вам большего. Начните с подсчета количества форм, таблиц, групп возможностей и запросов, которые вы строите. Сделайте поправку полученной таким образом покомпонентной оценки на внешние факторы, влияющие на разработку. Учтите степень повторной используемости, стандарты, сложность обработки, размах архитектуры, используемые средства; проследите, выполняется ли распределенная обработка, и не забудьте проектную политику. Мы даем полномочия нашим пользователям.

Мы даем полномочия нашим разработчикам. Так почему бы не дать полномочия лидерам проектов? Мы возлагаем на них ответственность, но добиться успеха не даем. Руководители, вы меня слышите?

Кристина Комафорд, президент фирмы Corporate Computing, MCI Mail: 371-9004, CompuServe: 74603,3664, Internet: 74603.3664@compuserve.com, факс:(708)374-1124.

Кристина Комафорд