ТВОРЧЕСКАЯ
ЛАБОРАТОРИЯ
АНТОНА НИКОЛАЕВА

главная
Мои проекты
Разработка и продвижение сайтов
Экономика, политика
Блог - разное
Дизайн
Пресса и выступления
карта сайта
Контакты



Отношение студии к проекту заказчика

главная > Разработка и продвижение сайтов > Заказчик и студия

Главная задача почти любого исполнителя (особенно хорошего коммерсанта) - поменьше поработать за ваши деньги. Поэтому:

1. Задача менеджера по веб-разработке уговорить вас на наименее трудозатратные и самые типовые программные решения (CMS и фреймворки) и типовой функционал. Минимум индивидуального подхода к вашим потребностям и вашей специфике. Все сложно-индивидуальное, что может отделить вас от конкурентов - в отказ.

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

3. В SEO услуги попытаются свести к наиболее простым и шаблонным. В худшем случае - только генерировать отчет.

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

----------------------------

«5. Когда это выгодно?

Code Review — ..., это выгодно на проектах, в которых планируется длительная поддержка. Аккуратный код минимизирует количество затрат на дальнейшую отладку и ковыряние в нем.

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

6. Что делать после Code Review?

Это тоже очень щепетильный и непростой вопрос. Допустим, вы закончили проект, все работает, но Code Review показал, что нужно, скажем, еще неделю на полировку кода.

Как быть? Заказчик за это дополнительно не платит, времени обычно лишнего нет.

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

7. Что позволяет выловить Code Review?

С высокой долей вероятности можно отловить утечки памяти и проблемы в безопасности, а так же потенциальные проблемы в производительности.
Со стопроцентной вероятностью вылавливаются косяки форматирования (соответственно, вы можете добиться однородности стиля кодирования у всей вашей команды).
Хорошо вылавливаются «велосипеды» и дублирование кода, излишняя усложненность и избыточные конструкции. Довольно неплохо вылавливаются мелкие ошибки, опечатки в сообщениях.

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

8. Когда Code Review НЕ НАДО делать?

Code Review по сути противоречит краткосрочным бизнес-целям web-студии.
 

Явной прибыли он не приносит, а время кушает порядочно
.
Нафиг он не нужен на коротких проектах, типа «натянуть дизайн на Joomla».
Нафиг он не нужен на проектах, где критична скорость запуска, а не чистота кода. (Например стартап: делаем быстро грязный работающий прототип, запускаем.
Если идея выстрелила — может быть перепишем красиво (обычно так никогда не бывает)...»


Еще один пример: обсуждение в закрытой группе сеошников отношения к работе для заказчика:










»Разработка и продвижение сайтов
    SEO: старые статьи
    SEO: мои инструментов для поисковой оптимизации 2000
    Маркетинг: Удаляем конкурентов из Яндекса 2005
    SEO: Текстоптимайзер 2006
    SEO: Нелинейная выдача на Яндексе 2006
    SEO: скрипт для перелинковки сайтов 2007
    SEO: Уникальность, как статический фактор при ранжировании 2007
    SEO: сервис и скрипт проверки текста на уникальность 2007
    UX: Поведение - смотрим глазами посетителя
    SEO: Истинное ранжирование Яндекса
    SEO: Оценка рисков поискового продвижения
    UX: Яндекс повторил "тропинки"
    UX: Гугловские тропинки по сайту
    SEO: Закладки вместо ссылок
    SEO: Качество текста по Яндексу 2015
    UX: быстродействие браузера
    SEO: Конверсии поисковых запросов в лиды
    SEO: Как бруазеры следят за пользователями
  »Заказчик и студия
    UI: интерфейс и угол зрения
    SEO: Атака ботов поведенческими
    UX и UI ошибки в примерах
    Поведение на сайте

СВИДЕТЕЛЬСТВА:








ПРЕССА И ВЫСТУПЛЕНИЯ:



Выступление для менеджеров по рекламе застройщиков недвижимости, 2016


Выступление на конференции "Интернет и Бизнес", Москва, 2008


Выступление на Санкт-Петербургской Интернет конференции СПИК 2008


Выступление на конференции по юзабилити "User Expirience 2007", Москва


Статьи для рассылки "Продвижение сайта. Профессиональные советы экспертов"


Бан Яндекса, оптимизация текста по методу Остапа Бендера.


Критерии для постановки задачи и оценки результатов поискового продвижения (2002)