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

Полное описание с возможностью прокомментировать тут: https://goo.gl/pvMExv

Обсудить за глубинные интервью с бизнесом тут: http://t.me/ctorecordschat

Про локализацию сервисов под разные страны. Часть 1.

Самым первым систематичным и удобным подходом к решению задачи стал GNU GetText: https://ru.wikipedia.org/wiki/Gettext, хранение переводов в .po файлах или их модификациях.

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

Android - https://developer.android.com/guide/topics/resources/localization

iOs -https://developer.apple.com/library/content/documentation/MacOSX/Conceptual/BPInternational/LocalizingYourApp/LocalizingYourApp.html

php/Symphony - https://symfony.com/doc/current/components/translation.html, включающий в себе массу провайдеров поставщиков переводов, в том числе и  https://api.symfony.com/4.0/Symfony/Component/Translation/Loader/MoFileLoader.html

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

Задача эта настолько непроста и зависит от множества людей и факторов, что, например, телеграмму пришлось даже запустить собственную платформу для переводов: https://translations.telegram.org/

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

https://crowdin.com/
https://gitlocalize.com/
https://poeditor.com/
https://localise.biz/

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

Так, например, для андроида вместо .po файлов используется аналог strings.xml, а для ios -  Localizable.strings

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

Итого, true way для локализации является использование gettext или аналогов в стыковке с платформой по менеджменту переводов, умеющей экспортировать переводы в нужные форматы.

Про локализацию сервисов под разные страны. Часть 2.

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

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

3. Если у Тебя хоть сколько-нибудь нормальный клиент-сайд интерфейс, то переводы потребуется и для него на стороне клиента.

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

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

6. Когда Ты соберёшься передавать тексты в перевод, то для каждого короткого текста потребуется комментарий, который описывает контекст, в котором нужен перевод (одно и тоже слов, как Ты знаешь, может иметь несколько значений). Более того, в такой комментарий потребуется точный перечень мест в интерфейс (и как до него добраться), где оно используется.

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

8. Таймзона в БД имеет значение. И вывод времени в нужной таймзоне тоже. В отдельных сложных случаях без костылей не обойтись. Например, по тайландскому летоисчислению, сейчас 2555 год.

9. Проект must be in UTF-8. Иначе вымрешь сразу же.
Вывод чисел с десятичной точкой в разных странах отличается. Будь готов.

10. Поиск по сайту. Каким бы ты не пользовался движком, важно знать, - все европейские языки, включая русский, процессятся специальным стеммером Snowball. Это такая штука, без которой орфография не будет работать вообще. НО для некоторых языков Snowball-а не хватит и движок заточенный под работу с ним станет бесполезной обузой. Чтобы решить проблему поройся по интернету и разберись, какие бывают стеммеры. Да, кстати, для некоторых языков символ пробела (" ") не является разделителем слов (сюрприз!).

11. Никогда не храни исходники текстов в html, - Ты его тупо не сможешь отдать на перевод, который тарифицируется по-символьно. Используй форматы типа wiki-markup или markdown.

12. Никогда не храни в .po файлах (это способ хранения коротких фраз для переводов с использование упомянутого тут всеми gettext) в лексемах что-либо кроме самого текста.

13. Для gettext-а НЕ ИСПОЛЬЗУЙ в качестве идентификаторов лексем русскую фразу, - ты не сможешь такой набор экспортировать на client-side.

Обсудить за локализацию софта тут: t.me/ctorecordschat

Размер команды

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

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

Обсудить за решения для команды тут: t.me/ctorecordschat

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

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

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

Всё гениально!

@eapotapov анонсирует регистрацию на весенний Uptime day началась!

Он состоится 12 апреля.
Тема конференции — обзор организации резервирования веб-проектов со сложной распределённой архитектурой: способы переключения с боевого окружения на резервное, а также разбор различных сценариев отката и переключения на резервную площадку в случае неудачного деплоя.

Доклады:
Qrator Labs — "Построение и эксплуатация отказоустойчивой anycast-сети";
Badoo — "Nginx + Keepalived: как надёжно отдавать 200k фоток в секунду";
Mail.Ru cloud solutions — "Как реализуется отказоустойчивая веб-архитектура в Mail.Ru Cloud Solutions";
ITSumma — "Резервирование в K8s";
AdminDivision — "Failover: нас губит перфекционизм и лень";
Битрикс24 — "Быстро поднятое не считается упавшим".

