Бізнес Майстерня

Main Text

Бізнес Майстерня
Цифрові рішення для Вашого бізнесу.

Slogan Section

Затишний телеграм канал "Бізнес Майстерні"

Digital

Канали

Менеджмент

Поради

Тренди

воронка

За якими показниками стежити і як витрачати на це мінімум часу.

Отже, у вас є сайт і інтернет-маркетолог (або ціле маркетингове агентство на підряді).

В ідеалі має бути так: ви нескінченно задоволені тим, скільки продажів генерує ваш маркетолог і скільки це коштує; з кожним звітним періодом окупність вкладень зростає; вам достатньо побіжного погляду на звіт, щоб побачити динаміку.

У ваших стосунках все не так райдужно? Пропонуємо спосіб це виправити.

Відразу обмовимося: мова піде не про e-commerce (це особливий світ зі своїми законами), а про ті сфери, де через сайт можна тільки замовити товар або послугу - саме вони зазвичай страждають від недостатньої аналітики.

Вимірювати і управляти

Ще в минулому столітті засновник американської школи менеджменту Пітер Друкер сказав: «Управляти можна тільки тим, що можна виміряти». Сподіваємося, сьогодні вам уже не потрібно нагадувати, що оцінювати маркетинг необхідно за цифрами, а не за суб'єктивним відчуттям «працює/не працює».

Другий важливий момент: якість управління безпосередньо залежить від того, в чому саме ми вимірюємо ефективність - в трафіку, об'ємі продажів або якихось інших цифрах. Правильно обрані показники дозволять точно оцінювати і планомірно підвищувати окупність вкладень. Простіше кажучи, ваші гроші будуть приносити максимум можливого прибутку.

Як це зазвичай влаштовано в середньому бізнесі:

  • Маркетинг не рахується взагалі. Просто є сайт, який приносить «мало» або «дуже мало» клієнтів. Часто саме з такими вихідними даними вперше звертаються до агентства.
  • Щось обліковується час від часу, десь в екселі. За цим звичайно треба радикальний крок - зміна маркетолога або вкладання грошей в новий рекламний канал. А потім все триває, як і раніше.
  • Звіт робиться регулярно, але містить якісь загальні цифри, які створюють видимість активності. Як з цим працювати - незрозуміло, тому раз по раз цифри майже не змінюються, якщо не змінюється рекламний бюджет.

Як це повинно бути влаштовано:

  • Цифри повинні бути доступні в режимі онлайн. По-перше, автоматизована система знижує тимчасові витрати і ймовірність помилки. По-друге, так в один і той же час директор, маркетолог і інші фахівці зможуть оперувати одними і тими ж цифрами.
  • Цифри повинні бути інформативні: скільки вклали, скільки отримали, як і динаміка в порівнянні з минулим місяцем. Плюс можливість легко заглибитися в деталі при необхідності.
  • Цифри повинні бути простими і наочними. Тобто щоб ви відкрили звіт на зустрічі, і ваш співрозмовник менше ніж за хвилину побачив головне.

Ви зможете оцінювати роботу маркетологів і приймати правильні рішення, якщо ваш звіт дає швидку відповідь на важливі питання:

питання

Що рахуємо

Звичайно, нам в першу чергу важливо, скільки грошей ми вклали в маркетинг і скільки клієнтів отримали. Але цього мало.

Невеликий лікнеп з інших важливих показників в порядку зростання значущості для бізнесу:

  • CPC (cost per click) - ціна за клік. Корисна тільки фахівцю, який веде рекламу.
  • CPL (cost per lead) - ціна за лід, тобто звернення потенційного клієнта (дзвінок і зворотний дзвінок, заявка через форму або пошту, звернення в чат).
  • CPS (cost per sale) - ціна продажу.

По-хорошому, знати потрібно всі ці показники. Але на якому сфокусуватися, щоб тримати руку на пульсі маркетингової активності? Очевидно, це не ціна за клік.

Це може бути ціна продажу, але тут є кілька нюансів:

  • Для аналізу продажів потрібна CRM система, а її інтеграція - це окремий непростий процес.
  • Якщо товар дорогий, з довгим циклом продажу, то даних для аналізу буде занадто мало.
  • Сам факт продажу сильно залежить від менеджера, який спілкується з потенційним клієнтом, тому оцінювати таким чином саме маркетинг буде некоректно.

Ми рекомендуємо дивитися на вартість звернення (ліда) - зрозумілий, інформативний і керований показник. По суті, це розумний компроміс між тим, що насправді потрібно керівнику (продажі), і тим, що підвладне маркетологу (кліки та конверсія).

Як це організувати технічно

  1. Підключаємо коллтрекінг - сервіс відстеження дзвінків з сайту. Коштує він не так дорого, але якщо ви даєте рекламу або просуваєте сайт в пошуку, без нього не обійтися.
  2. Налаштовуємо цілі в Google Analytics - відстежуємо всі види цільових дій, що здійснюються нашими потенційними клієнтами.
  3. Далі це все в кращому випадку збирається в Ексель, але для управління такий варіант не годиться. Потрібна професійна система аналітики - зрозуміла, автоматизована і, на жаль, зазвичай платна.
таблиця

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

Навіщо? Будь-яка проблема повинна бути очевидна і відразу кидатися в очі. У 1986 році космічний корабель «Челленджер» розвалився в повітрі. Інженери НАСА попереджали керівництво про проблему і пропонували перенести старт. Але керівники не надали проблемі великого значення через складно оформлений звіт.

звіт
Це хороший звіт - в ньому проблема відразу очевидна

Дізнайтеся, яка рекламна кампанія витрачає ваші гроші даремно. Не дайте своєму Челленджеру вибухнути!

Навчилися рахувати - що далі

Якщо раніше ви регулярно не рахували скільки коштує ваш лід - він точно може коштувати менше. Тому після налаштування аналітики ми переходимо до оптимізації витрат: допрацьовуємо кампанії, відключаємо неефективні, перерозподіляємо бюджет.

