Блог Илхома Назарова

об управлении IT-проектами, интернет-маркетинге и общении с клиентами

Системы контроля версий: Git, SVN, Mercurial для менеджеров

Задача проектного менеджера и коммерческой разработки как таковой — ставить конкретные цели и отслеживать этапы выполнения работ.

Для этого в производственный процесс принято внедрять дейли митинги, таск трекеры и системы контроля версий (СКВ или VCS — Version Control System), которые мы рассматриваем как инструменты для управления проектами.

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

Популярные решения

По опыту 9 из 10 команд разработки используют Git, хотя рейтинг Tagline говорит о меньшей его популярности.

Рейтинг систем контроля версий Git, SVN, Mercurial

После Git с большим отрывом идет SVN (Subversion) и Mercurial.

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

Долю на рынке, сопоставимую с массой электрона, занимают осталные системы : CVS (Concurrent Versions System), Team Foundation Server, Bazaar, Darcs итд.

Все системы контроля версий по сути решают 4 задачи

Доступ к коду

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

Логирование изменений в коде

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

Ветвление разработки

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

Поддержка версионности продуктов

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

Организация девелопмент процесса

Вам, как менеджеру проекта, стоит обратить внимание:

  1. Принят ли у разработчиков единый шаблон оформления комментариев к коммитам (commit message), из которых понятно, что делает коммит и зачем.
  1. Настроена ли привязка коммитов к конкретным задачам из таск трекера (traceability) для трассировки бизнес требований.
    В Mercurial это работает из коробки, а вот, например, в Git это обычно решают с помощью хука, который не дает ничего закоммитить без метки таска, а-ля “PROJECT-JIRA_ISSUE_NUMBER”
  1. Делают ли разработчики ежедневный пуш (выгрузку коммитов) в центральный репозиторий или работают локально не отдавая написанный за день код вовне.

Последний вопрос не актуален, если разработчики используют на проекте SVN, так как это централизованная СКВ и весь код хранится на сервере.

Распределенные и централизованные подходы к хранению кода

Git и Mercurial — распределенные системы, SVN — централизованная.

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

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

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

C этой точки зрения, SVN лучше вписывается в модель коммерческой разработки, где мы ежедневно контролируем объем и качество выполненной работы.

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

Как менеджеру освоить базовые функции Git

Вероятность столкнуться с использованием гита на проекте 90%, поэтому небольшая рекомендация для тех, кто собрался его изучить.

Матчасть:

Короткий видеокурс Geekbrains для старта за 2 часа.
Официальная документация для дотошных.

Программное окружение:

На Mac Git по умолчанию вшит в штатную консоль. На Windows первым делом скачайте и установите сам Git.

С гитом работают через консоль или графический интерфейс (GUI).

Графический интерфейс SourceTree для работы менеджера с Git

Для задач IT-менеджера рациональнее использовать графический клиент. Лично я использую SourceTree, хотя не всем нравится продукция Atlassian.

Выберите клиент по вкусу вот тут.

Вперед к первому $ git clone!

2018  

Lean Canvas для тех, кто запускает новые продукты

Lean Canvas — схема, которая отображает модель бизнеса или стартапа на 1 листе бумаги.

Эш Маурья (Ash Maurya) описал эту схему в книге «Running Lean».

Lean Canvas незаменим, когда есть идея продукта, но нет понимания его модели и плана выхода на рынок.

Однако, это не просто способ структурировать идеи и концепции для себя или презентации другим (коллегам, инвесторам, подрядчикам итд).

Цель Lean Canvas — определить гипотезы и требования для разработки и запуска MVP (minimum viable product).

Как заполнить Lean Canvas

Скачайте шаблон для печати на leanstack.com, хотя таблицу Lean Canvas можно также заполнять в простом Google Sheets.

Бланк Lean Canvas и инструкция по заполнению

1. Проблема (и существующие альтернативы решения)

Описываем 1-3 главные проблемы, которые мы решаем с помощью продукта. Расставляем их в порядке важности.

Именно с проблемы и начинается продукт.

Конкуренты и альтернативы:

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

