Тематические статьи: управление проектами

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

​Давайте рассмотрим «иллюзорные» гарантии, которые вроде как присутствуют в том или ином виде, но на самом деле их нет.

Гарантии в IT-услугах встречаются не так уж и редко: это и SLA в поддержке, и гарантии трафика или позиций в продвижении, и гарантии качества в разработке. Но тем не менее, понимаются эти гарантии не всегда правильно.

​Ежедневно мы отвечаем на этот вопрос и не один раз. Очень часто это первый вопрос позвонившего Клиента. Мы понимаем, что Клиенты устали слушать, что всё зависит от сложности разработки этого самого сайта.

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

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

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

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