Итак, «продукт» создан, есть какой-то маркетинг и первые сотрудники. Суммы «капают» на расчетный счет, пора расти дальше! И в этот момент, как рефлекс собаки Павлова, у 90% предпринимателей в голове возникает вопрос:

«А почему бы не внедрить CRM систему?»

Пошел процесс… Поиск вариантов… Подрядчики… Amo, 1С или Битрикс 24…

А ведь интуиция сидит на плече и подсказывает: «Мужик. Что-то не так. Как-то все очень туманно в этой автоматизации.»

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

Результат? CRM работает на 30% от своих возможностей, управление «не интуитивно», на все нужны инструкции, многие моменты не совпадают с практикой, сотрудники саботируют.

Что получаем «на выходе»? Возврат к Excel, потраченное время и деньги. Либо использование CRM, как органайзер. А процесс этот сродни ремонту в квартире — хочется, чтобы все было отлично и он по факту высасывает силы.

Проходит квартал и снова возврат к проблеме. Новый цикл, новые подрядчики, новая CRM и по кругу.

Почему так происходит и каким может быть решение?

Так происходит в России повсеместно. Мы часто перепрыгиваем один ключевой шаг, который называется «систематизация».

Кстати, а вам известно, что Россия занимает чуть ли не самое последнее место по производительности труда (по данным газеты «Ведомости»)?
За 1 человеко-час мы производим продукта на 25,9 долларов США, что меньше, чем в самых «отстающих» в Европе Латвии (27,6) и Польше (29,7), почти в 1,5 раза меньше, чем в Греции (36,2) и вдвое меньше среднего показателя стран еврозоны — 55,9 доллара США.

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

Вот вам еще одно подтверждение. Знаете, почему опытные участники рынка автоматизации — компания 1С — имеют столько «продуктов» и частенько люди отзываются о ней, как о «сложной»?

Потому что 1С работала по правилам рынка. Российские предприятия часто работают по принципу «многорукомногоного монстра» с огромным количеством «кусков». Все в хаосе. И они обратились к 1С с логичным запросом: «А теперь автоматизируйте мне все это!».

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

Вот метафора. Систематизация, как ядро атома. Вокруг которого кружат «электроны»: отдел продаж, маркетинг, финансы, найм сотрудников автоматизация. Без этого «ядра» все элементы движутся хаотично. А его наличие центрирует все эти элементы.

В заключении, резюмируя:

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

И вот когда «туман рассеялся», все перед глазами. Идет отсеивание лишнего и фокусировка на 20% действий, сотрудников, клиентов, продуктов, которые дают 80% результата. Бизнес становится такой аккуратной «коробочкой», которую легко автоматизировать и масштабировать.
ссылка на оригинал статьи https://habrahabr.ru/post/314082/

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

Превращаем планирование в точную науку

Как определить вектор развития продукта и совместить его полезность и инновационность? Для того, чтобы наши новые разработки с большей вероятностью «попали в цель», было принято решение провести глубокое исследование и на основе его результатов запланировать новую версию. Определением стратегии развития Macroscop занимается product-менеджер компании, и вот по какому алгоритму действовал он:

1. Выявить все идеи. Их может быть много, очень много.
Для того, чтобы найти все варианты новых функций, доработок и улучшений, product-менеджер Macroscop:
• общался с реальными пользователями продукта. Это были личные беседы с несколькими десятками людей на встречах или по skype, в ходе которых обсуждались их текущие потребности, идеи и проблемы;
• общался с технологическими лидерами отрасли на выставках, форумах и конференциях;
• общался с технической поддержкой и группой качества компании, чтобы понять их видение необходимых изменений и доработок на основе анализа проблем пользователей;
• проанализировал годовые цели разработчиков (каждый сотрудник компании формулирует в начале года свои личные цели);
• проанализировал около 10 тысяч оценок и комментариев к демо-версии Macroscop от тех, кто ее протестировал;
• проанализировал, какие модули видеоаналитики покупают чаще;
• проанализировал запросы на доработки ПО от крупных заказчиков;
• попросил менеджеров по продажам, пресейл-инженеров и специалистов по обучению партнеров составить свое видение необходимых доработок и разработок на основании их общения с партнерами в рамках своих направлений деятельности.

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