Участие, как всегда, бесплатное. Регистрируйтесь на https://uptime.community/ru/uptimeday-4

Бойся своих побед

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

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

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

Почему? Потому что победа тимлида, - это оставаться в игре, а не быть в ней победителем. Ты или в игре или Тебя сливают.

Обсудить за победы и достижения в работе тут: http://t.me/ctorecordschat

Посредники важны (откровенный наброс на вентилятор)

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

Стоит такой специалист дорого, цена ошибки велика: знает ли он своё дело? умеет ли он строить отношения в коллективе? развивается ли? Он для нас - незнакомая местность, где требуется проводник. Как известно, из плохих работников получаются великолепные ветераны и мне остаётся только прозвонить по предыдущим местам работы, найти "проводника" из числа руководителей "ветерана" или его подчинённых.

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

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

Доклад Алексея Катаева из Skyeng на TeamleadConf 2019: Мотивация, делегирование и автоматизация: рецепт создания суперкоманды. Часть 1.

http://teamleadconf.ru/moscow/2019/abstracts/4445
Конспект от Николая Волынкина @Nick_Volynkin, основателя @docops

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

Приходят к Диме: продакт с задачами, CTO с наймом, разработчики с повышением зарплаты. И уровень ада растёт.

* Дима не высыпается
* Задачи теряются
* Дима хочет сказать «ой, всё» и уйти.
* Дима может что-нибудь крупно профакапить.

Будем помогать Диме убирать ад и делать суперкоманду.

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

А тимлид (как Дима):

* технический лидер
* менеджер проекта
* лидер и наставник.

Конкретно, сейчас тимлид должен делать:

* важные штуки,
* нужно что-то делегировать и автоматизировать,
* рутинные задачи.

А вот что тимлид хочет делать:

* важные штуки.

И всё. Что с этим делать? Казалось бы:

* делегируем,
* автоматизируем,
* и всё хорошо, конец доклада,
* но нет! Так не получится!

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

Что делать-то?

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

   * Отказался отвечать в личке.
   * Создал канал #billing для вопросов про биллинг.
   * Назначил дежурных (это разработчики или QA). Если дежурный не может ответить — дергает ответственного за эту часть разработчика.
   * Написал правила, как писать обращения в саппорт.
   * Заказал разработку бота, который форсит эти правила.

* Отдавать ассистентам задачи, требующие низкой квалификации.

 В Skyeng есть отдел административных ассистентов.
 Такой внутренний YouDo, только с подписанным NDA, контролем качества и четким workflow.
 
 Что делегируют ассистентам:
 
 * рутинные задачи
 * перебрать кучу документов
 * рассортировать кучу документов
 * ...

 
* Не тушить пожары!

 Настроить автоэскалацию и назначить дежурных. Себя убрать из графика. Если разработчик не берёт — только тогда берет тимлид.

 Чтобы разработчики могли чинить проблемы, даем им доступ во всю аналитику, рутовый доступ на серверы и PANIC Doc — инструкцию по тушению пожаров.
 
*  Нормально делегируем техническое ревью:

   * Зачем проводить
   * Как провести — инструкция по шагам
   * Советы для ведущего
   * Шаблоны всех нужных документов
   * Примеры, success story

   Всё это — инструкция в Skyeng, над которой работали все тимлиды.
   В ней объединён опыт всей компании.
   
   Техническое ревью хотят проводить все разработчики.
   Но нельзя исключать себя из этого процесса.
   
   Стали собирать фидбек после встречи.
   Каждый участник даёт фидбек процессу и другим участникам:
   
   * интересно?
   * конструктивно?
   * все мнения услышаны?
   * свободный фидбэк

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

 Например:
 
 * Качество или скорость?
 * Можно ли аутсорсить?
 * Думаем ли о последствиях?

 Вещи, которые записаны, обладают магическим действием (вольная цитата, Юваль Ноэль Харрари).
 
 Ещё принципы:
 
 * Открыто говорим о проблемах и рисках
 * Не делаем ничего зря
 * Общаемся культурно
 
 Самый противоречивый принцип
 
 * <strike>Личная жизнь важнее, чем Skyeng</strike> (отклонили)
 * Домашнее дома, рабочее — на работе (приняли)

Задача тимлида Димы — не бегать и отвечать на вопросы, а выстроить систему, которая решает задачи и выдаёт ответы.

Роль: пушер. Пропушивает задачи вперёд по канбану. Назначается дежурный, участвуют все по очереди.

Каждую пятницу — семь минут рассказа о том, что сделал. Не «что делал», а именно что сделал. 99% сделано — не сделано. И там же есть слайд «что сделаю на следующей неделе», этот слайд попадает в презентацию следующей недели.

Доклад Алексея Катаева из Skyeng на TeamleadConf 2019: Мотивация, делегирование и автоматизация: рецепт создания суперкоманды. Часть 2.

http://teamleadconf.ru/moscow/2019/abstracts/4445
Конспект от Николая Волынкина @Nick_Volynkin, основателя @docops

## Эксперимент
 
Вот так выглядит flow разработки в Skyeng.

1. Цель
1. План
1. Проблемы
1. Решения
1. Технические решения.

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

Так вот, эксперимент. Продакт ставит только цель. Большая команда делится на маленькие проектные команды, которые вырабатывают план, проблемы и решения. Продакт и тимлид — только консультанты.

# Важные штуки

Что сюда входит?

* Мотивация команды. Если тимлид тухлый, то и команда тухлая.
* Найм и увольнение. Только тимлид видит всю команду целиком.
* 1:1 (встречи один на один). Тимлид даёт и получает обратную связь.
* Революционные изменения. Крутые команды сами могут так делать, но всё равно это задача тимлида.

# Чем занять освободившееся время?

Делать больше важных штук.

# Бонусы

1. Принципы
1. Алгоритм тех. ревью
1. Шаблон демо
1. Правила обращений в канал.

Полностью весь конспект тут: https://github.com/NickVolynkin/teamleadconf-19/blob/master/source/superteam.md

Почему запрещено говорить размер своей зп

На общем корпоративе Иванов шутит: "Вон Петров чуть ли не порнуху вместо работы смотрит, а зп у него выше! Давай всем разрешим порнуху смотреть?" Что ему ответить? Очень неудобная и неприятная ситуация.

В чём именно заключается неудобство и неприятность? Ведь Иванов прав, - Петров действительно халявчик и лентяй. Не уволили его только потому, что он приготовлен на конец года, когда скорее всего будет сокращение на 10%. Это уже не Петров, а балласт, который нужен, чтобы сбросить именно Петрова, а не Иванова, который супер-сеньор.

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

Если правильно не отреагировать, завтра он начнёт об этом говорить публично. Послезавтра начнёт не только сомневаться, а ещё и оспаривать Твои решения. На него будут смотреть менее мастистые коллеги, как на лидера мнений и будут брать пример.

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

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

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

- Иванов, у Тебя, вижу, даже на корпоративе слишком много свободного времени! Раз так, пойдём посмотрим в жиру, что у нас готово к демонстрации в понедельник!

Обсудить за чужие зп тут: http://t.me/ctorecordschat

Про админов и то, как я поверил в волшебство!

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

Мы собрались все в едином zoom-созвоне и синхронизировались в происходящем, - каждый рассказал, как видит ситуацию. К слову сказать, ребята-админы вполне вменяемые опытные специалисты... Да и как люди очень даже ничего! Арументы были железные, - ситуация была безвыходная, а кошелёк компании стремительно худел!

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

Я на сутки выкинул проблему из головы и абсолютно забыл о ней. Потом где-то за несколько минут до созвона в чатике спрашиваю, "все ли готовы?" и получаю ответ, что оказывается парни-админы закончили переносить БД  час назада! Вот это поворот!

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

Компания прекратила платить деньги за два ДЦ, переезд был завершён и вопрос таким образом сам решился! Того админа из девопсовой конторы так и не позвали! Зачем? Сами справились же!

Волшебство!

Мелочи - это детали, значение которых мы не понимаем.

На каждом сколько-нибудь серьезном сервисе всегда используется рассылалка писем/смс/пушей для самых разных нужд: от триггерных сообщений о событиях до маркетинговых рассылок.

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

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

Суть: при разработке независимо от квалификации всегда кто-то ошибётся и произведет тестовую рассылку на всю продакшн базу.

За последние 10 лет по статистике накопленной на 63 командах не было ни одного исключения. Ни одного.

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

Обсудить за мелочи тут: t.me/ctorecordschat