Для поетапної оптимізації допоможе проста воронка:

Кому продаємо

Аналізуємо вартість ліда в кожному з рекламних каналів, підбираємо аудиторії, працюємо з настройками показів

Як продаємо

Працюємо з пошуковими запитами і оголошеннями

Що продаємо

Підвищуємо конверсію сайту - його інформативність і зручність

Гарна аналітика дозволить швидко зрозуміти, на якому саме етапі ви втрачаєте гроші, сформулювати завдання і відстежити ефект від змін.

ефект

Після вказівки цін на сайті (послуги преміум-сегмента) ціна ліда різко зросла. Ціни вирішили прибрати.

Після періоду «просто поліпшення» і спостереження за показниками можна переходити до постановки довгострокових цілей (на 3-6-12 місяців).

Як ми це робимо:

  • Звіт показує нам, де ми зараз - кількість і вартість лідів по рекламних каналах, конверсія, кількість продажів.
  • Формулюємо бажаний обсяг продажів і «розкладаємо» по каналах потрібну кількість лідів.
  • Дивимося, за рахунок яких етапів воронки можна досягти зростання.
  • Пов'язуємо це з реальністю: наприклад, підняти конверсію вище 5% або розраховувати отримати з SEO більше трафіку і лідів, ніж основні конкуренти старші за нас - дещо самовпевнено.

Для зручного розрахунку ми зробили спеціальний калькулятор: з його допомогою отримуємо «оцифровані» цілі, зрозумілі і маркетологам, і керівнику.

розрахунки

Короткий підсумок

  1. Якщо ви вкладаєте в рекламу або просування сайту без якісної аналітики - ви втрачаєте гроші.
  2. Вартість ліда (звернення) - це той показник, на який варто дивитися в першу чергу для оцінки маркетингової активності.
  3. Щоб керувати своїми вкладеннями і говорити з маркетологами на одній мові, вам потрібен простий і інформативний звіт, який завжди під рукою.
  4. Якщо ваш маркетолог або підрядник не може надати такий звіт - знайдіть іншого. Ваше завдання - приймати рішення, а не намагатися розібратися в звітах.
  5. На першому етапі впровадження системи контролю потребуватиме додаткових витрат, але дуже швидко окупиться і почне приносити прибуток. Ви зможете керуватися чіткими критеріями ефективності маркетингу, і вам більше не доведеться розбиратися в нюансах з кожним новим підрядником. Краще витратити цей час на інші важливі цілі - пошук шляхів зростання і розвитку вашого бізнесу.
Фото: flickr.com
Обробка: Vinci
Читати далі
код

Напевно, у кожного програміста виникала ситуація, коли абсолютно не знайомі з IT люди просили його пояснити, в чому ж полягає суть його професії. Так уже склалося, що у більшості людей поняття «програміст» асоціюється або з замкнутим гіком в окулярах і светрі, або з якимось геніальним червонооким підлітком-хакером - але при цьому ніхто не знає, чим саме він займається.

Як розповісти їм про це, не лякаючи страшними термінами і фрагментами коду?

Для цього ми відтворимо таку розповідь, а також розвінчаємо кілька міфів про програмування.

- Чим займаються програмісти? Це не так-то просто розповісти... Скажіть мені для початку: як в двох словах можна описати, наприклад, суть професії хірурга?
- Хірург проводить операції.
- Так, відмінний опис! Ну а, скажімо, футболіста?
- Грає у футбол!
- Угу, а хірург «займається хірургією». А якщо без однокореневих слів?
- Штовхає м'яч?
- Ось це точно. А що ж робить програміст, крім як «розробляє програми»?
- ...
- Програміст пише код. Вихідний код своєї програми, складений на якійсь спеціальній мові програмування. Точніше кажучи, спочатку він продумує структури своїх даних, потім складає алгоритми для роботи з цими структурами - ну а потім вже представляє це в вигляді коду.
- Що ще за «структури даних»? Хіба він не керує комп'ютером, не натискаючи кнопки?
- Ех...

Міф №1: Програміст працює з комп'ютерами

Спробуйте донести до людей, що програмісту для написання коду, взагалі-то, зовсім не потрібен комп'ютер. Він потрібен лише для перевірки коректності коду, для його тестування - але писати сам код і складати схеми алгоритмів цілком можна і на папері (хоча на екрані монітора, звичайно, це робити зручніше). Розробник же просто записує на цьому папері набір якихось інструкцій, команд або конкретних даних (числа, текст). А хто цей набір виконує - комп'ютер, телефон або особливо розумний робот, не так вже й важливо. Програміст працює з даними, а не з машинами.

- Ну як, зрозуміло?
- Тобто, програміст просто повідомляє машині, що б він хотів зробити - а вона це виконує?
- Ну так, приблизно.
- Так само, як начальник віддає розпорядження підлеглим?
- Схоже на те.
- А якщо машина захоче виконати це якось по-іншому?
- Тобто?
- Ну, щось їй не сподобається. Або просто виконувати не захоче.
- Так, давайте з'ясуємо раз і назавжди, що...

цифри

Міф №2: Машина вміє думати

Чомусь чимале число людей реально вважає, ніби комп'ютер володіє якимось інтелектом. Насправді - це просто набір залізяк, які думати не вміють. Вони вміють лише зберігати числові дані. Розмагнічено якусь ділянку такої залізяки - значить, це нуль. Намагнічений - одиниця. Плюс, ще вони можуть додавати і віднімати ці одиниці, утворюючи більш складні числа (про двійкову систему числення краще не варто згадувати). Більше комп'ютер сам нічого робити не вміє, тільки зберігати числа і оперувати ними. Це бездумний дурень, який лише виконує команди програміста.

