Уважаемые форумчане, здравствуйте.

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

Передо мной стоит задача разработки и претворения в жизнь интернет-проекта одновременно информационного и коммерческого характера, если конкретнее - интернет-магазина с сильным информационно-аналитическим блоком и блоком поддержки клиентов. Я не специалист в этом вопросе, не совсем мой профиль, но все когда-то встречается впервые. Вопрос не стоит сделать самому - люди такой области знаний всю жизнь посвящают и я не питаю иллюзий по поводу своих способностей (в разрезе дефицита времени), вопрос организации процесса и дальнейшего сопровождения (чтобы работало как надо),- что-то типа ответственным за проект я получился невзначай. Бюджет, как обычно, начинался от "нахаляву сами сделаем", "ну ладно, 100 уев заплатим" и т.д. В конечном итоге разговор идет о двух - двух с половиной килобаксах под ключ. Это, в двух словах, дизайн, эргономика и само тело – «движок». Еще раз повторюсь, что я не специалист в этом вопросе и прошу поправить меня, если я в терминах неточен или употребляю их некорректно.

Дизайн – это слишком субъективный и расплывчатый блок, чтобы обсуждать его здесь.

Рассмотрев несколько (в основном, два – уми и битрикс) CMS пришел к выводу, что они в коробочной версии не отвечают стоящим задачам – простоваты в некоторых моментах. Конкретно не устраивает корзина, каталог, нет как такового личного кабинета и еще много моментов, слабоват информационный блок. Много «боданий» между ними (UMI vs Bitrix)  по поводу кто круче и подходящей (битрикс, конечно, дороговат). Эргономика. Напрямую связана с дизайном (включает его, но дизайна я касаться не буду). Но в штатном исполнении студий (фирм), делающих проекты на этих движках, эргономика не сахар (касаемо как системы навигации, так и заезженность и однотипность структуры страниц). Коротко говоря, здесь меня постигло некое разочарование. Отдаю себе отчет, что разрабатываемый проект не типовой и глупо было бы рассчитывать, что есть уже готовые «движки» - поставил и вперед. Отдельной проблемой стало написание технического задания, но об этом позже.

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

1. Правильно ли составлять ТЗ (техническое задание) самому заказчику? Не имея соответствующей квалификации заказчик вряд ли сможет правильно сформулировать свои потребности и тем более пути их реализации. Как правильно построить этот этап работы?
2. Возможно ли, купив коробочный вариант CMS (как платформу или «базу») и начав работы с ним, постепенно дописывать его под свои нужды? Понимаю, что это возможно, но правильно ли? потому как программисту может проще писать «с нуля», нежели дописывать или переписывать. 
3. Сколько времени может занять написание CMS? Поясню: я понимаю, что CMS – это «рулилка» с пользовательским интерфейсом. То есть что-то типа пользовательской оболочки, не совсем «движок» в моем понимании, а типа автомобиля (с рулем, педалями, кузовом и др.) с некоторыми ограничениями. Мое представление верно? Если писать «с нуля» или дописывать, сколько времени ( в пропорции) уходит обычно на «движок» и сколько на «педали-рули-кузова». Этот вопрос связан с дефицитом времени и необходимостью разбить работы на участки и этапы и максимально «распараллелить» их для возможности проведения одновременных работ на нескольких участках в нескольких этапах.
4. Разумен ли начальный вышеуказанный бюджет, исходя из того, что пишется не Эльдорадо или eBuy и не ixbt или vingrad – намного скромнее. Возможно, по мере работы проекта и получения прибыли, что-то будет дописываться. Можно ли предусмотреть блочную структуру проекта, написав основные блоки и запустив их в работу, дописывая что-то второстепенное (не первой очередности) уже на работающем проекте?

Понимаю, что пост получился длинноват. Извиняюсь. Понимаю, что первое, что хочется мне сказать: «Учите матчасть!». Но это не очень просто – разного материала море, но качество его, так сказать, для школьников: «Сделай сайт сам» и др. и пр. Если порекомендуете что почитать существенное (не книги по CSS, PHP, Java) по моей теме, буду крайне признателен.

Спасибо. Заранее спасибо всем, кто войдет в мое положение и сможет здесь со мной побеседовать.

