Спустя три года (!) оно случилось: теперь для того, чтобы платить страховые взносы по сниженной ставке в 14%, нужно иметь 7 сотрудников в штате. Раньше минимальный порог равнялся 30. Пруфлинк на Минкомсвязь России.

Самая важная часть:

«Принятый закон меняет порог численности сотрудников в компаниях, претендующих на льготы, с 30 до 7 человек».

История

Три года назад, в 2010-м, Дума подготовила изменения в Федеральном законе «О страховых взносах в Пенсионный фонд Российской Федерации, Фонд социального страхования Российской Федерации, Федеральный фонд обязательного медицинского страхования». Суть изменений была прекрасна: для малых ИТ-компаний процент страховых отчислений снижался до 14% вместо стандартных 34%. Загвоздка была в самом определении малых ИТ-компаний, а именно:

• Количество сотрудников компании — не менее 50 (потом снизили до 30, но в корне это ничего не поменяло).
• Доля доходов от реализации ИТ-продуктов и оказания ИТ-услуг — не менее 90%

Со вторым у большинства веб-разработчиков проблем бы не возникло, а вот первое — фактически сводило на нет всю полезность закона. Мы решили пойти в наступление.

Нерешенные задачи

Нововведение касается первых этапов работы над проектом: выяснения требований и дизайна. Собственно, неважных этапов в разработке не бывает, но эти — основополагающие, так как с них всё начинается.

Вспомните, какие самые болезненные проблемы разработки дизайна? Их, как минимум, три:

• Нет контента.
• НЕТ КОНТЕНТА!
• Резкая замена лица, принимающего решение (ЛПР). И, как вероятное следствие, смена общей концепции сайта.

Итого, имеем: ЛПР никак не выражает свое мнение ровно до того момента, как дизайнер демонстрирует ему готовый, с любовью сделанный, результат. А как только это произошло — предъявляет список правок.

*Whoision — официальное название сервиса, с налетом еле заметной иронии.

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

Сам по себе сервис прекрасный, там можно даже связывать макеты отдельных страничек в прототип. Одна загвоздка — ограничение по количеству активных проектов и участников демонстрации. Платный аккаунт всё решает, но у наших ребят давно зачесались руки устроить хакатон. А это значит, что мы построим свой Инвижин, с драг-н-дропом и Google-синхронизацией.

На весь проект у нас одни сутки. Сознаемся, дизайн и верстку мы вынесли за пределы хакатона — делали всё это непосредственно перед ним. Как и тестирование, которое мы перенесли на следующий день. Всё это, с одной стороны, нивелирует наш героический подвиг, но с другой — романтики в нем меньше не становится.

Итак, хроника рабочего процесса со слов участников. В конце — ссылка на сам сервис, для нетерпеливых.

У нас в студии всё, что не визуализировано, — рано или поздно этому подвергнется. Сегодня рассказ о нововведении, которое сделало работу по сделкам прозрачной и украсило скучную стену.

Предпосылки

Перед тем, как проект берется в работу, он проходит через «переговорные» этапы: брифование, обсуждение бюджета и т.п. Всем этим занимается аккаунт-менеджер. У нас два аккаунта и на каждом одновременно «висит» по нескольку десятков проектов.

Вся статистика в статье представлена только по нашему опыту и может расходиться с вашими данными (проанализировано 68 проектов на SEO, из них 26 — наша разработка и продвижение, а также 23 проекта, где разработка наша, а оптимизация — на стороне).

Web-разработчики очень не любят SEO-оптимизаторов. Естественно, основная проблема в генетически заложенной видовой ненависти, правда, есть и рациональные моменты. Но страдают-то от этого в первую очередь заказчики.

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

Часто мы делаем проекты продолжительностью в несколько месяцев. При этом горизонт планирования команд в Сибириксе — порядка пяти недель. В переложении на спринты — 3-5 спринтов (зависит от опыта конкретной команды).

Я использую два монитора, Google-календарь, Scrumban, общую тетрадь и песочные часы. Сам способ постоянно дорабатывается, но общие принципы остаются неизменными: держать под рукой все проекты в рукописном виде + управлять движением проектов на виртуальной канбан-доске.



Сама процедура занимает 2 часа в неделю. Этого времени достаточно, чтобы распланировать нагрузку примерно на 35-50 человек. Удобно делать либо рано утром в понедельник, либо в пятницу, во второй половине дня, либо в воскресенье вечером.

Сам термин «геймификация», вы, наверняка, слышали — он в последнее время снова стал модным. Означает примерно следующее: перенос игровых механик на неигровые процессы. Отчего последние (по задумке) становятся увлекательнее и охотнее воспринимаются теми, кто в них вовлечен.

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

Пожалуй, это был один из самых муторных челленжей для меня за последнее время.

Итак. Мы занимаемся технически сложными проектами, потенциально рассчитанными на высокие нагрузки (highload). Так получилось, что среди систем управления контентом пока победил Битрикс. Его хотят клиенты. Судя по нашему опыту — highload на Битриксе — очень даже реальная задача, если делать все аккуратно.



Обычно в проектах, где много форм, личных кабинетов или какая-то сложная логика — мы предлагали на выбор клиенту реализацию на Zend Framewok или на Битрикс. Минус ZendFramework был в том, что на нем нужно писать админку. Минус Битрикса — он плохо приспособлен под проекты со сложной бизнес-логикой: там толком нет MVC и местами отвратительный код и API. Маркетинговые байки-балалайки про ядро D7, которым уже 2 года — мы в расчёт не берем:

«Talk is cheap. Show me the code» (Linus)

Итак, возникла идея на сложных проектах использовать ZendFramework с управлением данными из админки Битрикса.

Я очень ленив, чтобы серьезно заниматься риск-менеджментом. Всегда считал это полной чушью, созданной неудачниками для отмазок в стиле: «А! Мы же говорили, что у вас ничего не получится!» Вон из моего проекта!

Кроме того — мы применяем аджайл. Мелкие итерации. И наши риски, и риски клиентов — ничтожно малы! А еще у нас есть типовые и четко очерченные в договорных отношениях этапы (не путать с agile-итерациями ;). Каждый раз, когда мы сталкиваемся с неопределенностью — мы разбиваем задачу на несколько мелких этапов и наши риски снижаются. Это же просто! Да? А теперь плохая новость:

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

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

Итак, у нас есть абсолютно типовые этапы:

Проблема создания качественного пользовательского интерфейса (UX-интерфейса) действительно существует. Конкретно — она проявляется, когда компания-разработчик использует гибкие методологи. Собственно причина того есть совокупность двух моментов:

• Итеративность работы программистов. В Agile разработчики предпочитают создавать проект «по частям», отдельными итерациями. И таким же образом «передавать» получающийся продукт заказчику.
• «Целостность» работы дизайнеров. UX-дизайнеры предпочитают продумывать и разрабатывать концепцию целиком. Соответственно, по готовности цельной концепции — они передают ее в разработку. Такой подход заставляет дизайнеров выбиваться из общего ритма, что порождает проблемы с распределением рабочего времени.

Намечается два пути: оставить дизайнеров в покое или попытаться вовлечь их в Agile (притом стараясь никого не покалечить). В первом случае придется жертвовать темпом, во втором — качеством конечного продукта. Или есть третий путь?

Сначала пример с большой красной машиной

Хочу поделиться опытом размещения приложений в социальных сетях.

Никого не удивлю, если скажу, что самые известные соцсети на территории нашей родины — это ВКонтакте, Одноклассники, Мой Мир и Facebook. Твиттер и YouTube в счет не берем, потому что там нет каталога приложений. Другие социальные сети не дотягивают по популярности и поэтому не представляют интереса.

Поедем вперед по списку. В качестве подопытного будет выступать наш Fresh Shop — магазин-приложение в социальных сетях.

Для удобства восприятия каждый кейс будет разбит на три шага, а в конце будут приведены итоги.

Третий раз за последний месяц встречаюсь с тем, как троллят разработчиков, практикующих всякие SCRUM/XP/AGILE и другие страшные слова. Вообще — есть за что. Значит, смысл такой:

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

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

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

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

Помнится, кстати, что в комментариях к статьям о проектировании мне задавали такие вопросы вроде «А что делать, когда нет времени и денег на проектирование?». Ответ ниже.

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

Проблематика

