Названия релизов

В одной знакомой команде каждый бекенд-релизы именуются по названию песни Rammstein. Вчера, например, выпустили https://www.youtube.com/watch?v=x2rQzv8OWEY

(Разумеется у них в названии релиза присутствуют также и числовые характеристики, ответственные за дату и номер, минорную/мажорную версию и вот это вот всё, требуют процессы)

Кто как ещё именует релизы?

Взаимодействие бизнеса и разработки

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

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

Знакомые искали программиста удалёнщика

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

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

О командах

Вот представь себе две команды:

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

Какие проекты с такой командой можно делать? Да точно такие же, как команда - проходные разменные.

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

Коммуникации в команде при решении сложных задач ("сложены из многих простых задач").

Возникла у заказчика Боль и он перекидывает её в разработку через забор: "сделайте красиво!". Команда разработки точно также запросто задачу возвращает с формулировку "сделать красиво качественно или дёшево?"

Что произошло?

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

Предположим в этом месте пришёл лесник и всем грозит пальцем.

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

Разработчики почесали репу и предложили реализовать её "дорого и долго". Вернули тикет на согласование. Заказчик настаивает на "дёшево и быстро". И снова начинается пинг-понг.

Снова приходит Лесник и грозит всем пальцем.

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

Таким образом для решения сложных требуется следующая цепочка коммуникационных действий:

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

С этим контекстом уже переспать и обдумать его.

* Провести митинг брейн-шторминг, который позволяет договориться о решении возникшей проблемы.

С этим уже можно идти в разработку.

Продуктовая проработка

Много лет назад я стал заниматься подготовкой задач к разработке, которая отвечает на большую часть вопросов разработчиков.  Лет 15 назад это было что-то типа "ой, доктор, что-то мне плохо! сделайте мне хорошо!". Теперь этот список вырос до 15 пунктов.

1. Прежде всего задачу от бизнеса надо провалидировать, - понять, что в реальности заказчик хочет:
* Какого хотим достичь результата?
* В чём будет измеряться результат?
* За счёт чего будет достигнут результат?
* Действительно ли выполнение данной задачи позволит достигнуть результата?
* В какие сроки имеет смысл данная задача

2, Теперь можно спросить как раз то, на что заказчик готов отвечать всегда - как он это видит: описание use кейсов

3.  После этого нарисуем на бумажке или в мокапах скетчи

4. Сразу придумаем и отдадим в переводы все тексты и переводы для них.

5. Договоримся о том, как различные компоненты системы будут общаться друг с другом: формализация API - Swagger/GraphQL

6. Тестировщики ушки на макушке уже разрабатывают тест кейсы

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

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

9. Добрались до дизайна. Сначала креативный дизайнер набрасывает концепт, а затем технический прорабатывает детали.

10. Верстальщики могут верстать

11. Вступает в бой тяжёлая артиллерий - Frontend-разработчики

12. Тестировщики пишут автоматизация тестов

13. И вот наконец главная валторна - backend часть

14. Рояль в кустах: аналитика и допилки для аналитики, раз у нас считается достижимость цели

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

Сегодня добавлю в этот список ещё 3 пункта!

— Внимание, говорит капитан. Мы находимся на высоте 10000 метров. В кабину пилота приглашаются специалисты по пилотированию ✈️
По салону прошла смутная волна тревоги. Даже спящие пассажиры стали хмуриться, хоть глаз так и не открыли.
— Повторяю, в кабину пилота приглашаются специалисты пилотированию ✈️
Теперь уже всем стало ясно, что происходит что-то из ряда вон выходящее. Пожилой мужчина поймал за руку стюардессу.
— Извините, а зачем вам нужны эти специалисты?
— А, ничего особого. — Очаровательно улыбнулась девушка. — Наши пилоты не умеют сажать самолет 🛬
— Что?! — Взвыла спутница пожилого мужчины. — Вы с ума сошли?! 😱😱😱
— Не стоит так волноваться! — Успокоила ее стюардесса. На борту полно специалистов!
— С чего вы так решили?
К разговору внимательно прислушивались все сидящие поблизости.
— Вы смотрели видео на ютубе где самолет болтает перед жесткой посадкой?
— Да! — Хором ответили сразу несколько пассажиров.
— А помните, что вы писали в комментариях? Про правильный крен, встречные воздушные потоки, идиота пилота и все такое?
— Ддда, — буквально коченея ответила женщина.
— Ну вот, не о чем беспокоиться! На борту почти 500 специалистов! Мы специально подбирали!

(Рагим Джафаров о диванном профессионализме).

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

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

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

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

