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

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

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

История

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Предпосылки

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

Часто мы делаем проекты продолжительностью в несколько месяцев. При этом горизонт планирования команд в Сибириксе — порядка пяти недель. В переложении на спринты — 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 с управлением данными из админки Битрикса.

Среди компаний веб-разработки принято мериться «показателями успешности». Кроме первичных признаков, вроде количества именитых клиентов и толщины портфолио, были придуманы и вторичные — рейтинги.

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

Кстати, сегодня запускает голосование Tagline, один из самых крупных российских рейтингов студий веб-разработки и интернет-агентств.

В свете актуальности вопроса, небольшое исследование. По порядку:

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

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

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

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

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

Вам тоже недавно приходили оповещения от Facebook-приложений? Со смыслом «мы тут кое-что поменяли в API, поэтому, возможно, приложение такое-то скоро начнет работать некорректно».

Дело в том, что не так давно Facebook внедрил новую практику Breaking Change Policy (если по-русски, то что-то вроде «Политика критических изменений»). Социальная сеть уведомляет разработчиков о грядущих «перестройках» в API, что, соответственно, требует изменений в коде уже существующих приложений. И которые надо будет учесть при разработке новых, естественно. Facebook призывает разработчиков подписаться на блог, дабы не пропустить ничего важного.

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

Привет, Хабр!

Недавно запустили в работу новую фичу — еженедельные отчеты для клиентов. Суть такова: руководитель проекта каждый понедельник составляет письмо-отчет, в котором описывает текущую ситуацию по проекту. И отправляет клиенту. Особенность в том, что для отчета мы придумали особую форму. Сейчас расскажу по порядку.

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

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

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

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

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

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

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

Для написания этой заметки  было затрачено:

• 68338 километров на поездки.
• 72 человеко-часа на почтовую переписку.
• 423 человеко-часа на эксперименты с коллективом в 30 человек.
• 88 часов на подготовку докладов и выступления на конференциях.
• 17 чашек кофе на беседу с мудрыми людьми на афтепати.
• Порядка 25 часов на набор этого текста и правку багов в нем :).
• До смерти замученный копирайтер, который был вынужден разбирать мои черновики, аудиозаписи и вообще ему спасибо.

Много денег и времени. Пожалуй, самым затратным (по нервам, времени и деньгам) был эксперимент над собственной командой, о котором мне безумно неловко вспоминать. Но об этом — ниже.

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

Смысл такого подхода: платить по справедливости. На сколько наработал — столько и получил. Это честно, это логично, это — прекрасно!

Ну, логично же, что:

• Продажникам  нужно назначать процент с оборота. Волки должны быть голодными. (Да, есть альтернативное мнение, что применить такой подход — значит «обложить себя дополнительным налогом». Но как по мне — тут все справедливо :-)).
• Офисному планктону — ставить оклад. Стабильность для них — ооочень важное условие существования.

А вот с творческими единицами (дизайнерами, программистами) — все значительно сложнее.

Мы недавно провели опрос руководителей ведущих диджитал-агентств и веб-студий страны на тему «а как вы используете KPI по отношению к труду творческих единиц», в результате получили вот такую картинку:



Некоторые компании (15%) применяют KPI для оценки эффективности труда программистов и дизайнеров.

Обнаруживаю себя вечером в 9 часов на работе, с гневным клиентом в ICQ, которому «срочно надо», и в попытке привести в рабочее состояние код, который сегодня писал другой программист. Похоже, сегодня запустить это не получится. Клиент не стесняется в выражениях, давит на чувство вины. Жутко стыдно. От долгого сидения за компом болят глаза. От необходимости отлаживать и разгребать чужой говнокод — спина. Если у вас болит спина — скорее всего, вы прямо сейчас должны делать работу, которую ненавидите. В голове — отчаянье, злость. И долбит мысль:

Я
Не хочу
Отвечать за чужие косяки

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

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

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

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

Всем привет!

Недавно мы сдали большой и интересный проект «Карта Таланта», визуализатор резюме. О нем и хотим рассказать. Наверное, последним нашим подопечным из проектов такого масштаба был Restlook, автор которого даже написал на хабр пост про то, как всё было.

Итак, к сути.

Автор оригинальной идеи этой статьи — Джон Иннс, консультант в области гибких методологий IT-разработки. С первоисточником можно познакомиться здесь. Мы его немного доработали, много упростили, но теперь статью, хотя бы, можно читать :)



Итак, есть такая штука, как опыт пользовательского взаимодействия (тот самый UX, User Experience). В целом, UX — это впечатление пользователя от вашего продукта (например, сайта). Сюда относится внешний вид, удобство расположения кнопок, ссылок и других элементов.

Почему учитывать опыт взаимодействия — важно?

Фэйлом кончаются от 30% до 50% попыток внедрить штатную интеграцию сайта с 1С. Это коллеги рассказали, у меня-то в бизнес-плане заложено 75%. То есть, в трех случаях из четырех — придется что-то подкручивать напильником, а в одном — вообще вызывать эвакуатор или реанимацию. И чего бы это, ведь…

… Топовые производители современных отечественных систем управления в один голос заявляют, что умеют интегрироваться с 1С. Естественно, это касается по большей части типовых конфигураций — всего не предусмотришь, ага. Да и маркетинг заставляет говорить, что «это просто!». Слоган, который, наверное, никогда не умрет.

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



Так что знакомимся с горьким опытом и делимся своим:

Меня просто бесит, когда менеджер проекта отправляет макет дизайна — письмом, с припиской «Вот, нарисовали. Смотрите. Ждем ваших замечаний». Убил бы.

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

— Это возмутительно! И вот почему: