Меню

Eremeev Group / News

Строим сайты, пишем программы, занимаемся продвижением

Корабли в Туле

В Туле нет «настоящей» реки. Такой, как Волга или Енисей, но есть речной трамвайчик.

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

Для этого проекта мы сделали небольшой сайт.

 

Наши технологии / Technology Stack

Проект на грани невозможного?
Давайте обсудим детали.

Эта страничка для роботов поисковых систем.

Она рассказывает о том, на чем и как мы готовы программировать.

Если вы не поисковый робот и вам действительно интересен наш стёк технологий (technology stack), ответ прост: давайте обсудим ваш проект и решим, какие технологии и методологии управления разработкой наиболее оптимальны для конкретной задачи.

 

Подробности нашего технологического стёка:

Наши технологии / Technology Stack

«Воспитательная работа», которая убьет ваш проект

Крепостное право в России отменили в 1861 году. В 1863 году открылась первая ветка лондонского метро. Эти две даты в совокупности демонстрируют днище в договороспособности нашего контингента и некоторое отсутствие самоуважения. В чем это все проявляется? Например, отношение «я начальник — ты дурак» проходят как в классическом режиме найма, так и в контрактных взаимоотношениях. Начинается все с того, что разработчик заранее соглашается с нереальными (или близким к нереальным) сроками сдачи этапов. Соглашается, хотя и клиент и разработчик отлично понимают, что озвученные  сроки будут безбожно про… сорваны. Конечно, если перед работами будет составлено подробное техзадание и разработчик «вопрётся» в задачу на фуллтайм, то все или почти все будет сделано вовремя. Но нормальных техзаданий не любят клиенты.
Почему не любят? Очень просто: ТЗ может разрабатываться неделю, две, месяц, а клиенту хочется с первого дня начать “рисовать дизайн” и вообще — документы это просто скучно. Клиент даже может услышать где-то слово agile («аджайл») и говорить, что у него все по agile. Да, agile позволяет сделать нечто, показать клиенту, а потом перерабатывать, но такая работа сразу отодвигает за горизонт понятие готового продукта, так как и клиент и разработчик не понимают, чем все кончится. А если такого понимания нет, то здесь лучше договариваться на помесячную оплату работ и нечеткий график сдачи этапов.

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

Естественно, нормальный разработчик до определенного момента будет пробовать спасти ситуацию, делая требуемые клиентом доработки и ожидая оплат, но долго это продолжаться не может. В некоторых ситуациях, видя, что способ «воспитательной работы» вроде бы действует («мы этим дебилам не платим, а они делают всё, что говорим»), заказчик уходит за грань адеквата и требует выполнения ранее не оговоренных задач. Одна задача, вторая, неделя задержки оплаты, вторая… и разработчик просто перестанет реагировать, находя законные способы выйти из проекта. Одним из оправданий (если дело дойдет до суда) будет та самая задержка оплаты. А если таких задержек или вовсе неоплат несколько, о чем вообще речь?

Что в итоге?
Варианты:
— проект закроют;
— передадут другим разработчикам (которые тоже пообещают волшебство);

Клиент и разработчик разойдутся, не позволяя себе признаться в очевидном:
— Разработчику не нужно заниматься благотворительностью и не кредитовать старых клиентов за счет новых (или просто одних за счет других).
— Заказчику важно понимать, что качественная работа стоит своевременных денег, а среднестатистический программист должен как минимум ежедневно принимать пищу и иметь кров над головой.

Как бы мы, программисты/дизайнеры/менеджеры, не любили свою работу — это совершенно не означает, что мы должны ставить под угрозу существования своё здоровье, семьи, жить в коробке из под мебели возле офиса заказчика и питаться с его помойки.

И все же, иногда мы работаем бесплатно или почти бесплатно. Когда нарабатываем портфолио, когда давно знаем клиента, когда помимо денег получаем брендового клиента, который поднимает наш статус под небеса. Или когда сами делаем собственные инвестиционные продукты, уже для себя. Но в этих историях всегда важен work/life баланс и понимание финвопроса. Как со стороны заказчика, так и со стороны исполнителя.

В ближайших выпусках выйдет статья «Работаем по уму». Если будет соблюдено хотя бы 50% из описанного — ваш проект спасён!

А теперь — ещё немного философии. С одной стороны, мы дети и внуки героев, которые не раз прогоняли всяких уродов с нашей земли. А с другой – мы же потомки холопов и самодуров. Мы можем в стрессе и напряге решать проблемы мирового масштаба. Прогнать фашистов, построить БАМ или запустить Гагарина в космос. Но когда надо грамотно распланировать сроки задач, рассчитать поток финансов и учитывать ресурсы — наш «типаж» дает сбой. Над этим можно и нужно усердно работать, выживая из себя ущербную психологию. Тесто, из которого сделан барин-самодур и вечно оправдывающийся холоп, вполне можно перемесить и начать наводить порядок, начиная с себя. Так мы вместе добьемся успеха.