2. Взвесить каждую идею.
Если бы мы были неограничены в ресурсах, мы бы реализовали все 130 идей. Но необходимо было выбрать конкретные задачи. Для этого мы взвесили каждую идею по 10 параметрам. Если не вдаваться в подробности, то все сводилось к 2 параметрам — инновационность и необходимость пользователям прямо сейчас.
За необходимость отвечал целый набор весов с разной степенью влияния: пожелания пользователей непосредственно, пожелания менеджеров, пожелания разработчиков и т.д. Вторая оценка, оценка инновационности, делалась умозрительно: мы сами сели и подумали, насколько та или иная идея инновационна.

3. Визуализировать распределение.
Далее мы построили такой график: по одной оси отложили инновационность, по второй – необходимость пользователям прямо сейчас. Каждая идея превратилась в одну из точек на этом графике с координатами (вес инновационности; вес необходимости)

Очевидно, что все 130 задач не реализуешь в рамках ближайших версий, но надо выбирать те, что находятся ближе к области (+∞; +∞). То есть идеальная задача – суперинновационная и необходимая пользователям прямо сейчас, та, за которую пользователи готовы уже сегодня заплатить деньги и пользоваться ей.

Мы разделили график на 3 зоны:

1 зона (выше красной линии) – это те идеи, которые надо реализовать обязательно. Они обладают одновременно высоким уровнем инновационности и высоким уровнем необходимости.

2 зона (между красной и зеленой линиями) – эти задачи решаем по возможности.

3 зона (ниже зеленой линии) — неинновационные и ненужные задачи (кстати, большая часть из этих 130 идей туда и попала). И мы их не делаем

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

Перевести идею в цель

Есть такая формула: цель = мечта + срок исполнения. И без четких сроков все наши планы целями не являлись. Ситуация усложнялась тем, что мы (как и многие разработчики) иногда грешили затягиванием внутренних сроков выхода версий, которые сами же себе устанавливали.
Поэтому необходимо было продумать реальные, но амбициозные сроки реализации новых функций и доработок согласно полученного списка, которые мы будем соблюдать.

Павел Дуров говорил, что каждый месяц нужно выпускать какое-то определенное количество улучшений. В своем блоге он описывал ежемесячно 7 улучшений ВКонтакте: 7 улучшений ноября, 7 улучшений декабря и т.д.
Мы сочли позицию «Делай что хочешь, но выпускай 7 обновлений в месяц и ритмично развивай свой продукт» сильной и решили применить ее в Macroscop (естественно, адаптировав под нашу специфику).
Product-менеджер компании обсудил новую стратегию и срок 1 месяц с разработчиками и после долгих споров конструктивных обсуждений они договорились, что мы будем выпускать новую версию каждые 1,5 месяца.

Когда о сроке 1,5 месяца узнал технический директор, ответственный за тестирование новых версий продукта, он сказал, что это невозможно, так как сейчас мы каждую версию тестируем по 3 месяца. Потому что разработчики дописывают только новые функции и доработки, а они тестируют не только новинки, а ВЕСЬ ФУНКЦИОНАЛ с нуля. Версия, которая пришла от разработчиков – это черный ящик, который они должны проверить вдоль и поперек.

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

Итого получится, что каждые 1,5 месяца мы выпускаем версию, но пользователю уходит каждая вторая, протестированная версия. Чтобы понять, сколько улучшений мы должны выпускать каждые 1,5 месяца, мы проанализировали прежнюю скорость нашей разработки и получили все ту же цифру 7, которая в нашем случае включала: 1 завершенный шаг по инновациям (какой-то новый модуль видеоанализа или существенное улучшение текущего модуля) + 2 важных для пользователя функции или существенных улучшения + 4 прочих функции или улучшения.

Пользователь – главный эксперт

Еще один важный аспект, который мы ввели для повышения качества продукта — непосредственное общение разработчиков с пользователями. Раньше цепочка получения пожеланий от пользователей у нас была очень длинной: пользователь говорил что-то своему менеджеру – менеджер говорил это product-менеджеру – product-менеджер говорил это разработчикам, и, наконец, они разрабатывали. В итоге иногда получалось, что то, что сделали разработчики не совсем совпадало с тем, что было изначально нужно пользователям. И получалось так не по вине какого-то конкретного человека, а просто потому, что в цепочке было много звеньев, и часть информации на каждом таком звене терялась.

