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

    Литературы п управлению проектами написано много, но правильного ответа для того, самого животрепещущего, вопроса там нет. И скорее всего не будет. Я попытаюсь посвятить этот пост тому, чтобы максимально занудно описать причины печального положения людей, ищущих опоры и поддержки в своих попытках ответить на один из главнейших вопросов разработки ПО: сколько времени это займет?

Постановка задачи

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

Взгляд со стороны

    Одна из величайших преград во взаимопонимании людей спрашивающих и программистов отвечающих заключается в том, что люди спрашивающие представляют себе написание программного кода как процесс, тождественный производственному процессу чего-то материального. И что бы не говорили менеджеры(в попытках привлечь клиента), пытающиеся правдами и неправдами доказать, что планирование сроков при разработке ПО — дело точное и обычное, различие тут есть, а значит и подход должен быть иной.
    Беда в том, что эта она из тех ситуаций, когда люди предпочтут услышать приятную ложь, нежели неприятную правду. И если вы попробуете совершенно правдиво сказать клиенту, что вы не знаете сколько времени займет проект, и попытаетесь объяснить почему именно установление сроков невозможно, то скорее всего клиент уйдет к вашим конкурентам, назвавшим сроки. Однако и расстраиваться тут не следует — ваши конкуренты тоже не знают сроков.
    В этой ситуации можно понять каждого. Клиенту хочется дать денег и получить результат, ему искренне плевать как вы это сделаете, ему просто нужны гарантии, что вы это сделаете и сделаете к определенному сроку. Вам не хочется врать человеку, что достойно всяческих похвал. Вашим конкурентам просто хочется получить заказ. В итоге проблемы у всех: вы сидите без работы, клиент не получает проект вовремя, конкуренты получают показательный геноцид нервных клеток и уникальную возможность работать гораздо больше при том же самом бюджете.

Два процесса

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

Спекуляция временем

    Практически все заказчики не хотят работать с не детерминированной моделью поставок, и у них нет понимания того, что программный продукт, который они хотят получить не производится, а придумывается на ходу. А мыслительный процесс нормируется плохо. Но гарантий и определенности хочется все равно. Плохо также то, что большинство заказчиков не могут и не хотят понять этого. И объяснить это тяжело — вы бы сами поверили доводам одного человека о том, что ответа нет, когда рядом стоит еще 10 человек, которые этот ответ готовы дать?
    Спекуляция на угадывании срока уже давно и прочно закрепилась как инструмент конкуренции, а сам срок уже перестал что-то значить. Какой смысл определять то, что в принципе невозможно определить? Какой смысл говорить правду человеку, который ее не хочет слышать? Масла в огонь подливает еще и то, что для некоторых проектов, срок определить все же реально, в результате чего клиент, глядя на то, как ему быстро и четко настроили 1С или сделали промо-сайт, начинает думать, что подобный механизм оценки сроков будет работать и для других проектов…

Триумф пунктуальности

    Дойдя до этого места, определенный круг читателей возможно станет подозревать автора в низкой компетенции, которую он пытается оправдать путем выставления задачи определения сроков проекта в нерешаемом свете. Вовсе нет! Я никоим образом не отрицаю того, что определить срок сдачи проекта возможно. Но давайте будем честны с собой.
    Много ли программирования в создании однотипных сайтов-визиток/интернет-магазинов/андройд-клиентов? В случае отлаженного тех-процесса, где различия между проектами минимальны, сроки будут точны. При этом упускается из внимания то, что вся фаза проектирования уже фактически выполнена. Даже некоторые программисты ведутся на эту ситуацию, оставляя у себя в голове твердую уверенность в том, что во всех программных проектах оценка сроков — вещь реальная.
    Занимает ли ваш проект больше месяца-двух? Обычно на таких сроках ошибка не очень велика, проект небольшой и погрешности при измерениях времени такие же. Однако они есть — если вы закончили проект за полтора месяца вместо месяца или двух, то вы серьезно ошиблись. Ваш прогнозируемый срок не совпал с реальным — а что будет если экстраполировать его на проекты больше длительности?
    Если вы все же считаете, что определение точное сроков возможно, то либо вы гений, либо вам следует в порядке эксперимента сменить предметную область программирования, чтобы проверить, будут ли ваши прогнозы сбываться с той же точностью как и на текущем поле деятельности.

Что делать?

    Если вы хотите, чтобы ваш прогноз был если не точен, то хотя бы не оказался меньше реального срока разработки, то вариантов всего два — излишняя подстраховка и смена условий задачи.
    Первый подход — это классика, когда вы берете время разработки и умножаете его на… то число, которое подскажет ваша интуиция. Нельзя сказать, что этот метод плох, единственное в чем его можно упрекнуть, так это в неоптимальности. Однако в свете того, что величина сроков часто обратно пропорциональна вероятности получения проекта, универсальным этот метод назвать нельзя.
    Когда с увеличением сроков выгадать не удается, следует попробовать изменить условия проекта так, чтобы они были максимально приближены к имеющимся у вас наработкам или готовым решениям. Какую-то долю определенности это внесет. По хорошему этот метод нужно применять для всех проектов, публикуемых на фрилансе не-специалистами. Дабы повысить градус адекватности и сэкономить деньги этих же не-специалистов, а так же нервы специалистов.

Автор: PerlPower

Источник