Смирнов Алексей @arkenoi рассказал, в чём отличия от типового комплаенс от вводимого GDPR (новые правила обработки персональных данных в Европе для международного IT-рынка)

Типовой комплаенс, вроде pci dss — он в основном про чеклисты. "должно быть так и так"
а в gdpr вообще чеклистов нет, он про процессы
собственно в основном про то, что
a) есть внятное описание какие персональные данные обрабатываются и как
b) эта обработка не избыточна
c) есть отвественный
d) по запросу пользователя ему подробно покажут что про него есть
e) после того как в данных отпала нужда или пользователь попросил их удалить — они удаляются.

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

Всю эту неделю я с удовольствием вёл канал https://twitter.com/backendsecret и сейчас кратко продублирую здесь некоторые твиты.

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

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

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

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

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

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

Я кратко расскажу, кто может запороть проект левой задней даже если разработчики сделали всё красиво! Первые - это конечно продуктоводы. Имейте в виду, - первое чему их учат, это сваливать вину на разработчиков!

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

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

По каждому продукту из цепочки 1) сформулирован результат, который достигается продуктом (конкретика) 2) он (результат) измерен (измеримость) 3) измерена его цена (достижимость) 4) понятно, нужен ли он в действительности (актуальность) 5) известно время его достижения.

Эти пять вопросов называются оценкой по SMART: Specific - конкретика, Measurable  - измеримость, Achievable  - достижимость, Relevant  - актуальность, Time-bound - ограниченность по времени. Подробнее прочитаете здесь: https://ru.wikipedia.org/wiki/SMART

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

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

А есть примеры из жизни про админов/devops у кого, когда их зря дернули ?

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

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

Смех-смехом, но это единственное, что отделяло нас от победы. И как быть, было непонятно.

Мои девопсы построили за пару дней небольшой machine learning на базе решения от ibm, который совмещал по смыслу картинку и текст, замыкая таким образом смысловой баннер в единую композицию.

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

Ок, это интересно. Но правильно понимаю, что тут devops можно заменить на разработчик/инженер и посыл не изменится ? то есть, это не devops-специфичная история.

Развейте тему, чтобы было понятно, - если можно с примерами. Где девопс специфичная история, а где нет. Сможете?

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

вам будет интересно если я напишу статью как сделал и нужно ли это вообще?