Если альтернативных решений нет, вероятно, мы преувеличили проблемы, либо их вовсе нет, иначе бы их уже решали.

2. Сегменты потребителей (и ранние клиенты)

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

Выбираем 1 сегмент потребителей, который станет «ранними клиентами». Это люди, которые по нашим расчетам будут релевантны для продукта, дадут обратную связь и принесут первые деньги. Для них и будем разрабатывать MVP.

Если стараться выпустить продукт «нужный для всех», вероятно, получится сделать продукт не нужный никому.

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

Обратите внимание, что потребители (customers), которые платят за продукт, могут не совпадать с пользователями (users), которые им пользуются. Например, для Яндекс или Google: потребитель — рекламодатель, пользователь — тот, кто ищет. В этом случае и проблемы и сегменты разделяем на 2 категории: customers и users. 

3. Уникальное торговое предложение (UVP)

Опишите в одном предложении ключевое отличие вашего продукта:

  1. Что такое ваш продукт?
  2. Кто ваши клиенты?
  3. Зачем им нужен ваш продукт? (Почему клиент захочет инвестировать свои деньги или время в вас?)

Разумеется, UVP (Unique Value Proposition) отвечает на главную проблему клиента, которую мы поставили первой в блоке «Problem» нашего Lean Canvas.

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

Как сконцентрироваться на результате и ответить на вопрос «зачем клиенту ваш продукт?» — пример для сервиса по составлению резюме:

«Профессиональные дизайнерские шаблоны для резюме» — лишь фича продукта. «Привлекательное резюме, выделяющееся на фоне других» — лишь промежуточный результат. «Работа мечты» — это конечный результат, который включаем в UVP.»
Ash Maurya «Running Lean»

Вот еще одна формула UVP:

«Конечный результат + Время его получения + Контраргумент возражению. Пример: «Горячая свежая пицца у вас за 30 минут, не успеем — достанется вам бесплатно.»
Дэйн Максвелл (Dane Maxwell)

Высокоуровневый концепт:

Это необязательная, но полезная опция — продающий концентрированный смысл. Это то, что клиент о вас запомнит (Ritter Sport: Quadratisch. Praktisch. Gut.)

4. Решения

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

5. Каналы привлечения пользователей и продаж

Как целевой сегмент потребителей (ранние клиенты) узнают о продукте и откуда они к нам придут?

Перечисляем каналы привлечения:

  • Inbound — потребители находят нас сами: вебинары, SMM, SEО итд
  • Outbound — мы находим потребителей: контекстная реклама, обзвоны, рассылки итд 

Не стоит тратить ресурсы на исходящие каналы до тех пор, пока мы не протестировали гипотезы бизнес-модели. Об этом еще расскажу чуть позже.

6. Источник дохода

Выбираем модель монетизации: подписочная, рекламная, транзакционная, freemium, free trial итд. Разбираемся в том, из чего будет складываться цена продукта и прибыль.

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

Также изучаем ценовую политику и модели монетизации конкурентов — это источник для получения конкретных цифр.

7. Структура расходов

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

8. Ключевые метрики (KPI)

Метрики выбираются исходя из специфики бизнеса и модели монетизации.

Например, отслеживаются: Downloads (скачивания), Installs (установки), Visits (визиты), Registrations (регистрации пользователей), RR (retention rate — процент пользователей, которые повторно вернулись на сайт или запустили приложение в течение n-периода времени), CAC (customer acquisition cost — цена привлечения одного пользователя), LTV (life time value —  средний доход с одного платного пользователя за его жизненный цикл), Bookings (заказы), Revenue (прибыль) итд

Главная задача — включить в KPI такие метрики, которые помогут:

  1. найти точку окупаемости проекта;
  2. проследить как изменения, которые мы вносим в продукт, влияют на результат (например, вы внедрили рекомендательную систему, и у нас есть метрика, фиксирующая результат — увеличение среднего чека).

В KPI продукта, как правило, включают метрики для отслеживания конверсионной воронки, от привлечения пользователя до конверсии и прибыли. Для этого идеально подходит воронка «AARRR» Дэйва МакКлура (Dave McClure).

Конверсионная воронка «AARRR» Дэйва МакКлура (Dave McClure)

