Добрый вечер, уважаемое хабрасообщество.Хотим пригласить к дискуссии всех представителей веб-студий и Интернет-агентств, фрилансеров, а также представителей заказчиков и людей, неравнодушных для обсуждения следующей темы.
В данный момент мы занимаемся сбором тезисов для серии публикаций газеты «Деловой Петербург» о том, как и когда лучше заказывать сайт, на какие существенные моменты стоит обратить внимание, а также как избежать критических ошибок при выборе подрядчика.
При внутреннем обсуждении мнения относительно некоторых моментов сильно разнились. По некоторым моментам хотелось бы получить подтверждение. Мы решили попробовать вынести тертую тему на обсуждение в компетентное сообщество.
Тема не новая, но и не теряющая своей актуальности, так как уровень осведомленности и грамотности, как показывает наша практика, среди, в том числе именитых заказчиков зачастую пока еще сравнительно невысок, а исполнителей, пользующихся этим намерено или ненамеренно, достаточно много. От этого страдают обе стороны.
Задача состоит в том, чтобы сформулировать факты, а также путем обсуждения и дальнейшего голосования, определить их значимость при заказе сайта.
Все участники обсуждения будут в дальнейшем прокомментированы и упомянуты, если только не пожелают обратного.
И так сначала несколько спорных фактов:
1. Не стоит/ стоит работать с компанией, пользующейся услугами фриленсеров.
Не только небольшие студии, но и достаточно крупные, не будем их называть, пользуются услугами фриланса. С одной стороны, это должно вести к уменьшению стоимости для Заказчика, а с другой стороны вносит нестабильность и дополнительные риски. Здесь наши мнения сильно разделились.
2. Не стоит/ стоит заказывать сайт на неизвестной/ известной CMS.
С одной стороны хорошо взять раскрученную CMS, которую используют многие разработчики. Это позволит безболезненно сменить в случае необходимости разработчиков и гарантирует стабильность работы проекта. С другой стороны скорее всего проект на CMS типо Bitrix будет дороже и менее гибок для нестандартных модернизаций.
3. Лучше жесткий или гибкий договор (ТЗ в том числе как часть договора)?
При жестком договоре заказчик имеет фиксированное количество вариантов макета, а если потребуется больше, то придется доплачивать. Это действует в отношении всех этапов. С другой стороны гибкий договор, ТЗ позволят лучше корректировать работу над проектом по ходу появления промежуточного результата. Но он скорее всего окажется дороже.
4. Имеет ли значение ПО, которое использует студия? Имеется в виду лицензионное платное/нелицензионное/опенсорс?
Есть факты, которые нам хотелось бы записать как бесспорные, если не будет доказано обратное, но хотелось бы получить по ним комментарии, определить их значимость и дополнить этот список:
1. Лучше всего заказывать сайт заблаговременно
2. У студии должен быть хороший офис в котором работают люди, а не офис в подвале, где сидит пару менеджеров, а все разработчики, например, в Узбекистане.
3. Хорошо, если студия использует какую-либо CRM, чтобы ничего не забывать и не упускать, а еще лучше ПО для автоматизации и формализации отношений с заказчиком в ходе работы над проектом.
4. Наличие в компании адекватного серьезного руководств с которым может придется также плотно взаимодействовать скорее всего не при благоприятном развитии событий.
И совсем капитаночевидные факты:
5. Наличие хорошего портфолио у студии, а еще лучше наличие работ по схожей тематике.
6. Наличие дополнительных услуг – хостинг, поддержка, продвижение в поисковиках. Их высокий уровень и развитость в компании.
7. Серьезный возраст студии (от 3-4-х лет работы на рынке).
8. Наличие менеджера
Еще раз повторюсь, что хочется обсудить озвученные тезисы и расширить их список. Если тема окажется хабрасообществу действительно интересной и фактов соберется достаточно много, то потом организуем голосование. Поможем заказчикам вместе! :-)
upd: мы уже заметили, что в корпоративных блогах сначала пару минусов появляются сразу от авторов соседних топиков (имхо и наблюдение), но все-таки будем признательны за простые комментарии по теме, чтобы может быть убедиться, что мы зашли к этому большому вопросу не с той стороны.
