Русский
Русский
English
Статистика
Реклама

Управление проектами

Странные управленческие решения внутри хостинга

15.06.2021 14:10:21 | Автор: admin
Звонит как-то вендор и говорит, что в возврате бракованного железа не их жёсткий диск.


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

Гарантийный отдел ковыряется с диском, а потом звонят:

А зачем вы подменили диск?

Мы такие:

В смысле подменили?

Мы вам продавали другой. А тут корпус тот, а внутри другой. Какие-то следы от отвёртки.

Дичь полнейшая! Мы начали было ругаться, но потом стали разбираться. Начали смотреть на камеры и увидели, что наш сотрудник очень подозрительно себя вёл, когда работал с этим диском в стойке. Как в плохих комедиях про жуликов: постоянно осматривался по сторонам, отходил в сторону, возвращался. Оказалось, что он подменил диск. Честно, я не знаю зачем. Его финансовая выгода минимальная, скорее всего, даже не окупает время работы по замене корпуса.

У нас было ещё несколько странных ситуаций, и сейчас я о них расскажу.

Форекс-трейдер


VDS часто покупаются для торговли на биржах. Ну, на нормальных биржах: я имею в виду тех, где важно географическое расположение сервера для минимизации задержек. Но есть и биржи уровня Форекса. Вернее их даже биржами назвать нельзя. Это на сленге трейдеров кухня. Напомню, что многие из них попали в список компаний с признаками нелегальной деятельности, который завёл ЦБ. У меня есть глубокое личное убеждение, основанное на здравом смысле и математике, что система работает как качели для вытаскивания денег из не самых разбирающихся в вопросе клиентов. Возможно, это не так, но свою точку зрения я могу аргументировать и обосновать при необходимости. Но в истории важно другое. Звонит мой знакомый, который взял у нас сервер в Швейцарии. И вот он начинает в открытую меня и всех наших сотрудников обвинять в том, что мы залезаем к нему на сервер в процессе торгов и вмешиваемся в его форекс-сделки.

По его словам, он придумал великую стратегию, а убыточные сделки берутся рынком, плюсовые же вовремя не берутся, игнорируются. И в этом виноваты мы. Точнее, сначала он обратился с задачей, что его не устраивает производительность сервера. С его слов, она радикально падала в момент выхода новостей. В 16:30, когда выходит мировая статистика. В этот момент времени все трейдеры, кто работает с помощью автоматических торговых систем, начинают многократно усиливать свою активность. Если, грубо говоря, внутри дня он делает десять сделок, то в эти 16:30 и одну минуту он может сделать сто сделок. Естественно, это создаёт пик нагрузки, причём не локально, а на принимающем сервере. Но трейдер этого не понимает, он думает, что у нас сервер именно в 16:30, когда ему надо выставить заявку или закрыть заявку, тормозит. А это совпадает с самым нужным временем. И не верится, что это просто совпадение.

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

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

Игровые серверы школьников


Школьники довольно часто размещают у нас игровые серверы. Это, скажем так, сложные клиенты, потому что они выбирают третий по цене тарифный план. Первый это промо за 30 рублей в месяц (по цене IP), второй урезанная версия стандартных конфигураций за 130 рублей и третий уже полноценный сервер от 300 рублей в месяц.

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

Поддержка вежливо объясняет суть проблемы и предлагает подключить защиту от DDOS-атак за 400 рублей (причём первый месяц бесплатно). По нашей практике, потом можно будет играть совершенно спокойно. На что клиент начинает нас обвинять в том, что это мы специально дидосим его, чтобы он нам заплатил ещё. Далее закономерно встаёт вопрос о возврате средств, и обычно мы средства возвращаем и с лёгкостью расстаёмся с таким клиентом.

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

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

Самый короткий детектив


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

И вот пишет клиент, что наш сервер не отвечает.

Мы просим трассировку. Клиент делает, присылает. Мы сообщаем, что RDP блокирует его отель, и желаем приятного отпуска в Таиланде. Клиент немного в панике, но мы поясняем, что его Wi-Fi-точка названа именно по отелю. И даём ссылку на то, как это обойти. В тот раз помогло.

Регистрации под ботами


Очень странная ситуация была с тестовыми периодами на наших 32-ядерных машинах. Кто-то научился брать американские номера, парсить голос, русский текст и цифры. Как только криптовалюты совершали очередной прыжок, начинались авторегистрации, а дальше серверы использовались (судя по характеру нагрузки) для майнинга криптовалют. Не знаю, что это было, но майнить биткоин на VDS без видеокарты идея откровенно так себе. Процессор уходит в потолок, три дня они пытаются что-то там сделать, потом период заканчивается. Мы обновили капчи, но на следующей волне скачка курса биткоина снова начались авторегистрации. Я откровенно не понимаю, какой в этом смысл, ведь аренда американского номера стоит дороже, чем возможный профит с майнинга на процессоре три дня. Сейчас эти волны мы наконец-то победили.

Блокировки по IP


Мы выдаём один статический IP клиенту при аренде сервера. Это не карусель динамических адресов, не замены раз в месяц, а конкретный IP, привязанный к клиенту. Сначала мы проверяем его чистоту и отсутствие во всяких чёрных списках, а потом даём клиенту.

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

Ещё накручивают отзывы и просмотры на Амазоне. Потом в поддержке: Ребята, это мой не первый аккаунт, можете, пожалуйста, сменить мне IP-адрес, потому что меня забанило?

Бывает так, что админ настраивает клиенту работу на сервере, но забывает уточнить вопрос про лицензии. Звонит генеральный директор, у которого 25 сотрудников, и они все сидят на удалённом рабочем столе, у нас размещали соответственно. Весь замес в том, что системный администратор, который это настраивал, был на аутсорсе. Он настроил кучу виртуальных рабочих мест. Человек платил около 35 тысяч. У него там размещалось 25 сотрудников, и 120 дней человек вообще не знал никакой проблемы с подключением к удалённому рабочему столу. А цимес в том, что Майкрософт даёт триалку на размещение этого удалённого сервера рабочих столов 120 дней ровно. Человек четыре месяца, получается, пользуется, и тут внезапно посреди пятого месяца обнаруживает, что у него ни один сотрудник не может зайти. Диктует нам ошибку, мы всё прекрасно понимаем, что у него там происходит. И предлагаем ему два варианта:

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

В общем, ребят, я не буду платить тройную цену от сервака.

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

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

А вы точно понимаете, что сейчас у официального партнёра MS спрашиваете, как их же обмануть?

Да! Ребята, какие ещё варианты есть?

Неожиданный уход коллеги


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

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

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

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

Дебош


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

В итоге уголовку он не получил, полицейские оказались добрыми. Оставили всего до утра к КПЗ и отпустили домой к жене и детям. Как бы конец истории, но непонятно, что делать дальше, потому что в беседе он пояснил, что нет гарантии того, что ровно такое же не повторится. Например, в офисе. Или в серверной. Или на переговорах с клиентом или ЦОДом.

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

Уничтоженный сервер 1С


Мы ужасно серьёзны в плане защиты финансовых данных своих клиентов, поскольку довольно часто наши ЦОДы в других юрисдикциях выбираются именно для этого. Одно из следствий если клиент отдаёт прямую команду из личного кабинета на удаление машины, то она именно удаляется, а не помещается в хранилище на несколько месяцев. Для подтверждения этого действия нужно ещё раз ввести пароль от ЛК.

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

Письмо приходит, в нём просьба поменять основную почту доступа.

Мы соответственно меняем почту.

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

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

Общие выводы и чем закончилась история с жёстким диском


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


Подробнее..

Перевод Сообщество как услуга. Бизнес-модель XXI века

08.06.2021 12:19:01 | Автор: admin

Какую пользу приносят сообщества и как авторы контента на этом зарабатывают.

На дворе 2021 г., и начинает казаться, что каждый первый разработчик делает собственный SaaS-продукт (ПО как услуга). Появилась возможность очень быстро реализовывать свои идеи, стало популярным вести разработку публично что само по себе здорово.

Но на фоне этого развивается другая парадигма, которую не так легко заметить и понять.

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

Сообщество как услуга

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

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

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

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

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

Сообщество как услуга состоит из двух элементов:

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

  2. Члены сообщества, которые приходят за оригинальным контентом и остаются по причинам, которые мы рассмотрим далее.

Польза для членов сообщества

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

  1. Получение знаний от автора контента: прямая передача знаний и навыков от автора аудитории.

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

  3. Построение собственной сети: предоставление ценного контента другим членам сообщества с целью построения собственного CaaS.

Я провел опрос в Твиттере по этой теме, и результаты меня удивили: мне казалось, что большинство выберет вариант 1 получение знаний у автора, но я ошибся.

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

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

Что мешает вам создать продукт, который принесет миллионы?

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

Таким образом я на собственном опыте увидел потенциал сообществ.

Польза для авторов контента

Авторы контента неофициальные лидеры сообществ. Они приносят пользу двумя путями:

  1. Делятся знаниями и опытом.

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

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

И речь здесь не только о социальных сетях: есть бизнес-модели с подпиской (например, Patreon) и чаевыми. Есть группы в Слаке, которые организуют бесплатные встречи единомышленников и иногда рекламируют платные товары.

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

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

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

Подводные камни

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

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

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

Взгляд в будущее

Что будет с моделью CaaS дальше?

Всё большее распространение получают различные способы коммуникации. Этот год начался с бума живого аудиообщения в Clubhouse (а теперь и в Spaces от Твиттера) и в результате зародились новые сообщества.

Что самый большой риск для авторов контента?

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

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

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


О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимаетсялокализацией игр,приложений и сайтовна 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаемрекламные и обучающие видеоролики для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Подробнее..

Как удвоить эффективность сотрудника при помощи цифровизации

11.06.2021 12:20:14 | Автор: admin

Всем привет!

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

Занимаясь развитием крупных брендов, увеличивая их ценность и вес на рынке, я наблюдаю за тем, как лидирующие компании усиливают свой успех. Это происходит за счёт технологий и автоматизации процессов. Часто этому способствуют HR-порталы, которые ещё в недалёком 2014 были новым веянием, а теперь стали мастхэвом.

Однажды крупная компания обратилась к нам с бизнес-задачей ежегодный рост EBITDA (прибыль до вычета процентов) на 10-15% в ближайшие 5 лет без найма новых сотрудников. Как решить эту задачу не увеличивая штат? Ответ есть цифровизовать предприятие.

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

При чем тут цифровизация?

Цифровизация способна удвоить, а то и утроить эффективность. Если у каждого сотрудника появится цифровой помощник второе цифровое я, то он:

  • уберёт ошибки;

  • автоматизирует рутинные процессы, которые занимают много времени;

  • передаст массу дополнительных знаний и инструментов.

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

Если коллеги находятся на разных этажах огромного здания, то сходить несколько раз за день туда-обратно с 1 на 9 этаж, казалось бы, несложно и занимает всего минут 30 в сумме. Но за год работы эти 30 минут превращаются в 126 часов рабочего времени одного человека. Это больше трёх рабочих недель чистого времени!

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

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

Это привело к тому, что окупаемость вложений снизилась до 3-5 лет. Возврат инвестиций стал быстрее.

Экономическая эффективность

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

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

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

Портал как якорь спасения

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

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

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

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

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

А вы в цифре?

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

  1. В вашей компании есть оцифрованные процессы, и вы работаете исключительно по ним;

  2. У вас есть примеры, когда за последние 2-3 года цифровые элементы позволили оптимизировать штат сотрудников;

  3. В постоянном использовании компании есть корпоративные инструменты взаимодействия людей на расстоянии (например, на уровне процессов внедрён Telegram или Zoom);

  4. У вас существуют цифровые системы обучения и развития сотрудников;

  5. Есть корпоративный новостной портал или корпоративная социальная сеть, в которую вовлечены сотрудники.

  6. Часть штата компании работает удалённо на постоянной основе. Есть регламенты удалённого взаимодействия.

Совпало? Поздравляю, вы восхитительны!

Редактор: Наумкина Карина.

Подробнее..

Внутренняя автоматизация почему мы отказались от low-code системы в пользу Camunda

17.06.2021 10:17:44 | Автор: admin

Привет! Меня зовут Мирослав, я инженер-разработчик проекта по реализации BPM-решений для внутренней автоматизации КРОК.

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

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

Теперь пользователь просто прописывает путь к папке, выбирает тип доступа (чтение/редактирование), оставляет при желании какой-нибудь увлекательный комментарий и все, дальше все делает BPMN.

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

Каким мы хотели видеть BPMS

Потребность в новой BPM-системе стала очевидной еще в 2018 году. Текущая K2 4.7 не шла в ногу со временем, а K2 5.0 не устроила нашу команду. В конце 2018 года менеджер нашего проекта в компании пары аналитиков начали изучать рынок BPM-решений в поисках альтернативы.

Тогда как раз набирала обороты глобальная трансформация КРОК (что это значит, в одном абзаце не объяснить, поэтому просто оставлю это здесь как факт). Бизнес повсеместно стремился к изменениям, и это, конечно же, влияло на нас. То, как было по-старому, работать перестало нужны были гибкая разработка, регулярные демо, работа бок о бок с заказчиком на понятном ему языке.

Нашей идеальной системе предстояло усилить взаимодействие команды с заказчиками и ускорить процесс разработки. Для этого отлично подходили iBPMS, в которых, при нашем сценарии использования, ведущая роль разработки отводилась аналитику и автогенерируемому интерфейсу. Именно аналитик должен был проектировать BPM-схему, собирать модель данных и создавать страницы в UI-дизайнере. Разработчики, в свою очередь, должны были насытить BPM-схему логикой при помощи скриптов, а также развернуть окружение и наладить workflow внедрения новых бизнес-процессов.

Спустя пару месяцев наш выбор пал на Bonita, а в феврале 2019 года мне поручили ее внедрение на нашем проекте.

Опыт использования Bonita

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

Архитектура Bonita BPMАрхитектура Bonita BPM

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

Bonita Studio

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

С чем столкнулись

  • Моделлер рисования схем сам по себе показался не очень удобным, так как достаточно криво отрисовывал XML. Редактирование схем и приведение их к единому стилю иногда доставляло боль.

Вот так выглядит BPMN-схема для процесса "Выдача прав доступа" в BonitaВот так выглядит BPMN-схема для процесса "Выдача прав доступа" в Bonita
  • Ограничение лицензии не позволяло нам открыть два окна Bonita Studio, а значит, два проекта одновременно, чтобы скопировать схемы или скрипты.

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

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

    Дальше мы старались писать фронтенд по старинке, при помощи Angular 2+, и налаживать взаимодействие с Bonita через REST API.