Сейчас, когда мы получили четкий список того, что надо сделать, мы должны понять, как это сделать максимально полезно. И для этого разработчики Macroscop общаются с пользователями – они звонят или приходят к ним на объекты и разбираются, а как те хотят, чтобы это выглядело. И, надо отметить, в ходе таких валидаций наших гипотез мы обнаруживаем множество вещей, о которых и не подозревали.

Все эти новшества мы разработали и ввели 2,5 месяца назад. Для того, чтобы понять, насколько точно мы сфокусировались и верно ли построили процесс разработки, должно пройти гораздо больше времени. Однако, согласно плана в конце сентября мы выпустили 1 новую внутреннюю версию, в которой реализовали 7 запланированных улучшений.
ссылка на оригинал статьи https://habrahabr.ru/post/314040/

Когда-то сетевая операционная система Novell NetWare была лидером мирового рынка. Когда-то в ее основу были заложены самые прогрессивные идеи. Однако в ИТ-индустрии все быстро устаревает, а конкуренты никогда не дремлют.

Microsoft Windows NT – более молодая ОС по сравнению с NetWare. Корпорация Билла Гейтса не могла упустить рынок сетевых операционных систем. Включившись в борьбу позже, но со свойственным ей размахом, Microsoft начала быстро осваивать рынок и смогла избежать некоторых ошибок первопроходцев.

Novell NetWare

Работа над будущей NetWare OS началась еще в SuperSet Software – консалтинговой группе, основанной друзьями Дрю Мэйджером, Дэйлом Найбауэром, Кайлом Пауэллом и Марком Хёрстом. Они использовали свои наработки, сделанные еще в университете Бригама Янга в городе Прово (штат Юта), в октябре 1981 года.

SuperSet Software была основана в 1979 году и занималась производством систем, работающих под управлением ОС CP/M. Группа должна была создать систему совместного использования дисков для сетей на основе CP/M.

CP/M (Control Program/Monitor либо Control Programs for Microcomputers) — операционная система, первоначально предназначенная для 8-разрядных микрокомпьютеров. Написана в 1973 году программистом Гэри Килдаллом на языке программирования PL/M (Programming Language for Microcomputers).

В ходе работы группа пришла к выводу, что дальнейшие перспективы CP/M равны нулю. Команда решила разработать свою операционную систему для IBM-совместимых ПК, которые тогда только появились и были «на гребне волны». В результате возникла сетевая операционная система, которая позже была названа Novell NetWare.

В 1983 году к работе группы SuperSet присоединился Рэймонд Ноорда, ставший во главе молодой фирмы Novell Inc.

В том же году компания выпустила первый коммерческий продукт – ОС NetWare 68 (или Novell S-Net). Она работала на базе процессора Motorola 68000. В 1985 году вышла NetWare 86, которая поддерживала процессоры Intel 8086.

В 1986 году, после выпуска процессора Intel 80286, компания Novell выпустила NetWare 286. А в 1989 году, появились Intel 80386 и NetWare 386. В дальнейшем Novell решила дать своим системам более простые номера версий: так, NetWare 286 стала называться NetWare 2.x, а NetWare 386 — NetWare 3.x.

Причины успеха NetWare

Для передачи пакетов в NetWare использовался протокол NCP (NetWare Core Protocol — протокол ядра). Он был разработан на базе популярных ранее протоколах IPX/SPX (Internetwork Packet eXchange/Sequenced Packet eXchange), разработанных всё той же Novell.

NCP использовался для организации обмена между рабочей станцией и файловым сервером. Протокол IPX обеспечивал сетевой уровень (доставку пакетов, аналог IP), SPX — транспортный и сеансовый уровень (аналог TCP). Правда, в пятой версии NetWare компания-производитель всё же сделала основной для протокола NCP поддержку TCP/IP, а не IPX/SPX.

Пик популярности NetWare пришелся на 80-90-е годы. Это была удобная по тем временам система, и весьма стабильная: серверы под управлением NetWare могли работать годами без вмешательства администратора.

Также немалую роль сыграл тот факт, что большинство сравнительных тестов в то время указывали на преимущество в производительности в соотношении от 5:1 до 10:1, по сравнению с продуктами Microsoft и других компаний. Такой эффект достигался благодаря использованию службы файлов вместо дисковых служб, эффективности протокола NCP и отсутствие вытесняющей многозадачности.

