Коля Митин говорит

Медиаинвестиции

Вам покажется, что пост про политику, но он про то, как эффективно работать в Ай-Ти и не только

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

Объясняю
Представьте, что вы купили акций Газпрома на всю котлету. Начинаете читать новости про него и вам начинает казаться, что компанией управляют как-то не так. И, вместо того, чтобы разобраться, как и зачем там принимают какие-то решения, что от чего зависит, какие перед Газпромом вызовы, задачи и прочее, вы начинаете строчить гневные тексты на профильных сайтах и в соц. сетях. Устраиваете пикеты перед главным офисом компании и т.д. И чем эффективнее ваша деятельность, тем дешевле становится ваш актив. Очевидно-же?

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

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

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

  "errors": [
    {
      "code": "missing_header",
      "message": "В файле отсутствует заголовок"
    }
 ],

Что-то забыли... Помочь разработчику понять, как исправить проблему. Добавим полезную информацию:

  "errors": [
    {
      "code": "missing_header",
      "message": "Нет заголовка в файле. Убедитесь, что первая строка в загружаемом файле вот такая: article;subject;date;quantity;source;address"
    }
 ],

Теперь проверим количество столбцов в строке:

  "errors": [
    {
      "code": "missing_header",
      "message": "Неверное количество значений в строке"
    }
  ],

И опять. В какой строке? Каких значений? Дополним вывод

  "errors": [
    {
      "code": "invalid_row",
      "message": "Количество значений в строке не равно 6. Убедитесь, что в строке ровно пять разделителей ';' и на конце строки нет этого символа",
      "row": 2,
      "content": [
        "24422",
        "Товар 1",
        "2024-06-30",
        "1",
        "any",
        "",
        ""
      ]
    }
  ],

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

  "errors": [
    {
      "code": "invalid_row",
      "message": "Количество значений в строке не равно 6. Убедитесь, что в строке ровно пять разделителей ';' и на конце строки нет этого символа",
      "row": 2,
      "content": [
        "24422,\"Товар 1\",\"2024-06-30\",\"1\",\"any\",\"\","
      ]
    }
  ]

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

  "errors": [
    {
      "code": "empty_address",
      "message": "Пустой адрес. Если у торговой точки нет адреса, то передавайте строку «Без адреса»",
      "row": 2
    }
  ],

В сообщении сразу подсказка и номер строки с ошибкой.

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

Обрабатывайте ошибки правильно, пересылайте своим разработчикам, всем чмоки!

Обрабатываем ошибки правильно

Ранее, я писал, что обрабатывать ошибки надо правильно. Наши разработчики пофиксили проблему

Дано
нужно принять CSV-файл и загрузить данные из него в базу.

Как было
Файл загружался, метод загрузки возвращал «Accepted for handle», далее стартовала задача, проходила по всему файлу построчно, выкидывала строки, если в них не 6 столбцов, остальные загружала в базу.

    while ($file->valid()) {
      $data = $file->fgetcsv(';');
      if (!is_array($data) || count($data) !== 6) {
        continue;
      }
    }

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

Никуда не годится!

Как стало
Реализовали проверку данных сразу в процессе загрузки и возврат ошибок в виде JSON-объекта. Разделили метод загрузки, на два: один просто проверяет файл, а второй проверяет и загружает в базу. Первый нужен, чтобы пробовать загружать, исправлять и пробовать ещё раз. То есть для разработки. Второй для реальной загрузки. Самый сок этой работы именно в обработке ошибок. О ней подробнее.

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

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

О загрузке CSV мы уже знаем очень много, поэтому есть две типовые проблемы: кодировка и разделители. Они происходят из того, что Microsoft Excel по умолчанию разделяет значения в файле, который имеет тип *значения разделённые запятой* точкой с запятой. А ещё русская версия экселя сохраняет CSV в кодировке Windows-1251. Да, в 2024 году! Да, последняя версия тоже! Думаю, что это уже скорее для обратной совместимости.

В нашей системе, мы имеем гибрид. Она принимает файлы с разделителем ;, но при этом в кодировке UTF-8. Почему так мне не ведомо, но переделать пока нет возможности, потому что система уже запущена и работает. Уже есть много клиентов и каждый день подключаются новые.

Тезисы для самопроверки
1. Находим все ошибки, но не исправляем их
2. Даём разработчику максимум информации для устранения ошибок
3. Все данные должны быть указаны, никаких значений по-умолчанию

Соответственно, делаем проверку на кодировку:

  "errors": [
    {
      "code": "invalid_encoding",
      "message": "Неправильная кодировка файла"
    }
 ],

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

  "errors": [
    {
      "code": "invalid_encoding",
      "message": "Файл должен быть в кодировке UTF-8, текущая кодировка: Windows-1251"
    }
 ],

Вот! Другое дело! Теперь понятно, чего мы ждём.

⬇️⬇️⬇️

Ладно, вот вам отличная актуальная рабочая шутейка:

— Слыш, ты в интернете только такой смелый? Да я тебе глаз на жопу натяну в реале!
— Да? Ну давай! Приезжай!
— Приеду!
— Приедешь?!
— Приеду!
— Когда? Буду ждать!
— У тебя во вторник и четверг во второй половине дня слоты есть?

По горячим следам

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

А иначе это какой-то GPT-программист, который умеет только ТЗ в код переводить. Ценность такого человека сомнительная.

Как программисты-технократы увеличивают стоимость поддержки продукта