Bonita Portal

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

С чем столкнулись

  • Такое пространство удобное решение, если нет необходимости его дорабатывать. У Bonita есть возможность кастомизировать портал при помощи архивов стилей, накатываемых прямо в Web. Мы легко перекрасили оформление и даже поменяли язык всего портала на русский. Но когда дело дошло до каких-то детальных изменений, не предусмотренных BonitaSoft, мы столкнулись с проблемой для подобных доработок Bonita Portal не был приспособлен.

  • В Bonita Portal можно редактировать скрипты и параметры бизнес-процессов в runtime. Это достаточно мощное решение, с которым можно здесь и сейчас устранить проблемы пользователей, но в перспективе эта опция создает огромные проблемы и хаос в Production среде. И естественно с этими перспективами мы столкнулись лицом к лицу. Но это уже совсем другая история :D.

Bonita Runtime

К этой части вопросов почти не было. Движок требует настройки, документация не идеальна, но сам по себе он работает хорошо и REST API у него описан достаточно подробно.

Version Control

Это опция Bonita Studio, которая обеспечивает взаимодействие с Git-репозиториями. Не очень красивая, и на самом деле, совершенно необязательная, так как можно воспользоваться каким угодно иным инструментом для работы с Git. Но работает исправно :)

Bonita Storage

С чем столкнулись

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

  • После создания модель данных содержалась в xml-файле, который необходимо было заархивировать и развернуть в Bonita Portal.

XML-схема, которую генерит Bonita на основе business data model. Далее в соответствии с этой схемой будут созданы таблицы в БДXML-схема, которую генерит Bonita на основе business data model. Далее в соответствии с этой схемой будут созданы таблицы в БД

И вот здесь нам снова аукнулись нюансы открывать одновременно два проекта нельзя. В итоге, xml затирала модели данных других бизнес-процессов. Решение оказалось костыльным - мы хранили в репозитории "главный" xml-файл модели данных, который вручную изменяли при появлении новых сущностей.

  • После деплоя архива с xml-схемой в BonitaPortal на ее основе создавались таблицы в заранее указанной базе данных. Выглядели они не совсем так, как нам хотелось. При этом в самой Bonita были ограничения по именованию объектов BDM. Все таблицы лежали в одной БД, хранить их иначе было невозможно. Для того, чтобы исключить пересечения именований, мы добавили префиксы, но в названиях таблиц (сущностей в модели данных) нельзя было использовать точки или нижние подчеркивания. В результате это были просто буквы, с которых начинались все названия сущностей.

    Еще были сложности с изменением модели данных. Добавление нового столбца или изменение Nullable могло обернуться вынужденным сносом всех данных из таблицы этого в проде мы допустить не могли.

Information systems

Пласт коннекторов, позволяющий Bonita взаимодействовать с внешними системами.Этот механизм облегчает жизнь разработчику можно подключиться к БД, SOAP, REST, отправлять письма. Пласт коннекторов, позволяющий Bonita взаимодействовать с внешними системами.Этот механизм облегчает жизнь разработчику можно подключиться к БД, SOAP, REST, отправлять письма.

С чем столкнулись

  • Основная проблема этого механизма - в его предопределенности. Здесь ситуация очень сильно похожа на Bonita Portal. В рамках задач, обозначенных BonitaSoft, коннекторы справлялись хорошо, но расширить их настройки или спектр применения было попросту невозможно. Да, мы могли создать самописные коннекторы, но тогда какой же это low-code? В итоге некоторые взаимодействия с внешними системами происходили через проставку из самописного сервиса.

Выводы

Bonita отлично подошла нам для создания простых бизнес-процессов: в некоторых случаях нам пригодился UI-дизайнер и даже генерация несложной модели данных. Но при создании нетривиальных, многомерных BPM-приложений такой подход начинал пробуксовывать, порождать костыли, а само приложение становилось неподъемным в плане поддержки и развития.

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

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

Поиск новой BPMS

В этот раз в выборе BPM системы участвовала большая часть проектной команды все те, кто был причастен к разработке процессов на Bonita. Пропустив через этот опыт решения из прошлого исследования, выбрали четырех финалистов Bizagi, ELMA, BpmOnline и Camunda.

Bizagi не устроила нас по цене, ELMA показалась слишком похожей на Bonita. BpmOnline мы смогли изучить подробнее, благодаря опыту наших коллег она уже используется в КРОК в качестве внутренней CRM-системы. В нашем случае она казалась не самым удачным вариантом могли быть трудности с поддержкой нетривиальных схем. У Camunda не было богатого набора инструментов iBPMS как у Bonita (но именно к ним у нас и было больше всего вопросов). Но зато у нее была Community-версия что стало дополнительным аргументом "за". Нам хотелось быстро и безболезненно протестировать решение, и быстро отмести его, если вдруг что-то опять пойдет не так. В общем-то, по этой причине мы выбрали ее качестве объекта для исследования и внедрения в тестовой среде.

Новая BPMS

Camunda - BPM Engine

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

Добавлю лишь немного лайфхаков.

  • Ссылка на git-репозиторий с огромным количеством тестовых проектов Camunda на любой вкус, которые помогут быстрому старту и поиску решений проблем, возникших при самостоятельном знакомстве.

  • Ссылка на telegram-канал русскоязычного сообщества Camunda, куда можно обратиться за помощью, когда документация и Google не смогли подсказать решение. Эти ребята ни раз меня выручали в период знакомства с движком, за что им огромное спасибо :)

Наша основная проблема

Начав исследовать Camunda я столкнулся с очевидной проблемой. Camunda написана на Java, разворачивается в среде Java и расширяется при помощи Java-подобных языков. А вся наша команда пишет на .NET (надеюсь, у вас тоже проигралась заставка из Ералаша).

Вероятных решений было два:

  • Научиться писать на Java или Kotlin, но не растерять при этом навыков .NET, так как на поддержке у команды остается еще более двадцати бизнес-процессов

  • Интегрировать Camunda в нашу экосистему таким образом, чтобы рассинхрон стека как можно слабее повлиял на получаемый результат

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

Новая концепция взаимодействия с BPM

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

Spring Boot

Java-часть нашей BPMS выглядит так:

Здесь мы используем Spring Boot, в который как зависимость импортируем Camunda.

У Camunda есть свой REST API и, конечно, BPMN-составляющая, а также своя БД, используемая для хранения процессных данных.BPM-движок через схему обращается к коду, написанному на Kotlin, который, в свою очередь, обращается к нашему .NET приложению для получения бизнес-данных.

.NET

Основная часть бизнес-процесса представляет из себя .NET приложение:

Бизнес-данные хранятся в БД, с помощью EF Core мы потребляем их в слой сервисов, где рассчитываем бизнес-логику и откуда обращаемся к Camunda REST API. Также у приложения есть формы на Angular для взаимодействия с пользователями и REST API для доступа к бизнес данным из Camunda и внешних систем.

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

Как теперь все устроено

За 8 месяцев мы исследовали и внедрили движок Camunda, а также мигрировали на него все бизнес-процессы, тем самым полностью отказавшись от Bonita BPM. Теперь у нас есть 3 отдельных Spring Boot приложения Camunda, под каждый бизнес-контур (Sales, HR и Production), самописный CROC BPM Portal, агрегирующий информацию о состоянии экземпляров процессов, и 4 бизнес-процесса, работающих в production-среде вот таких:


Выдача прав доступа

С него начался этот пост. Это инструмент, позволяющий автоматизировано получать права и доступ на файлы и папки КРОК.

Обходной лист

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

Согласование тендера

Мы упростили коммуникацию по согласованию участия в тендере и исключили из этого процесса электронную почту или мессенджеры. Теперь наши менеджеры используют автоматизированное приложение с продуманным WorkFlow.

Пульс проекта

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


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

Bonita Portal => CROC BPM Portal

Интерфейс, который отвечает за отображение скоупа задач и экземпляров процессов CROC BPM Portal теперь тоже самописный.Благодаря этому мы можем оперативно отвечать на требования пользователей и гибко его развивать.

Task-модуль CROC BPM Portal на тестеTask-модуль CROC BPM Portal на тесте

Bonita Runtime => Spring Boot и Camunda

Также, вместо standalone-подхода мы используем импорт библиотеки Camunda в Java-приложение. И таких приложений у нас несколько, в целях увеличения отказоустойчивости, каждое под свой бизнес-контур.

Bonita Storage => EF Core

Еще мы полностью контролируем бизнес-данные, для обновления БД используем миграции, а таблицы хранятся в удобном для нас виде:

Information systems => Самописные сервисы

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

Почему BPM это круто?

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

Центр любой BPMS это BPM-движок, и мы используем его по полной. Это удивительный инструмент, который действительно помогает ускорить разработку и повысить качество поставляемых решений. Фокус вовсе не в том, чтобы переложить ответственность на аналитика и автогенерацию. Основное преимущество в том, что BPMN это исполняемая документация.

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

Что дальше?

Наша BPM продолжает развиваться, и многое еще предстоит усовершенствовать. В ближайших планах написать собственную админку с возможностью просмотра истории экземпляров процесса, а также сервис, уведомляющий проектную команду об инцидентах Camunda.

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

Подробнее..

Интервью с Марселем Ибраевым о распиле монолита или Успех распила монолита грамотный менеджмент

17.06.2021 20:21:19 | Автор: admin
Я как-то видел, когда в команду разработки закинули задачу распилить монолит. И всё. Люди должны были работать в два раза больше это ужасно.
Когда поступает похожий запрос, важно не наворотить дел и понять, как избежать новых трудностей. Об этом рассказал Марсель Ибраев, технический директор Слёрма.

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



Давай представим, что перед нами стоит задача распилить монолит.

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

Так, и какими дальше будут наши действия?

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

Далее он вместе с командой проводит ретроспективу, где выясняет, как они дошли до жизни такой, какие проблемы сейчас актуальны и почему они возникли. Они могут быть следствием логичного развития проекта: кодовая база сильно выросла, появилось много зависимостей, выкатка релизов производится недостаточно часто. Или это следствие неправильных подходов и плохого кода, что бывает гораздо чаще, на мой взгляд,. Честный ответ на вопросы упростит всем жизнь в будущем.

Есть мнение, что монолит это плохо и нужно сразу делать микросервис. Это так?

Нет. Я в корне не согласен с этим. Монолит и микросервис это две разные архитектуры под две разные задачи. Например, если проект представляет собой магазин носков, который ежедневно посещают пять человек и в будущем их будет не сильно больше, то, скорее всего, лучше делать монолит. Так будет быстрее и проще. Главное не упустить момент, когда требования к проекту и подходам сильно изменились, а ваш магазин стал вторым Amazon. :)

А есть ли какое-то решение в обход распила монолита?
Допустим, мы мигрируем в облако, и нам требуется при миграции подготовить свое приложение к Кубу, а именно распилить на сервисы.


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

То есть не получится запихать legacy в контейнер и сказать, вот, пожалуйста, влезло.

Нет. Такая идея может возникнуть. Например, кто-то написал какое-нибудь древнее legacy, которое все боятся трогать. Допустим, этот человек пару лет назад уволился, а сейчас кто-нибудь предлагает взять и запихать его код в контейнер со словами: Пусть это там само работает. Звучит дико, согласен. И я бы не поверил, что такое может быть, если бы не увидел своими глазами.

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


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

Если компания всю жизнь разрабатывала на монолите, то, вполне возможно, что у разработчиков не будет опыта разработки микросервисной архитектуры. Это может быть неочевидно, так как сам по себе разработчик может быть хорошим, но это плохо для компании с точки зрения выполнения задачи. Подходы в монолитной и микросервисной архитектуре различны. Даже хороший монолитчик с большим стажем, который всю жизнь делает монолиты и даже слышал что-то про 12 факторов, не сможет хорошо выполнить работу с микросервисами именно из-за разницы в подходах. Но мое мнение, что успех работы на 80% зависит от менеджмента. Без человека, управляющего процессом, ничего путного не выйдет.

Почему?

Давай лучше приведу пример. Я как-то видел, когда в команду разработки закинули задачу распилить монолит. Просто поставили тикет, как будто разработать очередную фичу. И всё. Как команда должна решить этот вопрос, с какой стороны подступиться, непонятно. В итоге люди должны были работать в два раза больше это ужасно. Ну и положительного результата там тоже не случилось. Поэтому нужен человек, который возьмет на себя планирование. Это не должны быть детальные планы вплоть до дней и часов, это должны быть ключевые пойнты.

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

Есть какие-то выходы из этой ситуации?

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

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

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

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

Проекты бывают разные. У кого-то интернет-магазин, у кого-то платформа для торгов. Отличаются ли аспекты распила для них?

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

Копнём про гибкость глубже. Распил какой-то части отодвигается на месяц, как тогда быть?

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

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

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


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

С кем важно договориться в первую очередь?

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

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

Сколько нужно разработчиков и админов для распила монолита? Кто из них будет работать дольше или больше?

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

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

Да, у нас было такое. Пришел к нам клиент, которому нужен был Kubernetes. Поскольку мы ребята опытные, то сразу задаём встречный вопрос: А вам это зачем? Бывали случаи, когда мы отказывали клиентам, потому что не видели необходимость в Kubernetes, естественно всё объясняли. Человек услышал что-то про Kubernetes, решил, что это круто, и захотел. Расскажу про ситуацию, когда мы не отказали.

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

Часть монолита хостилась на нескольких серверах в разных частях. Примерно всей кодовой базы была неизвестна: туда никто не лез, потому что люди, которые ее писали, уволились, и изучение того, что там, оставляли на потом. Проект был в сложном состоянии. Контейнеры крутились в Docker Swarm. В одном контейнере был просто запущен кусок монолита, хотя ради справедливости стоит отметить, что было и несколько микросервисов. В итоге, конечно, мы разобрались со всем этим.

И всем стало хорошо?

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

Оказалось, история была следующей. У проекта изначально были некоторые бизнес-проблемы, в которых видели техническую причину. Один из разработчиков тогда сказал, что причина, почему так все плохо в монолите. В тот же день поставили задачу переезд на микросервисы. И действительно даже начали распил и частично заехали в Docker SWARM. Только счастье все равно не наступало, просвета не наблюдалось, проблемы не решались. Тогда решили, что проблема в Docker Swarm. И обратились к нам.

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