В 1993 году, рассчитывая на быстрый успех, фирма Novell выпустила NetWare 4.0 и NDS (названную тогда службой каталогов NetWare), но они не были встречены с распростертыми объятиями. Новые продукты воплощали реализацию нового подхода к организации сетевых вычислений на предприятии и сильно отличались от всего, к чему привыкли пользователи NetWare 3.x. Поэтому самой популярной версией долгое время оставалась именно 3.х.

Однако в дальнейшем служба каталогов (NDS), входящая в состав NetWare 4.x, стала индустриальным стандартом в корпоративной среде.

Windows NT

Сильнейшим конкурентом Novell NetWare стала сетевая операционная система Microsoft Windows NT.

Началось все в 1975 году. Именно тогда, когда корпорация Digital Equipment начала разработку своей 32-битной платформы VAX, которая впоследствии была подхвачена компанией Microsoft.

В 1977 году были анонсированы машина VAX-11/780 и операционная система для нее — VMS 1.0. Разработкой системы руководил Дэвид Катлер. Спустя четыре года он решил покинуть Digital: не устраивали темпы развития проекта.

Тогда руководство компании организовало автономное подразделение в Сиэтле, и Катлеру позволили набрать необходимое количество персонала (около 200 человек) непосредственно из сотрудников Digital. Новая структура занялась проектированием процессорной архитектуры и операционной системы под кодовым названием Prism.

Однако менеджеры не сумели довести начатое дело до логического завершения, и в 1988 году Катлер покинул компанию.

Именно тогда Билл Гейтс и пригласил его в Microsoft. К тому времени он как раз пришел к необходимости создания серверной ОС, конкурирующей с клонами Unix.

Гейтс настолько ценил Дэвида Катлера, что согласился нанять 20 бывших инженеров Digital вместе с ним. В ноябре 1988 года команда, включавшая пять выходцев из Digital и одного программиста Microsoft, начала работать над новой операционной системой. Конечно, она не была абсолютно новой, так как Катлер использовал свои наработки.

Необходимо было написать ОС для нового RISC-процессора Intel i860 под кодовым названием N-Ten. Отсюда, кстати, и возникла аббревиатура NT, позднее трактованная маркетологами Microsoft как New Technology. Уже в декабре 1988 года были готовы первые фрагменты системы. Однако проблема заключалась в том, что i860 пока существовал лишь на бумаге, поэтому код приходилось тестировать на программном эмуляторе. Разработка велась на «игрушечных», по нынешним меркам, машинах Intel 386 25 MHz с ОЗУ 13 MB и жесткими дисками 110 MB.

В 1989 году выяснилось, что «железный» i860 не способен достаточно эффективно исполнять написанный код. Пришлось переориентироваться на MIPS R3000, а затем и на стандартный процессор Intel 386, что было сделано командой, увеличившейся до 28 инженеров за несколько месяцев.

Диаграмма развития операционных систем семейства Windows NT

В 1990 году произошло ключевое событие в судьбе операционной системы NT — выход и головокружительный успех Windows 3.0. Фактически она стала первой многозадачной ОС Microsoft с приличным графическим интерфейсом, в которой можно было выполнять реальную работу. Именно заимствование данного интерфейса и API предопределили будущее NT.

Изначально серверная ОС должна была стать ремейком совместного с IBM проекта OS/2 и, соответственно, функционировать с существующими приложениями OS/2.

Однако после выхода третьей версии Windows компания Microsoft отказалась от сотрудничества с IBM и переориентировала команду разработчиков NT на проектирование Win32 API, сделанного по «образу и подобию» интерфейса Win16. Это обеспечивало необходимую преемственность, облегчившую портирование приложений из настольной на серверную платформу. Так группа разработки NT, превратившейся к тому моменту в Windows NT, выросла почти до 300 человек.

Отказ от сотрудничества с IBM привел к серьезным проблемам во взаимоотношениях между компаниями. Правда, официальных заявлений не поступало, но на одной из межкорпоративных презентаций сотрудники IBM с удивлением обнаружили, что созданная ОС не имеет никакого отношения к их OS/2.