Изображение с сайта startitup.co.

Подробнее о метриках фреймворка «AARRR» я напишу отдельно.

Итак, на основе блоков Lean Canvas № 6,7 и 8 мы сопоставляем доходы и расходы и планируем нужные показатели KPI, например, сколько платных пользователей нужно при текущей цене продукта, чтобы считать проект прибыльным.

9. Нечестное преимущество (скрытое)

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

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

Lean Canvas и тестирование гипотез

Перед запуском стартапа или нового продукта компании, проведите customer development — тестирование идеи на потенциальных клиентах.

Главное, что мы подтвердим или опровергнем:

  1. у выбранного сегмента потребителей действительно есть проблема и наш продукт ее решает;
  2. наше решение — это продукт, за который клиент готов платить.

Основа тестирования — проведение интервью с возможными клиентами, ранними адоптерами. При этом не всегда требуется разрабатывать даже MVP продукта, чтобы исключить основные риски бизнес-модели.

Риски разделяются на 3 категории:

Потребительские риски (Customer risk)

Ошибка в определении сегментов потребителей и ранних клиентов. Либо ошибка при выборе каналов связи с потребителями.

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

Продуктовые риски (Product risk)

Правильный ли продукт мы делаем? Выбрали реальные проблемы и нашли крутые решения.

Наиболее высокая цена ошибки при создании бизнес-модели — в постановке проблем. Например, если мы преувеличили их важность для потребителя, то все остальные части Lean Canvas окажутся уже не важны.

Чтобы проверить продукт — потребуется разработать MVP версию и провести интервью.

Рыночные риски (Market risk)

Будет ли работать наш бизнес? Возможно на рынке нет места или не получится отбить клиентов у конкурентов или допущена ошибка при планировании доходов и расходов.

Чтобы проверить эту часть бизнес-модели, придется запустить MVP продукта в боевом режиме.

PS