* SMART
* Usecases
* Mockups
* Text and translates
* API design
* Test cases
* Grumming
* Doc updates
* Creative & Tech design
* HTML-coding & Frontend Coding
* Automate tests
* Analytics
* Code growing

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

* движения задач в тикетнице
* апдейтов кода
* логирования времени

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

Оцениваем метрики отделов

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

Так как «эффективный менеджер» — по природе своей паразит и редиска, то первое, что делает наш гость — пересматривает метрики по всем направлениям.

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

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

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

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


https://habr.com/company/crossover/blog/428592/

Завтра стартует 12-ый Хайлод++. По доброй традиции трансляция из главного зала будет совершенно бесплатной. О том, как подключиться и что будет транслироваться можно посмотреть вот тут https://habr.com/company/oleg-bunin/blog/428852/. В главный зал попадают доклады, которые слушатели выбрали, как наиболее интересные, ПК лишь выстраивает их в цепочку. Подключайтесь, если не будете присутствовать лично.

P.S. Опубликовано по  просьбе организаторов Highload++

Идентифицируете ли в своей разработке любые проблемы, затронувшие конечных кастомеров каким-то идентификатором, который кастомер может предъявить, а вы по нему протрекать проблему?
anonymous poll

Да, трекаем – 8
👍👍👍👍👍👍👍 40%

Используем только sentry или жёстко следим за логами – 7
👍👍👍👍👍👍 35%

Нет, не трекаем. Не до этого. – 5
👍👍👍👍 25%

А зачем?
▫️ 0%

👥 20 people voted so far.

Работа, как приготовление пищи

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

С работой всё тоже самое, - чем лучше настроение, тем лучше результаты.

Такой вот Капитан Очевидность. Тут можно конечно включить сарказм mode и вспомнить известные слова «Пишите, деточки, хороший код, а плохой не пишите!» Но дело не коде, - это уже следствие.

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

На больших сложных проектах/дистанциях случается всякое. "Семь пудов соли съесть", - как раз про такие проекты.

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

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

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

@maxlapshin

Максим Лапшин, получивший сегодня статуэтку Highload++ пишет про погружение в область:

Чем глубже сам развиваешься, тем сложнее услышать что-то интересное.

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

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

Рассказал про MVNx биллинг Drimsim с использованием триады Tarantool + PgSQL + Clickhouse.

С своей боли про ГОСТ и персональные данные от сервиса со взаимодействием с госбанками пишет Александр Григоров:

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

Когда работаешь с гос.клиентами, они постоянно хотят какой нибудь "дичи", то ipsec на ГОСТах, то TLS с ГОСТом... Их конечно понять можно, но почему поддержки ГОСТа 2012 нету в open source библиотеках? Только всякие там КриптоПро и иже с ними, продают либо железку, с патченным openssl и старой версией rhel, либо как КриптоПро, патченным набор софта, с гостовыми шифрами и интеграцией с их хранилищем. Мало того, что приватные ключи нельзя выгрузить без боли и страдания. То когда у вас микросервисы и есть персональные данные, то если исполнять закон, то ГОСТ обязан быть между микросервисами и базами. Ну вот ГОСТ в ssl ещё может быть, в той же postgresql, хотя не уверен в какой редакции(Oleg Bartunov Ваша редакция Postgresql имеет поддержку и сертифицировано по ГОСТу? Для хранения персональных данных)? Но когда у тебя куча другого софта, для обмена информацией, то получается, нужно и в RabbitMQ ГОСТ пихать, а трафик заходит в ingress k8s, значит и там tls соединение по ГОСТу?!

Я начинаю люто ненавидеть тех людей, которые сделали это... Я понимаю своё шифрование придумали, но блин реализовать его во всей экосистеме Unix/Linux можно же было? Многие говорят, переходить на gnutls или openssl 1.1, там типа ГОСТ есть, но есть проблема, ОС и образы которые есть, они все содержат только openssl 1.0.x. а поддерживать сотни различных видов образов, да ещё патчить и пересобрать сотни компонентов, чтобы они поддерживали ГОСТ. Но беда в том, что любой custom который сделаешь, потом нужно сертифицировать, а это время и деньги. Выходит замкнутый круг...

Хочешь выполнить требование регуляторов, то должен купить много "говна" с ГОСТом, по сути тоже самое, что и сам можешь сделать, но только платишь за коробку с бумажкой. А в этой коробке либо патченным openssl, либо stunnel, либо openvpn с ГОСТом. При этом люто старой версией и без возможности обновления... К примеру, на балансировщиках хотят nginx с http2, но там надо openssl по свежее, а тут ещё и с поддержкой ГОСТовых сертификатов...

