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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

управление продуктамиуправление проектами
Статья опубликована в 2014 году

Тематические статьи

Ошибки при разработке сайтов: старт проекта без целей, задач и проектирования

Часто, когда встает вопрос о создании сайта, цели и задачи не формулируются или формулируются нечётко. В этом случае вы никогда не получите то, что хотели, так как разработчикам просто непонятно что именно вы хотите.

управление продуктами
управление проектами
Статья опубликована в 2014 году

Ошибки при разработке сайтов: субъективный подход к дизайну и стремление к самовыражению

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

управление продуктами
управление проектами
Статья опубликована в 2014 году

Ошибки при разработке сайтов: отсутствие аналитики и развития после запуска

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

управление продуктами
управление проектами
Статья опубликована в 2014 году

Как написать функциональное техническое задание?

Всё просто: нормальным русским языком описывайте нужные функции в формате сценария использования. Пункты ТЗ должны быть объективными, просто изложенными и элементарным способом проверяемыми требованиями.

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

управление продуктами
управление проектами
проектирование
Статья опубликована в 2019 и обновлена в 2020 году

Водопадная модель разработки

Водопадная модель разработки программного обеспечения — это процесс разработки, в котором все необходимые этапы проходят строго последовательно.

Разработка ПО по водопадной модели начинается со сбора и анализа требований, затем следует фаза проектирования и прототипирования. После завершения полного проектирования начинается этап программной реализации. После завершения этапа программирования разработанный продукт тестируется на соответствие требованиям. Затем осуществляется интеграция и запуск, после чего проект переходи в фазу поддержки и сопровождения.

управление проектами
управление продуктами
Статья опубликована в 2019 году

Итеративная модель разработки

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

Жизненный цикл проекта при итерационной разработке разбит на последовательность итераций. Каждая из этих итерации, по сути, является водопадным проектом в миниатюре, то есть включает в себя все ключевые процессы разработки ПО и результатом работы по каждой итерации обычно является пригодная для использования версия продукта.

управление продуктами
управление проектами
Agile
Статья опубликована в 2019 и обновлена в 2022 году

Создание дизайна сайта или веб‑приложения

Создание дизайна для сайта или веб‑приложения — это самый субъективно оцениваемый этап разработки, часто вызывающий сложности как на этапе постановки задачи, так и на этапе сдачи‑приёмки выполненных работ.

Задача этапа дизайна — разработка графических макетов интерфейса. К интерфейсу обычно выдвигаются вполне понятные технические требования — он должен быть понятен, удобен и позволять делать то, ради чего он создавался. В этой статье разберём основные подходы, позволяющие создать действительно качественный дизайн сайта.

дизайн
UX / UI
управление проектами
управление продуктами
Статья опубликована в 2018 году

Использование экономических критериев в веб‑разработке для оценки целесообразности реализации

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

управление продуктами
управление проектами
веб-разработка
Статья опубликована в 2014 году

​Создание сайта быстро, дешево, индивидуально и качественно

Альтернативное название статьи: «Ищем в стоге сена отсутствующую там иголку».

экономика
веб-разработка
управление продуктами
управление проектами
Статья опубликована в 2014 году

Как зависит качество разработанного сайта от количества выделенных ресурсов и менеджмента проекта?

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

экономика
веб-разработка
управление проектами
управление продуктами
Статья опубликована в 2014 году