Lean Canvas по сути — упрощенная версия Business Model Canvas (автор Александр Остервальдер (Alexander Osterwalder).

Модели достаточно похожи, но Business Model Canvas включает описание ключевых партнеров, каналов сбыта, используемых ресурсов — того, чего пока нет у стартапа или нового продукта.

Разница между ними в том, что Business Model Canvas описывает уже устоявшиеся бизнес-модели для их анализа и поиска точек роста, а Lean Canvas подходит для запуска новых продуктов и стартапов.

2018  

Разница в планировании проекта по Scrum и Waterfall

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

Хочу коротко остановиться на принципиальной разнице в этих подходах.

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

Waterfall (инкрементная модель) — MVP + итерации

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

Scrum — MVP + итерации

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

2018  

Классификация менеджеров в digital агентствах и веб студиях

Виды менеджеров в digital агентствах и веб студиях

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

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

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

Виды и роли менеджеров

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

Нью биз менеджер (new business managers) изучают потребности, проблемы или точки роста в бизнесе потенциального клиента, предлагают решение, заключают сделки и стартуют проекты.

Аккаунт менеджеры (account managers) — менеджеры по работе с клиентами. Поддерживают контакт и выстраивают доверительные отношения. Продают и допродают, согласуют договора, следят за счетами, но главное — следят за тем, чтобы клиент оставался счастлив. Аккаунт менеджеры подключаются к проекту на этапе продажи и контролируют, чтобы проект рос и развивался максимально долго, но самостоятельно проекты не ведут.

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

Продюсеры (digital producers) — у продюсеров полномочия шире, чем у проджектов. Они отвечают за экосистему проекта целиком: сами компонуют проектные команды (привлекают внешние ресурсы, когда это нужно) и управляют всеми направлениями работ по проекту (креатив, маркетинг и реклама, производство и т. д.). Другими словами, продюсер обеспечивает условия для производства и запуска проекта.

Как я уже говорил, конкретный менеджерский состав и разделение ролей зависят от конкретного агентства.

Например, у нас в H&H работают два вида менеджеров: аккаунт менеджеры, которые продают, и проджекты, которые ведут проекты.

А как же продакт менеджер?

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

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

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

Разделяй и властвуй

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

И к стати, почему это продакт менеджеров не бывает на стороне студий?

Предлагаю отдельно остановиться на этих ролях и зафиксировать различия.

Аккаунт vs проджект

Разница между аккаунт менеджером и проджект менеджером

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

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

Говоря метафорично, разница между ними в том, что проджект менеджер — зонтик проектной команды (маркетологов, дизайнеров, разработчиков, тестировщиков и т. д.). А аккаунт (как остроумно выразилась Лада Родзина) — зонтик зонтика! Он разрешает конфликтные ситуаций между тремя богатырями: клиентом, аккаунтом и менеджером проектов.

Проджект vs продакт

Разница между проджект менеджером и продакт менеджером

Почему продакт менеджеры бывают только на стороне продуктов (компаний или стартапов), а не в студии заказной разработки:

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

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

Надеюсь, теперь энтропии в мире менеджеров станет чуточку меньше.

2018  

Центрирующие парадигмы Александра Фридмана

В своем курсе «Управление мышлением подчиненных» Фридман приводит 7 простых правил, известных как «центрирующие парадигмы Фридмана». Если вы с ними не знакомы, вот конспект с небольшими комментариями:

  1. Проанализируй задание перед началом работы
    У исполнителя должны быть все ресурсы для выполнения задачи
  2. Задание должно быть выполнено на 100%
    100% и по качеству и по содержанию
  3. «Уперся — сообщи немедленно»
    О препятствиях к 100% выполнению задания немедленно сообщи руководителю и всем заинтересованным
  4. Приходи с решением проблемы
    Предложение по решению проблемы предпочтительнее информации об ее возникновении
  5. Факты и аргументация предпочтительнее мнения
    Всегда подкрепляем речь доводами
  6. Расширенное толкование задания не допускается
    Все что не разрешено — запрещено
  7. Несогласие с параметрами задания — не повод их игнорировать
    Не согласен — сообщи и аргументируй. Не приняли аргументы — делай, как сказали

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

А еще каждый знает, что ежедневная зарядка является залогом бодрости и крепкого здоровья. Однако знать о пользе зарядки и систематически ее выполнять — это, как говорят в Одессе, «две большие разницы».

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

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

Например:

Плакаты у нас в студии «Heads and Hands»

2017  

Вебмастера и вебмастеры

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

Грамотное написание вебмастера и вебмастеры, timeweb, таймвеб

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

Получаю неожиданный ответ:

Здравствуйте.
По правилам написания множественного числа существительного имени слово «вебмастеры» на нашей странице указано правильно.
gramma.ru/RUS/?id=4.15

Когда кто-то ошибается и учится на своих ошибках, в этом нет ничего страшного. Грустно, когда человек или компания упорствуют в своих заблуждениях.

2015   шедевр

Разработка мультиязычного сайта. Нюансы.

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

Определение стартовой языковой версии

В зависимости от задач сайта, нам предстоит определять язык (читая заголовки HTTP запроса, а именно Accept-Language) или язык + местоположение пользователя (Accept-Language + IP).

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

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

На деле пользоваться базами GeoIP важно для вывода рекламы, цен, товаров, услуг и другого зависящего от региональности контента, но не для выбора языка.

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

bodybuilding.com

Выбор языка на сайте вручную

Структура url

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

http: //www.apple.com/ru

С учётом того, что язык не равно страна:

http: //www.ibm.com/ru/ru/
http: //www.microsoft.com/en-us/

Однако если контент серьёзно различается для разных локализаций, имеет смысл вынести их на поддомены и продвигать как отдельные сайты:

https: //ru.wikipedia.org/

Выбор шрифта

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

Верстка страниц

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

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

Список языков на сайте

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

Выбор языка важно сделать интуитивно понятным.

Есть хорошие варианты:

artgorbunov.ru

Список языков при помощи сокращений

last.fm

Выбор языка на сайте одним списком

N.B.
Если языков не много, то не обязательно показывать в списке язык, на котором в данный момент отображается сайт:

gigi.lv (в данный момент открыта русская локализация)

Не отображаем много языков на сайте

Есть неплохие варианты:

ahrefs.com

Выпадающий список языков с пиктограммой

eukanuba.com (вспоминаем про «язык не равно страна»)

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

Есть отстойные варианты списков:

perco.com

Выбор языков при помощи флагов

eukanuba.ru

Выпадающий список языков

twitter.com

Некорректный выбор языков на сайте

Название языка в списке как бы говорит попавшему в чужую локализацию пользователю: «மொழி: தமிழ்», что в переводе означает «Язык: Томильский». Как выбрать язык, не понимая стартовой локализации, на которой ты оказался — остаётся тайной, окутанной невнимательностью и безразличием разработчиков.

— Та-ак. Значит, русский язык знаем. Зачем потребовалось скрывать?

— А мы и не скрываем. Очень трудно в язык проникать, когда сразу на двух
языках думаете.

— А этот пацак всё время говорит на языках, продолжения которых не знает.

Чё уставился, маймуна веришвило?



К/ф Кин-дза-дза!

2015   опыт

Skype энд Viber прононсейшен

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

Тюркская и некавказская кухня

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

Шашлык

Шашлык от татарского шишлык — шиш (вертел, копьё) + лык (мясо), то есть «мясо на вертеле». Наверняка подобным образом готовили ещё мамонтов, тем не менее современное блюдо в России называют на татарском (тюркском) языке.

Как переводится шашлык, история шашлыка

Чебурек

Чебурек от татарского чибәрәк — чи (сырой) + бәрәк [ берек ] (пирожок), то есть «сырой пирожок». Сырым его назвали из-за быстроты приготовления, кочевники жарили чибәрәк в походных условиях.

Как переводится чебурек, история чебуреков

Долма

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

Википедия подсказывает, что название пошло от тюркского глагола sarmak со значением «заворачивать», dolmak (тюрк. dolmak) со значением «заполнять».

Как переводится долма, история долмы

Беляш

С беляшом произошла самая возмутительная ошибка. Беляш на татарском и башкирском бәлеш — это просто пирог. Русские часто ошибочно называют пәрәмәч [ перемяч ] — жареный в масле пирожок с мясом — беляшом. Однако ещё большая ошибка — считать беляш кавказским блюдом.

Это перемяч

А вот это белеш

Сильный текст и словесный мусор

Вы не задумывались, почему владельцы сайтов размещают на своих проектах унылый, избитый текст, который никто не читает?

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

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

Такой текст или письмо никто и никогда не прочтёт — это просто спам. И дело не в штампованных словах, слова не так важны. Важны идеи. Сила текста в смысле и правде.

Пишите, если вам действительно есть что сказать.

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

Из неё я узнал про «Главред» — сервис, который помогает очистить текст от шлака. Теперь я регулярно им пользуюсь.

Понятный пример

Как выглядит попытка скрыть пустоту текста словесными ужимками, взял из статьи «Знакомство с информационным стилем»:

Наша компания является ведущим провайдером услуг по ИТ-интеграции в регионе. Мы работаем на рынке интеграционных и телекоммуникационных услуг с 2010 года. За долгие годы работы мы успешно выполнили проекты и завоевали безоговорочное доверие таких крупных клиентов как Сбербанк и завод «Северсталь»...

Вот что останется, если отфильтровать бессмысленные штампы и трусливую брехню:

Наша компания является ведущим провайдером услуг по ИТ-интеграции в регионе. Мы работаем на рынке интеграционных и телекоммуникационных услуг с 2010 года. За долгие годы работы мы успешно выполнили проекты и завоевали безоговорочное доверие таких крупных клиентов как Сбербанк и завод «Северсталь»...

Ещё примеры информационного стиля

Было Стало
Производим работы
по проектированию
и инсталляции компьютерных
сетей.

Строим компьютерные сети.
Было Стало
Мы являемся одним
из национальных лидеров
в сфере защищенных видеосетей.

Мы построили первую в России
защищенную федеральную
видеосеть.
Было Стало
Создаем эксклюзивные проекты
«под ключ».
Проектируем сети, поставляем
и устанавливаем оборудование,
внедряем программы и обучаем
сотрудников.

P.S.
Живой пример редакторской магии.

Главред, редакторская магия
Ранее Ctrl + ↓