Неочевидные процессы веб-разработки, которые существенно влияют на качество

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

Речь идёт по большей части о действиях, которые не имеют «на выходе» результатов, видимых невооруженным глазом. Или о проведении работ, целесообразность которых не очевидна Заказчику.

Неявные работы

Наиболее часто следующие процессы кажутся «ненужными»:

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

Разумеется, что никто не против выполнения этих процессов, покуда они не оплачиваются из бюджета проекта. Но так, конечно, не бывает, если мы рассматриваем профессиональную коммерческую разработку. За любые выполняемые работы Заказчик всегда платит: разработка программного обеспечения — это бизнес, любые «бесплатно» стоит интерпретировать как «уже включено в стоимость». Это очень банально и логично, однако вера в существование «бесплатного» настолько распространена, что сложно не написать об этом.

Но можно этого и не делать. Если вас не интересует результат. Михаил Жванецкий

Вариант, что можно не выполнять отдельные работы и при этом проект не пострадает, мы рассматривать не будем, так как это уже «из области фантастики» .

Осмечивание работ по веб-разработке

Если процесс запланирован, то его стоимость будет отражена в смете или в явном виде, или в виде неотъемлемой части других работ. И тут возможны 3 ситуации:

1. Вспомогательные процессы запланированы и указаны в смете в явном виде. Иногда это вызывает отторжение у заказчиков, особенно если смысл процессов непонятен. Если диалог конструктивен, то большая часть подобных возражений «снимается» после разъяснения целей процессов.
2. Вспомогательные процессы запланированы, но их стоимость заложена в другие работы, которые обладают более очевидными результатами выполнения. Тут возникает другая проблема — стоимость работ, в которые заложены неявные процессы, возрастает, а если имеет место сравнение цен нескольких поставщиков данных услуг, то это сравнение уже не в пользу поставщика, который изначально закладывает все нужные процессы в смету.
3. Вспомогательные процессы не запланированы и их стоимость в бюджет не заложена. В результате вышеописанные процессы либо не будут выполнятся вовсе (это часто приводит к провалу проекта), либо их выполнение «неожиданно» станет необходимым уже по ходу реализации, то есть потребует пересогласования бюджета и сроков в сторону увеличения.

На рынке имеют место все три подхода.

Нам близки первые два: первый — для объёмных по трудозатратам работ, а второй — для небольших по объёму. Это, конечно, «раздувает» бюджет, но зато уже в процессе выполнения работ не будет «неожиданностей», не потребуется пересогласование бюджета и заметно снижается риск провала проекта.

Третий подход еще часто называют «неполным осмечиванием», то есть включением в смету только тех работ, которые ожидаются заказчиком, а те работы которые не были включены в смету, но точно понадобятся, будут «сюрпризом». Такие неожиданности всегда неприятны, но чаще всего деваться от такого разработчика уже некуда — проект в активной фазе, часть бюджета израсходована и сроки «горят». Разумеется, что выявление скрытых работ в процессе реализации проекта вероятно и при следовании первым двум вариантам осмечивания, но в случае третьего варианта причина возникновения проблем проистекает из явного намерения исполнителя вести работу именно в таком стиле. На наш взгляд, это уже не партнёрское взаимодействие.