Вообще, если читать закон, то выходит, что любой сервис который хранит или передает перс данные, обязан использовать ГОСТ шифрование. А это боль и страдания для построения хоть чего-то менее вменяемого на ГОСТах... Либо везде должны стоять железки с бумажками, а когда у тебя виртуальная среда, то страдай... В мир современный, нужно тащить Легаси в виде железок (stonegate, vipnet и тп). А тащить трафик через cisco с модулем ГОСТовым, стоит не малых денег. И я задаюсь одним вопросом: вот нахрена нашему бизнесу нужен этот ГОСТ? Если безопасности он не добавляет, никто не соблюдает. А компаниям таким как google, cloudflare, которые цоды обязаны держать в РФ и по требованиям РФ, да они с ума сойдут, от нашего "дебелизма"... Особенно со своими разработками....


Безопасникам гос банков подавай сертифицированные средства, а это либо vipnet, s-terra, застава... И всё это добро на спец железе, которое не сунуть в облако

P.s. кто как решает свои проблемы с 152-фз?

@eapotapov
Евгений Потапов, основатель IT суммы, пишет про предстоящую конференцию UPTIME

В пятницу, 23 ноября, в Москве, в Deworkacy? вновь состоится конференция SRE-специалистов и менеджеров Uptime Day.
В прошлом году участники с докладчиками из Badoo, Carprice, ITSumma, «Битрикс24», «Хабрахабра», «Делимобиля» обсуждали фатальные происшествия в ИТ-инфраструктуре.
В этот раз разговор пойдёт о работе с современными инфраструктурами. В числе спикеров:

Егор Баяндин, технический директор S7 Travel Retail, — об опыте эксплуатации VMWare CSE;

Николай Сивко, сооснователь OkMeter, — об опыте внедрения Kubernetes в OkMeter, «ручной» сборке кубика для критических требований к отказоустойчивости и мегакритических требований к простоте;

Алекс Фон Розен, CTO Проекта «Первый ЦУПИС», ООО НКО «Мобильная Карта», — об очевидных и неочевидных проблемах, возникающих при реализации SOA, а также способах решения этих проблем;

Сергей Спорышев, руководитель отдела разработки высоконагруженных проектов ITSumma, — о смене парадигмы в головах разработчиков при переходе на Kubernetes;

Антон Маркелов, инженер United Traders, — о развитии используемых в United Traders СУБД и набитых в процессе их модернизации шишках;

Иван Круглов, Principal Developer Booking-com, — об опыте использования контейнеризации и микросервисах в Booking-com;

Иван Глушко, InfraTeam TechLead, Postmates, известный многим по подкасту DevZen, — c огромным опытом использования кубика и докладом под провокационным названием «Kubernetes не нужен 90% компаний»;

Дмитрий Симонов, технический директор ДримСим, — про то, как в Drimsim создаются коннекторы к интегрированным сервисам для обеспечения отказоустойчивости и балансировки, а также замены внешних сервисов «на лету».

На конференции будет развёрнута экспертная зона: в любой момент можно будет пообщаться с Иваном Евтуховичем из Экспресс42 про внедрение девопс-практик, с уже упомянутым Николаем Сивко из OkMeter про обеспечение мониторинга, Павлом Брагиным из QRator про защиту от DDOS и Евгением Потаповым из ITSumma про обеспечение работы круглосуточной поддержки.

Участие, как всегда, бесплатное, а регистрация тут — https://clck.ru/EfZcP

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

Должен ли CTO кодить?

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

У CTO есть ресурсы - разные кодеры: бекенд, фронтенд, мобилка, аналитики... В общем каждой твари по паре. Почему по паре? Потому что заболел единственный фронтендер и работа встала, сроки поползли не только в одной команде, но в и соседних. CTO показал себя как слабый руководитель, который заранее не подстелил себе соломки, не обеспечил выбор.

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

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

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

Заболел один фронтендер, - обеспеченный выбором CTO второй фронт его "перекрыл". Здесь CTO силён.

Модная технология "показала зубы" на больших нагрузках и не оказалось ни у кого достойной экспертизы, если CTO не подумал про это заранее. Здесь CTO слаб.

Ночью "пожар" случился, - CTO или обеспечивает ночные дежурства или сам открывает консоль и тушит пожар.

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

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

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

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

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

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

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

Право выбора, - это дар богов! Само существования CTO является доказательством их существования :)

Потрясающий доклад руководителя инфраструктуры Skyeng Артём Науменко: https://www.youtube.com/watch?v=t5X1D_KVa_w