Что именно вы делали?

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

Не знал, что Southbridge оказывает такую услугу (прим. Кейс с того времени, когда Маресль работал инженером в Southbridge).

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

Как понять, что мы действительно распилили монолит на микросервисы, а не сделали микросервисный монолит?

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

Приведи пример.

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

Подведём итог. Рецепт распила монолита состоит в следующем: компетентные кадры, грамотное планирование, четкое понимание целей и гибкость в работе. Ничего не упустил?

Забыл упомянуть менеджмент. Кстати, если этот рецепт переложить на выполнение других задач, то их реализация тоже получится хорошей. Тут я Америку никому не открыл. Я понимаю, что инженерам и программистам интересна техническая сторона вопроса, но предлагаю взглянуть на распил с точки зрения управления процессом. Если про это забыть, то ничего не получится.

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

Перевод Постмортем инцидентов для начинающих

15.06.2021 14:10:21 | Автор: admin

image


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


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


Зачем нужен постмортем?


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


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


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


В каком-то смысле, неопределенность, беспорядок, ошибки и время идут на пользу антихрупким системам
Antifragile, Nassim Nicholas Taleb (2012)

При сбое мы узнаем о системе что-то новое, особенно о скрытых связях между компонентами.
Допустим, у нас есть простая система с тремя компонентами (A, B и C) со следующими свойствами:


  • A связан с B;
  • A связан с C;
  • между B и C никаких связей не наблюдается;
  • любой процесс, порожденный A, открывает соединение с B и C.

Вот как выглядит эта схема:


image


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


Мы открыли скрытую связь между B и C. Вот как выглядит новая схема:


image


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


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


Когда проводить постмортем


Когда в системе происходит достаточно серьезный инцидент.


В теории любой инцидент. На практике вам вряд ли хватит ресурсов, поэтому начните с инцидентов, которые напрямую влияют на клиентов и стейкхолдеров.


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


Что нужно делать


Опишите, что произошло. Четко сформулируйте последствия инцидента:


  • Кто?
  • Что?
  • Как долго?

Составьте хронику событий и коммуникаций между участниками по поводу инцидента.
Попробуйте найти первопричину, если с ней можно что-то сделать:


  • пять почему;
  • практичность важнее истины;
  • процесс поиска первопричины нужно документировать.

Между истиной и практической пользой есть важное различие.
Data & Reality, William Kent (1978)

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


Решайте проблемы коллективно, чтобы быстро учиться новому.
The DevOps Handbook, Gene Kim, Jez Humble, Patrick Debois, John Willis (2006)

Предложите улучшение для системы


Если это случится снова:


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

Обращайте внимание на поток информации, фидбэк и задержки в коммуникациях:


  • Мы вовремя узнали об инциденте?
  • Все нужные люди получили уведомление?
  • Нужные подсистемы (например, автомасштабирование) получили нужный фидбэк?

Измените длительность задержки, и поведение всей системы может серьезно измениться.
Thinking in Systems, Donella H. Meadows (2008)

Чего не нужно делать


Никого не обвиняйте


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


Не копайте слишком глубоко


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


Что делать с документом?


Главная цель извлечь урок для себя и своей организации. Документы по постмортему должны быть:


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

Для вдохновения


Вот список общедоступных (и подробных) постмортемов:


Подробнее..

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

16.06.2021 08:14:44 | Автор: admin

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

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

Проекты автоматизации

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

Как ни стараются agile-цыгане, но проекты автоматизации до сих пор делаются по старинке каскад, водопад, PMBOK. Гибкие методы применяются лишь там, где не страшно ошибиться. А проект стоимостью в несколько миллионов хочется контролировать.

Пузырь растёт с самого начала проекта обследования, моделирования, написания ТЗ. Заказчик делает вид, что знает, чего ему надо. Интегратор делает вид, что не замечает, что заказчик делает вид. Все умные, толковые, деловитые и вежливые. А пузырь растёт.

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

Тут подключаются главные надуватели программисты. Берут ТЗ и фигачат. Наше дело маленькое сделать то, что написано. Правильно написано, или чушь какая-то мы причём? Пузырь, вместе с затратами, растёт очень быстро.

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

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

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

Но пузырь лопается редко. Слишком он прекрасен.

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

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

А пузырь стоит.

Корпоративные сайты

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

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

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

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

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

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

Внутренняя автоматизация

Это сфера, созданная именно для надувания пузырей. Особенно, если внутри компании работают программисты с выдумкой и амбициями.

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

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

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

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

А потом произойдёт сюжет, из которого жалобные статьи появляются. Не прижилось, Компания оказалась не готова, Я опередил завод в развитии, Меня никто не понимает и т.д. Но пузырь остаётся.

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

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

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

Да, вы правильно поняли. Я тоже пузыри надуваю иногда. Сказать директору завода в деревне создавай и поддерживай среду для самореализации людей Прям Тони Роббинс в фуфайке.

Подробнее..

Как каменщик дядя Толя учил программистов

08.06.2021 08:13:41 | Автор: admin

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

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

Поглядим, чему же программисты могут научиться у каменщика дяди Толи.

Исходная на стройке

На стройке работали три каменщика Костя, Рустам и дядя Толя. Косте было лет 25, Рустаму под 40, дяде Толе 50-60 (видимо, поэтому к его имени добавили уважительное дядя). Я, и еще человек 15 студентов и школьников, были разнорабочими принеси, подай, иди дальше, не мешай.

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

А теперь немного прервёмся и посмотрим, как дела у программистов.

Исходная на проекте

Клиент, силами каких-то чертей, внедрил себе ERP-систему. Черти, получив деньги и запустив систему, сбежали. Люди начали работать и, разумеется, огребли трудностей.

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

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

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

А теперь вернёмся на стройку и поглядим, как дела у дяди Толи и его друзей.

Процесс на стройке

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

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

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

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

Так и работали. Дядя Толя шёл примерно с той же скоростью, что Костя и Рустам вместе. Начальство не проявляло к работе дяди Толи никакого интереса. За Костей и Рустамом присматривали. Но, увы, не досмотрели.

А пока вернёмся к программистам и разработчикам.

Процесс на проекте

Программисты работали от проблемы. Сказали пользователям пишите, звоните, если чё не получается, будем вместе разбираться и решать. Когда их спросили, почему они не смотрят на систему в целом, те ответили чего на неё смотреть, она точно рабочая, мы её много раз внедряли. Это ж 1С:ERP. Там не всё гладко, но почти всё точно работает.

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

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

Разработчики с аналитиками взяли месяц на анализ доработок, выполненных предыдущими чертями. Чего они там анализировали им одним известно. Но счет выставили на 3 человекомесяца нетрудно догадаться, что анализировали в шесть глаз. В итоге пришли к неутешительному выводу все доработки надо переделывать, с нуля. Анализ, проектирование, разработка, тестирование, опытная эксплуатация.

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

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

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

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

Но вернёмся на стройку.

Результат на стройке

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

Оставить-то они оставили. У дяди Толи всё, как задумано в проектной документации. У Кости и Рустама дырки под окна получились на разной высоте, с разницей примерно в полметра. И одно окно было смещено на метр в сторону.

Дядя Толя смеялся. Мы, разнорабочие, смеялись. Костя и Рустам махали руками и что-то громко кричали. Но прораб кричал громче, и некоторые слова даже можно процитировать. Например, зато, ***, кирпичи у вас только целые, и раствор, ***, свежий!.

А что у программистов с разработчиками?

Результат на проекте

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

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

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

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

Через две недели разработчики с аналитиками сбежали, как предыдущие черти. Кто в срочный отпуск, кто сказался больным или очень-очень занятым. Заказчик был в ступоре одно не работает, второе работает, но использовать нельзя (РПЗ запрещает).

Дело быстро дошло выше РПЗ до директора. Тот, не долго думая, повелел остановить все работы. И начались длинные разбирательства за что оплатили 9 человекомесяцев, почему разработчики с аналитиками сбежали, что они там в ТЗ написали, кто подписывал и т.д.

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

Чем закончилось на стройке

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

Исправлял, естественно, дядя Толя. Костю и Рустама выгнали в тот же день.

А чем закончилось на проекте?

Чем закончилось на проекте

Директор собрал Большое Совещание. Со стороны подрядчика приехали программисты (разработчики с аналитиками, как мы помним, сбежали). Директор кричал и ругался, требовал объяснения и решения.

Когда проорался, программисты спросили так тебе объяснение или решение надо? Тот немного опешил, но сказал и то, и другое. Программисты спросили а в каком порядке? Сначала решение, потом объяснение.

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

Директор опешил чё, говорит, так можно было? И пристально посмотрел на РПЗ. Тот начал что-то тараторить, но директор его грубо прервал.

Через пару дней всё заколосилось. Правда, разборки про 9 человекомесяцев идут до сих пор.

Подробнее..

Перевод Навыки Senior Engineer, помимо программирования (неполный список)

08.06.2021 22:04:34 | Автор: admin
  1. Как провести собрание. И нет, не болтать больше всех на собрании, а именно провести его.
  2. Как написать проектную документацию, получить отзывы и довести ее до решения в разумные сроки
  3. Как наставлять младшего коллегу по команде, инженера в середине карьеры, нового менеджера, которому нужен технический совет
  4. Как порадовать старшего менеджера, который хочет поговорить о технических вещах, которых он на самом деле не понимает, не закатывая глаза и не заставляя его чувствовать себя глупо
  5. Как объяснить техническую концепцию за закрытыми дверями высокопоставленному лицу, слишком смущенному, чтобы открыто признать, что он ее не понимает
  6. Как убедить другую команду использовать ваше решение вместо написания собственного
  7. Как заставить другого инженера сделать что-то для вас, попросив о помощи таким образом, чтобы он почувствовал, что его ценят
  8. Как вести проект, даже если вы не менеджерите никем из людей, работающих над ним
  9. Как заставить других инженеров прислушиваться к вашим идеям, не заставляя их чувствовать угрозу
  10. Как прислушиваться к идеям других инженеров, не чувствуя угрозы
  11. Как отказаться от своего детища, от того проекта, который вы превратили во что-то великое, чтобы вы могли заняться чем-то другим
  12. Как научить другого инженера заботиться о том, что вас действительно волнует (операции, правильность, тестирование, качество кода, производительность, простота и т.д.)
  13. Как сообщить о статусе проекта заинтересованным сторонам
  14. Как убедить руководство в том, что нужно вкладывать деньги в нетривиальный технический проект
  15. Как создавать программное обеспечение, принося при этом дополнительную ценность в процессе
  16. Как составить проектное предложение, социализировать его и получить поддержку для его реализации
  17. Как повторять свои мысли достаточно, чтобы люди начали слушать
  18. Как выбрать битву/Как расставлять приоритеты
  19. Как помочь кому-то продвинуться по службе
  20. Как получить информацию о том, что на самом деле происходит (как сплетничать, как общаться)
  21. Как найти интересную работу самостоятельно, а не ждать, пока кто-то ее вам принесет
  22. Как сказать кому-то, что он неправ, не заставив его стыдиться
  23. Как изящно воспринимать отрицательные отзывы
Подробнее..

Аптайм 500 дней перезагрузка падение собираем бэкап по частям

09.06.2021 10:16:43 | Автор: admin

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

Все началось с того, что сервер статистики контактного центра заказчика (на тот момент ещё потенциального) сбросил все пользовательские сессии и перестал отвечать на запросы. Соответственно к нему подкатили тележку с монитором и перезагрузили. Это обычно надо делать раз в 90 дней по инструкции от вендора, но тут это не делалось больше 500 дней. В общем, сервер отметил юбилей аптайма.

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

Но после накатывания бэкапа система просто легла.

В этот момент нас позвали отмечать день рождения сервера. Без него не работала балансировка нагрузки на операторов внутри КЦ.

Что это была за система?

Система Avaya Call Management System (CMS). Это кусок колл-центра, который собирает статистику по звонкам, операторам, нагрузке исторические и реал-тайм данные. На этом же сервере каждое утро собираются отчёты о работе. В реальном времени сервер говорит, какие операторы сейчас в каких статусах находятся, какие звонки обрабатываются, сколько звонков висит в очереди. В целом система нужна, чтобы следить за группами операторов, за колл-центром, чтобы правильно распределять нагрузку, потому что можно переносить операторов из ненагруженных линий в нагруженные и так далее. Обычно там просто сидят супервизоры и следят за всем происходящим. Прямых аналогов нет, обычно используются самописные решения или же всё вообще делается вручную. Аваевскую систему выбирают за надёжность и многофункциональность.

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

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

Первый день пятница

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

Приезжаем на место (напомню, что сервер лёг и удалённого доступа нет), подключаемся с монитором и клавиатурой, ещё раз смотрим, как система не стартует.

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

У нас условно есть три части системы: железный сервер, который входит в ПАК, поставляемый сразу с софтом в виде чёрного ящика от вендора, CMS и база данных. Бэкапы CMS (конфигураций) и базы делаются в разные места.

ОК, система запустилась, но только база пустая данных никаких нет.

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

Итак, у нас на руках железный оракловский сервер, с которым что-то не то (но это не посыпавшийся раньше времени диск), на нём Solaris c базjq Informix от IBM + пакет CMS от вендора. Решение продаётся как программно-аппаратный комплекс, то есть всё там как поставил вендор, так никто и не трогал.

Бэкапы БД делались. Итерации были по 180 дней, бэкапирование настроено в планировщике системы. Логи бэкапов никто особо не читал, консистентность не проверяли, назад до этого юбилея сервака накатывать не пытались.

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

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

Дальнейшее исследование

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

К утру мы всё ещё думали, что справимся быстро (в КЦ уже начались проблемы). Решили не трогать бренную земную оболочку сервера, а сразу снять с него образ и развернуть на виртуалке. Это стандартная процедура и для форензики, и для восстановления чего-то, где может посыпаться дальше диск, и вообще очень удобно в конечном итоге в плане не навреди ещё.

Сначала мы развернули виртуалку на стенде прямо у заказчика и начали препарировать там. Фактически Авая сделала больше, чем должна была, подарив лицензию на виртуальную систему. Ну, точнее, заказчику. Выяснили, что бэкап встаёт с ошибкой устройства, но в остальном норм, правда, система пустая. Довольно быстро стало понятно, что бэкап битый полностью.

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

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

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

В лаборатории

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

