Стоит ли разработчику заниматься предварительной проработкой задачи
В проектно-водопадном подходе разработчик ограничивает свою зону ответственности кодом. А код он будет писать по ТЗ, которое ему должен принести аналитик. Нет ТЗ — и результат, как грица, хз. А еще в таком подходе любимая забава разрабов — воевать против бедного системного аналитика.
Такой разраб пишет код в отрыве от понимания бизнес-ценности задачи и вектора развития продукта.
Как следствие, проблемы:
— нет драйва довести задачу до прода;
— склонность к оверинжинирингу;
— всё новые и новые рефакторинги, чтобы запилить новую фичу;
Потом в компании случается Agile-трансформация. Альтернативный вариант — сам разработчик переходит в другую компанию с гибким подходом. Так или иначе, разработчик попадает в среду, где "все должны делать всё". Волей-неволей, он подключается к предварительной проработке задачи. Сначала есть сопротивление, что мол "меня нанимали код писать, а не это вот всё".
Но потом появляется понимание бизнес-ценности задачи и стратегии продукта. Прорабатывая задачу, разработчик начинает чувствовать причастность. Это теперь его задача и его продукт. Из понимания бизнеса и причастности рождается более полезный для бизнеса код, при этом растет мотивация самого разработчика. До какого-то момента это работает прям хорошо.
И вот наступило "светлое будущее": разработчики проводят 90% рабочего времени во встречах по обсуждению задач.
Одна из ценностей Scrum — Фокус. Обычно его преподносят как фокус всех членов команды на цели спринта. Но никто не лимитирует количество задач в предварительной проработке. Владелец продукта, потирая руки, начинает закидывать в разрабов всё новые и новые гипотезы. Собираются встречи со стейкхолдерами, доуточняются требования, бизнес-постановка и критерии приемки задачи.
В итоге я уже который раз вижу ситуацию, что 20 эпиков из бэклога потроганы по чуть-чуть, но ни один не проработан до уровня "можно взять и запилить". А 15 из этих 20 эпиков протухают, так и не будучи проработанными. При этом разработчики сходят с ума от переключения контекстов, и ни о каком фокусе речь не идет.
В проработке и разработке нужен баланс. Привлекать разработчиков к проработке задачи на раннем этапе — отличная идея. Но только до тех пор, пока у них сохраняется способность разрабатывать. Тогда профиты от понимания разрабом бизнес-ценности задачи таки смогут проявиться, когда задача доедет до пользователя.
В проектно-водопадном подходе разработчик ограничивает свою зону ответственности кодом. А код он будет писать по ТЗ, которое ему должен принести аналитик. Нет ТЗ — и результат, как грица, хз. А еще в таком подходе любимая забава разрабов — воевать против бедного системного аналитика.
Такой разраб пишет код в отрыве от понимания бизнес-ценности задачи и вектора развития продукта.
Как следствие, проблемы:
— нет драйва довести задачу до прода;
— склонность к оверинжинирингу;
— всё новые и новые рефакторинги, чтобы запилить новую фичу;
Потом в компании случается Agile-трансформация. Альтернативный вариант — сам разработчик переходит в другую компанию с гибким подходом. Так или иначе, разработчик попадает в среду, где "все должны делать всё". Волей-неволей, он подключается к предварительной проработке задачи. Сначала есть сопротивление, что мол "меня нанимали код писать, а не это вот всё".
Но потом появляется понимание бизнес-ценности задачи и стратегии продукта. Прорабатывая задачу, разработчик начинает чувствовать причастность. Это теперь его задача и его продукт. Из понимания бизнеса и причастности рождается более полезный для бизнеса код, при этом растет мотивация самого разработчика. До какого-то момента это работает прям хорошо.
И вот наступило "светлое будущее": разработчики проводят 90% рабочего времени во встречах по обсуждению задач.
Одна из ценностей Scrum — Фокус. Обычно его преподносят как фокус всех членов команды на цели спринта. Но никто не лимитирует количество задач в предварительной проработке. Владелец продукта, потирая руки, начинает закидывать в разрабов всё новые и новые гипотезы. Собираются встречи со стейкхолдерами, доуточняются требования, бизнес-постановка и критерии приемки задачи.
В итоге я уже который раз вижу ситуацию, что 20 эпиков из бэклога потроганы по чуть-чуть, но ни один не проработан до уровня "можно взять и запилить". А 15 из этих 20 эпиков протухают, так и не будучи проработанными. При этом разработчики сходят с ума от переключения контекстов, и ни о каком фокусе речь не идет.
В проработке и разработке нужен баланс. Привлекать разработчиков к проработке задачи на раннем этапе — отличная идея. Но только до тех пор, пока у них сохраняется способность разрабатывать. Тогда профиты от понимания разрабом бизнес-ценности задачи таки смогут проявиться, когда задача доедет до пользователя.
Miro
Где-то весной я решил попробовать продуктовый подход к найму. Чтобы лучше проводить интервью кандидатов в QIWI, я решил сам пойти попробоваться в роли кандидата. Пошел в компании, у которых есть чему поучиться. Одной из компаний была Miro. Тогда для меня стало откровением, что компания родом из Перми ищет разработчиков и тимлидов в свой Берлинский хаб.
Стал узнавать про них больше. Пришло осознание, что ковид и удаленка стали мощнейшим бустом для этой компании. Обнаружил крутой канал @miroengineering и движуху типа статей на хабре и медиуме, митапы и всякое такое. Мне захотелось прикоснуться к прекрасному, поэтому нашел интересную вакансию и вошел в процесс. Поговорил с HR и настолько она меня вдохновила, что пошел изучать продукт и сценарии использования. Даже нашел потенциальную уязвимость типа Secrets Exposure. С радостью понёс эту находку на интервью и...
Быстро вошел, — быстро вышел, приключение на полчаса :) Короче, я завалил первый же собес, где нужно было лайвкодить алгоритмы и говорить на английском. К такому меня жизнь не готовила) Впрочем, этот фейл меня раззадорил и я пошел дальше. Прошел собесы в разные компании и понял, что очень многое зависит от интервьюеров. Компания в лице интервьюеров может так относиться к кандидатам, что даже отвергнутый всё равно будет рекомендовать её.
Этот пост — рекомендация митапа для разработчиков и тимлидов от Miro. Ко мне в ЛС пришли организаторы из JUG Ru Group с просьбой попромить его. Мне, как человеку, который не стал тимлидом в Miro, офигенно интересно, как ребята справляются с быстрым ростом распределенных команд. И вообще как оно там, внутри.
В эту среду, 8 сентября, в 18:00. Онлайн. Бесплатно.
Нужна только регистрация.
Где-то весной я решил попробовать продуктовый подход к найму. Чтобы лучше проводить интервью кандидатов в QIWI, я решил сам пойти попробоваться в роли кандидата. Пошел в компании, у которых есть чему поучиться. Одной из компаний была Miro. Тогда для меня стало откровением, что компания родом из Перми ищет разработчиков и тимлидов в свой Берлинский хаб.
Стал узнавать про них больше. Пришло осознание, что ковид и удаленка стали мощнейшим бустом для этой компании. Обнаружил крутой канал @miroengineering и движуху типа статей на хабре и медиуме, митапы и всякое такое. Мне захотелось прикоснуться к прекрасному, поэтому нашел интересную вакансию и вошел в процесс. Поговорил с HR и настолько она меня вдохновила, что пошел изучать продукт и сценарии использования. Даже нашел потенциальную уязвимость типа Secrets Exposure. С радостью понёс эту находку на интервью и...
Быстро вошел, — быстро вышел, приключение на полчаса :) Короче, я завалил первый же собес, где нужно было лайвкодить алгоритмы и говорить на английском. К такому меня жизнь не готовила) Впрочем, этот фейл меня раззадорил и я пошел дальше. Прошел собесы в разные компании и понял, что очень многое зависит от интервьюеров. Компания в лице интервьюеров может так относиться к кандидатам, что даже отвергнутый всё равно будет рекомендовать её.
Этот пост — рекомендация митапа для разработчиков и тимлидов от Miro. Ко мне в ЛС пришли организаторы из JUG Ru Group с просьбой попромить его. Мне, как человеку, который не стал тимлидом в Miro, офигенно интересно, как ребята справляются с быстрым ростом распределенных команд. И вообще как оно там, внутри.
В эту среду, 8 сентября, в 18:00. Онлайн. Бесплатно.
Нужна только регистрация.
miro.jugru.org
Miro: онбординг инженеров, рост команды и Fluent setter’ы
Участие команды в принятии решений
В июле я вышел техлидом в команду, которая "выгнала" прошлого техлида через месяц работы. Конечно, я об этом узнал еще на собеседовании, и, конечно, для меня это стало звоночком. Причин того инцидента было много, но основная — это стиль руководства. Товарищ единолично принимал решения и транслировал их команде: "Делать будем так." А команда была не согласна. То ли сам стиль вызывал такое отторжение, то ли решения были реально фиговыми, мы уже не узнаем. В общем, ко мне был запрос на самом старте: помогать принимать решения командой, но не решать за команду.
Консенсус.
Слово звучит классно, но стоит очень дорого. Чтобы принять решение, которое устроит всех и каждого, нужно проделать много работы. Затронуть все аспекты темы, поговорить о мотивах всех участников, в том числе вскрыть неявные и потом найти такое решение, которое всем подойдет. Scrum ставит высшей ценностью принятие консенсусных решений всеми участниками. Проблема в том, что если в обсуждении участвует вся команда, то это реально может затянуться.
Идеальная слаженная команда, где все друг другу доверяют, принимает решения быстро и качественно. Команда на этапе становления может утонуть во встречах, бесконечно дискутируя об одном и том же. Встречи затягиваются в том числе потому, что участники не доверяют друг другу, имеют скрытые мотивы и боятся их озвучить.
Я раньше писал, что встречи отнимают много времени у разработчиков и что для продуктивной работы нужен баланс. Баланс участия в принятии решений. В продукте все время что-то происходит и принимаются какие-то решения. Часть из них выносится на встречи. Чем больше запрос на совместное принятие решений — тем больше встреч.
Можно ходить на все-все-все встречи, беситься, что их много, что они долгие, что на них одно и то же по десять раз перетирают и что не хватает времени покодить. А можно не ходить ни на какие встречи и тупо сидеть кодить что дают. Обе крайности имеют хреновые последствия. В первом случае разработка не движется. Во втором случае разработчик может быть тотально не согласен с решением и из-за этого накодить не то или не так.
Как вариант — можно пропускать некоторые встречи. По сути, пропуская какую-то встречу, человек позволяет принять решение без него. И здесь нужно либо доверие, либо пофигизм. Потому что иначе, если кто-то не согласен с принятым решением, то это может аукнуться очень больно и очень поздно. А когда аукнется, это обесценивает работу группы на встрече и потраченное время.
Идеального универсального решения нет. В любом случае учиться договариваться друг с другом придется. Как учиться договариваться? Тоже нет рецепта, но есть отрезвляющий чеклист:
1️⃣ — Держать в голове, что на первом месте польза для продукта. Приводить аргументы в первую очередь, отталкиваясь от этого.
2️⃣ — Думать о степени важности решения. Можно ли проверить гипотезу, выкинуть и с помощью полученной информации принять новое, более качественное решение.
3️⃣ — Ставить целью принять решение всей командой, а не продавить своё мнение. Иногда даже поступиться своим мнением, и дать команде ошибиться (см. п. 2). Впоследствии может оказаться что это и не ошибка вовсе.
Если каждый пришел на встречу, чтобы продавить свою уникальную точку зрения, то принять консенсусное решение почти невозможно. Если все участники понимают эти три простых пункта и пришли на встречу, чтобы договориться, то встреча пройдет быстро и не вызовет недовольства. Со временем некоторые вопросы можно будет просто и быстро решать "по ходу", не вынося на отдельные встречи. Получается, что страдания на встречах сейчас == меньше встреч потом. Ну, при условии прогресса в умении договариваться 🙂
В июле я вышел техлидом в команду, которая "выгнала" прошлого техлида через месяц работы. Конечно, я об этом узнал еще на собеседовании, и, конечно, для меня это стало звоночком. Причин того инцидента было много, но основная — это стиль руководства. Товарищ единолично принимал решения и транслировал их команде: "Делать будем так." А команда была не согласна. То ли сам стиль вызывал такое отторжение, то ли решения были реально фиговыми, мы уже не узнаем. В общем, ко мне был запрос на самом старте: помогать принимать решения командой, но не решать за команду.
Консенсус.
Слово звучит классно, но стоит очень дорого. Чтобы принять решение, которое устроит всех и каждого, нужно проделать много работы. Затронуть все аспекты темы, поговорить о мотивах всех участников, в том числе вскрыть неявные и потом найти такое решение, которое всем подойдет. Scrum ставит высшей ценностью принятие консенсусных решений всеми участниками. Проблема в том, что если в обсуждении участвует вся команда, то это реально может затянуться.
Идеальная слаженная команда, где все друг другу доверяют, принимает решения быстро и качественно. Команда на этапе становления может утонуть во встречах, бесконечно дискутируя об одном и том же. Встречи затягиваются в том числе потому, что участники не доверяют друг другу, имеют скрытые мотивы и боятся их озвучить.
Я раньше писал, что встречи отнимают много времени у разработчиков и что для продуктивной работы нужен баланс. Баланс участия в принятии решений. В продукте все время что-то происходит и принимаются какие-то решения. Часть из них выносится на встречи. Чем больше запрос на совместное принятие решений — тем больше встреч.
Можно ходить на все-все-все встречи, беситься, что их много, что они долгие, что на них одно и то же по десять раз перетирают и что не хватает времени покодить. А можно не ходить ни на какие встречи и тупо сидеть кодить что дают. Обе крайности имеют хреновые последствия. В первом случае разработка не движется. Во втором случае разработчик может быть тотально не согласен с решением и из-за этого накодить не то или не так.
Как вариант — можно пропускать некоторые встречи. По сути, пропуская какую-то встречу, человек позволяет принять решение без него. И здесь нужно либо доверие, либо пофигизм. Потому что иначе, если кто-то не согласен с принятым решением, то это может аукнуться очень больно и очень поздно. А когда аукнется, это обесценивает работу группы на встрече и потраченное время.
Идеального универсального решения нет. В любом случае учиться договариваться друг с другом придется. Как учиться договариваться? Тоже нет рецепта, но есть отрезвляющий чеклист:
1️⃣ — Держать в голове, что на первом месте польза для продукта. Приводить аргументы в первую очередь, отталкиваясь от этого.
2️⃣ — Думать о степени важности решения. Можно ли проверить гипотезу, выкинуть и с помощью полученной информации принять новое, более качественное решение.
3️⃣ — Ставить целью принять решение всей командой, а не продавить своё мнение. Иногда даже поступиться своим мнением, и дать команде ошибиться (см. п. 2). Впоследствии может оказаться что это и не ошибка вовсе.
Если каждый пришел на встречу, чтобы продавить свою уникальную точку зрения, то принять консенсусное решение почти невозможно. Если все участники понимают эти три простых пункта и пришли на встречу, чтобы договориться, то встреча пройдет быстро и не вызовет недовольства. Со временем некоторые вопросы можно будет просто и быстро решать "по ходу", не вынося на отдельные встречи. Получается, что страдания на встречах сейчас == меньше встреч потом. Ну, при условии прогресса в умении договариваться 🙂
Привет!
Я тут вписался в программный комитет Podlodka HR Crew, которая пройдет 18-29 октября🔥
Мы два месяца готовили эту конфу, и я буду ведущим четырех сессий.
Да, это первое промо платной конфы. Но это реально труд и мы старались сделать качественный продукт.
И за промо мне никто не платил, просто я верю в это мероприятие.
Раньше я покупал билетики на Teamlead и Backend Crew не задумываясь, потому что казалось недорого.
Сейчас я побывал в шкуре ПКшника и убежден, что мероприятие стоит своих денег.
Podlodka Crew — это двухнедельные конференции с сессиями в 10:00 и в 19:00.
Конкретно эта HR Crew — для рекрутеров, тимлидов, собеседующих сеньоров, нанимающих менеджеров, деврелов и всех сочувствующих.
Во время первой недели разбираем Поиск и привлечение:
— Узнаете способы привлечения: от реферальных программ до митапов и обучающих курсов
— Научитесь смотреть на процесс глазами нанимающего менеджера
— Поймете, как эффективно описывать вакансии
На второй неделе погружаемся в Собеседования кандидатов:
— Разберетесь, сколько нужно собеседований и каких
— Поймете, как дать обратную связь кандидату и не облажаться
— Узнаете, как изнутри устроено интервью разработчика
— Послушаете про опыт One-Day-Offer от топовых компаний
А еще разберем вакансии и покекаем вместе над факапами с собеседований, которыми поделятся участники конфы.
Подарю проходку тому, кто принесет в комменты к этому посту самый забавный факап с собеседования :)
Полное расписание и билетики тут
Я тут вписался в программный комитет Podlodka HR Crew, которая пройдет 18-29 октября🔥
Мы два месяца готовили эту конфу, и я буду ведущим четырех сессий.
Да, это первое промо платной конфы. Но это реально труд и мы старались сделать качественный продукт.
И за промо мне никто не платил, просто я верю в это мероприятие.
Раньше я покупал билетики на Teamlead и Backend Crew не задумываясь, потому что казалось недорого.
Сейчас я побывал в шкуре ПКшника и убежден, что мероприятие стоит своих денег.
Podlodka Crew — это двухнедельные конференции с сессиями в 10:00 и в 19:00.
Конкретно эта HR Crew — для рекрутеров, тимлидов, собеседующих сеньоров, нанимающих менеджеров, деврелов и всех сочувствующих.
Во время первой недели разбираем Поиск и привлечение:
— Узнаете способы привлечения: от реферальных программ до митапов и обучающих курсов
— Научитесь смотреть на процесс глазами нанимающего менеджера
— Поймете, как эффективно описывать вакансии
На второй неделе погружаемся в Собеседования кандидатов:
— Разберетесь, сколько нужно собеседований и каких
— Поймете, как дать обратную связь кандидату и не облажаться
— Узнаете, как изнутри устроено интервью разработчика
— Послушаете про опыт One-Day-Offer от топовых компаний
А еще разберем вакансии и покекаем вместе над факапами с собеседований, которыми поделятся участники конфы.
Подарю проходку тому, кто принесет в комменты к этому посту самый забавный факап с собеседования :)
Полное расписание и билетики тут
podlodka.io
Онлайн-конференция Podlodka HR Crew #2
Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным проблемам HR, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
Привет! В прошлом посте я предложил написать трешовую историю с собеса в комменты и получить проходку на HR Crew. Признаю ошибку, это был слишком сложный призыв к действию :)
Предлагаю вариант попроще. Завтра, в субботу 16 окт, в 10:00 один из жмякнувших на кнопку ниже получит проходку 😉
Имя победителя появится в этом посте.
*****
Победители: Эмилька
Предлагаю вариант попроще. Завтра, в субботу 16 окт, в 10:00 один из жмякнувших на кнопку ниже получит проходку 😉
Имя победителя появится в этом посте.
*****
Победители: Эмилька
Говорить словами через рот
Раньше я писал про ретроспективы на разных этапах становления команды по Брюсу Такмену.
Хочу поговорить про выход из шторминга, улучшение взаимодействия и повышение продуктивности команды.
Всё это счастье достигается одним простым инструментом — говорить словами через рот.
Переход на следующий этап и рост продуктивности команды связаны с обратной связью. А конкретно, с количеством и качеством обратной связи. А еще с балансом корректирующей и подкрепляющей.
Я намеренно сказал корректирующая, а не негативная. Разница в конструктивности. Корректирующая — о том, что нужно поменять и как именно поменять в работе. Негативная — неконструктивная ОС о том, что плохо в работе. В худшем случае, это ОС о том, что плохо в человеке. Очень часто вместо корректирующей люди дают негативную. В шторминге обратная связь обычно либо никакая, либо негативная. А негативная и неконструктивная обратная связь — хуже, чем никакая.
При этом продуктивное поведение часто остается незамеченным, потому что "ну наконец-то нормально сделал. так и должно быть, че тут говорить то". Если давать только корректирующую обратную связь, пусть даже максимально честную и справедливую, то окружающие не поймут, ценишь ли ты хоть что-то в их работе. Если в команде никто не дает подкрепляющую ОС, а все только негативят, то может показаться, что все плохо, и что все только и делают, что ошибаются.
Получается такой самоподдерживающийся шторминг. Есть способ остановить круг негативной обратной связи.
Способ очень простой: увидеть что-то хорошее в работе коллег и подкрепить это позитивной ОС. Если делать это от души, это не будет наигранно и искусственно. Важно создать прецедент. Рассказать всем, почему это важно. Если замечать позитивные изменения, их станет больше.
Когда окружающие замечают в твоей в работе много хорошего, корректирующая обратная связь воспринимается проще.
Поэтому, если хочешь что-то менять с помощью корректирующей обратной связи, — научись сначала подкреплять позитивной 😉
Раньше я писал про ретроспективы на разных этапах становления команды по Брюсу Такмену.
Хочу поговорить про выход из шторминга, улучшение взаимодействия и повышение продуктивности команды.
Всё это счастье достигается одним простым инструментом — говорить словами через рот.
Переход на следующий этап и рост продуктивности команды связаны с обратной связью. А конкретно, с количеством и качеством обратной связи. А еще с балансом корректирующей и подкрепляющей.
Я намеренно сказал корректирующая, а не негативная. Разница в конструктивности. Корректирующая — о том, что нужно поменять и как именно поменять в работе. Негативная — неконструктивная ОС о том, что плохо в работе. В худшем случае, это ОС о том, что плохо в человеке. Очень часто вместо корректирующей люди дают негативную. В шторминге обратная связь обычно либо никакая, либо негативная. А негативная и неконструктивная обратная связь — хуже, чем никакая.
При этом продуктивное поведение часто остается незамеченным, потому что "ну наконец-то нормально сделал. так и должно быть, че тут говорить то". Если давать только корректирующую обратную связь, пусть даже максимально честную и справедливую, то окружающие не поймут, ценишь ли ты хоть что-то в их работе. Если в команде никто не дает подкрепляющую ОС, а все только негативят, то может показаться, что все плохо, и что все только и делают, что ошибаются.
Получается такой самоподдерживающийся шторминг. Есть способ остановить круг негативной обратной связи.
Способ очень простой: увидеть что-то хорошее в работе коллег и подкрепить это позитивной ОС. Если делать это от души, это не будет наигранно и искусственно. Важно создать прецедент. Рассказать всем, почему это важно. Если замечать позитивные изменения, их станет больше.
Когда окружающие замечают в твоей в работе много хорошего, корректирующая обратная связь воспринимается проще.
Поэтому, если хочешь что-то менять с помощью корректирующей обратной связи, — научись сначала подкреплять позитивной 😉
В последнее время мало пишу, но больше говорю головой.
Сегодня заканчивается Podlodka HR Crew, где я побывал в шляпах программного комитетчика, ведущего и спикера. Было круто!
По праву спикера, выкладываю в паблик запись одной из сессий :)
Треш-истории с собесов, уникальный закрытый контент!
Доступ по ссылке без регистрации и смс:
https://youtu.be/jMsII2cZwxg
Сегодня заканчивается Podlodka HR Crew, где я побывал в шляпах программного комитетчика, ведущего и спикера. Было круто!
По праву спикера, выкладываю в паблик запись одной из сессий :)
Треш-истории с собесов, уникальный закрытый контент!
Доступ по ссылке без регистрации и смс:
https://youtu.be/jMsII2cZwxg
YouTube
Разбор факапов с собеседований / Никита Хромушкин, Инесса Васильева, Александр Андронов
Мы попросили участников конференции рассказать о самых отборных их и коллег факапах на интервью. Не важно, собеседовал или собеседовался. Зашел не в ту переговорку и начал собеседовать на джависта растерявшегося дизайнера? Забыл название своего текущего места…
Привет!
В этом канале до сих пор я писал про всякие софтовые штуки. А ведь мне есть чем поделиться и по хардам.
Поэтому прямо сейчас готовлю вебинар для бесплатного курса от Слёрма и Райфа. Стартует в понедельник, 8 ноября.
https://slurm.io/from-middle-to-senior
Открываю курс темой "Работаем с базами данных PostgreSQL".
Спешу успеть, потому что Podlodka HR Crew только-только отпустила, и на всю подготовку у меня была неделя.
Признаюсь честно, очково :)
Задача амбициозная — упаковать в полтора часа весь цикл разработки БД для бэкендера.
Презентация уже на 130 слайдов, материала еще примерно на 30. Уже сомневаюсь, что влезу в полтора часа.
Прикинул тут, а ведь с PostgreSQL я уже 9 лет. И есть столько всяких приколюх, которыми хочу поделиться.
Когда-то я прочитал, что делиться знаниями, — как отдавать частичку себя другим. Это как бы горизонтальный перенос генов. Читай, размножение. Поэтому это поведение самоподкрепляется организмом.
Поэтому я чувствую мотивацию провести офигенный вебинар.
Записывайтесь. Бешплатно :)
В этом канале до сих пор я писал про всякие софтовые штуки. А ведь мне есть чем поделиться и по хардам.
Поэтому прямо сейчас готовлю вебинар для бесплатного курса от Слёрма и Райфа. Стартует в понедельник, 8 ноября.
https://slurm.io/from-middle-to-senior
Открываю курс темой "Работаем с базами данных PostgreSQL".
Спешу успеть, потому что Podlodka HR Crew только-только отпустила, и на всю подготовку у меня была неделя.
Признаюсь честно, очково :)
Задача амбициозная — упаковать в полтора часа весь цикл разработки БД для бэкендера.
Презентация уже на 130 слайдов, материала еще примерно на 30. Уже сомневаюсь, что влезу в полтора часа.
Прикинул тут, а ведь с PostgreSQL я уже 9 лет. И есть столько всяких приколюх, которыми хочу поделиться.
Когда-то я прочитал, что делиться знаниями, — как отдавать частичку себя другим. Это как бы горизонтальный перенос генов. Читай, размножение. Поэтому это поведение самоподкрепляется организмом.
Поэтому я чувствую мотивацию провести офигенный вебинар.
Записывайтесь. Бешплатно :)
Продуктовые метрики по вчерашнему вебинару
Привет. Канал то про продуктовую разработку. А продуктовая разработка — это в том числе про обратную связь. Вчерашний вебинар можно расценивать как фичу в продукте "Курс: Разработчик, или от Мидла до Сеньора." О метриках продукта пока рано говорить, а вот промежуточные метрики фичи уже есть, и я несу их вам :)
Когда создавал этот канал, для себя видел мотивацию в том, чтобы помогать людям, которым небезразлична их работа, находить что-то новое и полезное для себя. Радовался как ребенок, когда 40 человек задумались об использовании Definition of Ready и Definition of Done. Подводя промежуточные итоги вчерашнего вебинара, могу сказать, что я удивлен, ошеломлен и счастлив.
1️⃣ — В пике было 876 зрителей онлайн-трансляции. Это очень-очень много и очень-очень волнительно для меня.
2️⃣ — Сейчас ютуб пишет 6803 просмотров. Это вообще охренеть)
3️⃣ — Очень хороший график числа зрителей, отток маленький. На перерыве мы почти никого не потеряли, хотя кураторы от Слёрма меня пугали потерей 30% аудитории.
4️⃣ В канал пришло 200+ подписчиков. Привет! :)
5️⃣ 227 человек оставили подробную обратную связь через гуглоформу. Особенно радует, что каждая из затронутых тем нашла своего зрителя. Ну и конечно есть негатив от тех, кто меня раскусил и сразу понял, что я — самозванец =)
Делюсь с вами сводной таблицей ответов на гуглоформу: https://docs.google.com/spreadsheets/d/1rVp48sYBPR-52NaVO8kWUAF1czori1UPS2Qdu5MP3xM
6️⃣ Сейчас гитхаб пишет, что 248 раз склонирован репозиторий с домашкой. Надеюсь, в ней есть практическая польза. Хочу собрать обратную связь по домашке, чтобы в будущем учесть и сделать лучше и полезнее.
Поэтому просьба: пройдите анонимный трёхминутный опрос в гуглоформе: https://forms.gle/3eCNJm5pGxzbsa2FA
В комментах к этому посту обязательно поделюсь сводной таблицей и графиками ответов на эту форму.
Спасибо!☺️
Привет. Канал то про продуктовую разработку. А продуктовая разработка — это в том числе про обратную связь. Вчерашний вебинар можно расценивать как фичу в продукте "Курс: Разработчик, или от Мидла до Сеньора." О метриках продукта пока рано говорить, а вот промежуточные метрики фичи уже есть, и я несу их вам :)
Когда создавал этот канал, для себя видел мотивацию в том, чтобы помогать людям, которым небезразлична их работа, находить что-то новое и полезное для себя. Радовался как ребенок, когда 40 человек задумались об использовании Definition of Ready и Definition of Done. Подводя промежуточные итоги вчерашнего вебинара, могу сказать, что я удивлен, ошеломлен и счастлив.
1️⃣ — В пике было 876 зрителей онлайн-трансляции. Это очень-очень много и очень-очень волнительно для меня.
2️⃣ — Сейчас ютуб пишет 6803 просмотров. Это вообще охренеть)
3️⃣ — Очень хороший график числа зрителей, отток маленький. На перерыве мы почти никого не потеряли, хотя кураторы от Слёрма меня пугали потерей 30% аудитории.
4️⃣ В канал пришло 200+ подписчиков. Привет! :)
5️⃣ 227 человек оставили подробную обратную связь через гуглоформу. Особенно радует, что каждая из затронутых тем нашла своего зрителя. Ну и конечно есть негатив от тех, кто меня раскусил и сразу понял, что я — самозванец =)
Делюсь с вами сводной таблицей ответов на гуглоформу: https://docs.google.com/spreadsheets/d/1rVp48sYBPR-52NaVO8kWUAF1czori1UPS2Qdu5MP3xM
6️⃣ Сейчас гитхаб пишет, что 248 раз склонирован репозиторий с домашкой. Надеюсь, в ней есть практическая польза. Хочу собрать обратную связь по домашке, чтобы в будущем учесть и сделать лучше и полезнее.
Поэтому просьба: пройдите анонимный трёхминутный опрос в гуглоформе: https://forms.gle/3eCNJm5pGxzbsa2FA
В комментах к этому посту обязательно поделюсь сводной таблицей и графиками ответов на эту форму.
Спасибо!☺️
Есть ли смысл в индексе, если выгребаем треть таблицы?
После вебинара мне и организаторам писали, что я не прав: индекс по валюте используется даже если в запросе выгребается треть таблицы при равномерном распределении трёх валют по таблице счетов. Причем аргументировали: заполнили таблицу равномерно, сняли планы запросов, приложили скрины.
Очень круто, что вскопали так глубоко! Напомню, вопрос был: имеет ли смысл индекс по currency? Прежде, чем я признаюсь, что меня раскусили, предлагаю посмотреть план запроса. Вникать в план — как раз то, что двигает мидла в сеньора :)
Давайте посмотрим, что мы могли бы увидеть в плане.
1️⃣ Index Only Scan — Cамый производительный вариант. Это когда все нужные для запроса данные находятся в индексе (индекс по нескольким колонкам) или покрыты индексом (covering index).
2️⃣ Index Scan — Классический вариант. Поиск по индексу + доступ к таблице. Тут останавливаться не будем.
3️⃣ Sequence scan. Ну тут всё понятно, перебираем данные в таблице
4️⃣ Bitmap Index Scan + Bitmap Heap Scan. Как раз наш третий вариант. Он возможен благодаря тому что данные хранятся в куче (heap).
Если в двух словах, то это значит, что по индексу БД составит битовую карту блоков, отметит блоки содержащие нужные данные и затем просканирует эти блоки в таблице. В некоторых случаях это более эффективно, чем sequence scan. А еще это позволяет использовать несколько индексов при поиске. Короче, механика крутая.
Казалось бы, обмазаться индексами и будет Bitmap Scan с использованием всех возможных индексов на таблице) Но напомню про оверхед на обслуживание индекса, и то что Bitmap scan всё еще "чуть лучше" чем Sequence scan. Посмотрите на cost: для sequence scan он 0..56, а для bitmap heap scan 14..51.
Вот вам еще один аспект в трейд-оффе для принятия решения об использовании индекса. Решать, как всегда, вам :)
Вот статья из цикла про EXPLAIN: https://habr.com/ru/post/276973/ В ней более детально описана механика Bitmap Heap Scan с примерами.
После вебинара мне и организаторам писали, что я не прав: индекс по валюте используется даже если в запросе выгребается треть таблицы при равномерном распределении трёх валют по таблице счетов. Причем аргументировали: заполнили таблицу равномерно, сняли планы запросов, приложили скрины.
Очень круто, что вскопали так глубоко! Напомню, вопрос был: имеет ли смысл индекс по currency? Прежде, чем я признаюсь, что меня раскусили, предлагаю посмотреть план запроса. Вникать в план — как раз то, что двигает мидла в сеньора :)
Давайте посмотрим, что мы могли бы увидеть в плане.
1️⃣ Index Only Scan — Cамый производительный вариант. Это когда все нужные для запроса данные находятся в индексе (индекс по нескольким колонкам) или покрыты индексом (covering index).
2️⃣ Index Scan — Классический вариант. Поиск по индексу + доступ к таблице. Тут останавливаться не будем.
3️⃣ Sequence scan. Ну тут всё понятно, перебираем данные в таблице
4️⃣ Bitmap Index Scan + Bitmap Heap Scan. Как раз наш третий вариант. Он возможен благодаря тому что данные хранятся в куче (heap).
Если в двух словах, то это значит, что по индексу БД составит битовую карту блоков, отметит блоки содержащие нужные данные и затем просканирует эти блоки в таблице. В некоторых случаях это более эффективно, чем sequence scan. А еще это позволяет использовать несколько индексов при поиске. Короче, механика крутая.
Казалось бы, обмазаться индексами и будет Bitmap Scan с использованием всех возможных индексов на таблице) Но напомню про оверхед на обслуживание индекса, и то что Bitmap scan всё еще "чуть лучше" чем Sequence scan. Посмотрите на cost: для sequence scan он 0..56, а для bitmap heap scan 14..51.
Вот вам еще один аспект в трейд-оффе для принятия решения об использовании индекса. Решать, как всегда, вам :)
Вот статья из цикла про EXPLAIN: https://habr.com/ru/post/276973/ В ней более детально описана механика Bitmap Heap Scan с примерами.
Какая часть знаний RDBMS независима от конкретной СУБД?
Вот есть же стандарт языка SQL. Актуальная версия SQL:2016 даже включает в себя SQL/JSON, например.
Почему мы в принципе разделяем опыт разработчиков БД по самой СУБД?
Предполагаю, дело в знании подкапотки. Мало знать декларативный язык, стоит знать детали императивной реализации запроса базой данных. То, как БД будет работать с вашими данными и с вашими запросами к ним.
MS SQL, OracleDb, PostgreSQL, MySQL, — у каждой БД под капотом свой движок. Некоторые даже могут использовать разные движки для разных таблиц в одной схеме. Это приводит к разным алгоритмам обработки. И разным артефактам этой самой обработки.
Да, не всегда всё идет по плану. И тогда крутые DBD вместе с DBA начинают "дебажить" базу данных. Пытаться подкрутить её так, чтобы она работала "как надо". Прибить нужный план запроса хинтами, поменять настройки самой СУБД типа размера той или иной области памяти.
Здесь начинают работать знания специфичные для базы данных. Такие знания не всегда можно нагуглить "по ходу". Им нужно учиться у опытных коллег. Этим постом я хочу отдать должное коллеге, у которого я многому научился. Еще до удалёнки, Денис Кивилев вёл очные курсы внутри QIWI.
Денис ведет канал Oracle Developer. Многие знания релевантны для любой СУБД. В вебинаре про PostgreSQL, рассказывая об индексах и о партиционировании, я во многом опирался на знания, которые мне дал Денис. При этом у Oracle есть огромная специфика по части PL/SQL и по части внутреннего устройства. Денис подробно рассказывает и об общих темах, и о специфике Oracle. Советую подписаться.
Вот есть же стандарт языка SQL. Актуальная версия SQL:2016 даже включает в себя SQL/JSON, например.
Почему мы в принципе разделяем опыт разработчиков БД по самой СУБД?
Предполагаю, дело в знании подкапотки. Мало знать декларативный язык, стоит знать детали императивной реализации запроса базой данных. То, как БД будет работать с вашими данными и с вашими запросами к ним.
MS SQL, OracleDb, PostgreSQL, MySQL, — у каждой БД под капотом свой движок. Некоторые даже могут использовать разные движки для разных таблиц в одной схеме. Это приводит к разным алгоритмам обработки. И разным артефактам этой самой обработки.
Да, не всегда всё идет по плану. И тогда крутые DBD вместе с DBA начинают "дебажить" базу данных. Пытаться подкрутить её так, чтобы она работала "как надо". Прибить нужный план запроса хинтами, поменять настройки самой СУБД типа размера той или иной области памяти.
Здесь начинают работать знания специфичные для базы данных. Такие знания не всегда можно нагуглить "по ходу". Им нужно учиться у опытных коллег. Этим постом я хочу отдать должное коллеге, у которого я многому научился. Еще до удалёнки, Денис Кивилев вёл очные курсы внутри QIWI.
Денис ведет канал Oracle Developer. Многие знания релевантны для любой СУБД. В вебинаре про PostgreSQL, рассказывая об индексах и о партиционировании, я во многом опирался на знания, которые мне дал Денис. При этом у Oracle есть огромная специфика по части PL/SQL и по части внутреннего устройства. Денис подробно рассказывает и об общих темах, и о специфике Oracle. Советую подписаться.
Telegram
Oracle Developer👨🏻💻
🔝 канал о разработке в СУБД Oracle:
SQL, PL/SQL, оптимизация, архитектура и многое другое...
Backend-pro.ru - обучение по различным программам, связанных с backend-разработкой для ФЛ и ЮЛ.
Основатель: @denis_dbd Кивилёв Денис
Помощница: @love_flowerrr
SQL, PL/SQL, оптимизация, архитектура и многое другое...
Backend-pro.ru - обучение по различным программам, связанных с backend-разработкой для ФЛ и ЮЛ.
Основатель: @denis_dbd Кивилёв Денис
Помощница: @love_flowerrr
Сначала сказал "нет", а потом придумал, почему
Иногда я слышу, как человек отвечает резко "нет, ..", а потом задумывается и начинает формулировать, почему же его собеседник идёт нахрен вместе со своим предложением. 🤔
У разных исследователей и авторов книг по софтам есть общая концепция "быстрого" и "медленного" мышления. "Быстрое" — обезьянка по Дорофееву, Система 1 по Канеману, Лимбический/Рептильный мозг по Маклину.
Так вот. Эта первая реакция "нет" — плод "быстрого" мышления. У нас не было возможности задуматься, почему "нет". Это просто оборона. Или "бей и беги".
Сказав "Нет", мы попали в ловушку. Теперь мы вынуждены придумывать, почему "нет". А дальше вынуждены упарываться до последнего или признавать собственную неправоту (что сложнее).
У этого быстрого ответа "нет" есть более социально-одобряемая маскировка "Да, но..". Эрик Берн в книге "Игры, в которые играют люди" описал игру, основанную на ответе "Да, но .."
Каждый раз, когда вы слышите "да, но ..", — знайте: собеседник не настроен воспринимать ваши идеи.
Без этого знания вы можете обнаружить себя в "продавливания" своей идеи или в демотивации от обесценивания.
Обладая этим знанием, вы можете подумать, как помочь собеседнику настроиться на восприятие. Например, проговорить, что вы понимаете его чувства и ситуацию с его стороны. Проговорить его аргументы. "Выложить все карты на стол". Или отступить. Главное, — вы сэкономите свой ресурс.
Если вы обнаруживаете себя говорящими "нет" или "да, но..", то я вас поздравляю! Это первый шаг к эффективной коммуникации. Обнаружение и принятие дают возможность что-то поменять. Вместо подбора аргументов "почему именно нет", попробуйте подумать о том, от каких позитивных вещей вы отказываетесь, говоря "нет". Пока думаете, можете сказать "нет, ... хотя..".
А в следующий раз попробуйте просто взять паузу. От одной-двух-пяти секунд паузы ваш разговор не испортится :) Более того, к вам прислушаются. Потому что пауза говорит о том, что вы подумали, прежде чем ответить.
А пока будете думать, подумайте, что вы могли бы ответить, начиная с "Да, и ...". Как можно развить идею, которую предлагает собеседник? Показав уважение к его мнению и идее, вы можете рассчитывать на взаимность.
Иногда я слышу, как человек отвечает резко "нет, ..", а потом задумывается и начинает формулировать, почему же его собеседник идёт нахрен вместе со своим предложением. 🤔
У разных исследователей и авторов книг по софтам есть общая концепция "быстрого" и "медленного" мышления. "Быстрое" — обезьянка по Дорофееву, Система 1 по Канеману, Лимбический/Рептильный мозг по Маклину.
Так вот. Эта первая реакция "нет" — плод "быстрого" мышления. У нас не было возможности задуматься, почему "нет". Это просто оборона. Или "бей и беги".
Сказав "Нет", мы попали в ловушку. Теперь мы вынуждены придумывать, почему "нет". А дальше вынуждены упарываться до последнего или признавать собственную неправоту (что сложнее).
У этого быстрого ответа "нет" есть более социально-одобряемая маскировка "Да, но..". Эрик Берн в книге "Игры, в которые играют люди" описал игру, основанную на ответе "Да, но .."
Каждый раз, когда вы слышите "да, но ..", — знайте: собеседник не настроен воспринимать ваши идеи.
Без этого знания вы можете обнаружить себя в "продавливания" своей идеи или в демотивации от обесценивания.
Обладая этим знанием, вы можете подумать, как помочь собеседнику настроиться на восприятие. Например, проговорить, что вы понимаете его чувства и ситуацию с его стороны. Проговорить его аргументы. "Выложить все карты на стол". Или отступить. Главное, — вы сэкономите свой ресурс.
Если вы обнаруживаете себя говорящими "нет" или "да, но..", то я вас поздравляю! Это первый шаг к эффективной коммуникации. Обнаружение и принятие дают возможность что-то поменять. Вместо подбора аргументов "почему именно нет", попробуйте подумать о том, от каких позитивных вещей вы отказываетесь, говоря "нет". Пока думаете, можете сказать "нет, ... хотя..".
А в следующий раз попробуйте просто взять паузу. От одной-двух-пяти секунд паузы ваш разговор не испортится :) Более того, к вам прислушаются. Потому что пауза говорит о том, что вы подумали, прежде чем ответить.
А пока будете думать, подумайте, что вы могли бы ответить, начиная с "Да, и ...". Как можно развить идею, которую предлагает собеседник? Показав уважение к его мнению и идее, вы можете рассчитывать на взаимность.
Вебинар про Soft Skills
Привет! Сегодня в 19 часов будет мой второй вебинар в совместном курсе от Райфа и Слёрма. Буду рассказывать про Soft Skills. Курс уже близится к завершению и записаться не получится, но вебинары проходят в виде открытой трансляции на ютубе. Поэтому можно посмотреть все вебинары по запросу
Курс "Разработчик, или от Мидла до Сеньора"
Когда составлял структуру сегодняшнего вебинара, пытался придумать категоризацию навыков. Крутил их так и эдак, рисовал кружочки с пересечениями, пытался строить майндмэпы. В итоге пришел к классическим квадрантам.
На горизонтальной оси степень конкретности навыка. Те навыки, у которых есть наблюдаемые проявления, — наиболее конкретные. Например, фасилитация встреч, публичные выступления или навык проведения интервью.
Неконкретные, "размытые" навыки, у которых менее яркое внешнее проявление я назвал "базовые". Например, рефлексия. Фиг поймешь снаружи, рефлексирует ли человек. Только косвенно, по изменению его поведения, или если он сам скажет: "я тут подумал, поанализировал нашу коммуникацию и вот какие выводы сделал".
На вертикальной оси расположил степень взаимодействия с другими. Навыки "про себя" — те, для проявления которых нужен только сам человек. Допустим, та же рефлексия.
Навыки "про коммуникацию" — понятно, чтобы коммуницировать, нужна вторая сторона. Допустим, разрешение конфликтов, — это про коммуникацию.
На этих квадрантах четко прослеживается степень сложности прокачки навыка:
— Конкретные про себя проще всего;
— Конкретные про коммуникацию чуть сложнее;
— Базовые про коммуникацию уже сложно;
— Базовые про себя — вообще жесть и перевоспитание поведенческих паттернов, которые формировались десятки лет.
Поэтому и говорят, что soft skills качать сложнее, чем hard skills. Потому что перевоспитание взрослых людей это безнадежная затея.
Свои размышления про soft skills расскажу подробнее сегодня в 19:00 Мск.
Приходите!
Привет! Сегодня в 19 часов будет мой второй вебинар в совместном курсе от Райфа и Слёрма. Буду рассказывать про Soft Skills. Курс уже близится к завершению и записаться не получится, но вебинары проходят в виде открытой трансляции на ютубе. Поэтому можно посмотреть все вебинары по запросу
Курс "Разработчик, или от Мидла до Сеньора"
Когда составлял структуру сегодняшнего вебинара, пытался придумать категоризацию навыков. Крутил их так и эдак, рисовал кружочки с пересечениями, пытался строить майндмэпы. В итоге пришел к классическим квадрантам.
На горизонтальной оси степень конкретности навыка. Те навыки, у которых есть наблюдаемые проявления, — наиболее конкретные. Например, фасилитация встреч, публичные выступления или навык проведения интервью.
Неконкретные, "размытые" навыки, у которых менее яркое внешнее проявление я назвал "базовые". Например, рефлексия. Фиг поймешь снаружи, рефлексирует ли человек. Только косвенно, по изменению его поведения, или если он сам скажет: "я тут подумал, поанализировал нашу коммуникацию и вот какие выводы сделал".
На вертикальной оси расположил степень взаимодействия с другими. Навыки "про себя" — те, для проявления которых нужен только сам человек. Допустим, та же рефлексия.
Навыки "про коммуникацию" — понятно, чтобы коммуницировать, нужна вторая сторона. Допустим, разрешение конфликтов, — это про коммуникацию.
На этих квадрантах четко прослеживается степень сложности прокачки навыка:
— Конкретные про себя проще всего;
— Конкретные про коммуникацию чуть сложнее;
— Базовые про коммуникацию уже сложно;
— Базовые про себя — вообще жесть и перевоспитание поведенческих паттернов, которые формировались десятки лет.
Поэтому и говорят, что soft skills качать сложнее, чем hard skills. Потому что перевоспитание взрослых людей это безнадежная затея.
Свои размышления про soft skills расскажу подробнее сегодня в 19:00 Мск.
Приходите!
Про зарплату новых и текущих сотрудников
Обычно есть разрыв между зарплатами тех, кто уже давно работает и тех, кто пришел только что "с рынка". В большой компании нанять дорогого спеца с рынка бывает проще, чем повысить зп сотрудника до рыночной.
Почему так происходит?
1️⃣ — Рынок айти растет, спрос на айтишников превышает предложение. Поэтому срабатывает естественный механизм регулирования цены на товар.
2️⃣ — Компаниям приходится адаптировать свои процессы найма и вилки зп, чтобы продолжить нанимать.
3️⃣ — При этом внутри обычно нет процесса пересмотра зп до рыночной. Бывает индексация, бывают повышения в связи с повышением грейда. Но всегда отталкиваются от текущего уровня зп сотрудника. А рынок мог вырасти быстрее, чем сам сотрудник внутри компании. Этот же сотрудник может выйти на рынок сейчас и получить больше.
Кандидата на вакансию оценивают обычно по hard skills, реже по soft skills. При пересмотре зп внутри компании сотрудника обычно тоже оценивают в основном по хардам, и реже по софтам. На мой взгляд, несправедливо упускают одну супер-важную характеристику.
Эта характеристика — перформанс и знания предметной области. Новый сотрудник тратит первые месяцы на онбординг, чтобы выйти на нормальный уровень перформанса. Я бы сказал, что до полугода уходит у разработчика, чтобы хорошо ориентироваться в существующем продукте и окружении, его бизнес-логике и специфике.
Допустим, текущий сотрудник Вася делает работу в нормальных условиях и получает рыночную зарплату Х рублей. Рядом с ним начинает работать новый коллега Петя, такого же уровня по hard skills, и тоже за Х рублей. Такая вот идельная картина мира, хотя мы с вами знаем, что обычно Петя приходит на 1,5Х.
Одинаковая ли ценность этих двух сотрудников? Конечно, нет. В момент выхода на работу Пети, производительность команды не только не вырастет, а даже упадет раза в 2. Потому что Вася будет тратить время на онбординг.
Таким образом, компания платит 2Х за 0,5 работы. То есть, компания инвестирует 1.5Х (зп Пети и половину зп Васи) в Петю в первые месяцы и получает отдачу только через полгода. Думаю, любая компания была бы рада нанять такого Петю, который с первого дня фигачил бы так же, как будто он здесь работает уже полгода. За такого Петю можно было бы даже сразу заплатить 1.5Х.
Оглянитесь. Ваш "Петя через полгода" уже здесь. Это Вася, и он фигачит здесь и сейчас. Я считаю, у Васи есть нехилая добавочная стоимость относительно кандидата с рынка. И это экономически выглядит рационально. Так почему же вы оптимизируете процессы и вилки для найма кандидатов с рынка, но не заботитесь о том, чтобы сохранить экспертов? Возможно, экономически целесообразно оценить Васю чуть выше рынка прямо сейчас?
Нанимать людей с рынка надо. Но при этом надо не забывать о ценности текущих сотрудников.
Обычно есть разрыв между зарплатами тех, кто уже давно работает и тех, кто пришел только что "с рынка". В большой компании нанять дорогого спеца с рынка бывает проще, чем повысить зп сотрудника до рыночной.
Почему так происходит?
1️⃣ — Рынок айти растет, спрос на айтишников превышает предложение. Поэтому срабатывает естественный механизм регулирования цены на товар.
2️⃣ — Компаниям приходится адаптировать свои процессы найма и вилки зп, чтобы продолжить нанимать.
3️⃣ — При этом внутри обычно нет процесса пересмотра зп до рыночной. Бывает индексация, бывают повышения в связи с повышением грейда. Но всегда отталкиваются от текущего уровня зп сотрудника. А рынок мог вырасти быстрее, чем сам сотрудник внутри компании. Этот же сотрудник может выйти на рынок сейчас и получить больше.
Кандидата на вакансию оценивают обычно по hard skills, реже по soft skills. При пересмотре зп внутри компании сотрудника обычно тоже оценивают в основном по хардам, и реже по софтам. На мой взгляд, несправедливо упускают одну супер-важную характеристику.
Эта характеристика — перформанс и знания предметной области. Новый сотрудник тратит первые месяцы на онбординг, чтобы выйти на нормальный уровень перформанса. Я бы сказал, что до полугода уходит у разработчика, чтобы хорошо ориентироваться в существующем продукте и окружении, его бизнес-логике и специфике.
Допустим, текущий сотрудник Вася делает работу в нормальных условиях и получает рыночную зарплату Х рублей. Рядом с ним начинает работать новый коллега Петя, такого же уровня по hard skills, и тоже за Х рублей. Такая вот идельная картина мира, хотя мы с вами знаем, что обычно Петя приходит на 1,5Х.
Одинаковая ли ценность этих двух сотрудников? Конечно, нет. В момент выхода на работу Пети, производительность команды не только не вырастет, а даже упадет раза в 2. Потому что Вася будет тратить время на онбординг.
Таким образом, компания платит 2Х за 0,5 работы. То есть, компания инвестирует 1.5Х (зп Пети и половину зп Васи) в Петю в первые месяцы и получает отдачу только через полгода. Думаю, любая компания была бы рада нанять такого Петю, который с первого дня фигачил бы так же, как будто он здесь работает уже полгода. За такого Петю можно было бы даже сразу заплатить 1.5Х.
Оглянитесь. Ваш "Петя через полгода" уже здесь. Это Вася, и он фигачит здесь и сейчас. Я считаю, у Васи есть нехилая добавочная стоимость относительно кандидата с рынка. И это экономически выглядит рационально. Так почему же вы оптимизируете процессы и вилки для найма кандидатов с рынка, но не заботитесь о том, чтобы сохранить экспертов? Возможно, экономически целесообразно оценить Васю чуть выше рынка прямо сейчас?
Нанимать людей с рынка надо. Но при этом надо не забывать о ценности текущих сотрудников.
💯2❤1
Data-driven итоги года
Откопал свой план развития на 2021. Делюсь сокровенным :)
Вообще я должен был его пересмотреть и актуализировать летом. Но летом случилась смена работы и меня завалило. Тем не менее, смотрю сейчас в этот ИПР после долгого перерыва и радуюсь.
Hard Skills
🔧— Получилось прокачать JVM + Spring "на восьмерочку". Оценка вполне объективная, ее дали интервьюеры. Чуть позже я получил офферы на тимлида в Тинькофф и на техлида в Райф.
🔧— С NoSQL чуть похуже, хотя на тех же интервью оценили неплохо. Была задача, где прям погрузился в специфику, начитался статей и наобщался с экспертами, благодаря чему осознанно и аргументированно выбрали Cassandra вместо PgSQL и CockroachDB.
Soft Skills
Тут я объединю в группы, потому что одно тянет за собой другое.
💡— Развитие других, менторство + Эмпатия. Считаю, получилось неплохо качнуть. С несколькими разработчиками составил ИПР и в формате менторства прошли по ним. Эмпатию и активное слушание очень хорошо получилось прокачать, когда помогал команде решать некоторые внутренние конфликтики. 1-1 с каждым раз в неделю по полчаса — польза не только для команды, но и для меня в плане прокачки этого навыка.
💡— Системное мышление, Понимание процессов продуктовой разработки
1. Получилось поучаствовать в трансформации нескольких процессов в QIWI, замечая системные проблемы и аргументируя способы их решения. Аналогично и в Райфе, но пока я больше на этапе сбора информации и понимания других процессов продуктовой разработки.
2. Этот канал. Это офигенный способ отрефлексировать, структурировать свои мысли, прийти к умозаключениям.
💡— Презентационные навыки. Персональный бренд.
Очень сложно оценивать объективно. В этом помогает обратная связь после вебинаров на Слёрме. Кстати, пост с метриками второго вебинара я так и не опубликовал. Обещаю исправиться в ближайшие пару недель.
В общем, я и мечтать не мог о суммарном охвате двух вебинаров в 15к просмотров и 500+ отзывах в гуглоформе.
А еще ведь есть сезон Podlodka HR Crew, который я провел в составе ПК.
А еще было выступление о продуктовой разработке на оффлайновой QIWI Server Party.
А еще мы провели онлайн OpenSpace митап на базе этого канала!
А еще несколько внутренних митапов в QIWI и Райфе.
А еще я провел для внешней компании обучение инженерным практикам на стыке JVM-бэка и PgSQL (хозяйке на заметку :)
💎Про этот канал
Я завел его осознанно, с целью прокачать системное мышление, понимание продуктовой разработки, презентационные навыки (текстовую коммуникацию) и персональный бренд.
Первые посты начал прописывать ровно год назад. Создал канал, наполнил 10 постами. Попросил обратную связь у авторов больших каналов. Переписал 10 постов, и начал привлекать аудиторию. Первой сотней были коллеги из QIWI. Спасибо, вы навсегда в моем сердечке :) А еще спасибо всем, кто давал обратную связь на посты перед публикацией и всем коллабам! На картинке к посту метрики канала, и они значительно выше моих ожиданий год назад.
План по аудитории я перевыполнил на 40%. Платное привлечение довольно хреново работает, особенно на маленьком канале. С помощью рекламы у меня получилось привлечь около 300 подписчиков, и последнюю рекламу я давал 23 марта. На отметке 500 подписчиков я перестал давать рекламу. Дальше — органический рост и взаимопосты с другими каналами. Самый большой эффект дали вебинары на Слёрме. +400 подписчиков, это считай треть всей аудитории. Надо бы подготовить подборку зашедших постов про продуктовую разработку.
Итог и пожелания
Плыть по течению или грести — выбор за каждым. Раньше я плыл по течению и в целом было норм. В какой-то момент захотелось проверить, что будет если грести целенаправленно. Мне понравилось. Оказалось, что можно ускориться и достичь большего.
Желаю осознанности в 2022. Прокачать то, что хочется прокачать. Составить план развития, включить в него и Hard Skills и Soft Skills. Идти по этому плану, актуализировать и корректировать его (а не как я), и в следующем декабре оглянуться на год назад, посмотреть на свой план, и сказать себе: "Да, оно того стоило".
Откопал свой план развития на 2021. Делюсь сокровенным :)
Вообще я должен был его пересмотреть и актуализировать летом. Но летом случилась смена работы и меня завалило. Тем не менее, смотрю сейчас в этот ИПР после долгого перерыва и радуюсь.
Hard Skills
🔧— Получилось прокачать JVM + Spring "на восьмерочку". Оценка вполне объективная, ее дали интервьюеры. Чуть позже я получил офферы на тимлида в Тинькофф и на техлида в Райф.
🔧— С NoSQL чуть похуже, хотя на тех же интервью оценили неплохо. Была задача, где прям погрузился в специфику, начитался статей и наобщался с экспертами, благодаря чему осознанно и аргументированно выбрали Cassandra вместо PgSQL и CockroachDB.
Soft Skills
Тут я объединю в группы, потому что одно тянет за собой другое.
💡— Развитие других, менторство + Эмпатия. Считаю, получилось неплохо качнуть. С несколькими разработчиками составил ИПР и в формате менторства прошли по ним. Эмпатию и активное слушание очень хорошо получилось прокачать, когда помогал команде решать некоторые внутренние конфликтики. 1-1 с каждым раз в неделю по полчаса — польза не только для команды, но и для меня в плане прокачки этого навыка.
💡— Системное мышление, Понимание процессов продуктовой разработки
1. Получилось поучаствовать в трансформации нескольких процессов в QIWI, замечая системные проблемы и аргументируя способы их решения. Аналогично и в Райфе, но пока я больше на этапе сбора информации и понимания других процессов продуктовой разработки.
2. Этот канал. Это офигенный способ отрефлексировать, структурировать свои мысли, прийти к умозаключениям.
💡— Презентационные навыки. Персональный бренд.
Очень сложно оценивать объективно. В этом помогает обратная связь после вебинаров на Слёрме. Кстати, пост с метриками второго вебинара я так и не опубликовал. Обещаю исправиться в ближайшие пару недель.
В общем, я и мечтать не мог о суммарном охвате двух вебинаров в 15к просмотров и 500+ отзывах в гуглоформе.
А еще ведь есть сезон Podlodka HR Crew, который я провел в составе ПК.
А еще было выступление о продуктовой разработке на оффлайновой QIWI Server Party.
А еще мы провели онлайн OpenSpace митап на базе этого канала!
А еще несколько внутренних митапов в QIWI и Райфе.
А еще я провел для внешней компании обучение инженерным практикам на стыке JVM-бэка и PgSQL (хозяйке на заметку :)
💎Про этот канал
Я завел его осознанно, с целью прокачать системное мышление, понимание продуктовой разработки, презентационные навыки (текстовую коммуникацию) и персональный бренд.
Первые посты начал прописывать ровно год назад. Создал канал, наполнил 10 постами. Попросил обратную связь у авторов больших каналов. Переписал 10 постов, и начал привлекать аудиторию. Первой сотней были коллеги из QIWI. Спасибо, вы навсегда в моем сердечке :) А еще спасибо всем, кто давал обратную связь на посты перед публикацией и всем коллабам! На картинке к посту метрики канала, и они значительно выше моих ожиданий год назад.
План по аудитории я перевыполнил на 40%. Платное привлечение довольно хреново работает, особенно на маленьком канале. С помощью рекламы у меня получилось привлечь около 300 подписчиков, и последнюю рекламу я давал 23 марта. На отметке 500 подписчиков я перестал давать рекламу. Дальше — органический рост и взаимопосты с другими каналами. Самый большой эффект дали вебинары на Слёрме. +400 подписчиков, это считай треть всей аудитории. Надо бы подготовить подборку зашедших постов про продуктовую разработку.
Итог и пожелания
Плыть по течению или грести — выбор за каждым. Раньше я плыл по течению и в целом было норм. В какой-то момент захотелось проверить, что будет если грести целенаправленно. Мне понравилось. Оказалось, что можно ускориться и достичь большего.
Желаю осознанности в 2022. Прокачать то, что хочется прокачать. Составить план развития, включить в него и Hard Skills и Soft Skills. Идти по этому плану, актуализировать и корректировать его (а не как я), и в следующем декабре оглянуться на год назад, посмотреть на свой план, и сказать себе: "Да, оно того стоило".
🎉17👍11🔥8
Cassandra vs. PostgreSQL
Я люблю PostgreSQL и всем рассказываю о том, какая это универсальная СУБД с инструментами и расширениями на все случаи жизни. И когда встает вопрос хранения, в первую очередь всегда думаю о PgSQL.
Но бывают специфичные кейсы, которые можно на PgSQL, но с оговорками, и количество оговорок заставляет задуматься об альтернативах.
Расскажу про один из таких кейсов в формате "Условие" - "Сравнение двух СУБД".
1️⃣ Условие – Одна табличка без связей и логики. Одна запись на один платёж. Платежей – миллионы в сутки. При этом реляционная модель и транзакционность не нужны.
Внутреннее устройство реляционных СУБД здесь будет скорее мешать. Движок MVCC ничем не пригодится и скорее создаст проблемы. Миллионы записей в сутки очень быстро приведут к деградации на одной таблице, нужно делить данные между таблицами. В PgSQL администрировать партиционирование или шардирование нужно самим, и это еще одна механика, за которой нужно следить.
Вы не подумайте, что в Cassandra можно хранить только одну таблицу) Просто такой кейс. Ограничение Cassandra – отсутсвтие JOINов. Поэтому приветствуется денормализация данных, чтобы доставать всё из одной таблицы. Подробнее о проектировании структуры хранения в Cassandra: https://cassandra.apache.org/doc/latest/cassandra/data_modeling/data_modeling_rdbms.html
А такой объем данных – не много, и из коробки есть обязательное шардирование между нодами, которое называется там партиционированием).
2️⃣ Условие – Нужны самые быстрые вставка и чтение, которые только возможны. При этом данные – критичные и могут повлиять на конверсию платёжной формы. Читай, платежи ходить не будут, если потеряется.
Аналогично предыдущему пункту, MVCC будет скорее мешать. А синхронная репликация между датацентрами даст лишнюю задержку на записи.
Cassandra позволяет управлять балансом скорости и надёжности. Можно указать уровень консистентности при вставке и чтении. Указывая
Читать будем через 10 секунд, максимум сутки после вставки.
За это время данные точно разлетятся по всему кластеру и читать их можно откуда быстрее.
3️⃣ Условие – Читать будем только по первичному ключу.
Это ограничение Cassandra, и в этом кейсе мы по нему проходим. Вообще очень важно понимать ограничения, мне в этом помогла статья коллеги на хабре: https://habr.com/ru/company/qiwi/blog/486800/
4️⃣ Условие – Повторное чтение данных не нужно. То есть данные одноразовые. А старые данные будут мешать и со временем приведут к деградации системы. Надо их как-то чистить.
А в Cassandra есть встроенная механика TTL (Time To Live) записей. Можно прямо при вставке указать, типа INSERT
Итог
Выбрали Cassandra, потому что она автоматом решает проблемы, которые нужно было бы решать руками на PgSQL.
Признаюсь, я хотел попробовать Cassandra, и это было в моем ИПР. Но я не тащил её в первую попавшуюся задачу, а дождался подходящей, поисследовал вопрос, пообщался с экспертами, выписал аргументы за и против, презентовал команде и мы все вместе приняли это решение.
С момента запуска прошло время и я уже полгода работаю в другой компании, поэтому прежде чем писать пост спросил у ребят, как оно.
Ответ: "Вроде всё отлично, проблем никаких не было) Качественно довольно запедалили"
Я люблю PostgreSQL и всем рассказываю о том, какая это универсальная СУБД с инструментами и расширениями на все случаи жизни. И когда встает вопрос хранения, в первую очередь всегда думаю о PgSQL.
Но бывают специфичные кейсы, которые можно на PgSQL, но с оговорками, и количество оговорок заставляет задуматься об альтернативах.
Расскажу про один из таких кейсов в формате "Условие" - "Сравнение двух СУБД".
1️⃣ Условие – Одна табличка без связей и логики. Одна запись на один платёж. Платежей – миллионы в сутки. При этом реляционная модель и транзакционность не нужны.
Внутреннее устройство реляционных СУБД здесь будет скорее мешать. Движок MVCC ничем не пригодится и скорее создаст проблемы. Миллионы записей в сутки очень быстро приведут к деградации на одной таблице, нужно делить данные между таблицами. В PgSQL администрировать партиционирование или шардирование нужно самим, и это еще одна механика, за которой нужно следить.
Вы не подумайте, что в Cassandra можно хранить только одну таблицу) Просто такой кейс. Ограничение Cassandra – отсутсвтие JOINов. Поэтому приветствуется денормализация данных, чтобы доставать всё из одной таблицы. Подробнее о проектировании структуры хранения в Cassandra: https://cassandra.apache.org/doc/latest/cassandra/data_modeling/data_modeling_rdbms.html
А такой объем данных – не много, и из коробки есть обязательное шардирование между нодами, которое называется там партиционированием).
2️⃣ Условие – Нужны самые быстрые вставка и чтение, которые только возможны. При этом данные – критичные и могут повлиять на конверсию платёжной формы. Читай, платежи ходить не будут, если потеряется.
Аналогично предыдущему пункту, MVCC будет скорее мешать. А синхронная репликация между датацентрами даст лишнюю задержку на записи.
Cassandra позволяет управлять балансом скорости и надёжности. Можно указать уровень консистентности при вставке и чтении. Указывая
LOCAL_QUORUM при вставке, мы получаем достаточную надёжность записи на несколько нод в кластере, при этом избегаем сетевой задержки между датацентрами.Читать будем через 10 секунд, максимум сутки после вставки.
За это время данные точно разлетятся по всему кластеру и читать их можно откуда быстрее.
3️⃣ Условие – Читать будем только по первичному ключу.
Это ограничение Cassandra, и в этом кейсе мы по нему проходим. Вообще очень важно понимать ограничения, мне в этом помогла статья коллеги на хабре: https://habr.com/ru/company/qiwi/blog/486800/
4️⃣ Условие – Повторное чтение данных не нужно. То есть данные одноразовые. А старые данные будут мешать и со временем приведут к деградации системы. Надо их как-то чистить.
DELETE в PgSQL – не лучшая идея, хотя и возможная. Типа, чистить сразу после прочтения. Но фактически это лишняя нагрузка на запись и необходимость последующего vacuum (сборки мусора). Поэтому мы решали бы эту задачу с помощью партиционирования и дропа старых партиций.А в Cassandra есть встроенная механика TTL (Time To Live) записей. Можно прямо при вставке указать, типа INSERT
... USING TTL 1800. Есть свои нюансы у этой механики, но подкупает факт, что она предусмотрена из коробки.Итог
Выбрали Cassandra, потому что она автоматом решает проблемы, которые нужно было бы решать руками на PgSQL.
Признаюсь, я хотел попробовать Cassandra, и это было в моем ИПР. Но я не тащил её в первую попавшуюся задачу, а дождался подходящей, поисследовал вопрос, пообщался с экспертами, выписал аргументы за и против, презентовал команде и мы все вместе приняли это решение.
С момента запуска прошло время и я уже полгода работаю в другой компании, поэтому прежде чем писать пост спросил у ребят, как оно.
Ответ: "Вроде всё отлично, проблем никаких не было) Качественно довольно запедалили"
Хабр
Cassandra. Как не умереть, если знаешь только Oracle
Привет, Хабр. Меня зовут Миша Бутримов, я хотел бы хотел немного рассказать про Cassandra. Мой рассказ будет полезен тем, кто никогда не сталкивался с NoSQL-баз...
👍16🔥5
Подборка постов про процессы и артефакты продуктовой разработки
Привет! Как и обещал, делаю подборку стареньких, но актуальных постов в этом канале.
Когда писал подборку, понял что стоит сконцентрироваться на какой-то общей теме.
В этот раз — подборка про цикл продуктовой разработки: процессы, чеклисты и таблички.
📜Откуда появляются задачи — Проработка бэклога
Как понять, что задача проработана — Definition Of Ready (for Sprint)
📜Что значит ”Задача сделана” — Когда заканчивается работа разработчика
Как всем одинаково это понять — Чеклист Definition Of Done
📜Ревью спринта, отличие от демо
📜Три лайфхака к ретроспективе
📜Почему техдолг называют долгом и как это объяснить бизнесу.
2 поста про техдолг — Технический долг — как кредит
2 поста, как поступательно бороться с техдолгом — Как совмещать бизнесовые фичи и развитие инженерки с разгребанием техдолга
📜 Как понять, кто есть кто в команде — StarMap — карта компетенций команды
📜 Как мы составляли StarMap, Definition of Ready, Definition of Done — фреймворк встречи
Привет! Как и обещал, делаю подборку стареньких, но актуальных постов в этом канале.
Когда писал подборку, понял что стоит сконцентрироваться на какой-то общей теме.
В этот раз — подборка про цикл продуктовой разработки: процессы, чеклисты и таблички.
📜Откуда появляются задачи — Проработка бэклога
Как понять, что задача проработана — Definition Of Ready (for Sprint)
📜Что значит ”Задача сделана” — Когда заканчивается работа разработчика
Как всем одинаково это понять — Чеклист Definition Of Done
📜Ревью спринта, отличие от демо
📜Три лайфхака к ретроспективе
📜Почему техдолг называют долгом и как это объяснить бизнесу.
2 поста про техдолг — Технический долг — как кредит
2 поста, как поступательно бороться с техдолгом — Как совмещать бизнесовые фичи и развитие инженерки с разгребанием техдолга
📜 Как понять, кто есть кто в команде — StarMap — карта компетенций команды
📜 Как мы составляли StarMap, Definition of Ready, Definition of Done — фреймворк встречи
Telegram
Product Developer
Discovery vs Delivery, ч.1
Что если разработчик будет не только кодить? Как встроить проработку задач в рабочий процесс разработчика?
В серии из 3 постов расскажу о процессе и профитах для продукта и самого разраба.
Процесс проработки бэклога не очень…
Что если разработчик будет не только кодить? Как встроить проработку задач в рабочий процесс разработчика?
В серии из 3 постов расскажу о процессе и профитах для продукта и самого разраба.
Процесс проработки бэклога не очень…
👍16❤1
Про взаимодействие разработчиков внутри команды
Каждое утро наша команда собирается и каждый рассказывает, что делал вчера и что будет делать сегодня. Один разработчик провел эксперимент: на дейли он говорил не связанные по смыслу вещи. Из 10 человек заметили двое. Возникает резонный вопрос: если друг друга никто не слушает, зачем это нужно?
...
Когда-то я сходил на оффлайновые тогда еще тренинги по скраму, и стал повсюду в работе видеть неидеальность процессов. Я хотел построить коллаборацию, совместное принятие решений и работу в команде. Но каждый раз в попытке приблизиться к этому идеальному миру, что-то ломалось и случался диссонанс. Так происходило потому что работа разработчиков была скорее индивидуальной, а не общей. Не было объединяющей цели спринта.
Потом пришло понимание, что совместная работа не особо нужна, если в спринте 10 разных задач, не объединенных общей целью. Зачем на дейли вникать в работу коллеги, если у самого и так голова от своей задачи пухнет? Да и помочь вроде бы особо не можешь: погружаться в контекст дольше. Какой тогда смысл от дейли? Вот и получается, что все говорят в формате отчетности, что вчера делали и что сегодня будут. А кому эта отчетность нужна — непонятно. Вроде бы и так все взрослые люди и потребности в контроле нет.
Стали просить продакта больших амбициозных задач. Таких, чтобы можно было распараллелить работу и сделать командой значительно больше, чем мог бы сделать один. С одной стороны, это как будто подстраивание продукта под фреймворк и пожелания разработчиков. С другой стороны, кайфа от работы стало в разы больше, и полезных штук делать мы стали больше.
Попробую объяснить, почему большая общая задача решает проблему коммуникации внутри команды.
Сначала большой эпик нужно декомпозировать на такие этапы, чтобы каждый спринт был инкремент для пользователя. Потом этап нарезается в бэклог спринта. В идеале распараллелить доработку компонентов так, чтобы все были при деле. И потом интегрировать результат работы друг друга, сшивая компоненты. Чтобы нормально интегрироваться, нужно понимать, что там коллега разрабатывает.
Когда есть общая цель и предстоит интегрироваться с работой товарища, становится интересно, что там у него происходит. Причем иногда настолько, что вся инфа уже есть до дейли. Тогда вопрос, а нафига говорить, что делал вчера и что будешь делать сегодня, если все и так знают, потому что вчера вечером созванивались?
...
Мой идеал дейли — когда все и так знают, кто чего делает, а на дейли приходят, чтобы задать друг другу простой вопрос:
"Мы успеваем по цели спринта?"
Каждое утро наша команда собирается и каждый рассказывает, что делал вчера и что будет делать сегодня. Один разработчик провел эксперимент: на дейли он говорил не связанные по смыслу вещи. Из 10 человек заметили двое. Возникает резонный вопрос: если друг друга никто не слушает, зачем это нужно?
...
Когда-то я сходил на оффлайновые тогда еще тренинги по скраму, и стал повсюду в работе видеть неидеальность процессов. Я хотел построить коллаборацию, совместное принятие решений и работу в команде. Но каждый раз в попытке приблизиться к этому идеальному миру, что-то ломалось и случался диссонанс. Так происходило потому что работа разработчиков была скорее индивидуальной, а не общей. Не было объединяющей цели спринта.
Потом пришло понимание, что совместная работа не особо нужна, если в спринте 10 разных задач, не объединенных общей целью. Зачем на дейли вникать в работу коллеги, если у самого и так голова от своей задачи пухнет? Да и помочь вроде бы особо не можешь: погружаться в контекст дольше. Какой тогда смысл от дейли? Вот и получается, что все говорят в формате отчетности, что вчера делали и что сегодня будут. А кому эта отчетность нужна — непонятно. Вроде бы и так все взрослые люди и потребности в контроле нет.
Стали просить продакта больших амбициозных задач. Таких, чтобы можно было распараллелить работу и сделать командой значительно больше, чем мог бы сделать один. С одной стороны, это как будто подстраивание продукта под фреймворк и пожелания разработчиков. С другой стороны, кайфа от работы стало в разы больше, и полезных штук делать мы стали больше.
Попробую объяснить, почему большая общая задача решает проблему коммуникации внутри команды.
Сначала большой эпик нужно декомпозировать на такие этапы, чтобы каждый спринт был инкремент для пользователя. Потом этап нарезается в бэклог спринта. В идеале распараллелить доработку компонентов так, чтобы все были при деле. И потом интегрировать результат работы друг друга, сшивая компоненты. Чтобы нормально интегрироваться, нужно понимать, что там коллега разрабатывает.
Когда есть общая цель и предстоит интегрироваться с работой товарища, становится интересно, что там у него происходит. Причем иногда настолько, что вся инфа уже есть до дейли. Тогда вопрос, а нафига говорить, что делал вчера и что будешь делать сегодня, если все и так знают, потому что вчера вечером созванивались?
...
Мой идеал дейли — когда все и так знают, кто чего делает, а на дейли приходят, чтобы задать друг другу простой вопрос:
"Мы успеваем по цели спринта?"
👍38🔥20
Продукт vs проект, и в чем разница для разработчика.
Представим проект по постройке дома на заказ. Есть чертежи, есть план работ, сроки. Всё посчитано, всё оптимально. Берешь ресурсы, делаешь по плану, в срок сдаешь дом. Звучит просто.
На деле все проекты едут по срокам, а дом в итоге получается не совсем таким, как его задумывали. И когда дом сдадут, внезапно окажется, что по соседству построили дом для сдачи в аренду посуточно, и там каждый вечер тусовки. Это я веду к тому, что за время проекта может произойти столько всего, что по итогу результат проекта может быть уже никому не нужен.
В продуктовом подходе сначала быстро делают бытовку и в ней сразу начинают жить. Потом, если оказывается что жить здесь можно, бытовку начинают перестраивать. В новой версии учитывают специфику местности. Например, добавляют теплоизоляцию и отопление. И так итерациями улучшают, делая более подходящим под изменяющиеся условия. Если рядом построили дом с вечеринками, можно добавить нашему дому шумоизоляции в новой версии.
Что это значит для разработчика?
В проекте есть начало и конец. Обычно стараются пилить проект одной командой от начала и до конца. Редко донабирают разрабов в середине. Это значит, что в большинстве случаев это green field, возможность начать с нуля, спроектировать красивую архитектуру и заложить инженерные практики, которые сберегут время в конце проекта, когда сроки будут гореть. Ну а если что-то не совсем правильно спроектировали, то часто выбирают вариант не переделывать, а довести проект до конца и переключиться на следующий.
В продукт постоянно приходят новые разработчики и уходят старые. Ротация кадров для продукта — нормальное явление. Приходя в продукт, надо быть готовым иметь дело с легаси. Потому что оно приносит деньги. И нужно уметь дорабатывать легаси и строить рядом с ним новые направления. И при построении чего-то нового нужно уметь заложить архитектуру и инженерные практики такие, чтобы не испытывать проблем, когда это станет легаси. У продукта нет конца как у проекта, поэтому разработчики имеют дело со своим же легаси через год-два-пять.
Поэтому в продукте так важно «правило бойскаута»:
Представим проект по постройке дома на заказ. Есть чертежи, есть план работ, сроки. Всё посчитано, всё оптимально. Берешь ресурсы, делаешь по плану, в срок сдаешь дом. Звучит просто.
На деле все проекты едут по срокам, а дом в итоге получается не совсем таким, как его задумывали. И когда дом сдадут, внезапно окажется, что по соседству построили дом для сдачи в аренду посуточно, и там каждый вечер тусовки. Это я веду к тому, что за время проекта может произойти столько всего, что по итогу результат проекта может быть уже никому не нужен.
В продуктовом подходе сначала быстро делают бытовку и в ней сразу начинают жить. Потом, если оказывается что жить здесь можно, бытовку начинают перестраивать. В новой версии учитывают специфику местности. Например, добавляют теплоизоляцию и отопление. И так итерациями улучшают, делая более подходящим под изменяющиеся условия. Если рядом построили дом с вечеринками, можно добавить нашему дому шумоизоляции в новой версии.
Что это значит для разработчика?
В проекте есть начало и конец. Обычно стараются пилить проект одной командой от начала и до конца. Редко донабирают разрабов в середине. Это значит, что в большинстве случаев это green field, возможность начать с нуля, спроектировать красивую архитектуру и заложить инженерные практики, которые сберегут время в конце проекта, когда сроки будут гореть. Ну а если что-то не совсем правильно спроектировали, то часто выбирают вариант не переделывать, а довести проект до конца и переключиться на следующий.
В продукт постоянно приходят новые разработчики и уходят старые. Ротация кадров для продукта — нормальное явление. Приходя в продукт, надо быть готовым иметь дело с легаси. Потому что оно приносит деньги. И нужно уметь дорабатывать легаси и строить рядом с ним новые направления. И при построении чего-то нового нужно уметь заложить архитектуру и инженерные практики такие, чтобы не испытывать проблем, когда это станет легаси. У продукта нет конца как у проекта, поэтому разработчики имеют дело со своим же легаси через год-два-пять.
Поэтому в продукте так важно «правило бойскаута»:
«оставь место стоянки чище, чем оно было до твоего прихода». Чистка не обязательно должна быть глобальной, достаточно почистить хотя бы небольшой кусок кода, режущий глаз.
© Роберт Мартин👍31🔥5
Разработчик — больше чем профессиональный кодер
Я программист и я ненавижу встречи — с такой установкой я довольно долго жил. Десять черных квадратиков собрались, побухтели и разошлись. Встречи без четкой агенды, без плана, без цели, без итогов, без визуализации и без камер. Ууу аж трясёт!
Многие встречи могли бы быть письмом. Но есть такие ситуации, которые текстом сложнее и дольше. Например, когда нужно экстренно что-то поправить. Или когда тема слишком неизвестная и нужно побрейнштормить. Или когда нужно чтобы все высказали свое мнение и принять совместное решение. Короче, встречи были, есть и будут, как бы я к ним не относился.
Потом я понял, почему ненавижу встречи. Помните мем "я ограничен технологиями своего времени"? Так и мы. Пока не сделали нейролинк, нам приходится говорить словами через рот. А это ужасно долго. А еще разные люди почему-то понимают одни и те же слова по-разному. А еще кто-то много говорит одно и то же по кругу, а другие отмалчиваются. А еще кто-то обижается, но не понятно на что. А когда все без камер, вообще хрен поймёшь, что там у кого в голове. В общем, разные странности-сложности.
А потом я понял, что раз от встреч никуда не деться, и что это тоже моя работа, то надо быть в этом профессионалом. В продукте профессиональный разработчик — не только профессионально пишет код, но и общается. Доносит свои мысли аргументированно и открыто. Задает вопросы по сути, проясняя нужную информацию. Аппелирует к пользе для продукта при спорах. Не отклоняется от цели коммуникации.
Оказалось, что люди сильно раньше меня поняли, что коммуникация тоже должна быть профессиональной. И что есть целый навык профессионального проведения встреч — фасилитация. Оказывается, на встрече может быть специальный человек, который следит, чтобы все высказались и не отклонялись от темы встречи. А еще создает рабочую атмосферу, управляет неконструктивным поведением, вовлекает каждого участника и поддерживает энергию в группе.
Казалось бы, завести в команде фасилитатора и проблема решена. В чем профессионализм и при чем тут разработчик?
А при том. Чем больше фасилитатору приходится вмешиваться и останавливать кого-то или передавать слово, тем больше оверхед встречи. Если сами участники встречи будут чувствовать, что пора передать слово, или что отклоняются от темы, то это будет сильно продуктивнее. Даже встреча может раньше закончиться.
Поэтому в следующий раз, когда будете бугуртить, что встреча долгая и бестолковая, задайте себе вопрос: а что вы как профессионал сделали, чтобы она прошла продуктивно?
Я программист и я ненавижу встречи — с такой установкой я довольно долго жил. Десять черных квадратиков собрались, побухтели и разошлись. Встречи без четкой агенды, без плана, без цели, без итогов, без визуализации и без камер. Ууу аж трясёт!
Многие встречи могли бы быть письмом. Но есть такие ситуации, которые текстом сложнее и дольше. Например, когда нужно экстренно что-то поправить. Или когда тема слишком неизвестная и нужно побрейнштормить. Или когда нужно чтобы все высказали свое мнение и принять совместное решение. Короче, встречи были, есть и будут, как бы я к ним не относился.
Потом я понял, почему ненавижу встречи. Помните мем "я ограничен технологиями своего времени"? Так и мы. Пока не сделали нейролинк, нам приходится говорить словами через рот. А это ужасно долго. А еще разные люди почему-то понимают одни и те же слова по-разному. А еще кто-то много говорит одно и то же по кругу, а другие отмалчиваются. А еще кто-то обижается, но не понятно на что. А когда все без камер, вообще хрен поймёшь, что там у кого в голове. В общем, разные странности-сложности.
А потом я понял, что раз от встреч никуда не деться, и что это тоже моя работа, то надо быть в этом профессионалом. В продукте профессиональный разработчик — не только профессионально пишет код, но и общается. Доносит свои мысли аргументированно и открыто. Задает вопросы по сути, проясняя нужную информацию. Аппелирует к пользе для продукта при спорах. Не отклоняется от цели коммуникации.
Оказалось, что люди сильно раньше меня поняли, что коммуникация тоже должна быть профессиональной. И что есть целый навык профессионального проведения встреч — фасилитация. Оказывается, на встрече может быть специальный человек, который следит, чтобы все высказались и не отклонялись от темы встречи. А еще создает рабочую атмосферу, управляет неконструктивным поведением, вовлекает каждого участника и поддерживает энергию в группе.
Казалось бы, завести в команде фасилитатора и проблема решена. В чем профессионализм и при чем тут разработчик?
А при том. Чем больше фасилитатору приходится вмешиваться и останавливать кого-то или передавать слово, тем больше оверхед встречи. Если сами участники встречи будут чувствовать, что пора передать слово, или что отклоняются от темы, то это будет сильно продуктивнее. Даже встреча может раньше закончиться.
Поэтому в следующий раз, когда будете бугуртить, что встреча долгая и бестолковая, задайте себе вопрос: а что вы как профессионал сделали, чтобы она прошла продуктивно?
👍26🔥21