ПыСы: В фирмы, студии обращался. Мои вопросы вызывают недоумение и пожелания типа: «Вам это не надо, делайте как все» и прочее. Хотел бы избежать ситуации, когда исполнитель (подрядчик) в какой-то момент скажет: «Здесь расширение (или еще что-то) невозможно, потому как это не было предусмотрено в начале работ» или еще что-то. Если я не прав, то готов выслушать.




    


Это сообщение отредактировал(а) neKur - 28.5.2007, 11:04

1.
Правильней с точки зрения распределения работы делать это заказчику т.к. вы программист, а не телепат. Но за дополнительную плату конечно можно и поиграть в "угадай, что хочет заказчик".
2.
Купить CMS? Хм... Честно говоря, я не когда не покупал CMS, качал только демо версии, но за что деньги платить я не понял. Есть достаточно не плохие альтернативные варианты, с очень грамотным кодом, который действительно понятен. В пример Joomla.
А вопрос бать чужое или делать свое мне кажеться метанием из крайности в крайность... Возьмите Joomla и делайте как там, изучая интерфейс и код - имхо, лучшее решение.
3.
Смотря какие функции должны быть у вашей "машины". Я честно говоря сомневаюсь, что вы схожу напишите CMS... очень много повдодных камней.
4.
Сути проекта не понял - понятия не имею сколько это может стоить... А будет ли возможность сделать основу и дописывать потом зависит только от того, как вы организуете код.

По поводу обучения... Если вы знакомы с программированием, то по JS (именно JavaScript, а не Java) подойдет любая книжка т.к. она даст представление о том, что такое JS , а далее уже конечно придеться разбираться самому (сам ищу нормальную книгу по JS).
По PHP - на форуме бытует мнение, что книги по PHP отечественные - это зло. И я с ним соглашусь частично, давай базовые знания книги очень сильно дизинформаруют программиста в плане валидности и безопастности кода. Я начинал с книги "Освой самостоятельно PHP за 24 часа", не жалею, без нее бы не понял нечего, но в итоге полностью пришлось менять точку зрения о PHP.
CSS - технология проста, в интернете инфы море - а еще проще смотреть как у других.
Java - это прикладной язык программирования, он вам не нужен.

Если будут вопрос стучитесь - 455636110

Это сообщение отредактировал(а) BuShaRt - 17.5.2007, 17:43

BuShaRt, спасибо большое за внимание к моему вопросу. Насколько я понял, я не смог правильно выразить свои мысли, за что прошу прощения. Попробую немного расширить ранее озвученную информацию.

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

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

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

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

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

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


Это сообщение отредактировал(а) neKur - 18.5.2007, 09:06

Контору фрилансеров найти не так уж и сложно, есть множество сайтов предоставляющих сервисы по поиску удаленных работников.
Вот на пример weblancer.net (с моей анкетой).

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

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

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

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

А на грабли полезно наступать в плане повышения уровня осведомленности о местонахождение вышеупомянутых грабель.   

BuShaRt, извиняюсь за молчание.

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

neKur, 
Спрашивайте - не стисняйтесь.

BuShaRt, здравствуйте.

Пользуюсь Вашим предложением и хочу задать несколько вопросов. Пишу и горящего танка на сапоге убитого друга   .

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

По описанию блоков (обособленно) худо-бедно работа идет.

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

Мне начинает вырисовываться такая картина - необходим аудит ТЗ. То есть люди не стараются воплотить мое невежество в чем-то в кривой код и потом ткнуть мне бумажкой в нос с надменным: "Лох, у нас все ходы записаны", а реально ведут со мной диалог и говорят: "Ноги рациональней прикрутить внизу туловища подальше от головы, руки к ногам пришивать не стоит, а орган размножения возле уха выглядит не эстетично и в последующем может приносить неудобства в эксплуатации".  Я верно понимаю и называю это как "аудит" или не прав?

Интерфейс и возможности "рулилки" и "заполнялки"- абзац. 

Спасибо . Я не тормоз, мне надо просто подождать . 

Дырявая.


Не известно, нужно ТЗ что бы понять.

А вот это хорошо, можете просто как хорший тестер сроботать (по пользовательскому интерфейсу) сесть и написать что вы хотите там видеть, и как это должно работать.

да нет, есть что то, но мало и все англ авторов.

Ну тогда считайте что цена у вас увеличится в 1,5 раза примерно за такую срочность.