Если ты заказчик, у тебя нет денег, но проект нужен – скажи сразу, не дури с оплатой аванса и задержками платежей «в воспитательных целях». Всегда можно найти разработчика, озвучить ситуацию и поискать выходы. Разумную постоплату также никто не отменял, но она должна быть в договоре, а не по факту в виде задержек. То же самое и к исполнителю: проработай свои бизнес-процессы, пиши техзадания, рисуй макеты, утверждай под расписку у клиента каждый этап работы и не двигайся без оплаты ни на сантиметр. Озвучивай причины остановки «где бабло бля?», а не занимайся вежливыми оправданиями «скоро всё будет готово», в то время, как истерящему «когда все будет готово?!» клиенту клиенту весьма начихать на то, что едят твои программисты и дизайнеры.

Хранитель кода или дровосек?

 

В индустрии разработки программ и сайтов практически каждый день происходят стандартные, связанные между собой истории:

История 1:
Некто однажды заказал себе сайт или программу. Сайт или программа нормально работали полгода-год-два-три. Или даже десять! И вдруг понадобились какие-то доработки. Предыдущий разработчик «куда-то пропал», либо по каким-то причинам не может взяться за доработки. Найден новый, который готов сделать доработки и здесь начинается…

История 2:
Новый разработчик говорит: «Да тут полный [рифма от слова молодец], надо ВСЁ ПЕРЕДЕЛЫВАТЬ». И далее следуют тирады о криворукости предыдущих разработчиков, их неспособности сделать хоть что-то толковое и так далее.

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

Фишка 1: Паттерны программирования
Это даже не проблема, это закон IT-индустрии. Несмотря на внешнюю заформализованность нашей, программерской, работы, одну и ту же задачу можно спрограммировать по-разному. Скажу больше, по-разному это вообще даже не то слово. Все истории и попытки «внести науку» в виде паттернов программирования, готовых блоков и фреймворков добавляют удобства, но практически не решают проблему. Да, хорошо, что программируя под Windows можно не париться о том, как рисовать кнопку, достаточно «побросать» кнопки на проектируемую форму программы и… И начать программировать действия, происходящие при щелчках по этим кнопкам. И… (слишком много «И», но это для важности момента) И… здесь мы снова возвращаемся к проблеме множественной вариативности реализации одной и той же задачи.

Например, есть такое понятие, как «индусский код». Так вот, на ассемблере есть команда NOP (NO OPERATION) и HLT (HALT). Они обе подтормаживают программу, каждая со своими особенностями. Если вам надо так или иначе подтормозить процесс, вы используете в соответствующих случаях NOP или HLT. NOP просто ничего не делает, а HLT при особом подходе еще позволяет оттормозиться так, чтобы не греть саму микросхему процессора, что в определенных промышленных задачах может быть важно (энергосбережение). Иной раз приходится видеть, как одни разработчики используют NOP и/или HLT, а разработчики из Индии, зная сколько тактов процессора занимает то или иное вычисление, задают расчет совершенно ненужных цифр вместо того, чтобы остановить процессор и не жрать аккумулятор и не греть микросхему.

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

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

Либо вовсе получает от клиента отмашку на «переделать все, но, чтобы экраны/страницы выглядели как раньше».

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

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

Допустим, взять код у каждого из описанных выше программистов и предложить поддерживать код друг друга – от обоих друг о друге можно наслушаться такого, что уши завянут сразу.
Фишка 2: Финансово-организационный вопрос
Вам сделали проект, вы за него заплатили N рублей. Кто сделал – не важно, это может быть и программист на удаленке и компания по договору, бывает всякое. Через полгода-год и т.д. «необщения» у вас и у того разработчика могут быть совершенно другие жизненные/бизнесовые и прочие обстоятельства.

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

У вас за время «необщения» может накопиться список доработок, который по бюджету может быть уже не особо интересен разработчику и т.д.

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

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

Конечно, подобная организация процесса, наверное, гораздо лучше работает только на больших проектах и вообще не работает на «мелких», но, смеем заметить, по нашему опыту – работает везде!

Что такое «мелкий» проект? Например, сайт небольшой фирмы, который у разных исполнителей может стоить как 10 000, так и 100 000 рублей (в зависимости от наглости исполнителя и подходу к оценке своих трудозатрат). Мы делаем такой проект за 50 000 рублей, но при условии, что клиент заходит к нам на поддержку. Поддержка обычно включает в себя работы по наполнению сайта, ведению контекста, размещению сайта на нашем оборудовании (хостинг). В итоге первоначальные затраты на проект снижаются, а клиент получает «одно окно» для решения всех своих задач по сайту, который по сути и зачастую является лишь частью того digital-маркетинг-микса, который мы предлагаем. Стартовая цена сайта размывается в годовой поддержке, а клиенту с нами более удобно, чем с десятком разных поставщиков.

Примерно так же и с небольшими приложениями. Бюджет на разработку и контракт на год, по которому мы выделяем 5-10-15 часов в месяц программиста для всплывающих доработок. Если эти часы не используются – то они «сгорают», но в этом случае клиент всегда уверен в том, что любые просьбы по доработке будут выполнены, исходники не потеряются и вообще – ведь у продукта есть «хранитель кода», который не будет называть дровосеками предыдущих разработчиков, а спокойно доработает продукт при необходимости и проконсультирует пользователей.

