Есть мнение, что рынок веб-разработки постепенно «схлопывается». Например, что заказчики обычных сайтов всё активнее пользуются конструкторами сайтов. Так ли это? Отчасти это мнение — результат кризиса и поговорки «у страха глаза велики». В качестве примера рассмотрим сегмент средних сайтов.

Что это за «средние сайты»? Произошло ли что-нибудь с этим сегментом в последнее время? Может быть, средние сайты никуда не делись?

Текст написан по мотивам выступления Романа Петрова (@romanpetrov), директора компании ITConstruct, на Партнерской конференции «1С-Битрикс».

Если вы озадачитесь поиском CRM, то на многочисленных форумах неизбежно столкнётесь с упоминанием системы Битрикс24 и её обсуждением. Сторонников и противников хватает: кто-то утверждает, что это не CRM вовсе (что правда), кто-то сводит весь функционал системы к корпоративному порталу, кто-то вспоминает про 12 бесплатных пользователей. Как и в любой другой компании, сотрудники Битрикс пристально следят за отзывами и обсуждениями наших продуктов в сети. Иногда нас удивляют отдельные комментарии и даже небылицы, связанные с Битрикс24. Но всему есть предел. О том, что же такое Битрикс24 на самом деле, как он может объединить компанию и помочь любому бизнесу, мы последовательно расскажем в нашем блоге на Хабре.

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

Продолжу рассказ на тему интеграции интернет-магазинов с бэкофисом и подходе к их решению в нашей реализации интеграции интернет-магазина 1С: Битрикс с системой 1С: Управление торговлей.

В первом посте на эту тему мы рассуждали о том, как были проанализированы задачи, которые стоят перед владельцами интернет-магазинов, выбрана концепция обмена данными и разработан протокол обмена между 1С и интернет-магазином.

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

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

Мне довелось продолжительное время работать менеджером-админом (эдакий играющий тренер) на большом 1С-Битрикс веб проекте: более 40 сайтов для разных организаций холдинга из разных стран, Oracle БД, редакция «Веб-Кластер», более 100 Гб файлов, несколько лет истории, более 20 правок ядра переживших множество обновлений Ядра, параноидальный режим безопасности и… прямые изменения функционала «руками» на боевом сервере без каких либо намёков на версионный контроль…
Очень грустная картина, вызывающая множество «несчастных случаев на производстве», которую после очередного инцидента была приказано исправить.

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

Знаете анекдот про самолет, в котором есть и бар, и бассейн, и ресторан, но только при взлете стюардесса говорит: «А теперь со всем этим мы попробуем взлететь»?

Веб-разработка немного похожа на такой самолет. Заказчик хочет от веб-студии и классный дизайн, и кучу интерактива, и все службы доставки и оплаты в интернет-магазины, студия с удовольствием все это программирует… А вот хватит ли мощностей сервера на обеспечение стабильной работы сайта — непонятно.
Чтобы нагрузка была прогнозируемой, чтобы задать некоторые эталонные значения, мы провели нагрузочное тестирование «1С-Битрикс: Управление сайтом» и «1С-Битрикс: Энтерпрайз».

Мы постарались так провести тестирование, чтобы клиент понимал, что можно получить на текущем оборудовании, а разработчик мог понять, каковы перспективы роста проекта. Получится ли отмасштабироваться при росте нагрузки?

В этой статье мы расскажем о том, как организовывали и проводили тестирование, и какие выводы для себя сделали.

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

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

Наш гендир Наталья Прокофьева посмотрела в календарь, увидела пятницу, 13-е, махнула на всё рукой и решила рассказать — для разнообразия — не об успехах, а о провалах. Точнее, об одном провальчике старта нового продукта.

Денег на ремонт не просим, чинить будем сами, а вот опытом с вами поделимся.

Муда, что по-японски означает «потери» — это любая деятельность, которая потребляет ресурсы, но не создает ценности для клиента. (Источник).



Эта короткая заметка для тех, кто системно ищет, где его студия теряет деньги. Похвальное занятие в наше весёлое время.

Хорошо систематизировали виды потерь ребята из Toyota. Тойотовцы выделяют 7-8 видов муды, потерь на производстве. Посмотрим, есть ли аналоги между потерями в автомобилестроении и работе студии.

Если вы продаете ПО, то наверняка при виде бюджетов больших корпораций задумывались, как бы и вам откусить кусочек от этого пирога. Лично мы в Web-payment.ru, проекте о платежных системах, постоянно ищем способы заполучить в партнеры крупные платежные системы или сервисы на рекламные услуги, разработку, или даже помощь в ведении блога на Хабре. В этой статье-переводе как раз пойдет речь о том, как работать с крупной рыбой. Сразу хотел бы предупредить, что наши реалии отличаются от западных, которые описываются в статье, но в чем-то они пересекаются, так что почитать интересно.