Тем не менее, в Windows NT 3.1 (нумерация была «подогнана» к текущей версии 16-разрядной Windows, существовавшей на тот момент) была реализована поддержка DOS, Win16, POSIX и OS/2 API в том числе. В июле 1993 году новая серверная система от Microsoft вышла в свет и начала завоевывать рынок.

Интеграция

В сентябре 1994 года вышла Windows NT 3.5. В ней были решены некоторые проблемы эффективности и быстродействия, которые из-за спешки не удалось решить в предыдущей версии.

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

В Novell не могли принять решение об обеспечении клиентской поддержки Windows NT и тянули время. В итоге Microsoft остановилась перед выбором: ждать еще или писать свой клиент для NetWare.

Компания Гейтса выбрала второй вариант и не прогадала: их самописный NetWare-клиент оказался настолько хорош, что его продолжали использовать и после выхода оригинального программного обеспечения от Novell. Время было упущено. Более того, было упущено не только оно.

Пользователи, особенно поначалу, выказывали резкое недовольство позициями Novell и Microsoft. Борьба между сетевыми компаниями предоставляла свободу выбора, но не давала возможности использовать оба продукта в одной среде.

Догнать и перегнать

В мае 1995 года благодаря архитектуре, основанной на микроядре, появилась специальная «PowerPC-редакция» ОС — Windows NT 3.51.

PowerPC (или сокращённо PPC) — микропроцессорная RISC-архитектура, созданная в 1991 году альянсом компаний Apple, IBM и Motorola, известным как AIM.

По некоторым данным, ее выпуск был в свое время задержан вследствие неспособности IBM придерживаться плана по выводу этого процессора на рынок. Поэтому эволюция PowerPC-версии зашла несколько дальше, чем Windows NT 3.5, что позволило ей стать основой для следующей версии ОС.

В версии Windows NT 4.0 графическая подсистема была интегрирована в ядро.Такое решение было абсолютно логичным выводом из печального опыта попытки интеграции в NT популярной оконной среды Windows 95. Вероятно, идея повторения архитектурной модели X Window — Unix — возникла именно из-за первоначальной «серверной ориентации» NT.

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

Графическая подсистема Windows несоизмеримо сложнее и, соответственно, требовательнее к ресурсам, чем X Window, «понимающая» исключительно растровые дисплеи. Так, в составе ядра Windows NT 4.0, выпущенной в июле 1996 года, появился еще один модуль. Ревизия получила название Shell Update Release (SUR).

Чтобы превратить Windows 95 и Windows NT в универсальные клиенты сети для любого сервера, корпорация Microsoft в прошлом году встроила стек протоколов TCP/IP в свои операционные системы.

Переход на TCP/IP, оказал значительное давление на традиционных поставщиков сетевых ОС, использующих свои собственные протоколы. Он не прошел незамеченным и для Novell. Компания выпустила новый продукт – NetWare/IP, загружаемый модуль, дающий возможность использовать IP в качестве сетевого протокола на сервере NetWare. Однако это не помогло удержать лидерство на рынке.

«NetWare/IP, поначалу вызывавший интерес, не оправдал надежд в полной мере, — делился своими впечатлениями Джон Миллер, специалист по планированию сети в Apollo Travel Division в United Airlines. — Он не справляется с ролью сетевого протокола для серверов».

По мнению Миллера, требования к заголовку IPX означали, что Novell в действительности не поддерживал IP или не предлагал каких-либо преимуществ при его использовании.

Реализация TCP/IP в Netware 5.x не спасла положение, так как вновь было потеряно драгоценное время.

Перевес по голосам

Крупным компаниям, которым Microsoft уделяла непосредственное внимание, не пошли на поводу у корпорации и предпочли NetWare. Тем не менее, проведенный Computer Intelligence и InfoCorp обзор свидетельствовал о том, что NT популярна в мелких центрах, где работают менее 1000 сотрудников.

Мелкие компании предпочитают Windows NT (количество компаний, использующих NT, %)

Однако NT проникла и на территорию NetWare. Все решили приложения. Выбор одной из этих систем в огромной степени зависел от того, какими приложениями пользовался клиент. Со временем приложения Microsoft оказались более чем на половине рассмотренных в обзоре станций NetWare.

Количество станций NetWare, на которых используется Windows NT, %

По мере увеличения мощности процессоров значение эффективности становилось всё меньше и меньше, а с появлением процессора Pentium сложность управления и разработки приложений для NetWare стали перевешивать ее преимущества. Но эти факты упорно игнорировались маркетинговым отделом Novell, равно как и руководством компании.

Так Novell NetWare потеряла позиции лидера, уступив их Windows NT.
ссылка на оригинал статьи https://habrahabr.ru/post/314078/

Всем привет!

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

Это будет первая статья цикла “Популяризация ASO”. В этом цикле я опишу все этапы оптимизации приложения, какими сервисами пользуюсь и на что нужно обращать внимание при проведении оптимизации.

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

Понятие семантического ядра

App Store Optimization — это оптимизация метаданных для улучшения метрик приложения и улучшения поисковой видимости в выдаче магазинов приложений.

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

В первую очередь хотелось бы обратить ваше внимание на то, что сбор семантического ядра (далее – “СЯ”) – это одна из самых важных и трудозатратных задач в оптимизации приложения. Но именно на его основе мы и выбираем, какие ключевые слова (далее – “КЧ”) мы будем использовать.
Ключевые слова могут иметь:

• высокую частотность (ВЧ);
• среднюю частотность (СЧ);
• низкую частотность (НЧ).

В мобайле мы не можем узнать какую частотность имеет тот или иной запрос, и ни один сервис не дает нам таких данных, в том числе и Apple SearchAds (абсолютных значений они, к сожалению, не дают), поэтому частотность запросов мы можем только предполагать.

Для наглядности, рассмотрим этапы составления СЯ на примере приложения моего хорошего знакомого, который любезно согласился предоставлять и разглашать все данные по приложению – “Quest Travel” (на момент публикации статьи, приложение еще не вышло в App Store).
Перед составлением СЯ очень важно ответить для себя на несколько вопросов.

Подготовительная работа

Кто ваша целевая аудитория?

Здесь нужно понимать, на кого рассчитано ваше приложение. Приведу пример: у вас есть игра, но она подходит для игры только маленьким девочкам (например, в ней нужно одевать кукол, мальчики и девочки постарше вряд ли захотят в такое играть, ведь так?). Поэтому нужно четко сегментировать аудиторию при составлении СЯ.

Какое ценностное предложение несет приложение?

О чем, вообще, ваше приложение? Какую задачу оно позволит решить пользователю, если он установит ваше приложение? Ответы на эти вопросы будут вашими первыми релевантными запросами.

Каковы основные отличия от конкурентов?

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

Кто ваши конкуренты?

Тут не надо ограничиваться только тем, что первое приходит в голову, а внимательно изучить поле, в котором вам предстоит работать. Посмотреть, какие КЧ используют они, возможно, это натолкнет вас на новые идеи.

Какой основной рынок вашего приложения?

Например, ключевые слова, используемые на странице британского и австралийского App Store работают и для поиска на российском рынке. Поэтому если основная аудитория вашего приложения в России, то разумно добавить в эти две локали те КЧ, по которым вы хотите продвигаться в России, но которые не влезли по символам на страницу в российском App Store. Подробнее про дополнительные локали и индексацию в Google Play я расскажу в одной из следующих статей.

Вы, наверное, уже отвечали на эти вопросы перед началом проектирования приложения. Если нет, то самое время это сделать. Ответы на них пригодятся вам при составлении СЯ и дальнейшем выборе ключевых слов.

Как подобрать ключи?

Для составления СЯ нам необходимо подобрать ключевые слова, из которых мы потом будем выбирать наиболее подходящие для продвижения. Тут вернемся к нашему приложению Quest Travel. Собственно, из названия можно понять, что это сервис этот связан с квестами и путешествиями. Поэтому ориентироваться будем на людей, которые хотят отправиться в поездку и ищут различные варианты для проведения активного и полезного отдыха.

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

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

• спросить у текущих или потенциальных потребителей вашего продукта, как бы они искали приложение (в данном случае, для путешествий), опрос друзей и знакомых тут тоже может дать много полезной информации;
• посмотреть на названия и описания приложений конкурентов, это очень важный пункт, внимательно изучите названия конкурентов;
• использовать сервисы статистики и мобильной аналитики: App Annie, Mobile Action, Sensor Tower и т.д., там можно взять на вооружение некоторые КЧ, по которым ваши конкуренты есть в выдаче;
• изучить комментарии ваших пользователей, если приложение уже есть в сторе;
• использовать инструменты подбора КЧ для веба: Google Keyword Planner, Google Trends, Яндекс.Wordstat. Последний вам очень поможет, если основной рынок для вас российский, однако на частотность тут лучше не обращать особого внимания, по опыту могу сказать, что в мобайле и вебе она может очень сильно отличаться.
• использовать словарь синонимов и языковые словари, например, Multitran, если подбираете слова для зарубежного рынка.