Сразу стало понятно, что свежий бэкап неконсистентен и вообще похож на записанный прямо из /dev/random. То есть последний месяц (который не бэкапился) пропал просто в силу того, что его никто никуда не резервировал. Следующие полгода пропали из-за битого бэкапа. И только в следующей итерации нашлись таблицы, где были реальные данные. То есть минус семь месяцев от момента аварии, и, как позже выяснилось, целых данных там было не очень много, не больше года, а часто по некоторым показателям и меньше.

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

То есть в итоге оставили систему в рабочем режиме со старыми данными, руками настраиваем всё то, что не удалось восстановить из бэкапа системы (пользовательские учётки, коннекторы к другим системам, скрипты).

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

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

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

Выводы

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

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

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

Подробнее..

Перевод Всегда старайтесь быть незаменимым

10.06.2021 18:12:02 | Автор: admin
Есть хорошая жизненная философия, которой можно придерживаться на рабочем месте, это постоянно быть готовым увольняться (always be quitting). Это не значит думать о том, чтобы уйти с работы. Но вести себя так, как будто вы можете уйти в кратчайшие сроки. Парадоксально, но это сделает вас лучшим инженером и откроет возможности для роста.

Так что же значит постоянно быть готовым уйти? Это означает сделать себя заменимым; унизить себя; автоматизировать свою работу. Возможно, вы слышали эти более популярные ярлыки (и вам нужно будет с этим поразбираться и выяснить что это), и они дают подсказку что делать.

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

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


  1. Задокументируйте свои знания. Каждый раз, когда кто-то задает вам вопрос, он подчеркивает пробел в документации. Воспользуйтесь возможностью записать ответ (в документе, баг-репорте, комментарии к коду где угодно), чтобы следующий человек не нуждался в ВАС.
  2. Задокументируйте свои долгосрочные планы. Люди должны знать, что происходит в ваших проектах и/или команде, просматривая эти планы, а не полагаясь на то, что вы расскажете им в режиме реального времени. Планируйте на несколько месяцев вперед, чтобы, если вы уйдете, ваши сверстники не потерялись с первого дня.
  3. Документируйте свои встречи. Ведите (публичные, внутри команды) заметки обо всех встречах, которые вы посещаете, перечисляя, кто там был, что обсуждалось, и любые выводы. Обратитесь к этим примечаниям из проектной документации. Тому, кто придет на ваше место это понадобится, чтобы наверстать упущенное.
  4. Приводите других на собрания. Если это не встреча 1 на 1 и вы единственный человек из вашей команды, присутствующий на собрании, привлеките кого-нибудь другого. Различные точки зрения полезны, но что более важно, вы избегаете становиться единственной точкой соприкосновения.
  5. Прокачивайте людей рядом с вами. Цель состоит в том, чтобы они были независимыми (что обычно считается старшинством(seniority) на типичной инженерной лестнице). Ознакомьте их с планами и технологиями и убедитесь, что они знают, как использовать документацию.
  6. Подберите человека себе на замену и обучите его. В том же духе, что и при обучение других, чтобы переключиться ролями, вам нужно будет найти замену себе. Определите, кто может заменить вас, и активно и постоянно тренируйте их.
  7. Дайте власть людям. Верьте, что они поступят правильно. Если вы занимаете руководящую должность, не делайте так, чтобы люди приходили к вам за разрешением. Пусть они сами делают свой выбор. Направляйте их таким образом, чтобы их выбор основывался на правильных данных.
  8. Не делайте себя ключевым звеном. Создайте списки рассылки или другие формы общения, которые могут вместить других людей, а затем расширьте эти группы. (Исключение составляют случаи, когда руководству нужны имена для подотчетности.)
  9. Делегируйте. Как только вы дадите власть другим, включите их в группы и собрания и задокументируете свои знания, они будут готовы принять от вас работу. Делегируйте работу, которая может заставить их расти, и сосредоточьтесь на том, что можете делать только вы.
  10. Учитесь непрерывно. Воспользуйтесь шансом расширить свои знания в любой области, которая вас интересует, и продолжайте получать удовольствие. Бонус для вас, если эта область совпадает с вашим будущим проектом.


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

Наконец, обратите внимание, что, выполняя все вышеперечисленное, вы активно улучшаете всю свою команду, а не только себя, даже если вы являетесь individual contributor. На самом деле вы практикуете подмножество навыков, иногда связанных с начальник/подчиненный+ инженеры.
Подробнее..

Recovery mode Рецепты счастья как поддерживать корпоративный дух в непростое время

10.06.2021 20:10:36 | Автор: admin

О том, что такое счастье, спорили раньше, спорят и сейчас. Но если взять частный случай, получение удовольствия от работы в компании, то ответ на этот вопрос не так и сложен. Чувствовать себя счастливым можно, если в компании все хорошо, работа интересная, коллектив дружелюбный и сплоченный. Конечно, в спокойное время поддерживать эту сплоченность не так и сложно. А вот в наше непростое время это непростой челлендж. О том, как поддерживать корпоративный дух, рассказывает Екатерина Проньшина, амбассадор Всероссийского конкурса Цифровой прорыв флагманского проекта президентской платформы Россия страна возможностей.

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

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

Что такое корпоративный дух?

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

Елена Арефьева, заместитель директора ИПМКН ТулГУ: Корпоративный дух это ощущение единения сотрудников с компанией, чувство сопричастности, ответственности за результаты ее деятельности.

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

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

  • Повышается мотивация, увеличивается продуктивность. Все заинтересованы в развитии фирмы.

  • Поддерживается репутация организации, которая будет устойчивее менее объединенных конкурентов даже в кризисных обстоятельствах. Исследования показали, что 84 % сплоченных команд удержали на плаву бизнес во время потрясений пандемии, а в разобщенных коллективах таких осталась лишь треть. Респонденты фирмы со штатом до 100 человек.

Согласно совместному исследованию ученых из университетов Италии, Финляндии и Германии, продуктивность специалиста, который доволен своим окружением, повышается в среднем на 58%.

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

Игорь Кожелин, директор по работе с партнерами и инвесторами частной космической компании Success Rockets: Мы бежали с коллегами Гонку героев. До этого мы были хорошие друзья и работали над одними проектами, но после долгого и сложного забега мы стали по-настоящему единой командой, которую объединяли общие ценности и прошедшие трудности.

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

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

Что делать, чтобы все было хорошо?

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

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

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

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

Что касается сотрудников, то и для них есть дельные советы:

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

  • Активности в созвонах/переписке с коллегами. Не стоит игнорировать сложности в работе. Если показалось, что смысла нет, нужно срочно стучаться в чат и сверять компас.

  • Важна техническая поддержка с облачными хранилищами. Одновременное информирование и просмотр документов в режиме реального времени. Фиксация важных новостей или предложений в общем чате сопричастность и возможность быть в курсе событий по всем направлениям.

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

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

Кое-что еще

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

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

А йога-онлайн? Это ощущение полного присутствия и домашний комфорт одновременно. Или можно собраться на вечеринку. Интересно сделать ее тематической, учредить приз, а победителя выбрать голосованием. Например, конкурс фото Мой питомец или Я в выходной. Так каждый работник будет мысленно с командой, получит обратную связь, не потеряет сигнальные моменты командного духа и не закроется в себе, отрываясь от коллектива.

Игорь Буслов, заместитель начальника отдела ТФОМС Красноярского края: Мы совместно ходим в спортзал частью коллектива. Практикуем выходы на шашлыки, иногда играем отделом в пейнтбол. Участвуем частью отдела в хакатонах. Ходим на отраслевые спортивные мероприятия. У нас в отделе стоит шахматная доска, где сотрудники могут сыграть между собой в шахматы. Также есть стол для настольного тенниса. Поздравляем отделом друг друга с днями рождения и другими важными для человека событиями, устраиваем совместные pizza day, иногда ходим отделом в боулинг.

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

Подробнее..

Перевод Откровения кофеин-зависимого инженера как писать документацию

11.06.2021 22:17:41 | Автор: admin
image
Четыре вида документации распределнные по двум осям: практика-теория и обучение-работа.

Недавно вышли два нашумевших поста:



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

Я выпил достаточно кофе, и я попытаюсь объяснить то, что знаю.

TL; DR: пишите документацию для решения конкретной проблемы для определенной группы людей, а не только для того, чтобы документация была.

Пишите хорошо


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

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

Самый полезный совет для написания документации пишите в разговорном стиле. Воспринимать информацию из неформального письма намного проще.

Виды документации


Ладно, теперь вернемся к документации.

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

  1. Информация для обучения VS информация для работы.
  2. Практические шаги VS теоретическая информация.