Если подходить к задаче разработки большого интернет-магазина формально, описывая каждый миллиметр будущего проекта, то у вас получится ТЗ на несколько сотен, если не тысяч листов и десятки диаграмм и экранных форм. И писать вы его будете, скорее всего, не менее полугода… впятером, ночуя на работе. Но самое «страшное» впереди — когда вы его наконец торжественно допишите и объявите об этом выпучив воспаленные глаза, с огромной долей вероятности поменяются требования к проекту: рыночные условия за полгода изменились, приходят и уходят люди, ваши начальники и подчиненные, появляются новые идеи и у них и у вас и т.п. И придется срочно нанимать 10 переписчиков и так до бесконечности :-)

С другой стороны, если ТЗ написать маленьким, страниц на 10, за выходные, и все его согласуют… не читая, то вам придется поселиться в команде разработки для конкретизации требований и ответов на поражающие своей точностью мозгоразжижающие вопросы: «А напишите пожалуйста формулу расчета скидки при оплате продукта долларами с учетом погрешности машинного нуля». Скорее всего, больше недели вы не продержитесь и проект так и не появится.
Так что же делать, если на проектирование отведен месяц, на программирование — три, вы не хотите поселяться в команде разработки, а кто-то уже публично объявил дату запуска проекта? :-)

Сделать в России простую и удобную платёжную систему как для продавца, так и для покупателя — серьёзный вызов для любого UX-специалиста/проектировщика интерфейсов. Чем интереснее и сложнее задача, тем больше опыта и знаний получаешь в процессе работы. Именно над такой задачей я работаю и в этой статье хотел бы поделиться полученным опытом по перепроектированию и доработке системы интернет-платежей A1Pay.

В статье рассмотрены этапы работы, решения, которые были приняты и то, на чём они основывались. Описать в одной статье все интересные идеи, возникшие трудности и их решения, находки и т.д. -. не простая задача. Часть важных вопросов, например, измеряемые KPI и их значения, по понятным причинам, остались совсем за рамками.

Почти у всех SEO-компаний, компаний занимающихся контекстной рекламой, медийной рекламой и другими подобными услугами по привлечению трафика на сайт, есть одна большая проблема. Эта проблема — заказчики, недовольные даже когда все обязательства по договору выполнены на 5+. Менеджерам приходится ежемесячно по сути заново продавать услугу, и с каждым разом это сложнее. Самое неприятное, что с аргументами заказчика не поспоришь — с сайта нет заказов. О решении этой проблемы и поговорим.

Для начала разберемся с причинами
(смотрим с точки зрения руководителя SEO-компании)

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

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

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

Так в чем же? На самом деле выявить причины нулевой (или близкой к тому) конверсии можно за пару часов. Раз никто не виноват, еще раз взгляните на сайт, с которого все ждут заказов (по-умному это называется аудит-сайта, точнее — экспресс-аудит).

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

Этот дайджест основан на моем приличном опыте мониторинга и анализа сайтов на рынке веб-разработок (исследования конкурентов в ADV, мониторинг и анализ участников «Тэглайн», проведение заказных аудитов для студий и пр.).

Я попытался систематизировать основные «ляпы» и упущения по нескольким основным категориям, на которых и остановлюсь подробнее:

• Ошибки позиционирования;
• Ошибки расстановки приоритетов;
• Неправильная презентация компании и услуг;
• Неправильная презентация портфолио и кейсов;
• Ошибки в коммуникации с заказчиком;

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

Одним прекрасным утром к нам в офис забежал молодой парень, с амбициозной идеей и “средствами для реализации” в кармане. “Заходишь на сайт, а там — телевизор. К нему можно подключиться через свою web-камеру. Одновременно может вещать только один человек, остальные — ждут своей очереди (но можно посмотреть скриншоты с их вебкамер). Задача каждого — удержаться в эфире, как можно дольше. Если выступающий нравится публике — все жмут “Cool!”, если подкачал — “Go away!”. И человек заменяется на следующего в очереди. Ну и можно в чат писать”.

Хорошая идея — драйвовый проект. Рисуем прототип, решаем реализовать обновление чата, списка пользователей, рейтинга и т.д. с помощью push-технологии. Это когда после загрузки страницы соединение между клиентом и сервером не закрывается, а продолжает использоваться для отправки сервером каких-либо событий на клиента.

Осторожно! Эта шняга может убить ваш сервер! Кстати, если вы вдруг решите написать высконагруженный скандинавский аукцион – истина и веселые картинки где-то рядом, под катом.