- Загалом, код будь-якої програми представляє собою набір команд, а комп'ютер їх тупо виконує.
- Тобто, він не розуміє суті самих команд? Але як він сприймає текст, який я ввожу на екрані?
- Коли ти крутиш педалі на велосипеді - чи розуміє він, що йому зараз потрібно поїхати вперед?
- Ні, але ж їде. Оскільки його ланцюг перетворює обертання педалей в обертання колеса.
- Саме так! Так само і комп'ютер перетворює введений тобою текст в набір чисел.
- Яким чином?
- У кожного символу тексту є свій числовий код, який знає комп'ютер. Це називається кодуванням. Наприклад, англійська «a» кодується числом 97, а знак рівності - числом 61.
- Тому машина і може розуміти текст, який ми їй повідомляємо?
- Ні, вона «розуміє» не сенс. А лише те, яким чином цей текст зберігати, і як до нього звертатися.
- Виходить, спочатку ми вводимо текст, потім комп'ютер розбиває його на символи, а кожен символ вже представляє у вигляді числа?
- Вірно. Складні структури представляються у вигляді більш простих, які і «розуміє» машина.

Скажіть мені, з чого складається житловий будинок?
- Ну... З поверхів.
- А з чого складаються поверхи? І так далі.
- Поверхи - зі стін. А стіни - з цегли. А цеглу...
- Ось числа для комп'ютера - це те ж, що і цегла для будинку. Символи - це стіни. Окремі пропозиції - поверхи. А книги - цілі будинки! Але у програмістів є перевага перед будівельниками.
- Яке?
- Будівельник не може будувати цілими поверхами, він змушений завжди класти цеглу. Навіть якщо якийсь надпотужний підйомний кран дозволить йому будувати готові поверхи, він не зможе будувати їм цілі будинки або житлові квартали. А програміст зможе! Раз він вже «навчив» машину розуміти кінцевий текст - то, по суті, він «навчив» підйомний кран будувати готовий будинок за одну дію.
- Тобто, програміст може використовувати все більш і більш складні структури даних?
- Так. Тому перша зі складових його роботи - представити зрозумілі людині дані (текст, зображення, звук) у вигляді об'єднання простіших даних, вже зрозумілих комп'ютеру. Розробник практично «з нуля» становить структуру, яка повинна повністю описувати зрозумілу людині річ - причому таким чином, щоб ця структура була легко розширюваною і змінною (адже в програму часто доводиться вносити якісь нові можливості).
- Хех! Виходить, що він будує гумові будинку зі знімних панелей!
- Приблизно так. Однак, ще йому доведеться не лише описати, що ж йому потрібно побудувати - але і як все це побудувати. Тобто, придумати алгоритм. Це друга зі складових його роботи.
- Програміст придумує алгоритм на кожну дію?
- Саме так. Тому алгоритмів виходить дуже багато. Але його роботу полегшує те, що одні дії можуть містити в собі інші, вже описані ним раніше.
- І тут йому на допомогу приходить мова програмування?
- Не зовсім...

Міф №3: Мова програмування потрібна для складання алгоритмів

Ні, мова - це всього лише інструмент. Як гітара для музиканта. Саме по собі вміння грати на гітарі зовсім не гарантує слави - бо люди, як правило, захоплюються самою музикою, а не вмінням швидко і чітко смикати струни. З іншого боку, навряд чи хто прийде подивитися на поганого гітариста, яку б чудову композицію він не виконував. Так само і з мовою програмування: знання її синтаксису і пов'язаних з ним нюансів дуже важливе, так само як і вміння писати красивий і ясний код. Однак, якщо людина не вміє складати алгоритми і структури даних - то вона не може називатися хорошим програмістом.

клавіатура

Комп'ютер не розуміє мову програмування безпосередньо. Як і раніше, він представляє кожну команду мови у вигляді набору «найпростіших» команд (зберегти число, обнулити число, додати до нього одиницю), які він здатний виконати. «Розуміє» мову програміст, а машина її лише виконує. По суті, будь-яка мова програмування - це набір команд, що служать для спілкування з нею.

- Правда, багато нинішніх мов програмування вже містять «в собі» набір заздалегідь складених алгоритмів, які розробник може використовувати в якості готових. Тому мова все ж трохи полегшує процес складання алгоритмів.
- Тобто, якщо один програміст склав якийсь алгоритм, то його тут же можуть використовувати інші?
- Так, і це відбувається постійно. Це одна з причин, чому галузь IT так швидко розвивається. Однак нові алгоритми доводиться складати самому.
- А склади який-небудь прямо зараз!
- Легко. Класичний приклад: у вас є книга, в ній 1000 сторінок. Вам потрібно відкрити в ній, наприклад, 875-ю сторінку. Як би ви стали це робити?
- Ну, просто пробіг від першої до 875-ї, тільки і всього.
- Угу, і доведеться тобі дивитися на номер кожної сторінки. А уяви, якщо всі їхні куточки злиплися - скільки часу тоді пройде? А ось мені достатньо перебрати лише 3 сторінки!
- Як?
- Спочатку я виберу сторінку, яка знаходиться посередині книги, тобто 500-ю. Потім подивлюся: в яку з утворених половин повинна потрапити шукана сторінка?
- У другу. А далі що?
- Теж саме. Інтервал з 500-ї по 1000-ю я знову поділю надвоє, відкривши центральну сторінку. Вийде інтервал від 750-ї сторінки до 1000-й, в ньому я знову виберу центральну. Якою буде номер?
- 750 плюс 125... Так це ж і є 875!
- От бачиш. Всього 3 дії! Навіть якщо я буду не зовсім точний при виборі центральної сторінки, я все одно знайду потрібну набагато швидше тебе. Цей алгоритм носить назву «дихотомія». Хоча в реальності програмісти використовують куди більш складні алгоритми.
- І ти можеш записати його на папері?
- Звісно. Де там моя ручка?

