Процессы веб-разработки, которые не очень заметны, но существенно влияют на качество полученного результата

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cтатьи по теме:

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

Тематические технологии:

Язык программирования Ruby
Фреймворк Ruby on Rails
PostgreSQL — объектно-реляционная СУБД
Поисковая система ElasticSearch
СУБД Redis
Язык программирования Go
Язык программирования Python
Язык разметки HTML
CSS — каскадные таблицы стилей
Язык программирования JavaScript
Библиотека React
Библиотека MobX
Библиотека MobX State Tree
Система сборки WebPack
Платформа NodeJS
Red Hat Enterprise Linux