(Это не моя мысль, я увидел это в https://documentation.divio.com/)



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

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

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

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

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

Если все, что у вас есть, это справочная документация (reference documentation), информация будет бесполезным набором случайных фактов для читателей, не знакомых с основами. Справочная документация это все равно, что иметь подробное описание перекрестков, когда новые читатели ищут карты автомагистралей.

Я думаю, что на самом деле существует пятый вид документации: breadcrumbs. Это небольшие комментарии в коде или заметки в документах (или даже сообщения об ошибках в пользовательских линтерах), которые указывают читателям на то, что им нужно знать. Вы можете написать небольшой комментарий со ссылкой на тикет Jira, объясняющий, почему этот код необходим, или указать людям, какую команду нужно запустить для устранения ошибки. Breadcrumbs действительно легко добавить в документацию и сэкономить массу времени.

Почему


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

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

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

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

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

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

Нетехнический темы


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

Другие полезные нетехнические детали, включая:

  • Процессы, которым необходимо следовать (например, прежде чем обновлять что-то, отправьте электронное письмо в этот список рассылки, чтобы служба поддержки могла подготовиться).
  • Командная динамика. Та команда X действительно беспокоится о том, чтобы произошло Y, так что узнайте у них о Z
  • Информация о пользователях. У нас много пользователей, которые создали свои собственные штуки, и им не нужно менять свои штуки, поэтому мы делаем это обновление только для пользователей без специальных штук.
  • Интересные факты, например мы называем эту систему Нарнией, потому что ...


Туториалы


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

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

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

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

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

Гайды


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

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

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

Объяснение и справка


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

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

Практика документации


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

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

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

Пожалуйста, во имя всего святого, не пишите такую документацию:

/** * @param customer The customer * @param order The order * @return The price */public Price getPrice(Customer customer, Order order) {}


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

Документацию, как и код, нужно поддерживать. За ее хранение приходится платить. Вы должны выделить время, чтобы поддерживать ее. К счастью, это обычно намного дешевле, чем поддержка кода. Несколько часов в месяц это все, что вам нужно, чтобы прочитать всю вики и исправить то, что сейчас не так.

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

Один из способов сэкономить время превратить другую работу в документацию. Если вам нужно объяснить коллеге, как интегрироваться с вашей системой, скопируйте то, что вы пишете в Slack, в документ. Если вы написали проектную документацию, скопируйте несколько ее разделов в документацию и потратьте 10 минут на ее подготовку. Когда вам нужно что-то объяснить рецензенту в код ревью, объясните это с помощью комментария в коде, а не коммита в Github. Объясняет ли ваш тикет Jira, почему необходимо выполнить задачу? Круто, скопируйте это, и у вас есть документация. (Если это не так, заставьте спрашивающего написать это!)

Сообщите людям, куда обращаться, чтобы задать вопросы. Чтобы написать если у вас есть какие-либо вопросы, вы можете связаться с нами по адресу #team-channel в Slack, примерно за 15 секунд. Это поможет сэкономить часы, если вы запутаетесь. Довольно хорошая окупаемость на мой взгляд

Итак, кофе кончается, поэтому остановлюсь на этом.
Подробнее..

PM-школа от CS центра итоги первого года в онлайне глазами выпускников

14.06.2021 20:18:14 | Автор: admin

Два года назад Computer Science Center провел экспериментальный запуск курса по управлению продуктами, о результатах которого мы рассказывали ранее. Эксперимент удался, и в 2020-21 учебном году прошла уже полноценная годовая программа повышения квалификации с поправкой на новые идеи и вынужденный онлайн-формат. Сегодня выпускники нашей программы поделились своими историями: почему они решили развиваться в продакт-менеджменте, как совмещали учебу и работу и с какими результатами вышли с курса.

До 20 июня открыт набор на третий поток обучения по направлению Product Management с преподавателями и наставниками из ведущих мировых IT-компаний. Подробнее о школе смотрите в записи Дня открытых дверей онлайн и на нашем сайте.

До и После: зачем вы изначально подавали заявку на конкурс и что получилось в результате?

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

Я дважды пытался запустить стартап и дважды спотыкался о собственную некомпетентность. Профессия Product Manager предполагает, что ты знаешь как из пункта А привести продукт в пункт Б. Когда я увидел, что на продакта будут учить в Computer Science Center, я сразу подал заявку: все мои знакомые, которые проходили курсы в CS центре, говорили о лучшем опыте обучения в своей жизни.

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

Будь у меня возможность, я бы прошел эту школу еще раз. Зная организаторов, могу гарантировать, что курс станет еще лучше.

Я хотел изменить карьерную траекторию это очень значимое для меня решение. Раньше я работал в сфере ядерной энергетики: занимался как инженерными задачами, так и развитием бизнеса. Понимал, что хочу качественных изменений: новых знаний и практики для старта в IT. Обучение в школе по управлению продуктами от CS центра было для меня этой возможностью. С одной стороны, что-то близкое и знакомое (менеджмент, инженерия и бизнес-анализ), с другой новая сфера инженерии (цифровые продукты).

Результат сейчас обучение завершено. Закрыв одну дверь, я открыл две новые: Business Аnalysis и Product Management. Сейчас я работаю в IT-компании и двигаюсь по треку управляющего цифровыми проектами, потому что мне нужен базовый опыт. После перейду в управление продуктами. Рассчитываю совершить карьерный маневр в течение этого года.

Сначала был конкурс: первое впечатление от знакомства и советы бывалых будущим абитуриентам.

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

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

Самое сложное в отборе ответить на три довольно глобальных вопроса в двухминутном видео. Съемка этого видео заняла у меня пару часов: хотелось сделать что-то задорное, но информативное о себе и моем опыте. В итоге все получилось: благодаря видео я попала на собеседование, а после него и на курс. Если у вас совсем нет знаний о работе IT-продуктов, для подготовки к интервью рекомендую послушать лекции из Школы менеджеров Яндекса.

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

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

В процессе: как справлялись с учебной нагрузкой и какие изменения происходили с вами в течение учебного года?

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

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

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

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

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

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

Второй семестр был менее динамичным, однако тут настало время прохождения индивидуальной практики в компаниях. Мне повезло попасть к хорошему ментору Матвею Брыксину, Product Lead в Arrival. Нагрузка была умеренной, в этот раз я успевал делать задачки хорошо, а не в режиме стартапера, которому нужно было вчера. Работая для корпорации, я получил совершенно другой опыт. Мне было интересно заниматься реальной проблемой бизнеса.

Атмосфера на курсе: ощущения от взаимодействия с организаторами, преподавателями и друг другом.

Когда я рефлексирую на тему школы, то слово, которое приходит на ум это живой. Люди на курсе живые и очень разные, как преподаватели/кураторы, так и студенты. Благодаря этому в рамках курса создается очень благоприятная и дружелюбная атмосфера получения новых знаний. Все готовы делиться друг с другом опытом, информацией, фидбэком. Даже сама программа школы специально подстраивается под поток.

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

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

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

Что дальше: что вы будете делать с полученными знаниями, опытом и связями после выпуска?

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

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

Знания, которые я получил в процессе обучения, помимо собственно понимания, какие процессы и фреймворки существуют в области создания продуктов, значительно расширили мой профессиональный и общий кругозор. Хоть я и не планирую в ближайшее время переходить на позицию продакт-менеджера, многое я смогу применить в роли Lead-engineer. Большая часть вопросов относительно ожиданий бизнеса и прогнозирования хода проекта стали разрешимы с меньшим объемом коммуникаций. Да и возможность видеть что-либо на большем уровне абстракции само по себе прекрасно и интересно.

Курс был однозначно полезен, и я рад, что смог дойти до конца и получить такие ценные знания!

Новые идеи для работы и жизни

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

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

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

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


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

Заявки принимаются до 20 июня на https://pmcsc.ru/ ;)

Подробнее..

Recovery mode Как заказать услуги по SEO и не потерять

16.06.2021 14:10:53 | Автор: admin
Иван Бабайлов

Сооснователь в ADWAI Digital

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


Вы можете посмотреть видеоверсию статьи или прочитать ее в текстовом формате.

Первое правило подбора подрядчика по SEO: Общая адекватность подрядчика

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

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

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

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

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

Подобный фильтр я рекомендую установить и вам при подборе исполнителя под SEO-задачи. Это очень ответственная задача и поручать ее абы кому я бы не стал.

Кстати, мы с командой записали очень мощный вебинар о том, как масштабировать бизнес с помощью инструментов маркетинга и аналитики. В этом вебинаре мы собрали весь свой опыт и наработки по таким проектам, как: Бизнес Молодость, Яндекс Такси и т.д. Будет полезно.

Второе правило подбора подрядчика по SEO: Использует ли этот подрядчик инструмент SEO-продвижения для себя?

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

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

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

Что я бы сделал: проанализировал бы всех подрядчиков, с кем мне потенциально было бы интересно начать сотрудничество и отсек бы тех, кто не подходит под мои начальные критерии: например, страницы их сайта не оптимизированы по SEO, у них не прописаны теги H1, H2, H3, не установлены alt-теги на изображениях и не добавлены ключевые слова к каждой странице. Если бы я наткнулся на подрядчика с такими ошибками на его собственном сайте, то я сразу бы перестал рассматривать этого кандидата в качестве потенциального подрядчика.

В общем здесь все просто: если потенциальный подрядчик не справляется со своим SEO, то с большой долей вероятности не справится и с продвижением вашей компании.

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

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

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

Еще, очень часто, маркетологи, при описании результатов работы, используют такие хитрости, как рост в процентном соотношении. Давайте разберемся что это означает. Мы, при анализе конкурентов, очень часто видели такую ситуацию, когда другие агентства использовали в своем портфолио формулировки вроде: Рост SEO-трафика на 300% и тому подобные. На первый взгляд кажется, что ого, рост в 3 раза. Отличный результат, но при этом всегда оставался какой-то осадок, некоторые сомнения и мы потом поняли в чем тут дело. Рост в 3 раза от начальных показателей это хорошо, но маркетологи очень редко называют в таких кейсах точку А, то есть точку откуда они стартовали и всегда давят на 300-процентный или какой-то аналогичный рост в процентах.

В чем же проблема? Рост в 3 раза от 100 посетителей сайта с SEO это не тоже самое, что рост в 3 раза от 100 тысяч посетителей сайта с SEO. Это совершенно разный объем трудозатрат, это совершенно другой объем инвестиций в маркетинг и другой масштаб результата. Понимаете? А маркетологи выставляют свои результаты так, как будто это одно и тоже. Поэтому будьте крайне внимательны и обращайте внимание на все нюансы. Так как, как мы все знаем: дьявол кроется в деталях.


На этом все.

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

Подробнее..

Перевод Как Airbnb скрывает кошмары при помощи тайной команды чистильщиков

16.06.2021 18:22:08 | Автор: admin

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

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

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


Инцидент на 37-й улице

Квартира на первом этаже на 37-й Западной улице, в нескольких кварталах к югу от Таймс-сквер, была популярна среди туристов настолько, что ключи для арендаторов Airbnb оставляли на стойке соседнего винного магазина. Именно там 29-летняя австралийка и её друзья забрали их, не предъявляя никаких документов, когда приехали на Манхэттен провожать 2015 год. Квартира была размещена на Airbnb, несмотря на то, что краткосрочная аренда в Нью-Йорке в большинстве случаев вне закона. Город, подталкиваемый влиятельными профсоюзами отельеров, вёл войну с компанией, которая размещала тысячи объявлений о сдаче квартир в пяти районах, несмотря на одни из самых строгих законодательных предписаний об аренде в стране.

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

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

О происшествии немедленно известили кризис-менеджера Airbnb Ника Шапиро. Шла вторая неделя его работы в этой должности, куда он перешёл с поста заместителя начальника штаба ЦРУ и советника в Совете национальной безопасности в Белом доме Обамы. Я помню, как думал, что снова оказался в гуще событий. вспоминает он. Происшествие вернуло меня к ощущениям, которые я испытывал, сталкиваясь с действительно ужасными вещами в Лэнгли и в ситуационной комнате Белого дома.

Даже видавший некоторое де**мо Ник Шапиро был в шоке.Даже видавший некоторое де**мо Ник Шапиро был в шоке.

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

Дубликаты ключей представляли собой особую проблему для компании и загадку для следователей. Откуда они у мужчины? У Airbnb нет правил, как хозяева (здесь и далее владельцы сдаваемых помещений) должны обмениваться ключами с гостями, и от ответа на этот вопрос зависела репутация компании в плане безопасности и, возможно, её юридическая ответственность. Шапиро (который на сегодня уже покинул компанию) помогал координировать расследование этого вопроса.

Тот самый дом на 37-й Западной улице.Тот самый дом на 37-й Западной улице.

Через неделю один из сотрудников был отправлен в суд, чтобы проверить, не упоминался ли Airbnb в ходе судебного разбирательства. Местные СМИ также не сообщали о преступлении, несмотря на ужасающие подробности, и компания хотела, чтобы СМИ и дальше молчали. Эта история осталась не освещённой до сих пор, в немалой степени потому, что через два года после нападения Airbnb выписал женщине чек на 7 млн. долларов это одна из самых больших выплат, которые когда-либо делала компания. В обмен на деньги она подписала соглашение не говорить об урегулировании или подразумевать уголовную ответственность или обязательства со стороны Airbnb или хозяина дома.

Подробности преступления, реакция компании и факт урегулирования были реконструированы из полицейских и судебных протоколов и конфиденциальных документов, а также из интервью с людьми, которые знакомы с этим делом. Женщина, имя которой было изменено в судебных документах и которая через своего адвоката попросила не называть её имени, отказалась от комментариев. Так же поступил и её адвокат. Бен Брейт, представитель Airbnb, говорил, что у компании нет полномочий скрывать информацию от СМИ и что, несмотря на формулировку мирового соглашения, женщина может обсуждать, считает ли она кого-либо ответственным. Он добавил, что целью Airbnb после инцидента была поддержка выжившей после ужасного нападения и что местные политические вопросы не имеют никакого отношения к её реакции.

Этот случай в Нью-Йорке произошёл во время ожесточённой борьбы с регуляторами, и реакция Airbnb на него показывает, насколько важна была команда безопасности для роста компании. Бизнес-модель Airbnb основана на идее, что незнакомые люди могут доверять друг другу. Если идея будет развенчана, это может означать уменьшение числа пользователей и увеличение количества судебных исков, не говоря уже об ужесточении регулирования.

При всей своей важности команда безопасности остаётся секретной. Инсайдеры называют её чёрным ящиком. Но восемь бывших членов команды и 45 других сотрудников Airbnb (нынешних и бывших), знакомых с ролью команды, дали редкую возможность взглянуть на её операции и внутренние проблемы. Большинство из этих людей говорили на условиях анонимности, опасаясь нарушить соглашения о конфиденциальности. По словам бывших членов команды, это очень нервная работа балансировать между часто противоречивыми интересами гостей, хозяев и компании. У меня были ситуации, когда я говорил с клиентом после инцидента, вешал трубку и плакал, вспоминает один из бывших агентов. Это всё, что я мог сделать.

Рождение секретной службы Airbnb

Airbnb была основана в 2008 году студентами-дизайнерами Брайаном Чески и Джо Геббиа вместе с инженером-программистом Натаном Блечарчиком. Из забавной альтернативы каучсёрфингу Airbnb выросла до одной из крупнейших гостиничных компаний в мире с 5,6 миллионами объявлений, а это больше, чем количество номеров в семи крупнейших гостиничных сетях, вместе взятых.

Светлые и прекрасные лица основателей Airbnb, слева направо: Джо Геббиа, Брайан Чески, Натан Блечарчик.Светлые и прекрасные лица основателей Airbnb, слева направо: Джо Геббиа, Брайан Чески, Натан Блечарчик.

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

Одним из первых привлечённых ими венчурных капиталистов Кремниевой долины был Крис Сакка, один из первых инвесторов Instagram, Twitter и Uber. Позже Сакка вспоминал, что после их презентации он отвёл их в сторону и сказал: Ребята, это очень опасно. Кого-то изнасилуют или убьют, и кровь будет на ваших руках. Деньги вкладывать он не стал.

С самого начала Airbnb поощряла незнакомых людей общаться в Интернете, а затем встречаться в реальной жизни, часто ночуя под одной крышей. Компания находится где-то между технологической платформой и гостиничным оператором она не может снять с себя ответственность за безопасность своих пользователей, как некоторые технологические компании (вспоминаем известное у нас Мы не такси, мы просто агрегатор прим. перев.), или предоставить охрану и другой персонал на месте, как гостиница. Доверие и безопасность в Airbnb сложнее, чем в Apple или Facebook, потому что вы имеете дело с реальными людьми в домах реальных людей, рассказывает Тара Банч, руководитель глобальных операций Airbnb.

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

В следующем посте хозяйка написала, что с ней связался соучредитель Airbnb и, вместо того чтобы предложить поддержку, попросил её удалить историю из блога, сказав, что это может повредить предстоящему раунду финансирования. Вскоре #RansackGate стал трендом в Твиттере, и этот инцидент превратился в краткий курс по управлению кризисом. Результат публичные извинения Чески, гарантия хозяевам на возмещение ущерба в размере 50 000 долларов (с тех пор она увеличена до 1 млн. долларов), круглосуточная горячая линия поддержки клиентов и новый отдел доверия и безопасности.

Брайан Чески смотрит на вас как на помеху в привлечении инвестиций.Брайан Чески смотрит на вас как на помеху в привлечении инвестиций.

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

Многие из этих преступлений, происходивших в рамках краткосрочной аренды квартир, размещённых на платформе компании, могли произойти в любой квартире или гостиничном номере. Но в некоторых случаях хозяева использовали платформу компании как инструмент для совершения преступлений. В октябре 2011 года хозяин квартиры в Барселоне, выставленной на Airbnb, угостил алкоголем двух американок, забронировавших проживание в его доме, а затем изнасиловал их. Когда на следующее утро женщины обратились в полицию, хозяин пригрозил выложить в Интернет видеозаписи нападения, если они не откажутся от претензий. Полиция обыскала его квартиру и нашла сотни подобных фотографий других жертв. Мужчина был приговорен к 12 годам тюрьмы. В Airbnb отказались комментировать эту историю, заплатив двум женщинам нераскрытую сумму и пожизненно забанив хозяина квартиры.

К 2016 году команда безопасности была перегружена звонками, многие из которых были незначительными по своему характеру, и Airbnb начала обучать подрядчиков в колл-центрах по всему миру, чтобы они справлялись с потоком жалоб. Airbnb утверждает, что менее 0,1% случаев проживания приводят к возникновению проблем с безопасностью, но при более чем 200 млн. бронирований в год это всё равно очень много поездок с плохим концом. В службу внутренней безопасности передаются только самые серьёзные проблемы.

Эта команда состоит примерно из 100 агентов в Дублине, Монреале, Сингапуре и других городах. Некоторые из них имеют опыт работы в аварийно-спасательных службах или в армии. Члены команды имеют право на любые расходы, чтобы жертва почувствовала поддержку, включая оплату авиабилетов, проживания, питания, консультаций, медицинских расходов и анализов на заболевания, передающиеся половым путем, для тех, кто пережил изнасилование. Бывший агент, проработавший в Airbnb пять лет, описывает этот подход как стрельбу из денежной пушки. Команда переселяла гостей в гостиничные номера по цене, в 10 раз превышающей стоимость их бронирования, оплачивала кругосветные отпуска и даже подписывала чеки на сеансы психологической помощи собакам. Мы делаем всё возможное, чтобы обо всех, кто пострадал на нашей платформе, позаботились, рассказывает Тара Банч. Мы не беспокоимся о бренде и имидже. Эта штука позаботится о себе сама, пока вы поступаете правильно.

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

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

Работа может быть настолько напряжённой, что агенты имеют доступ к комнатам с приглушённым освещением, чтобы создать успокаивающую атмосферу для ответов на тревожные звонки. И это может привести к тяжёлым потерям. Некоторые бывшие агенты говорят, что страдают от викарной (или заместительной) травмы. На работе они старались помнить, что всё происходящее в жизни может произойти и в Airbnb. Эту точку зрения вдалбливали новобранцам во время 12-недельных тренингов: точно так же, как ночные клубы не могут исключить сексуальные посягательства, а отели не могут остановить торговлю людьми, Airbnb не может помешать злоумышленникам использовать свою платформу.

В компании отказались комментировать условия расчётов или бюджет службы безопасности. Но из конфиденциального документа, с которым ознакомился Bloomberg Businessweek, следует, что в последние годы Airbnb тратила в среднем около 50 млн. долларов в год на выплаты хозяевам и гостям, в том числе на судебные разбирательства и возмещение ущерба, нанесённого жилью. (Компания утверждает, что большинство её выплат связано с ущербом имуществу по программе страхования хозяев и что шестизначные суммы выплат исключительная редкость.)

Бывшие агенты по безопасности также рассказывают о напряжённых отношениях с отделом доверия, чья работа заключается в разработке политики по предотвращению плохих вещей, будь то клопы, заряжённое оружие или похищения. Агенты по безопасности, которые наводят порядок только после происшествий, говорят, что чувствовали себя изгоями. Между отделами безопасности и продаж также существовала напряжённость из-за профессиональных хозяев, управляющих несколькими объектами недвижимости, удаление которых с платформы за нарушение правил безопасности могло стоить Airbnb сотен объявлений.

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

Представляем работу секретной команды Airbnb в российских реалиях.Представляем работу секретной команды Airbnb в российских реалиях.

Как и многие другие компании Кремниевой долины, Airbnb поднялась благодаря политике роста любой ценой: она проникала в города, обходя правила, побеждала в народном голосовании и набирала популярность так быстро, что к тому времени, когда чиновники замечали происходящее, у них уже не оставалось шансов контролировать ситуацию. По всему миру разгорелись нормативные битвы, самая токсичная из которых разыгралась в Нью-Йорке в 2015 году. Городские власти проводили операции по выявлению незаконной аренды жилья на срок менее 30 дней и обязали компанию предоставить адреса своих объявлений, что вызвало многолетнюю судебную тяжбу. Airbnb нанимала исследователей оппозиции, чтобы изучить биографии своих критиков, и оплачивала атаки на них в прессе.

Инцидент на 37-й улице. Расследование

В начале 2016 года, после нападения в районе Таймс-сквер, агенты по безопасности сделали то, чему их учили: обеспечили комфорт и помощь жертве. Но возможность судебного разбирательства повысила ставки. Крис Лихэйн, бывший политический консультант президента Билла Клинтона, был принят на работу в Airbnb в качестве главы отдела глобальной политики и коммуникаций за несколько месяцев до инцидента. Инсайдеры компании говорят, что Лихэйн, автор книги 2014 года Masters of Disaster о чёрном искусстве контроля репутационного ущерба, боялся, что этот случай может быть использован оппонентами для изгнания Airbnb из города.

Крис Лихэйн как бы намекает, что даже с супружеской изменой президента можно работать.Крис Лихэйн как бы намекает, что даже с супружеской изменой президента можно работать.

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

Уильям Делайно, много лет живущий в доме на 37-й Западной улице, вспоминает, что друзья этой женщины позвонили в его квартиру в тот вечер, не получив от неё ответа. В здании было довольно много квартир Airbnb, и я привык к подобным поступкам иностранных путешественников, говорит он. По его оценкам, в то время на Airbnb сдавались 4 из 12 квартир здания. Владеющая зданием компания Kano Real Estate Investors LLC отказалась от комментариев. Но после нападения, по словам жильцов, она внесла изменения в свои договоры аренды, запретив им размещать свои квартиры на Airbnb.

Детективам повезло, что предполагаемый насильник, Джуниор Ли, вернулся с ключами. Ему было предъявлено обвинение в хищническом сексуальном нападении, которое в штате Нью-Йорк предусматривает максимальное наказание в виде пожизненного заключения. Прокурор заявил судье, что 24-летний Ли закоренелый преступник, имеющий 40 судимостей за мелкие правонарушения. Ли не признал себя виновным, и залог был установлен в размере 250 000 долларов.

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

Потенциальная ответственность Airbnb за несоблюдение более строгой политики обмена ключей не будет проблемой благодаря урегулированию в размере 7 млн. долларов, которое было достигнуто после того, как адвокат пострадавшей женщины отправил письмо с угрозой судебного разбирательства. Хотя это соглашение не запрещает женщине сотрудничать с прокуратурой, оно не позволяет ей обвинять компанию или подавать на неё в суд. Это было особенно важно для Airbnb, потому что женщина не снимала квартиру и не подписывала соглашение об условиях предоставления услуг компании, состоящее из 10 000 слов еще один важный способ Airbnb не доводить инциденты от суда и не привлекать внимание общественности.

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

От сексуального насилия до убийства

То самое единственное дело, которое удалось довести до конца, было возбуждено в 2017 году, когда Лесли Лапайоукер, 51-летняя женщина, подала в суд на Airbnb после того, как якобы подверглась нападению со стороны хозяина в Лос-Анджелесе. Согласно судебным документам, Лапайоукер переезжала в город из Нью-Мексико и заказала 30-дневное проживание, пока искала постоянную квартиру. В иске говорится, что после того как она решила уехать из-за странного поведения хозяина, он последовал за ней в однокомнатную квартиру, которую она сняла, запер дверь, удерживал её на стуле против её воли, мастурбировал перед ней и кончил в мусорное ведро. Когда Лапайоукер убегала, согласно жалобе, хозяин сказал: Не забудьте оставить мне положительный отзыв на Airbnb. Мужчине, который заявил, что встреча произошла по обоюдному согласию, не было предъявлено никаких обвинений.

Фильм Американский психопат.Фильм Американский психопат.

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

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

Этот же адвокат урегулировала ещё одно дело о нападении, возбуждённое гражданкой США, изнасилованной в Индии родственником хозяина, который был выпущен под залог после обвинения в убийстве.

Аналогичный процесс произошёл, когда семья Карлы Стефаниак, женщины из Флориды, убитой во время празднования своего 36-летия в Коста-Рике в 2018 году, подала иск против компании в том же году. Разлагающиеся останки Стефаниак были обнаружены полузарытыми и завёрнутыми в пластик примерно в 300 метрах от её квартиры на Airbnb. Охранник комплекса, где она остановилась, был признан виновным в её убийстве. В иске утверждалось, что Airbnb не проверила биографию охранника, который работал в стране нелегально. Компания урегулировала дело за нераскрытую сумму.

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

Меньше знаешь крепче спишь?

Стремление Airbnb к секретности также затрудняет понимание того, какое влияние оказывает краткосрочная аренда на общую безопасность районов. Компания не публикует адреса объявлений, чтобы защитить безопасность и конфиденциальность своих пользователей. И, хотя некоторые города США требуют от хозяев вносить свои квартиры в реестры краткосрочной аренды, большинство из них не публикуют эти данные, ссылаясь на те же соображения конфиденциальности. Те, кто это делает, часто не раскрывают номера квартир, что делает практически невозможной проверку многих адресов по звонкам полиции или записям об арестах. Реестры также не включают квартиры, арендуемые незаконно.

Журналисты Bloomberg получил реестры для Остина, Майами-Бич и Лос-Анджелеса через запросы на публичные документы, попытались сопоставить их с публичными базами данных полицейских вызовов или преступлений. За последние два года полиция отреагировала на тысячи инцидентов, связанных с краткосрочной арендой жилья в этих трёх городах. В Майами-Бич реестр показал 1071 вызов полиции по адресам, указанным в 2019 году, включая 40 случаев насильственных преступлений. Однако в полицейских отчётах не указывается, на какой платформе находилась квартира и сдавалась ли она в аренду в тот момент, что затрудняет получение полезных выводов о взаимосвязи между индустрией краткосрочной аренды и преступностью. Научные исследователи говорят, что аналогичные ограничения помешали их усилиям изучить эту связь. Было проведено всего около полудюжины научных исследований по этому вопросу, и их результаты противоречивы.

Поскольку города и полиция не в состоянии собрать данные, а дела редко доходят до суда, громкие инциденты, как правило, определяют политические дискуссии вокруг краткосрочной аренды. Помня об этом, с 2018 года Airbnb передаёт подобные инциденты в свою глобальную группу кризисного управления, которая была сформирована Лихэйном и другими руководителями и первоначально возглавлялась Шапиро, бывшим сотрудником ЦРУ.

В 2018 и 2019 годах произошло несколько смертельных инцидентов, помимо убийства Стефаниак, когда компания готовилась к первичному размещению акций. Один из них произошёл в ноябре 2018 года, когда пара пенсионеров из Нового Орлеана умерла в Мексике, надышавшись токсичными испарениями, когда они спали в арендованной квартире Airbnb. После этого их сын выступил по телевидению, умоляя Airbnb сделать больше для защиты своих пользователей.

Брайан Чески как бы намекает, что устал от таких инцидентов.Брайан Чески как бы намекает, что устал от таких инцидентов.

Брайан Чески, который отказался дать интервью для этой статьи, хотел знать, почему подобные случаи продолжают попадать к нему на стол и почему компания неправильно или несвоевременно реагирует на такие инциденты. Ответ на второй вопрос заключался в том, что у команды безопасности было недостаточно сотрудников. Когда руководители поняли это, последовала встряска. В начале 2019 года группа безопасности была отделена от группы доверия, передана в ведение отдела поддержки и получила дополнительные инженерные ресурсы и персонал.

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

Кровавая хэллоуинская вечеринка

В Хэллоуин Airbnb столкнулась с одним из самых смертоносных инцидентов: перестрелка в доме с четырьмя спальнями стоимостью 1,2 млн. долларов в Оринде, штат Калифорния, примерно в 32 км к востоку от Сан-Франциско. Дом, на который было подано множество жалоб в полицию и городские власти, был забронирован на одну ночь. Гость, о котором Airbnb уже сообщили, что за несколько дней до этого он оставил пулю в другом арендованном доме, что было зафиксировано внутри компании, затем дал объявление о вечеринке в особняке в социальных сетях. На вечеринке было более 100 человек, когда гость-стрелок открыл огонь, убив пятерых.

Полиция расследует стрельбу в Оринде.Полиция расследует стрельбу в Оринде.

Чески выразил свои соболезнования в Твиттере и объявил о новых мерах безопасности, включая запрет на дома для вечеринок и обещание проверять фотографии, удобства, чистоту и безопасность всех объявлений на Airbnb. Но компания не связывалась с матерью одной из жертв, 23-летнего Реймона Хилла, в течение недели, пока её адвокат, Джесси Данофф, не написал письмо и не выступил с заявлением, в котором раскритиковал Airbnb за то, что компания предоставляет лишь молитвы. Даже некоторые из собственных агентов компании по безопасности были расстроены. Они говорят, что дома для вечеринок были проблемой на протяжении многих лет.

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

Впоследствии Airbnb предложила оплатить похороны, но Данофф рассказывает, что, когда некоторые из семей прислали счета на сумму более 30 тыс. долларов, компания начала торговаться. Им уже всё равно, потому что новостной цикл пошёл дальше, рассказывает Данофф. Единственное, что их действительно мотивирует, это угроза или потенциальная угроза плохого пиара или кошмара в прессе. (Airbnb утверждает, что оплатила счета. Данофф говорит, что он всё ещё ведёт переговоры об урегулировании.)Они должны ответить за то, что произошло, говорит об Airbnb мать Хилла, Синтия Тейлор. У моего сына отняли жизнь в доме, который они разрешили продолжать сдавать в аренду на своём сервисе после многочисленных жалоб.

Синтия Тейлор со своим сыномСинтия Тейлор со своим сыном

В декабре того же года Airbnb объявила о выделении 150 млн. долларов на дополнительные расходы, связанные с доверием и безопасностью. Компания ввела круглосуточную горячую линию, которая предоставляет арендаторам немедленный доступ к агенту по безопасности; создала систему, чтобы отмечать бронирования с высоким риском; запретила пользователям моложе 25 лет и не имеющим истории положительных отзывов бронировать Airbnb в районе, где они живут; и перестала разрешать останавливаться на одну ночь на Хэллоуин, 4 июля и Новый год. Многие из этих мер были введены в США их внедрение по всему миру оказалось непростой задачей, учитывая различия в культуре, обычаях и правилах в 191 стране, где работает Airbnb. Компания также обсуждала вопрос о том, нужно ли заставлять пользователей предоставлять удостоверения личности государственного образца, но решила не делать этого, чтобы не исключить хозяев и гостей в странах, где удостоверение личности трудно получить.

Последствия

В начале 2020 года разразилась пандемия, которая свела на нет все путешествия, так как страны закрыли границы, и мир оказался под замком. Airbnb потерял 80 % своего бизнеса за восемь недель. Команда по безопасности была завалена звонками по поводу инфекции. Что ещё хуже, профессиональные организаторы вечеринок начали превращать арендуемые Airbnb квартиры и дома в ночные клубы. Сотни пьяных гуляк без масок разгуливали по пригородам США, напрягая ресурсы полиции, приводя в ярость чиновников здравоохранения и перегружая команду безопасности.

В мае прошлого года Чески плакал в веб-камеру во время общекорпоративного собрания, на котором он объявил о сокращении 25% персонала. Увольнения были ожидаемы, но для многих было шоком то, что вся команда безопасности в Портленде, штат Орегон, была уволена, включая 25 самых опытных агентов компании. Некоторым сказали, что они смогут сохранить работу, если пойдут на сокращение зарплаты и переедут в Монреаль, куда Airbnb переводит свои североамериканские подразделения безопасности, привлеченные выгодными налоговыми льготами и более низкими затратами на недвижимость и рабочую силу.

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

Из эпизода Южный парк Енот 2: Непредусмотрительность, в котором CEO BP в издевательской манере просит прощения за аварию в Мексиканском заливеИз эпизода Южный парк Енот 2: Непредусмотрительность, в котором CEO BP в издевательской манере просит прощения за аварию в Мексиканском заливе

В то время об этом не сообщалось, и это не помешало IPO. После открытия торгов в декабре Airbnb продемонстрировала один из самых больших скачков (цены на акции) в первый же день, увеличив состояние каждого из основателей более чем на 10 млрд. долларов.

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

Airbnb всё ещё приходится сталкиваться с кризисами безопасности, реагировать на нападения и бороться с регуляторами. 31 мая в рамках соглашения об урегулировании судебного процесса с Нью-Йорком компания начала передавать информацию о своих хозяевах, включая имена, адреса и информацию о том, сдают ли они всю квартиру. Эти данные облегчат отслеживание незаконных объявлений.

Спустя более пяти лет после нападения на 37-й Западной улице Airbnb всё ещё не установила чётких правил относительно ключей. Этот случай положил начало многолетним внутренним дебатам о бесключевом доступе. Если бы хозяев можно было заставить пользоваться цифровыми клавиатурами и менять код после каждого пребывания, то в будущем можно было бы избежать подобных ситуаций. Даже требование раскрывать информацию о том, есть ли у них вход с клавиатуры, может изменить ситуацию. Шапиро, бывший глава антикризисного управления, вспоминает, как настаивал на том, чтобы исключить обмен ключами. Я помню, как пытался поговорить о процессе обмена ключами и способах предотвращения того, чтобы хозяева оставляли их в магазинах, говорит он.

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

Узнайте, как прокачаться и в других специальностях или освоить их с нуля:

Другие профессии и курсы
Подробнее..

Recovery mode Правильное распределение ролей в проекте половина успеха!

17.06.2021 20:21:19 | Автор: admin

Авторы кейса для хакатона рассказали, как стать победителем IT-конкурса.

Уже завтра Нижний Новгород превратится в столицу цифровой экономики. Здесь проведут сразу два хакатона: первое в России IT-соревнование по искусственному интеллекту и полуфинал Всероссийского конкурса разработчиков Цифровой прорыв Медицина, здравоохранение, наука. Для последнего EPAM вместе с ННГУ им. Лобачевского подготовили кейс CardioSpike. На основе полученных учеными данных нужно разработать детектор ковидных аномалий в ритме сердца. Пять сотрудников EPAM практики Data Science, которые участвовали в создании датасета, войдут в состав жюри. Они рассказали, как правильно подготовиться к хакатону.

Павел Шашкин, Data Science, EPAM: Каждый набор данных особенный по-своему, и не всегда перенос опыта из других задач даёт хорошие результаты. Начинайте с максимально простого решения, постепенно эмпирически проверяя новые гипотезы и наращивая сложность. Важно отдавать себе отчёт, что, независимо от уровня ваших навыков, с ростом количества разнообразной логики в решении растёт и вероятность допустить в одном из шагов ошибку.

Даниил Гусев, Data Scientist, EPAM: Каждый хакатон это вызов вам, вашим знаниям и умениям решать проблему здесь и сейчас. Для победы нужно придумывать новые подходы, экспериментировать, но это не касается инструментов, которые вы будете использовать. У вас не будет времени на освоение новых библиотек и фреймворков. Используйте только те инструменты, которыми вам уже хорошо знакомы.

Павел Смирнов, Data Science, EPAM: Распределите роли в команде. Кто занимается внешним видом и UX? Кто занимается архитектурой и масштабирование? Кто отвечает за МЛ часть? Кто готовит презентацию? Кто питчит финальное решение перед жюри? Перечитайте постановку задачи несколько раз. Очень важно не забыть в конце, какую задачу вы решаете. Поставьте библиотеки для работы с данными (numpy, pandas и т.д. ). Познакомьтесь с целевой метрикой - https://scikit-learn.org/stable/modules/generated/sklearn.metrics.f1_score.html)/. Посмотрите на описание и документацию к классическим алгоритмам, которые можно применить для решения задачи - https://scikit-learn.org/stable/supervised_learning.html.

Михаил Терпелец, Data Science, EPAM: Всем участникам я бы посоветовал избегать процедурного спагетти и не забывать следовать DRY, KISS, YAGNI. Ну и, конечно, дважды проверять код перед запуском, чтобы в ограниченное время не допускать ошибок по невнимательности. Обученных вам моделей и оптимальных гиперпараметров!

Всеволод Мицкевич, Data Science, EPAM: Так как и задача, и состав команды известны заранее, стоит побеспокоиться о том, чтобы правильным образом делегировать задачи. Каждый из инженеров обладает сильными и слабыми сторонами в разработке. Следует поближе познакомиться между собой и выяснить, какой опыт каждого из участников команды релевантен по отношению к задаче хакатона. Кому-то стоит заняться подготовкой данных, кто-то лучше пишет код, а у кого-то обширнее теоретические знания. Правильное распределение ролей в проекте половина успеха!

Подробнее..

Перевод Разработчики не могут исправить ошибки управленцев

18.06.2021 12:04:53 | Автор: admin
Мне постоянно попадаются статьи, в которых разработчиков упрекают за нежелание вникать, зачем нужна их работа, и доказывают им, что это неправильно вслепую вносить изменения, не разбираясь, какая за этим стоит цель. Звучат призывы в духе оглянитесь вокруг, не уходите с головой в написание кода!. На мой взгляд, эти статьи обращены не к тем людям.

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

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

Организации, живущие по заветам университетских программ делового администрирования, избегают моделей с нефиксированными объемами работ. Им проще сосредоточиться на том, чтобы у технических команд было что-нибудь Готово к определенному сроку. Готово обычно бывает что-то никому не нужное, потому что вопрос об определении реальных потребностей аудитории замяли. Вдобавок в проекте обычно царит полный хаос, потому что команда раз за разом бросает силы на то, чтобы делать новый функционал, вместо того чтобы оценить свою работу и устранить тот самый хаос. Единственный плюс того, что проект довели до состояния Готово как правило, это событие отмечают пиццей и тортом. Если очень повезет, то еще и умеренным повышением кого-нибудь из команды, за то, что уложились в сроки. Правда, в реальности новым функционалом люди не пользуются, но это до поры до времени не имеет значения, пока в один прекрасный день кто-нибудь (как правило, финансовый директор) не посчитает KPI по формуле 4Х и не урежет команде финансирование.

В истории уже такое было


Для сложившейся ситуации в разработке ПО можно привести историческую параллель. Где-то в сороковых годах прошлого века Уильям Эдвардс Деминг предложил производителям автомобилей Детройта новую методику автомобилестроения. В Детройте в то время деньги гребли лопатой за счёт того, что успели захватить самый прибыльный рынок в мире, и, честно сказать, не видели смысла что-то менять в принципе. Получив отказ, Деминг перешел на другие виды деятельности, стал принимать участие в восстановлении японской экономики после войны. Там его методы показали себя хорошо, и понемногу машины японского производства стали теснить Детройт на рынке.

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

К 1981 году, когда Япония подтачивала позиции Форда на рынке уже десятки лет, руководство наконец сдалось и пригласило Деминга отладить производство. В их преставлении проблема заключалась в качестве изготовления деталей иными словами, в рабочих, которые изготавливали недостаточно качественные детали. Ведь не начальство же этим занимается. К большому их удивлению, Деминг заявил, что 85% проблем, негативно влияющих на качество продукции, происходят от неправильного руководства. Компании понадобилось шесть лет, чтобы перейти на новую модель, и результатом стала линейка автомобилей Taurus-Sable на голову выше того, что они делали до этого.

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

Теперь вернемся к тем статьям с призывами разработчики, подтянитесь!, которыми кишит Интернет. Давайте представим, что они обращены к рабочим, занятым в автомобилестроительстве. Прямо вижу эти заголовки:

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

Авторы хотят как лучше и, на первый взгляд, вроде бы дают разумные советы. Но как именно эти самые работники автомобильной промышленности должны перекраивать рабочие процессы? Им предлагается переучивать начальство? В истории прецедентов особо не встречается, и я сильно сомневаюсь, что и сейчас это кому-то удастся. В подобной же ситуации оказываются и разработчики многих компаний. Большинство работает под игом выпускников по специализации делового администрирования. Каждый разработчик становится метафорическом винтиком в системе PMP/WBS всем по диаграмме Ганта, менеджеру проекта и индикатору типа задачи.

И даже когда компания, работающая по традиционной модели, решает переключиться на Agile, зачастую всё выливается во внедрение антипаттерна Date Scrum, который прекрасно уживается со стандартным подходом к руководству. Растущая популярность Date Scrum привела к тому, что у многих разработчиков сложилось неприязненное отношения к практикам Agile вообще. Их сложно винить: если до внедрения Agile им приходилось терпеть собрания с отчетом по текущим задачам раз в пару недель, то с Date Scrum приходится страдать ежедневно!

Что такое Date Scrum?
Это практика из сферы R&D, которая предписывает разработчикам оценивать проектные требования сразу для всей протяженности работ целиком. Когда проекту дают зелёный свет и утверждают бюджет на базе конечных оценок, команда каждый день собирается на встречах (скрамах), чтобы отчитаться по текущему положению и нейтрализовать рискованные моменты; таким образом решение итерируется по мере продвижения к дате релиза. Некоторые воспринимают этот подход как каскадную модель, только реализованную спринтами.

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

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

Форду понадобилось сорок лет, чтобы перенять модель, разработанную Демингом. Сейчас темп жизни ускорился, и компании, которые ещё сорок лет намерены продолжать дёргать талантливых разработчиков, просто не вытянут. Полагаю, что большая часть тех, кто будет сопротивляться изменениям, пойдет ко дну уже лет через десять. Подобные мрачные предзнаменования вызваны тем, что компании с традиционным подходом работают по методичкам, написанным для промышленной сферы. Они разбивают сотрудников на группы по типу работ, а затем оптимизируют все отделы при помощи одного набора жёстких, шаблонных лучших практик, которые обычно один в один списаны с фабричных. Именно это препятствует созданию продуктов, которые несли бы ценность за счёт выявления и закрытия важных потребностей, и приводит к тому, что разработчики вынуждены с головой уходить в код, который в конечном счёте никому не нужен. По той же причине в компаниях упорно закрывают глаза на все знаки того, что проект сошел с рельсов в них слишком крепко прижились застарелые антипаттерны из университетских программ. Например:

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

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

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

Следует обратить внимание и на то, чего разработчики просят не делать:

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

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

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

Что за группы, генерирующие идеи?
Это структуры внутри компании, которым поручается придумывать новые продукты и новый функционал. Затем их идеи передаются на реализацию другой группе. Во многих компаниях за этот круг задач отвечают менеджеры продуктов.

В команде iiSM.ORG бытует мнение, что ПО меняет в жизни, работе и развлечениях людей очень многое за счет оптимизации и автоматизации. Доля IT-предприятий среди мировых топ-компаний неуклонно растёт по экспоненте, и вскоре наш ждёт целый поток изменений, который вызовет переворот в бизнесе и видоизменит общество. Если мы правы (а я полагаю, что правы), то руководителям, работающим по старинке, придётся подстраиваться под реалии мира после цифровой трансформации. Поэтому давайте не пожалеем времени на то, чтобы донести: традиционные техники менеджмента попросту не работают применительно к разработке ПО и продержаться на них в долгосрочной перспективе невозможно.
Подробнее..

Хочу больше годных профстатей, Хабр

21.06.2021 10:15:25 | Автор: admin

Листая страницы Хабра, поймал себя на мысли, что я воспринимаю Хабр как новостную ленту в социальной сети. То есть как нечто, что прямого отношения лично ко мне не имеет и касается меня очень косвенным путем. Нечто полуразвлекательное-полупознавательное.

Ну, судите сами. Вот примерный список тем, которые превалируют на Хабре.

  1. Что там новенького у Илона Петровича Маска.

  2. Как с помощью Arduino, говна и палок сделать годный фаллоимитатор радиоприемник.

  3. Как я ушел с прошлой работы, и как мне было там плохо.

  4. Как я нашел свою текущую работу, и какая она крутая.

  5. Как живется специалисту X в стране Y.

  6. Какой путь нужно проделать фельдшеру из Ангарска, чтобы стать тестировщиком мобильных приложений в Ирландии.

  7. Обсуждение новомодной платформы для веб-разработки, которая через 3 года станет старомодной.

  8. Промываем косточки крупным компаниям.

  9. Исторические экскурсы в IT/технологии/медицину.

  10. Реклама компаний.

  11. Мнения обо всем отвлеченном на свете.

  12. И т. д.

Все эти темы и все статьи неплохие, интересные. Но я хотел бы другого.

Я давно программирую на С++/qt. Думаю, что могу создать с нуля любой программный продукт (desktop) . Могу набирать команды, могу выстраивать отношения с заказчиками и т.д. Периодически приходится запускать (создавать) новые направления/программные продукты. Однако время, затрачиваемое мной и командой на каждый новый продукт, остается примерно постоянным. Вернее, не совсем так. Время суммарной работы оказывается в прямой пропорциональной зависимости от сложности продукта (объема кодовой базы). То есть постоянной величиной оказывается производительность работ, или эффективность труда. На всякий случай оговорюсь, что речь не идет о новичках, в команде только опытные толковые сотрудники.

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

Мне хотелось бы поднимать свой профессиональный уровень серьезными профессиональными статьями по проектированию/созданию/ведению больших продуктов. Статьями, которые по легкости восприятия были бы такого же классного уровня, как и сейчас большинство статей на Хабре. Но статьями, которые по глубине и полезности были бы как классические книги Скотта Майерса, банды четырех, Алана Купера, Роберта Мартина и др. Знаете, читая эти книги, я прибавлял каждый раз в квалификации. К сожалению, читая статьи на Хабре, я этого не чувствую. Даже более того: не могу припомнить случая, когда я хотел изучить какой-то новый для меня (и обычно нетривиальный) нюанс и находил бы его на Хабре. Я находил его где угодно, но только не на Хабре. Или вообще не находил.

Посему я очень жду и буду приветствовать появление на Хабре статей по следующим направлениям.

Новые шаблоны проектирования (С++)

Да, я знаю, что шаблоны не догма и не панацея, и всё всегда можно придумать и самому. Но я также знаю, что это проверенная годами экономия времени архитекторов и программистов. Это кругозор, который (при его наличии) позволяет делать сложную работу быстрее, а то и вообще моментально. У меня сложилось ощущение, что в мире С++ развитие шаблонов практически остановилось на известной книге банды четырех. Там описано 23 шаблона, и еще примерно столько же можно накопать в интернете. Я хочу больше! В моей практике были случаи, когда приходилось создавать шаблоны, разительно непохожие на известные. И приходилось тратить довольно много времени на приведение их к товарному использованию, хотя бы даже на продумывание такой терминологии, которая бы естественно бы воспринималась коллегами. Уверен, что если бы мы имели возможность в нужный момент найти и прочитать описание свежего шаблончика, наша работа местами была бы намного быстрее.

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

Кстати, по шаблонам есть фундаментальный труд POSA: 5-томник на 2000+ страниц, перевода на русский язык до сих пор нет. Чем не непаханное поле?

Шаблоны ведения проектов в Git

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

  1. Я веду маленький проект на 20 тысяч строк кода, в нем задействовано 5 человек, с системой контроля версий мы работаем вот так (и описать конкретно, вплоть до команд командной строки).

  2. Я веду неплохой проект на 100 тысяч строк кода, в нем задействовано 10 человек, и мы работаем вот так: схемы, команды git.

  3. Мы с тремя командами по 10 человек развиваем проект на 1 миллион строк кода, продаем продукт разным клиентам в разных конфигурациях, и всё свое хозяйство мы покрыли регрессионным тестированием. И для этого мы делаем вот это: схемы, команды git.

  4. У нас работает 200 человек, и у нас 10 миллионов строк кода в монорепе на 5 продуктов, и каждый продукт ещё поставляется в трех разных версиях. Мы опытным путем пришли, что только так: схемы, команды git.

  5. А у нас очень много кода и много микросервисов, каждый в своем репозитории, впрочем, есть и подрепозитории (подмодули). Часть кода покрыта тестами, часть нет. Раньше мы работали вот так, а теперь перешли на вот это (схемы, команды), но по эффективности труда одинаково приемлемо.

GUI

Дизайн GUI, новые подходы, примеры удачных и неудачных виджетов, примеры плохих и хороших интерфейсов/решений. Эта область очень динамично развивается в плане того, что мы видим на экранах своих смартфонов и мониторов (причем на смартфонах более динамично, чем на мониторах). Однако в плане научного описания, осмысления и систематизации всё как-то вяло. То есть решений полно, но ими никто не делится. А если и делится, то как-то не очень доходит до конкретных исполнителей, и те пишут с нуля. Думаю, ситуация бы улучшилась, если бы появилась серия статей в таком духе:

  1. Камрады, я внедрил к себе гамбургер-меню на 500 строк (qt) вот отсюда (ссылка). Вот, смотрите: скриншот, gif-анимация. Работает чётко! Лицензия LGPL. Короче, пользуйтесь все.

  2. Я создал свой виджет ввода паролей. Он круче, чем другие по таким-то причинам. Делюсь! Ссылка на репозиторий, скриншоты.

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

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

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

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

  7. Я супермегадизайнер, и на примере 30 известных приложений за последний год объясню вам, что попало в тренд, что не попало, а что создает будущий тренд.

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

Знаете, меня не сильно цепляют новости, о том, какие планы у Джеффа Безоса на космос или как Boston Dynamics обучает своего пса. Это не увеличивает мою зарплату. Я хочу чего-то более близкого и понятного мне, но самое главное применимого в моей работе.

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

Сложные ли это задачи? Непростые, но решаемые. И некоторые из них решены многократно самыми разными производителями софта.

Давайте еще пример. Я запускаю приложение X и параллельно еще парочку для полного занятия вычислительных ресурсов (например, конвертор видео). И вот в приложении X вижу слайд-анимацию, который замечательно себя ведет (нисколько не тормозит) при том, что соседние приложения на 100% заняли мой процессор. Это неплохой результат для X, и, черт возьми, я хочу знать, как они этого добились.

Да, я знаю, что есть такие понятия, как коммерческие секреты, патенты и всякое такое. Но ведь несложно же из груды решенных задач вытащить что-то такое, что давно уже не представляет коммерческой ценности и поделиться этим с программистским сообществом. Подозреваю, что в команде разработки, к примеру, Adobe Photoshop найдется немалая кипа примеров изящно решенных нетривиальных задач, которые незаслуженно скрыты от мира. И если бы их открыть в виде конкретных формул, диаграмм (а в идеале исходного кода) и разместить в удобочитаемом виде на Хабре, это было бы очень многим полезно.

Вместо послесловия

Изложенные мной хотелки уже присутствуют в некотором небольшом количестве на Хабре, а помимо этого, подобную информацию по крупинкам можно собирать на конференциях, искать в книгах и некоторых научных журналах. Но трудозатраты слишком велики! Бывает, читаешь книгу в 500 страниц, чтобы найти хоть намек на решение, а его там не оказывается. Или, того хуже, оказывается, но такой, что лучше бы его не было Статьи в научных журналах часто оказываются написанными не с целью поделиться со всем миром своими достижениями, а просто формально отчитаться за очередной грант. Да и вообще, кажется, что печатные научные журналы по программированию эволюционно проигрывают интернет-платформам.

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

Подробнее..

Кошмары нашего городка как производство работало в первые месяцы пандемии

21.06.2021 10:15:25 | Автор: admin

Нас вы, скорее всего, знаете по блефарогелю для глаз и ещё разной косметике и медсредствам. Но если брать основной выход нашего производства по объёму, то это гели для УЗИ. В пандемию они стали критичными для страны, потому что с помощью УЗИ нельзя было ни поставить, ни исключить диагноз, но можно было определить, стоит ли вести пациента на КТ. А когда случился коллапс на КТ, УЗИ в кабинетах врачей и региональных клиниках очень помогали.

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

Теперь, когда мы все будем вспоминать 2020 год как первый год с возрастным рейтингом, я могу рассказать эти тёплые ламповые истории.

Проблемы с компонентами

Заграницы на какое-то время не стало не только в плане путешествий, но и в плане поставок. Резко подорожали компоненты средств. Сразу же подорожал полимер. Мы используем разные кросс-полимеры, включая акрилаты для медицинского и косметического производства. Больше всего проблем было с полиакрилатами, которые нужны для самой основы геля. В момент, когда весь мир искал способы быстро производить санитайзеры, упало количество производимых в мире полиакрилатов нужного нам качества. Сырья осталось настолько мало, что появилось квотирование. Крупнейшие производители начали устанавливать верхнюю планку отгрузок. Нам сообщали: Мы можем вам отправить в этом не больше N тонн сырья. Почти все эти N тонн нужны были, чтобы произвести гели для УЗИ, которые внезапно стали нужны в стране больше, чем раньше.

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

Начали разоряться контрагенты по сырью. Некоторые просто говорили, что всё заморозили, некоторые переставали отвечать. Мы до пандемии хотели делать крутые косметические маски из нетканки, и вот в саму пандемию начался кризис материала.

Люди с чемоданами денег

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

К нам приезжали странные люди с юга России, которые очень плохо говорили по-русски. Но при этом они все были с чемоданами денег, спортивными сумками денег или мешками денег и хотели купить у нас наш гель для УЗИ. Тем, кто делал это легально, мы его продавали, поскольку по антимонопольному законодательству не можем отказывать клиентам. Насколько мы знаем, они собирались брать наши медиагели и вмешивать в них спирт, чтобы получать антисептики для продажи. Что характерно, спирт у них был а в стране уже не было. Мы им объясняли: Ребята, вы сейчас не сделаете антисептик с помощью геля для УЗИ и спирта, который вы где-то там украли цистерну. Это не будет антисептик. На что они отвечали: Нам плевать, мы продадим.

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

За апрель 2020-го мы произвели абсолютный максимум геля для УЗИ в тоннах за всю историю компании. Потом рекорд побили ещё раз, но тогда это казалось невероятным. При этом цены на гель росли прямо в процессе из-за сырья, и нам тоже нужно было поднимать цены, чтобы можно было делать следующую партию. Можно было получить письмо от производителя об увеличении цены в полтора раза с завтрашнего дня.

Карантин

Всё это безумие дополнялось тем, что у нас постоянно сбоило что-то из-за карантинных мер в Москве. Мы сразу же получили письмо от Минпромторга, что производство останавливать нельзя, потому что гели для УЗИ критически важны. Но это не значит, что наши поставщики, производители канистр или дозаторов и так далее тоже подпали под такие письма. Цепочка поставок разрушалась на глазах, и при этом царило полное непонимание, кто может работать, кто нет и что вообще делать.

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

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

Респираторы

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

Мы успели запастись и медицинскими СИЗами, и промышленными СИЗами, которые для промышленных нужд делают. То есть мы успели купить респираторы третьего класса мы создали запасы, когда ещё закрывали Европу. Это уже потом начались запреты на продажу масок негосударственным компаниям. Но всё равно масок было мало. Через несколько недель наши запасы начали кончаться, и мы запросили помощь у государства, чтобы нам дали квоту чтобы производство не останавливалось. В итоге всё равно пришлось выкручиваться самим. Нам предложили СИЗы по коммерческой цене из Китая без регистрационных удостоверений. Взять мы их не могли. Все эти ростехи и прочие конторы, которые должны были помочь нам от государства, просто не работали. У меня прям переписки с ними хранятся до сих пор. В какой-то момент мы научились правильно обеззараживать респираторы третьего класса, что продлило их ресурс. У нас было по три респиратора на человека.

Напомню, это было самое начало пандемии, когда люди по домам шили маски из носков (и, естественно, они не работали). На рынке были многоразовые маски, которые ни от чего не защищают. В аптеках масок не было. Мы не знали, что делать, как делать, как будут лечить, куда бежать. Это сейчас заболеть куда менее страшно, потому что тебя хотя бы будут лечить и понятно, чем лечить. А тогда реально не было ИВЛ, не было гелей в больницах, не было разработанных протоколов.

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

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

Обстановка на производстве

В целом мы прошли ситуацию очень гуманно. Не было острой вспышки заболевания на производстве. Возможно, потому что мы очень жёстко соблюдали все правила госпитального уровня. У нас были камеры везде по производственным, по складским помещениям, и любое снятие маски в рабочей зоне каралось лишением премии. Люди не снимали. Люди вменяемы. Мы всё очень хорошо прорабатывали, каждое совещание обсуждали, декларировали, что, нет, нельзя и так далее. Говорили, что ребята, поймите, это ради вас и не ради чего-то. Мы оплачивали все тесты. Абсолютно все тесты: если чувствуешь себя плохо, то сиди дома или иди к платникам и делай экспресс-тест. Мы безжалостно высаживали на больничный, но больничные нашим коллегам частично не проводили официально. Мы оплачивали такие периоды как рабочие дни. У нас были личные градусники у сотрудников, и раз в три часа по команде все мерили температуру. Мы нашли ртутные градусники, потому что мы не доверяли электронным, особенно после того как разобрали пару. И особенно с учётом того, что полстраны тогда имели температуру 35,2 на входе в здания, и никого это не беспокоило. В итоге у каждого сотрудника был свой ртутный градусник для индивидуального пользования. При любом отклонении выше 37 однозначная отправка домой.

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

Радости добавили бытовые истории ну, знаете, вроде той, что парень развёлся с девушкой, но не до конца успел в карантин, и они оказались заперты вместе на 32 квадратных метрах в квартире-студии.

Рынок на тот момент

В какой-то момент косметологиям попросту запретили работать. Всех косметологов России высадили по домам на карантин, потому что они попали в сферу бытового обслуживания. Это как парикмахеры, только чуть другие. У них был запрет на приём пациентов, длиной у кого месяц, у кого два месяца, а у кого и три с половиной сидели в зависимости от региона. Но даже когда официальный запрет на приём пациентов кончился, косметологи вышли работать далеко не все. Многие салоны просто поумирали. Понятное дело, что потребность в косметологии в принципе никуда не делать, но традиционный рынок в тот момент сначала практически остановился, а потом сильно просел. Всем тем, кто работали с косметологами по стандартным каналам, пришлось туго. Напомню, мы достаточно долго рассматривали себя как производство без розницы, то есть продавали свои гели либо в аптечные сети, либо оптом косметологическим сетям. Только ближе к пандемии мы задумались про онлайн-розницу и начали что-то понимать в ИТ (про это я писала вот здесь). Это тоже очень сильно ударило по бюджету производства, но не так сильно, как могло бы.

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

Но со спиртами ещё проблема в том, чтобы антисептик работал, там должно быть не меньше 70% спирта в большинстве составов. То есть всё, что ниже не работает. А как только вы начинаете работать на производстве с 70% раствором изопропилового спирта, надо всерьёз задуматься о взрывозащищённости. Этиловый просто горит, а изопропиловый либо горит очень весело, либо грустно взрывается. Это совершенно другие типы реакторов, другие трассы, другие требования к производству. Хороший антисептик получался дорогим. Мы решили в это не лезть. Как оказалось, правильно. До сих пор к нам приходят коллеги и с печальными глазами спрашивают: А вам не нужен антисептик? Мы говорим: Нет. Один из поставщиков в какой-то момент готов был отдавать свои запасы за 3% оптовой цены, потому что у них склады надо было освобождать, и его хранение создавало уже убытки.

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

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

Как я говорила, дальше пандемию мы пережили довольно гладко (ну, если не считать того, что ещё ничего не кончилось). При этом мы уже почувствовали на себе новый тренд в косметологии, связанный с запахами. Началось с того, что увеличилось количество жалоб на запахи. Причём у тех продуктов, которые вообще не пахнут. Вот есть крем, 20 лет мы его делаем, там очень слабый запах отдушки, который почти не чувствуется. Мы гордились этой отдушкой всегда, потому что её такую было очень сложно подобрать. И вот на продукты вроде него, где либо вообще нет отдушек или где отдушек минимальное количество, нам приходят жалобы Мне запах не понравился. Лаборатория всё проверила: ни отдушка не менялась, ни производитель не менялся, и контрольные образцы так же пахнут и так далее.

Есть подозрения, что это, на самом деле, бойцы невидимого фронта, то есть те, кто болели коронавирусом, например, бессимптомно. Или симптомно, но давно, у которых коронавирус влияет на органы чувств в основном: на вкус и запах. Причём влияет очень странно. Эти проблемы могут вылезать не только после болезни и во время болезни, но и через полгода. Я болела сама, думала, ничего не поменялось. Но через пару месяцев вдруг поехала мимо заправки и бензин запах лавандой очень сильно. Потом я ещё неделю чувствовала странные сильные запахи от всего. Потом это прошло. Потом месяца через три случилось снова. Повторного заражения не было. В косметике тот факт, что приятные запахи начинают вызывать отвращение либо наоборот симпатию начинают вызывать запахи, которые никогда не вызывали, он очень сильно повлияет на использование отдушек.

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

Если интересно, как мы создаём новые средства, заходите к нам в telegram-канал (@geltek_cosmetics). Там мы рассказываем интересные штуки про хроники нашей уютной лаборатории.

Подробнее..

Категории

Последние комментарии

© 2006-2021, personeltest.ru