Распространенные мифы о разработке ПО

Четыре мифа о разработке программного обеспечения

В этой статье мы поговорим о мифах, которые часто встречаются в мире разработки программного обеспечения или веб-сайтов, веб-приложений и других элементов. Их всего четыре в нашем случае.

Первый миф заключается в том, что проект можно сделать быстро, качественно и дешево. Три параметра, которые мы должны выставить по максимуму, то есть мы должны сделать очень быстро, очень качественно и очень дешево. Это миф.

На самом деле вы можете достичь только двух из этих трех параметров. Вы можете сделать либо быстро и дешево, либо быстро и качественно, либо сделать качественно и дешево, но очень долго. Третий параметр всегда будет отставать, и вместе три вы не получите никогда.

Часто можно увидеть на различных биржах такую ситуацию: нужно сделать портал, сроки горят очень сильно и есть, например, двадцать тысяч. Такие вещи в таких рамках сделать не реально. Качество тоже можно заменить на параметр – объем проекта.

Второй миф – до начала проекта мы можем очень точно оценить проект. Это невозможно. Есть такое понятие, как «конус неопределенности». В начале проекта оценка находится в широком диапазоне, например, цена 100-200 тысяч рублей. Затем, когда мы определили ТЗ (учим составлять техническое задание на курсе создания ТЗ), можем уменьшить оценку, но не можем сказать точно, например, мы можем сделать оценку 150-200. То есть конус сузился. Чуть позже, после выполнения нескольких этапов мы можем еще уменьшить оценку. Но, опять же, на всех этих этапах мы не можем точно сказать, сколько это будет стоить. Можно, конечно, рискнуть и дать точную оценку, но скорее всего она не будет являться достоверной. При этом возникает два эффекта: либо клиент переплачивает, если исполнитель дал завышенную оценку, либо исполнитель платит из своего кармана, если дал заниженную оценку. Не оценивайте проект очень точно, это в принципе невозможно.

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

Четвертый миф – делаем все сразу. Можно делать все сразу, но вы получите не очень хороший результат. Вы должны понимать, что у вас есть главный функционал, а есть второстепенный. Старайтесь главный функционал сделать как можно раньше. Это лучше для заказчика и для вас. Второстепенный функционал лучше откладывать на потом. Разбейте свой проект на такие части, когда самое главное вы делаете в начале, и получаете сразу же, как можно раньше, и платите
за это деньги, чем делать все одним куском с ошибками, которые будут тестироваться только в конце, и сумма будет висеть значительная, что всех напрягает. Значит, нужно проект разбивать на части. Сделали часть, внедрили, протестировали, оплатили, приступили к следующей части. Это лучше в плане здоровья проекта и для заказчика тоже выгода в том, что он сразу получает главный функционал и внедряет его, система раньше запускается, и не нужно вносить большую предоплату. И для исполнителя уменьшаются риски, сразу тестируется функционал и исправляются
ошибки. Именно поэтапный подход позволяет заказчику внедрять новые изменения в проект. Он смотрит результат и может сказать, где не устраивает и что изменить. А если он получает большой монолитный кусок, внедрять изменения гораздо сложнее. Может оказаться, что много лишней работы сделано, и какой-то блок вообще не нужен.

Еще раз повторим эти 4 мифа: