Comments 64
за 4 месяца
в очень сжатые сроки
Суровая ЦМС эта ваша битрикс.
А не сжатые сроки — это сколько? 1.5 года?))
На проектирование интернет-магазина с десятком сотрудников в бэкофисе у вас уйдет не один месяц, если будете описывать все бизнес-процессы и согласовывать их с клиентом. А потом еще разработка, тестирование, нагрузочные испытания… :-)
Зато сразу можно оценить стоимость разработки магазина на Битрикс.
Если пишите срок разработки 4 месяца, то или пишите конкретно, что входит в этот срок или не надо это как преимущество выставлять.
А то люди делают магазины за месяц и без бюджета в пол миллиона рублей и не совсем понятно, что они делают не так?
Если пишите срок разработки 4 месяца, то или пишите конкретно, что входит в этот срок или не надо это как преимущество выставлять.
А то люди делают магазины за месяц и без бюджета в пол миллиона рублей и не совсем понятно, что они делают не так?
Погодите. В статье подробно и конкретно описан процесс от проектирования до ввода в экплуатацию под ключ крупного высоконагруженного проекта с нестандартным функционалом. Что именно еще пояснить?
В том и дело, что конкретно ничего не расписано, расписано «например», «может быть». Например кому-то нужно сложное ценообразвоание, а кому-то нет. Кому-то нужна регистрация юр. лиц, а кому-то нет, плюс задание мы не пишем, так как это очень долго, но срок разработки ровно 4 месяца и это очень круто.
Спасибо, Александр, за подробную статью.
Однако позвольте с вами не согласиться в части "… — заставляйте обновлять проект каждый день". На нагруженных рабочих проектах это рискованно, потому что надо тестировать обновление, что тоже затратно.
Например, обновление 9.5.* с «живой сессией» несмотря на полное отсутствие кастомизации функционала чуть не завалило сервер, а исправлений пришлось ждать несколько дней. Нас спас только большой запас мощности на железке.
Однако позвольте с вами не согласиться в части "… — заставляйте обновлять проект каждый день". На нагруженных рабочих проектах это рискованно, потому что надо тестировать обновление, что тоже затратно.
Например, обновление 9.5.* с «живой сессией» несмотря на полное отсутствие кастомизации функционала чуть не завалило сервер, а исправлений пришлось ждать несколько дней. Нас спас только большой запас мощности на железке.
Мир софта это же постоянное движение вперед. Возьмите дистрибутивы серверных операционных систем, например Redhat/CentOS — 7 лет багфиксов и бэкпортов, в т.ч. нового функционала в ядро.
В 1С-Битрикс тщательно тестируют все обновления перед их выходом, понимая, что будут обновляться боевые высоконагруженные системы. К большому сожалению, иногда вкрадываются ошибки — ведется активная работа по минимизации их появления. Надежнее всего — обновляться на отдельной машине, запускать юнит и интеграционные тесты и после этого обновляться на боевой машине.
В 1С-Битрикс тщательно тестируют все обновления перед их выходом, понимая, что будут обновляться боевые высоконагруженные системы. К большому сожалению, иногда вкрадываются ошибки — ведется активная работа по минимизации их появления. Надежнее всего — обновляться на отдельной машине, запускать юнит и интеграционные тесты и после этого обновляться на боевой машине.
«В 1С-Битрикс тщательно тестируют все обновления перед их выходом»
— вот уж насмешили))
— вот уж насмешили))
В настройках главного модуля можно отключить флаг «Загружать только стабильные обновления» — и наслаждаться бетами, кому не терпится :-) После стабилизации беты модуля, он переходит в разряд стабильных — все по взрослому.
Ничего криминального там нет. Решается или уже решено косметическим рефакторингом.
Но вы же предлагаете с этим работать и это дописывать и расширять…
Вы думаете в исходниках linux все совершенно? :-) Да, есть чистоплюи в OpenBSD — которые обсасывают каждую строку кода — ну и какой индекс популярности у подобных систем? Архитектура 1С-Битрикс — грамотна, модульна и расширяема. Пишите свои модули на строгом ООП, никто не мешает.
Искренне желаю вашей компании нанять толковых технарей и избавиться от сложившейся репутации, потому что, если бы возможности битрикса были бы еще подкреплены возможностью его сопровождения, ему бы цены не было.
Но пока вы пишите такие комментарии, битрикс не отмоется от ссылок на говнокод.
З.Ы. плюйте в карму еще, битриксу станет лучше от этого :)
Но пока вы пишите такие комментарии, битрикс не отмоется от ссылок на говнокод.
З.Ы. плюйте в карму еще, битриксу станет лучше от этого :)
Спасибо. А можете назвать продукт, который отмылся от ссылок на говнокод, есть такие в природе или только в книжках в университете?
везде есть говнокод, вопрос в его проценте. В Битриксе его 200%.
Не понимаю я вас. Знаете, 90% программистов, которых я собеседовал, считают говнокодом почти любой непонятный им код, кроме своего (из-за чувства страха перед неизвестным). А когда сами начинают писать, то все оказывается наоборот — пишут хуже библиотек и коробочных решений.
Далее. АПИ 1С-Битрикс просто и модульно. Там практически нет ООП — для упрощения и гибкости, в основном функции. А задача программиста уже творить объекты или модули на базе АПИ — где тут поддержка говнокода, кроме как своего :-), я не вижу. Вас никто не просит поддерживать ядро и АПИ, это наша задача.
Далее. АПИ 1С-Битрикс просто и модульно. Там практически нет ООП — для упрощения и гибкости, в основном функции. А задача программиста уже творить объекты или модули на базе АПИ — где тут поддержка говнокода, кроме как своего :-), я не вижу. Вас никто не просит поддерживать ядро и АПИ, это наша задача.
Я не собираюсь вас переубеждать, т.к. даже судя по этому топику — это бесполезно. На любой аргумент — у вас 100 своих.
В любом случае что-то не так в датском королевстве, если так много людей говорят о том, что код Битрикса довольно плох. Если для вас это ничего не значит, то и нет смысла продолжать разговор.
Как говорится — хай буде гречка.
В любом случае что-то не так в датском королевстве, если так много людей говорят о том, что код Битрикса довольно плох. Если для вас это ничего не значит, то и нет смысла продолжать разговор.
Как говорится — хай буде гречка.
>Требуется, чтобы система выдержала 1000000 хитов в сутки, со средним временем получения страницы в 0.5 секунды и процентом ошибок (50*) менее 1%.
И таки вы считаете что это годная цель?
И таки вы считаете что это годная цель?
Для системы с несколькими сотнями таблиц в базе данных, десятками настроенных бизнес-процессов, веб-антивирусом, каталогом с сотнями тысяч позиций, работающим постоянно обменом данными с 1С и одновременной работой фронтенда и бэкэнда (десятки сотрудников), на одноюнитовой железке — цель имхо вполне достойная.
Приложение, имеющее несколько сотен таблиц в базе — уже никуда не годится для высоких нагрузок.
И именно поэтому делать такие решения на базе ЦМС (битриксов, джумл и прочих друпалов), которые медленные как каракатицы — высшей степени глупость.
При грамотном подходе на фреймворке и с заточкой под конкретное приложение — можно уложиться в несколько десятков таблиц и многократным (на порядки) увеличением производительности.
И совсем не уверен, что это займет много больше времени на разработку, чем запиливание этих ваших ЦМС.
И именно поэтому делать такие решения на базе ЦМС (битриксов, джумл и прочих друпалов), которые медленные как каракатицы — высшей степени глупость.
При грамотном подходе на фреймворке и с заточкой под конкретное приложение — можно уложиться в несколько десятков таблиц и многократным (на порядки) увеличением производительности.
И совсем не уверен, что это займет много больше времени на разработку, чем запиливание этих ваших ЦМС.
(спешу уточнить, что понятно, что бывают случаи когда таблиц действительно сотни и по делу, но это уже столь редкие случаи, что это выходит за рамки данной темы)
Я не буду спорить по поводу 1М хитов или 0.5 секунды, но 1% ЗАПЛАНИРОВАННЫХ отказов — это песец. Так нельзя.
А php иногда начинает сыпаться записями segmentation fault — не встречали? :-) Вот такие вот непредвиденные обстоятельства рождают малый процент ошибок. Но если использовать веб-кластер, то процент ошибок можно свести к нулю.
Segmentation fault я встречал.
Но во-первых у нее как правило есть причина, которую можно найти, а во-вторых, если у вас каждый сотый запрос сегфолтится, то вы точно что-то делаете не так ;)
Но во-первых у нее как правило есть причина, которую можно найти, а во-вторых, если у вас каждый сотый запрос сегфолтится, то вы точно что-то делаете не так ;)
Причина? Ошибки в ядре php ;-)
Пишите баг-репорты.
Любую ошибку можно локализовать и сообщить о ней разработчикам.
ps. У вас действительно php сегфолтится на каждый сотый запрос? как вам это удалось?
Любую ошибку можно локализовать и сообщить о ней разработчикам.
ps. У вас действительно php сегфолтится на каждый сотый запрос? как вам это удалось?
Видимо вы не работали в высоконагруженных PHP-проектах, где отлавливаются баги в линуксе, nginx, apache и php и прекомпиляторах :-).
Не надо переходить на личности.
Я работал и продолжаю работать в «высоконагруженных php-проектах».
Могу сказать, что 99% для нас — недопустимо мало. Сейчас, если верить моему заббиксу, наш аптайм выше 99,99%
На вопросы, что я задал выше, ответьте пожалуйста.
И да, раз вы отлавливали баги в линуксе, nginx и apache, приведите пример хотя бы одного в каждой группе.
Я работал и продолжаю работать в «высоконагруженных php-проектах».
Могу сказать, что 99% для нас — недопустимо мало. Сейчас, если верить моему заббиксу, наш аптайм выше 99,99%
На вопросы, что я задал выше, ответьте пожалуйста.
И да, раз вы отлавливали баги в линуксе, nginx и apache, приведите пример хотя бы одного в каждой группе.
Два моих любимых бага:
1) PHP с любым прекомпилятором в апаче сыпется при увеличении нагрузки на проектах с большим числом php скриптов. Я отлавливал ситуацию на FreeBSD, Debian, CentOS. Собирали отладочные бинарники — php падает в разных местах в момент повторного освобождения памяти кастомизированной функцией движка ZendEngine. Меняли версии glibc — не помогает. 100% стабильности работы я за много лет так и не увидел. Самое интересное, что падает даже сертифицированная сборка php на ZendServer. Все стороны валят друг на друга — т.к. прекомпилятор это же не PHP и наоборот.
2) Между apache и nginx редко, но с забавной настойчивостью опять таки при высоких нагрузках появляются ридинги (слоты апача забиваются процессами в статусе "...reading..."). Решение ищу давно. Настройки стека TCP — не помогают. Баг где-то между линуксом и nginx :-) В исходниках копаться честно лень.
Эти вещи однако успешно закрываются успешно веб-кластерными технологиями. Тогда процент ошибок будет 0%.
1) PHP с любым прекомпилятором в апаче сыпется при увеличении нагрузки на проектах с большим числом php скриптов. Я отлавливал ситуацию на FreeBSD, Debian, CentOS. Собирали отладочные бинарники — php падает в разных местах в момент повторного освобождения памяти кастомизированной функцией движка ZendEngine. Меняли версии glibc — не помогает. 100% стабильности работы я за много лет так и не увидел. Самое интересное, что падает даже сертифицированная сборка php на ZendServer. Все стороны валят друг на друга — т.к. прекомпилятор это же не PHP и наоборот.
2) Между apache и nginx редко, но с забавной настойчивостью опять таки при высоких нагрузках появляются ридинги (слоты апача забиваются процессами в статусе "...reading..."). Решение ищу давно. Настройки стека TCP — не помогают. Баг где-то между линуксом и nginx :-) В исходниках копаться честно лень.
Эти вещи однако успешно закрываются успешно веб-кластерными технологиями. Тогда процент ошибок будет 0%.
На каких версиях php провляется первый баг? Баг-репорт писали?
Я правильно понимаю, что эти баги дают вам 1% ошибок на проде?
Я правильно понимаю, что эти баги дают вам 1% ошибок на проде?
На всех версиях php, но не факт что дело в php. А кому писать репорт — в php или автору прекомпилятора? :-) Или в копию и тех и тех. Я думаю дело в связке php с прекомпилятором. Опять таки повторю, что нередко эта проблема не проявляется вообще. Все зависит от проекта, нагрузки, железа и софта.
Вы упорно игнорируете мой второй вопрос.
Позволю себе повторить его еще раз.
Вы ставите себе целью терять 1% запросов.
Вопрос: куда теряется этот процент? Неужели у вас php сегфолтится так часто?
Позволю себе повторить его еще раз.
Вы ставите себе целью терять 1% запросов.
Вопрос: куда теряется этот процент? Неужели у вас php сегфолтится так часто?
Вы видимо не заметили второй пункт про apache и nginx. Предлагаю не зацикливаться — пусть каждый выбирает себе такой процент ошибок, какой считает нужным. Я лишь поделился практическим опытом поведения php под высокими нагрузками на современном серверном софте.
Ради вас поправил текст статьи про 1%, написал более ясно, что имеется в виду.
Спасибо, это честь для меня :)
Ранее никто не правил ради меня статьи, кроме шуток.
Ранее никто не правил ради меня статьи, кроме шуток.
Вот еще интересный материал на эту тему, надеюсь пригодится. Буду благодарен, если подскажите как бороться с такими вот багами серверного софта.
У нас на большой нагрузке eAccelerator постоянно приводил к сегфолтам. С xcache проблем таких пока не замечено
Только для меня этот пост пахнет заказухой?
Показухой, пожалуй
Так вроде там и не скрывается, что статья написана сотрудником компании Битрикс. Прямого указания не вижу (не всё прочитал :) но там выражения «наша партнерская сеть», и т.п. встречаются.
А, там же подпись внизу! :)
В статье изложен реальный опыт внедрения и применения фреймворка на известных крупных проектах рунета. Использование подобного 1С-Битрикс решения нередко позволяют достигнуть отличных результатов в короткие сроки, но иногда, и все мы это понимаем, при наличии сильной команды разработчиков — нужно и эффективнее писать решение самим, возможно с нуля.
По-моему, вместо первой картинки лучше бы подошла вот эта:
Хм, не вставилось. army-life.ru/wp-content/uploads/2008/10/d184d0bed182d0be030.jpg
Вот вроде почитаешь всё так красиво, но почему я так и не видел ни одного нормального внедрения Битрикса? Невезение-совпадение?
Здесь можно посмотреть: www.1c-bitrix.ru/products/cms/projects/
тут тоже можете найти много нового: www.itrack.ru/research/cmsrate/
тут тоже можете найти много нового: www.itrack.ru/research/cmsrate/
А вот список успешных высоконагруженных внедрений.
По личному опыту скажу, что внедрять со слабой командой разработчиков (а таких большинство) решения на базе ZF, Symfony, Magento для интернет-магазина — гораздо более рискованное занятие, т.к. одно дело скриптики писать и править даже студентам понятные на 1С-Битрикс, а другое — использовать возможности ООП в php на полную катушку, для чего требуется многолетний опыт и практика, понимание паттернов проектирования и т.п. А испортить объектную модель бестолковым наследованием — очень просто, и как часто это случается.
По личному опыту скажу, что внедрять со слабой командой разработчиков (а таких большинство) решения на базе ZF, Symfony, Magento для интернет-магазина — гораздо более рискованное занятие, т.к. одно дело скриптики писать и править даже студентам понятные на 1С-Битрикс, а другое — использовать возможности ООП в php на полную катушку, для чего требуется многолетний опыт и практика, понимание паттернов проектирования и т.п. А испортить объектную модель бестолковым наследованием — очень просто, и как часто это случается.
Я не верю этому списку, там присутствуют притянутые за уши внедрения. Чего только стоит внедрение в Эльдорадо, уж постистиснялись бы вывешивать как успешное внедрение.
А что вам не нравится в этом замечательном высоконагруженном проекте на платформе Битрикс? ;-)
То есть по Вашему там всё прекрасно? :)
Я даже периодически пользуюсь данным сайтом для покупок. Все отлично работает.
Вы знаете во сколько вышла разработка этого сайта и сколько сейчас стоит его поддержка?
Даже на часть этих денег можно было нанять пару отличных спецов с бесплатным фреймворком и всё было бы дешевле, быстрее, надёжнее и производительнее. Но всем почему-то мерещиться что с битриксом можно занедорого сделать высоконагруженный проетк. «Не гонялся бы ты поп за дешевизной». :)
Даже на часть этих денег можно было нанять пару отличных спецов с бесплатным фреймворком и всё было бы дешевле, быстрее, надёжнее и производительнее. Но всем почему-то мерещиться что с битриксом можно занедорого сделать высоконагруженный проетк. «Не гонялся бы ты поп за дешевизной». :)
Знаете, я встречал на своем жизненном пути много самописных «крутыми» разработчиками систем, которые либо умирали через год-два так и выйдя в релиз по причине самозапутывания кода разработчиками, их увольнения и постоянного изменения требований, либо запускались и их поддержка превращалась в вечный деморализующий кошмар.
В платформе Битрикс вы получаете 90% нужного и работающего функционала типичного веб-проекта с технической поддержкой и обновлениями, а именно на 10% нестандарта можно эффективно сконцентрировать усилия «крутых ребят» и… достичь цели за короткий срок.
В платформе Битрикс вы получаете 90% нужного и работающего функционала типичного веб-проекта с технической поддержкой и обновлениями, а именно на 10% нестандарта можно эффективно сконцентрировать усилия «крутых ребят» и… достичь цели за короткий срок.
Полностью с Вами согласен, но среди самописок я видел удачные внедрения, а среди Битриксов — нет.
Мне кажется дело в грамотном сопровождении решения на платформе Битрикс после его разработки:
— имеется ли постоянно обновляемое ТЗ к проекту и описание его настроек, например в вики, или никто не знает как ОНО все работает
— имеются ли интеграционные и модульные тесты проекта, проверяемые после модификации его кода или проект перманентно тестируется на клиентах
— проводится ли аудит доработок проекта или программисты развлекаются как могут
— ведется ли непрерывный мониторинг решения с помощью например nagios, pinba — размера кэша, время исполнения страниц, отлов отпавших по недостатку памяти страниц в логах, отлов медленных запросов к БД и их оптимизация или это брошено на самотек
и т.п.
Там, где эти вещи делаются, решения на битриксе живут и процветают и… постоянно развиваются. Недавно обсуждали с одними крупными клиентами планы по их развитию — вдохновляет :-)
— имеется ли постоянно обновляемое ТЗ к проекту и описание его настроек, например в вики, или никто не знает как ОНО все работает
— имеются ли интеграционные и модульные тесты проекта, проверяемые после модификации его кода или проект перманентно тестируется на клиентах
— проводится ли аудит доработок проекта или программисты развлекаются как могут
— ведется ли непрерывный мониторинг решения с помощью например nagios, pinba — размера кэша, время исполнения страниц, отлов отпавших по недостатку памяти страниц в логах, отлов медленных запросов к БД и их оптимизация или это брошено на самотек
и т.п.
Там, где эти вещи делаются, решения на битриксе живут и процветают и… постоянно развиваются. Недавно обсуждали с одними крупными клиентами планы по их развитию — вдохновляет :-)
Однажды Ходжа Насреддин решил подшутить над слишком сильно шумящими детьми. И сказал детям: «Дети, на кладбище раздают конфеты, бегите туда скорее.» Дети побежали на перегонки. Ходжа постоял, подумал… и пришел к выводу что если бы конфеты на кладбище не давали то дети бы не побежали. И сам побежал на кладбище за конфетами.
Интересная статья, Александр.
Скептикам рекомендую ознакомиться с трудовой биографией автора.
По сути у меня ряд вопросов.
1. Мы делаем магазины куда более простые чем Эльдорадо и без такой нагрузки, сценарии более простые и прямые, чем вы пугаете. В любом магазине 20-30 различных типов html-страниц (собственно магаз+неизбежные доп.разделы типа новостей, статей, фака, акций и т.п.)
Вы их не кастомизируете? Оставляете стандартные от Битрикса? Или не описываете в ТЗ? Кто и как их делает?
Дизайнер (1шт)+верстальщик (1шт)+программист клиентских скриптов (1шт) тратят в сумме не менее 20 рабочих дней только на реализацию дизайна и клиентской логики. И ПМ их непрерывно модерирует независимо от того, есть ТЗ или нет.
Это гигантская работа, особенно если заказчик внимателен к ее результату.
2. Разностное ТЗ (пишем только то, что отличается от стандарта) это прекрасно в смысле экономии времени и текста. У нас есть ряд проектов, где мы такое ТЗ применяем. Однако вы в начале пишете (адресуясь к проектировщику) что он должен понять логику работы компонентов и прочувствовать точки роста. Ну он-то прочувствует, а клиент?
Допустим, реализация магазина Битриксом хороша. Но клиент-то не знает что есть стандарт и что он ему дает. Клиент хочет (и не говорит, естественно, пока не покажешь или прямо не спросишь) массу мелочей, настраиваемых в специфических местах. Я говорю о сценарии заказа со скидками, ограничениями, правами доступа и т.п.
Сказать: извините, этого нет в ТЗ, мы вас предупреждали что пишем отличия от стандарта Битрикса — вы будете быстро и совершенно справедливо посланы на йух.
Реально получается что разностное ТЗ работает только в двух случаях: клиент знает Битрикс не хуже ПМ, причем не только как юзер, но и немного как системно-мыслящий проектировщик, или ему совершенно плевать как оно будет выглядеть, лишь бы работало и продавало.
Мне кажется, оба типа клиентов — абсолютная экзотика. Да и разработчики редко берут на себя смелость утверждать «мы знаем как оно будет продавать, берем на себя ответственность».
3. Натягивание нестандартной верстки на магаз = 1 человеко-день?
Может я не понимаю чего-то, но если верстка отличается от стандарта не только цветами и оформительскими картинками, а еще и меняет хотя бы чуть-чуть процесс или интерфейс просмотра товаров, это требует работы напильником и кастомизации компонентов. Я оцениваю натягивание даже готовой верстки (чего не бывает, всегда есть пропущенные страницы и забытые поля) в несколько раз больше. Или у вас 5 человек одновременно будут это делать?
Понятно, что изменение логики и вида заказа, корзины, оформления мало кому реально надо, но большинство этого хотят, и в проекте от этого не уйти, если не продавать тиражку прямо как есть.
4. мозгоразжижающие вопросы про скидки, которые нереально уточнить ни до, ни во время проектирования, кто и когда будет задавать? уже кодить надо, проект стынет, а формул нету! как решается?
Меня статья огорчила тремя вещами:
a. я не поверил что хайлоад магазин с нестандартными сценариями можно сделать за 4 месяца. можно примеры? и на мои вопросы ответьте, аспекты проектирования и утряски мелочей мне непонятны.
я по-прежнему сторонник нормального проработанного ТЗ. наша практика показывает, что если клиент не понимает бизнес-вопроса или не готов на него быстро ответить в процессе проектирования, он на него не ответит и потом, как бы не клялся. соответствующий функционал надо убирать.
тз на не особо навороченный магаз это 25-40 листов с картинками или скетчами всех страниц. пишется 2-5 недель.
b. где agile? можно для неразвитых показать где он тут?
открыл вики, прочитал манифест. ничего не увидел тут у вас от agile. я без сарказма, я правда не понял
c. битрикс. пусть он хорош, не полезем в детали. мне кажется что тут дело не совсем в платформе. вы не доказываете что битрикс лучший, вы просто берете его как данность. хорошо.
если надо доказать что он крут, сравните с osCommerce хотя бы. покажите чем плох последний, чем плохи решения типа Magento
если вы видите серьезные преимущества Битрикса для проектных операций — расскажите подробности.
намеки есть, но честно я не увидел аргументов. много мнений без ссылок на проекты.
ссылок много, а статья отличная, дает задуматься.
Скептикам рекомендую ознакомиться с трудовой биографией автора.
По сути у меня ряд вопросов.
1. Мы делаем магазины куда более простые чем Эльдорадо и без такой нагрузки, сценарии более простые и прямые, чем вы пугаете. В любом магазине 20-30 различных типов html-страниц (собственно магаз+неизбежные доп.разделы типа новостей, статей, фака, акций и т.п.)
Вы их не кастомизируете? Оставляете стандартные от Битрикса? Или не описываете в ТЗ? Кто и как их делает?
Дизайнер (1шт)+верстальщик (1шт)+программист клиентских скриптов (1шт) тратят в сумме не менее 20 рабочих дней только на реализацию дизайна и клиентской логики. И ПМ их непрерывно модерирует независимо от того, есть ТЗ или нет.
Это гигантская работа, особенно если заказчик внимателен к ее результату.
2. Разностное ТЗ (пишем только то, что отличается от стандарта) это прекрасно в смысле экономии времени и текста. У нас есть ряд проектов, где мы такое ТЗ применяем. Однако вы в начале пишете (адресуясь к проектировщику) что он должен понять логику работы компонентов и прочувствовать точки роста. Ну он-то прочувствует, а клиент?
Допустим, реализация магазина Битриксом хороша. Но клиент-то не знает что есть стандарт и что он ему дает. Клиент хочет (и не говорит, естественно, пока не покажешь или прямо не спросишь) массу мелочей, настраиваемых в специфических местах. Я говорю о сценарии заказа со скидками, ограничениями, правами доступа и т.п.
Сказать: извините, этого нет в ТЗ, мы вас предупреждали что пишем отличия от стандарта Битрикса — вы будете быстро и совершенно справедливо посланы на йух.
Реально получается что разностное ТЗ работает только в двух случаях: клиент знает Битрикс не хуже ПМ, причем не только как юзер, но и немного как системно-мыслящий проектировщик, или ему совершенно плевать как оно будет выглядеть, лишь бы работало и продавало.
Мне кажется, оба типа клиентов — абсолютная экзотика. Да и разработчики редко берут на себя смелость утверждать «мы знаем как оно будет продавать, берем на себя ответственность».
3. Натягивание нестандартной верстки на магаз = 1 человеко-день?
Может я не понимаю чего-то, но если верстка отличается от стандарта не только цветами и оформительскими картинками, а еще и меняет хотя бы чуть-чуть процесс или интерфейс просмотра товаров, это требует работы напильником и кастомизации компонентов. Я оцениваю натягивание даже готовой верстки (чего не бывает, всегда есть пропущенные страницы и забытые поля) в несколько раз больше. Или у вас 5 человек одновременно будут это делать?
Понятно, что изменение логики и вида заказа, корзины, оформления мало кому реально надо, но большинство этого хотят, и в проекте от этого не уйти, если не продавать тиражку прямо как есть.
4. мозгоразжижающие вопросы про скидки, которые нереально уточнить ни до, ни во время проектирования, кто и когда будет задавать? уже кодить надо, проект стынет, а формул нету! как решается?
Меня статья огорчила тремя вещами:
a. я не поверил что хайлоад магазин с нестандартными сценариями можно сделать за 4 месяца. можно примеры? и на мои вопросы ответьте, аспекты проектирования и утряски мелочей мне непонятны.
я по-прежнему сторонник нормального проработанного ТЗ. наша практика показывает, что если клиент не понимает бизнес-вопроса или не готов на него быстро ответить в процессе проектирования, он на него не ответит и потом, как бы не клялся. соответствующий функционал надо убирать.
тз на не особо навороченный магаз это 25-40 листов с картинками или скетчами всех страниц. пишется 2-5 недель.
b. где agile? можно для неразвитых показать где он тут?
открыл вики, прочитал манифест. ничего не увидел тут у вас от agile. я без сарказма, я правда не понял
c. битрикс. пусть он хорош, не полезем в детали. мне кажется что тут дело не совсем в платформе. вы не доказываете что битрикс лучший, вы просто берете его как данность. хорошо.
если надо доказать что он крут, сравните с osCommerce хотя бы. покажите чем плох последний, чем плохи решения типа Magento
если вы видите серьезные преимущества Битрикса для проектных операций — расскажите подробности.
намеки есть, но честно я не увидел аргументов. много мнений без ссылок на проекты.
ссылок много, а статья отличная, дает задуматься.
Спасибо.
1) Для сложных высоконагруженных проектов (1-5% от общего числа проектов на платформе, думаю) иногда проще написать компоненты на чистом АПИ платформы Битрикс, чем кастомизировать стандартные.
2) Если Клиент злостно отказывается включать мозги, прикидывется идиотом, но при этом отлично считает деньги… значит, он скорее всего никогда не обламывался, получая за свое злостно-бестолковое поведение и троллинг кучу неуправляемого информационного г… на, которое нельзя развивать. Клиент, как правило, становится адекватным, когда два или три раза обломается, а затем все таки начнет думать, разбираться в системе и читать собственное ТЗ, т.е. ХОЧЕТ СОЗДАТЬ ПРОЕКТ С РАЗРАБОТЧИКАМИ, а не хочет получать зарплату за троллинг :-) Некоторые команды поэтому работают только с Клиентами «после второго, третьего автоматизатора».
3) Верстка… согласен, бывает сложная верстка шаблона, дня может не хватить. Я имел в виду настройку верстки для шаблона сайта (хедер/футер) — не конкретных компонентов.
4) см. п. 2. Постараться решить юридически, приложением к договору. Бизнес-процессы в своей компании клиент должен либо знать либо заранее описать, пригласив отдельно бизнес-аналитика, бухгалтера и т.п. Уверен — этими задачами не должны заниматься разработчики :-)
а) Это в моей трудовой биографии есть. Большинство сложных проектов на платформе Битрикс с такой высокой скоростью и делались. Проекты, которые делаются год и более — как правило из-за бардака с требованиями на стороне клиента, который просто НЕ ГОТОВ к разработке.
b) Эффективное короткое ТЗ, итерационный подход, участие клиента (не смотреть п.2 :-)) в проектировании и разработке, эффективные техники программирования и оценки, эффективное использование инструментов аудита платформы Битрикс, быстрый результат.
с) Magento — высокий уровень вхождения, люди должны понимать ООП и стоить дорого, однако по функционалу не такой широкий как Битрикс, всего процентов 10-15% функционала имхо.
d) Философия Битрикс — модульность, управляемость системы клиентом, встроенные инструменты глубокого аудита и на подходе чеклист контроля качества внедрения — вот преимущества для проектных операций, точнее их неполный список.
1) Для сложных высоконагруженных проектов (1-5% от общего числа проектов на платформе, думаю) иногда проще написать компоненты на чистом АПИ платформы Битрикс, чем кастомизировать стандартные.
2) Если Клиент злостно отказывается включать мозги, прикидывется идиотом, но при этом отлично считает деньги… значит, он скорее всего никогда не обламывался, получая за свое злостно-бестолковое поведение и троллинг кучу неуправляемого информационного г… на, которое нельзя развивать. Клиент, как правило, становится адекватным, когда два или три раза обломается, а затем все таки начнет думать, разбираться в системе и читать собственное ТЗ, т.е. ХОЧЕТ СОЗДАТЬ ПРОЕКТ С РАЗРАБОТЧИКАМИ, а не хочет получать зарплату за троллинг :-) Некоторые команды поэтому работают только с Клиентами «после второго, третьего автоматизатора».
3) Верстка… согласен, бывает сложная верстка шаблона, дня может не хватить. Я имел в виду настройку верстки для шаблона сайта (хедер/футер) — не конкретных компонентов.
4) см. п. 2. Постараться решить юридически, приложением к договору. Бизнес-процессы в своей компании клиент должен либо знать либо заранее описать, пригласив отдельно бизнес-аналитика, бухгалтера и т.п. Уверен — этими задачами не должны заниматься разработчики :-)
а) Это в моей трудовой биографии есть. Большинство сложных проектов на платформе Битрикс с такой высокой скоростью и делались. Проекты, которые делаются год и более — как правило из-за бардака с требованиями на стороне клиента, который просто НЕ ГОТОВ к разработке.
b) Эффективное короткое ТЗ, итерационный подход, участие клиента (не смотреть п.2 :-)) в проектировании и разработке, эффективные техники программирования и оценки, эффективное использование инструментов аудита платформы Битрикс, быстрый результат.
с) Magento — высокий уровень вхождения, люди должны понимать ООП и стоить дорого, однако по функционалу не такой широкий как Битрикс, всего процентов 10-15% функционала имхо.
d) Философия Битрикс — модульность, управляемость системы клиентом, встроенные инструменты глубокого аудита и на подходе чеклист контроля качества внедрения — вот преимущества для проектных операций, точнее их неполный список.
Sign up to leave a comment.
Agile проектирование, разработка и запуск высоконагруженного интернет-магазина на платформе 1С-Битрикс — за 4 месяца