Псевдокод
повторюємо цикл:
	
        шукаємо(в книзі, центральну_сторінку);
	
        якщо (центральная_сторінка = шуканій_сторінці)
                виходимо з циклу;
	
        інакше
                якщо (центральна_сторінка < шуканій_сторінці)
                        видаляемо(в книзі, всі сторінки від першої до центральної);
                інакше
                        видаляемо(в книзі, всі сторінки від центральної до останньої);

- Ну як, алгоритм зрозумілий?
- Хм... Так, і справді зрозумілий.
- Зараз він записаний у вигляді, вже злегка схожому на реальний програмний код.
- А в чому відмінності?
- У реальному коді всі слова будуть написані англійською, а також буде заздалегідь описана структура «книга». Плюс, для дій «шукаємо» і «видаляємо» теж будуть складені свої алгоритми. Але в цілому - все те ж саме.
- І ти займаєшся цим із дня в день?
- Переважно.
- І тобі не нудно?
- Анітрохи.

програміст

Міф №4: Програмування - це нудно

Звичайно, розробка цілком може набриднути, якщо займатися тільки рутинними й одноманітними справами. Наприклад, складанням дуже простих алгоритмів, але у великій кількості. Або монотонним пошуком помилок в чужому коді. Але це ж стосується і будь-якої іншої роботи - рутина всюди вбиває творчий процес. А творчості в програмуванні чимало, написання коду схоже на написання художньої книги. Тільки, на відміну від більшості письменників, програміст спочатку сам створює свій власний світ (структури даних) - а вже потім наповнює його сюжетом (алгоритмами).

Часом це справді чиста творчість, де розробник сам встановлює власні правила. Незважаючи на те, що в світі даних і алгоритмів все строго і логічно, в ньому присутня своя краса. Будь-який програміст може привести десятки прикладів дуже красивого коду, і ще більше прикладів потворного. Програмісти, як і всі люди, теж помиляються: якщо десь в вихідному коді допущена помилка, то задумані алгоритми можуть працювати неправильно. Тому код часто перетворюється на такий собі детектив - в якому йде пошук чергового підступного бага, що заважає виконанню алгоритму, або порушує структуру даних...

- Жартома можна сказати, що в підсумку виходить якийсь детектив в вигаданому світі, виражений за допомогою мови програмування.
- А вбивця в цьому детективі - дворецький?
- Ага, нульовий покажчик. Буває так, що весь відділ день-другий ловить особливо настирливий баг, і кожен програміст з відділу бере на себе якусь ділянку коду. Виходить ціле розслідування, з покаранням винних і нагородженням причетних...
- Хм, а це і справді цікаво звучить!
- От бачиш.
- А, скажімо, я можу хоч трохи навчитися програмуванню?
- Так звісно! Я знаю один сайт спеціально для цього...

Фото: flickr.com
Обробка: Vinci
Читати далі
обличчя

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

Додати 3-5-секундний трейлер

Коротке прев'ю на початку відео - досить поширений підхід на YouTube, а тепер і в Facebook. Достатньо ключовий фрагмент з відео додати в початок, щоб зацікавити і захопити користувача.

Щоб побачити, в який момент перегляду ви втрачаєте глядачів, використовуйте аналітику Creator Studio.

«Відкрийте відомості про відео, натиснувши на свій ролик в бібліотеці контенту Creator Studio. Подивіться на криву утримання аудиторії і зніміть прапорець "only include views over 15 seconds", щоб зрозуміти, в якому місці люди залишають ваше відео в перші секунди перегляду. Ми рекомендуємо часто перевіряти криві утримання і прагнути покращувати час перегляду - це допоможе розширити охоплення на Facebook».

Відкадрувати відео зі співвідношенням сторін 4: 5

А краще відразу знімати вертикальні відео.

«Ми живемо в світі, де більшість людей дивляться відео на мобільному телефоні в декількох дюймах від імені і часто в вертикальної орієнтації, не повертаючи телефон в горизонтальне положення. Спробуйте створювати свої відео в вертикальному форматі. Або переведіть їх в формат 4: 5».

Внутрішнє дослідження Facebook показало, що продуктивність деяких відеороликів значно покращилася просто за рахунок перемикання з формату 16:9 на 4:5.

Facebook

Залучати свою спільноту, відповідаючи на коментарі під своїми відео-повідомленнями

«Участь в обговоренні в розділі коментарів під вашими власними постами може порадувати вашу аудиторію і максимізувати охоплення. Об'ємні коментарі, детально роз'яснюють вашу точку зору або відповідають на питання, ще сильніше активізують взаємодію з вашим контентом».

Facebook також зазначає, що набагато простіше відповідати на коментарі до відео в Facebook і Instagram через вкладку «Вхідні» в Creator Studio:

Creator Studio

Але головне - пам'ятайте: єдина чарівна формула успішного контенту на Facebook - це ви.

Фото: flickr.com
Обробка: Vinci
Читати далі
проект

Ми вирішили підготувати для Вас, друзі, невеликий екскурс в типовий IT проект. Ми часто спостерігаємо круглі очі наших майбутніх колег, коли говоримо, що в IT галузі є місце не тільки програмістам, так й і що програмістів, насправді, кілька типів. Отже, давайте розбиратися, хто ж такі "конси", аналітики, "РП", розробники, тестери.

Отже, почнемо з того, що ролі в команді можуть суттєво відрізнятися в залежності від типу проекту. Створюючи софт з нуля, Вам потрібна одна команда, впроваджуючи ERP систему - інша, ставлячи додаток BI для топ-менеджменту замовника - третя і так далі. Але тут ми вирішили розповісти Вам найбільш поширені і загальноприйняті професії і ролі, які затребувані в тій чи іншій мірі практично на будь-якому проекті.

Розробникч ДЕВ