К нам пришёл проект на поддержку, который построен вокруг получения и обработки больших массивов данных из разных источников. Проект написан на Ларавеле (это такая болванка того, чтобы быстро и понятно запускать веб-сервисы), всё чистенько, аккуратно, по гайдлайнам, архитектурные решения все по делу. С точки зрения программирования всё хорошо. Но при этом каждый день приходят по 10 писем от пользователей, что не работает то, не грузится сё, непонятно тут, непонятно там. При этом пользователей у проекта не сказать, что много. То есть в процентном соотношении большое количество пользователей страдают.

Но как же так?

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

Возьмём простой пример. Есть в системе загрузка экселевского файла: пользователь загружает файл с шестью столбцами с определёнными заголовками, файл обрабатывается, данные появляются в табличке на сайте. Очень простая история. Что же тут может пойти не так?

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

А ещё она не обрабатывает файлы, если файл с таким именем уже был загружен ранее.

И делает это МОЛЧА. То есть никакого лога, никакой обратной связи пользователю по результатам обработки, ничего! Просто пропускает строки.

И вот пользователь, значит, загрузил файл, сидит ждёт данные. А их нет или есть, но не все. Что он делает дальше? Правильно пишет обычное письмо: «Я гружу на ваш портал данные, у меня ничего не грузится, что делать?» Не питайте иллюзий, это типовое обращение в поддержку. И вот оператор поддержки будет по крупицам вытаскивать хоть какую-то информацию. И это будет цепочка из 20 писем. Пользователь будет раздражаться, что вместо решения проблемы, его просят какие-то скриншоты отправлять, файлы присылать и вот эти вот все типовые издевательства.

Стоимость такой переписке в человекочасах колоссальная!

А все потому что программист-технократ не понимает, что пользователи сделают всё не идеально:
— Прочитают инструкцию и поймут её не так
— Будут грузить файлы с 5, 7, 10 столбцами
— Будут грузить не данные, а какую-то чушь
— Будут грузить не эксельки а цсвшки
— Ещё как-то развлекут систему

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

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

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

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

Добрый день! Прекрасный вопрос!

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

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

Думаю, что когда вы начинали работать с вашим клиентом, то первые две-три итерации у вас были проблемы, которые как-то разрешали, вырабатывали протоколы, которые (надеюсь) фиксировали в виде скриптов или документов. Со временем вы начали понимать друг-друга с полуслова и механизм стал работать практически без сбоев. То есть вы пусконаладили все процессы.

Вот возьмите весь этот опыт, назначьте встречу с новым менеджером, и пройдитесь по всем вопросам подробно и участливо.
Разберите ситуации на примерах.
Если вы обмениваетесь каким-то данными/выгрузками, то проведите внеплановый тестовый обмен.
Покажите как вы ставите и принимаете задачи.
Убедитесь, что менеджер добавлен во все ЦРМки, ЦМСки, Хелпдески и прочие важные системы.

Даже если вам кажется, что клиент должен был сам сделать это всё, не факт, что он это сделал. Чем больше компания, с которой вы работаете, тем выше риски, что человеку просто отгрузили проект, а предыдущий человек ушёл на повышение или в другую компанию и у него сейчас примерно такая же история «Я НИЧЕГО НЕ ПОНИМАЮ».

А если вы работаете с корпорацией, то в 99% случаев виноваты будете вы. С этим нет смысла бороться, проще разработать протоколы дэмедж-контроля и следовать им в таких случаях.

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

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

Главный секрет успеха любого проекта

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

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

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

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

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

Не заполнить контентом

У Ильи Бирмана вышел любопытный пост про кнопку «Стать клиентом». Вкратце он про то, что кнопка «Стать клиентом» ничего не значит. Если написать «Записаться на шиномонтаж», «Купить подписку», то будет понятнее.

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

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

Стоимость обслуживания. Неочевидное

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

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

Оказалось, что из-за того, что не продумали сценарии бэкофиса, и товароведам (назовём их так) стало неудобно управлять карточками товаров и обрабатывать заказы. Как следствие участились ошибки и количество конфликтов с клиентами выросло. В какой-то момент негативный эффект и повышение расходов полностью нивелировал повышение конверсии. И как говорится: эксперимент, очевидно, неудачный.

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

Ну вот! Наконец-то первые проблески интеллекта. Так глядишь и правда человеком станет. (Это, кстати, почти не шутка. Напишу как-нибудь почему)

Observatory Management System. Коробочная версия

Я понял! Нейросети сейчас делают реверс-инжиниринг человеческой культуры по текстам и изображениям.

Занимаются информационной археологией, так сказать

В Unicode 16 собираются добавить египетские иероглифы.

Сколько, интересно, мемов начнут делать в чатах с их помощью?

https://www.unicode.org/charts/PDF/Unicode-16.0/U160-13460.pdf

Ну и с 8 Марта заодно.

Удивительное непонимание своего рынка

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

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

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

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

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

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

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

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

Переключения передач — это точки кратного роста или даже порядкового роста компании.

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

Сегодня в Кортексе завершился подпроект большого проекта, в котором я:
1. Получил ТЗ от нашего клиента
2. Отправил его на оценку и планирование команде
3. Согласовал полученные сроки с клиентом
....
4. Выслал клиенту акт о приёме работы

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

Оказывается, если следить за здоровьем компании и команд, внедрять процессы и приучаться им следовать, то так может быть!

Спасибо девчатам и ребятам из Кортекса, за что, что всё сделали, не создав лишних проблем по пути. Это прямо прорыв!

С днём всех влюблённых!

Я: Уважаемый СКБ Контур, очень хочу платить вам 19 000 в год.
СКБ Контур: