будни

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

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

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

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

Клиент получает быстрый запуск MVP, качественные процессы разработки и минимальную стоимость дальнейшего развития. Нам с Федей не скучно и есть чем привлечь к себе особо горячих программистов. А ещё это кармически правильно — в мире становится больше команд, в которых приятно работать.

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

Чайка — один из таких примеров. Классные ребята, рекомендую.

Извините, перегрузка на работе.

Сначала ад с запуском игры "делай деньги". Потом сетевая авария в scaleway, из-за которой пришлось немного поработать ночью. Ну и фоном подготовка к очень крупному запуску.

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

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

Мы уже вовсю работаем над новым, 13 сезоном; скоро запуск. Только что записали эпизод про ИИ-инфлюенсеров, у меня было 6 утра, у гостя — 8 вечера, у редактора вообще 11 ночи.

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

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

Новый публичный сезон — скоро!

Очень волнительно. В какой-то момент, после 10 сезонов была усталость, а теперь как будто новое дыхание — пробуем новые темы, новые форматы. Идеи и предложения можно обсудить в чате подкаста (нас там уже 1500!) или отправить записку команде через бота.

Составляем карту технологических зависимостей Медузы.

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

Посередине слева — полный список «пользовательских view»: то, откуда можно читать Медузу. Web, iOS, Android, Instant Articles, etc. 20 пунктов.

Ряд сверху — список зависимостей для каждого View. Зависимости есть от внутренних сервисов и от внешних.

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

Где лучше составлять такие схемы? Я пока остановился на Scapple. Кстати, эта же компания уже много лет производит очень мощную программу для писателей Scrivener — ведь не всем писателям нравится WordStar.

Извините, что не хайрез. Смысл, надеюсь, понятен.

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

Вчера была ровно такая встреча с разработчиками сети клиник доказательной медицины «Чайка». Что за программисты в сети медицинских клиник? «Картриджи в принтерах меняют?!», спросите вы.

У Чайки десяток больших информационных систем: ядро — Медицинская Информационная Система, в которой врачи ведут медицинские карты пациентов, лабораторная система для обмена данными с лабораториями типа Invitro, продвинутый модуль BI для анализа финансовых показателей и тд. А ещё у них есть амбиция продавать свои технические решения на международном рынке.

Большую часть этих систем Чайка программирует инхаус командой из 15 программистов, тестировщиков и 3 продакт-менеджеров. Nodejs, php, typescript, postgres — современный стартап, но в отличие от обычного стартапа, если наши системы упадут, то 600 врачей не смогут эффективно лечить людей.

Нас с Федей позвали, потому что исторически в Чайке не было компетенции управления разработкой и команда перестала справляться с объемом хотелок бизнеса. Классическая история: со временем вырос и техдолг и скоуп.

В мае мы подключили несколько своих программистов и сейчас готовимся к запуску первого совместного продукта — AstraShare. Это модуль, который позволяет делиться частями медицинской карты пациента со внешними врачами в электронном виде; например, когда нужно отправить клиента на операцию или для получения второго мнения. В отличие от остальных систем Чайки, модуль построен на основе международного стандарта FHIR.

Ещё мы с Федей анализируем, как можем отрефакторить некоторые уже существующие части системы. Мы много общаемся с бизнесом и дизайнером, но плохо коммуницировали то, что делаем, текущему тимлиду, в результате накопилось много вопросов. Сделали заметку на будущее — больше общаться с внутренними командами заказчика. Эх, пишу это и понимаю, что всё не то.

Самый кайф — в сути того, что мы говорили, заперевшись в переговорке на полтора часа вместо запланированного часа. Как рубились по фактам, ругались и даже кричали, не понимая друг-друга (ок, кричал я один), а в результате — разобрались и договорились, как работать дальше вместе. Обожаю личные встречи, никакой зум не заменит ❤️

Кстати, мы ищем технического директора в Чайку, вот вакансия. Рекомендую.

Есть старая шутка, что в программировании есть только две сложности — инвалидация кеша и придумывать названия вещам.

Меня больше достают интеграции. Когда разные системы должны работать вместе.

Недавняя авария AWS — это радикальный вариант с точки зрения взаимозависимости сложных систем, но вот совсем простой пример от нашего клиента.

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

Только коды эти приходят по почте. Поэтому они попросили завести в почтовой системе клиента адреса для отправки и получения. Что может пойти не так? Да всё!

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

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

Жду, когда эти письма начнут попадать в спам.

Если можно обойтись без внешних зависимостей и интеграций — лучше без них!

Тормозит приложение.

На днях написала топ-менеджер одной ритейл-сети. Тормозит мобильное приложение. Медленно работает поиск, добавление в корзину, оформление заказа. Нажимаешь на кнопку и ждешь…

В ритейле каждая доля секунды задержки — это люди, которые не купили товары, прямые потери. Мобильные разработчики не исправляют ситуацию. Переводят стрелки на бэкендеров, мол это бэкенд тормозит. Как разобраться, на чьей стороне сломалось и починить проблему?

Хорошие разработчики собирают аналитику по производительности своих приложений — какое время занимают ключевые действия типа «открытие главной», «поиск», «добавление в корзину», «оплата». Это называется Real User Monitoring.

Дальше мы кладем эту информацию на график: на оси Х — время, которое занимает действие, на оси Y — количество пользователей. Столбики слева — хорошо. Длинный хвост справа — это несчастные, у них, например, экран оплаты грузится минуту! Эти люди поменяют приложение, если у них будет выбор!

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

Тут поможет другой классический график: на оси Х — время (вчера, сегодня в течении дня, завтра), на оси Y — время ответа (задержка, latency). Три черты — среднее время, медиана и 95 персентиль. То есть за сколько миллисекунд происходит оплата в среднем, у медианы и за какое время происходит оплата у 95% быстрых пользователей? Он помогает отследить, нет ли тормозов в определенное время суток или в день недели.

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

Итак, шаг первый — замерить экраны и действия.

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

Тут мы опираемся на те же два графика, но уже смотрим скорость ответа бэкенда.

Качественно настроить сбор данных и дэшборды — это дополнительная работа, но она с лихвой окупается при расследовании проблем.

Хотите заказать классную разработку или аудит? Обращайтесь! @samatg https://fansdev.ru