Без розробників/програмістів/девелоперів, зрозуміло, нікуди. Це ключові люди в будь-який ІТ команді, саме вони займаються безпосереднім створенням програмного продукту або складним конфігуруванням базового коробкового рішення. Ціни немає тем розробникам, які розуміють (або хоча б хочуть розуміти, будемо чесними) бізнес-сторону питання. Адже за будь-яким програмним продуктом стоїть якась бізнес потреба і хоча б приблизне її розуміння командою розробки є суттєвою перевагою і спрощує всім життя. У командах цінують розробників, а таких особливо, а також з них виростають одні з найуспішніших керівників проектів.

Аналітики

Розглянувши роль Розробник, найлогічніше перейти до його/її самому вірного колеги і соратнику на будь-якому проекті - аналітику або бізнес-аналітику. Ці хлопці беруть на себе дуже істотну частину роботи, перебуваючи на стику бізнесу і технологій. Звичайно, як ми вже обговорили вище, ідеальною людиною був би той, хто вислухав потреби бізнесу, 100% зрозумів їх з першого разу, придумав відповідне рішення, написав по ньому документацію, розробив, протестував, навчив і порадів. Такі люди дійсно є, але набагато ефективніше в даному випадку працює зв'язка аналітик + програміст.

До типових завдань бізнес-аналітика входить:

  1. Робота з представниками бізнесу та глибоке розуміння їх процесів;
  2. Самостійна ідентифікація і аналіз проблем/вузьких місць в робочих процесах;
  3. Спіставлення знайдених проблем з потребами бізнесу, які вони самі виявили;
  4. Проектування рішення, яке задовольнить усі потреби і вирішить проблеми (найчастіше, крім проектування IT рішення, потрібно також і пропозиція з реструктуризації діяльності);
  5. Після того, як рішення спроектовано (побудовані моделі даних, описані use-case, написані специфікації на розробку), документація переходить до розробника, а аналітик продовжує постійну комунікацію з розробником для більш ефективної роботи.
гроші

Консультант Конс

У багатьох компаніях роль консультанта повністю збігається з роллю аналітика на проекті і ніякої різниці між ними немає. Однак у великих IT компаніях, ці ролі трохи розрізняються. Якщо аналітик більшою мірою фокусується на участь у проектах (і при цьому володіє більш технічними навичками, знає мови програмування на рівні читання коду для коректного написання специфікацій на розробку, розуміє в архітектурі front-end і back-end, здатний вибудувати структуру бази даних майбутнього додатка на основі вимог і потреб бізнесу, здатний розуміти, чи можна додати якусь функціональність в код і не зламати всі попередні доробки), то консультант або бізнес-консультант в більшій мірі фокусується на IT-консалтингу, тобто на тих роботах, які передують IT проекту. Консультанти проводять глибокий аналіз бізнес-процесів компанії, аналізують проблеми і пропонують варіанти проведення реінжинірингу процесів (перебудови діяльності) для більш успішного функціонування компанії, підбирають існуючі IT-рішення, які можуть допомогти бізнесу функціонувати, або проектують на верхньому рівні і пропонують замовнику розробку з нуля.

Менеджер проекту РП

Про цю професію/роль/покликання можна розповідати нескінченно. Якщо коротко, то менеджер проекту - це той, хто бере проект, кладе на свої плечі і тягне в пургу, шторм, метеоритний дощ і ядерну війну, але не має право відпустити (має звичайно, але у нього прав на це менше, ніж у інших учасників команди). Менеджер проекту виконує величезну кількість робіт, починаючи від розробки плану проекту, оцінки ризиків, контролю функціональних і вартісних рамок і закінчуючи щоденною роботою з командою на проекті.

Тестувальники тестери

Що таке тестування і хто такі тестувальники? У двох словах - це біль. Ім'я у цій ролі цілком говорить, і ці хлопці займаються тестуванням програмних продуктів. І особливість їх професії в тому, що якщо аналітика (не найбільш досвідченого) ще можна переконати, що "це не баг, а фіча", то ось цих хлопців точно ні. Фраза "на моїй машині працює" теж не врятує нікого від цих хлопців. Вони - інженери по QA (Quality Assurance) і тестують не просто зовнішню частину програми, але і коректність звернення до бек-енду, швидкодію і відмовостійкість системи, застосовуючи найрізноманітніші методики тестування.

Фото: flickr.com
Обробка: Vinci
Читати далі

Автор матеріалу - Олексій Ткачук, творець найбільшого блогу в рунеті про Instagram Dnative.ru

Блог Dnative в соціальних мережах:

FB VK Youtube Telegram

Посилання на оригінал: Накрутить подписчиков в Instagram? #ля, зачем!?

Як же ви дратуєте, найрозумніші і хитрозроблені, які впевнені в тому, що накрутивши підписників в Instagram ти відразу ж станеш відомим, багатим, клієнти підуть і продажі злетять до небес. #якбинетак

накрутка

Як виглядає типовий скрипт просування чергового магазину китайського барахла або ж нової перукарні?

  1. Створити обліковий запис з назвою типу @nizki_cini_u_nas21
  2. Заповнити профіль
  3. Купити три тисячі, а ще краще п'ять тисяч підписників.
  4. Запостити перше фото з підписом «Друзі, ми починаємо».
  5. Постити фотки з корпоративів раз на тиждень.
  6. Лайкати всіх підряд.

Само собою, я трохи утрирую і перебільшую, адже хто буде публікувати фото з корпоративів раз на тиждень? Треба мінімум 5 фотографій столів з офісу і тортика Тітки Зіни з Дня Народження.

В принципі на кожному з етапів подібного просування відбуваються грубі помилки, але зупинимося на накрутках.

лебідь

Чому накручені підписники в Instagram здатні вбити ваш аккаунт?

По-перше, вас можуть просто забанити. Якщо на молодий аккаунт одномоментно підписуються тисячі підписників, алгоритми Instagram починають вас підозрювати і профіль блокується. Зазвичай - безповоротно.

