Конспект курса «Управление проектами, людьми и собой» Николая Товеровского
Последние несколько месяцев часто обращаюсь к записям, которые делал на курсе Товеровскго уже больше 3 лет назад. Оказалось, что в моей новой команде не все знают, что такое флексить, зачем нужно прибивать гусеницу и фиксировать дедлайн, почему именно исполнитель понимает задачу, что на самом деле значит «сделать», почему важно делать не в притык и концентрироваться на пользе.
Это нормально, хоть и непривычно. Раньше я работал преимущественно в разработке на заказ или маленьких продуктовых командах, где эти принципы и подходы часто были необходимы для выживания и развития. В функциональном отделе большой успешной компании вопрос о выживании как правило не стоит очень остро, но повышение качества и скорости работы всегда актуально.
Про "fixed price, fixed budget, flexible scope" (ФФФ) я впервые прочитал у 37signals (теперь просто basecamp), но в России именно Бюро Горбунова, их статьи и курсы — один из основных распространителей подхода.
Курс Николай проводит до сих пор. Это не реклама, но я искренне до сих пор советую его всем, кто причастен к управлению в IT, а иногда советую и тем, кто не причастен, но хочет сделать свою работу лучше.
Оцифрованный конспект доступен по ссылке, все три дня в виде коротких заметок и цитат.
https://telegra.ph/Konspekt-kursa-Upravlenie-proektami-lyudmi-i-soboj-Nikolaya-Toverovskogo-09-01
Последние несколько месяцев часто обращаюсь к записям, которые делал на курсе Товеровскго уже больше 3 лет назад. Оказалось, что в моей новой команде не все знают, что такое флексить, зачем нужно прибивать гусеницу и фиксировать дедлайн, почему именно исполнитель понимает задачу, что на самом деле значит «сделать», почему важно делать не в притык и концентрироваться на пользе.
Это нормально, хоть и непривычно. Раньше я работал преимущественно в разработке на заказ или маленьких продуктовых командах, где эти принципы и подходы часто были необходимы для выживания и развития. В функциональном отделе большой успешной компании вопрос о выживании как правило не стоит очень остро, но повышение качества и скорости работы всегда актуально.
Про "fixed price, fixed budget, flexible scope" (ФФФ) я впервые прочитал у 37signals (теперь просто basecamp), но в России именно Бюро Горбунова, их статьи и курсы — один из основных распространителей подхода.
Курс Николай проводит до сих пор. Это не реклама, но я искренне до сих пор советую его всем, кто причастен к управлению в IT, а иногда советую и тем, кто не причастен, но хочет сделать свою работу лучше.
Оцифрованный конспект доступен по ссылке, все три дня в виде коротких заметок и цитат.
https://telegra.ph/Konspekt-kursa-Upravlenie-proektami-lyudmi-i-soboj-Nikolaya-Toverovskogo-09-01
Telegraph
Конспект курса «Управление проектами, людьми и собой» Николая Товеровского
Конспект курса «Управление проектами, людьми и собой» Николая Товеровского в апреле 2016 года. Записи делались для себя, частично отредактированы. Сам курс оставил очень приятное впечатление, как и сам Николай. Пользы было много, советую сходить даже тем…
Про стори поинты от создателя стори поинтов
Я всегда не любил стори поинты, как и оценки для задач и проектов. Если только задуматься, насколько целая индустрия полагается на умение (точнее неумение) угадывать будущее, то сразу отчаяние накатывает. Про движение #NoEstimates и то, как оно немного сдвинуло моё сознание в отношении эстимейтов, я расскажу отдельно. Сегодня хочу поделиться замечательной статьёй про стори поинты от их непосредственного создателя.
В статье прекрасно всё с первого предложения: "I like to say that I may have invented story points, and if I did, I’m sorry now."
Рон Джеффрис рассказывает, как концепт родился в их тусовке XP из идеальных дней, которые домножали на коэффициент, чтобы не путать стейкхолдеров. Как он должен был восстановить равновесие силы, а не ввергнуть её во мрак. Как неплохая идея в итоге чаще всего используется неправильно.
Ключевые моменты:
⁃ стори поинты нельзя использовать, чтобы предсказать, когда что-то будет сделано
⁃ трекать, насколько оценка в стори поинтах, соотнеслась с затратами времени бесполезно
⁃ сравнивать команды на основе умения делать оценки вредно
⁃ эстимейты чаще всего являются попыткой угадать, нельзя воспринимать их как обещание и коммит
⁃ важнее определять самые важные и приоритетные вещи для работы и делать их быстро
⁃ чтобы это было возможно надо резать задачи на кусочки, каждый из которых несёт ценность; стори поинты и оценки в этом не помогают
⁃ Рон идет дальше и говорит, что идеи итераций и спринтов также вторичны и не особо нужны перед знанием, какие следующие фичи принесут наибольшую ценность
⁃ честный ответ на «когда это будет сделано?» при фиксации списка фич «никто на самом деле не знает»
⁃ гораздо лучше идти от обратного: выбрать дату релиза пользователям и до неё сделать как можно больше полезного; оценки и стори поинты тут опять не помогают
Несколько цитат
> The best way to deliver value isn’t more, more, more, it’s to do small valuable things frequently. If instead of estimating stories, we slice them down to “small enough”, we can come to a smooth flow of value, delivering all the time.
> I’ll go further: I’d prefer to avoid iteration or Sprint planning entirely. We wouldn’t work to fill up a budget for the next few weeks: we’d work to have a list of the few most important next things to do.
> It is common practice to make a list of essential features, think about them for a while, and then decide that they define the next release of our product. The next question, of course, is “when will all this be done?”
> The answer is that no one knows.
> It’s far better to pick a close-in date for the next release to customers, and pick as much good stuff into that release as possible. Estimating, be it in story points or gummi bears or even time, gets in the way of this. Where possible, in my opinion, it’s best avoided.
https://ronjeffries.com/articles/019-01ff/story-points/Index.html
Я всегда не любил стори поинты, как и оценки для задач и проектов. Если только задуматься, насколько целая индустрия полагается на умение (точнее неумение) угадывать будущее, то сразу отчаяние накатывает. Про движение #NoEstimates и то, как оно немного сдвинуло моё сознание в отношении эстимейтов, я расскажу отдельно. Сегодня хочу поделиться замечательной статьёй про стори поинты от их непосредственного создателя.
В статье прекрасно всё с первого предложения: "I like to say that I may have invented story points, and if I did, I’m sorry now."
Рон Джеффрис рассказывает, как концепт родился в их тусовке XP из идеальных дней, которые домножали на коэффициент, чтобы не путать стейкхолдеров. Как он должен был восстановить равновесие силы, а не ввергнуть её во мрак. Как неплохая идея в итоге чаще всего используется неправильно.
Ключевые моменты:
⁃ стори поинты нельзя использовать, чтобы предсказать, когда что-то будет сделано
⁃ трекать, насколько оценка в стори поинтах, соотнеслась с затратами времени бесполезно
⁃ сравнивать команды на основе умения делать оценки вредно
⁃ эстимейты чаще всего являются попыткой угадать, нельзя воспринимать их как обещание и коммит
⁃ важнее определять самые важные и приоритетные вещи для работы и делать их быстро
⁃ чтобы это было возможно надо резать задачи на кусочки, каждый из которых несёт ценность; стори поинты и оценки в этом не помогают
⁃ Рон идет дальше и говорит, что идеи итераций и спринтов также вторичны и не особо нужны перед знанием, какие следующие фичи принесут наибольшую ценность
⁃ честный ответ на «когда это будет сделано?» при фиксации списка фич «никто на самом деле не знает»
⁃ гораздо лучше идти от обратного: выбрать дату релиза пользователям и до неё сделать как можно больше полезного; оценки и стори поинты тут опять не помогают
Несколько цитат
> The best way to deliver value isn’t more, more, more, it’s to do small valuable things frequently. If instead of estimating stories, we slice them down to “small enough”, we can come to a smooth flow of value, delivering all the time.
> I’ll go further: I’d prefer to avoid iteration or Sprint planning entirely. We wouldn’t work to fill up a budget for the next few weeks: we’d work to have a list of the few most important next things to do.
> It is common practice to make a list of essential features, think about them for a while, and then decide that they define the next release of our product. The next question, of course, is “when will all this be done?”
> The answer is that no one knows.
> It’s far better to pick a close-in date for the next release to customers, and pick as much good stuff into that release as possible. Estimating, be it in story points or gummi bears or even time, gets in the way of this. Where possible, in my opinion, it’s best avoided.
https://ronjeffries.com/articles/019-01ff/story-points/Index.html
Что впитывать начинающему менеджеру
Последние несколько недель среди прочего постепенно перевожу одного из специалистов QA в роль лида команды тестировщиков. Помимо основной работы на него ложится часть менеджерских забот и хлопот.
В процессе возник вопрос: что можно почитать и где подучиться? Я уже несколько раз отвечал на него для разных людей, но каждый раз вспоминал и составлял список заново. В этот раз зафиксировал, в будущем буду дополнять или изменять.
Речь именно про часть управления процессами и людьми, а не продуктами. Отмечу, что в моём идеальном мире с радугами и пони эти знания полезны не только менеджерам и руководителям, а всем ребятам, кто работает с проектам и людьми, не ограничиваясь сферой IT.
1. Книги https://basecamp.com/books, блог https://m.signalvnoise.com/ и подкаст https://rework.fm/ от компании Basecamp (ex 37signals). Советую, т.к. во многом разделяю их философию. Не везде и не всё применимо в наших реалиях, но вектор правильный. Недавно они выложили в паблик новую книгу https://basecamp.com/shapeup, изучаю прямо сейчас.
2. Курс Товеровского и Бюро https://bureau.ru/educenter/fff/ — как правило советую всем, кто относится к работе в IT, даже если не руководитель, но последним особенно. В сети есть множество неплохих конспектов, мой есть выше в этом канале, на сайте бюро много советов, а у Николая выходит книга на базе курса https://bureau.ru/books/fff/demo/3
3. Для академических целей можно почитать Голдратта. Например, «Цель». Это классика, но с ней надо аккуратно в интерпретациях. На идеях Голдратта организовано много управленческих подходов. Мне нравится ментальная модель конвеера для процессов разработки, но не все её разделяют.
4. Книга "No Estimates" https://oikosofyseries.com/no-estimates-book-order. Интересна для понимания, что можно делать по-другому, и опыт десятилетий в индустрии не обязательно гарантирует, что какая-либо практика полезная и хорошая.
5. По работе с людьми всегда и всем советовал книгу «Общаться с ребёнком. Как?» Гиппенрейтер. Давно не перечитывал, но в своё время много откровений получил оттуда.
6. Ещё в сторону понимания людей и себя: «The Power of Habit» by Charles Duhigg.
7. Советую критично относиться к разрозненным статьям, блогам и телеграм-каналам (такая вот ирония), больше доверять авторскому опыту, но использовать это всё как поддержку для книг, а не замену.
Последние несколько недель среди прочего постепенно перевожу одного из специалистов QA в роль лида команды тестировщиков. Помимо основной работы на него ложится часть менеджерских забот и хлопот.
В процессе возник вопрос: что можно почитать и где подучиться? Я уже несколько раз отвечал на него для разных людей, но каждый раз вспоминал и составлял список заново. В этот раз зафиксировал, в будущем буду дополнять или изменять.
Речь именно про часть управления процессами и людьми, а не продуктами. Отмечу, что в моём идеальном мире с радугами и пони эти знания полезны не только менеджерам и руководителям, а всем ребятам, кто работает с проектам и людьми, не ограничиваясь сферой IT.
1. Книги https://basecamp.com/books, блог https://m.signalvnoise.com/ и подкаст https://rework.fm/ от компании Basecamp (ex 37signals). Советую, т.к. во многом разделяю их философию. Не везде и не всё применимо в наших реалиях, но вектор правильный. Недавно они выложили в паблик новую книгу https://basecamp.com/shapeup, изучаю прямо сейчас.
2. Курс Товеровского и Бюро https://bureau.ru/educenter/fff/ — как правило советую всем, кто относится к работе в IT, даже если не руководитель, но последним особенно. В сети есть множество неплохих конспектов, мой есть выше в этом канале, на сайте бюро много советов, а у Николая выходит книга на базе курса https://bureau.ru/books/fff/demo/3
3. Для академических целей можно почитать Голдратта. Например, «Цель». Это классика, но с ней надо аккуратно в интерпретациях. На идеях Голдратта организовано много управленческих подходов. Мне нравится ментальная модель конвеера для процессов разработки, но не все её разделяют.
4. Книга "No Estimates" https://oikosofyseries.com/no-estimates-book-order. Интересна для понимания, что можно делать по-другому, и опыт десятилетий в индустрии не обязательно гарантирует, что какая-либо практика полезная и хорошая.
5. По работе с людьми всегда и всем советовал книгу «Общаться с ребёнком. Как?» Гиппенрейтер. Давно не перечитывал, но в своё время много откровений получил оттуда.
6. Ещё в сторону понимания людей и себя: «The Power of Habit» by Charles Duhigg.
7. Советую критично относиться к разрозненным статьям, блогам и телеграм-каналам (такая вот ирония), больше доверять авторскому опыту, но использовать это всё как поддержку для книг, а не замену.
Basecamp
Books we’ve written
On top of making Basecamp, we write books about what we’ve learned running our own business. They’re filled with practical advice you won’t find anywhere else.
Выживают наиболее приспособленные
В эволюционном процессе выживает не сильнейший, а тот, кто адаптировался быстрее и лучше. Survival of the fittest.
Точно так же выживают компании и команды, которые лучше адаптируются к реальности, к изменениям, будь это изменения требований, начальства, рынка, трендов. Их процесс более устойчив, неизбежность перемен для них норма. Привет Таллебу и его антихрупкости.
Крутая команда строит свой процесс так, что адаптация и постоянное улучшение становятся частью ежедневной деятельности. В прошлое такая команда смотрит для анализа и выводов, чтобы не наступать на прежние грабли.
Обречённая команда не хочет менять процесс, считая его подходящим. Она фокусируется не на бизнес-ценности, а, например, абстрактном качестве и ненужных деталях или только на себе. В прошлое такая команда смотрит с ностальгией, но не делает выводов, поэтому грабли повторяются.
Адаптация — это не «прогибаться под изменчивый мир», а про осознанность, честность перед собой, умение спорить и договариваться, ясная оценка происходящего, принимать решения и их последствия, признавать риски, учиться на ошибках. И в результате меняться, эволюционировать.
Обречённая команда может стать крутой и выжить. Это не просто и требует сдвигов сознания, ломки, местами признания слабости и просьбы помощи. Но выживание того стоит.
В эволюционном процессе выживает не сильнейший, а тот, кто адаптировался быстрее и лучше. Survival of the fittest.
Точно так же выживают компании и команды, которые лучше адаптируются к реальности, к изменениям, будь это изменения требований, начальства, рынка, трендов. Их процесс более устойчив, неизбежность перемен для них норма. Привет Таллебу и его антихрупкости.
Крутая команда строит свой процесс так, что адаптация и постоянное улучшение становятся частью ежедневной деятельности. В прошлое такая команда смотрит для анализа и выводов, чтобы не наступать на прежние грабли.
Обречённая команда не хочет менять процесс, считая его подходящим. Она фокусируется не на бизнес-ценности, а, например, абстрактном качестве и ненужных деталях или только на себе. В прошлое такая команда смотрит с ностальгией, но не делает выводов, поэтому грабли повторяются.
Адаптация — это не «прогибаться под изменчивый мир», а про осознанность, честность перед собой, умение спорить и договариваться, ясная оценка происходящего, принимать решения и их последствия, признавать риски, учиться на ошибках. И в результате меняться, эволюционировать.
Обречённая команда может стать крутой и выжить. Это не просто и требует сдвигов сознания, ломки, местами признания слабости и просьбы помощи. Но выживание того стоит.
"Shape Up" by Ryan Singer from Basecamp
Слежу за тем, что делают ребята из Basecamp (ex. 37signals) уже лет 10, если не больше. Во многом разделяю их идеи и философию.
Shape Up прочитал с огромным удовольствием. Некоторые идеи уже применял в работе раньше, что-то начал внедрять в процессе прочтения, до некоторых вещей еще предстоит дорасти.
Книга очень практичная, описывает конкретные процессы, которые команда Basecamp использует в своей работе, и принципы, на которых базируются эти процессы.
Собрал ключевые идеи, принципы и цитаты.
https://telegra.ph/Recenziya-na-knigu-Shape-Up-by-Ryan-Singer-from-Basecamp-10-20
Слежу за тем, что делают ребята из Basecamp (ex. 37signals) уже лет 10, если не больше. Во многом разделяю их идеи и философию.
Shape Up прочитал с огромным удовольствием. Некоторые идеи уже применял в работе раньше, что-то начал внедрять в процессе прочтения, до некоторых вещей еще предстоит дорасти.
Книга очень практичная, описывает конкретные процессы, которые команда Basecamp использует в своей работе, и принципы, на которых базируются эти процессы.
Собрал ключевые идеи, принципы и цитаты.
https://telegra.ph/Recenziya-na-knigu-Shape-Up-by-Ryan-Singer-from-Basecamp-10-20
Telegraph
Рецензия на книгу "Shape Up" by Ryan Singer from Basecamp
Shape Up рассказывает в деталях и по шагам, как налажен процесс работы над продуктом в Basecamp от идеи до реализации. Таким образом, чтобы делать действительно ту работу, которая имеет смысл и значение, и делать её вовремя. "Stop Running in Circles and Ship…
Работать нормально
В одной из своих рассылок vas3k (@vas3k_channel) написал:
> «Палю моднейший тренд в айти: работать нормально.»
Фраза меня зацепила. Далее по тексту было пояснение в контексте статьи про 10x engineers. Моё «нормально» созвучно, но всё-таки отличается.
В реальности большинство людей хотят работать нормально. Только это «нормально» у каждого своё. Это как многие злодеи в фильмах думают, что творят добро, только по-своему.
Мне стало любопытно, и я спросил несколько друзей: что для них значит «работать нормально»? Формат ответа был любой, никаких ограничений.
Получилось любопытно. По ссылке несколько ответов и в конце мой.
https://telegra.ph/CHto-znachit-rabotat-normalno-10-28
В одной из своих рассылок vas3k (@vas3k_channel) написал:
> «Палю моднейший тренд в айти: работать нормально.»
Фраза меня зацепила. Далее по тексту было пояснение в контексте статьи про 10x engineers. Моё «нормально» созвучно, но всё-таки отличается.
В реальности большинство людей хотят работать нормально. Только это «нормально» у каждого своё. Это как многие злодеи в фильмах думают, что творят добро, только по-своему.
Мне стало любопытно, и я спросил несколько друзей: что для них значит «работать нормально»? Формат ответа был любой, никаких ограничений.
Получилось любопытно. По ссылке несколько ответов и в конце мой.
https://telegra.ph/CHto-znachit-rabotat-normalno-10-28
Telegraph
Что значит «работать нормально»
Эта фраза в одной из рассылок vas3k'а меня зацепила. Далее по тексту было пояснение в контексте статьи про 10x engineers. Я тут же понял, что моё «нормально» созвучно, но всё-таки отличается.
Конспект PM Starter Pack
https://pmstarterpack.onfielder.com/ — этот небольшой гайд запустился на Product Hunt в мае и ссылку на "Practical guide on how to get started in product management" можно было увидеть во многих околопродуктовых каналах и рассылках.
На прошлой неделе добрался посмотреть, что же там внутри. К сожалению practical этот гайд назвать можно с трудом. Внутри достаточно общие и абстрактные истории. Вместо конкретики в большинстве ситуаций подборки ссылок на статьи. Ryan Hover в комментарии на странице гайда на PH просто написал, что советует начинающим продактам копать свои сайд проекты, и он прав.
Сделал одностраничный конспект. Рекомендую только действительно начинающим ребятам.
https://telegra.ph/Konspekt-PM-Starter-Pack-10-31
https://pmstarterpack.onfielder.com/ — этот небольшой гайд запустился на Product Hunt в мае и ссылку на "Practical guide on how to get started in product management" можно было увидеть во многих околопродуктовых каналах и рассылках.
На прошлой неделе добрался посмотреть, что же там внутри. К сожалению practical этот гайд назвать можно с трудом. Внутри достаточно общие и абстрактные истории. Вместо конкретики в большинстве ситуаций подборки ссылок на статьи. Ryan Hover в комментарии на странице гайда на PH просто написал, что советует начинающим продактам копать свои сайд проекты, и он прав.
Сделал одностраничный конспект. Рекомендую только действительно начинающим ребятам.
https://telegra.ph/Konspekt-PM-Starter-Pack-10-31
Onfielder
VIKINGTOTO > Situs Toto Online Terpercaya Amanah Pasti Bayar
VIKINGTOTO adalah situs toto online yang terkenal dengan kepercayaan dan amanah serta memiliki banyak pilihan game gacor dengan kategori slot, casino hingga togel populer yang memiliki hadiah terbesar di Indonesia hari ini.
«Хьюстон, у нас всё хорошо (на самом деле нет)»
Писать в канал после 5 месяцев тишины — почти восстать из мёртвых.
Нет, работы не стало меньше, скорее наоборот. Нет, это не из-за самоизоляции, хоть она и немного способствует.
Просто изменилась структура времени и следом за ним внимания. Хотя чаще происходит наоборот.
Возвращение в поток началось с ревизии, приведения в порядок и разбора старых записей. Поэтому сегодня делюсь заметками с лекции Людвига Быстроновского, которую посетил ещё в 2015-м.
Её название удивительно созвучно текущему времени. Но мы же тут про менеджмент, поэтому не буду слишком обобщать.
Людвиг очень круто мыслит, выступает и пишет. Вот несколько отличных цитат:
> Я могу пойти в настройки и сказать уведомлению: «а ну-ка иди нахуй»
> Как избавиться от микроменеджмента: надо дать людям обосраться
> Вы не можете контролировать ситуацию. Единственное, что вы можете контролировать — это себя
На днях поделюсь конспектом с ещё одной лекции Людвига.
И да, в дополнение к каналу теперь есть простой сайт. Или в дополнение к сайту теперь остался канал. Как пойдёт.
https://onehandclapping.ru/ldwg-houston-we-are-fine-or-not.html
Писать в канал после 5 месяцев тишины — почти восстать из мёртвых.
Нет, работы не стало меньше, скорее наоборот. Нет, это не из-за самоизоляции, хоть она и немного способствует.
Просто изменилась структура времени и следом за ним внимания. Хотя чаще происходит наоборот.
Возвращение в поток началось с ревизии, приведения в порядок и разбора старых записей. Поэтому сегодня делюсь заметками с лекции Людвига Быстроновского, которую посетил ещё в 2015-м.
Её название удивительно созвучно текущему времени. Но мы же тут про менеджмент, поэтому не буду слишком обобщать.
Людвиг очень круто мыслит, выступает и пишет. Вот несколько отличных цитат:
> Я могу пойти в настройки и сказать уведомлению: «а ну-ка иди нахуй»
> Как избавиться от микроменеджмента: надо дать людям обосраться
> Вы не можете контролировать ситуацию. Единственное, что вы можете контролировать — это себя
На днях поделюсь конспектом с ещё одной лекции Людвига.
И да, в дополнение к каналу теперь есть простой сайт. Или в дополнение к сайту теперь остался канал. Как пойдёт.
https://onehandclapping.ru/ldwg-houston-we-are-fine-or-not.html
Хлопок Одной Ладони
«Хьюстон, у нас все хорошо (на самом деле нет)», лекция Людвига Быстроновского
Ниже мои заметки-конспект с лекции Людвига Быстроновского «Хьюстон, у нас всё хорошо (на самом деле нет)» про наведение порядка в дизайн-проектах (и не только). Я посещал лекцию в Петербурге весной 2015 года.
«Дизайн+1»
Продолжаю разбирать конспекты и записи. Эту лекцию Людвига Быстроновского я лучше всего помню по новому для себя факту: если в меню ресторана есть салат «Цезарь», его берут чаще остальных в 8 раз.
Но лекция, конечно, не про салаты. А про профессионализм. И не только дизайнеров а вообще всех. Вот, например, несколько мыслей:
> Чтобы научиться делать проекты, надо делать проекты.
> Не надо останавливаться на технологии, останавливаться надо на решении задач.
> Если люди делают хорошо, хули лезть.
> Можно за 15 минут сделать много, если ты умный, но если ты 8 часов как чмо, то и письмо напишешь как чмо.
Как и в прошлый раз советую посмотреть видео. И помните: «Просто надо хуячить».
https://onehandclapping.ru/ldwg-design-plus-one.html
Продолжаю разбирать конспекты и записи. Эту лекцию Людвига Быстроновского я лучше всего помню по новому для себя факту: если в меню ресторана есть салат «Цезарь», его берут чаще остальных в 8 раз.
Но лекция, конечно, не про салаты. А про профессионализм. И не только дизайнеров а вообще всех. Вот, например, несколько мыслей:
> Чтобы научиться делать проекты, надо делать проекты.
> Не надо останавливаться на технологии, останавливаться надо на решении задач.
> Если люди делают хорошо, хули лезть.
> Можно за 15 минут сделать много, если ты умный, но если ты 8 часов как чмо, то и письмо напишешь как чмо.
Как и в прошлый раз советую посмотреть видео. И помните: «Просто надо хуячить».
https://onehandclapping.ru/ldwg-design-plus-one.html
Хлопок Одной Ладони
«Дизайн+1», лекция Людвига Быстроновского
Ниже мои заметки-конспект с лекции Людвига Быстроновского «Дизайн+1» про работу суммы навыков и про общие черты хороших дизайнеров (и не только). Я посещал лекцию в Петербурге весной 2015 года.
Rams
Продолжительное время я считал, что не предрасположен к пониманию и тем более созданию дизайна. Постепенно осознал, что это не совсем так, и на самом деле мне очень важен дизайн вещей и инструментов, которые меня окружают. Более того, в некоторых случаях я оказался крайне замороченным.
В этом контексте мне очень понравился фильм Rams независимого режиссёра Gary Hustwit. Личность немецкого дизайнера Дитера Рамса привлекла внимание, а его философия "less, but better" оказалась очень созвучна с моим ощущением дизайна и мира.
Дитер Рамс известен как дизайнер множества продуктов фирмы Braun, мебели от компании Vitsœ, а также автор 10 принципов хорошего дизайна. Его работа стала вдохновением для многих поколений дизайнеров.
> "Less, but better" is not just a design concept, it's also about our behavior. Less would be better everywhere.
Посмотрите обязательно.
https://onehandclapping.ru/rams
Продолжительное время я считал, что не предрасположен к пониманию и тем более созданию дизайна. Постепенно осознал, что это не совсем так, и на самом деле мне очень важен дизайн вещей и инструментов, которые меня окружают. Более того, в некоторых случаях я оказался крайне замороченным.
В этом контексте мне очень понравился фильм Rams независимого режиссёра Gary Hustwit. Личность немецкого дизайнера Дитера Рамса привлекла внимание, а его философия "less, but better" оказалась очень созвучна с моим ощущением дизайна и мира.
Дитер Рамс известен как дизайнер множества продуктов фирмы Braun, мебели от компании Vitsœ, а также автор 10 принципов хорошего дизайна. Его работа стала вдохновением для многих поколений дизайнеров.
> "Less, but better" is not just a design concept, it's also about our behavior. Less would be better everywhere.
Посмотрите обязательно.
https://onehandclapping.ru/rams
Хлопок Одной Ладони
Rams и 10 принципов хорошего дизайна
Про фильм о немецком дизайнере Дитере Рамсе и его философии “Less but better”
Заслать фоллоу-ап
Фоллоу-ап — краткий итог встречи, которым поделились со всеми участниками в удобном всем канале. Например, это может быть письмо, пост в чате, комментарий в задаче.
Этот термин распространён в продажах, но для меня это больше про закрепление любого устного взаимодействия письменным.
Фоллоуапить — очень крутая практика и навык. Сказанное слово ненадёжно, оно забывается, меняет смысл, что приводит к проблемам, неоправданным ожиданиям и спорам в стиле “he said, she said”. Письменное слово в гораздо меньшей степени подвержено девиациям и разным трактовкам.
Фоллоу-ап — это выжимка, а не изложение. Часто готовить фоллоу-ап можно прямо по ходу встречи. Это нормально делать записи по ходу разговора. Навык слепой печати и умение сжато формулировать помогают.
Фоллоу-ап желательно засылать сразу после встречи, либо с минимальной задержкой. Так суть разговора ещё не до конца вымывается из памяти, у читающего будет меньше сомнений, что все действительно было так, как написано.
Идеальный фоллоу-ап содержит следующие детали:
- что обсудили
- о чём договорились и почему
- план ближайших действий
- договоренность о следующей точке синхронизации
- просьба подтвердить правильность написанного
Остальное опционально. Иногда я забываюсь и пишу очень много. Это плохо, так как требует больше времени на прочтение, понимание и выделение сути.
Самая главная проблема с фоллоу-апом — это сомнение, как же правильно писать это слово на русском. С дефисом? Или слитно? Или через пробел? А если в глагольной форме? Но с этим всем можно жить.
Вот пример фоллоу-апа:
- обсудили: что такое фоллоу-апы и как их готовить
- договорились: будем фанатично фоллоуапить после всех встреч на всех участников
- дальнейший план: будем разбираться с чем-нибудь поинтереснее скучных фоллоу-апов
- до встречи в новой заметке
- поделитесь постом с коллегами, если всё верно
Фоллоу-ап — краткий итог встречи, которым поделились со всеми участниками в удобном всем канале. Например, это может быть письмо, пост в чате, комментарий в задаче.
Этот термин распространён в продажах, но для меня это больше про закрепление любого устного взаимодействия письменным.
Фоллоуапить — очень крутая практика и навык. Сказанное слово ненадёжно, оно забывается, меняет смысл, что приводит к проблемам, неоправданным ожиданиям и спорам в стиле “he said, she said”. Письменное слово в гораздо меньшей степени подвержено девиациям и разным трактовкам.
Фоллоу-ап — это выжимка, а не изложение. Часто готовить фоллоу-ап можно прямо по ходу встречи. Это нормально делать записи по ходу разговора. Навык слепой печати и умение сжато формулировать помогают.
Фоллоу-ап желательно засылать сразу после встречи, либо с минимальной задержкой. Так суть разговора ещё не до конца вымывается из памяти, у читающего будет меньше сомнений, что все действительно было так, как написано.
Идеальный фоллоу-ап содержит следующие детали:
- что обсудили
- о чём договорились и почему
- план ближайших действий
- договоренность о следующей точке синхронизации
- просьба подтвердить правильность написанного
Остальное опционально. Иногда я забываюсь и пишу очень много. Это плохо, так как требует больше времени на прочтение, понимание и выделение сути.
Самая главная проблема с фоллоу-апом — это сомнение, как же правильно писать это слово на русском. С дефисом? Или слитно? Или через пробел? А если в глагольной форме? Но с этим всем можно жить.
Вот пример фоллоу-апа:
- обсудили: что такое фоллоу-апы и как их готовить
- договорились: будем фанатично фоллоуапить после всех встреч на всех участников
- дальнейший план: будем разбираться с чем-нибудь поинтереснее скучных фоллоу-апов
- до встречи в новой заметке
- поделитесь постом с коллегами, если всё верно
Лекция Виктора Козлова в ИТМО
За последние два месяца интернет-магазин Ozon стал для меня регулярным местом для посещения и перераспределения бюджета от несостоявшихся поездок и других невозможных сейчас активностей. При том, что до этого я пользовался им много лет назад. Самоизоляция действительно перестраивает жизнь.
На этом фоне вспомнил про конспект выступления Виктора Козлова, одного из основателей Ozon,Рексофт, Assist и Clever Pumpkin. В лекции не было неожиданных откровений, но были довольно простые и понятные мысли и идеи без претензии на что-то глобальное:
- ставьте меньше условий для своего счастья
- создавайте удачу упорным трудом
- расценивайте неудачу как полезный опыт
- учитесь всю жизнь
Думаю, поэтому и человек, и лекция произвели приятное впечатление.
https://onehandclapping.ru/victor-kozlov-v-itmo
За последние два месяца интернет-магазин Ozon стал для меня регулярным местом для посещения и перераспределения бюджета от несостоявшихся поездок и других невозможных сейчас активностей. При том, что до этого я пользовался им много лет назад. Самоизоляция действительно перестраивает жизнь.
На этом фоне вспомнил про конспект выступления Виктора Козлова, одного из основателей Ozon,Рексофт, Assist и Clever Pumpkin. В лекции не было неожиданных откровений, но были довольно простые и понятные мысли и идеи без претензии на что-то глобальное:
- ставьте меньше условий для своего счастья
- создавайте удачу упорным трудом
- расценивайте неудачу как полезный опыт
- учитесь всю жизнь
Думаю, поэтому и человек, и лекция произвели приятное впечатление.
https://onehandclapping.ru/victor-kozlov-v-itmo
Хлопок Одной Ладони
Лекция Виктора Козлова в ИТМО
Весной 2016 года я почти случайно попал на выступление Виктора Козлова в университете ИТМО. Лекция была нацелена на студентов и по характеристике самого выступающего была скорее для вдохновения и как резюме и рефлексия собственного опыта.
Вера и идеи
В фильме замечательного режиссёра Кевина Смита «Догма» на тему веры и идей мне запомнилось два диалога.
Bethany: You’re saying having beliefs is a bad thing?
Rufus: I just think it’s better to have ideas. I mean, you can change an idea, changing a belief is trickier. People die for it, people kill for it.
Rufus: Why, Bethany Sloane, are you saying you believe?
Bethany: No. But I have a good idea.
В русской озвучке последний диалог звучал так:
— Кризис веры миновал?
— Я получила больше, чем заказывала.
— Не засуха, так ливень. Укрепилась верой?
— Нет. Но обогатилась идеями.
— Браво.
Если представить, что Вифания и Руфус два менеджера, и одна из них сначала перегорела на работе, но потом пришла в себя через почти божественное касание, то мы получаем нужный контекст. И цитирование фильма «Догма» выглядит уже не так странно.
Вера — отличный инструмент создания интерсубъективной реальности для любой группы людей. В том числе компании или, более локально, команды. Но он обладает существенным недостатком — мы воспринимаем веру догматично. Поэтому всё, что переходит в разряд веры, а точнее то, что мы переводим в разряд веры, нам самим же становится сложно менять, оно реже подвергается сомнениям. Вера становится «слепой», команда негибкой, инерция неизбежной, а люди постепенно начинают сгорать. Это в том числе случай, когда в ответ на «почему?» получаем ответ «мы всегда так делали». Да, я специально обобщаю и утрирую, чтобы сделать акцент.
Идеи как противопоставление веры очень крутой концепт. Идеи свежи. Идеи могут быть неверны, но это нормально, потому что идеи ничего не стоят сами по себе. Без реализации, без валидации, без проверки гипотез идея очень хрупка. Идея стимулирует к действию, открыта к неудобным вопросам. Она лучше поддаётся трансформации и адаптации. И поэтому идеи более удачный инструмент создания коллективного знания.
В вере нет ничего плохого, если она не доведена до фанатизма или автоматизма. Но лучше всё-таки обогащайтесь идеями.
В фильме замечательного режиссёра Кевина Смита «Догма» на тему веры и идей мне запомнилось два диалога.
Bethany: You’re saying having beliefs is a bad thing?
Rufus: I just think it’s better to have ideas. I mean, you can change an idea, changing a belief is trickier. People die for it, people kill for it.
Rufus: Why, Bethany Sloane, are you saying you believe?
Bethany: No. But I have a good idea.
В русской озвучке последний диалог звучал так:
— Кризис веры миновал?
— Я получила больше, чем заказывала.
— Не засуха, так ливень. Укрепилась верой?
— Нет. Но обогатилась идеями.
— Браво.
Если представить, что Вифания и Руфус два менеджера, и одна из них сначала перегорела на работе, но потом пришла в себя через почти божественное касание, то мы получаем нужный контекст. И цитирование фильма «Догма» выглядит уже не так странно.
Вера — отличный инструмент создания интерсубъективной реальности для любой группы людей. В том числе компании или, более локально, команды. Но он обладает существенным недостатком — мы воспринимаем веру догматично. Поэтому всё, что переходит в разряд веры, а точнее то, что мы переводим в разряд веры, нам самим же становится сложно менять, оно реже подвергается сомнениям. Вера становится «слепой», команда негибкой, инерция неизбежной, а люди постепенно начинают сгорать. Это в том числе случай, когда в ответ на «почему?» получаем ответ «мы всегда так делали». Да, я специально обобщаю и утрирую, чтобы сделать акцент.
Идеи как противопоставление веры очень крутой концепт. Идеи свежи. Идеи могут быть неверны, но это нормально, потому что идеи ничего не стоят сами по себе. Без реализации, без валидации, без проверки гипотез идея очень хрупка. Идея стимулирует к действию, открыта к неудобным вопросам. Она лучше поддаётся трансформации и адаптации. И поэтому идеи более удачный инструмент создания коллективного знания.
В вере нет ничего плохого, если она не доведена до фанатизма или автоматизма. Но лучше всё-таки обогащайтесь идеями.
How to Manage a Remote Team Well
Посмотрел, законспектировал и выделил основное из воркшопа Clair Lew, CEO сервиса Know Your Team, про то как грамотно управлять удалённой командой. В идеях видно наследие идеалогии Basecamp. Но мне оказалось не лишним себе ещё раз напомнить. Вот самое главное:
1. Асинхронность — самый важный и при этом недооценённый бонус удалённой работы. При этом самый нетривиальный в настройке. Менее реактивная коммуникация даёт возможность фокусироваться на задачах и думать.
2. Удалённо работать можно только на доверии. Трекинг и микроменеджмент это убивают. Тащат понятная трансляция ожиданий в одну сторону и прозрачный прогресс (в идеале автоматический) в другую сторону.
3. Настроенные процессы очень важны. Начать с базы: док-методичка «как мы работаем», правила коммуникации, вопросы по таймзонам и ожиданиям по времени вообще. Дальше подкручивать.
4. Уделить внимание социальным связям. По сути офисные неформальные коммуникации надо адаптировать для удалённой работы. Потому что работа это огромная часть жизни людей, и это не только про «фигачить», но и про коммуникацию.
5. Встречи один-на-один: не превращать в сверку по текущему статусу, а стараться раскрыть потенциал или потенциальные проблемы. Регулярность встреч решает.
Более подробный конспект на английском: https://onehandclapping.ru/claire-lew-how-to-manage-a-remote-team-well
Посмотрел, законспектировал и выделил основное из воркшопа Clair Lew, CEO сервиса Know Your Team, про то как грамотно управлять удалённой командой. В идеях видно наследие идеалогии Basecamp. Но мне оказалось не лишним себе ещё раз напомнить. Вот самое главное:
1. Асинхронность — самый важный и при этом недооценённый бонус удалённой работы. При этом самый нетривиальный в настройке. Менее реактивная коммуникация даёт возможность фокусироваться на задачах и думать.
2. Удалённо работать можно только на доверии. Трекинг и микроменеджмент это убивают. Тащат понятная трансляция ожиданий в одну сторону и прозрачный прогресс (в идеале автоматический) в другую сторону.
3. Настроенные процессы очень важны. Начать с базы: док-методичка «как мы работаем», правила коммуникации, вопросы по таймзонам и ожиданиям по времени вообще. Дальше подкручивать.
4. Уделить внимание социальным связям. По сути офисные неформальные коммуникации надо адаптировать для удалённой работы. Потому что работа это огромная часть жизни людей, и это не только про «фигачить», но и про коммуникацию.
5. Встречи один-на-один: не превращать в сверку по текущему статусу, а стараться раскрыть потенциал или потенциальные проблемы. Регулярность встреч решает.
Более подробный конспект на английском: https://onehandclapping.ru/claire-lew-how-to-manage-a-remote-team-well
Хлопок Одной Ладони
How to Manage a Remote Team Well, воркшоп Clair Lew
Клэр Лью (Clair Lew) — CEO сервиса Know Your Team, который в своё время отпочковался от команды Basecamp.
Рекомендую
В последнее время всё чаще делюсь с коллегами и друзьями рекомендациями курсов, книг и прочего по менеджменту и вокруг него. Решил сделать подборку и собрал всё на одной странице, буду постепенно дополнять и обновлять. Пока есть курсы и книги. Очередность ничего не значит, порядок случайный.
Только опробованное лично и то, что считаю полезным.
https://onehandclapping.ru/recommendations
В последнее время всё чаще делюсь с коллегами и друзьями рекомендациями курсов, книг и прочего по менеджменту и вокруг него. Решил сделать подборку и собрал всё на одной странице, буду постепенно дополнять и обновлять. Пока есть курсы и книги. Очередность ничего не значит, порядок случайный.
Только опробованное лично и то, что считаю полезным.
https://onehandclapping.ru/recommendations
Хлопок Одной Ладони
Рекомендации
Рекомендую курсы, книги и прочее по менеджменту и вокруг. Только то, что сам проходил и прочитал, на что подписался, за кем поглядываю, куда захожу.
Learning How to Learn
Чтобы понять, что такое рекурсия, надо понять, что такое рекурсия. А чтобы научиться учиться, надо пройти курс Learning How to Learn на курсере.
Заканчиваю читать книгу Mindshift, которую написала Барбара Оакли (Barbara Oakley), поэтому решил освежить в памяти материалы её курсов (есть ещё курс, который называется Mindshift).
В Learning How to Learn Барбара рассказывает, что лучшему запоминанию способствуют, например:
- здоровый сон + повторение материала перед сном
- работа с материалом: подчеркивать, выделять, проговаривать
- распределение обучение во времени (spaced repetition)
- разбиение материала на кусочки (chunking)
- занятия спортом
- ещё куча вещей
Там же будет про то, как творчески подойти к прокрастинации и работе с памятью, про то как дофамин не всегда одинаково полезен, а ацетилхолин и серотонин в этом плане кажутся получше.
По ссылке ключевые идеи + более подробный конспект. Советую пройти курс самостоятельно, он совсем ненапряженый, но важный для осознания базовых вещей по работе с любым обучением.
https://onehandclapping.ru/learning-how-to-learn
Чтобы понять, что такое рекурсия, надо понять, что такое рекурсия. А чтобы научиться учиться, надо пройти курс Learning How to Learn на курсере.
Заканчиваю читать книгу Mindshift, которую написала Барбара Оакли (Barbara Oakley), поэтому решил освежить в памяти материалы её курсов (есть ещё курс, который называется Mindshift).
В Learning How to Learn Барбара рассказывает, что лучшему запоминанию способствуют, например:
- здоровый сон + повторение материала перед сном
- работа с материалом: подчеркивать, выделять, проговаривать
- распределение обучение во времени (spaced repetition)
- разбиение материала на кусочки (chunking)
- занятия спортом
- ещё куча вещей
Там же будет про то, как творчески подойти к прокрастинации и работе с памятью, про то как дофамин не всегда одинаково полезен, а ацетилхолин и серотонин в этом плане кажутся получше.
По ссылке ключевые идеи + более подробный конспект. Советую пройти курс самостоятельно, он совсем ненапряженый, но важный для осознания базовых вещей по работе с любым обучением.
https://onehandclapping.ru/learning-how-to-learn
Хлопок Одной Ладони
Learning How to Learn
Ключевые идеи и конспект самого известного курса про то, как учиться.
Обмазаться
Чтобы эффективно и быстро погрузиться в новый проект, надо создать условия, при которых новый контекст обволакивает тебя со всех сторон, лезет из всех внешних щелей во все предназначенные для этого внутренние, буквально погружает тебя с головой.
За последние полтора года я несколько раз сталкивался с проектами в сферах, где у меня было мало опыта. На каждом новом включении я применял примерно одинаковый подход, который для себя называю «обмазаться». Термин бережно заимствован у бывших коллег, но автора не помню.
На практике это означает воткнуться во все информационные потоки:
- подписаться на апдейты проектов в системе ведения задач и на апдейты ключевых задач
- сходить на все командые встречи и обсуждения
- попасть во все возможные каналы общения (slack и подобное)
- прочитать все имеющиеся материалы из документов, документаций и баз знаний
- пообщаться со всеми ключевыми ребятами и выборочно с линейными специалистами
Обмазаться — это аналог первой фазы любого research, когда идёт активный, немного хаотичный сбор материалов. На этом этапе надо впитывать и перемалывать контекст, привыкать, вычленять терминологию, задавать вопросы, вмешательство в ход событий должно быть минимально.
Ещё один аналог — это O из OPDCA. Observe, наблюдай.
Главный трюк обмазывания — вовремя остановиться. Иначе станет сложно отмываться. Поэтому на старте надо обмазаться по полной, а затем методично сокращать включения до нужного уровня погружения и детализации, сохраняя знание, куда можно копнуть в случае конкретного вопроса.
Чтобы эффективно и быстро погрузиться в новый проект, надо создать условия, при которых новый контекст обволакивает тебя со всех сторон, лезет из всех внешних щелей во все предназначенные для этого внутренние, буквально погружает тебя с головой.
За последние полтора года я несколько раз сталкивался с проектами в сферах, где у меня было мало опыта. На каждом новом включении я применял примерно одинаковый подход, который для себя называю «обмазаться». Термин бережно заимствован у бывших коллег, но автора не помню.
На практике это означает воткнуться во все информационные потоки:
- подписаться на апдейты проектов в системе ведения задач и на апдейты ключевых задач
- сходить на все командые встречи и обсуждения
- попасть во все возможные каналы общения (slack и подобное)
- прочитать все имеющиеся материалы из документов, документаций и баз знаний
- пообщаться со всеми ключевыми ребятами и выборочно с линейными специалистами
Обмазаться — это аналог первой фазы любого research, когда идёт активный, немного хаотичный сбор материалов. На этом этапе надо впитывать и перемалывать контекст, привыкать, вычленять терминологию, задавать вопросы, вмешательство в ход событий должно быть минимально.
Ещё один аналог — это O из OPDCA. Observe, наблюдай.
Главный трюк обмазывания — вовремя остановиться. Иначе станет сложно отмываться. Поэтому на старте надо обмазаться по полной, а затем методично сокращать включения до нужного уровня погружения и детализации, сохраняя знание, куда можно копнуть в случае конкретного вопроса.
"The Power of Habit" by Charles Duhigg
Откопал и обработал заметки и сохранённые цитаты из книги Чарльза Дахигга «Сила Привычки».
Сейчас, в эпоху осознанности, медитаций и домашнего просветления, эти идеи растиражированы довольно сильно. Но в своё время, в 2014 году, книга стала для меня небольшим откровением.
Ключевая мысль: мозг ленивый, люди — влажные роботы, много стандартных программ которых работает по фреймворку cue -> routine -> reward (триггер -> действие -> награда). Награда даёт положительное подкрепление, и с каждым следующим триггером привычка становится всё сильнее.
Книга не перегружена наукой, построена на историях и примерах, читать интересно.
https://onehandclapping.ru/the-power-of-habit-by-charles-duhigg
Откопал и обработал заметки и сохранённые цитаты из книги Чарльза Дахигга «Сила Привычки».
Сейчас, в эпоху осознанности, медитаций и домашнего просветления, эти идеи растиражированы довольно сильно. Но в своё время, в 2014 году, книга стала для меня небольшим откровением.
Ключевая мысль: мозг ленивый, люди — влажные роботы, много стандартных программ которых работает по фреймворку cue -> routine -> reward (триггер -> действие -> награда). Награда даёт положительное подкрепление, и с каждым следующим триггером привычка становится всё сильнее.
Книга не перегружена наукой, построена на историях и примерах, читать интересно.
https://onehandclapping.ru/the-power-of-habit-by-charles-duhigg
Хлопок Одной Ладони
“The Power of Habit”, Charles Duhigg
Люди — влажные роботы. Привычки — их программы.
Настройка MacBook для замороченного менеджера
Собрал в один пост всё, что настраиваю и устанавливаю на своём макбуке для комфортной ежедневной работы.
Может показаться, что заморочек по настройкам слишком много, но по сути они все направлены на то, чтобы:
- минимизировать отвлечения и шум
- убедиться в базовых мерах безопасности
- настроить всё так, чтобы потом не замечать и не вспоминать про ось, фокусируясь только на текущем деле
В канале теперь включены комментарии. Делитесь своими фишками, рекомендуйте софт, расскажите, что оказалось полезным.
https://onehandclapping.ru/macbook-setup-for-managers
Собрал в один пост всё, что настраиваю и устанавливаю на своём макбуке для комфортной ежедневной работы.
Может показаться, что заморочек по настройкам слишком много, но по сути они все направлены на то, чтобы:
- минимизировать отвлечения и шум
- убедиться в базовых мерах безопасности
- настроить всё так, чтобы потом не замечать и не вспоминать про ось, фокусируясь только на текущем деле
В канале теперь включены комментарии. Делитесь своими фишками, рекомендуйте софт, расскажите, что оказалось полезным.
https://onehandclapping.ru/macbook-setup-for-managers
Хлопок Одной Ладони
Настройка MacBook для замороченного менеджера
Настройки, Finder, программы и другие признаки обсессивно-компульсивного расстройства.
Десять ключевых мыслей c курса Change Basics
В декабре прошёл курс-сериал Change Basics от Наташи Бабаевой и Школы ченджеров.
Change Basics выстроен в виде истории, в каждой из 10 серий героиня падает всё глубже в кроличью нору, а мы смотрим, как ей удаётся это осознать и найти равновесие. Ключевые идеи подаются через призму разделения активностей на «чендж и ран» по модели компании Gartner, её также называют бимодальной (Bimodal).
Курс классный. Уже купил его в подарок другу на Новый год. По-моему, это главный показатель крутости продукта — желание подсадить на него всех вокруг.
Для начинающих специалистов — это просто находка, для уже более спелых и зрелых — отличный способ ещё раз вспомнить основы, пересистематизировать знания на базе новой подачи и ситуаций и, конечно, пожалеть, что такого курса не выдавали на старте карьеры.
При прохождении составил себе подробный коспект, но поделюсь десятью мыслями из курса, которые для меня показались самыми важными и актуальными.
1. Не смешивать ран и чендж. Это касается и правил игры, условий работы, и оценки ошибок, и измерения прогресса, и подходов, и оценки качества, и отношения к процессу и результатам. Разделение помогает избавиться от вредных искажений восприятия.
2. Чтобы быть хорошим ченджером, надо понимать ран. Чтобы быть хорошим раннером, надо понимать чендж. Этапы ченджа и рана переплетены, понимание улучшает взаимные и общие результаты.
3. Ран можно и нужно уплотнять. Для этого есть понятный арсенал: визуализации, шаблоны, чек-листы, «полуфабрикаты», анализ, оптимизация.
4. Не забывать мечтать. Dreamability — дополнение привычных компонентов дизайн-мышления (desirability, viability, feasibility). Вопрос: от чего прёт?
5. Планировать назад. От дедлайна, от желаемого результата, от ограничений.
6. Праздновать эмоциями, как дети. И хорошее, и плохое. Часто. Не вечеринками, не алкоголем.
7. Докручивать цикл. Качественный анализ итогов проекта или итерации — основа дальнейшего роста.
8. Ограничивать Work in Progress. От уровня проектов, до уровня отдельных задач.
9. Нанимать людей круче себя.
10. Не срезать коммуникацию. Через неё решаются многие проблемы команды.
Это всё только верхушка айсберга, под водой гораздо больше идей, нюансов и деталей.
Я был участником первого потока, брал тариф с домашкой, но постепенно на неё забил (зря). У курса офигительный лендинг https://basics.changerschool.ru/: понятно, подробно, полно и с картинкам. Советую.
В декабре прошёл курс-сериал Change Basics от Наташи Бабаевой и Школы ченджеров.
Change Basics выстроен в виде истории, в каждой из 10 серий героиня падает всё глубже в кроличью нору, а мы смотрим, как ей удаётся это осознать и найти равновесие. Ключевые идеи подаются через призму разделения активностей на «чендж и ран» по модели компании Gartner, её также называют бимодальной (Bimodal).
Курс классный. Уже купил его в подарок другу на Новый год. По-моему, это главный показатель крутости продукта — желание подсадить на него всех вокруг.
Для начинающих специалистов — это просто находка, для уже более спелых и зрелых — отличный способ ещё раз вспомнить основы, пересистематизировать знания на базе новой подачи и ситуаций и, конечно, пожалеть, что такого курса не выдавали на старте карьеры.
При прохождении составил себе подробный коспект, но поделюсь десятью мыслями из курса, которые для меня показались самыми важными и актуальными.
1. Не смешивать ран и чендж. Это касается и правил игры, условий работы, и оценки ошибок, и измерения прогресса, и подходов, и оценки качества, и отношения к процессу и результатам. Разделение помогает избавиться от вредных искажений восприятия.
2. Чтобы быть хорошим ченджером, надо понимать ран. Чтобы быть хорошим раннером, надо понимать чендж. Этапы ченджа и рана переплетены, понимание улучшает взаимные и общие результаты.
3. Ран можно и нужно уплотнять. Для этого есть понятный арсенал: визуализации, шаблоны, чек-листы, «полуфабрикаты», анализ, оптимизация.
4. Не забывать мечтать. Dreamability — дополнение привычных компонентов дизайн-мышления (desirability, viability, feasibility). Вопрос: от чего прёт?
5. Планировать назад. От дедлайна, от желаемого результата, от ограничений.
6. Праздновать эмоциями, как дети. И хорошее, и плохое. Часто. Не вечеринками, не алкоголем.
7. Докручивать цикл. Качественный анализ итогов проекта или итерации — основа дальнейшего роста.
8. Ограничивать Work in Progress. От уровня проектов, до уровня отдельных задач.
9. Нанимать людей круче себя.
10. Не срезать коммуникацию. Через неё решаются многие проблемы команды.
Это всё только верхушка айсберга, под водой гораздо больше идей, нюансов и деталей.
Я был участником первого потока, брал тариф с домашкой, но постепенно на неё забил (зря). У курса офигительный лендинг https://basics.changerschool.ru/: понятно, подробно, полно и с картинкам. Советую.
Change Basics
10 мини уроков о пути неинноватора в инновациях. В каждом уроке одни «грабли» и один вывод. Все уроки строятся вокруг истории начинающего ченджера Зои. Каждый раз она сталкивается с «неразрешимой» проблемой ченджера и очень стрессует. А мы кидаем ей спасательный…
Ryan’s Newsletter
Райан Сингер (Ryan Singer) — глава продуктовой стратегии в Basecamp и автор книги ShapeUp.
В ноябре 2020 он запустил свою рассылку, Ryan’s Newsletter, где делится своими наблюдениями, мыслями и идеями на основе того, над чем сейчас работает. Формат очень лёгкий и приятный. Как он сам описывает, это почти как Твиттер, но с добавлением контекста.
Мне очень интересна работа Райана, она на стыке управления продуктом и процессами. И он показывает реальный внутряк: свой процесс на реальных фичах, со скриншотами скетчей, схем, диаграмм и документов, описывает ход мышления, недавно записал видео о том, как сейчас пробует коммуницировать концепты новых фич команде, используя идею языка паттернов (pattern language).
На текущий момент вышло пять выпусков, в каждом 2-3 идеи. Вот несколько, которые меня зацепили.
1. Demand-side differentiation (дифференциация по спросу)
Разные подходы часто ведут к соревнованию, какой из них единственно верный. Но в этом соревновании нельзя победить, т.к. подходы контекстны ситуации, компании, людям. Выход — дифференциироваться по спросу.
Например, есть стопицот таскменеджеров, которые продвигаются, подчёркивая разницу в интерфейсе и фичи — это дифференциация по предложению. Но если сфокусироваться на том, какой аудитории идеально подходит конкретный таскменеджер и для каких задач, то это уже поиск отличий по спросу.
2. Sequence != priority (последовательность — это не приоритет)
Это очень красивая и новая для меня мысль. Я привык думать о приоритете в контексте последовательности действий. Но, оказывается, их можно разделить.
Приоритет по сути бинарное состояние: must-have или nice-to-have в рамках ограничения времени. Когда установлен этот приоритет, уже можно говорить о последовательности в рамках must-have элементов.
> Sequence and priority sound similar. It can be natural to say "I'll use the diagram to figure out what to prioritize first." But actually, given a fixed time box, sequence and priority are orthogonal. Sequence is about order: first, second, ... last. Priority is about what's in and what's out: what is a "must" within the given time constraint and what is "nice to have." When every element in a system is a "must," you have a sequencing problem
3. Измерение использования фичи через отношение сигнала к шуму
Здесь Райан рассуждает о том, как можно измерить, что продукт работает для его пользователей так, как должен, через определение «намерения». И примеряет один из подходов статистических методов Тагучи, чтобы определить метрику правильности использования фичи.
Отношение сигнала к шуму для функции системы должно показывать, насколько часто функция используется так, как задумано, по отношению к общему числу использований. Детали лучше прочитать в рассылке, т.к. пересказ потянет на отдельный пост.
Подписаться на рассылку можно по ссылке: https://mailchi.mp/hey/ryans-newsletter
Сайт Райана: https://feltpresence.com/
Ключевые мысли из книги ShapeUp: https://onehandclapping.ru/shapup-by-ryan-singer-from-basecamp
Райан Сингер (Ryan Singer) — глава продуктовой стратегии в Basecamp и автор книги ShapeUp.
В ноябре 2020 он запустил свою рассылку, Ryan’s Newsletter, где делится своими наблюдениями, мыслями и идеями на основе того, над чем сейчас работает. Формат очень лёгкий и приятный. Как он сам описывает, это почти как Твиттер, но с добавлением контекста.
Мне очень интересна работа Райана, она на стыке управления продуктом и процессами. И он показывает реальный внутряк: свой процесс на реальных фичах, со скриншотами скетчей, схем, диаграмм и документов, описывает ход мышления, недавно записал видео о том, как сейчас пробует коммуницировать концепты новых фич команде, используя идею языка паттернов (pattern language).
На текущий момент вышло пять выпусков, в каждом 2-3 идеи. Вот несколько, которые меня зацепили.
1. Demand-side differentiation (дифференциация по спросу)
Разные подходы часто ведут к соревнованию, какой из них единственно верный. Но в этом соревновании нельзя победить, т.к. подходы контекстны ситуации, компании, людям. Выход — дифференциироваться по спросу.
Например, есть стопицот таскменеджеров, которые продвигаются, подчёркивая разницу в интерфейсе и фичи — это дифференциация по предложению. Но если сфокусироваться на том, какой аудитории идеально подходит конкретный таскменеджер и для каких задач, то это уже поиск отличий по спросу.
2. Sequence != priority (последовательность — это не приоритет)
Это очень красивая и новая для меня мысль. Я привык думать о приоритете в контексте последовательности действий. Но, оказывается, их можно разделить.
Приоритет по сути бинарное состояние: must-have или nice-to-have в рамках ограничения времени. Когда установлен этот приоритет, уже можно говорить о последовательности в рамках must-have элементов.
> Sequence and priority sound similar. It can be natural to say "I'll use the diagram to figure out what to prioritize first." But actually, given a fixed time box, sequence and priority are orthogonal. Sequence is about order: first, second, ... last. Priority is about what's in and what's out: what is a "must" within the given time constraint and what is "nice to have." When every element in a system is a "must," you have a sequencing problem
3. Измерение использования фичи через отношение сигнала к шуму
Здесь Райан рассуждает о том, как можно измерить, что продукт работает для его пользователей так, как должен, через определение «намерения». И примеряет один из подходов статистических методов Тагучи, чтобы определить метрику правильности использования фичи.
Отношение сигнала к шуму для функции системы должно показывать, насколько часто функция используется так, как задумано, по отношению к общему числу использований. Детали лучше прочитать в рассылке, т.к. пересказ потянет на отдельный пост.
Подписаться на рассылку можно по ссылке: https://mailchi.mp/hey/ryans-newsletter
Сайт Райана: https://feltpresence.com/
Ключевые мысли из книги ShapeUp: https://onehandclapping.ru/shapup-by-ryan-singer-from-basecamp