Сенменов Сергей
40 лет, Россия
5 сообщений
#12 лет назад
Здравствуйте, уважаемые форумчане.

Стоит задача разработки и претворения в жизнь интернет-проекта одновременно информационного и коммерческого характера, если конкретнее – «грамотного» интернет-магазина с сильными и «правильными» информационно-аналитическим блоком и блоком поддержки клиентов. Требования к функционалу проекта (как его коммерческой, так и информационной части) не позволяют остановиться на какой-то коробочной версии CMS, потому как функционала таковых во многом не достаточно. Вопрос не стоит в создании чего-то сверхестественного, прямо-таки уникального. Нет, нужно сделать два-в-одном: интернет-магазин + информационный блок, сквозные личный кабинет и навигация, нормальный бэкофис (back office). Предполагаемая структура всего содержимого – динамическая, код писать с учетом сторонней поддержки (чтоб кто-то еще мог разобраться) и т.д. Все стандартно.

В связи с тем, что «содрать» с кого-либо (что обычно, как оказалось, практикуется и называется «Хочу, шоб как у них, но тока у миня и круче») возможности не представлялось, единственным выходом виделось самостоятельное написание ТЗ (технического задания). Вот здесь началось самое интересное в виду отсутствия опыта построения таких систем. Но не об этом. Основная проблема, как я ее вижу, связана с размытостью понимания «глубины» описания. Начальная стадия написания была определена стандартно: описание функционала. Все казалось ясно и прозрачно: описал функционал – получил сайт. В результате сейчас это описание (функционала) производится по схеме "кто что знает + кто что видел". Страшно хаотический и противоречивый процесс.

Засада обстоит в невозможности определения в ТЗ действительно стоящих моментов (ключевых) построения сайта ( с учетом некоторых требований). Фундамента, на котором можно будет построить надежную, а главное гибкую и расширяемую, систему. Ошибки в фундаменте не прошаются. Плюс слабое знание технологий и подразумевающих очевидных моментов. Возможно организовать безопасность (SSL) раздела личного кабинета или необходимо защищать весь с учетом его предположительного размещения не отдельным окном, а частью страницы? Какие бызовые функции движка (или чего?) должны быть заложены для организации и обслуживания динамической среды сайта? Стоит описывать, что css должны быть внешними и содержать описание тегов ('[В][/В], [Н1][/Н1]' и прочие) для дальнейшего применения SEO? И куча, огромная куча подобных и прочих вопросов. Возможно я даже не те термины употребляю, ведь есть же старое мнение "Чтобы правильно задать вопрос надо знать бОльшую чать ответа". Я считаю себя больше дилетантом, нежели человеком сведущим. Что-то знаю, что-то видел, что-то делал. Но системы в целом в голове нет.

Согласитесь, не являясь специалистом в программировании, дизайне, интернет-технологиях, сложно отличить очевидные моменты от неочевидных. Так можно накатать «Войну и мир», но даже не приблизиться к реальной разработке, погрязнув в разработке ТЗ. Тем более что всего предусмотреть просто невозможно.

Постепенно пришел к мысли, что на этапе разработки ТЗ должен быть кто-то, кто имеет реальный опыт проектирования таких систем, но не студия. Объясню свои предположения. Студии часто оговаривают ТЗ в зависимости от своих возможностей, а чаще просто просят готовое ТЗ. Это напрягает. Мне необходимо не ТЗ, заточенное под студию, а студия, работающая с ТЗ, написанном по реальным потребностям. Необходим аудитор технического задания или сторонний консультант? Если я правильно понимаю и не ошибаюсь в терминологии.

Повторюсь, я в этом деле – «мимо проходящий». Так получилось, что эта задача на этом этапе – моя. Понимаю, что каждый должен заниматься своим делом. Меня интересует алгоритм действий, потому как, думаю, я не уникален в своих потребностях и многие уже сталкивались с такой потребностью.

Заранее спасибо. Не судите строго.
Вадим Т.
44 года, Нидерланды
3240 сообщений
#12 лет назад
"Аудитор технического задания" не является необходимым, точно так же, как и в проекте, который выполнили программисты, не является обязательным QA. Но если Вы хотите получить качественный документ, с минимумом дефектов, то ревьюинг его желателен. ТЗ - документ очень важный, так как обычно именно на основании ТЗ делается оценка рисков проекта, смета расходов, календарный план работ. Дефекты в ТЗ могут привести к проблемам со сроками и бюджетом проекта.

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