Оцениваем частотность

Как я уже говорил выше, получить статистику по частотности запросов в App Store и Google Play нельзя, но это не значит, что ее никак нельзя оценить.

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

Для App Store есть еще один инструмент, который Apple недавно представила разработчикам — SearchAds. По нему можно приблизительно оценить количество трафика по тому или иному запросу. Но сейчас это работает только для рынка США. Если ваше приложение нацелено как раз на американский рынок, то пользоваться SearchAds обязательно!

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

Suggest & Search

Итак, регистрируемся в AppFollow, в верхнем баре выбираем «ASO Tools», затем «Suggest & Search». Увидим такое окно:

Выбираем интересующий нас девайс: iPhone/iPad или Android. В следующем поле мы вбиваем слова, саджесты которых хотим увидеть. Последним пунктом в выпадающем списке, выбираем нужную нам локаль.

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

Замечу, что если вы проверяете саджесты для Android, то Google Play их выдает с учетом вашего IP-адреса. Т.е. если вы находитесь в России, а вам нужно посмотреть саджесты для США, обязательно поменяйте свой IP на американский (бесплатные VPN в помощь), иначе выдачу вам дадут по стране, где вы находитесь. Если же вы собираете СЯ из России для российского Google Play, то все ОК.

Именно по саджестам правильнее всего собирать семантическое ядро, т.к. далеко не все запросы, которые предлагает Keyword Planner или Яндекс.Wordstatпользуются популярностью в мобильном поиске.

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

Google Sheets

Существует и более быстрый способ выгрузки саджестов — через Google Sheets.
Для этого создаем новый документ в Google Docs и устанавливаем дополнение AppFollow ASO. Дальше будет много картинок и немного кода, поэтому для удобства чтения я спрятал это все под спойлер.

Нажимаем сюда и экономим свое время в дальнейшем..

Далее, в любой ячейке прописываем формулу: =getSuggestRU(«запрос»). Вместо «запрос» пишите слово или словосочетание, по которому хотите получить список саджестов. Не забудьте поставить его в кавычки.

Если вам нужно собрать запросы для другой локали (US\UK\ES\DE и т.д) или стора (Android), то заходим в «Инструменты – Редактор Скриптов».

Вам откроется новая вкладка с возможностью правки кода:

Чтобы поменять локаль, достаточно написать вместо ‘country’: ‘RU’, — ‘country’: локаль, которая вам нужна (допустим ‘US’). Для смены стора можно заменить ‘device’: ‘iphone’ на ‘device’: ‘Android’.

Если меняете локаль (например, на US), то лучше поменять и название функции c function getSuggestRU(term) на function getSuggestUS(term).

Далее сохраняем изменения и возвращаемся к нашей формуле в Google Sheets: =getSuggestRU(«запрос»). Если вы не меняли функцию, то трогать ничего больше не надо, если же поменяли название функции, то и в ячейке Google Sheets меняем =getSuggestRU(«запрос») на =getSuggestUS(«запрос»).

Если у вас по какой-либо причине не устанавливается дополнение AppFollow ASO, то вот ссылка на GitHub, где выложен код нужного нам скрипта. Копируем этот код и вставляем его в редакторе скриптов Google Sheets, затем сохраняем. Теперь можно пользоваться этой фичей.

Выбираем важное

Итак, с помощью ручного ввода, AppFollow или Google Sheets мы собрали список саджестов. В итоге, у нас получилась таблица, где мы указываем наши запросы, а ниже список саджестов для того или иного маркета в той или иной локали. Получилось что-то вроде этого:

Собрав выдачу по всем возможным саджестам, отмечаем цветами релевантные и околорелевантные запросы. В этой таблице релевантные запросы выделены синей заливкой, а околорелевантные — желтой.

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

