Итак, построение системы управления
1. Настройте целеполагание
2. Выберите метрики
3. Настройте операционное ревью - формат
4. Поставьте ревью в календари
5. Make policies explicit - чтобы люди знали, что от них ожидают
В вопросах - метрики же могут не корректно показывать. Ответ: надо периодически исследовать детали, для погружения в команду любит замещать руководителя на время отпуска. И это дает дополнительную диагностику.
1. Настройте целеполагание
2. Выберите метрики
3. Настройте операционное ревью - формат
4. Поставьте ревью в календари
5. Make policies explicit - чтобы люди знали, что от них ожидают
В вопросах - метрики же могут не корректно показывать. Ответ: надо периодически исследовать детали, для погружения в команду любит замещать руководителя на время отпуска. И это дает дополнительную диагностику.
👍5
#Teamlead Роман Поборчий. Особенности создания внутренних сервисов в крупных компаниях, и как избежать провала. Рассказ начался с вопроса, что такое провал? Мы попробовали, сделали, но это не оказалось полезным. Это провал или нет? Ответ - итерация, мы потратили свое время и чужие деньги, чтобы уточнить картину мира. Полезный опыт.
Дальше была история. 1957 fairchild semiconductor. 8 человек уволились от William Shockley, чтобы основать свою компанию, и основали ее как дочку fairchild, которая занималась разным. Они изобрели интегральную схему и начали делать, начали делать процессоры и память. Одновременно с Килби, было признано. В 1971 Don Hoefler написал статью про fairchild semiconductor, где впервые употребил термин silicon valley - и он прижился.
Все росло в 2 раза, и был год, когда дочка приносила 60% холдингу, там были внутренние дележки. Но в 1968 двое ушли, основали Integrated Electronics - Intel, был первый коммерчески неуспешный год. А в 1969 - Sanders уволился и основал advanced micro devices - AMD.
Провал - когда вы были в нужное время в нужном мести, придумали то что нужно людям, сделали. Но у вас это почему-то не получается, а этот нужный сервис делает кто-то другой.
Возвращаясь к внутренним сервисам. Внутренний сервис - это сервис, потребителями которого являются клиенты компании, может быть разным: платформа, биллинг, аналитика (человек+машина). Внутренние пользователи и внешние - отличаются. Внешние - многочисленны, обезличены. Хотя в b2b некоторые важнее других. Но в целом восполнимый ресурс. Внутри пользователей мало, они рядом с руководством, и они - не восполнимый ресурс.
Внутренний сервис делает своему подразделению, часто маленькими ресурсами, а потом распространяют на другие. И общий принцип: не стоит делать чужую работу. И есть подводные камни, которые этому мешают.
1. Интеграция. Аналитический сервис, мы получаем данные и возвращаем. Клиент приходит, говорит где взять. А дальше много клиентов - и везде разные форматы и разные данные. И интеграция разнородных форматов начинает занимать значительную часть работы. Нанять 15 стажеров - не выход, с ними надо общаться, развивать, они не хотят всю жизнь парсить логи, они отнимают твое время. А еще любые внутренние логи могут поменять формат и вам надо будет переделывать. Да еще тесты у них не упадут - НЕ работает у вас.
Поэтому правильно оставить интеграцию клиента на другом конце: клади данные в этом формате сюда. Но! удобный API - ваша часть. И помощь в написании тестов. Но это работает начиная с 3-4 клиента, первых надо сделать самим - иначе они просто не начнут пользоваться.
2. Приоритеты. Agile учит планировать спринт, собирая заказчиков, и заказчики договариваются. В принципе работает, если общее дело, есть точки пересечения, на которых договариваются. Если же много разных подразделений, то они отказываются договариваться. Не приходят на встречу, а если пришли - только познакомились на ней. И они не договариваются между собой, а пытаются договорить вас. Ошибка - пытаться самому принять решение, кто важнее. Но если подразделения далекие и компания большая, то вы не можете сделать.
Что помогает? Наименьший общий начальник. Был кейс в Яндекс-поиске, много начальник. Но оказалось, что можно привлечь к планированию одного из топов. Пару раз в месяц, на планировании спринта, он приходил. Так бывает можно, не надо бояться.
Правда, на мой взгляд, это больше счастливый случай, а не правило. Если же НОК не доступен - приходится решать самому. Помогают квоты и предложение при срочных азачах ими меняться или брать в долг. Дело в том, что не хотят договариваться не со зла, а потому что нет времени вникнать в проблемы другого, а чтобы договориться - это нужно. А обмен или взять в долг - понятная конструкция.
Дальше была история. 1957 fairchild semiconductor. 8 человек уволились от William Shockley, чтобы основать свою компанию, и основали ее как дочку fairchild, которая занималась разным. Они изобрели интегральную схему и начали делать, начали делать процессоры и память. Одновременно с Килби, было признано. В 1971 Don Hoefler написал статью про fairchild semiconductor, где впервые употребил термин silicon valley - и он прижился.
Все росло в 2 раза, и был год, когда дочка приносила 60% холдингу, там были внутренние дележки. Но в 1968 двое ушли, основали Integrated Electronics - Intel, был первый коммерчески неуспешный год. А в 1969 - Sanders уволился и основал advanced micro devices - AMD.
Провал - когда вы были в нужное время в нужном мести, придумали то что нужно людям, сделали. Но у вас это почему-то не получается, а этот нужный сервис делает кто-то другой.
Возвращаясь к внутренним сервисам. Внутренний сервис - это сервис, потребителями которого являются клиенты компании, может быть разным: платформа, биллинг, аналитика (человек+машина). Внутренние пользователи и внешние - отличаются. Внешние - многочисленны, обезличены. Хотя в b2b некоторые важнее других. Но в целом восполнимый ресурс. Внутри пользователей мало, они рядом с руководством, и они - не восполнимый ресурс.
Внутренний сервис делает своему подразделению, часто маленькими ресурсами, а потом распространяют на другие. И общий принцип: не стоит делать чужую работу. И есть подводные камни, которые этому мешают.
1. Интеграция. Аналитический сервис, мы получаем данные и возвращаем. Клиент приходит, говорит где взять. А дальше много клиентов - и везде разные форматы и разные данные. И интеграция разнородных форматов начинает занимать значительную часть работы. Нанять 15 стажеров - не выход, с ними надо общаться, развивать, они не хотят всю жизнь парсить логи, они отнимают твое время. А еще любые внутренние логи могут поменять формат и вам надо будет переделывать. Да еще тесты у них не упадут - НЕ работает у вас.
Поэтому правильно оставить интеграцию клиента на другом конце: клади данные в этом формате сюда. Но! удобный API - ваша часть. И помощь в написании тестов. Но это работает начиная с 3-4 клиента, первых надо сделать самим - иначе они просто не начнут пользоваться.
2. Приоритеты. Agile учит планировать спринт, собирая заказчиков, и заказчики договариваются. В принципе работает, если общее дело, есть точки пересечения, на которых договариваются. Если же много разных подразделений, то они отказываются договариваться. Не приходят на встречу, а если пришли - только познакомились на ней. И они не договариваются между собой, а пытаются договорить вас. Ошибка - пытаться самому принять решение, кто важнее. Но если подразделения далекие и компания большая, то вы не можете сделать.
Что помогает? Наименьший общий начальник. Был кейс в Яндекс-поиске, много начальник. Но оказалось, что можно привлечь к планированию одного из топов. Пару раз в месяц, на планировании спринта, он приходил. Так бывает можно, не надо бояться.
Правда, на мой взгляд, это больше счастливый случай, а не правило. Если же НОК не доступен - приходится решать самому. Помогают квоты и предложение при срочных азачах ими меняться или брать в долг. Дело в том, что не хотят договариваться не со зла, а потому что нет времени вникнать в проблемы другого, а чтобы договориться - это нужно. А обмен или взять в долг - понятная конструкция.
👍2
Еще один трюк. После планирования приходит заказчик, говорит "Мне очень надо, ты сделай, давай я тебе помогу". Ваша работа - заранее думать, что я могу попросить у такого клиента. И в этот момент быть готовым попросить. В идеале, когда разовая услуга меняется на долгосрочные обязательства. Например, попросили сервис, который в ответ на слово отдавал основную форму - это часто нужно. Это выигрышная стратегия, стоит вкладываться.
3. Стабильность. Начинается на маленьком железе, старый сервер. Внутренние лучше внешних, они не уходят, осознают ресурсный голод. Но в какой-то момент не могут терпеть. Как оттянуть этот момент, и успеть сделать нормально?
Если от внутреннего сервиса не зависит продакшн - его не обязательно резервировать. Достаточно мониторить и вешать плашку "не работаю планово". И по входным данным - вести мониторинг, вешать плашку "мы уже знаем". Это как "мы адекватны и стараемся".
Рост нагрузки системы. Измеряться может в разном, а скачки - с новым клиентом. И часто есть точка апокалипсиса - ресурс весь потребляется. Например, может быть время на ежедневную обработку данных - не должно превышать 24 часа. Пока всего мало, можно проводить тесты и предсказать точку апокалипсиса. Это надо сделать и готовиться.
Мониторинг и информирование - важнее постоянной доступности.
4. Велосипеды. Однажды было нужно строить тепловую карту России по метрикам, по регионам. Маленькая команда, Apach Superset - позволяет подобное делать. Но! Деление по регионам может быть не очень хорошим, Красноярский край - большой, надо дробить. А еще есть города - миллионники - они маленькие, людей много - их надо показывать специально. А еще состав региона надо уметь менять. Коробка - не поддерживает. В результате аналитик данных занимается тем, что пытается поставить точку в нужное место и другой борьбой с инструментом. В результате, пока боролись, другая команда напилила собственные карты, начала им предоставлять.
Готовые инструменты хороши для прототипов, но даже для MVP - не обязательно. Надо оценивать, не слишком ли он дорог. Часто на первом этапе нужно небольшое подмножество, но с нашлепкой, которую сложно сделать, и это проще сделать самим.
3. Стабильность. Начинается на маленьком железе, старый сервер. Внутренние лучше внешних, они не уходят, осознают ресурсный голод. Но в какой-то момент не могут терпеть. Как оттянуть этот момент, и успеть сделать нормально?
Если от внутреннего сервиса не зависит продакшн - его не обязательно резервировать. Достаточно мониторить и вешать плашку "не работаю планово". И по входным данным - вести мониторинг, вешать плашку "мы уже знаем". Это как "мы адекватны и стараемся".
Рост нагрузки системы. Измеряться может в разном, а скачки - с новым клиентом. И часто есть точка апокалипсиса - ресурс весь потребляется. Например, может быть время на ежедневную обработку данных - не должно превышать 24 часа. Пока всего мало, можно проводить тесты и предсказать точку апокалипсиса. Это надо сделать и готовиться.
Мониторинг и информирование - важнее постоянной доступности.
4. Велосипеды. Однажды было нужно строить тепловую карту России по метрикам, по регионам. Маленькая команда, Apach Superset - позволяет подобное делать. Но! Деление по регионам может быть не очень хорошим, Красноярский край - большой, надо дробить. А еще есть города - миллионники - они маленькие, людей много - их надо показывать специально. А еще состав региона надо уметь менять. Коробка - не поддерживает. В результате аналитик данных занимается тем, что пытается поставить точку в нужное место и другой борьбой с инструментом. В результате, пока боролись, другая команда напилила собственные карты, начала им предоставлять.
Готовые инструменты хороши для прототипов, но даже для MVP - не обязательно. Надо оценивать, не слишком ли он дорог. Часто на первом этапе нужно небольшое подмножество, но с нашлепкой, которую сложно сделать, и это проще сделать самим.
👍4
#Teamlead Эрик Бурыгин. Сила нетворкинга, или Нетворкинг как стиль жизни. Доклад с одной сквозной историей о пользе нетворкинга и множестве частных. Основная идея: не бойтесь начать, и активно делайте. Потому что нетворкинг реально помогает достигать своих желаний и осуществлять мечты. Сила в том, что когда вам что-то нужно - вы знаете у кого спросить, и вам расскажут. Например, вы умеете шить одежду, захотели запустить производство - и вам расскажут процесс в деталях, ведь уметь шить - далеко не все. А еще через нетворкинг можно найти ресурсы. Но чтобы это случилось, надо активно знакомится, знать кто чем может помочь. Не когда у вас возник конкретных вопрос, а заранее, чтобы когда вопрос возник - уже было понятно кто ответит. При этом жизнь часто ходит очень извилистыми путями, но приводит в нужном направлении, если вы при этом активны и ловите моменты.
Это иллюстрирует сквозная история - о том, как Эрик хотел сделать курсы, и даже учился этому - но у него не получалось. Но однажды он попал в Гонку героев. Потому что до этого хотел попасть в спорт, было 100500 попыток, но не складывалось. А тут увидел в инстаграмме фотку с гонки героев, где был его друг, узнал, решил в очередной раз попробовать, друг дал телефон - и этот вариант зашел. И он не просто участвовал, а стал инструктором, сдал необходимое, хотя для этого пришлось с другими инструкторами договориться о переносе даты экзамена, он не мог в назначенную. А потом был тренинг по публичным выступлениям, где он человек рассказывал про Яндекс-практикум, и он подумал, что это клевое место, пошел туда работать. Но с курсом не складывалось, надо было пройти обучение, а там не было вакансий. Однако, Гонка героев осталась, он собрал команду от Яндекса, только формально они опоздали, но поскольку руководитель по спорту в Яндексе тоже был инструктором в гонке героев, он договорился. А потом, на гонке, познакомился с девочкой QA-факультета, рассказал ей про мечту о курсе, его начала включили в середину обучения, а позднее у него получилось сделать курс, и он быстро нашел команду для этого за счет накопленных контактов. И таких историй у Эрика много.
Дальше были рекомендации. Они, в общем простые и достаточно известные.
Люди часто охотно разговаривают о том, что они делают. Это кажется, что они не хотят. Просто они не обо всем.
Где и как разговаривать? Везде.
* Профильные конференции
* Пейте кофе, ходите на обед с новыми людьми. В Яндексе есть рандомный кофе
* Тимбилдинги и неформальные встречи. Если не хватает - свои: настолки, пати, спорт...
* Открытые и доброжелательные
* Проявляйте заинтересованность, не отвлекайтесь на встрече
* Делитесь историями
* Обменяйтесь контактами
* Не забывайте напоминать о себе
* Будьте отзывчивыми
* Не будьте навязчивыми
* Если плохое настроение - перенесите
Страхи. Ему и сейчас страшно. Но он пытался изменить, потому что хотел. Как готовиться?
* Начать здороваться с коллегами. И на улице тоже. Это точка входа.
* Больше говорить на встречах. Презентовал проекты и так далее.
* Активно использовать текстовую коммуникацию. Писать проще, чем говорить.
Систематизируйте контакты. Набрать целый телефон - не проблема, проблема вспомнить кто. Оставляйте артефакты, делайте селфи или кружки с новым знакомым и отправляйте в телегу. Больше общайтесь, со временем нетворкинг станет частью жизни.
Чек лист быстрого старта
* Какую задачу нетворкинг поможет решить сейчас
* Определиться со списком задач и подготовить вопросы
* Подумать, кто может помочь, где и как начать коммуникацию.
Хотел стать сейлом. Всех сейлов спрашивал - а как ты стал сейлом? Многие рассказывали. И руководители просили подчиненных.
Это иллюстрирует сквозная история - о том, как Эрик хотел сделать курсы, и даже учился этому - но у него не получалось. Но однажды он попал в Гонку героев. Потому что до этого хотел попасть в спорт, было 100500 попыток, но не складывалось. А тут увидел в инстаграмме фотку с гонки героев, где был его друг, узнал, решил в очередной раз попробовать, друг дал телефон - и этот вариант зашел. И он не просто участвовал, а стал инструктором, сдал необходимое, хотя для этого пришлось с другими инструкторами договориться о переносе даты экзамена, он не мог в назначенную. А потом был тренинг по публичным выступлениям, где он человек рассказывал про Яндекс-практикум, и он подумал, что это клевое место, пошел туда работать. Но с курсом не складывалось, надо было пройти обучение, а там не было вакансий. Однако, Гонка героев осталась, он собрал команду от Яндекса, только формально они опоздали, но поскольку руководитель по спорту в Яндексе тоже был инструктором в гонке героев, он договорился. А потом, на гонке, познакомился с девочкой QA-факультета, рассказал ей про мечту о курсе, его начала включили в середину обучения, а позднее у него получилось сделать курс, и он быстро нашел команду для этого за счет накопленных контактов. И таких историй у Эрика много.
Дальше были рекомендации. Они, в общем простые и достаточно известные.
Люди часто охотно разговаривают о том, что они делают. Это кажется, что они не хотят. Просто они не обо всем.
Где и как разговаривать? Везде.
* Профильные конференции
* Пейте кофе, ходите на обед с новыми людьми. В Яндексе есть рандомный кофе
* Тимбилдинги и неформальные встречи. Если не хватает - свои: настолки, пати, спорт...
* Открытые и доброжелательные
* Проявляйте заинтересованность, не отвлекайтесь на встрече
* Делитесь историями
* Обменяйтесь контактами
* Не забывайте напоминать о себе
* Будьте отзывчивыми
* Не будьте навязчивыми
* Если плохое настроение - перенесите
Страхи. Ему и сейчас страшно. Но он пытался изменить, потому что хотел. Как готовиться?
* Начать здороваться с коллегами. И на улице тоже. Это точка входа.
* Больше говорить на встречах. Презентовал проекты и так далее.
* Активно использовать текстовую коммуникацию. Писать проще, чем говорить.
Систематизируйте контакты. Набрать целый телефон - не проблема, проблема вспомнить кто. Оставляйте артефакты, делайте селфи или кружки с новым знакомым и отправляйте в телегу. Больше общайтесь, со временем нетворкинг станет частью жизни.
Чек лист быстрого старта
* Какую задачу нетворкинг поможет решить сейчас
* Определиться со списком задач и подготовить вопросы
* Подумать, кто может помочь, где и как начать коммуникацию.
Хотел стать сейлом. Всех сейлов спрашивал - а как ты стал сейлом? Многие рассказывали. И руководители просили подчиненных.
В целом Эрик весь доклад объяснял, что никакая магия тут не нужна. Нужна активность и простые приемы, и не надо бояться, и получится куча пользы. Но реально магия - требуется. Тут как со спортом: многие знают, что это нужно и несложно, и часть из них даже покупает абонементы в фитнес, а реально занимаются - гораздо меньше. Так что не в страхе дело, или не в нем одном. Возможно, лично для Эрика главным было преодолеть страх, а дальше мастерство как-то росло и сейчас это на уровне неосознанной компетентности, которую он не может раскрыть, потому что она неосознанна.
Но по-любому такой доклад заставляет заглянуть в себя и спросить - почему ты сам этого не делаешь. Я лично не то, чтобы совсем не нетворкаюсь, но вот так, как делает Эрик - точно не делаю. Хотя знаю, что это нужно. Наверное, дело в том, что я не люблю строить орг.системы из людей, не вижу именно в этом свою реализацию. А нетворкинг - он про это, ты просто копишь материал, чтобы использовать в нужный момент. Впрочем, это вполне может быть лишь рассуждение "от ответа", а не реальная причина. Но это не страшно, ведь обязанности - нет.
Но по-любому такой доклад заставляет заглянуть в себя и спросить - почему ты сам этого не делаешь. Я лично не то, чтобы совсем не нетворкаюсь, но вот так, как делает Эрик - точно не делаю. Хотя знаю, что это нужно. Наверное, дело в том, что я не люблю строить орг.системы из людей, не вижу именно в этом свою реализацию. А нетворкинг - он про это, ты просто копишь материал, чтобы использовать в нужный момент. Впрочем, это вполне может быть лишь рассуждение "от ответа", а не реальная причина. Но это не страшно, ведь обязанности - нет.
👍6❤3🔥2
#Teamlead Александр Зиза. Три субкультуры в IT-компаниях. Очень хороший рассказ о происходящих сейчас принципиальных изменениях в культуре компаний. Это был второй слот, но конспект я публикую только вечером, потому что было желание обдумать и дополнить то, что говорил Александр, а это требует времени. Свои дополнения я отделяю от конспекта, пишу от первого лица. Но надо понимать, что всякий конспект - интерпретация, а не точная передача смысла.
Итак, сейчас, летом 2024 происходит много изменений. И в результате в каждой компании есть винегрет разного. В докладе Александр расчерчивает карту, чтобы в этом разном разбираться.
До субкультур надо поговорить про культуру ИТ-компаний в целом. И это - важно, хотя многие руководители говорят "вы мне практик дайте, не надо про культуру". Я замечу, что такие руководители просто не понимают, насколько у людей различается мышление, и насколько это мышление влияет на жизнь и поведение людей. При этом про себя они бычно это понимают, а вот других считают не такими, как они сами (иначе им бы не были нужны практики управления) - основная ошибка атрибуции. Впрочем, может, они и про себя понимают, и им нужны практики не только для других, но и для себя.
Какие есть проекции, планы, viewpoint для описания культуры? Их много, они перечислены, и большинство остались за рамками доклада, но по ним есть источники.
1. Ограничивающие убеждения, система-1 и система-2 Канемана в мышлении.
2. Культура цивилизаций. Тойнби: цивилизация это культура. Запад: мышление и коммуникации между равным позициями, Россия - эмоциональное присоединение. Интернет, платформы, чаты - про организацию коммуникаций. Выстраивание отношений - это не про коммуникации, отношения бывают деловые и не деловые - разные.
3. Культура как культура быта, артефакты. Они впитаны.
4. Организационная культура - инструменты спиральной динамики.
5. Индустрия в цифровом торнадо (digidal tornado). Каждая индустрия в разных ситуациях.
6. Организационные субкультуры. DevOps, продуктовый подход.
Каждый viewpoint дает фрагментированное представление, надо собирать целое.
Безработица 2.7%, для нормального рынка труда нужно 6-7%. В ИТ не хватает 45% специалистов. У части ИТ-шников есть стратегия: каждый год менять место. Я тут хочу сказать, что это - не особенность России. Питер Друкер, рассматривая вызовы менеджмента 21 века, более 20 лет назад писал о том, что переход от физического труда к умственному приведет к переходу от профицитного рынка труда к дефицитному, при котором специалист будет сам выбирать место работы, при этом деньги будут не основным фактором. Собственно, это и происходит, в ИТ - раньше, в других отраслях - позже, но оно неизбежно.
Культура: цели, ценности, стереотипы, практики. Два способа движения по жизненному циклу: upstream и downstream.
Развитие технологий. Из жизни: как делаем самолеты. Три фазы.
* Модель, ответ на вопрос взлетит или нет.
* Два экземпляра прототипа. Один летает, второй в запасе
* Дальше завод штампует.
Жизненный цикл - детальнее. Важно, что есть Разные места, разные типы деятельности: наука, производство, бизнес.
Здравоохранение - продуктовый подход.
* Обычные задачи - поликлиника, регламенты, ОМС/ДМС
* Сложная проблема - научный клинический центр. И там - другой подход внутри.
* И еще - наука, экспериментальные методы.
Интегрировать это - все очень сложно.
Стивен Деннинг. Эпоха Agile. Складывается мозаичная система и надо интегрировать.
Инженер: назначение бизнеса - обеспечивать развитие науки и технологии. На Highload очень много докладов, и за каждой - стоит тот, кто так думает. Из основного процесса развития технологии появляются боковички развития технологии: о - можно упаковать и продать. И это может быть сырая непонятная шняга. Или Технология как продукт - он рисковая, может быть голубой океан, а может - пусто. А может быть технология как коммерческий продукт. Но инженер об упаковке не думает. Он видел историю со светодиодами времен СССР: у нас развивали науку и рассказывали, а японцы упаковывали.
Итак, сейчас, летом 2024 происходит много изменений. И в результате в каждой компании есть винегрет разного. В докладе Александр расчерчивает карту, чтобы в этом разном разбираться.
До субкультур надо поговорить про культуру ИТ-компаний в целом. И это - важно, хотя многие руководители говорят "вы мне практик дайте, не надо про культуру". Я замечу, что такие руководители просто не понимают, насколько у людей различается мышление, и насколько это мышление влияет на жизнь и поведение людей. При этом про себя они бычно это понимают, а вот других считают не такими, как они сами (иначе им бы не были нужны практики управления) - основная ошибка атрибуции. Впрочем, может, они и про себя понимают, и им нужны практики не только для других, но и для себя.
Какие есть проекции, планы, viewpoint для описания культуры? Их много, они перечислены, и большинство остались за рамками доклада, но по ним есть источники.
1. Ограничивающие убеждения, система-1 и система-2 Канемана в мышлении.
2. Культура цивилизаций. Тойнби: цивилизация это культура. Запад: мышление и коммуникации между равным позициями, Россия - эмоциональное присоединение. Интернет, платформы, чаты - про организацию коммуникаций. Выстраивание отношений - это не про коммуникации, отношения бывают деловые и не деловые - разные.
3. Культура как культура быта, артефакты. Они впитаны.
4. Организационная культура - инструменты спиральной динамики.
5. Индустрия в цифровом торнадо (digidal tornado). Каждая индустрия в разных ситуациях.
6. Организационные субкультуры. DevOps, продуктовый подход.
Каждый viewpoint дает фрагментированное представление, надо собирать целое.
Безработица 2.7%, для нормального рынка труда нужно 6-7%. В ИТ не хватает 45% специалистов. У части ИТ-шников есть стратегия: каждый год менять место. Я тут хочу сказать, что это - не особенность России. Питер Друкер, рассматривая вызовы менеджмента 21 века, более 20 лет назад писал о том, что переход от физического труда к умственному приведет к переходу от профицитного рынка труда к дефицитному, при котором специалист будет сам выбирать место работы, при этом деньги будут не основным фактором. Собственно, это и происходит, в ИТ - раньше, в других отраслях - позже, но оно неизбежно.
Культура: цели, ценности, стереотипы, практики. Два способа движения по жизненному циклу: upstream и downstream.
Развитие технологий. Из жизни: как делаем самолеты. Три фазы.
* Модель, ответ на вопрос взлетит или нет.
* Два экземпляра прототипа. Один летает, второй в запасе
* Дальше завод штампует.
Жизненный цикл - детальнее. Важно, что есть Разные места, разные типы деятельности: наука, производство, бизнес.
Здравоохранение - продуктовый подход.
* Обычные задачи - поликлиника, регламенты, ОМС/ДМС
* Сложная проблема - научный клинический центр. И там - другой подход внутри.
* И еще - наука, экспериментальные методы.
Интегрировать это - все очень сложно.
Стивен Деннинг. Эпоха Agile. Складывается мозаичная система и надо интегрировать.
Инженер: назначение бизнеса - обеспечивать развитие науки и технологии. На Highload очень много докладов, и за каждой - стоит тот, кто так думает. Из основного процесса развития технологии появляются боковички развития технологии: о - можно упаковать и продать. И это может быть сырая непонятная шняга. Или Технология как продукт - он рисковая, может быть голубой океан, а может - пусто. А может быть технология как коммерческий продукт. Но инженер об упаковке не думает. Он видел историю со светодиодами времен СССР: у нас развивали науку и рассказывали, а японцы упаковывали.
👍1
У бизнеса - противоположный взгляд. Ему не интересны технологии. Задача - делать продукты, которые продаются. Но встречаются проблемы: то, что делаем - вдруг не продается. Первая идея - выяснить почему не выполнили план. Следующая стадия: поищем другие средства, лучше готовые. Если их не получается найти, можно поставить цель на создание средств. Но в голове у бизнеса - нет способа про это подумать. Это же нельзя запланировать, нет гарантий и непонятны бюджеты.
Итого, классификация:
* Средства понятны и доступны - задачи
* Средства неясны, но их можно найти - Цель
* Средства никогда не созданы - Проблема.
Отмечу, что это близко к классификации Дэвида Майстера на три типа проектов: Мозги, Седина и Процедуры.
И есть вопрос владения результатом. Бизнес поставил задачу: инженер, сделай эту метрику не 10, а 5. Инженер думает, придумал, на коленках в выходные - сделал технологию, которая снимает проблему. Вопрос - кому принадлежат права на это средство? Менеджер "сделал у меня", инженер "в воскресенье на кухне". Эта бизнес-проблема, она не решенная. И пока выигрывают инженеры, которые уносят технологии - если не была явно поставлена цель.
Карта фаз развития технологии
* Проектирование: технологии, рынок, орг.управление
* Разработка и тестирование
* Производство и эксплуатация
Каждая фаза - своя субкультура, принципиально отличающаяся от других.
* Заказная разработка, культура операционной эффективности: инженеру ставят задачи. Фокус - орг.управления + производств и эксплуатация. За последние 2 года в России взорвалась - есть большой госзаказ. Как правило, коммерческие средства с гарантией результата. Создаются орг.формы и партнерства с заказчиком и так далее. Главный вызов - сформировать слой среднего управления, умеющий вести орг.проектирование
* Продуктовая компания: разработка и тестирование, fail fast, гибкая технология управления
* Инновационно-технологическая компания, инженерная культура. Разработка новых технологий и средств, которые обеспечат новизну. Главный вызов - связь технолога и бизнеса, это сложно, потому что говорят про разное.
* Культура операционной эффективности - план-факт, все через процессы и kpi, приходят за стабильностью.
* Продуктовая культура - fail fast fail cheap. Ключ - нетворкинг и сообщества. Потребление, а не деньги. Главное, чтобы заработало. Приходят за востребованностью.
* Инженерная культура. Придумать, чтоб показать работоспособность, дальше не важно. Любопытство. Бизнес - обеспечивающая структура для исследований.
Александр говорит, что в компании объединяются только попарно: продукты + операционная эффективность или инженерная культура + продукты. Но я хочу сказать, что изменения текущего момента состоят в том, что надо рассматривать целостную деятельность из всех трех фаз, пусть не в одной компании, а в кооперации. Это раньше, когда развитие технологий было медленным, можно было рассматривать отдельно. У меня есть есть статья https://mtsepkov.org/De3-ground, где я формулирую такую схему деятельности ценностно.
И Александр в заключении сказал, что для целостного представления необходимо коммуницировать, несмотря на разницу культур. Коммуникация есть преодоление отвращения к точки зрения собеседника, это Александр сослался на Бориса Марковича Островского, одного из учеников Щедровицкого-старшего, от которого я тоже много почерпнул. Чтобы вести такую коммуникацию, надо говорить про дело, оставляя все остальное - за рамками.
И вот такому подходу к коммуникации в России - всего 30 лет, до этого было эмоциональное присоединение. Впрочем, я считаю, что с этим надо детально разбираться: что было у нас и как это изменялось со временем, что было на западе и как оно изменялось там, когда там возникла коммуникация равных позиций и кого считали равными. Потому что есть известный эффект, когда победившая в борьбе сторона ретроспективно переписывает историю, объявляя себя продолжателем традиции...
Итого, классификация:
* Средства понятны и доступны - задачи
* Средства неясны, но их можно найти - Цель
* Средства никогда не созданы - Проблема.
Отмечу, что это близко к классификации Дэвида Майстера на три типа проектов: Мозги, Седина и Процедуры.
И есть вопрос владения результатом. Бизнес поставил задачу: инженер, сделай эту метрику не 10, а 5. Инженер думает, придумал, на коленках в выходные - сделал технологию, которая снимает проблему. Вопрос - кому принадлежат права на это средство? Менеджер "сделал у меня", инженер "в воскресенье на кухне". Эта бизнес-проблема, она не решенная. И пока выигрывают инженеры, которые уносят технологии - если не была явно поставлена цель.
Карта фаз развития технологии
* Проектирование: технологии, рынок, орг.управление
* Разработка и тестирование
* Производство и эксплуатация
Каждая фаза - своя субкультура, принципиально отличающаяся от других.
* Заказная разработка, культура операционной эффективности: инженеру ставят задачи. Фокус - орг.управления + производств и эксплуатация. За последние 2 года в России взорвалась - есть большой госзаказ. Как правило, коммерческие средства с гарантией результата. Создаются орг.формы и партнерства с заказчиком и так далее. Главный вызов - сформировать слой среднего управления, умеющий вести орг.проектирование
* Продуктовая компания: разработка и тестирование, fail fast, гибкая технология управления
* Инновационно-технологическая компания, инженерная культура. Разработка новых технологий и средств, которые обеспечат новизну. Главный вызов - связь технолога и бизнеса, это сложно, потому что говорят про разное.
* Культура операционной эффективности - план-факт, все через процессы и kpi, приходят за стабильностью.
* Продуктовая культура - fail fast fail cheap. Ключ - нетворкинг и сообщества. Потребление, а не деньги. Главное, чтобы заработало. Приходят за востребованностью.
* Инженерная культура. Придумать, чтоб показать работоспособность, дальше не важно. Любопытство. Бизнес - обеспечивающая структура для исследований.
Александр говорит, что в компании объединяются только попарно: продукты + операционная эффективность или инженерная культура + продукты. Но я хочу сказать, что изменения текущего момента состоят в том, что надо рассматривать целостную деятельность из всех трех фаз, пусть не в одной компании, а в кооперации. Это раньше, когда развитие технологий было медленным, можно было рассматривать отдельно. У меня есть есть статья https://mtsepkov.org/De3-ground, где я формулирую такую схему деятельности ценностно.
И Александр в заключении сказал, что для целостного представления необходимо коммуницировать, несмотря на разницу культур. Коммуникация есть преодоление отвращения к точки зрения собеседника, это Александр сослался на Бориса Марковича Островского, одного из учеников Щедровицкого-старшего, от которого я тоже много почерпнул. Чтобы вести такую коммуникацию, надо говорить про дело, оставляя все остальное - за рамками.
И вот такому подходу к коммуникации в России - всего 30 лет, до этого было эмоциональное присоединение. Впрочем, я считаю, что с этим надо детально разбираться: что было у нас и как это изменялось со временем, что было на западе и как оно изменялось там, когда там возникла коммуникация равных позиций и кого считали равными. Потому что есть известный эффект, когда победившая в борьбе сторона ретроспективно переписывает историю, объявляя себя продолжателем традиции...
👍2
Книги по различию Запада и России:
* Лотман. Беседы о русской культуре
* Бердяев. Истоки и смысл русского коммунизма.
* Александр Зиновьев. Русская трагедия
* Аузан Культурные коды экономики
* Эрик Мейер. Карта культурных различий
А начать можно с лекций Аузана, которые гуглятся по словам "Аузан Арзамас".
Книги про современную западную культуру.
* The beginers guide to OKR
* Никаких правил - про Netflix
* Ким Скотт. Радикальная прямота
* Стивен Деннинг. Эпоха Agile.
* Лотман. Беседы о русской культуре
* Бердяев. Истоки и смысл русского коммунизма.
* Александр Зиновьев. Русская трагедия
* Аузан Культурные коды экономики
* Эрик Мейер. Карта культурных различий
А начать можно с лекций Аузана, которые гуглятся по словам "Аузан Арзамас".
Книги про современную западную культуру.
* The beginers guide to OKR
* Никаких правил - про Netflix
* Ким Скотт. Радикальная прямота
* Стивен Деннинг. Эпоха Agile.
👍6
#Teamlead Юлия Лукина. Как окунуться в новую предметную область и не утонуть. Юлия сменила много предметок: телеком (управление железом, портал для сотрудников), DWH+BI, Порталы госуслуг, Атомные станции, e-com (озон). Погружение в новую область кому-то тяжело, кто-то обжигаешься, кому-то больно. И она рассказывала свои техники погружения, чтобы не было страхов. Приемы - простые, превратились в чек-лист. Это про предметную область, смену стека она полагает отдельной, хотя лично я не очень вижу разницы на уровне чек-листа. Дальше по пунктам.
1. Глоссарий. В новой сфере он свой, и там куча сокращений, сленга. Который ясен тем, кто работает внутри. Глоссарий часто собран в головах. И тогда надо сделать самому. И удобно сделать общедоступным. И не надо накапливать, заносить быстро, каждый день. При этом полезно не только понимать термины, но и самому начинать употреблять.
2. Волна непонятной информации. Визуализировать и собирать по крупицам. Как собирать паззл или вести расследование. Картинку сразу увидеть хочется, но ты не увидишь. Только вот в паззле есть целевой образ, а у нас - нет. Нужно место, и тоже надо обновлять регулярно, пару раз в неделю. И видеть прогресс. Стикеры в миро как процесс или сущности и связи или что-то еще. Схема процессов, но это - на любителя.
3. Множество новых контактов. В новом отделе 10-15 человек в принципе запомнишь через 2 недели. Но есть большие проекты, где в чате 1000 человек. Матрица взаимодействия, Миро или что-то еще. Кто за что отвечает.
Где брать на все это время? Реально достаточно 15 минут в день, как и с контактами. И надо каждый день. С визуализацией пореже, но тоже не накапливать.
4. Обязательно задавайте вопросы. Да, даже глупые, и если кажется, что это элементарно.
Исnория - термин Mesh. Все употребяют, а она не знает. Но не спрашивает, спрашивает у коллег, а те - не знают. И полтора часа потерянного времени, потому что спросить надо было того, кто сказал. При чем выяснилось, что это - сленг, включить "как на проде"
Спрашивать надо своевременно. Рассказывают про червяка, во-время не спрашивают, надеется понять из контекста, не получается. Но когда полчаса говорили, сложно. А это на отгрузке зона, куда паллеты ставят. Или вопрос про имя через два дня знакомства.
Будь тем, кто переспросит и уточнит. Особенно на фразу "не буду останавливаться, всем понятно". Не понятно - спросите. Может потом, в личке. Но лучше - сразу, не только вам не понятно.
Не бойся спрашивать у экспертов. Если у эксперта спрашиваешь "расскажи мне все" - он не знает, что ответить, он три года может рассказывать. Стоит в вопросе раскручивать от задаче, а потом идти вширь, если уместно. Не "какие бывают топологии сети", а "если роутер вышел из строя - как узнать топологии, в которых он включен"
5. Фокус на здесь и сейчас - погружение через текущие задачи. Отбрасывать все лишнее. Беречь силы. Не распылять внимание. Иначе вас может накрыть, узнать все - не реально.
6. Практика. Наблюдай, как реально работает предметная область, если есть возможность. Если есть порталы, приложения, сайты - попробуй работать как пользователь. Посещая объекты, для которых работаешь - если есть возможность. В озоне она реально работала на складе, 12 часов. А на немецкой атомной станции, для которых работала, было без шансов. Погружение позволяет почувствовать требуемую эргономику.
7. Понять и простить. В первую очередь себя. Если мы принимаем решение о смене предметной области, надо заходить с пониманием на входе, что ты не понимаешь ничего. И не постигнешь все за неделю-две. Будут моменты, когда будет жестко накрывать, будете сидеть с кипящей головой. Обращаемся за помощью к себе самим, сила в нас. Тут помогает книга Е.Резанова "Это норм". А еще есть эксперты. Она ищет жертву среди экспертов, и просит рассказать, как он начинал, погружался. И в 90% случаев они отвечают "я и сейчас не понимаю", а другие "первые полгода я не понимал". И тут становится легче. И можно явно попросить помощи, не обязательно сделать задачу за вас, а направить на правильный путь.
1. Глоссарий. В новой сфере он свой, и там куча сокращений, сленга. Который ясен тем, кто работает внутри. Глоссарий часто собран в головах. И тогда надо сделать самому. И удобно сделать общедоступным. И не надо накапливать, заносить быстро, каждый день. При этом полезно не только понимать термины, но и самому начинать употреблять.
2. Волна непонятной информации. Визуализировать и собирать по крупицам. Как собирать паззл или вести расследование. Картинку сразу увидеть хочется, но ты не увидишь. Только вот в паззле есть целевой образ, а у нас - нет. Нужно место, и тоже надо обновлять регулярно, пару раз в неделю. И видеть прогресс. Стикеры в миро как процесс или сущности и связи или что-то еще. Схема процессов, но это - на любителя.
3. Множество новых контактов. В новом отделе 10-15 человек в принципе запомнишь через 2 недели. Но есть большие проекты, где в чате 1000 человек. Матрица взаимодействия, Миро или что-то еще. Кто за что отвечает.
Где брать на все это время? Реально достаточно 15 минут в день, как и с контактами. И надо каждый день. С визуализацией пореже, но тоже не накапливать.
4. Обязательно задавайте вопросы. Да, даже глупые, и если кажется, что это элементарно.
Исnория - термин Mesh. Все употребяют, а она не знает. Но не спрашивает, спрашивает у коллег, а те - не знают. И полтора часа потерянного времени, потому что спросить надо было того, кто сказал. При чем выяснилось, что это - сленг, включить "как на проде"
Спрашивать надо своевременно. Рассказывают про червяка, во-время не спрашивают, надеется понять из контекста, не получается. Но когда полчаса говорили, сложно. А это на отгрузке зона, куда паллеты ставят. Или вопрос про имя через два дня знакомства.
Будь тем, кто переспросит и уточнит. Особенно на фразу "не буду останавливаться, всем понятно". Не понятно - спросите. Может потом, в личке. Но лучше - сразу, не только вам не понятно.
Не бойся спрашивать у экспертов. Если у эксперта спрашиваешь "расскажи мне все" - он не знает, что ответить, он три года может рассказывать. Стоит в вопросе раскручивать от задаче, а потом идти вширь, если уместно. Не "какие бывают топологии сети", а "если роутер вышел из строя - как узнать топологии, в которых он включен"
5. Фокус на здесь и сейчас - погружение через текущие задачи. Отбрасывать все лишнее. Беречь силы. Не распылять внимание. Иначе вас может накрыть, узнать все - не реально.
6. Практика. Наблюдай, как реально работает предметная область, если есть возможность. Если есть порталы, приложения, сайты - попробуй работать как пользователь. Посещая объекты, для которых работаешь - если есть возможность. В озоне она реально работала на складе, 12 часов. А на немецкой атомной станции, для которых работала, было без шансов. Погружение позволяет почувствовать требуемую эргономику.
7. Понять и простить. В первую очередь себя. Если мы принимаем решение о смене предметной области, надо заходить с пониманием на входе, что ты не понимаешь ничего. И не постигнешь все за неделю-две. Будут моменты, когда будет жестко накрывать, будете сидеть с кипящей головой. Обращаемся за помощью к себе самим, сила в нас. Тут помогает книга Е.Резанова "Это норм". А еще есть эксперты. Она ищет жертву среди экспертов, и просит рассказать, как он начинал, погружался. И в 90% случаев они отвечают "я и сейчас не понимаю", а другие "первые полгода я не понимал". И тут становится легче. И можно явно попросить помощи, не обязательно сделать задачу за вас, а направить на правильный путь.
🔥5👍1
8. Погружение через обучение других. Когда начали понимать - помогайте, и при этом сам разбираешься.
И в конце это сведено в чек-лист: глоссарий, визуализация, карта взаимодействий, фокус на задачах, изучай в реальности что делаешь, не пытайся объять необъятное, изучай в реальности что делаешь, не пытайся объять необъятное, фокусируйся на своих сильных сторонах, обращайся к опыту и помощи экспертов, погружайся через помощь менее опытным.
И есть смысл многое вынести в онбординг в команду. Например, глоссарий.
На этом все. А я в заключении хочу резюмировать и дополнить, что по сути есть две стороны. Во-первых, надо выкинуть свои комплексы. Синдром самозванца, стеснительность некомпетентности и так далее. И доклад был во многом об этом. А во-вторых, надо прокачивать концептуальное мышление. Не собирать картинку из кусочков, как делают сенсорики, а создавать концепции, как делают интуиты (сенсорик-интуит - это одна из дихотомий MBTI). Практически это второй пункт, визуализация, просто интуиты быстро выходят на схему верхнего уровня, применяя что-то известное из своей модели мира, которую потом доопределяют, они не работают с чистого листа.
И в конце это сведено в чек-лист: глоссарий, визуализация, карта взаимодействий, фокус на задачах, изучай в реальности что делаешь, не пытайся объять необъятное, изучай в реальности что делаешь, не пытайся объять необъятное, фокусируйся на своих сильных сторонах, обращайся к опыту и помощи экспертов, погружайся через помощь менее опытным.
И есть смысл многое вынести в онбординг в команду. Например, глоссарий.
На этом все. А я в заключении хочу резюмировать и дополнить, что по сути есть две стороны. Во-первых, надо выкинуть свои комплексы. Синдром самозванца, стеснительность некомпетентности и так далее. И доклад был во многом об этом. А во-вторых, надо прокачивать концептуальное мышление. Не собирать картинку из кусочков, как делают сенсорики, а создавать концепции, как делают интуиты (сенсорик-интуит - это одна из дихотомий MBTI). Практически это второй пункт, визуализация, просто интуиты быстро выходят на схему верхнего уровня, применяя что-то известное из своей модели мира, которую потом доопределяют, они не работают с чистого листа.
🔥3
#Teamlead Антон Огородников из Mаgnit Tech. Инженерная культура. Что это и почему она важна? У бизнеса компании есть продуктовая культура со своими принципами. Они были на слайде, но я не успел записать. А у ИТ - инженерная культура, обеспечивающая поддержку бизнеса. Принципы формулировали на уровне руководства ИТ.
1. Здоровье сервиса - нулевой приоритет. Если у тебя проблемы с продом - ты чинишь. А не сидишь на встрече с руководителем. Ты покрываешь сервис метриками, чтобы следить за его здоровьем, не катишь без метрик, не переключаешься на другие фичи.
2. Инцидент - незапланированная инвестиция в стабильность сервиса. Инцидент - нормально. Но если он произошел - сделай вклад в стабильность. Упала база, сервис - не рестарт, а постмортен и разбор причин с их устранением. Ответственность - на команде, доносим до команды целиком.
3. Platform by design. Если есть задача, то (а) поищи этот велосипед в других командах и (б) при разработке подумай об использовании в других командах, особенно если в ходе поиска обнаружил интерес. Сделали, когда в появилось два сервиса авторизации. Обобщение - в ответ на интерес другой команды.
4. Принцип горящего дома. Ситуации - разные, отпуска, болезни. Если есть проблема, то как ее изолировать от других. Ну и потушить. Поднимаем то, что упало, и потом - ищем причины. Кейс - большая кастомизация поверх базового механизма сломалась при обновлении. Сначала - делаем костыль, чтобы поднялось. Потом - хорошее решение и профилактика будущего.
5. Tech follows Business. ИТ поддерживают. Были прецеденты, когда расходились. В частности: мы как ИТ должны уметь давать оценки. Как можем по текущему описанию. Некоторые инженеры - не про бизнес, они про фреймворки и технологии, и таких не берем.
6. We build it - we run it. Команда отвечает за фичу целиком, без функционального деления, от начала и до конца. Люди приходят из разных компаний, у многих сопровождение отдельно, а у них - нет. Команда отвечает за фичи на проде, за данные, которые через себя пропускает, и метрики - чтобы следить за этим.
7. Explicit is Better Then Implicit. Явное лучше неявного. Все, что делаешь должно быть визуализировано и оставлять артефакты. Камеры на встречах, это упрощает коммуникацию и упрощает встречи, невербальная коммуникация. Например Feature release freeze в конце года: мы не катим фичи.
8. Принцип швейцарского ножа. В нем много элементов. Инженер-программист должен стремитсья к тому, чтобы быть универсальным, хотя основное время пользуется 1-2 инструментами. Можно заменить того, кто заболел, не ждете его.
Выводы
* Культура может являться фундаментом
* Нет плохой и хорошей культуры, есть текущая ситуация
* Заниматься формированием культуры можно начинать, когда становится много
* Культура не высечена в камне, она живет.
Распространение. Сначала продать принципы руководству. А затем закидывать в инженеров точечно. А потом как достигается принятие нужной массой экспертов - распространяют на всех.
1. Здоровье сервиса - нулевой приоритет. Если у тебя проблемы с продом - ты чинишь. А не сидишь на встрече с руководителем. Ты покрываешь сервис метриками, чтобы следить за его здоровьем, не катишь без метрик, не переключаешься на другие фичи.
2. Инцидент - незапланированная инвестиция в стабильность сервиса. Инцидент - нормально. Но если он произошел - сделай вклад в стабильность. Упала база, сервис - не рестарт, а постмортен и разбор причин с их устранением. Ответственность - на команде, доносим до команды целиком.
3. Platform by design. Если есть задача, то (а) поищи этот велосипед в других командах и (б) при разработке подумай об использовании в других командах, особенно если в ходе поиска обнаружил интерес. Сделали, когда в появилось два сервиса авторизации. Обобщение - в ответ на интерес другой команды.
4. Принцип горящего дома. Ситуации - разные, отпуска, болезни. Если есть проблема, то как ее изолировать от других. Ну и потушить. Поднимаем то, что упало, и потом - ищем причины. Кейс - большая кастомизация поверх базового механизма сломалась при обновлении. Сначала - делаем костыль, чтобы поднялось. Потом - хорошее решение и профилактика будущего.
5. Tech follows Business. ИТ поддерживают. Были прецеденты, когда расходились. В частности: мы как ИТ должны уметь давать оценки. Как можем по текущему описанию. Некоторые инженеры - не про бизнес, они про фреймворки и технологии, и таких не берем.
6. We build it - we run it. Команда отвечает за фичу целиком, без функционального деления, от начала и до конца. Люди приходят из разных компаний, у многих сопровождение отдельно, а у них - нет. Команда отвечает за фичи на проде, за данные, которые через себя пропускает, и метрики - чтобы следить за этим.
7. Explicit is Better Then Implicit. Явное лучше неявного. Все, что делаешь должно быть визуализировано и оставлять артефакты. Камеры на встречах, это упрощает коммуникацию и упрощает встречи, невербальная коммуникация. Например Feature release freeze в конце года: мы не катим фичи.
8. Принцип швейцарского ножа. В нем много элементов. Инженер-программист должен стремитсья к тому, чтобы быть универсальным, хотя основное время пользуется 1-2 инструментами. Можно заменить того, кто заболел, не ждете его.
Выводы
* Культура может являться фундаментом
* Нет плохой и хорошей культуры, есть текущая ситуация
* Заниматься формированием культуры можно начинать, когда становится много
* Культура не высечена в камне, она живет.
Распространение. Сначала продать принципы руководству. А затем закидывать в инженеров точечно. А потом как достигается принятие нужной массой экспертов - распространяют на всех.
👍5🔥2
#Teamlead Ольга Муттер из СберМаркет. Прозрачная структура проектов в компании от стратегии до исполнителя. Структуру выстраивали на 100+ команд в 3-уровневой иерархии команда-юнит-домен. Каждая команда живет своей жизнью, у нее свой проект в Jira, разный flow, разные типы задач и виды оценок. У бизнеса проблема - предсказуемость, понять, когда будет сделана фича. А еще им интересно оценить эффективность системы в целом и работать над повышением. Они решали эту задачу 2 года. Четыре компоненты: единая точка входа, ключевые метрики по эффективности, процесс работы с метриками и культура. Есть ее статья "Как подружить проектное управление с продуктовым подходом". Дальше - по пунктам.
1. Единая точка входа. Свой мир Jira в команде оставили, но два года назад сделали единый проект, с обобщенным flow, в котором надо вести все эпики. И смогли посмотреть на работу всей компании однородно. Дальше надо было всех заставить там работать. Это - отдельный доклад. Был пилот на нескольких командах, потом директива. И это была первая итерация.
Вторая итерация - новый тип работ - инициатива. Инициатива - это направление бизнеса, нацеленное на изменение бизнес-метрик компании. К ним должны быть привязаны все эпики, и это дает связь эпиков со стратегией. И можно было увидеть, куда тратим время и ресурсы. Появилось единообразие полей, отчеты и метрики.
С апреля 2024 следующая итерация - перенести в Jira discovery. Тип работы Идея, и тоже привязан к стратегии через инициативы. И бизнес-требования, замена Excel с бэклогом. Получается трассировка: Стратегия - Инициативы - Идеи, Эпики и бизнес-требования. Решилась проблема приоритизации, потому что инициативы имеют приоритет.
Этот путь требовал много работы: воркшопы обучения, шаблоны structure представления информации, дерево продуктовых меток, плагины wip-лимитов, доски под все нужды, дашборды визуализации работ, документация, сбор обратной связи, чат поддержки.
2. Метрики. Что есть эффективность для ИТ и как выражается? Проблема бизнеса: не понимаем, когда команда разработки это сделает. Постоянные переносы.
1. lead time - сроки поставки ценности
2. точность поставки - попадание в сроки
3. объем поставки - эффективность использую ресурсы
4. Эффективность поставки - чтобы не было делаю за час в течении недели
Урок: сначала накопите статистику lead time, а потом ставьте целевые значения. Они поставили сразу, и потом долго с этим мучились - команды заметали сложности под ковер и так далее.
Метрики показали, какой этап сколько занимает и какие разбросы. И позволил с этим точечно работать в разных командах. Работа часто останавливается по внешним причинам, и было добавлены блокеры разных видов, которая команда вешала, когда встречалась с этим, а дальше вели анализ и устраняли проблемы.
У всех готовы объяснения, почему lead time нельзя улучшить. Опыт показывает, что можно - но надо проводить анализ. Поэтому на входе нельзя идти в персонализацию, надо чтобы люди научились вести анализ метрик, разбираться в проблемах? это должно стать частью культуры работы.
Целевые метрики - менялись. Добавили: t2m, cycle time discovery, value, % отмен. value - что приносим ценность, а не просто делаем объем работ. Но мерить - сложно, пока тут проблемы. Системы можно взломать, они следят и работают через контр-метрики, это - постоянный процесс.
3. Процесс. Есть поддержка от вице-президента по технологиям. Точки контроля на уровне компании - в OKR появились процессные метрики. KPI тоже пробовали, там грабли. B Performance review. Для метрик - int-autometion-bot с уведомлениями - предсказание, что не попадешь в сроки, изменение метрики и так далее.
Анализ цепочки поставки - оценка каждого этапа поставки. Кластеризация проблем - по фазам. Проблема-влияние-ответственный-решение. После анализа: Проактивные действия - здесь и сейчас, и системные улучшения, которые делают итерациями.
1. Единая точка входа. Свой мир Jira в команде оставили, но два года назад сделали единый проект, с обобщенным flow, в котором надо вести все эпики. И смогли посмотреть на работу всей компании однородно. Дальше надо было всех заставить там работать. Это - отдельный доклад. Был пилот на нескольких командах, потом директива. И это была первая итерация.
Вторая итерация - новый тип работ - инициатива. Инициатива - это направление бизнеса, нацеленное на изменение бизнес-метрик компании. К ним должны быть привязаны все эпики, и это дает связь эпиков со стратегией. И можно было увидеть, куда тратим время и ресурсы. Появилось единообразие полей, отчеты и метрики.
С апреля 2024 следующая итерация - перенести в Jira discovery. Тип работы Идея, и тоже привязан к стратегии через инициативы. И бизнес-требования, замена Excel с бэклогом. Получается трассировка: Стратегия - Инициативы - Идеи, Эпики и бизнес-требования. Решилась проблема приоритизации, потому что инициативы имеют приоритет.
Этот путь требовал много работы: воркшопы обучения, шаблоны structure представления информации, дерево продуктовых меток, плагины wip-лимитов, доски под все нужды, дашборды визуализации работ, документация, сбор обратной связи, чат поддержки.
2. Метрики. Что есть эффективность для ИТ и как выражается? Проблема бизнеса: не понимаем, когда команда разработки это сделает. Постоянные переносы.
1. lead time - сроки поставки ценности
2. точность поставки - попадание в сроки
3. объем поставки - эффективность использую ресурсы
4. Эффективность поставки - чтобы не было делаю за час в течении недели
Урок: сначала накопите статистику lead time, а потом ставьте целевые значения. Они поставили сразу, и потом долго с этим мучились - команды заметали сложности под ковер и так далее.
Метрики показали, какой этап сколько занимает и какие разбросы. И позволил с этим точечно работать в разных командах. Работа часто останавливается по внешним причинам, и было добавлены блокеры разных видов, которая команда вешала, когда встречалась с этим, а дальше вели анализ и устраняли проблемы.
У всех готовы объяснения, почему lead time нельзя улучшить. Опыт показывает, что можно - но надо проводить анализ. Поэтому на входе нельзя идти в персонализацию, надо чтобы люди научились вести анализ метрик, разбираться в проблемах? это должно стать частью культуры работы.
Целевые метрики - менялись. Добавили: t2m, cycle time discovery, value, % отмен. value - что приносим ценность, а не просто делаем объем работ. Но мерить - сложно, пока тут проблемы. Системы можно взломать, они следят и работают через контр-метрики, это - постоянный процесс.
3. Процесс. Есть поддержка от вице-президента по технологиям. Точки контроля на уровне компании - в OKR появились процессные метрики. KPI тоже пробовали, там грабли. B Performance review. Для метрик - int-autometion-bot с уведомлениями - предсказание, что не попадешь в сроки, изменение метрики и так далее.
Анализ цепочки поставки - оценка каждого этапа поставки. Кластеризация проблем - по фазам. Проблема-влияние-ответственный-решение. После анализа: Проактивные действия - здесь и сейчас, и системные улучшения, которые делают итерациями.
❤1
4. Культура. Она не строится за месяц или за квартал. Она в том, что все понимают, что нужна задача верхнего уровня именно в общем проекте. Так устроено. Все задачи подвязаны. И бизнес появился именно поэтому вместо Excel. Работа на всех уровнях VP, EM/CPO, Unit lead, team lead. Распространение с обратной связью.
Как починили проблему? Тимлид - мини-CTO, он понимает, как он на уровне всей компании влияет на то, что компания делает. А бизнес может по каждой команде посмотреть скорость работы, попадание в обещания и построить прогноз.
В заключении я хочу отметить, что 10 с небольшим лет назад я слушал доклад про то, как в Касперском ставли единообразие процессов обработки задач и отметить разнообразие подхода. Там главным была общая система и одинаковый workflow для всех типов задач, без отдельного пространства для команд, и меряли единые характеристики, а все особые случаи согласовывал комитет по изменениям уровня компании, и их на всю компанию была пара случаев. А вот речь о трассировке задач до уровня стратегии - не шла. А в этом случае задачей было обеспечить единообразное представление только на верхнем уровне, и построить трассировку до стратегии, которую обвесить метриками. С моей точки зрения, это характеризует изменения, произошедшие за это время в культуре отрасли в целом.
Как починили проблему? Тимлид - мини-CTO, он понимает, как он на уровне всей компании влияет на то, что компания делает. А бизнес может по каждой команде посмотреть скорость работы, попадание в обещания и построить прогноз.
В заключении я хочу отметить, что 10 с небольшим лет назад я слушал доклад про то, как в Касперском ставли единообразие процессов обработки задач и отметить разнообразие подхода. Там главным была общая система и одинаковый workflow для всех типов задач, без отдельного пространства для команд, и меряли единые характеристики, а все особые случаи согласовывал комитет по изменениям уровня компании, и их на всю компанию была пара случаев. А вот речь о трассировке задач до уровня стратегии - не шла. А в этом случае задачей было обеспечить единообразное представление только на верхнем уровне, и построить трассировку до стратегии, которую обвесить метриками. С моей точки зрения, это характеризует изменения, произошедшие за это время в культуре отрасли в целом.
👍5🔥2
#Teamlead Игорь Курочкин. Как стать 10x экспертом. Основная идея доклада: экспертность сейчас определяется не накопленными в мозге знаниями и опытом, а мощностью личной базы данных, вынесенной из головы во внешнюю систему хранения знаний, которая дает возможность быстро решать задачи. И доклад - призыв осознать это и вести собственную базу, дополненный описанием процесса, которым для этого пользуется сам Игорь.
Контекст. Игорь работал с высоконагруженными системами, и несколько лет назад ушел в консалтинг по этой теме вместе с партнером. Проблема - нехватка знаний, потому что есть большое разнообразие технологий и все время появляются новые, техрадар за 15 лет накопил 1600+ технологий. И большая нехватка времени в операционной работе, чтобы это освоить. Идет большой поток информации, при этом в нем много шума и мало сигналов, а у предметной области - высокая сложность. Поэтому поиск в тот момент, когда задача уже получена - слабо эффективен. Решение - вести личную базу знаний, в которой накапливать и структурировать информацию заранее. Сейчас у него накоплено 15к заметок и 50к связей, и это - персональная база. У партнера - собственная, иначе организованная, чуть меньшего масштаба - 10к заметок, и когда они решают вопрос, то идет взаимное ревью или совместное решение, при котором каждый использует свою базу.
Как он это делает? Первое - надо организовать входящий поток ограниченной мощности, который ты успеваешь перерабатывать. Он подписан на профессиональные соцсети в linkedin и github и ряд профессиональных блогов по теме. А также почтовые рассылки - они все еще живы, и среди платных есть качественные, надо отбирать. Вопрос доверия к автору. Есть платные относительно качественные. Получается лента под себя, которую разбираешь пару раз в неделю. Далее, поиск. Помимо личной базы знаний, выполняешь поиск в почте, где собраны рассылки, и настраиваешь Google CSE, ограничивая список URL, где ищем. У него в индексе 884 блога - инженерные техблоги разных компаний. И прикрутили валидацию и проверку источников. А при разборе рассылок - еще анализируют кто, где и что публикует и добавляют в базу источников.
Второе - систематизация. Быстро переработать большой материал, когда уже пришел запрос - тяжело, надо заранее. И еще вести мысли и заметки, чтобы не повторять. Этапы структурирования:
* Данные - набор фактов.
* Информация - раскрашивание фактов по категориям.
* Знания - граф связей между фактами.
* Озарение (insight) - это связь двух точек.
* А мудрость (wisdom) - видение путей в графе.
У него примерно так: источников данных 10к+, информация 1к, знания 100 узлов, заметки-инсайты 1к, мудрость 10к заметок и *3 связей. За 3 года 15к заметок, 50к связей, 555к слов, 8к картинок, 800 контактов, 800 компаний, 530 конференций и других событий, 465 книг.
Инструменты: obsidian, roam research, logseq, Zettlr. Подходы: lyt/ideaverse, basp/para, Zettlercasten
Наполнение базы знаний - ежедневная работа. 10 заметок в день, примерно одна в час. Надо доверять своей базе знаний. Заметки визуализируются и анализируются, можно увидеть проблемы: заметки без связей и клубки сильно связанного. Нужен рефакторинг и структура. Визуальный граф на таком количестве не работает, а поиск на графах - работает.
Собственно, все. Следующие шаги, который он видит: дайджест или рассылка по списку своих блогов; поиск по tg, github, twitter; персональный дашборд; персональный помощник. НА правах идеи - я бы еще подумал о подключении к этому GPT: сейчас есть доступные технологии, при которым ты подключаешь к GPT собственный массив информации так, что он первично формирует ответ с учетом ее, в чем-то по сути это получается аналог поиска по заданному набору URL, но GPT знает про синонимы и связи понятий, что расширяет контекст.
Контекст. Игорь работал с высоконагруженными системами, и несколько лет назад ушел в консалтинг по этой теме вместе с партнером. Проблема - нехватка знаний, потому что есть большое разнообразие технологий и все время появляются новые, техрадар за 15 лет накопил 1600+ технологий. И большая нехватка времени в операционной работе, чтобы это освоить. Идет большой поток информации, при этом в нем много шума и мало сигналов, а у предметной области - высокая сложность. Поэтому поиск в тот момент, когда задача уже получена - слабо эффективен. Решение - вести личную базу знаний, в которой накапливать и структурировать информацию заранее. Сейчас у него накоплено 15к заметок и 50к связей, и это - персональная база. У партнера - собственная, иначе организованная, чуть меньшего масштаба - 10к заметок, и когда они решают вопрос, то идет взаимное ревью или совместное решение, при котором каждый использует свою базу.
Как он это делает? Первое - надо организовать входящий поток ограниченной мощности, который ты успеваешь перерабатывать. Он подписан на профессиональные соцсети в linkedin и github и ряд профессиональных блогов по теме. А также почтовые рассылки - они все еще живы, и среди платных есть качественные, надо отбирать. Вопрос доверия к автору. Есть платные относительно качественные. Получается лента под себя, которую разбираешь пару раз в неделю. Далее, поиск. Помимо личной базы знаний, выполняешь поиск в почте, где собраны рассылки, и настраиваешь Google CSE, ограничивая список URL, где ищем. У него в индексе 884 блога - инженерные техблоги разных компаний. И прикрутили валидацию и проверку источников. А при разборе рассылок - еще анализируют кто, где и что публикует и добавляют в базу источников.
Второе - систематизация. Быстро переработать большой материал, когда уже пришел запрос - тяжело, надо заранее. И еще вести мысли и заметки, чтобы не повторять. Этапы структурирования:
* Данные - набор фактов.
* Информация - раскрашивание фактов по категориям.
* Знания - граф связей между фактами.
* Озарение (insight) - это связь двух точек.
* А мудрость (wisdom) - видение путей в графе.
У него примерно так: источников данных 10к+, информация 1к, знания 100 узлов, заметки-инсайты 1к, мудрость 10к заметок и *3 связей. За 3 года 15к заметок, 50к связей, 555к слов, 8к картинок, 800 контактов, 800 компаний, 530 конференций и других событий, 465 книг.
Инструменты: obsidian, roam research, logseq, Zettlr. Подходы: lyt/ideaverse, basp/para, Zettlercasten
Наполнение базы знаний - ежедневная работа. 10 заметок в день, примерно одна в час. Надо доверять своей базе знаний. Заметки визуализируются и анализируются, можно увидеть проблемы: заметки без связей и клубки сильно связанного. Нужен рефакторинг и структура. Визуальный граф на таком количестве не работает, а поиск на графах - работает.
Собственно, все. Следующие шаги, который он видит: дайджест или рассылка по списку своих блогов; поиск по tg, github, twitter; персональный дашборд; персональный помощник. НА правах идеи - я бы еще подумал о подключении к этому GPT: сейчас есть доступные технологии, при которым ты подключаешь к GPT собственный массив информации так, что он первично формирует ответ с учетом ее, в чем-то по сути это получается аналог поиска по заданному набору URL, но GPT знает про синонимы и связи понятий, что расширяет контекст.
🔥10❤3
Меня лично этот доклад заставил задуматься - а почему я не пользуюсь подобной системой личных заметок? Наверное, потому, что нарабатывал навыки работы со знаниями, когда компьютеры для этого были не доступны. А потом освоил предыдущий стек, вики-системы, которые мы в компании применяем с 2005 года, в которых вел персональные заметки наряду с проектными. При этом персональных заметок всегда было не много, потому что освоение новых областей практически всегда шло в рамках проектной деятельности. А, заметив интересное помимо проекта - тоже старался поделиться в виде блога, который с 2010 стал еще и публичным, к 2014 превратившись в собственный сайт. И как-то сложилось, что освоение новых тем я тоже делаю в публичном пространстве. Так было с конспектом лекций Петра Щедровицкого по СРТ. Так произошло с моделями soft skill, которые я собрал в модель личности: были доклады, потом - статьи и книга, в процессе подготовки было много заметок, но они вошли в книгу, остались только наборы ссылок-источников, которые вполне помещаются в GoogleDocs. Впрочем, может быть это объяснение "от ответа", чтобы не делать. Но, в любом случае я активно использую поиск по своему сайту при работе над разными вопросами, и регулярно нахожу очень интересные материалы собственного авторства :)
🔥11
#Teamdlead Александра Прокшина из Авито. Искусство спрашивать, или 42 вопроса, которые ускорят развитие вашей команды и вас самих. Очень хороший доклад из тех, в которых автор говорит вроде знакомые и известные вещи, но рассказывает это настолько хорошо, а материал так сфокусирован, что ты обновляешь у себя это в памяти, практически переоткрываешь заново. И это не только рассказ, но и презентация, где на слайде - просто вопросы, по одному или малой группой, но в них подсвечены ключевые моменты. Дальше - сами вопросы с краткими комментариями. Я чуть опоздал, так что начинаю с группы про испытательный срок.
Об испытательном сроке - вопросы поступающего на работу.
* Как вы узнаете, что я успешно прошел испытательный срок?
* Что важное надо сделать 90 дней?
* Как проявить чтобы добиться успеха в вашей компании?
* Каких навыков не хватает команде, куда я прихожу?
Последние два - подстройка под конкретную компанию, это важно.
Вопросы к сотруднику на регулярной встрече.
* Не "Как дела", а "Что самого интересного сделал за неделю?" - это стимулирует воспоминания. Кстати, его можно применять не только на встречах, я знаю руководителя высокого уровня, который регулярно, проходя по офису, спрашивает почти у всех в коридоре "Ну, что новенького, что интересненького?".
* Не "Как я могу помочь", а "Что для тебя самое сложное в работе?" - часто люди не просят помощи, чтобы на проявить слабость, а такой вопрос подсвечивает трудности, и дальше можно по-разному раскручивать диалог.
* Какую обратную связь ты хотел бы получать чаще? Кейс к вопросу: есть классный спец, ему говорят "ты классный", а он говорит "мне не хватает обратной связи - развивающей"
* Важно ли тебе, чтобы тебя хвалили? Тут у всех разная потребность, одним важно каждую неделю услышать хорошее, а другим - только когда неординарное сделал.
* Есть ли какая-то работа, которая была недооценена за последнее время? Возможно, что-то не заметили, а он гордится и ожидал похвалы
* Какие сильные стороны ты НЕ используешь в работе? Может, что-то не используется, нам нужно а мы не знаем, а человек страдает?
Вопросы руководителю.
* Есть что-то, что я по твоему мнению должна делать, но не делаю?
* В каком случае мне просить твоей помощи?
* О каких ситуациях мне нужно тебя уведомлять? Акценты руководителя бывают разные
* Какие мои точки роста ты видишь сейчас?
* Что мне нужно делать, чтобы получать x2? Не когда уже хотите повышения, а заранее, чтобы сделать план и пойти по нему.
Что общего в хороших вопросах.
* Есть промежуток времени. Не вообще, а конкретно.
* Крайности: самое важное, интересное, сложное
* Вопросы-аналогии, с чем бы ты сравнил что-то
* Шкалы 1-10. Оцените довольство зарплатой, насколько склонен уволиться
* Обращайте внимание на то, чего нет, не хватает
Вопросы себе. Это важная часть самоопределения и рефлексии.
* Зачем я это делаю? Зачем пришел на эту конференцию, работаю на этой работе, дела этот проект
* Квадрат Декарта для самоопределения: что будет/не будет если это произойдет/не произойдет.
* Расширение предыдущего: что будет, если этого не произойдет никогда? Это работает против бесконечного откладывания решения об изменениях.
* Если я буду продолжать делать то, что сейчас, буду ли я доволен собой результатом через год? Тоже против того, чтобы не меняться.
* Есть ли кто-то, кто уже решал похожую проблему. Вряд ли твоя проблема уникальна.
* А что бы на моем месте сделал авторитетный (для вас, подставить имя) человек?
* Рефлексия дня. Что нового я узнал сегодня? Как это может быть полезно? Что нового я начну делать завтра?
Резюме
* Вопросы - инструмент для установления связей и решения проблем
* Хорошие вопросы могут вывести коммуникацию на следующий уровень
* Не недооценивайте уточняющие вопросы
В вопросах к докладу: а как быть с социально ожидаемыми ответами? Она за прозрачность, может спросить "а насколько ты честен/откровенен со мной 1-10?", или даже явно "Я думаю, что ты тут не договариваешь примерно это", особенно если есть альтернативная информация. И это - помогает.
Об испытательном сроке - вопросы поступающего на работу.
* Как вы узнаете, что я успешно прошел испытательный срок?
* Что важное надо сделать 90 дней?
* Как проявить чтобы добиться успеха в вашей компании?
* Каких навыков не хватает команде, куда я прихожу?
Последние два - подстройка под конкретную компанию, это важно.
Вопросы к сотруднику на регулярной встрече.
* Не "Как дела", а "Что самого интересного сделал за неделю?" - это стимулирует воспоминания. Кстати, его можно применять не только на встречах, я знаю руководителя высокого уровня, который регулярно, проходя по офису, спрашивает почти у всех в коридоре "Ну, что новенького, что интересненького?".
* Не "Как я могу помочь", а "Что для тебя самое сложное в работе?" - часто люди не просят помощи, чтобы на проявить слабость, а такой вопрос подсвечивает трудности, и дальше можно по-разному раскручивать диалог.
* Какую обратную связь ты хотел бы получать чаще? Кейс к вопросу: есть классный спец, ему говорят "ты классный", а он говорит "мне не хватает обратной связи - развивающей"
* Важно ли тебе, чтобы тебя хвалили? Тут у всех разная потребность, одним важно каждую неделю услышать хорошее, а другим - только когда неординарное сделал.
* Есть ли какая-то работа, которая была недооценена за последнее время? Возможно, что-то не заметили, а он гордится и ожидал похвалы
* Какие сильные стороны ты НЕ используешь в работе? Может, что-то не используется, нам нужно а мы не знаем, а человек страдает?
Вопросы руководителю.
* Есть что-то, что я по твоему мнению должна делать, но не делаю?
* В каком случае мне просить твоей помощи?
* О каких ситуациях мне нужно тебя уведомлять? Акценты руководителя бывают разные
* Какие мои точки роста ты видишь сейчас?
* Что мне нужно делать, чтобы получать x2? Не когда уже хотите повышения, а заранее, чтобы сделать план и пойти по нему.
Что общего в хороших вопросах.
* Есть промежуток времени. Не вообще, а конкретно.
* Крайности: самое важное, интересное, сложное
* Вопросы-аналогии, с чем бы ты сравнил что-то
* Шкалы 1-10. Оцените довольство зарплатой, насколько склонен уволиться
* Обращайте внимание на то, чего нет, не хватает
Вопросы себе. Это важная часть самоопределения и рефлексии.
* Зачем я это делаю? Зачем пришел на эту конференцию, работаю на этой работе, дела этот проект
* Квадрат Декарта для самоопределения: что будет/не будет если это произойдет/не произойдет.
* Расширение предыдущего: что будет, если этого не произойдет никогда? Это работает против бесконечного откладывания решения об изменениях.
* Если я буду продолжать делать то, что сейчас, буду ли я доволен собой результатом через год? Тоже против того, чтобы не меняться.
* Есть ли кто-то, кто уже решал похожую проблему. Вряд ли твоя проблема уникальна.
* А что бы на моем месте сделал авторитетный (для вас, подставить имя) человек?
* Рефлексия дня. Что нового я узнал сегодня? Как это может быть полезно? Что нового я начну делать завтра?
Резюме
* Вопросы - инструмент для установления связей и решения проблем
* Хорошие вопросы могут вывести коммуникацию на следующий уровень
* Не недооценивайте уточняющие вопросы
В вопросах к докладу: а как быть с социально ожидаемыми ответами? Она за прозрачность, может спросить "а насколько ты честен/откровенен со мной 1-10?", или даже явно "Я думаю, что ты тут не договариваешь примерно это", особенно если есть альтернативная информация. И это - помогает.
🔥8👍3❤1
На прошлой неделе в Питере прошли #Highload и #Teamlead. Я участвовал в обоих, публиковал заметки с докладов, а сейчас публикую отчет https://mtsepkov.org/Saint-2024, в котором добавил общие впечатления и объединил обе конференции. Не все участники одной были на другой, так что общий отчет, думаю, будет интересен. Читайте! Помимо докладов, на конференциях было много интересного общения но это, увы, остается за рамками.
👍9❤1
Работаю над книгой. У меня просьба ко всем читателям: оставьте отзывы, они помогут ориентироваться тем, кто не знаком, плюс наличие отзывов учитывается в рекомендациях. Книга сделана на ridero, но доступна на многих площадках: litres, ozon, bookmate, wiliberries и других и отзывы полезны везде.
А я получил свою книгу в бумажном виде, она ждала меня в Москве пока я был в Питере. Переживал за иллюстрации, но они почти все читаемы, лишь на некоторых черно-белый вариант убрал контрастность изображения. А вот со ссылками - беда, надо делать читаемые варианты. Буду править, и сделаю страничку со ссылками, чтобы открыть и легко переходить.
А я получил свою книгу в бумажном виде, она ждала меня в Москве пока я был в Питере. Переживал за иллюстрации, но они почти все читаемы, лишь на некоторых черно-белый вариант убрал контрастность изображения. А вот со ссылками - беда, надо делать читаемые варианты. Буду править, и сделаю страничку со ссылками, чтобы открыть и легко переходить.
👍19⚡3❤3
И снова про книгу https://ridero.ru/books/inzhenernaya_model_lichnosti/ - хотя читающих бумажный вариант - меньшинство, они есть и я доработал иллюстрации, чтобы они нормально получались в черно-белом варианте, а еще добавил QR-коды для ссылок в каждой главе. И опубликовал как обновление книги, у тех, кто уже купил электронную, обновление появится. Я должен извиниться перед теми, кто уже купил бумажную книгу, что не сделал так сразу. Но это - мой первый опыт издания бумажной книги, Менеджмент цифрового мира вышел только в электронной версии. Возможно, я его тоже теперь подготовлю для бумаги.
ridero.ru
Инженерная модель личности
Книга "Инженерная модель личности". "Меняя себя и других — понимай устройство" - Максим Цепков - печатная, электронная: epub, fb2, pdfRead, mobi - Для работы с развитием сотрудников и своими собственным, эффективной коммуникации и совместной работы полезно…
👍9❤4
Сегодня на #lafest, одна из моих любимых конференций, в которой я участвую с 2010 года, хотя и с перерывами. И у меня открывающий доклад про модель личности, построенную на связке психологических моделей с нейрофизиологией. У меня об этом книга, но там модель изложена от базовых уровней к прикладным, а в докладе я буду рассказывать наоборот, от практических применений. Хотя в любом случае это будет краткий обзор. Презентация уже опубликована у меня на сайте https://mtsepkov.org/SoftSkillsLAF
👍8❤🔥3
#lafest Алексей Трошин. Инструменты командного планирования для тимлида. Рассказ о том, как получить оценки по новым задачам, когда еще даже непонятно что делать. С практиками ссылками на статьи и примерами. Четыре этапа: Декомпозиция - Оценка - Этапы - Сроки.
1. Декомпозиция - есть разные варианты. Садитесь с командой и выписываете на стикерах. Получаете - иерархическая структура работ. Эпик - Такс - Субтаск. И с ее помощью отслеживают. И есть плугины для сложной Structure - и он делает произвольную структуру и появляются графики.
2. Оценка. Есть хорошая статья Андрей Летюшев. Путеводитель по оценкам задач и котики. https://habr.com/ru/articles/742364/ Оценка не является обязательством. Это предварительное представление. Они могут и должны изменяться. Программисты не любят оценки. Они отвечают "1 день", делая ввиду, что сделают какой-то прототип, который как-то заработает. А там - посмотрим. Этого менеджер не понимает.
Planing poker. Смысл карт в закрытую - чтобы зафиксировать разницу мнений. Если оценки близкие - значит есть понимание что надо делать. Если большие различия - значит разные представления. А если оценка большая - значит большая неопределенность, надо вынести исследовательскую задачу.
Механика story point - есть статья https://habr.com/ru/articles/489500 И пересчет sp в трудоемкости.
Риски не закладываются в оценку, они отдельно.
3. Этапы. user story mapping. Дальше делаем поэтпаное выполнение. Есть дополнительные активности, влияющие на сроки: найм, инфраструктура, доступы, лицензии, закупки. Это может двигать сроки, а в задачах на разработку этого нет.
Приоритизация Статья https://spark.ru/user/34904/blog/34748/20-tehnik-prioritizatsii-v-produkte-karta-i-rukovodstvo 20 техник приоритизации в продукте: карта и руководство
Техники MVP minimal viable product и MMF - minimal marketable feature. Примеры.
* Поиск - сначала по названию, посмотреть как используют.
* Новость - как есть, потом умный редактор, потом массовое.
* Поиск авиабилетов - сначала медленно с крутилкой, потом ускоряем.
* Оплаты - сначала 1 способ, потмо добавляем.
* Загрузка каталога в формате Яндекс-маркета: сначала вручную из файла командой, потом скрипты - уже можно наполнять массово, потом ui без обработки ошибок, потмо разбор ошибок.
4. Сроки. Их всегда два: запланирвоанный и желаемый. Они не совпадают. Когда сделали - надо проверить и исправить. Должен быть запас, и с учетом праздников.
Нетривиально: Пришпоренная лошадь бежит быстрее, а команды под давлением работают меленнее.
Итак, алгоритм командного планирования. Когда надо оценить, а мы еще не знаем что это такое. Кейс: дизайнер нарисовал дизайн нового кабинета, и босс спрашивает - когда сделаете. Фронт смотрит, у него много вопросов - а нужен срок. Прошли по алгоритму, и команда нечто смогла сказать. И команда - выполняет упражнение, а не выдает срок.
* Декомпозируем: главная страница, еще страницы, инфраструктура и т.д. Стараемся не забыть.
* Берем понятную, но не самую простую работу. Потом следующий - оцениваем по предыдущей - сложнее или проще. Растаскиваем по горизонтальной шкале условной оценки. И вешаем майки на ось. Размер увеличивает срок вдвое. Важно: много сделано, но никаких сроков и дат не называем.
* Дальше коэффициент пересчета размеров в трудоемкости или сроки.
* Проверка реалистичности оценки.
* Определяем скоуп первого этапа - что и когда покажем заказчику как первую версию. Как только заказчик увидит прототип - он забудет про вторую дату, и начнет креативить.
* Смотрим календарь, не забываем внешние задачи и работы. Включая сроки найма, если надо.
Я хочу заметить, что вопрос о первом демо - реально ключевой, надо делать как можно быстрее. Потому что после этого при правильной организации действительно есть вовлечение заказчика, сотрудничество, и дальше проект идет естественным образом.
Команда соучаствует в оценке - и это важно. Это работает как эффект ИКЕА: The IKEA effect and how I screwed up https://www.jeremybrown.tech/the-ikea-effect/
1. Декомпозиция - есть разные варианты. Садитесь с командой и выписываете на стикерах. Получаете - иерархическая структура работ. Эпик - Такс - Субтаск. И с ее помощью отслеживают. И есть плугины для сложной Structure - и он делает произвольную структуру и появляются графики.
2. Оценка. Есть хорошая статья Андрей Летюшев. Путеводитель по оценкам задач и котики. https://habr.com/ru/articles/742364/ Оценка не является обязательством. Это предварительное представление. Они могут и должны изменяться. Программисты не любят оценки. Они отвечают "1 день", делая ввиду, что сделают какой-то прототип, который как-то заработает. А там - посмотрим. Этого менеджер не понимает.
Planing poker. Смысл карт в закрытую - чтобы зафиксировать разницу мнений. Если оценки близкие - значит есть понимание что надо делать. Если большие различия - значит разные представления. А если оценка большая - значит большая неопределенность, надо вынести исследовательскую задачу.
Механика story point - есть статья https://habr.com/ru/articles/489500 И пересчет sp в трудоемкости.
Риски не закладываются в оценку, они отдельно.
3. Этапы. user story mapping. Дальше делаем поэтпаное выполнение. Есть дополнительные активности, влияющие на сроки: найм, инфраструктура, доступы, лицензии, закупки. Это может двигать сроки, а в задачах на разработку этого нет.
Приоритизация Статья https://spark.ru/user/34904/blog/34748/20-tehnik-prioritizatsii-v-produkte-karta-i-rukovodstvo 20 техник приоритизации в продукте: карта и руководство
Техники MVP minimal viable product и MMF - minimal marketable feature. Примеры.
* Поиск - сначала по названию, посмотреть как используют.
* Новость - как есть, потом умный редактор, потом массовое.
* Поиск авиабилетов - сначала медленно с крутилкой, потом ускоряем.
* Оплаты - сначала 1 способ, потмо добавляем.
* Загрузка каталога в формате Яндекс-маркета: сначала вручную из файла командой, потом скрипты - уже можно наполнять массово, потом ui без обработки ошибок, потмо разбор ошибок.
4. Сроки. Их всегда два: запланирвоанный и желаемый. Они не совпадают. Когда сделали - надо проверить и исправить. Должен быть запас, и с учетом праздников.
Нетривиально: Пришпоренная лошадь бежит быстрее, а команды под давлением работают меленнее.
Итак, алгоритм командного планирования. Когда надо оценить, а мы еще не знаем что это такое. Кейс: дизайнер нарисовал дизайн нового кабинета, и босс спрашивает - когда сделаете. Фронт смотрит, у него много вопросов - а нужен срок. Прошли по алгоритму, и команда нечто смогла сказать. И команда - выполняет упражнение, а не выдает срок.
* Декомпозируем: главная страница, еще страницы, инфраструктура и т.д. Стараемся не забыть.
* Берем понятную, но не самую простую работу. Потом следующий - оцениваем по предыдущей - сложнее или проще. Растаскиваем по горизонтальной шкале условной оценки. И вешаем майки на ось. Размер увеличивает срок вдвое. Важно: много сделано, но никаких сроков и дат не называем.
* Дальше коэффициент пересчета размеров в трудоемкости или сроки.
* Проверка реалистичности оценки.
* Определяем скоуп первого этапа - что и когда покажем заказчику как первую версию. Как только заказчик увидит прототип - он забудет про вторую дату, и начнет креативить.
* Смотрим календарь, не забываем внешние задачи и работы. Включая сроки найма, если надо.
Я хочу заметить, что вопрос о первом демо - реально ключевой, надо делать как можно быстрее. Потому что после этого при правильной организации действительно есть вовлечение заказчика, сотрудничество, и дальше проект идет естественным образом.
Команда соучаствует в оценке - и это важно. Это работает как эффект ИКЕА: The IKEA effect and how I screwed up https://www.jeremybrown.tech/the-ikea-effect/
👍8❤1