І правильно роблять, ці самі «пильнуючі» алгоритми Instagram. Без вас світ стане тільки чистішим і кращим. А тепер уявіть, що ви не тільки купили ботів, але вже похвалилися керівництву про свої перші успіхи, скромно промовчавши про те, що підписники були куплені на першому-ліпшому сайті. А премію то вже пропили, та й шукати нову роботу зовсім не хочеться. Тому не треба накручувати підписників на новий акаунт! Це вбереже ваші нерви, кар'єру і премію.

По-друге. Користувачі теж не ідіоти, ну в переважній більшості, тому дуже дивно виглядають акаунти з кількома фотографіями і тисячами підписників. Чи станете ви підписуватися на щось подібне? І не просто підписуватися, а довіряти подібному бізнесу і робити у них замовлення? Та й удар по репутації це може завдати не слабкий, якщо не сьогодні, то завтра точно відгукнеться.

Для довідки, на скріншоті ще один підтип акаунтів-одноденок. Це вони дратують користувачів мережі своїми сотнями лайків, підписок, безглуздими коментарями в ваших стрічках. Акаунти-вітрини, які горять дуже швидко і за цей час прагнуть зробити якомога більший радіус дії, щоб хоч одна людина що-небудь та й прикупила. #ненавидітицепогано.

фоловери

Так ось, припустимо, що ви все ж накрутили собі кілька тисяч підписників. В середньому залученість в середньостатистичному акаунті буде на рівні 1-3%. Тобто при наявності 3.000 підписників, фотографія повинна отримувати від 30 до 100 лайків. «Пффф, та це ж копійки», справедливо можете помітити ви. Адже на своїх особистих облікових записах ви збираєте набагато більше.

Тільки мова йде про комерційний акаунт. А у брендових сторінок закони життя зовсім інші, і чим більше підписників у вас буде, тим менший відсоток залучення ER ви зможете підтримувати. То ж, накрутивши тисячі підписників, лайків від цього більше не стане. І у вас залишиться тільки два виходи:

  1. Блокувати накручені акаунти вручну, але це не дуже приємне задоволення.
  2. Змиритися з низькою відносною залученістю і плакати під столом, міцно стискаючи коліна.

А другий варіант, в свою чергу, веде до ще більшої проблеми. На початку літа 2016 року, адміністрація Instagram почала масово вводити алгоритмічну стрічку новин на всі профілі користувачів. Гортали стрічку в Facebook? Ага, значить розумієте, про що йдеться.

Чим вище рівень залученості ваших підписників в той контент, який ви публікуєте, тим більшій кількості підписників він буде показуватися. А частина з них взагалі його не побачить ні за яких обставин. І тут накручені підписники зіграють фатальне значення, адже вони тягнуть вас на дно, як бетонні черевики.

шльопки

Міфи накруток. Чому люди накручують підписників

Міф 1. Велика кількість підписників залучає нових користувачів.

Багато хто чомусь вважає, що раз у вас 10.000 підписників і ви лайкаєте користувачів, то вони обов'язково побіжать на вас підписуватися, адже у вас ОГОГОСКІЛЬКИ фоловерів. Це не зовсім так, точніше зовсім не так. Принцип соціального доказу має місце бути, але в першу чергу аналізується контент, активність і відповідність акаунту цільовим інтересам користувача. А ось невідповідність кількості лайків і коментарів сумі ваших підписників цілком може зіграти фатальну роль і відлякати потенційного клієнта.

Міф 2. Багато підписників = багато клієнтів.

Щоб в це вірити, треба бути закінченим ідіотом. Однак, він має коріння ще й в низькосортної та непрофесійної роботи підрядників і агентств, які, зазвичай, прагнуть приховати косяки своєї роботи за видимими показниками. Накручуючи підписників ви просто збільшуєте цифри. Якщо так хочеться подивитися на великі цифри, поумножайте на калькуляторі, чого вже там.

Міф 3. Всі накручують і мені треба.

Існує поширена думка, що будь-яке просування починається з початкової накрутки. Адже хто підпишеться на ваш акаунт, коли в ньому стоїть горда цифра 3 підписника (це ви, ваш начальник і найближчий до вас колега).

Підпишуться і так. Інші комерційні акаунти, і це не жарт. Днями я зробив нову сторінку, яку ніяк не просував. За перші кілька днів на мене підписалося майже 80 акаунтів, серед яких були як живі люди, так і неживі бізнес-сторінки. І лайків на кожну фотографію прилітає не менш 20-30 за раз. Прям таки свято ботоводства у плоті.

Точно не накручувати?

Прям точно. Нехай помруть від голоду всі ці сервіси по накруткам. Через них страждають чесні і красиві профілі, втрачаючи варіантів просування і піддаються загальним санкціям від адміністрації сервісу. Нехай Instagram буде красивим і затишним, як раніше.

А всі поради і статті, які стверджують вам зворотне - повинні палати на яскравому багатті, священним полум'ям якого буде очищений інтернет-маркетинг від ботовід та іншого мотлоху.

Фото: flickr.com
Обробка: Vinci
Читати далі
крестики

У світі миттєвого спілкування чат стає найкращим каналом зв'язку з клієнтами, але 45% компаній не просять користувачів навіть залишити відгук після завершення спілкування.

В наші дні найбільша проблема омніканального обслуговування клієнтів - це час відгуку. Клієнти очікують негайної реакції. Superoffice провела дослідження підтримки чатів на 1000 веб-сайтах з США і Європи. Чати оцінювалися тільки в години підтримки веб-сайту, причому питання задавалися по суті. Після завершення кожного чату оцінювалася якість за часом відповіді, часом очікування і загальним досвідом спілкування.

А що в результаті?

  • На 21% запитів в чаті підтримки не відповіли.
  • Середній час очікування реакції служби підтримки в чаті складає 2 хвилини 40 секунд.
  • 55% компаній не пропонують відправити копію чату після завершення спілкування.
  • 23% компаній не запитують контактну інформацію до початку чату.
  • Середній час обробки запиту в чаті становить 6 хвилин 50 секунд.
  • 45% компаній не просять користувачів залишати відгуки після завершення чату.