Многие задаются вопросом о продаже ПО офигенно большим организациям. Работать с такими крутыми компаниями в установленном вами ценовом диапазоне крайне непросто, так как любые величины меньше 500$ для них выглядят как ошибка в округлении. В то же время, наличие пары таких клиентов дарует вам социальную значимость, которая позволяет вам продавать как другим таким же гигантам, так и более мелким клиентам. Получив IBM в качестве клиента, вы ничего не потеряете. Ну а если при этом в самом IBM никого не уволили за выбор вас в качестве поставщика, значит, и вы вполне подходите для большой игры.

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

Мы пишем много разных теоретических материалов, и меня часто спрашивают "Андрей, теория — это хорошо, ну а покажи, как должно выглядеть конкретное предложение, которое ты считаешь хорошим?". Этот текст — мой развернутый, почти на 20 страниц, ответ на этот вопрос.

Я выбрал кейс, максимально приближенный к реалиям — и в виде полу-художественного повествования провел своего лирического героя Бубликова по всем этапам подготовки КП и участия в тендере. Давайте начнем:

Итак, в рамках кейса мы представляем выдуманную компанию «Студия Бубликова», работаем в Москве, основаны в 2008 году, в нашем штате 17 человек, мы специализируемся на продакшн-услугах, работаем на UMI, для пары-тройки давних клиентов ведем контекст и немного SMM, работаем по средней ставке в 1700 руб./час, имеем хорошую поддержку (с выстроенными процессами и выделенными ресурсами). Мы есть в некоторых рейтингах веб-студий в середине списка, пару раз в год выступаем с докладами на среднего размера конференциях, позиционируемся как хороший продакшн второго эшелона с сильной поддержкой. Наши клиенты — сфера услуг, ecommerce, несколько добывающих компаний, пара агентств недвижимости. Делаем, в основном, корпоративные сайты, магазины, иногда промо-сайты. Сложные большие сервисы и порталы особо не умеем.

Я тот самый Бубликов, чьим именем названа наша студия.

^{Фото с wiki.apidesign.org/wiki/HtmlForFood}

Здравствуйте. Мы подвели итоги проделанной за восемь лет работы, посчитали проекты, куда наша студия входила технологическим инвестором, проанализировали успехи и провалы. Несмотря на некоторый достигнутый прогресс, мы пришли к выводу, что coding for equity не работает.

Под катом – описание причин отказа от практики технологических инвестиций, причин провалов проектов, которые мы кодили for equity, и разных схем работы с основателями в зависимости от временного периода, размера студии, ситуации на рынке. А также – немного грусти, философии и лирики.

Подавляющая масса исследований и отчетов подтверждает тенденцию к превышению бюджетов и сроков программных проектов. В среднем, это превышение составляет порядка 30 процентов¹. Более того, если мы сравним точность оценивания в 1980-х и ту, которая фигурирует в недавних исследованиях, мы не обнаружим существенной разницы (Единственный анализ, предполагающий существенное улучшение качества оценки, встречается в отчетах Chaos Reports от Standish Group. Однако, это «улучшение», вероятнее всего, проистекает из того факта, что исследователи улучшили качество своих данных, перейдя от излишне перегруженной проблемными проектами, к более репрезентативной выборке²). Методы оценки также существенно не изменились. Несмотря на интенсивные исследования в области формальных моделей оценки, доминирующим методом продолжает оставаться «экспертная оценка»³

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

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

Традиционно, для тех кто не любит много буков, краткие (более-менее) тезисы:

• Будучи долгое время лидером на рынке, Нокиа сильно расслабилась и загадила свою внутреннюю инфраструктуру бюрократией, чрезмерным аутсорсингом и огромным количеством бесполезной «менеджерской прослойки».
• Будучи долгое время лидером, Нокиа просрала потратила много денег на ненужные операционные расходы, поглощения никому не нужных фирм и на невменяемую модель аутсорсинга.
• Полностью оторвавшись от реальности с уходом Йормы Оллилла, Нокиа, под управлением гениального юриста CEO Олли-Пекки Каласвуо, потратила кучу денег и усилий на создание бесполезной и неконкурентоспособной сервисной инфраструктуры Ovi. В результате этого, помимо денег, Нокиа потеряла уйму полезного времени, которое можно и нужно было потратить на развитие основного бизнеса — телефонов, софта и т.д.
• Бюрократия и непотопляемая менеджерская прослойка в Нокиа, последовательно мигрировала из одного передового проекта в другой, в составе одних и тех же групп лиц, самореплицируясь в виде кучи формальных дебилопроцессов комитетов и управленческих групп, немного перетасовываемых с учетом специфики. В итоге именно эта бюрократия убила и Symbian, и Ovi, и MeeGo и остальные попытки догнать уходящий поезд своими силами.
• Борьба с бюрократией и прослойкой в Нокиа зашла в полный тупик.
• У великого CEO Элопа просто не было другого выхода кроме как прибить всю старую, неповоротливую и прогнившую организацию, путем создания альянса с Майкрософтом и переходом на Windows Phone. Тем самым все старые процессы, компетенции, технологии и самое главное — люди резко стали, что называется, «не в тему». И следовательно тем самым можно было под благовидным предлогом прибить этот табун менеджеров, бесконечно рисующих фэнтезийные роадмапы с единорогами и перекладывающих бумаги с левого края стола на правый.
• Новая Нокиа, после 2011 года и старая Нокиа до 2011 года – это две РАЗНЫЕ организации. Их объединяет только общее название и операционка S40 для телефонов Asha.
• Горящая платформа, это не Symbian и не MeeGo. Горящая платформа, это то состояние в которое Нокиа загнали годы расслабленного лидерства и тупоголовые амбиции предыдущего CEO – Олли-Пекки Каласвуо с кликой подкаркивающих вице-президентов.
• С бюрократией и бизнес процессами, имеющимися на 2010 год, Нокиа не спас бы ни Андроид, ни половина населения Бангалора, пишущих на Qt под MeeGo. Даже если бы Apple бесплатно передал Нокиа iOS и все сервисы, то они бы выродились руками всяких Requirement Managerов в типичные Нокийские дизайн-химеры и в итоге загнулись через какое-то время.
• То, что сделал великий CEO Элоп – было единственно возможным разумным решением, дающим хоть какие-то шансы на выживание. Вопрос «каким образом он это сделал?», остается открытым, равно как и вопрос «поможет ли это Нокиа?» в итоге. Не следует забывать, что нынешняя Нокиа — это совершенно новая организация, поэтому глупо предполагать, что она разом вернет себе лидерство. Как и всем новым организациям ей придется за это лидерство долго бороться.
• Без ошибок и побед Нокиа никогда не было бы ни Андроида, ни Айфона. И Google и Apple тщательно проанализировали достоинства и недостатки более старших конкурентов перед тем как шагнуть вперед.

Все это в деталях — под катом. Предупреждаю что клевых картинок там нет. Сплошное графоманство и ёрничанье.

Предисловие

Не знаю, все ли программисты всесторонне любознательные люди, но я всегда пытаюсь получить фундаментальные знания во всех областях, которые могут быть практически полезны. В то время, когда мне в голову пришла эта идея я изучал анатомию и физиологию по журналам «Тело человека. Снаружи и внутри», ну а по работе я занимался стерео-варио фотографиями (для тех кто не знает — были такие советские календарики с ребристой поверхностью, где картинка либо казалась объемной, либо менялась). Так вот, в один из вечеров мне пришла в голову замечательная идея, которую я на протяжении уже 4х лет использую для поддержания своего зрения.
Обещаю, что эффект почувствуете сразу!

В данной статье хотелось бы поделиться с читателями своим личным опытом о китайских интернет-магазинах, в которых мне (или моим друзьям) приходилось делать покупки. Речь пойдет именно про электронный сегмент товаров. Сразу перейду к сути, и приведу обзоры этих самых магазинов с заключительной оценкой:

Привет, хабр. Не так давно мы написали модуль, который подключает магазины на 1С-Битрикс к социальной сети Facebook. Хочу поделиться опытом, а также особенностями настройки приема Facebook Credits в вашем магазине — не суть важно, на какой CMS он реализован. Помчались!

Сегодня в своем блоге Сергей Назарук опубликовал выдержки из стандарта, согласно которому должны разрабатываться веб-сайты государственных структур. Интересный документ.

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

Зачем вообще нужны стандраты? Чтобы по-меньше думать при принятии каких-то решений. При этом за счет накопленных и собранных в стандарт знаний повысить качество этих решений. Приведу пример. В 80х годах военное ведомство США озадачилось процедурой выбора вендоров на разработку и поставку ПО. Как выбирать подрядчиков? Надо было ввести какие-то показатели-уровни компаний, чтобы отделить тех, кто работает надежно, от тех кто работает как попало. В иделе этот показатель всего одно число: 1,2,3,4,5… Компания уровня 5ть лучше, чем компания уровня 3, поэтому работаем с компанией уровня 5ть. Так появился  стандарт CMMI (Capability Maturity Model Integration). У компании EPAM – 4й уровень (из 5ти), значит на рынке она выглядит привлекательнее тех у кого 2й или 3й.

Как-то мне приходилось сталкиваться с разработкой интернет-проектов для государственных органов. Занятие это непростое и сопряжено с массой рисков. Результат часто зависел только от качества налаженных отношений с конкретным чиновником. Но если его меняли – можно было выкидывать написанный продукт в мусор – его заместитель снова требовал странного. Единственный выход – четкая фиксация требований и каждого движения в проекте. Уже тогда я писал ТЗ по ГОСТам, что приводило в восторг чиновников.

Так зачем же нужен такой стандарт?

Продолжаю свой цикл статей про фреймворк.

[ExtJS] :: Часть 8. Меню и тулбары.
[ExtJS] :: Часть 9. Работа с графиками и диаграммами.
[ExtJS] :: Часть 10. Шаблоны в ExtJS

Ссылка на ресурс тут

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

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