Там где будет понятно программистам.

возьмите внешего консультанта, не зависимого и пусть он им мозг компастирует.

А никто этого и не говорит, вы просто пытаетесь въехать в вопрос.

Str!pe, спасибо за Ваши комментарии.

Сейчас приблизительно и получаются функции тестера - типа "бой с воображаемым противником". Только воображение у всех разное .  Просто засада вырисовывается в том, что чем больше описывается, тем более нарастает впечатление, что описывать можно до бесконечности... Сейчас наброски тянут где-то на 20 листов А4 (если не на 30). Это беспредел, как мне кажется. Вроде без особой воды.

Вот и встал вопрос: где край-то? Есть субъективное ощущение, что что-то понимается или делается не так. 

Вероятно, моя мысль об "аудите ТЗ" где-то пересекается с Вашим предложением о "внешнем консультанте". Как это обычно осуществляется на практике?

Интересует именно не привлечение сторонних разработчиков на написание ТЗ, а аудит ТЗ - направить, указать на ошибки и недочеты, где-то лишнее убрать, где-то описать подробнее.  

Спасибо. 

Это сообщение отредактировал(а) neKur - 28.5.2007, 18:09

Ну... Отвечу на первый пост, пожалуй.. По роду деятельности и ситуации я являюсь и менеджером, и дизайнером, и наполнителем, и отчасти разработчиком веб-сайтов...
Кратко опишу организацию работы, которой пользуюсь. Может, поможет чем..
1. ТЗ формируется на основе брифа, заполненного заказчиком. Бриф являет собой "анкету", в которой учитываются пожелания по дизайну, функциональности, блокам, категориям материалов, тематике и т.д. и т.п. не думаю, что из ТЗ стоит развивать "поэмы" во много страниц...
2. Покупать CMS особого смысла не вижу. Еще не видел платной системы, которая бы по параметрам и защищенности была чем-то уникальнее в положительном смысле, чем бесплатные альтернативы. Все зависит от задачи. К тому же, расширения под платные системы найти - дело гиблое.  Как по мне, для Вашей ситуации полностью применима Joomla.
3. Относительно написания CMS... Не вижу смысла. Это требует и времени и наёма квалифицированных работников, которые должны быть сработанным коллективом, с опытом совместной работы и достаточным уровнем доверия.
4. Бюджет вполне разумен.

5. Желаю удачи . Если что, стучитесь. Я не гуру, но может что и подскажу.

m0ro, здравствуйте. Спасибо за внимание к моему вопросу. А то что-то я расстраиваться начал в ответ на молчание.

Итак,
я понимаю, что ТЗ составляется на основании брифа, заполняемого заказчиком. Верно.
НО ЗАКАЗЧИК - ЭТО Я   . Я - заказчик. Мне и бриф делать, мне и ТЗ писать.

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

Возможно я даже не те термины употребляю, ведь есть же старое мнение "Чтобы правильно задать вопрос надо знать бОльшую чать ответа". Я считаю себя дилетантом. Что-то знаю, что-то видел, что-то делал. Но системы в целом в голове нет.

Что делать?

Это сообщение отредактировал(а) neKur - 31.5.2007, 18:38

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

Это сообщение отредактировал(а) m0ro - 1.6.2007, 15:47

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



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


  Не английских, а на английском. Таких постов почитаешь, кажеться, что Англия великая страна, где все поголовно гении 


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


Очень зря, безплатные движки хорошо, но они далеки от севершенства по определению.


Тут вариант два, или продолжить все писать или закосить под непонимающего пользователя, нарисовать на пальцах, что требуеться и молиться, чтоб у них все получилось 


Сомневаю, что данный пункт будет обозначенн сразу или вообще будет обозначен. Хотя я могу ошибаться - я не знаю, что вы собрались делать за продукт.


Об это на данном этапе безпокоиться не стоит, это относиться к этапу тестирования и откладки, вот тогда (почитав материалы) вы спросите и потребуете показать где и как данные моменты организованны.

А функций требуемых для работы модуля основной задачи не достаточно?


вот это лишние


Попробуйте просвятить нас в конечные цели проекта и/или выложить накопленный материал.

Добавлено через 3 минуты и 45 секунд
Извеняюсь за опечатки и орф. ошибки  не выспался наверно