Як перетворити чат в зручний і ефективний канал зв'язку з клієнтами

1. Якщо онлайн-чат є частиною вашої стратегії спілкування з клієнтами, важливо швидко реагувати на запити клієнтів. Якщо при використанні електронної пошти клієнти очікують відповіді протягом 6 годин, то в чаті - негайно. Найбільше розчарування клієнтів викликає звернення до компанії кілька разів з одного й того ж питання. На жаль, 1 з 5 чатів або 21% під час дослідження так і залишився без відповіді.

дослідження

Пропонуйте чат як варіант спілкування, тільки якщо у вас є для цього ресурси. Хоча б просто вимикайте його, якщо немає кому відповісти. Чим більше запитів в чат ви ігноруєте, тим більше клієнтів ви втрачаєте.

2. Скоротіть час відповіді за допомогою заздалегідь написаних шаблонів. Люди терпіти не можуть чекати. Середній час очікування відповіді оператора після запуску чату становить 2 хвилини 40 секунд. Всього лише кілька операторів відповіли протягом 30 секунд (що забезпечило позитивний досвід клієнтів). Максимальний час очікування склав 9 хвилин.

стовпчики

Попередньо написаний шаблон скорочує час очікування відповіді, також можна, наприклад, створювати шаблони для найбільш поширених питань. І по можливості включіть посилання на більш детальну інформацію на своєму веб-сайті, наприклад відповіді на актуальні питання та бази знань, замість того, щоб вводити відповідь вручну. А найоптимальніший варіант це чатботи. Вони дійсно здатні змінити життя як бізнесу, так і клієнтів.

3. Персоналізуйте спілкування зі своїми клієнтами. Дивно, але до цього часу 23% компаній не запитують контактну інформацію до початку чату. Відсутність контактної інформації означає, що оператор чату не знає, з ким він спілкується. Попередній запит імені або адреси електронної пошти дозволить йому вибрати цінну інформацію з вашої CRM-системи заздалегідь для більш особистого обслуговування.

обслуговування

Згідно з дослідженням Economist Intelligence Unit, це призводить до скорочення часу обробки запиту і більш швидкому відгуку, що вважається найбільш важливим елементом для створення ідеального клієнтського досвіду.

4. Створюйте довгострокові позитивні враження. Після закінчення чату, замість того, щоб просто поставити галочку «виконано», відправте копію чату клієнту по електронній пошті. Наявність балки чату дозволяє клієнту продовжити спілкування в будь-який час. На жаль, більше половини (55%) чатів не пропонували таку можливість. А оператор легко може зробити копію розмови і відправити її клієнтові на email, але з 1000 компаній тільки одна виступила з такою ініціативою.

статистика

Пост-чат - також відмінний час, щоб запитати думку клієнтів про обслуговування. 45% компаній не запитували відгуки клієнтів після завершення чату. Чи був чат корисний? Чи були клієнти задоволені своїм досвідом? Якщо ви не запитаєте їх, ви ніколи не дізнаєтеся. Клієнти цінують, що їх просять дати зворотний зв'язок, але доступ до таких даних також допомагає виявляти проблемні місця, усувати і покращувати їх.

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

Фото: flickr.com
Обробка: Vinci
Читати далі
механізм

Текст про стереотипи і помилки, які побутують в ІТ. Про те, що розробник - це фахівець, який пише код, а тім лід - це не просто керівник групи.

Групи ролей

Ролі в ІТ можна розділити за кількома зрізами:

  • за активністю;
  • за відповідальністю;
  • за завантаженістю.

Поділ за активністю:

  • виробники;
  • управлінці;
  • перевіряючі.

Поділ за відповідальністю:

  • без відповідальності
  • з відповідальністю за якість
  • з фінансовою відповідальністю

Поділ за призначенням:

  • наймані на позицію;
  • виховувані в колективі.

Опис ролей

Назви ролей будуть використовуватись американські, звідки, по-суті, вони родом. Велика частина назв запозичена з англомовної спільноти.

Developer.

Характеристики:

  • займається виробництвом програмних алгоритмів;
  • не несе відповідальності за застосування результату і по фінансових ризиках;
  • наймається на позицію.

Ця роль класичного виконавця: керівник ставить задачу на автоматизацію того чи іншого процесу, розробник це виконує.

сходи

У сучасному світі, розробник об'єднується ще з кількома ролями, які будуть описані нижче.

Дана роль часто сегментується з розділенням відповідальності:

  • Back-end developer - розробник програмно-апаратної частини комплексного ПЗ;
  • Front-end developer - розробник клієнтської сторони призначеного для користувача інтерфейсу до програмно-апаратної частини.

Так само, роль сегментується по платформах, під які ведеться розробка, наприклад:

  • Web;
  • Mobile;
  • Server-Side;

і так далі. А для більш зручної роботи рекомендуємо користуватись ось цими розширеннями для VS-code:

User Experience Designer (UX)

Характеристики:

  • займається виробництвом карт користувацького досвіду;
  • несе відповідальності за застосування результату, але не несе відповідальність за фінансовими ризиками;
  • наймається на позицію.

Ця роль вивчає і оцінює, як користувачі відносяться до розроблюваного програмного забезпечення. Вони виявляють простоту використання ПЗ, сприйняття цінності ПЗ, корисність ПЗ, ефективність ПЗ. Продумують і оцінюють процеси і сценарії використання ПЗ.

Помилково цю роль плутають, а часом і поєднують з роллю UI Designer (див. нижче). UX vs UI Designer відрізняються не тільки предметною областю, а й специфікою мислення. UX Designer більше про аналітику і систематизацію, ніж про ергономіку і естетику.

User Interface Designer (UI)