Алгоритм действий. Если сами не можете подготовить ТЗ - наймите спеца со стороны. Он Вас проинтервьюирует, проанализирует все материалы которые Вы ему предоставите или о чем расскажете, подготовит ТЗ. Затем покажет Вам разработанный документ, Вы ему отправите Ваши замечания, он их исправит, у Вас будут новые замечания... и так, итерационно, доведете ТЗ до финала. Если потом дадите разработанный ТЗ на ревьюинг третьей стороне, документ от этого значительно выиграет по качеству.
Виктор Брылев
38 лет, Украина
226 сообщений
#12 лет назад
tvv, у меня вопрос втему. Сейчас мне предложили заниматься вот таким аудитом о котором говорит автор топика. Например, оценить ТЗ на интернет-магазин заточенный под определенный товар и определенную аудиторию. Сколько такой аудит может стоить?
Никита Липинский
35 лет, Украина
403 сообщения
#12 лет назад
neKur,
На Вашем месте, я бы рассматривал задачу более масштабно, чем составление ТЗ, а именно с точки зрения управления проектом.

Я предпочитаю называть ТЗ для крупных проектов проектной документацией, по аналогии с данным понятием в архитектуре.
Проект можно разбить на несколько этапов:
1. Бизнес-концепция/Бизнес-план
(отличие в степени детализации, бизнес-концепция описывает коммерческую деятельность проекта, бизнес-план основан на конкретных финансовых показателях и может быть правильно составлен на основе данных аналогичных проектов)

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

3. Организационные данные
(календарный график работа, график платежей, взаимодействие с командой разработчиков, система контроля, схема приемки-передачи работ и т.д.)

Наличие проработанной информации по перечисленным пунктам позволит спроектировать работу с минимальным количеством ошибок.

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

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

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

Если же на данном этапе у Вас нет возможности нанять специалиста, то Вы можете действовать по следующему алгоритму:
1. Описание проекта
2. Структура проекта
3. Описание функциональности
4. Особые требования

Каждый из перечисленных пунктов состоит из десятков подразделов, в свою очередь подраздел состоит из сотен блоков - то есть основной ответ на Ваш вопрос:
В проектной документации описывается каждый элемент и каждая деталь, примерный объем хорошо написанной документации в среднем равняется 100 страницам А4.
Проектная документация должна быть дополнена документами с полным содержанием магазина (каждого товара, всех инструкций для пользователей и т.д.)
Проектная документация должна быть дополнена описанием описанием методики SEO (еще несколько десятков страниц)
Все это увязывается организационной схемой в соответствии с принятым бизнес-планом.

При этом правила составления проектной документации для Интернета не стандартизированы...

