В последнее время я много обсуждал с ИТ-менеджерами нескольких довольно крупных организаций вопрос об управлении их активами. Один из них рассказал о своем “правиле числа π”. Думаю, оно заслуживает того, чтобы им поделиться. Эта буква греческого алфавита обозначает геометрическую константу, равную 3,14159.
Правило очень простое. Каждый раз, когда консультант или кто-то из сотрудников сообщает вам, сколько что-то будет стоить или сколько времени займет реализация этого что-то, умножайте все цифры на число π. Если некто утверждает, будто проект займет два месяца, то в действительности потребуется немногим больше шести. Ну, и так далее.
Я от души посмеялся над этим правилом, а потом задумался. Почему ИТ-специалисты выглядят столь некомпетентными при оценке затрат и сроков выполнения работы? Может быть, они в принципе неспособны сделать это точнее? У меня, конечно, были генеральные подрядчики, которые принадлежали не к самой лучшей части человечества. Но, полагаю, я должен считать себя счастливчиком, поскольку они выбивались из графика лишь на несколько дней. И никогда сроки не приходилось увеличивать в три с лишним раза.
Разумеется, все мы читали о мифических человеко-месяцах, изучали и другие труды, в которых утверждается, будто чем больше разработчиков участвует в проекте, тем дольше он будет осуществляться. Но речь не об этом.
Может быть, это происходит потому, что в действительности ИТ-специалисты просто хотят услужить своим клиентам и, не раздумывая, принимают на себя завышенные обязательства, недооценивая объем работ. Или, возможно, это происходит потому, что конечный продукт представляется недолговечным. Я хочу сказать, что работа программистов совсем не похожа на труд строительной бригады, которая возводит мост или сооружает новое офисное здание.
Наверное, я излишне остро воспринимаю все, что относится к этим проблемам, поскольку сам должен выполнять все задания в строго определенные сроки. Если я их хоть раз нарушу, кто-то другой будет вынужден заполнить образовавшуюся брешь в работе редакции. Ведь надо, чтобы журнал был отпечатан к установленному сроку или статья выложена в интернет в заданное время. Могу с гордостью сказать, что я всегда соблюдал сроки, кроме тех случаев, когда оказывался в нестандартной ситуации.
Но если речь заходит об ИТ-проектах, сроки ассоциируются, скорее, с неким ориентиром, чем с жестко фиксированной датой. Отчет не готов? Ну, ладно, не беспокойтесь, мы можем недельку подождать. Или противоположный случай. Ваш босс дает вам заведомо мало времени на выполнение работы. Вы с ней справляетесь к заданному сроку. И тут он говорит, что вовсе не рассчитывал получить ее сегодня, что у него не будет времени ознакомиться с ней раньше, чем на следующей неделе. Господи, как вы будете себя чувствовать после этого, если сделали все возможное и невозможное, чтобы все выполнить в срок?
Конечно, иногда вы бессильны. Люди совершают ошибки, в программах сидят “жучки”, настройка оборудования потребовала больше времени, чем предполагалось, собака сжевала документы, с которыми вы решили поработать дома, и т. д. Какие-то задержки разработчики могут объяснить желанием добавить “всего одну функцию” прежде, чем завершить работу над программным кодом и передать его в производство. Их кто-нибудь просил добавлять эту функцию? Скорее всего, нет. Они проявили инициативу, поскольку в тот момент это показалось им хорошей идеей.
Поверьте, еще когда я обучал студентов по специальности “компьютерные сети”, я уже слышал все эти истории от тех, кто опаздывал со сдачей домашнего задания. (надо сказать, что я не давал им спуску. В конце концов, срок есть срок. Большинство из них совершало подобную ошибку только единожды, и в дальнейшем мы прекрасно ладили).
Если мы хотим получить более реалистичные прогнозы, то обязаны тщательнее просчитывать, с какими проблемами могут столкнуться наши проекты. Кроме того, мы должны иметь возможность обсудить ситуацию как с начальством, так и с подчиненными, едва только заметим первые признаки намечающегося отставания от сроков или попыток добавить новую функцию.
В следующий раз, если у вас спросят, когда вы закончите то, над чем сейчас работаете, вспомните о “правиле пи” и немного поразмышляйте на эту тему, прежде чем давать ответ.
