CURL WRITE-OUT JSON

В новой версии curl будет поддержка вывода в формате json.

https://daniel.haxx.se/blog/2020/03/17/curl-write-out-json

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

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

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

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

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

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

Наверное стоит еще заметить, что это тулза/клиент к чему-то. То есть мало кому интересны внутренности, главное что работает и есть новые-полезные фичи. Стоит ли ругаться, что это может поддерживать 1 человек? Спорный момент, обе стороны правдивы.

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

Understanding Raft Consensus - Part 1

https://www.micahlerner.com/2020/05/08/understanding-raft-consensus.html

#raft #cluster

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

1. Она все-таки сложна в реализации и
2. Нередко затрагивает достаточно важные бизнес-процессы в распределенной, событийной системе

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

А ведь больше половины ответов на чаще всего возникающие вопросы содержатся прям вот в том самом документе, который её и породил: https://www.cs.cornell.edu/andru/cs711/2002fa/reading/sagas.pdf

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

Кто еще не читал — must read!

​​👻 Как известно, Google и другие топовые компании мира, такие как: Linkedin, Twitter, Netflix, BMW, Samsung, UBER, Amazon используют метод постановки целей и достижения желаемых результатов — OKR. Сундар Пичаи, CEO Google, даже заявил, что благодаря OKR Google стал той компанией которую мы знаем (нет, это не про империю зла, как уже могли подумать).

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

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

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

Встречайте, стрим #2.
🔥 OKR. Опыт внедрения системы целеполагания в компаниях.

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

Наш звездный состав:
— Алексей Солнцев (CTO, Kasta, ранее известная как ModnaKasta)
— Дмитрий Гринь (CTO, Jooble)
— Евгений Пилянкевич (CEO & CTO, Cossack Labs)
— Дмитрий Меньшиков (кто бы это мог быть? 😄)

Стрим будет бесплатный и интерактивный. Вопросы уже сейчас можно и нужно задать https://app.sli.do/event/qpkn7ib3/live/questions. Вопросы во время стрима чуть ниже имеют приоритет, потому прошу задать в sli.do, а на стриме уточнения. Нам нужно подумать тоже.

Что можно вынести из ивента?
● Ознакомитесь с кейсами от 4-х разных компаний
● Поймете как работает система OKR на практике
● Сможете использовать методологию OKR для себя, команды и для достижения целей компании
● Узнаете заранее о возможных нюансах, сможете учесть все подводные камни, избежать факапов
● Получите от внедрения системе OKR только преимущества (быстрый рост, достижение результатов, синхронизация задач,мотивация команды)

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

🎥 Ссылка на стрим (жмите кнопку “Напомнить” чтобы не пропустить): https://youtu.be/NuwPzwM5tnw
🍸Чтобы не забыть, сделали и ивент в фейсбуке, чтоб напоминал:
🚀 Если вы не знаете что такое OKR, то я выложил запись и текст. В том же виде, как давал это в Авроре. Я убрал всю воду, консолидировал чужой опыт. Теперь делюсь бесплатно во имя науки!
http://dmenshikov.com/2020-04-21-okr-goal-setting-system/

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

​​🍸 Продолжение трансформации в компании. От OKR к кросс-функциональности. Часть 1.

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

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

В компании была структура где присутствовали сервисные команды. Это когда есть отдельно backend, отдельно frontend, отдельно qa, аналитики… все отдельно. Когда product manager придумывал новую задачу, то она проходила технические команды и оценивался их эстимейт. Замечу, что несколько команд проводили оценку. Вот прошло от нескольких дней до нескольких недель, оценка составлена и принимается решение какие задачи делать. Конечно, на базе эстимейта, ведь мы хотим делать те задачи, которые менее затратны и дают наибольший возможный результат.

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

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

P.S. Друзья, если вам нравится контент, то делитесь им, делитесь каналом. Это очень поддерживает и стимулирует меньше спать и больше думать и писать. Я почти год на одном и том же уровне по количеству подписчиков. Чет тут не чисто)

​​🍸 Продолжение трансформации в компании. От OKR к кросс-функциональности. Часть 2.

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

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

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

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

Посчитаем на пальцах. Продакт менеджер проводит встречи с 3 командами, дабы донести свою идею. Тратит на это N часов, включая фоллоу-апы. Если он по-отдельности проводит митинги, то потратит 3*N часов своего времени и суммарно 3*N часов тимлидов. Можно оптимизировать до одного митинга, и тогда затраты всех участников составят 4*N часов. Затем тимлид тратит время на обдумывание, может поэкспериментировать, расписывает эту задачу и доносит до конечного исполнителя. Это еще затраты на коммуникацию с конечным исполнителем. Конечно же, включается испорченный телефон и исполнитель получает не цель продакт менеджера, интерпретацию этой цели из уст тимлида, может цель вообще видоизменится и тимлид свою цель озвучит. Порой возникают трудности и выполнить желаемое не получается. Маховик начинает вращаться в обратную сторону: проходят снова митинги, выяснения что делать и согласования. Если медиатором служит тимлид, то происходит тройная трата ресурса (конечный исполнитель-тимлид, тимлид-менеджер, тимлид-исполнитель). Если еще и переписать после этого задачу придется, то это снова повторные согласования и все по кругу. Ах да, все же заняты, митинги с уточнениями происходят когда у всех есть время. Это смещает срок до получения результата, как уже писал в прошлом посте.

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

Что еще не так и есть ли выход? Об этом далее… @noTieInIT

У сообщества Women Who Code Kyiv открылась регистрация на вторую волну менторской программы. 🎉
Я сама являюсь учасницей этой программы в роли менти, и довольна всем, от выбора менторки для меня, так и нашим сотрудничеством.

Приглашаются как менти, так и менторки и менторы. Подробная информация здесь.

Написала о том, как был придуман мини-квест и вообще про Spotify-коды.
Не поверите куда написала.

https://habr.com/ru/post/518970/