Чтобы лучше сориентироваться прочтите:
- Что такое хорошее ТЗ на сайт? (http://www.webmascon.com/topics/planning/22a.asp)
- Графическая нотация для документирования информационной архитектуры и взаимодействий пользователя с веб-сайтом (http://www.webmascon.com/topics/planning/17a.asp)
- Техническое задание на создание автоматизированной системы (http://www.nist.ru/hr/doc/gost/34-602-89.htm)

Удачи!
Вадим Т.
44 года, Нидерланды
3240 сообщений
#12 лет назад
Цитата ("bewhite"):
tvv, у меня вопрос втему. Сейчас мне предложили заниматься вот таким аудитом о котором говорит автор топика. Например, оценить ТЗ на интернет-магазин заточенный под определенный товар и определенную аудиторию. Сколько такой аудит может стоить?

Стоимость - целиком и полностью зависит от предполагаемого потраченного на эту работу времени.
То есть, цена = предполагаемое_потраченное_время * часовой_рейт.
Предполагаемое потраченное на работу время зависит от самого характера работы. В случае аудита ТЗ - зависит от того, насколько он должен быть качественный, сколько может пройти ступеней итерации, и т.д. Что такое итерации? Например, ревьюинг ТЗ прошел, выслан отчет со списком вопросов и замечаний. ТЗ было переделано. Логично что опять нужно провести ревьюинг.

В общем, для разового ревьюинга среднего ТЗ (на разработку типового обычного Web проекта объемом примерно до 300-400 человеко-часов) обычно достаточно 1 часа, стоимость около 20 USD. Для более крупных проектов и соответственно более масштабных ТЗ, времязатраты будут больше, все зависит от проекта.
Вадим Т.
44 года, Нидерланды
3240 сообщений
#12 лет назад
Также, ревьюинг ТЗ может быть разный.
Он может заключаться просто в анализе ТЗ, и обращении внимания на то, что там не хватает.
А может быть более глубокий ревьюинг (аудит), в состав которого входит полный анализ всех входящей информации по проекту, которую имели сами разработчики этого ТЗ. Это более дорогой ревьюинг (по сути, это уже QA).
Новик Роман
43 года, Украина
697 сообщений
#12 лет назад
tvv, опять Вы не учитываете коэффициент aXel, просто возмутительно.
Вадим Т.
44 года, Нидерланды
3240 сообщений
#12 лет назад
Цитата ("Novick"):
tvv, опять Вы не учитываете коэффициент aXel, просто возмутительно.

Я называю цифры, по которым работаю сам. Считаю эти цифры для себя достаточными. А раз они достаточны для меня, то наверняка достаточны и для большинства остальных фрилансеров, так как расценки у меня достаточно высокие. Проблем не вижу.

А "доить" заказчиков, то есть брать с них не столько, сколько стоит работа, а сколько можно вытянуть, я считаю делом недостойным.
Новик Роман
43 года, Украина
697 сообщений
#12 лет назад
На самом деле, насколько я успел вникнуть в суть коэффициента aXel, при стабильном рейте он включается в цену автоматически. Т.е., если ваш рейт 1уе/час и Вы делаете работу впервые, то соответственно она забирает у Вас больше времени, при последующих аналогичных работах быстрее... Конечно это только поверхностное однобокое рассмотрение этого сложнейшего многогранного коэффициента. Не думаю, что доживу до его полной расшифровки . Опрометчиво я заявил, что построю автомат по его расчёту.
Кстати, спешу заявить, что к "дойке" заказчиков этот коэффициент не имеет ни малейшего отношения. Скорее пострадавшим может выявиться исполнитель, не учитывающий его хотя-бы интуитивно.
Group Trish
33 года, Украина
711 сообщений
#12 лет назад
Novick, я вижу вы вникли , но недоконца :P
Group Trish
33 года, Украина
711 сообщений
#12 лет назад
Оффтопик
Novick,реализовать "программу расчёта" нужно =) так лечге всем , будет ...
и даже есть вариант для заказчика ...
Сенменов Сергей
40 лет, Россия
5 сообщений
#12 лет назад
Спасибо, уважаемые форумчане, за внимание к моему вопросу.

Приятно удивлен взвешенному походу в ответах и рекомендациях. В эпоху "аффтар жжот" это встречается не часто.

tuls, Вы совершенно правы. Я сузил тему с "проект" на "сайт" потому как "проект" часто воспринимается за пафос "ламера" и не воспринимается серьезно, наталкивая на резонные замечания гуру: "А Вы вообще знаете, что такое проект? Вот это (название) - проект, а то, о чем говорите Вы - детский лепет" . Поэтому я и озвучивал "сайт". Бизнес-план (в локальном понимании) определен, концепция есть, есть общее видение (вернее, "знаю, чую что надо, сказать сложно) тоже есть, идет систематизация и подготовка материала, подбор инструментария и бла-бла-бла. В этом опыт некоторый есть. Осталось дело за малым: написать ТЗ на "интернет-составляющую" (назовем это так). Наполнение понимания "интернет-составляющей" определим как набор самостоятельных бизнес-процессов или часть имеющихся, направленных на как на дополнение, так и на улучшение взаимодействия в рамках систем B2B и B2C. Определение у меня здесь не очень получилось, если сказать честно .

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

Возвращаясь от теоретических заключений к практическим, отмечу, что на данный момент видится целесообразным разработка части ТЗ, описывающей "фундамент" и "выходные параметры блоков". Архитектура проекта (интернет-составляющей) должна подразумевать по-умолчанию максимальную гибкость. А в таких вещах без консултьтанта, имеющего представление об этом вопрсе, практический опыт, можно изобрести такой велосипед... Короче, неправильный велосипед. И даже или имея навыки программирования, или написав тысячи страниц текстов, или освоив несколько пакетов графических программ, не имея при всем при этом видения всего целого, вряд ли что-то получится. Если делать не "хомяка" или "презентацию", а что-то серьезнее.

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

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

Практикуются ли такие варианты сотрудничества? Если да, то как правильно построить диалог, что "перетряхнуть" в своей голове, к камим моментам подготовиться? Как решаются вопросы "удаленно" (оплата, гарантии и пр.)? Может кто-то имеет реальный опыт и сможет поделиться им здесь?

Будет ли тактично с моей стороны выложить здесь "содержание" (оглавление) ТЗ, чтобы добавить конкретики в рассуждения?

Спасибо tuls и tvv за не поверхостные ответы
Вадим Т.
44 года, Нидерланды
3240 сообщений
#12 лет назад
Цитата ("neKur"):
Практикуются ли такие варианты сотрудничества? Если да, то как правильно построить диалог, что "перетряхнуть" в своей голове, к камим моментам подготовиться? Как решаются вопросы "удаленно" (оплата, гарантии и пр.)? Может кто-то имеет реальный опыт и сможет поделиться им здесь?
Будет ли тактично с моей стороны выложить здесь "содержание" (оглавление) ТЗ, чтобы добавить конкретики в рассуждения?

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

2. Ваш вопрос насчет "перетряхнуть в своей голове" я не понял, тут пожалуйста поясните что имели ввиду.

3. Оплата и гарантии - если специалист Вам доверяет, он сможет работать по постоплате. Если не доверяет, значит будет работать только по предоплате. Предоплата - лучшая гарантия, но Вы тоже ведь будете ее платить только в том случае, если доверяете исполнителю, уверены что он не исчезнет после получения денег. Тут лучший способ - сервис безопасных сделок, потеря 5% от суммы, зато на порядок больше шансов того, что деньги не достанутся кидале.

Можно заключить официальный договор на выполнение работ, если суммы более-менее крупные. Только имейте ввиду, что требование заключить такой договор сразу отсечет удаленных специалистов из других стран, так как им тогда придется пропускать сделку по ВэД, одно это уже отметет 99% фрилансеров-одиночек и команд, останутся только те, у которых цены выше в 5 раз за ту же работу..

Можно заключить неофициальный договор, например такой, как делают на Weblancer.net при сервисе безопасных сделок. Тут договор абсолютно неформальный, но все-таки некоторые моральные обязательства накладывает.

А вот что имеет смысл заключить - это NDA, договор о неразглашении. Хотя при работе со специалистами из других стран он все равно не имеет силы. Но смысл работать по NDA все равно есть, накладывается больше ответственности.

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

5. Запостить ли сюда оглавление ТЗ? Не думаю что есть смысл, ведь это нам ничего не скажет, конкретики не добавит, ничем обсуждению не поможет.
Никита Липинский
35 лет, Украина
403 сообщения
#12 лет назад
neKur,

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

По оплате и гарантиями вопрос достаточно простой - Вадим описывает его детально.
Я всегда работаю через СБС или по предоплате в качестве фрилансера и только через СБС в качестве заказчика.

Вам для того, чтобы "подготовиться" нужно сделать совсем немного:
1) Выбрать субподрядчика в качестве консультанта (создать проект на Weblancer)
2) Заключить договор о неразглашении информации
3) Выслать все материалы по проекту
4) После первой же консультации Вам все станет ясно и ничего не нужно будет "перетряхивать"

Ограниченность бюджета может быть легко компенсирована долей в проекте...
Сенменов Сергей
40 лет, Россия
5 сообщений
#12 лет назад
Уважаемые господа (не обижу таким обращением?).

Спасибо за ваши ответы. Очень ценно для меня. Пишу этот пост чтобы не показаться невежливым. Информацию к размышлению, которую вы мне дали, необходимо немного "переварить" и обдумать, чтобы не убивать ваше время понапрасну. Если кому есть что добавить (дополнить), то буду признателен. Через пару дней постараюсь сформулировать новые вопрсы, с учетом "переваренного"

Спасибо еще раз.