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