Крутейшая заметка Всеволода Устинова о том, что значить отвечать за себя — http://vsevolodustinov.ru/blog/all/chto-znachit-otvechat-za-sebya/
vsevolodustinov.ru
Что значит отвечать за себя
Примеры вымышленные. Всё в процессе осмысления. Понимание ещё изменится
Банальная, плохо доказанная, но мега-полезная лично для меня мысль: если хочешь хорошо подумать — прогуляйся по улице.
https://www.ted.com/talks/marily_oppezzo_want_to_be_more_creative_go_for_a_walk/
В эксперименте людей разделили на группы: одни решали творческие задачи сидя на стуле, другие — шли по беговой дорожке. Те, кто шли — решали задачи лучше, даже после того, как прекращали упражнение.
Если рядом с вами работают люди, которые еще не научились управлять своей творческой энергией — покажите им это пятиминутное видео.
https://www.ted.com/talks/marily_oppezzo_want_to_be_more_creative_go_for_a_walk/
В эксперименте людей разделили на группы: одни решали творческие задачи сидя на стуле, другие — шли по беговой дорожке. Те, кто шли — решали задачи лучше, даже после того, как прекращали упражнение.
Если рядом с вами работают люди, которые еще не научились управлять своей творческой энергией — покажите им это пятиминутное видео.
Ted
Want to be more creative? Go for a walk
When trying to come up with a new idea, we all have times when we get stuck. But according to research by behavioral and learning scientist Marily Oppezzo, getting up and going for a walk might be all it takes to get your creative juices flowing. In this…
Короткая и внятная статья Натальи Бабаевой о том, как выбирать из беклога только самое важное. И как НЕ раздуывать его до километровой длины при помощи идей от сотрудников.
https://medium.com/@nbabaeva/%D0%BF%D1%80%D0%B8%D0%B5%D0%BC-%D0%B8%D0%B4%D0%B5%D0%B9-%D0%B7%D0%B0%D0%BA%D1%80%D1%8B%D1%82-293047188dec
https://medium.com/@nbabaeva/%D0%BF%D1%80%D0%B8%D0%B5%D0%BC-%D0%B8%D0%B4%D0%B5%D0%B9-%D0%B7%D0%B0%D0%BA%D1%80%D1%8B%D1%82-293047188dec
Medium
— Прием идей закрыт!
Диалог двух продактов о нужных и ненужных продуктовых идеях, цене ведения беклога и как хакнуть оценку проектов.
Длинные ТЗ не работают
Наши родители верили, что планы сбываются — в их стране было принято строить пяти- и десятилетние планы. Чтобы планы работали на производстве, возводили целые проектировочные НИИ с множеством этажей. В НИИ сочиняли документы, описывающие процесс, а не результат: сколько нанимать рабочих, где брать сырье, как контролировать качество.
От этих монументальных документов никто потом не отклонялся — в плановой экономике нет конкуренции, можно выпускать одни и те же жигули хоть 30 лет подряд.
В айтишных проектах, в отличие от жигулей и самолётов, нельзя отделять производство от проектирования. От ТЗ до запуска меняется мир: приходит новый архитектор, арт-директор меняет концепцию, конкуренты запускают новый продукт. Я не знаю ни одного сложного проекта, который на финише соответствовал бы первоначальному заданию.
Не заморачивайтесь на этапе проектирования — все равно в реальной жизни все пойдёт не так, и ваше ТЗ станет никому не нужным.
Чтобы запустить интернет-магазин, не обязательно продумывать 20 состояний корзины. Разбейте проект на короткие итерации и концентрируйте усилия только на текущей:
— Концептуальная страница-заглушка с телефоном
— Страница с контактами и десятком самых продаваемых товаров
— Каталог товаров, «купить в один клик»
— Корзина
— Синхронизация с црм, 1с
С каждой новой итерацией вы сверяете часы с бизнесом — выясняете невысказанные требования, анализируете поведение пользователей и корректируете планы. Кажется такой подход ещё называют «аджайл».
Наши родители верили, что планы сбываются — в их стране было принято строить пяти- и десятилетние планы. Чтобы планы работали на производстве, возводили целые проектировочные НИИ с множеством этажей. В НИИ сочиняли документы, описывающие процесс, а не результат: сколько нанимать рабочих, где брать сырье, как контролировать качество.
От этих монументальных документов никто потом не отклонялся — в плановой экономике нет конкуренции, можно выпускать одни и те же жигули хоть 30 лет подряд.
В айтишных проектах, в отличие от жигулей и самолётов, нельзя отделять производство от проектирования. От ТЗ до запуска меняется мир: приходит новый архитектор, арт-директор меняет концепцию, конкуренты запускают новый продукт. Я не знаю ни одного сложного проекта, который на финише соответствовал бы первоначальному заданию.
Не заморачивайтесь на этапе проектирования — все равно в реальной жизни все пойдёт не так, и ваше ТЗ станет никому не нужным.
Чтобы запустить интернет-магазин, не обязательно продумывать 20 состояний корзины. Разбейте проект на короткие итерации и концентрируйте усилия только на текущей:
— Концептуальная страница-заглушка с телефоном
— Страница с контактами и десятком самых продаваемых товаров
— Каталог товаров, «купить в один клик»
— Корзина
— Синхронизация с црм, 1с
С каждой новой итерацией вы сверяете часы с бизнесом — выясняете невысказанные требования, анализируете поведение пользователей и корректируете планы. Кажется такой подход ещё называют «аджайл».
Критика
Когда я только попал в Студию Лебедева, меня больше всего удивил не музей старья, и даже не кот Филя.
Меня шокировал объем критики. В студии принято поправлять новичков во всем — в письмах, документах, в общении с командой, в разговоре с клиентом. Чтобы понять количество критики, загляните в любой «процесс» — и это только видимая часть замечаний, которые получает дизайнер от арт-директора.
Многие не выдерживают, начинают чувствовать себя говном и сбегают. Зря. Персональная критика от строгого наставника прокачивает лучше любой книги. Можно два года учиться на собственных ошибках, а можно узнать все то же самое от старших товарищей за месяц.
Гораздо хуже для бизнеса, когда новичков не критикуют, а отпускают в свободное плавание. Если так делать, то компания превращается из того, что задумал основатель, в то, что находится в голове у случайных, в общем-то людей.
Критикуйте. Настраивайте жёсткий код-ревью. Делайте системы согласований. Собирайте обратную связь и ещё раз критикуйте.
Когда я только попал в Студию Лебедева, меня больше всего удивил не музей старья, и даже не кот Филя.
Меня шокировал объем критики. В студии принято поправлять новичков во всем — в письмах, документах, в общении с командой, в разговоре с клиентом. Чтобы понять количество критики, загляните в любой «процесс» — и это только видимая часть замечаний, которые получает дизайнер от арт-директора.
Многие не выдерживают, начинают чувствовать себя говном и сбегают. Зря. Персональная критика от строгого наставника прокачивает лучше любой книги. Можно два года учиться на собственных ошибках, а можно узнать все то же самое от старших товарищей за месяц.
Гораздо хуже для бизнеса, когда новичков не критикуют, а отпускают в свободное плавание. Если так делать, то компания превращается из того, что задумал основатель, в то, что находится в голове у случайных, в общем-то людей.
Критикуйте. Настраивайте жёсткий код-ревью. Делайте системы согласований. Собирайте обратную связь и ещё раз критикуйте.
Книга: Размышления Ицхака Адизеса о личном развитии
Ицхак Адизес — известный бизнес-консультант, который придумал классифицировать менеджеров по 4-м ролям: P (производство), A (администрирование), E (предпринимательство) и I (умение объединять людей). Код PAEI описывает стиль управления руководителя, его совместимость с командой или организацией на каждой стадии развития. Судя по википедии, Адизес написал 8 книг с пафосными названиями вроде «Управляя изменениями» или «Развитие лидеров». Я читал «Как преодолеть кризисы менеджмента» — мне понравилось, когда-нибудь напишу о ней отдельный пост.
В «Размышлениях» Адизес сделал перерыв. Теперь он рассказывает не о теории управления организациями, а о личных материях. Этим «Размышления» и примечательны — вы получите селф-хелп, но не от профессионала вроде Дейла Карнеги, а от признанного бизнес-эксперта с мировым именем.
Книга представляет собой дайджест из блога Адизеса на волнующие темы: откуда берутся вредные привычки, где находить время на семью, как контролировать эмоции и принимать решения в отношениях. Несколько разделов посвящены неосязаемым вещам вроде иуадизма или рей-ки.
Наверное для меня это еще рано, но из «духовной» части размышлений я ничего не вынес — не понимаю, чем могут быть полезны размышления о судьбах евреев или об уважении к родителям.
Книга короткая (у Темы толще). Ту часть которая имеет отношение к реальности, нужно читать как блог или рассылку — по 2–3 главы за один раз, спокойно переосмысливая все, что рассказывает Адизес.
Книга продается на озоне.
Ицхак Адизес — известный бизнес-консультант, который придумал классифицировать менеджеров по 4-м ролям: P (производство), A (администрирование), E (предпринимательство) и I (умение объединять людей). Код PAEI описывает стиль управления руководителя, его совместимость с командой или организацией на каждой стадии развития. Судя по википедии, Адизес написал 8 книг с пафосными названиями вроде «Управляя изменениями» или «Развитие лидеров». Я читал «Как преодолеть кризисы менеджмента» — мне понравилось, когда-нибудь напишу о ней отдельный пост.
В «Размышлениях» Адизес сделал перерыв. Теперь он рассказывает не о теории управления организациями, а о личных материях. Этим «Размышления» и примечательны — вы получите селф-хелп, но не от профессионала вроде Дейла Карнеги, а от признанного бизнес-эксперта с мировым именем.
Книга представляет собой дайджест из блога Адизеса на волнующие темы: откуда берутся вредные привычки, где находить время на семью, как контролировать эмоции и принимать решения в отношениях. Несколько разделов посвящены неосязаемым вещам вроде иуадизма или рей-ки.
Наверное для меня это еще рано, но из «духовной» части размышлений я ничего не вынес — не понимаю, чем могут быть полезны размышления о судьбах евреев или об уважении к родителям.
Книга короткая (у Темы толще). Ту часть которая имеет отношение к реальности, нужно читать как блог или рассылку — по 2–3 главы за один раз, спокойно переосмысливая все, что рассказывает Адизес.
Книга продается на озоне.
Ребята из Movable Ink исхитрились и вставили в письмо живой таймер обратного отсчета. Интересно, как быстро такой таймер попадет в письма озона?
Мне тут подсказывают, что таймер не совсем живой, однако иллюзия очень крутая — открываешь письмо, а оно ШЕВЕЛИТСЯ
Как убить технаря в руководителе
Александр Трофимов рассказывает обо всех граблях, на которые наступил, когда из программиста превратился в руководителя.
Рассказ — длинный. Там и попытки делать работу за других, и микроконтроль и даже Павлик Морозов. Опыт Александра взят из Лаборатории Касперского, однако специфики больших компаний совсем не много. Есть видеоверсия.
Рассказ будет полезен если вы (или ваши подчиненные) только что резко повысили свой уровень ответственности.
Картинка на тему одной известной книги, посвященной управлению программистами:
Александр Трофимов рассказывает обо всех граблях, на которые наступил, когда из программиста превратился в руководителя.
Рассказ — длинный. Там и попытки делать работу за других, и микроконтроль и даже Павлик Морозов. Опыт Александра взят из Лаборатории Касперского, однако специфики больших компаний совсем не много. Есть видеоверсия.
Рассказ будет полезен если вы (или ваши подчиненные) только что резко повысили свой уровень ответственности.
Картинка на тему одной известной книги, посвященной управлению программистами:
Без срочных задач
Во всех своих командах я избавляюсь от срочных задач. Люблю, когда даже в трекере такого флага нет.
Без срочных задач ребята сами управляют временем, а значит живут в комфортном и эффективном графике. Можно сходить в кино во вторник, устроить выходной в среду, или наоборот, быстро закрыть все задачи и отдыхать три дня подряд. Лично мне больше нравится график без выходных — когда я дозирую нагрузку каждый день, в зависимости от настроения и планов.
Такой режим приносит огромную пользу бизнесу — когда нет срочного, делается больше важного. При этом действительно срочные задачи каким-то таинственным образом решаются.
Конечно, не все люди совместимы с таким графиком — даже среди высокоразвитых профессионалов много таких, которые зависят от внешних стимулов. Такие люди обычно выявляются за первые две недели испытательного срока. Зависимость от внешних стимулов — не порок, это скорее индивидуальные особенности. Есть же чуваки, которые наоборот, не совместимы с большими компаниями (как я), или в принципе не могут работать без личного контакта с коллегами.
Вот вам три шага, чтобы победить срочные задачи в вашей команде:
🔹 Разберитесь с техническими и управленческими долгами. Чаще всего срочные задачи возникают на уровне «я выкатил, а оно упало», и «я выкатил, а через неделю поняли, что нихуя не работает». Чтобы привести долги в порядок, нужна сила воли и пара месяцев. Если вы понимаете, что за два месяца не разберетесь — значит что-то в вашем проекте серьезно не в порядке, нужно все бросать и лечить.
🔹 Перестаньте оценивать задачи в часах. Если в вашей команде меньше 5 человек — совсем не оценивайте. Если больше, и план на неделю не удается обсудить с каждым лично — попробуйте оценивать днями.
🔹 Возьмите комфортный интервал планирования, на который вы можете построить четкий план, к примеру 1 неделю. Заложите запас и не трогайте ребят в течение этого интервала.
Во всех своих командах я избавляюсь от срочных задач. Люблю, когда даже в трекере такого флага нет.
Без срочных задач ребята сами управляют временем, а значит живут в комфортном и эффективном графике. Можно сходить в кино во вторник, устроить выходной в среду, или наоборот, быстро закрыть все задачи и отдыхать три дня подряд. Лично мне больше нравится график без выходных — когда я дозирую нагрузку каждый день, в зависимости от настроения и планов.
Такой режим приносит огромную пользу бизнесу — когда нет срочного, делается больше важного. При этом действительно срочные задачи каким-то таинственным образом решаются.
Конечно, не все люди совместимы с таким графиком — даже среди высокоразвитых профессионалов много таких, которые зависят от внешних стимулов. Такие люди обычно выявляются за первые две недели испытательного срока. Зависимость от внешних стимулов — не порок, это скорее индивидуальные особенности. Есть же чуваки, которые наоборот, не совместимы с большими компаниями (как я), или в принципе не могут работать без личного контакта с коллегами.
Вот вам три шага, чтобы победить срочные задачи в вашей команде:
🔹 Разберитесь с техническими и управленческими долгами. Чаще всего срочные задачи возникают на уровне «я выкатил, а оно упало», и «я выкатил, а через неделю поняли, что нихуя не работает». Чтобы привести долги в порядок, нужна сила воли и пара месяцев. Если вы понимаете, что за два месяца не разберетесь — значит что-то в вашем проекте серьезно не в порядке, нужно все бросать и лечить.
🔹 Перестаньте оценивать задачи в часах. Если в вашей команде меньше 5 человек — совсем не оценивайте. Если больше, и план на неделю не удается обсудить с каждым лично — попробуйте оценивать днями.
🔹 Возьмите комфортный интервал планирования, на который вы можете построить четкий план, к примеру 1 неделю. Заложите запас и не трогайте ребят в течение этого интервала.
Работа любого профессионала строится на обещаниях. Менеджер обещает достичь KPI, программист — сдать задачу в срок, пилот самолета — довезти пассажиров из точки A в точку Б.
Хорошо, когда длинная задача разбита на маленькие циклы «пообещал» → «сделал». Бизнесу это дает прозрачность — всегда видно ваш следующий шаг. Вам лично это позволяет быстро оценивать состояние дел — не расходится ли количество «пообещал» с количеством «сделал»?
Марьяна Онысько рассказывает о том, как они в электронной библиотеке МИФа дают обещания, которые зажигают не только команду, но и клиента:
Хорошо, когда длинная задача разбита на маленькие циклы «пообещал» → «сделал». Бизнесу это дает прозрачность — всегда видно ваш следующий шаг. Вам лично это позволяет быстро оценивать состояние дел — не расходится ли количество «пообещал» с количеством «сделал»?
Марьяна Онысько рассказывает о том, как они в электронной библиотеке МИФа дают обещания, которые зажигают не только команду, но и клиента:
Forwarded from Продукты, книги и любовь
Как обещания влияют на фокус команды
В каждой компании, которая купила электронную библиотеку МИФа, есть выделенные люди (кураторы библиотек), которые отвечают за маркетинг библиотеки внутри. И они сильно влияют на решение о покупке библиотеки на следующий год.
Когда мы решили активно развивать библиотеку, то первое что мы сделали после сбора команды — рассылку-обещание о поставке ценностей каждую неделю. Т.е мы сказали, что будем каждую неделю выпускать какое-то улучшение в библиотеке и раз в две недели оповещать кураторов об этом письмом.
Когда ты обещаешь своему клиенту что-то — у тебя возникает адский фокус. Ты думаешь «Блин, а что я напишу в следующем письме». И тогда включаются часики, которые тебе говорят «Что ты можешь выпустить за эту неделю, чтобы рассказать в письме?».
С августа, когда мы это затеяли, у нас забирали ресурс дизайнера, у нас не было фронта, еще куча вещей случалось, но мы бесперебойно каждые 2 недели пишем письма кураторам.
И кстати — это win-win. Потому что кураторы очень рады получать эти письма. Ведь они заплатили за один продукт, и никто не обещал, что мы в течение года добавим кучу фич.
В каждой компании, которая купила электронную библиотеку МИФа, есть выделенные люди (кураторы библиотек), которые отвечают за маркетинг библиотеки внутри. И они сильно влияют на решение о покупке библиотеки на следующий год.
Когда мы решили активно развивать библиотеку, то первое что мы сделали после сбора команды — рассылку-обещание о поставке ценностей каждую неделю. Т.е мы сказали, что будем каждую неделю выпускать какое-то улучшение в библиотеке и раз в две недели оповещать кураторов об этом письмом.
Когда ты обещаешь своему клиенту что-то — у тебя возникает адский фокус. Ты думаешь «Блин, а что я напишу в следующем письме». И тогда включаются часики, которые тебе говорят «Что ты можешь выпустить за эту неделю, чтобы рассказать в письме?».
С августа, когда мы это затеяли, у нас забирали ресурс дизайнера, у нас не было фронта, еще куча вещей случалось, но мы бесперебойно каждые 2 недели пишем письма кураторам.
И кстати — это win-win. Потому что кураторы очень рады получать эти письма. Ведь они заплатили за один продукт, и никто не обещал, что мы в течение года добавим кучу фич.
Тестовые задания для программистов
В процессе найма программистов принято давать тестовые задания. Обычное это демонстрирует аккуратность, знание заявленных технологий, способность понимать задачу и предвосхищать ожидания.
Самая большая ошибка — вместо тестового задания давать абстрактные задачи на знание алгоритмов. Часто ли в работе ваши программисты обходят графы или вручную реализуют шейкерную сортировку?
Клево, когда задание проверяет программиста в максимально реальных условиях. Я обычно даю настоящую, но устаревшую копию проекта — со всей документацией, багами и нерешенными долгами. Задачу ставлю ровно такую же, которую уже решали ребята из существующей команды.
Такое задание — как открытый вопрос. Поймет ли новенький наш стиль для названий тестов? Не испугается ли сложности? Дополнит ли документацию? Напишет ли переиспользуемый код? Не постесняется задавать вопросы? Выдержит ли дедлайн, который сам назовёт?
Если вдруг проект не получается отдать из-за НДА-шных причин — отдаю специально хранимый для этих целей pet project.
В процессе найма программистов принято давать тестовые задания. Обычное это демонстрирует аккуратность, знание заявленных технологий, способность понимать задачу и предвосхищать ожидания.
Самая большая ошибка — вместо тестового задания давать абстрактные задачи на знание алгоритмов. Часто ли в работе ваши программисты обходят графы или вручную реализуют шейкерную сортировку?
Клево, когда задание проверяет программиста в максимально реальных условиях. Я обычно даю настоящую, но устаревшую копию проекта — со всей документацией, багами и нерешенными долгами. Задачу ставлю ровно такую же, которую уже решали ребята из существующей команды.
Такое задание — как открытый вопрос. Поймет ли новенький наш стиль для названий тестов? Не испугается ли сложности? Дополнит ли документацию? Напишет ли переиспользуемый код? Не постесняется задавать вопросы? Выдержит ли дедлайн, который сам назовёт?
Если вдруг проект не получается отдать из-за НДА-шных причин — отдаю специально хранимый для этих целей pet project.
Книга: Голая Статистика
Статистика — единственная полезная наука, которую нельзя изучить через википедию. Так что если соберетесь — начните с «Голой статистики» Чарьльза Уиллана.
Автор не углубляется в теорию и трогательно извиняется, когда ссылается на формулы. Книга — практичная: расскажет как устроены опросы общественного мнения, что такое корреляция и центральная предельная теорема, и что лучше показывать руководству — среднее арифметичекое или медиану.
Читать «Статистику» стоит всем, чья работа связана с цифрами. Если ваша — не связана, то почитайте хотя бы начало, где автор рассказывает о популярных приемах вранья при помощи статистики.
> Систематическая ошибка выбора может возникнуть при различных обстоятельствах. Опрос потребителей в аэропорту искажается тем фактом, что любители летать самолетами, как правило, более состоятельные люди, чем население в целом; в случае проведения опроса на площадке для отдыха возле автомагистрали Interstate 90 может сложиться противоположная ситуация.
> На результаты обоих опросов наверняка повлияет и то, что люди, готовые в них участвовать, отличаются от людей, предпочитающих не отвлекаться на подобные вещи. Если вы попросите 100 человек в каком-либо общественном месте заполнить совсем небольшую анкету, то те 60, которые согласятся это сделать, наверняка будут существенно отличаться от остальных 40, которые вас проигнорируют.
Книга продается на озоне.
Статистика — единственная полезная наука, которую нельзя изучить через википедию. Так что если соберетесь — начните с «Голой статистики» Чарьльза Уиллана.
Автор не углубляется в теорию и трогательно извиняется, когда ссылается на формулы. Книга — практичная: расскажет как устроены опросы общественного мнения, что такое корреляция и центральная предельная теорема, и что лучше показывать руководству — среднее арифметичекое или медиану.
Читать «Статистику» стоит всем, чья работа связана с цифрами. Если ваша — не связана, то почитайте хотя бы начало, где автор рассказывает о популярных приемах вранья при помощи статистики.
> Систематическая ошибка выбора может возникнуть при различных обстоятельствах. Опрос потребителей в аэропорту искажается тем фактом, что любители летать самолетами, как правило, более состоятельные люди, чем население в целом; в случае проведения опроса на площадке для отдыха возле автомагистрали Interstate 90 может сложиться противоположная ситуация.
> На результаты обоих опросов наверняка повлияет и то, что люди, готовые в них участвовать, отличаются от людей, предпочитающих не отвлекаться на подобные вещи. Если вы попросите 100 человек в каком-либо общественном месте заполнить совсем небольшую анкету, то те 60, которые согласятся это сделать, наверняка будут существенно отличаться от остальных 40, которые вас проигнорируют.
Книга продается на озоне.
Гитхаб продолжает удивлять своей заботой о программистах.
Если упомянуть какой-нибудь опенсорсный проект внутри своего приватного, то тег покажется на странице опенсорсного проекта. И увижу его только я и члены моей команды.
Попробуйте представить масштаб — сколько такая мелкая фича обошлась бы в такой нагруженной системе? А в вашем проекте нашелся бы менеджер, которому хватило бы решимости довести такую фичу до продакшена?
Гитхаб — это те ребята, которым точно стоит заплатить денег, чтобы они захостили ваш код.
Если упомянуть какой-нибудь опенсорсный проект внутри своего приватного, то тег покажется на странице опенсорсного проекта. И увижу его только я и члены моей команды.
Попробуйте представить масштаб — сколько такая мелкая фича обошлась бы в такой нагруженной системе? А в вашем проекте нашелся бы менеджер, которому хватило бы решимости довести такую фичу до продакшена?
Гитхаб — это те ребята, которым точно стоит заплатить денег, чтобы они захостили ваш код.
У канала новости — благодаря Саше Бизикову обновилась иконка. Саша успешно проходит сложный путь из разработчика в дизайнеры, ведет интересный канал @bizikovru, и любезно согласился помочь с иконкой.
Вторая новость: благодаря пинку от все того же Саши, наша дорогая редакция наконец-то определилась с форматом канала.
Все новые заметки будут посвящены одной (и моей любимой) теме — производству сложных проектов с позиции CTO. Тем много — инструментарий, управление командами разработки, построение отношений с бизнесом, проектный менеджмент. Иногда будут появляться новости про мой любимый стек — Python и vue.js.
Канал перестает быть блогом ненужного менеджера (хотя я по-прежнему считаю, что менеджеры в хорошей команде не нужны) и, пока я не придумал лучшее название, становится каналом имени меня.
Вторая новость: благодаря пинку от все того же Саши, наша дорогая редакция наконец-то определилась с форматом канала.
Все новые заметки будут посвящены одной (и моей любимой) теме — производству сложных проектов с позиции CTO. Тем много — инструментарий, управление командами разработки, построение отношений с бизнесом, проектный менеджмент. Иногда будут появляться новости про мой любимый стек — Python и vue.js.
Канал перестает быть блогом ненужного менеджера (хотя я по-прежнему считаю, что менеджеры в хорошей команде не нужны) и, пока я не придумал лучшее название, становится каналом имени меня.
Как удобно планировать встречи
Созвоны — важная часть работы любой удаленной команды. Во взрослых командах, в которых не принято звонить друг-другу по любому поводу, часто пользуются корпоративными календарями, вроде гугловского. Это удобно — все видят загрузку коллеги и могут вписаться в свободное время. Не нужно обмениваться десятком писем-подтверждений ради одной встречи.
Минус публичного календаря — сложно открывать его наружу компании, к примеру для собеседований или подрядчиков. Чтобы записаться, получателю приходится обязательно регистрироваться в гугль-каленадре. Процесс записи тоже сложен — как человеку извне можно понять, удобно ли мне созвониться в 21:00, или просто это время свободное?
Второй минус гугль-календаря — чтобы удобно настроить доступные часы, приходится действовать от противного: не ограничивать доступное время, а закрывать недоступное какими-нибудь фейковыми делами, вроде «занято».
Чтобы решать эти проблемы, существуют сервисы планирования, вроде calendly.com или appoint.ly. Основной продукт у этих сервисов предельно простой — создаешь в них расписание, подключаешь свой календарь и получаешь публичную ссылку, которую рассылаешь всем авторизованным.
Сервис сам определяет свободное время (в рамках расписания конечно), добавляет новые события в календарь, и даже рассылает уведомления. Большинство этих сервисов доступны бесплатно на весьма лояльных условиях.
Вот так к примеру выглядит ссылка на мой календарь сегодня:
Созвоны — важная часть работы любой удаленной команды. Во взрослых командах, в которых не принято звонить друг-другу по любому поводу, часто пользуются корпоративными календарями, вроде гугловского. Это удобно — все видят загрузку коллеги и могут вписаться в свободное время. Не нужно обмениваться десятком писем-подтверждений ради одной встречи.
Минус публичного календаря — сложно открывать его наружу компании, к примеру для собеседований или подрядчиков. Чтобы записаться, получателю приходится обязательно регистрироваться в гугль-каленадре. Процесс записи тоже сложен — как человеку извне можно понять, удобно ли мне созвониться в 21:00, или просто это время свободное?
Второй минус гугль-календаря — чтобы удобно настроить доступные часы, приходится действовать от противного: не ограничивать доступное время, а закрывать недоступное какими-нибудь фейковыми делами, вроде «занято».
Чтобы решать эти проблемы, существуют сервисы планирования, вроде calendly.com или appoint.ly. Основной продукт у этих сервисов предельно простой — создаешь в них расписание, подключаешь свой календарь и получаешь публичную ссылку, которую рассылаешь всем авторизованным.
Сервис сам определяет свободное время (в рамках расписания конечно), добавляет новые события в календарь, и даже рассылает уведомления. Большинство этих сервисов доступны бесплатно на весьма лояльных условиях.
Вот так к примеру выглядит ссылка на мой календарь сегодня:
Не любить новые фичи
Если вы работали с опытными продуктовыми менеджерами, то знаете, насколько они не любят новые фичи. Прежде, чем поставить фичу в план, продуктолог испробует все возможные способы от нее отказаться. У Интеркома даже целый мануал на эту тему есть.
Ненавидеть фичи — задача не только продуктолога, но и всей команды: дизайнеров, программистов, менеджеров и тестировщиков. Особенно важно ненавидеть фичи в стартапах.
Между простым и сложным, влюбленный в фичу программист всегда выбирает сложное. Он будет рефакторить код, менять архитектуру и делать другие программистские штуки только ради того, чтобы новой фиче приятнее жилось в системе. Не важно, что фичу не внедрят или забудут — программист любит свою работу и сделает ее хорошо.
Когда программист не любит фичи, все наоборот — он пишет код, не касаясь участков приложения, которые можно не трогать. Если фича заработает — плохой код перепишут, не страшно. Если не заработает — ну и хрен с ней, сделаем реверт.
Менеджер, который любит фичи, не жалеет инвестиций, — выделяет время команды и стейкхолдеров, нанимает больше программистов, и вообще превращается в трудолюбивого идиота.
Трезвый менеджер, наоборот, думает про цифры — на какую метрику бизнеса эта фича влияет? А что считать показателем успеха внедрения? Если ответов нет — фича режется.
Давайте экономить деньги и не любить фичи.
Если вы работали с опытными продуктовыми менеджерами, то знаете, насколько они не любят новые фичи. Прежде, чем поставить фичу в план, продуктолог испробует все возможные способы от нее отказаться. У Интеркома даже целый мануал на эту тему есть.
Ненавидеть фичи — задача не только продуктолога, но и всей команды: дизайнеров, программистов, менеджеров и тестировщиков. Особенно важно ненавидеть фичи в стартапах.
Между простым и сложным, влюбленный в фичу программист всегда выбирает сложное. Он будет рефакторить код, менять архитектуру и делать другие программистские штуки только ради того, чтобы новой фиче приятнее жилось в системе. Не важно, что фичу не внедрят или забудут — программист любит свою работу и сделает ее хорошо.
Когда программист не любит фичи, все наоборот — он пишет код, не касаясь участков приложения, которые можно не трогать. Если фича заработает — плохой код перепишут, не страшно. Если не заработает — ну и хрен с ней, сделаем реверт.
Менеджер, который любит фичи, не жалеет инвестиций, — выделяет время команды и стейкхолдеров, нанимает больше программистов, и вообще превращается в трудолюбивого идиота.
Трезвый менеджер, наоборот, думает про цифры — на какую метрику бизнеса эта фича влияет? А что считать показателем успеха внедрения? Если ответов нет — фича режется.
Давайте экономить деньги и не любить фичи.
Я не знаю ни одного владельца нового макбука, который был бы доволен тачбаром. Написал статью, которая рассказывает, как не отвлекаться на ненужные кнопки и переключающиеся треки: http://telegra.ph/Kak-zhit-s-tachbarom-02-27-2