На этом можно считать семантическое ядро собранным, дальше мы будем работать с нашим списком релевантных и околорелевантных запросов при подборе названия приложения и выбора КЧ для страницы в App Store и Google Play. Но это уже совсем другая история, подробнее об этом процессе я расскажу в следующих статьях.

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

Задавайте вопросы, пишите с чем не согласны, спрашивайте если что-то не совсем понятно. Пишите в комментах, или на facebook, буду рад ответить на все вопросы!

P.S.

Полезные ссылки на статьи по ASO:
vc.ru/p/aso-secrets
vc.ru/p/aso-3
www.slideshare.net/PCampRussia/aso-app-store-google-play-app-follow
www.mobilegrowthstack.com/acquisition/app-store-optimization/increasing-number-keywords-app-store-optimization-localization

Google Sheets:

docs.google.com/spreadsheets/d/1qWyoj7bN8jRiTW2H2lux3KhYdpg4ZxOQCAiK9eOQhy8/edit#gid=0
ссылка на оригинал статьи https://habrahabr.ru/post/314068/

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

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

Базовый чеклист

1. Проверить отзывы о контрагенте в Интернете (Яндекс.маркет, группы недовольных в социальных сетях). Желательно проверять не только по бренду, но и по названию фирмы (которое указано в договоре и на счетах), и по ФИО директора / учредителя (фирм может быть несколько).

Случай из практики: офис-менеджер заказала кофе-машину для нашей фирмы, кликнув по самому дешевому предложению в Яндекс.маркете. Машину привезли на следующий день. После того, как ее распаковали и заправили, оказалось, что в машине сломана Самая Главная Часть. Выяснилось, что машину мы купили у компании «Лабион», известной своей недобросовестностью: она продавала (и до сих пор продает) заведомо сломанные и неликвидные товары юридическим лицам. Закон «О защите прав потребителей» не распространяется на отношения между предпринимателями, а в суд никто не хочет идти. В итоге кофемашину отбили, но осадочек, конечно, остался.

Низкий рейтинг и проплаченные отзывы — плохой знак

2. Проверить компанию по ЕГРЮЛ — реестру юридических лиц. Основные вопросы:

• Давно ли она зарегистрирована?
• Как часто менялся директор?
• В каком регионе (несовпадение регионов повлияет на стоимость суда)?
• Где находится офис (в бизнес-центре, квартире, на «массовом адресе»)?
• Совпадает ли адрес с адресами других фирм (адрес забивается в поисковик)?

Напрямую о случаях смены директора в ЕГРЮЛ не пишут, но форма 14001 — это с вероятностью в 95% либо смена директора, либо смена адреса. Смену адреса можно косвенно проверить по ИНН и хронологии изменений в выписке.

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

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

Дополнительный чеклист

Помимо базовых проверок, если есть время — можно прогнать и по дополнительному перечню:
4. Реестр недобросовестных поставщиков ФАС, в который попадают «закупочные тролли» и поставщики, не исполнившие условий государственного контракта: rnp.fas.gov.ru
5. Реестр сведений о банкротстве. Контрагент вряд ли там будет (если только он проходит внешнее управление), но другие компании того же владельца можно найти. По сравнению с «картотекой» тут больше документов — скажем, можно посмотреть, удовлетворены ли требования кредиторов и не привлекались ли руководители к ответственности. bankrot.fedresurs.ru
6. Банк данных исполнительных производств — здесь все неплательщики, которые уклоняются от исполнения судебных решений: fssprus.ru/iss/ip/
7. База неплательщиков налогов и «брошенных» компаний (пока работает в тестовом режиме и только для юридических лиц): service.nalog.ru/zd.do
8. Представителей контрагента можно также проверить в реестре дисквалифицированных — не запретил ли им суд руководить компаниями за административные или налоговые пригрешения: service.nalog.ru/disqualified.do

И, наконец, обязательно проверьте полномочия того, кто подписывает сделку от имени другой стороны. Помните: договор становится действительным на основании подписи, а не печати, поэтому само по себе наличие печати у представителя не гарантирует совершения сделки. Когда речь идет о накладной или счете, это не так важно; но если вы подписываете крупный договор, важно проверить, что другая сторона имеет право подписывать все бумаги.

Если знаете другие сервисы проверки контрагента — давайте вместе дополнять чеклист 🙂
ссылка на оригинал статьи https://habrahabr.ru/post/314076/