Характеристики:

  • займається виробництвом графічної складової інтерфейсів;
  • не несе відповідальності за застосування результату і по фінансових ризиках;
  • наймається на позицію.

Ця роль розробляє візуальну частину призначеного для користувача інтерфейсу. Основними цілями роботи UI дизайнера є: интуїтивність сприйняття, простота, юзабільність і естетика інтерфейсу ПЗ.

Quality Assurance (QA)

Характеристики:

  • займається перевіркою результату;
  • не несе відповідальності за застосування результату і по фінансових ризиках;
  • наймається на позицію.

QA займається тестуванням всього, як би дивно це не звучало.

Системний підхід фахівця QA дозволяє тестувати як програмний код, так і продуманість карт користувацького досвіду.

команда

Також дуже важливий аспект роботи фахівця QA - планування, тобто вміння складати тест план, слідувати йому, готувати звіти згідно з підготовленим планом. Фахівців QA на ринку праці багато, а ось людей з системним підходом, необхідним багажем знань і умінь - одиниці.

Human Resource (HR)

Характеристики:

  • займається первинним підбором кандидатів згідно вимог
  • несе часткову відповідальність за результат, але не несе відповідальність за фінансовими ризиками;
  • наймається на позицію.

HR займається первинним підбором кандидатів згідно вимог, забезпечує прозоре проходження всіх етапів співбесід при працевлаштуванні.

Обов'язки HR часто замішані з наступною роллю, яка на більшості ринків праці трактується так, як хочеться керівництву компанії.

Team Leader

Характеристики:

  • відповідає за роботу групи фахівців;
  • несе відповідальності за командну роботу, не несе фінансових ризиків;
  • вирощується в колективі.

Team Leader забезпечує комфортні умови роботи колективу і підтримує високий рівень її ефективності. Дана роль не зобов'язана знати специфіку роботи команди досконально. Для прикладу, якщо мова про Team Leader в групі розробників, то він не зобов'язаний бути програмістом, йому достатньо мати знання про організацію праці, процеси, що протікають під час виробництва. Але на практиці так історично склалося, що найбільш досвідчених програмістів ставлять на цю позицію, що є класичною помилкою управління.

Це важливо розуміти:

  1. Team Leader завжди вирощується в середовищі, це єдиний спосіб заробити авторитет в групі людей; немає авторитету, ніхто не буде слухати Team Leader, процеси йтимуть своїм шляхом;
  2. Можна процес вирощування прискорити, найнявши одного з досвідчених Team Leader, але в колектив він повинен потрапити спершу як рядовий фахівець, заробити авторитет, тільки потім перейти на цільову позицію;
  3. Роль більше не про управління командою, не про виробництво, а про рішення проблем в роботі команди, налагодження комунікації всередині команди, вибудовування комфортних умов виробництва;
  4. Team Leader зобов'язаний володіти аналітичними навичками та системним поглядом; просто робити, щоб всім було "добре" мало, основне завдання - постійне вимірювання внутрішніх метрик команди, як соціальних, так і виробничих, зміна процесів для підвищення результативності.

Чому досвідчений розробник флегматик або меланхолік не підходить на цю роль, думаю, тепер стало очевидним.

Tech Leader

  • відповідає за грамотний аргументований вибір технічних рішень;
  • несе часткову відповідальність за результат, але не несе відповідальність за фінансовими ризиками;
  • вирощується в колективі.

Особливостей всіх ролей, в назві яких є слово Leader, є те, що всі вони вирощуються в колективі (див. вище).

Але дану роль ми вирішили виділити, так як, на практиці, її найчастіше плутають з роллю Team Leader.

Tech Leader так само вирощується в колективі, команді потрібен авторитет, щоб впевнено доносити свої думки і рішення з технічних питань.

Tech Leader торкається таких аспектів роботи команди:

  1. Відповідальний вибір стороннього ПЗ для проекту;
  2. Рекомендація по вибору конкретного алгоритму або архітектурного рішення при виробництві ПЗ;
  3. Визначення технічних особливостей в процесах виробництва.

Головною особливістю цієї ролі полягає те, що на її позицію найчастіше потрапляють саме флегматики або меланхоліки. Так складається, що досвідчені програмісти мають саме цей тип темпераменту.

код

Scrum Master

З появою термінів Scrum, Agile, KanBan, гнучкі методології, і інші теоретичні знання, які вкрай не приносять користі без практики/досвіду, до команд розробки стали прикріплювати роль Scram Master.

Характеристики:

  • відповідає за грамотнє застосування тієї чи іншої гнучкої методології (буває, що навіть тієї, яка не стосується Scrum взагалі);
  • несе часткову відповідальність за результат, але не несе відповідальність за фінансовими ризиками;
  • наймається на позицію.

Чому ми вирішили описати дану роль? Так склалося, що цю роль часто плутають з Project Manager.

Давайте з'ясуємо ситуацію. Scrum Master - це фахівець, який допомагає команді застосовувати методологію Scrum правильно, пояснює правила методології, контролює їх виконання.

Важливим моментом тут є те, що фахівець не контролює виконання проекту, він контролює саме виконання правильної роботи з методологією, роблячи команду "гнучкою".

Project Manager (PjM)

Характеристики:

  • відповідає за старт, ведення і здачу проектних робіт;
  • несе повну відповідальність за результат, несе часткову відповідальність за фінансовими ризиками;
  • наймається на позицію.

Ця роль класичного управлінця процесами. Робота над проектом починається з Project Manager`а, ведеться (ставляться завдання), контролюється (контроль якості та ефективності), і здається теж ним. У більшості компаній Project Manager управляє проектним фондом. Про грамотний розрахунок по digital-проекту читайте в цій статті. Коли швидкість реалізації швидше планованих термінів проекту, проектний фонд утилізується не повністю, залишається частина грошей, які за результатом успішної здачі проекту розподіляється на премії учасників. Розподілом також займається Project Manager.

Фото: flickr.com
Обробка: Vinci
Читати далі