Бесплатный сыр для Mac-пользователей

Возможно, вы имеете некоторое отношение к разработке и поддержке сайтов. Также возможно, что вы работаете на Маке. Иногда вы генерируете для своих сайтов sitemap.xml файлы, а при запуске рекламных кампаний строите utm-ссылки пачками. Теперь у вас есть две бесплатные программы под Мак, которые умеют это все:

Пакетный конструктор UTM-ссылок
https://itunes.apple.com/us/app/utm-link-bulk-builder/id1192250018

Простой и дерзкий генератор sitemap.xml
https://itunes.apple.com/us/app/simplesitemapgenerator/id1191222999

 

Однажды мы столкнулись с «проблемой именного портфолио». На самом деле, новому потенциальному клиенту вообще все равно, делал ты софт для вот того крутого клиента или нет. Если делал, то реализованное решение крутится где-то там, в кабинетах Пенсионного фонда РФ или в на складе какого-то винодела в Бордо, и показать потенциальному клиенту реальный продукт в работе весьма сложно. «Коробочные» же клиентские приложения на iOS/Android в 100% проектов выкладываются под аккаунтами заказчиков и здесь тоже кроме «мы делали вот то» не работает. Софт это не сайты, где можно в подвале написать «сделано теми-то», хотя и с сайтами все непросто. Иной раз в сложных и крупных вебпроектах участвует несколько поставщиков и вряд ли кто-то захочет раскрывать всю «матрешку» исполнителей.

В итоге мы решили сделать пачку продуктов для массового пользователя — от утилит до игрушек.

Игрушки пока в работе, а утилитки — просто выложили на AppStore то, что изначально делали для себя под Mac. Для рекламных кампаний нужно часто собирать UTM-ссылки — сделали. А также для сайтов (иногда весьма больших) нужно иногда варить sitemap.xml, но на маке — тоже сделали. Оба приложения были выложены в начале января 2017 года и на старте они были платными. Всего за два месяца без какой-либо рекламы продано около 200 установок (активно играли с ценами от $3 до $19.99), после чего поток продаж рухнул и оживать не собирался. Ну, оно и понятно, мы особо и не рассчитывали здесь на сверхзаработки, это же простые приложения.

23 февраля 2017 года мы уронили ценники на $0, и, произошло страшное — менее, чем за сутки приложение для генерации sitemap.xml было скачано больше 400 раз.

Собственно, эксперимент считаем удавшимся и продолжим работать в принятом направлении: будем наполнять свой аккаунт приложениями разной степени платности. Теперь потенциальным клиентам будет гораздо сложнее вешать на нас ярлыки “неумех, у которых нет собственных продуктов на AppStore” [картинка—мем с усталым Железным Человеком].

Статистика красивая, но радоваться рано

Консалтинг в продвижении — одна из наших услуг. Обычно мы беремся за продвижение одновременно или после создания сайта для клиента. Зачастую ещё на этапе проектирования можно избежать подводных камней по SEO, usability и другим способам испортить жизнь сайту, Яндексу, Google, пользователям, и, в конечном счете, клиенту — владельцу сайта. Ведь, если сайтом невозможно пользоваться, его не могут проиндексировать поисковики, то и наш клиент вряд ли получит отдачу от такого проекта.

Изучим картинку:

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

Конечный KPI маркетинговых телодвижений — продажи.

Понимать, помнить и расширять аналитику от точки контакта с рекламой до продажи и постпродажного взаимодействия (допродать/продлить подписку, обратная связь по качеству и т.д.).

Дальше начинают работать следующие факторы: востребованность товара услуги, качество, цена и т.д.

Обновили раздел о сайтах

Если что, мы умеем делать сайты. Любые. От лэндинга-одностраничника до корпоративного портала.

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

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

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

Продолжить на сайте

Портирование приложений на Mac

Для предприятий, работающих на Windows-платформе и планирующих переход на Apple, мы предлагаем услуги по портированию приложений на Mac.

Удобно, красиво, быстро — и со всеми плюсами Mac-платформы.

Подробности: http://eremeev.ru/eremeev-group-about-company-software-development-porting-macos.php

Свежее / Портфолио / QuickAppNinja использует наш custom-сервис аналитики. Ура!

QuickAppNinja — конструктор приложений под Android.

Клиенты QuickAppNinja создают собственные приложения и размещают их в Google Play.

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

Имея опыт разработки высоконагруженных сервисов и аналитическим систем, специалисты Eremeev Group развернули первую очередь проекта.

Серверная часть разработанной системы собирает данные по установкам и сессиям (повторным запускам) работы системы, пакует их и передает по запросу в QuickAppNinja для анализа.

 

Система сбора данных разработана с использованием нашей технологии DigitalBurn.

Свежее / Портфолио / Английский Сад

Сайт «Английского Сада» (Тула). Он нам и самим нравится, да.

Хотите хороший сайт? Велком! 🙂

Помимо разработки сайта для клиента запущена и контролируется рекламная кампания в контексте.