войти зарегистрироваться

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

Сколько лет занимаюсь разработкой сайтов, всегда сталкиваюсь с одной проблемой — 9 из 10 заказчиков считают, что мы телепаты. Мы — это в принципе все айтишники, а, может быть, и специалисты других отраслей (не могу сказать точно — не пробовал). Когда заказчик говорит «мне нужен интернет-магазин для продажи <...> через интернет», он обычно предполагает, что любой интернет-магазин — это нечто «готовое», позволяющие «делать деньги» просто после того как «наполнил склад» и получил от Исполнителя сам сайт.
Я не буду здесь расписывать про раскрутку магазина, про юридические и бюрократические нюансы. Просто хочу потенциальным заказчикам (неважно у кого заказывать) дать несколько советов, чтобы в результате они получили то, чего хотят, а не то, чего хотел разработчик.

Блог компании МосиграПочему фрилансер и заказчик часто считают друг друга идиотами

Мне повезло: я побывал по обе стороны баррикад и теперь знаю, что и как делает заказчик на проектах разного уровня и что делает фрилансер, чтобы получить или провалить такой проект. В итоге я уверен, что 95% фрилансеров говорят с заказчиком на разных языках.

Осторожно, butthurt.

GTDКак я научился работать по техзаданиям: неочевидные плюсы очевидного решения из песочницы

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

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

Блог компании Digital Professionals HubТехническое задание: какие элементы должны быть прописаны, а какие – в уме

Когда мне предложили данную тему для написания своих мыслей в виде статьи, я долго думал, о чем же написать, потому что, по сути, вся данная статья укладывается в одно предложение, которое является прямым ответом на данный вопрос — Все документы должны быть прописаны и никаких моментов не должно быть в уме. Почему именно так? Рассмотрим по пунктам:

Бизнес студииТиповой шаблон технического задания на разработку сайта

ОФФТОП: Хочу выразить свою благодарность, всем кто плюсанул мой предыдущей пост и карму, это позволило мне пригласить на Хабр еще несколько хороших людей.

Во многих студиях нет единого формата ТЗ, у нас его тоже не было. Просмотрев множество различных форматов и ГОСТов, мы выбрали самые значимые пункты и разработали типовой шаблон ТЗ для нашей компании.
Возможно, это будет полезно и другим студиям, т.к. если мы все будем работать по единым стандартам плюсы очевидны как для студий, так и для заказчиков.

image

Управление проектамиЧто должно быть в техническом задании для программиста сайта

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

Суть её — переложение Концепции сайта, написанной специально для Заказчика, на тот язык, который более понятен программисту. Программист не будет внимательно читать объёмную Концепцию, ему надо потратить минимум времени на чтение, чтобы понять и реализовать свою задачу.

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

Веб-дизайнТехническое задание на дизайн

Техническое задание дизайнеру у меня, если честно, вызывает вопросы. Каким оно должно быть? Полным, чтобы при приёмке результата не было никаких недоразумений по поводу того, что представлялось всё не так? Или неполным, чтобы дизайнер мог проявить всю свою креативность и предложить собственный вариант дизайнерского решения поставленной задачи?

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

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

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