Какие плюсы даст типизация вашему проекту
Сегодня хотел бы остановиться на более технической теме, не касаясь вопросов управления и организации. А именно паре простых вещей, которые сделают ваш проект значительно лучше с точки зрения сопровождения.
В последнее время я в основном имею дело с языком Go. Избегая вопросов о плюсах и минусах, скажу, что, даже после многих лет работы на Python, обязательная типизация все равно имеет больше плюсов, чем дает удобство от ее отсутствия. Опуская все возражения, что задавать типы сложно и неудобно, а так же что в Go многое нельзя сделать (что довольно забавно, если это не пытаются рассказать вам лично), то строгая типизация дает сильный прирост в читаемости и строгости написания кода. Пропадает эта частая проблема, что же тут вообще идет на вход, а что на выход и почему в одном из миллиона случаев оно ломается (как раз когда подается на вход не пойми что).
Как раз на днях копался в Python проекте и убил большую часть времени, чтобы разобраться в тонкостях входных и выходных данных, а по скольку тестов конечно же тоже не было, то это заняло какое-то время.
Также я проводил несколько беглых ревью фронтовых проектов и должен сказать, что проекты на TypeScript с классами, настолько понятнее и легче во вхождении, что вся это фронтовая магия не стоит того, чтобы пренебречь таким инструментарием. С учетом моего небольшого знания губин JS, проект на TypeScript оценить было легче всего, как и понять, что там происходит.
Собственно к чему это я все говорю. А к тому, что в современной разработке очень пагубно избегать использования типизации и тестов. Наличие только этого, повысит читаемость и поддерживаемость вашего проекта (конечно если не использовать везде где не надо костыли вроде any или interface{}). Так же это сэкономит уйму времени для людей, которых вы вводите в проекте. И для этого не нужно отказываться от своих языков и фреймворков. В Python давно уже есть typing и mypy, как и pytest. TypeScript так же не наложит на вас особых ограничений, кроме некоторого времени на погружение в детали. Используйте инструменты, которые позволят вам сделать ваши проекты понятнее и проще поддерживаемыми, оно того стоит. Тем более, что затраты на внедрение невелики, а тесты должны быть и так в каждом проекте. Если этот пост зайдет, то можно будет также порассуждать о плюсах и минусах grpc, protobuf и многого другого.
Максим Шаламов
#разработчику
Сегодня хотел бы остановиться на более технической теме, не касаясь вопросов управления и организации. А именно паре простых вещей, которые сделают ваш проект значительно лучше с точки зрения сопровождения.
В последнее время я в основном имею дело с языком Go. Избегая вопросов о плюсах и минусах, скажу, что, даже после многих лет работы на Python, обязательная типизация все равно имеет больше плюсов, чем дает удобство от ее отсутствия. Опуская все возражения, что задавать типы сложно и неудобно, а так же что в Go многое нельзя сделать (что довольно забавно, если это не пытаются рассказать вам лично), то строгая типизация дает сильный прирост в читаемости и строгости написания кода. Пропадает эта частая проблема, что же тут вообще идет на вход, а что на выход и почему в одном из миллиона случаев оно ломается (как раз когда подается на вход не пойми что).
Как раз на днях копался в Python проекте и убил большую часть времени, чтобы разобраться в тонкостях входных и выходных данных, а по скольку тестов конечно же тоже не было, то это заняло какое-то время.
Также я проводил несколько беглых ревью фронтовых проектов и должен сказать, что проекты на TypeScript с классами, настолько понятнее и легче во вхождении, что вся это фронтовая магия не стоит того, чтобы пренебречь таким инструментарием. С учетом моего небольшого знания губин JS, проект на TypeScript оценить было легче всего, как и понять, что там происходит.
Собственно к чему это я все говорю. А к тому, что в современной разработке очень пагубно избегать использования типизации и тестов. Наличие только этого, повысит читаемость и поддерживаемость вашего проекта (конечно если не использовать везде где не надо костыли вроде any или interface{}). Так же это сэкономит уйму времени для людей, которых вы вводите в проекте. И для этого не нужно отказываться от своих языков и фреймворков. В Python давно уже есть typing и mypy, как и pytest. TypeScript так же не наложит на вас особых ограничений, кроме некоторого времени на погружение в детали. Используйте инструменты, которые позволят вам сделать ваши проекты понятнее и проще поддерживаемыми, оно того стоит. Тем более, что затраты на внедрение невелики, а тесты должны быть и так в каждом проекте. Если этот пост зайдет, то можно будет также порассуждать о плюсах и минусах grpc, protobuf и многого другого.
Максим Шаламов
#разработчику
Всего неделя до Нового Года! 🎉🥳
Вы же не думаете, что мы оставим вас без подарка?! 👀🎁
Специально для пользователей нашего канала мы подготовили промокод на наши обучающие материалы со скидкой 22% (в честь уходящего года):
NEW_YEAR_2023
Если вы хотите дать буст своей карьере с началом нового года, то крайне рекомендуем наш учебник для тимлидов. Там собраны самые полезные практические знания для начинающего, и не только, тимлида от нашего СТО с многолетним опытом Максима Шаламова. Отличное решение для тех, кто хочет в спокойной обстановке почитать что-то полезное.
А если вам надоело читать книжки и не терпится ринуться в бой, то с 10 января начнется интенсив для тимлидов, где вы вместе с Максимом в качестве ментора будете решать практические задачи по управлению командой. Это отличная возможность начать свою карьеру руководителя под крылом опытного наставника, разобрать все самые горячие кейсы, с которыми вы обязательно столкнетесь в карьере руководителя и задать волнующие вопросы по вашему собственному опыту. Зачем ждать, когда ваш руководитель решит вложиться в ваш рост, когда можно сделать первый шаг уже сейчас. Материалы курса доступны сразу после оплаты.
И все же для многих год был непростым, и если вы чувствуете, что ваши силы на исходе, а работа перестала приносить радость, то вам просто необходима наша Экстренная помощь при выгорании. Не откладывайте заботу о себе в долгий ящик, начните новый год с чистого листа.
Помните, что промокод превратится в тыкву в полночь 31 декабря.
Спасибо, что были с нами этот год, мы будем и дальше радовать вас постами из нашего опыта! С наступающими и до встречи в новом году!
Вы же не думаете, что мы оставим вас без подарка?! 👀🎁
Специально для пользователей нашего канала мы подготовили промокод на наши обучающие материалы со скидкой 22% (в честь уходящего года):
NEW_YEAR_2023
Если вы хотите дать буст своей карьере с началом нового года, то крайне рекомендуем наш учебник для тимлидов. Там собраны самые полезные практические знания для начинающего, и не только, тимлида от нашего СТО с многолетним опытом Максима Шаламова. Отличное решение для тех, кто хочет в спокойной обстановке почитать что-то полезное.
А если вам надоело читать книжки и не терпится ринуться в бой, то с 10 января начнется интенсив для тимлидов, где вы вместе с Максимом в качестве ментора будете решать практические задачи по управлению командой. Это отличная возможность начать свою карьеру руководителя под крылом опытного наставника, разобрать все самые горячие кейсы, с которыми вы обязательно столкнетесь в карьере руководителя и задать волнующие вопросы по вашему собственному опыту. Зачем ждать, когда ваш руководитель решит вложиться в ваш рост, когда можно сделать первый шаг уже сейчас. Материалы курса доступны сразу после оплаты.
И все же для многих год был непростым, и если вы чувствуете, что ваши силы на исходе, а работа перестала приносить радость, то вам просто необходима наша Экстренная помощь при выгорании. Не откладывайте заботу о себе в долгий ящик, начните новый год с чистого листа.
Помните, что промокод превратится в тыкву в полночь 31 декабря.
Спасибо, что были с нами этот год, мы будем и дальше радовать вас постами из нашего опыта! С наступающими и до встречи в новом году!
Основные мысли по результатам года
Перед Новым Годом хотел бы не много обобщить мысли, с которыми смирялся последние 2 года и смог собрать в кучу в момент смены работу, которая пришлась на сентябрь 22 года. В целом, опыт более волнительный, чем хотелось бы, но не могу сказать, что неудачный. Проекты интереснее, людей больше, что еще для счастья надо?)
Однако, хочется скорее поговорить о выводах, которые сделал для себя. Они все не новы, но лично я не мог с ними примириться какое-то время.
Ставьте реальные цели
Амбиции и желание сделать лучше это хорошо, но всегда ставьте реальные цели. Это как участвовать в “24 часа Ле-Мана” на запорожце и ставить цели победить. Это глупо и абсурдно, и сколько бы сил вы не вложили, кроме разочарования вы ничего не получите. Но вот скажем цель просто не сойти с дистанции уже будет реальной, сложной, но достижимой.
Цели должны основываться на возможностях и целях компании
Всегда, ставьте цели от задач и возможностей компании. Оно может и дублирует слегка, но это все очень важно. Если вы хотите успешно работать в компании (я говорю работать, про видимость работы это не сюда), вы должны понимать проблемы и цели, которые вы решите для компании. Не всегда вам их готовы озвучить, в этом есть особое умение. Вы можете их немного развернуть так, чтоб вам было проще или интереснее, но думайте о том, что вы покажете, как результат, и думайте о том, кто будет принимать результат. Как бы все там не было, если принимающая сторона ничего не смыслит в том, что вы сделали, но какой-то формочки нет, то это ваша проблема. Если в компании нет целей, то прогнозировать свое будущее в ней довольно сложно.
Подбирайте правильных людей
Все также уверен, что команда решает, но пришел к тому, что нужно системно подходить к вопросу переоценки участников вашей команды. Можно не заметить, как люди, которые с вами давно, начинают создавать больше проблем, чем решают. Но они же свои, так комфортно, без этого страшно. Это все не аргументы, подбирайте людей, решающих нужные вам проблемы.
Команда, это больше чем группа сработанных людей. Это группа единомышленников, которые понимают почему и зачем они что-то делают вместе и делают коллектив сильнее. С этой точки зрения, особо больших команд быть не может впринципе. Тем ценнее такие люди вокруг, просто объективно подходите к выбору и оценке людей.
Не бойтесь рисковать
Если вы зашли в тупик, то все же стоит рисковать, даже где-то откатываться и начинать нарабатывать в новой компании все с начала. Из тупика роста нет, а так вы откроете для себя пространство.
Контакты нужны всем
Ищите хорошие контакты и единомышленников. В наше время это важно, как никогда.
На этом все, надеюсь, что-то полезное вы смогли почерпнуть. Напомню, что до 31 декабря вы можете использовать промокод NEW_YEAR_2023 для покупки моих обучающих материалов. Там я собрал для вас самое важное из своего опыта, этих материалов нет на этом канале. Всех с наступающими праздниками! И до встречи в нового году, берегите себя и своих близких, и не болейте!
Максим Шаламов
Перед Новым Годом хотел бы не много обобщить мысли, с которыми смирялся последние 2 года и смог собрать в кучу в момент смены работу, которая пришлась на сентябрь 22 года. В целом, опыт более волнительный, чем хотелось бы, но не могу сказать, что неудачный. Проекты интереснее, людей больше, что еще для счастья надо?)
Однако, хочется скорее поговорить о выводах, которые сделал для себя. Они все не новы, но лично я не мог с ними примириться какое-то время.
Ставьте реальные цели
Амбиции и желание сделать лучше это хорошо, но всегда ставьте реальные цели. Это как участвовать в “24 часа Ле-Мана” на запорожце и ставить цели победить. Это глупо и абсурдно, и сколько бы сил вы не вложили, кроме разочарования вы ничего не получите. Но вот скажем цель просто не сойти с дистанции уже будет реальной, сложной, но достижимой.
Цели должны основываться на возможностях и целях компании
Всегда, ставьте цели от задач и возможностей компании. Оно может и дублирует слегка, но это все очень важно. Если вы хотите успешно работать в компании (я говорю работать, про видимость работы это не сюда), вы должны понимать проблемы и цели, которые вы решите для компании. Не всегда вам их готовы озвучить, в этом есть особое умение. Вы можете их немного развернуть так, чтоб вам было проще или интереснее, но думайте о том, что вы покажете, как результат, и думайте о том, кто будет принимать результат. Как бы все там не было, если принимающая сторона ничего не смыслит в том, что вы сделали, но какой-то формочки нет, то это ваша проблема. Если в компании нет целей, то прогнозировать свое будущее в ней довольно сложно.
Подбирайте правильных людей
Все также уверен, что команда решает, но пришел к тому, что нужно системно подходить к вопросу переоценки участников вашей команды. Можно не заметить, как люди, которые с вами давно, начинают создавать больше проблем, чем решают. Но они же свои, так комфортно, без этого страшно. Это все не аргументы, подбирайте людей, решающих нужные вам проблемы.
Команда, это больше чем группа сработанных людей. Это группа единомышленников, которые понимают почему и зачем они что-то делают вместе и делают коллектив сильнее. С этой точки зрения, особо больших команд быть не может впринципе. Тем ценнее такие люди вокруг, просто объективно подходите к выбору и оценке людей.
Не бойтесь рисковать
Если вы зашли в тупик, то все же стоит рисковать, даже где-то откатываться и начинать нарабатывать в новой компании все с начала. Из тупика роста нет, а так вы откроете для себя пространство.
Контакты нужны всем
Ищите хорошие контакты и единомышленников. В наше время это важно, как никогда.
На этом все, надеюсь, что-то полезное вы смогли почерпнуть. Напомню, что до 31 декабря вы можете использовать промокод NEW_YEAR_2023 для покупки моих обучающих материалов. Там я собрал для вас самое важное из своего опыта, этих материалов нет на этом канале. Всех с наступающими праздниками! И до встречи в нового году, берегите себя и своих близких, и не болейте!
Максим Шаламов
План по приведению отдела в порядок, разбираем предновогодний кейс
Сегодня хочу поделиться опытом с пылу с жару так сказать. Представьте, что вы уже закрыли год, все распланировали на новый и до конца года осталось 3 недели. И тут вам прилетает новый отдел, где из вводных есть только то, что едут все сроки, нет прозрачности и вообще людей, которыми усиливали отдел, хотят вернуть на другие задачи. Надо бы все завести, а до конца года хотя бы погасить пожары и составить общее видение и план. Вот такая абстрактная ситуация, которая со мной случается чаще, чем я ожидал. Итого, есть: вы и свободные 60% дня (другие задачи сами себя не сделают), установочная встреча с бизнес лидером и тем, кто пытался до вас.
С чего начать
Итак, что делаем, прямо по шагам.
• Верхнеуровнево вникаем в детали бизнеса, смотрим цели и планы. Собираем видение проблем с бизнеса. Записываем выжимку полученной информации.
• Дальше параллельно идем двумя путями:
◦ знакомимся с ПО каждой команды и тем, что они делают. Записываем основные моменты, планы, смотрим как они пересекаются с общими планами. Выписываем основные проблемы
◦ знакомимся с лидами. Записываем их видение дел и проблем.
• Выписываем все полученные проблемы, объединяя общие. Приоритезируем проблемы. Из списка проблем выделяем смежников, на которых завязаны.
• Знакомимся со смежниками и пытаемся наладить контакт, собираем их версию проблем.
• Выделяем проблемы, требующие немедленного решения и назначаем ответственных, желательно как можно больше делать не самому (времени мало, а дел много). В проблемах указываем ожидаемый результат и шаги, если они понятны. Не переживаем, что не знаем людей, за одно они себя и покажут в реальных условиях. Не забываем держать каждую проблему на контроле.
• Верхнеуровнево знакомимся с процессами команд и архитектурой проектов. В детали не лезем, времени мало. Выписываем основные проблемы, которые видим, они уйдут в план на первый или второй квартал.
Что имеем после первых действий
Итого, получаем:
• знакомство с основными участниками отдела;
• верхнеуровневое понимание бизнеса, целей и задач команд, архитектуры и ее проблем;
• самые насущные проблемы, часть из которых оперативно будет закрыта;
• знакомство со смежниками, от которых зависим и понимание их проблем и роли в рабочем процессе.
Имея это, мы начинаем контролировать основные блокеры, мешавшие запустить проекты, даже если не можем быстро на них повлиять. Мы уже можем составить план на первый квартал. В реальных условиях смотрим на то, как работают лиды и возможно ПО.
Важные уроки
Какие моменты могу выделить в очередной раз:
• многие проблемы со смежниками кроются в отсутствии нормально выстроенной коммуникации и понимания блокеров и приоритетов друг друга;
• команды, которые смогли запустить хоть что-то имеют зачатки адекватных процессов работы. Хаотичная работа, показывает нулевой результат;
• проекты без адекватного технического IT-руководства, при очень быстрых темпах роста, имеют тенденцию так же быстро разваливаться;
• мотивацией людей нужно заниматься, сама по себе мотивация к работе, идущая из гиперответственности, есть у единиц.
Надеюсь, что-то из этого будет вам полезно или просто занимательно для чтения.
#сто #тимлиду
Максим Шаламов
Сегодня хочу поделиться опытом с пылу с жару так сказать. Представьте, что вы уже закрыли год, все распланировали на новый и до конца года осталось 3 недели. И тут вам прилетает новый отдел, где из вводных есть только то, что едут все сроки, нет прозрачности и вообще людей, которыми усиливали отдел, хотят вернуть на другие задачи. Надо бы все завести, а до конца года хотя бы погасить пожары и составить общее видение и план. Вот такая абстрактная ситуация, которая со мной случается чаще, чем я ожидал. Итого, есть: вы и свободные 60% дня (другие задачи сами себя не сделают), установочная встреча с бизнес лидером и тем, кто пытался до вас.
С чего начать
Итак, что делаем, прямо по шагам.
• Верхнеуровнево вникаем в детали бизнеса, смотрим цели и планы. Собираем видение проблем с бизнеса. Записываем выжимку полученной информации.
• Дальше параллельно идем двумя путями:
◦ знакомимся с ПО каждой команды и тем, что они делают. Записываем основные моменты, планы, смотрим как они пересекаются с общими планами. Выписываем основные проблемы
◦ знакомимся с лидами. Записываем их видение дел и проблем.
• Выписываем все полученные проблемы, объединяя общие. Приоритезируем проблемы. Из списка проблем выделяем смежников, на которых завязаны.
• Знакомимся со смежниками и пытаемся наладить контакт, собираем их версию проблем.
• Выделяем проблемы, требующие немедленного решения и назначаем ответственных, желательно как можно больше делать не самому (времени мало, а дел много). В проблемах указываем ожидаемый результат и шаги, если они понятны. Не переживаем, что не знаем людей, за одно они себя и покажут в реальных условиях. Не забываем держать каждую проблему на контроле.
• Верхнеуровнево знакомимся с процессами команд и архитектурой проектов. В детали не лезем, времени мало. Выписываем основные проблемы, которые видим, они уйдут в план на первый или второй квартал.
Что имеем после первых действий
Итого, получаем:
• знакомство с основными участниками отдела;
• верхнеуровневое понимание бизнеса, целей и задач команд, архитектуры и ее проблем;
• самые насущные проблемы, часть из которых оперативно будет закрыта;
• знакомство со смежниками, от которых зависим и понимание их проблем и роли в рабочем процессе.
Имея это, мы начинаем контролировать основные блокеры, мешавшие запустить проекты, даже если не можем быстро на них повлиять. Мы уже можем составить план на первый квартал. В реальных условиях смотрим на то, как работают лиды и возможно ПО.
Важные уроки
Какие моменты могу выделить в очередной раз:
• многие проблемы со смежниками кроются в отсутствии нормально выстроенной коммуникации и понимания блокеров и приоритетов друг друга;
• команды, которые смогли запустить хоть что-то имеют зачатки адекватных процессов работы. Хаотичная работа, показывает нулевой результат;
• проекты без адекватного технического IT-руководства, при очень быстрых темпах роста, имеют тенденцию так же быстро разваливаться;
• мотивацией людей нужно заниматься, сама по себе мотивация к работе, идущая из гиперответственности, есть у единиц.
Надеюсь, что-то из этого будет вам полезно или просто занимательно для чтения.
#сто #тимлиду
Максим Шаламов
Как наладить интеграции
Пост про типизацию прошел весьма неплохо, поэтому я хотел бы закончить эту историю и рассказать о проблеме, от которой я к этому начал идти. И как многие, наверное, догадались, это проблема интеграций. Она остро стоит между фронт (web/mobile) и бэк, а еще хуже дела обстоят с межкомандными интеграциями.
Проблема интеграций
Классическая проблема заключается в том, что никто заранее не фиксирует форматы взаимодействия, а на интеграции мы получаем два нестыкующихся куска. Происходят бурные трения и выяснения, потом в несколько итераций все это соединяется. Если речь идет о межкомандных историях, то это уже занимает ощутимое время, но и внутри команд по сути время и нервы уходят впустую.
Начинаем решать проблему
Мы конечно же учимся на своих ошибках и говорим, что теперь мы на старте задач по интеграции согласуем формат. Отлично, с горем пополам согласовали и записали. Пришли к моменту интеграции - не стыкуется. На практике часто всплывают всякие вещи и часто можно услышать подобные объяснения: "ой тут было не додумано, не придумано, я поправил". Поправил и не сказал, собственно проблема интеграции на этом этапе сохранилась.
Идем дальше и учимся коммуницировать. Становится лучше, но проблем все равно с этим связанных остается много.
Как сделать еще лучше
Какой шаг можно рассмотреть следующим? Берем, на пример, gRPC, и, на этапе постановки задач на интеграции, фиксируем протокол общения. Раздаем сгенерированные под языки файлы и стыкуемся. Конечно поправить их может каждый и сказать, что так и надо было. Тут появляется новый ответственный за конкретную интеграцию, в задачи которого входит принимать и согласовывать изменения по формату и рассылать всем новые варианты. Чем больше команд будет вовлечено, тем сильнее необходимость в таком человеке, а не в саморегулирующемся процессе. Для очередей можно просто взять Protobuf.
Для меня следующий шаг в улучшении процесса интеграций и уменьшение издержек на него стоит потраченного времени на внедрение и поддержку gRPC и Protobuf. Конечно не каждому это нужно и это точно не решение без минусов. Но оно нацелено на улучшение ситуации в процессах интеграций и, при правильном подходе, улучшит и упростит ситуацию.
#разработчику
Максим Шаламов
Пост про типизацию прошел весьма неплохо, поэтому я хотел бы закончить эту историю и рассказать о проблеме, от которой я к этому начал идти. И как многие, наверное, догадались, это проблема интеграций. Она остро стоит между фронт (web/mobile) и бэк, а еще хуже дела обстоят с межкомандными интеграциями.
Проблема интеграций
Классическая проблема заключается в том, что никто заранее не фиксирует форматы взаимодействия, а на интеграции мы получаем два нестыкующихся куска. Происходят бурные трения и выяснения, потом в несколько итераций все это соединяется. Если речь идет о межкомандных историях, то это уже занимает ощутимое время, но и внутри команд по сути время и нервы уходят впустую.
Начинаем решать проблему
Мы конечно же учимся на своих ошибках и говорим, что теперь мы на старте задач по интеграции согласуем формат. Отлично, с горем пополам согласовали и записали. Пришли к моменту интеграции - не стыкуется. На практике часто всплывают всякие вещи и часто можно услышать подобные объяснения: "ой тут было не додумано, не придумано, я поправил". Поправил и не сказал, собственно проблема интеграции на этом этапе сохранилась.
Идем дальше и учимся коммуницировать. Становится лучше, но проблем все равно с этим связанных остается много.
Как сделать еще лучше
Какой шаг можно рассмотреть следующим? Берем, на пример, gRPC, и, на этапе постановки задач на интеграции, фиксируем протокол общения. Раздаем сгенерированные под языки файлы и стыкуемся. Конечно поправить их может каждый и сказать, что так и надо было. Тут появляется новый ответственный за конкретную интеграцию, в задачи которого входит принимать и согласовывать изменения по формату и рассылать всем новые варианты. Чем больше команд будет вовлечено, тем сильнее необходимость в таком человеке, а не в саморегулирующемся процессе. Для очередей можно просто взять Protobuf.
Для меня следующий шаг в улучшении процесса интеграций и уменьшение издержек на него стоит потраченного времени на внедрение и поддержку gRPC и Protobuf. Конечно не каждому это нужно и это точно не решение без минусов. Но оно нацелено на улучшение ситуации в процессах интеграций и, при правильном подходе, улучшит и упростит ситуацию.
#разработчику
Максим Шаламов
Как вернуть рабочий настрой после долгого отпуска или новогодних праздников
Всем нам, я думаю, тяжело начинать работать после отпуска или новогодних праздников. Периодически, события складываются так, что вас накрывает волной задач, которые надо решить здесь и сейчас, и втягивание происходит естественным образом. Если у вас все идет без форс-мажоров и авралов, я тоже могу предложить пару вариантов.
Составляем список, сортируем и фиксируем выполнение
Первое, зафиксируйте все задачи, которые вы хотите сделать письменно (на бумаге или компьютере), сделайте максимальную детализацию и выстройте их, по возможности, так, чтобы самые мелкие были вверху. Зачем вам такая скучная и нудная история, когда итак сложно собраться? Все очень просто, начните закрывать задачи и вычеркивать их (или закрывать в онлайн инструменте). Каждая решенная задача в таком формате будет придавать вам мотивацию работать дальше. Маленькие и простые задачи, позволят в первый же день выдать результат и дать себе позитивное подкрепление. Это очень простая техника, которая работает на всех с кем я ее пробовал.
Возьмитесь за интересные задачи
Еще отличным вариантом, если позволяет ситуация, будет заняться интересными именно вам задачами на исследования или улучшения, которые всегда есть, но всегда откладываются в виду не самого большого приоритета и необходимости. Работа над такими задачами обычно сильно увлекает и помогает быстро прийти в рабочую форму.
Не сидите без дела
Главное это не сидеть без дела, найдите любые задачи рабочие или около рабочие, но обязательно что-то делайте. Если сидеть с мыслями, как заставить себя работать, то скорее всего ответ будет - никак. Поэтому главное правило - начните делать и настрой придет.
Максим Шаламов
#советы
Всем нам, я думаю, тяжело начинать работать после отпуска или новогодних праздников. Периодически, события складываются так, что вас накрывает волной задач, которые надо решить здесь и сейчас, и втягивание происходит естественным образом. Если у вас все идет без форс-мажоров и авралов, я тоже могу предложить пару вариантов.
Составляем список, сортируем и фиксируем выполнение
Первое, зафиксируйте все задачи, которые вы хотите сделать письменно (на бумаге или компьютере), сделайте максимальную детализацию и выстройте их, по возможности, так, чтобы самые мелкие были вверху. Зачем вам такая скучная и нудная история, когда итак сложно собраться? Все очень просто, начните закрывать задачи и вычеркивать их (или закрывать в онлайн инструменте). Каждая решенная задача в таком формате будет придавать вам мотивацию работать дальше. Маленькие и простые задачи, позволят в первый же день выдать результат и дать себе позитивное подкрепление. Это очень простая техника, которая работает на всех с кем я ее пробовал.
Возьмитесь за интересные задачи
Еще отличным вариантом, если позволяет ситуация, будет заняться интересными именно вам задачами на исследования или улучшения, которые всегда есть, но всегда откладываются в виду не самого большого приоритета и необходимости. Работа над такими задачами обычно сильно увлекает и помогает быстро прийти в рабочую форму.
Не сидите без дела
Главное это не сидеть без дела, найдите любые задачи рабочие или около рабочие, но обязательно что-то делайте. Если сидеть с мыслями, как заставить себя работать, то скорее всего ответ будет - никак. Поэтому главное правило - начните делать и настрой придет.
Максим Шаламов
#советы
4 признака, что в вашей команде проблемы с процессами
Проблемы с процессами это слабое место многих компаний. Они напрямую ведут к потере прибыли, лишним тратам и созданию ненужного пользователю продукта. Самое коварное в ошибках процесса кроется в том, что они строятся на нашей психологии и мы можем даже не замечать, когда их совершаем. А самый важный шаг навстречу решению проблемы - осознать и признать ее наличие. Поэтому давайте разберем некоторые признаки, которые помогут вам выявить проблемы в процессах.
Постоянно вымотанная команда
Одно из последствий плохих процессов это переработки, которыми приходится компенсировать проседающий процесс. Переработки могут случатся в случае форс-мажора, но если компания на постоянной основе живет в таком ритме это признак плохо выстроенных процессов. От этого чаще всего страдает команда разработки и это можно заметить простым наблюдением. Люди уставшие, могут быть дергаными и нервными, с отсутствием инициативы и энтузиазма, общение в такой команде обычно не очень развито, потому что общаться никогда, да и не приветствуется.
Слишком много времени тратится на коммуникацию
Коммуникации невероятно важны в команде и могут помочь решить очень многие проблемы быстро и эффективно. Но иногда ими пытаются полностью заменить процессы. Если вы замечаете, что утопаете в коммуникациях, то стоит обратить внимание на правильность выстроенных процессов.
Начинаются новые фичи, когда старые еще не закончены
Нередко встречается такой стиль работы бизнеса, когда команде отдается крупный эпик, команда начинает его делать, и одновременно с этим бизнес приходит с новой большой фичей, которую срочно нужно делать. И такая работа ведется на постоянной основе. После этого на проекте обычно остаются части разного функционала, но единство продукта совершенно теряется. Здесь проблема в самом начале процесса - построении бизнес видения. Когда бизнес видение плохо составлено, то проект не сможет развиваться целостно, его будет мотать из одной стороны в другую.
Постоянные проверки руководителем
Случается, что руководитель, или представитель бизнеса, буквально стоит у вас над душой, когда вы решаете какую-то задачу. Постоянно пишет с вопросами: готова ли задача, а когда она будет готова, а чем сейчас занимаешься, а что потом будешь делать? Это все просто кричащий пример отсутствия процессов.
Таких признаков можно найти еще много, но эти встречаются чаще всего. Увидели в каком-то пункте свою команду? Тогда делитесь со своими коллегами, чтобы вместе обсудить проблему.
А мы пока готовим очень мощный материал по практическому применению Agile-практик. Тем, кто уже давно пробует Agile, он поможет понять, почему некоторые вещи не работают и как это исправить. А тем, кто никогда не работал с Agile, он поможет с нуля разобраться, как все должно работать именно на практике. Полный анонс будет чуть позже, так что оставайтесь с нами, вы все узнаете первыми!
Александра Шаламова
#agile_который_работает
Проблемы с процессами это слабое место многих компаний. Они напрямую ведут к потере прибыли, лишним тратам и созданию ненужного пользователю продукта. Самое коварное в ошибках процесса кроется в том, что они строятся на нашей психологии и мы можем даже не замечать, когда их совершаем. А самый важный шаг навстречу решению проблемы - осознать и признать ее наличие. Поэтому давайте разберем некоторые признаки, которые помогут вам выявить проблемы в процессах.
Постоянно вымотанная команда
Одно из последствий плохих процессов это переработки, которыми приходится компенсировать проседающий процесс. Переработки могут случатся в случае форс-мажора, но если компания на постоянной основе живет в таком ритме это признак плохо выстроенных процессов. От этого чаще всего страдает команда разработки и это можно заметить простым наблюдением. Люди уставшие, могут быть дергаными и нервными, с отсутствием инициативы и энтузиазма, общение в такой команде обычно не очень развито, потому что общаться никогда, да и не приветствуется.
Слишком много времени тратится на коммуникацию
Коммуникации невероятно важны в команде и могут помочь решить очень многие проблемы быстро и эффективно. Но иногда ими пытаются полностью заменить процессы. Если вы замечаете, что утопаете в коммуникациях, то стоит обратить внимание на правильность выстроенных процессов.
Начинаются новые фичи, когда старые еще не закончены
Нередко встречается такой стиль работы бизнеса, когда команде отдается крупный эпик, команда начинает его делать, и одновременно с этим бизнес приходит с новой большой фичей, которую срочно нужно делать. И такая работа ведется на постоянной основе. После этого на проекте обычно остаются части разного функционала, но единство продукта совершенно теряется. Здесь проблема в самом начале процесса - построении бизнес видения. Когда бизнес видение плохо составлено, то проект не сможет развиваться целостно, его будет мотать из одной стороны в другую.
Постоянные проверки руководителем
Случается, что руководитель, или представитель бизнеса, буквально стоит у вас над душой, когда вы решаете какую-то задачу. Постоянно пишет с вопросами: готова ли задача, а когда она будет готова, а чем сейчас занимаешься, а что потом будешь делать? Это все просто кричащий пример отсутствия процессов.
Таких признаков можно найти еще много, но эти встречаются чаще всего. Увидели в каком-то пункте свою команду? Тогда делитесь со своими коллегами, чтобы вместе обсудить проблему.
А мы пока готовим очень мощный материал по практическому применению Agile-практик. Тем, кто уже давно пробует Agile, он поможет понять, почему некоторые вещи не работают и как это исправить. А тем, кто никогда не работал с Agile, он поможет с нуля разобраться, как все должно работать именно на практике. Полный анонс будет чуть позже, так что оставайтесь с нами, вы все узнаете первыми!
Александра Шаламова
#agile_который_работает
Оцениваем своего руководителя
Сегодня я бы хотел поговорить не о вас, как руководителях (действующих или потенциальных), а о том, как можно оценить своего руководителя. Не все задумываются, но от руководителя зависит многое. И если то, насколько долго и успешно вы проработаете в компании зависит в первую очередь от вас, то на второе место можно смело ставить вашего руководителя. Приведу мой список параметров для оценки руководителя.
Умение держать слово
Одним из важнейших пунктов для меня идет умение держать слово. Потому что без этого, говорить о долгосрочных планах, развитии или чем-то долгосрочном вообще не получится. Если вы можете доверять договоренностям между вами и руководителем, у вас появится возможность не только планировать свою работу и рост, но и в целом понимать устраивает вас текущая ситуация или нет, готовы вы идти по такому пути развития или нужно искать что-то дальше.
Растет руководитель - растете вы
Я думаю не секрет, что в итоге оценку вашей работы проводит ваш руководитель. И подает вас (или сам принимает решения) о должностных и финансовых изменениях. Поэтому, под хорошим руководителем, хорошие сотрудники должны расти. Если вы выполняете все и даже больше (в рамках ваших договоренностей с руководителем), а с ростом вашего руководителя вы остаетесь на месте, это значит, что вам, скорее всего, не по пути. И вы не так ценны для своего руководителя, как хотели бы.
Совместимые подходы к работе
Бывает так, что вы видите подходы к управлению, развитию и построению рабочих процессов совсем по разному. Настолько, что начинаются постоянные споры. Даже если ваш руководитель вам полностью доверяет, но не доверяет вашим подходам (не видел такого, но наверное все бывает) это будет чувствоваться. При любой попытке изменений или неудаче к вам будет слишком много внимания, вопросов, сомнений и возражений. Работать так будет очень сложно и малоэффективно.
Личное отношение к руководителю
Это весьма личный пункт, но для меня важно, чтобы я мог уважать своего руководителя. Уважение в работе очень критично. Мы не должны на работе с кем-то дружить, кого-то любить, но атмосфера уважения позволяет создать эффективную рабочую среду. Также руководитель должен быть достаточно сильным и энергичным. Чем больше будет ваша компания и отдел, чем выше будут амбиции, тем это будет ценнее и важнее. Сила несколько общее понятие, включающее возможность брать необходимую ответственность и добиваться результата. А без энергии много работы не сделаешь.
Личное отношение руководителя
Тут для меня важно, чтобы тебя уважали, ценили в той мере, чтобы давали достаточно свободы для адекватного выполнение задачи.
Сейчас у меня критериев в разы меньше, чем раньше, но по ним у меня всегда получается понять насколько есть смысл работать с тем или иным руководителем. Конечно, есть много факторов при принятии решения о смене работы. Я уже писал о том, как определить, что текущее место вам не подходит (или подходит). Будет полезно провести такой анализ вместе с оценкой своего руководителя.
Максим Шаламов
#советы #разработчику
Сегодня я бы хотел поговорить не о вас, как руководителях (действующих или потенциальных), а о том, как можно оценить своего руководителя. Не все задумываются, но от руководителя зависит многое. И если то, насколько долго и успешно вы проработаете в компании зависит в первую очередь от вас, то на второе место можно смело ставить вашего руководителя. Приведу мой список параметров для оценки руководителя.
Умение держать слово
Одним из важнейших пунктов для меня идет умение держать слово. Потому что без этого, говорить о долгосрочных планах, развитии или чем-то долгосрочном вообще не получится. Если вы можете доверять договоренностям между вами и руководителем, у вас появится возможность не только планировать свою работу и рост, но и в целом понимать устраивает вас текущая ситуация или нет, готовы вы идти по такому пути развития или нужно искать что-то дальше.
Растет руководитель - растете вы
Я думаю не секрет, что в итоге оценку вашей работы проводит ваш руководитель. И подает вас (или сам принимает решения) о должностных и финансовых изменениях. Поэтому, под хорошим руководителем, хорошие сотрудники должны расти. Если вы выполняете все и даже больше (в рамках ваших договоренностей с руководителем), а с ростом вашего руководителя вы остаетесь на месте, это значит, что вам, скорее всего, не по пути. И вы не так ценны для своего руководителя, как хотели бы.
Совместимые подходы к работе
Бывает так, что вы видите подходы к управлению, развитию и построению рабочих процессов совсем по разному. Настолько, что начинаются постоянные споры. Даже если ваш руководитель вам полностью доверяет, но не доверяет вашим подходам (не видел такого, но наверное все бывает) это будет чувствоваться. При любой попытке изменений или неудаче к вам будет слишком много внимания, вопросов, сомнений и возражений. Работать так будет очень сложно и малоэффективно.
Личное отношение к руководителю
Это весьма личный пункт, но для меня важно, чтобы я мог уважать своего руководителя. Уважение в работе очень критично. Мы не должны на работе с кем-то дружить, кого-то любить, но атмосфера уважения позволяет создать эффективную рабочую среду. Также руководитель должен быть достаточно сильным и энергичным. Чем больше будет ваша компания и отдел, чем выше будут амбиции, тем это будет ценнее и важнее. Сила несколько общее понятие, включающее возможность брать необходимую ответственность и добиваться результата. А без энергии много работы не сделаешь.
Личное отношение руководителя
Тут для меня важно, чтобы тебя уважали, ценили в той мере, чтобы давали достаточно свободы для адекватного выполнение задачи.
Сейчас у меня критериев в разы меньше, чем раньше, но по ним у меня всегда получается понять насколько есть смысл работать с тем или иным руководителем. Конечно, есть много факторов при принятии решения о смене работы. Я уже писал о том, как определить, что текущее место вам не подходит (или подходит). Будет полезно провести такой анализ вместе с оценкой своего руководителя.
Максим Шаламов
#советы #разработчику
Нетворкинг для айтишников зачем и как?
Нетворкинг стал довольно популярной темой, особенно в бизнес-среде. Бизнесмены давно уяснили, что без связей построить бизнес очень сложно. Однако, какую роль нетворкинг играет для обычного исполнителя в ИТ-сфере? Для разработчика, тестировщика, менеджера продукта? Так ли важно заводить знакомства? Давайте разбираться.
Плюсы, которые дают связи
На самом деле полезные связи нужны каждому. Об этом знает даже моя бабушка, которая узнает у своей сети к какому терапевту лучше записаться. Вот основные преимущества, которые вам даст развитая сеть контактов:
1. Доступ к экспертам. У каждого случаются задачи, которые сложно преодолеть без помощи сообщества. Даже гуру гугления иногда не может найти решение. Если вы состоите в контакте с парой экспертов в нужной области, то это дает дополнительную возможность быстро разобраться с проблемой.
2. Возможности трудоустройства. Да, рынок ИТ переполнен вакансиями и, будучи хорошим спецом, найти работу не составит труда. Однако, найти именно то, что вам нужно может оказать уже задачей не из легких. Чем лучше вы подбираете под себя место (мы писали раньше о том, как это делать тут и тут), тем больше понимаете, что таких мест не так уж и много. А чем выше вы будете подниматься в должности, тем эта проблема будет вставать острее. На топовые позиции чаще нанимают знакомых, риск слишком велик. Но развитый нетворкинг поможет вам решить и эту проблему.
3. Потенциальные возможности. Имея хороших знакомых в разных областях, можно получать неожиданные предложения для роста и развития, о которых вы бы даже не узнали. Начиная новый проект, люди чаще обратятся с предложением к своим знакомым, которым они больше доверяют. Так можно не только поучаствовать в интересных мероприятиях и проектах, но и начать свой бизнес.
Как поддерживать связь?
Умелое использование контактов, может принести много пользы вашей карьере. Но как сохранять контакт, чтобы он был полезным? Ведь не стоит ждать от человека, с которым пару лет назад познакомились на конференции, предложения о работе, да и задать ему вопрос после такого перерыва будет не комфортно. Поэтому, чтобы связи работали, их нужно поддерживать. Вот несколько советов, которые в этом помогут:
- Составьте список всех ваших знакомств и постоянно его обновляйте.
- Периодически напоминайте о себе каждому из своего списка знакомств. Чем слабее связь, тем больше ее нужно укреплять.
- Помните, что связи тем крепче, чем больше вы ими пользуетесь. Человек привязывается не только к тому, кто ему помогает, но и к тому, кому помогает он. Не бойтесь использовать свои связи и просить о помощи.
- Будьте полезными. Найдите то, чем вы сможете быть полезными своей сети контактов. Может вы в чем-то особо хорошо разбираетесь и можете давать в этом советы. Станьте экспертом для своих контактов. Это не обязательно должна быть именно рабочая информация, иногда самым вспоминаемым знакомым становится тот, кто скидывает самые смешные мемы.
- Планируйте, фильтруйте и развивайте свою сеть. Огромное количество ненужных вам людей только будут тратить ваше время на общение и не принесут никакой пользы. Стоит думать над тем, с кем и почему вы хотите развивать знакомства. Какие контакты будут вам полезны для реализации ваших целей?
Конечно хранить всю информацию по сети контактов в голове будет максимально неэффективно, ресурсы мозга полезнее использовать для чего-то более важного. Поэтому лучше пользоваться инструментом, который дает возможность организовывать контакты и вести их. Мы с командой для этого разработали сервис Связи Решают, которым сами пользуемся. Пока там есть только самый необходимый функционал для обдуманного ведения контактов, поэтому у вас есть уникальная возможность поучаствовать в его развитии, оставляя отзывы и предложения в форме обратной связи или прямо мне в личку @shalamova_as . Вместе мы можем создать наиболее удобный инструмент и прокачать свою карьеру сильными связями.
Нетворкинг стал довольно популярной темой, особенно в бизнес-среде. Бизнесмены давно уяснили, что без связей построить бизнес очень сложно. Однако, какую роль нетворкинг играет для обычного исполнителя в ИТ-сфере? Для разработчика, тестировщика, менеджера продукта? Так ли важно заводить знакомства? Давайте разбираться.
Плюсы, которые дают связи
На самом деле полезные связи нужны каждому. Об этом знает даже моя бабушка, которая узнает у своей сети к какому терапевту лучше записаться. Вот основные преимущества, которые вам даст развитая сеть контактов:
1. Доступ к экспертам. У каждого случаются задачи, которые сложно преодолеть без помощи сообщества. Даже гуру гугления иногда не может найти решение. Если вы состоите в контакте с парой экспертов в нужной области, то это дает дополнительную возможность быстро разобраться с проблемой.
2. Возможности трудоустройства. Да, рынок ИТ переполнен вакансиями и, будучи хорошим спецом, найти работу не составит труда. Однако, найти именно то, что вам нужно может оказать уже задачей не из легких. Чем лучше вы подбираете под себя место (мы писали раньше о том, как это делать тут и тут), тем больше понимаете, что таких мест не так уж и много. А чем выше вы будете подниматься в должности, тем эта проблема будет вставать острее. На топовые позиции чаще нанимают знакомых, риск слишком велик. Но развитый нетворкинг поможет вам решить и эту проблему.
3. Потенциальные возможности. Имея хороших знакомых в разных областях, можно получать неожиданные предложения для роста и развития, о которых вы бы даже не узнали. Начиная новый проект, люди чаще обратятся с предложением к своим знакомым, которым они больше доверяют. Так можно не только поучаствовать в интересных мероприятиях и проектах, но и начать свой бизнес.
Как поддерживать связь?
Умелое использование контактов, может принести много пользы вашей карьере. Но как сохранять контакт, чтобы он был полезным? Ведь не стоит ждать от человека, с которым пару лет назад познакомились на конференции, предложения о работе, да и задать ему вопрос после такого перерыва будет не комфортно. Поэтому, чтобы связи работали, их нужно поддерживать. Вот несколько советов, которые в этом помогут:
- Составьте список всех ваших знакомств и постоянно его обновляйте.
- Периодически напоминайте о себе каждому из своего списка знакомств. Чем слабее связь, тем больше ее нужно укреплять.
- Помните, что связи тем крепче, чем больше вы ими пользуетесь. Человек привязывается не только к тому, кто ему помогает, но и к тому, кому помогает он. Не бойтесь использовать свои связи и просить о помощи.
- Будьте полезными. Найдите то, чем вы сможете быть полезными своей сети контактов. Может вы в чем-то особо хорошо разбираетесь и можете давать в этом советы. Станьте экспертом для своих контактов. Это не обязательно должна быть именно рабочая информация, иногда самым вспоминаемым знакомым становится тот, кто скидывает самые смешные мемы.
- Планируйте, фильтруйте и развивайте свою сеть. Огромное количество ненужных вам людей только будут тратить ваше время на общение и не принесут никакой пользы. Стоит думать над тем, с кем и почему вы хотите развивать знакомства. Какие контакты будут вам полезны для реализации ваших целей?
Конечно хранить всю информацию по сети контактов в голове будет максимально неэффективно, ресурсы мозга полезнее использовать для чего-то более важного. Поэтому лучше пользоваться инструментом, который дает возможность организовывать контакты и вести их. Мы с командой для этого разработали сервис Связи Решают, которым сами пользуемся. Пока там есть только самый необходимый функционал для обдуманного ведения контактов, поэтому у вас есть уникальная возможность поучаствовать в его развитии, оставляя отзывы и предложения в форме обратной связи или прямо мне в личку @shalamova_as . Вместе мы можем создать наиболее удобный инструмент и прокачать свою карьеру сильными связями.
Как подпитывать драйв в команде
Давайте поговорим об одной из важнейших составляющих успеха любой команды или продукта. Сложно назвать это каким-то одним слово, но пусть это будет драйв. Это непрерывное желание и движение к тому, чтобы сделать лучше, больше, превзойти конкурентов и т.д. В каком-то смысле это энергия, на которой идет развитие продукта и команды, то, что заряжает людей и позволяет двигаться вперед. Давайте обсудим то, как его можно поддерживать и какие методы не работают.
На ком должен держаться драйв команды
Я не сильно хотел бы углубляться в материи типа огня в глазах и всего такого. В больших проектах добиться равной большой вовлеченности всех участников команды очень сложно. Поэтому основные участники процесса должны обладать этим качеством и делиться с командой. Это выражается в постоянном поиске и устранении проблем, как в продукте, так и в процессах. Постоянно должны подниматься вопросы, а как сделать лучше, а не можем ли мы сделать быстрее, не должны ли мы доработать идею или выкинуть то, что плохо работает.
Как поддержание драйва не сработает
Обычно такую роль на себя берут владельцы продукта (PO), которые низводят ее до банального хаоса и постоянного давления на команду. Берут больше задач, чем можно сделать, бегают вокруг с вопросами, а когда будет готово, а уже сроки прошли, надо поднажать и т.д. Если не нормализовать этот процесс, то получим хаос, текучку и весьма слабо рабочий проект.
Забавно, но когда такого воздействия на команду нет совсем, результат получается примерно таким же. Наводя порядок в одном из проектов, я обратил внимание, что на команду никогда не давили сроки, никто особо не рвался вперед, все старались работать ровно. К сожалению, это не дало ожидаемого эффекта, команда со временем стала скучать и утратила мотивацию, а перенос сроков ушел за все разумные границы.
А как подпитать драйв в команде правильно?
В итоге, мы получили снова задачу о балансе, как и все в нашей жизни. Что же можно сделать, чтобы вернуть жизнь в ваш проект и по возможности не выжечь себя и других. Выстраивайте коммуникации так, что все идеи не отбрасываются, а обсуждаются в рамках отдельных встреч (или собираются в каком-то месте, с последующим разбором). Отобранные удачные идеи должны попадать в бэклог и реализовываться, это повысит вовлеченность каждого участника команды.
Всегда должны озвучиваться вопросы, а эффективно ли мы хотим что-то делать или делаем, нет ли способов ускориться или сделать лучше. Это не повод жить на работе, или увеличить сроки в 10 раз, это повод взвесить все за и против и выстроить работу вокруг принятых решений. Главное - это правильная коммуникация. Такие вопросы должны ставиться не с целью навязать что-то, а с целью поиска лучших решений. Соответственно и восприниматься такие вопросы должны спокойно, с целью найти лучшее решение.
Владелец продукта и тимлид должны взять на себя задачи по построению таких коммуникаций и адекватного общения вокруг них. Команду нужно вовлекать и удерживать от конфликтов и неконструктивных отвлечений. Любые идеи, лучше всего, для начала, собирать в каком-то пространстве, а потом собираться для их обсуждения. Постоянно собираться в моменте может быть неэффективно.
Больше таких фишек в работе с командой мы разбираем с участниками моего интенсива для тимлидов. Там и примеры, что делать, если у вас нет формальной должности, и как привести в порядок отдел, где ничего не работает, и многое другое. Приходите, и узнаете больше. Пока больше 7 человек взять не смогу, так что мест не очень много.
Максим Шаламов
#тимлиду #разработчику
Давайте поговорим об одной из важнейших составляющих успеха любой команды или продукта. Сложно назвать это каким-то одним слово, но пусть это будет драйв. Это непрерывное желание и движение к тому, чтобы сделать лучше, больше, превзойти конкурентов и т.д. В каком-то смысле это энергия, на которой идет развитие продукта и команды, то, что заряжает людей и позволяет двигаться вперед. Давайте обсудим то, как его можно поддерживать и какие методы не работают.
На ком должен держаться драйв команды
Я не сильно хотел бы углубляться в материи типа огня в глазах и всего такого. В больших проектах добиться равной большой вовлеченности всех участников команды очень сложно. Поэтому основные участники процесса должны обладать этим качеством и делиться с командой. Это выражается в постоянном поиске и устранении проблем, как в продукте, так и в процессах. Постоянно должны подниматься вопросы, а как сделать лучше, а не можем ли мы сделать быстрее, не должны ли мы доработать идею или выкинуть то, что плохо работает.
Как поддержание драйва не сработает
Обычно такую роль на себя берут владельцы продукта (PO), которые низводят ее до банального хаоса и постоянного давления на команду. Берут больше задач, чем можно сделать, бегают вокруг с вопросами, а когда будет готово, а уже сроки прошли, надо поднажать и т.д. Если не нормализовать этот процесс, то получим хаос, текучку и весьма слабо рабочий проект.
Забавно, но когда такого воздействия на команду нет совсем, результат получается примерно таким же. Наводя порядок в одном из проектов, я обратил внимание, что на команду никогда не давили сроки, никто особо не рвался вперед, все старались работать ровно. К сожалению, это не дало ожидаемого эффекта, команда со временем стала скучать и утратила мотивацию, а перенос сроков ушел за все разумные границы.
А как подпитать драйв в команде правильно?
В итоге, мы получили снова задачу о балансе, как и все в нашей жизни. Что же можно сделать, чтобы вернуть жизнь в ваш проект и по возможности не выжечь себя и других. Выстраивайте коммуникации так, что все идеи не отбрасываются, а обсуждаются в рамках отдельных встреч (или собираются в каком-то месте, с последующим разбором). Отобранные удачные идеи должны попадать в бэклог и реализовываться, это повысит вовлеченность каждого участника команды.
Всегда должны озвучиваться вопросы, а эффективно ли мы хотим что-то делать или делаем, нет ли способов ускориться или сделать лучше. Это не повод жить на работе, или увеличить сроки в 10 раз, это повод взвесить все за и против и выстроить работу вокруг принятых решений. Главное - это правильная коммуникация. Такие вопросы должны ставиться не с целью навязать что-то, а с целью поиска лучших решений. Соответственно и восприниматься такие вопросы должны спокойно, с целью найти лучшее решение.
Владелец продукта и тимлид должны взять на себя задачи по построению таких коммуникаций и адекватного общения вокруг них. Команду нужно вовлекать и удерживать от конфликтов и неконструктивных отвлечений. Любые идеи, лучше всего, для начала, собирать в каком-то пространстве, а потом собираться для их обсуждения. Постоянно собираться в моменте может быть неэффективно.
Больше таких фишек в работе с командой мы разбираем с участниками моего интенсива для тимлидов. Там и примеры, что делать, если у вас нет формальной должности, и как привести в порядок отдел, где ничего не работает, и многое другое. Приходите, и узнаете больше. Пока больше 7 человек взять не смогу, так что мест не очень много.
Максим Шаламов
#тимлиду #разработчику
Фокусировка - держим команду в фокусе
Важнейшей составляющей для любого успешного релиза является фокусировка. Это становится важнее с ростом размера релиза. Чем больший объем функционала вы хотите сделать (тем соответственно больше сроки реализации), тем важнее становится фактор фокусировки.
Мы всего лишь говорим об умении фокусироваться на главном и отбрасывать лишнее. Однако это бывает очень сложно, когда задач много и все они важные и нужные, а помогать выделить критичное никто не спешит.
Поставьте цели
Фокусировка начинается с малого, у каждого спринта или итерации, обязательно должна быть сформулирована цель. Все задачи работающие на выполнение цели, являются приоритетными и задача команды иметь приоритет на их решение. Все остальные задачи должны идти либо после выполнения цели, либо в случае, если у участников команды появляется время (сидеть и смотреть в монитор никому не нужно). Задача лидера команды все время держать фокус на важном. Переложить задачу на бизнес обычно не получается, потому что, в противном случае, задачи будут прибывать и прибывать. Все в команде должны понимать, что не закрытие цели спринта это отклонение от нормы и нужно разбираться в причинах (Как? Это тема отдельного разговора).
Расставьте приоритеты
Говоря про большие релизы, нужно сформировать не только цель, но и четко приоритезировать все задачи, связанные с целью. Приоритезация будет нужна, потому что в больших релизах от части запланированного функционала придется отказаться. Я рекомендую всегда уменьшать функционал, а не двигать сроки. Это позволяет минимально работать в стол и максимально быстро получить обратную связь от пользователей и понять идет ли все по плану или нет. Сдвиги сроков обычно сильно давят на команду и чем дальше, тем будет становиться хуже. Мое мнение на этот вопрос однозначное: ваша задача к дедлайну иметь работающий и отлаженный проект с набором критичного функционала. Очень важно, что работающего и отлаженного функционала, в который можно пускать пользователей. Тогда можно уже обсуждать в деталях, есть ли смысл в том, что получилось, и какой приоритет у доработок и следующих шагов. Если же вы приходите к дедлайну с набором недоделанных фичей, то ни о каком запуске речи быть не может, как и об успешной работе над взятым функционалом.
Что если бизнес не участвует в приоритезации
Если бизнес не может сам ставить приоритеты, то вам придется, слушая их, делать это самим. Тут очень простая логика, вам все равно нужно сделать каждую задачу в надлежащем качестве, поэтому если вы к дедлайну выберите и сделаете определенные, это как минимум ничего не испортит, как максимум - вы сможете запустить проект раньше. Если Бизнес приоритезирует задачи так, что они не влазят, то делаем тоже самое, выстраиваем максимально возможный по приоритету вариант.
В фокусировке важно, чтобы руководитель всегда доносил это до своих подчиненных, чтобы это не уходило у них из головы: есть цели и к ним нужно идти. Мы не должны умирать в пути к цели или делать плохой продукт. Мы должны искать варианты и обходные пути, где это возможно, а где это невозможно уменьшать число фичей или их сложность. Для руководителя очень важно не терять фокус самому и не переставать доносить важность этого до своей команды, тогда все получится. Найдутся и обходные пути, и результат придет.
Максим Шаламов
#тимлиду #agile_который_работает
Важнейшей составляющей для любого успешного релиза является фокусировка. Это становится важнее с ростом размера релиза. Чем больший объем функционала вы хотите сделать (тем соответственно больше сроки реализации), тем важнее становится фактор фокусировки.
Мы всего лишь говорим об умении фокусироваться на главном и отбрасывать лишнее. Однако это бывает очень сложно, когда задач много и все они важные и нужные, а помогать выделить критичное никто не спешит.
Поставьте цели
Фокусировка начинается с малого, у каждого спринта или итерации, обязательно должна быть сформулирована цель. Все задачи работающие на выполнение цели, являются приоритетными и задача команды иметь приоритет на их решение. Все остальные задачи должны идти либо после выполнения цели, либо в случае, если у участников команды появляется время (сидеть и смотреть в монитор никому не нужно). Задача лидера команды все время держать фокус на важном. Переложить задачу на бизнес обычно не получается, потому что, в противном случае, задачи будут прибывать и прибывать. Все в команде должны понимать, что не закрытие цели спринта это отклонение от нормы и нужно разбираться в причинах (Как? Это тема отдельного разговора).
Расставьте приоритеты
Говоря про большие релизы, нужно сформировать не только цель, но и четко приоритезировать все задачи, связанные с целью. Приоритезация будет нужна, потому что в больших релизах от части запланированного функционала придется отказаться. Я рекомендую всегда уменьшать функционал, а не двигать сроки. Это позволяет минимально работать в стол и максимально быстро получить обратную связь от пользователей и понять идет ли все по плану или нет. Сдвиги сроков обычно сильно давят на команду и чем дальше, тем будет становиться хуже. Мое мнение на этот вопрос однозначное: ваша задача к дедлайну иметь работающий и отлаженный проект с набором критичного функционала. Очень важно, что работающего и отлаженного функционала, в который можно пускать пользователей. Тогда можно уже обсуждать в деталях, есть ли смысл в том, что получилось, и какой приоритет у доработок и следующих шагов. Если же вы приходите к дедлайну с набором недоделанных фичей, то ни о каком запуске речи быть не может, как и об успешной работе над взятым функционалом.
Что если бизнес не участвует в приоритезации
Если бизнес не может сам ставить приоритеты, то вам придется, слушая их, делать это самим. Тут очень простая логика, вам все равно нужно сделать каждую задачу в надлежащем качестве, поэтому если вы к дедлайну выберите и сделаете определенные, это как минимум ничего не испортит, как максимум - вы сможете запустить проект раньше. Если Бизнес приоритезирует задачи так, что они не влазят, то делаем тоже самое, выстраиваем максимально возможный по приоритету вариант.
В фокусировке важно, чтобы руководитель всегда доносил это до своих подчиненных, чтобы это не уходило у них из головы: есть цели и к ним нужно идти. Мы не должны умирать в пути к цели или делать плохой продукт. Мы должны искать варианты и обходные пути, где это возможно, а где это невозможно уменьшать число фичей или их сложность. Для руководителя очень важно не терять фокус самому и не переставать доносить важность этого до своей команды, тогда все получится. Найдутся и обходные пути, и результат придет.
Максим Шаламов
#тимлиду #agile_который_работает
Кто должен быть лидером в команде разработки
Давайте сегодня обсудим вопрос кто и почему должен быть лидером в команде (речь о неформальном лидере, кто направляет команду в реальности, а не на бумаге). Варианта у нас всего два тимлид и владелец продукта (Product Owner, ПО). Очень часто в команде складывается ситуация, когда лидер именно владелец продукта. Уверен, что бывают удачные исключения, но я таких не видел и у своих коллег такого не наблюдал. Основная проблема по в том, что им слишком тяжело нащупать внутренний баланс. Они должны гореть идеей дать как можно больше и как можно быстрее, это не то что нормально, это необходимо для активного роста проекта. Но вместе с этим такой подход приведет к ужасному качеству продукта и выгоранию команды.
Почему ПО становится лидером?
Почему же владелец продукта так часто становятся лидерами команды. ПО роль сама по себе очень активная и направляющая. Хочешь не хочешь, а решать куда двигаться продукту или какие фичи брать, будет ПО (не важно как он к этому приходит). Так же ПО отвечает за бизнес показатели своего проекта или его части, поэтому ему реально нужно быстрее и больше, от этого зависит результат его работы, реализация его амбиций, да и банально сохранение своего места. Опять же ПО роль про коммуникации, поэтому обычно у них хорошо подвешен язык. А главное, с ПО не спросят за развалившийся технически проект, он отправит все вопросы к инженерам (по крайней мере попытается и скорее всего успешно).
Почему лидером не становится тимлид?
Что же касается нас с вами, то есть инженеров, обычно многие лиды (особенно начинающие), вполне довольны просто наличием лычки лида, и как-то особо не пытаются проявлять себя, что ПО обычно устраивает. Часто всплывают проблемы с коммуникациями, умение общаться и ясно излагать свои мысли нужно развивать, что хочется не многим. Многие становятся лидами, потому что они были самыми лучшими разработчиками в команде, но они, получив роль, продолжают быть лучшими разработчиками и не более. Ну и главное: многие не могут и не хотят брать на себя ответственность.
Как должно быть?
Однако, я считаю, что в эффективной команде (опять же в жизни бывает всякое) лидером должен быть именно тимлид. Потому что тимлид должен думать о команде, качестве продукта, поддерживаемости и так далее. Это как минимум часть его работы, причем существенная. Тимлид должен балансировать ПО и его неуемное желание бежать вперед.
А не получим ли с тимлидом туже проблему?
Почему же тимлид не сделает перекос в ненужную сторону? Это может случится, но есть несколько моментов. Первое, большинство людей все же приходят делать что-то значимое и стоящее, и сами заинтересованы в том, чтобы продукт выпускался и пользователи были довольны. Мало кто хочет работать в стол. Второе, тут всегда есть естественная балансировка. Мы в компаниях наняты для развития или поддержки проектов, соответственно если кто-то из инженеров встанет на пути развития компании/проекта без видимых причин, его просто уволят. Я общался с немалым количеством компаний, где искали замены своим техническим лидерам (даже тем с кем стартовали проекты и стартапы), потому что они совсем потеряли баланс и новый функционал просто не появлялся. И тут как раз оправдание, что зато работает скорее всего не сработает.
Максим Шаламов
#тимлиду #разработчику
Давайте сегодня обсудим вопрос кто и почему должен быть лидером в команде (речь о неформальном лидере, кто направляет команду в реальности, а не на бумаге). Варианта у нас всего два тимлид и владелец продукта (Product Owner, ПО). Очень часто в команде складывается ситуация, когда лидер именно владелец продукта. Уверен, что бывают удачные исключения, но я таких не видел и у своих коллег такого не наблюдал. Основная проблема по в том, что им слишком тяжело нащупать внутренний баланс. Они должны гореть идеей дать как можно больше и как можно быстрее, это не то что нормально, это необходимо для активного роста проекта. Но вместе с этим такой подход приведет к ужасному качеству продукта и выгоранию команды.
Почему ПО становится лидером?
Почему же владелец продукта так часто становятся лидерами команды. ПО роль сама по себе очень активная и направляющая. Хочешь не хочешь, а решать куда двигаться продукту или какие фичи брать, будет ПО (не важно как он к этому приходит). Так же ПО отвечает за бизнес показатели своего проекта или его части, поэтому ему реально нужно быстрее и больше, от этого зависит результат его работы, реализация его амбиций, да и банально сохранение своего места. Опять же ПО роль про коммуникации, поэтому обычно у них хорошо подвешен язык. А главное, с ПО не спросят за развалившийся технически проект, он отправит все вопросы к инженерам (по крайней мере попытается и скорее всего успешно).
Почему лидером не становится тимлид?
Что же касается нас с вами, то есть инженеров, обычно многие лиды (особенно начинающие), вполне довольны просто наличием лычки лида, и как-то особо не пытаются проявлять себя, что ПО обычно устраивает. Часто всплывают проблемы с коммуникациями, умение общаться и ясно излагать свои мысли нужно развивать, что хочется не многим. Многие становятся лидами, потому что они были самыми лучшими разработчиками в команде, но они, получив роль, продолжают быть лучшими разработчиками и не более. Ну и главное: многие не могут и не хотят брать на себя ответственность.
Как должно быть?
Однако, я считаю, что в эффективной команде (опять же в жизни бывает всякое) лидером должен быть именно тимлид. Потому что тимлид должен думать о команде, качестве продукта, поддерживаемости и так далее. Это как минимум часть его работы, причем существенная. Тимлид должен балансировать ПО и его неуемное желание бежать вперед.
А не получим ли с тимлидом туже проблему?
Почему же тимлид не сделает перекос в ненужную сторону? Это может случится, но есть несколько моментов. Первое, большинство людей все же приходят делать что-то значимое и стоящее, и сами заинтересованы в том, чтобы продукт выпускался и пользователи были довольны. Мало кто хочет работать в стол. Второе, тут всегда есть естественная балансировка. Мы в компаниях наняты для развития или поддержки проектов, соответственно если кто-то из инженеров встанет на пути развития компании/проекта без видимых причин, его просто уволят. Я общался с немалым количеством компаний, где искали замены своим техническим лидерам (даже тем с кем стартовали проекты и стартапы), потому что они совсем потеряли баланс и новый функционал просто не появлялся. И тут как раз оправдание, что зато работает скорее всего не сработает.
Максим Шаламов
#тимлиду #разработчику
Как правильно принимать решение
Довольно часто в нашей жизни нужно принимать решения. Сегодня мы конечно будем говорить о принятии решений в работе. Есть решения, которые вам нужно принять лично, есть решения, которые нужно принять совместно с другими. Решать нужно и руководителям, и людям, которые отвечают только за себя.
Возможности в принятии решений в зависимости от должности
Будучи исполнителем, в зависимости от компании, вы имеете рамки, в которых выполняете задачи, в них часто бывает достаточный простор для выбора способов решений и выбора инструментов.
Как часть команды, вы можете договариваться о способах решения командных проблем и взаимодействий, выбор инструментария и т.д.
Как руководитель, вы имеете много возможностей для принятия решений, главное находить баланс (об этом отдельно).
Ключевые моменты для правильного принятия решения
Что я считаю критично для принятия решений:
- каждое решение должно быть принято своевременно, то есть нужно ставить конечные сроки принятия решения. Даже если вы будете ставить их сами себе. Слишком поздно принятые решения могут сильно повлиять на сроки и качество проекта. Плюс, многие забывают про неприятный момент в виде того, что, если вы не приняли решение, за вас его примет руководство. Например, если я готов отдать принятие решения на откуп команды или исполнителя, по достижению оговоренного конечного срока принятия решения, если я готовое решение от команды не получаю, то решение выбираю я сам. Также делают многие руководители. Поэтому своевременность и оперативность в этом вопросе имеет большое значение.
- после принятия решения нужно собирать установки метрики/критерии успешности. Это нужно, чтобы понять насколько хорошо мы приняли решение, не обходится ли это нам слишком дорого и не создало ли это больше проблем, чем решило. Эти критерии нужно выбрать в момент выбора и ориентироваться на них в процессе решения.
- после принятия решения, пока не выбрано иное, нужно целенаправленно и четко следовать этому решению. Не нужно метаться и пытаться попробовать что-то еще. Идите к цели, не распыляйтесь.
- в случае, если решение перестает удовлетворять установленным критериям, то нужно взвесить снова все за и против и, либо изменяйте решение, либо скорректируйте метрики и ожидания.
Готовность принимать решения и отвечать за них - одно из важнейших умений руководителя и любого хорошего специалиста. Помимо ответственности, это позволит получить вам больше возможностей. Поэтому не бойтесь принимать решения, а то их примет кто-то другой.
Максим Шаламов
#разработчику #тимлиду
Довольно часто в нашей жизни нужно принимать решения. Сегодня мы конечно будем говорить о принятии решений в работе. Есть решения, которые вам нужно принять лично, есть решения, которые нужно принять совместно с другими. Решать нужно и руководителям, и людям, которые отвечают только за себя.
Возможности в принятии решений в зависимости от должности
Будучи исполнителем, в зависимости от компании, вы имеете рамки, в которых выполняете задачи, в них часто бывает достаточный простор для выбора способов решений и выбора инструментов.
Как часть команды, вы можете договариваться о способах решения командных проблем и взаимодействий, выбор инструментария и т.д.
Как руководитель, вы имеете много возможностей для принятия решений, главное находить баланс (об этом отдельно).
Ключевые моменты для правильного принятия решения
Что я считаю критично для принятия решений:
- каждое решение должно быть принято своевременно, то есть нужно ставить конечные сроки принятия решения. Даже если вы будете ставить их сами себе. Слишком поздно принятые решения могут сильно повлиять на сроки и качество проекта. Плюс, многие забывают про неприятный момент в виде того, что, если вы не приняли решение, за вас его примет руководство. Например, если я готов отдать принятие решения на откуп команды или исполнителя, по достижению оговоренного конечного срока принятия решения, если я готовое решение от команды не получаю, то решение выбираю я сам. Также делают многие руководители. Поэтому своевременность и оперативность в этом вопросе имеет большое значение.
- после принятия решения нужно собирать установки метрики/критерии успешности. Это нужно, чтобы понять насколько хорошо мы приняли решение, не обходится ли это нам слишком дорого и не создало ли это больше проблем, чем решило. Эти критерии нужно выбрать в момент выбора и ориентироваться на них в процессе решения.
- после принятия решения, пока не выбрано иное, нужно целенаправленно и четко следовать этому решению. Не нужно метаться и пытаться попробовать что-то еще. Идите к цели, не распыляйтесь.
- в случае, если решение перестает удовлетворять установленным критериям, то нужно взвесить снова все за и против и, либо изменяйте решение, либо скорректируйте метрики и ожидания.
Готовность принимать решения и отвечать за них - одно из важнейших умений руководителя и любого хорошего специалиста. Помимо ответственности, это позволит получить вам больше возможностей. Поэтому не бойтесь принимать решения, а то их примет кто-то другой.
Максим Шаламов
#разработчику #тимлиду
Алгоритм подготовки и проведения любой встречи
Сложно переоценить важность взаимодействия людей при работе над любым проектом. Не смотря на то, что это является одной из ключевых частей нашей работы, проводить встречи эффективно умеют не многие. Чтобы каждый раз не думать о том, как лучше провести встречу, я составила для вас небольшой алгоритм, который может стать основой для подготовки большинства встреч.
1. Определите тему и цели встречи. Как ни парадоксально это звучит, но иногда об этом пункте забывают. Прежде чем собирать кого бы то ни было, нужно определить зачем вы встречаетесь, какая цель у этой встречи, что в итоге вы должны получить в конце обсуждения.
2. Определите участников встречи. Хорошо подумайте над тем, кто вам действительно нужен для обсуждения. Не приглашайте лишних людей, они могут мешать эффективному общению, а вы потратите их время зря.
3. Определите ведущего встречи. У любой встречи должен быть человек, который направляет общение и следит, чтобы участники двигались к выполнению цели встречи. Это поможет провести встречу эффективно и поддерживать порядок.
4. Заранее спланируйте встречу в удобное для участников время. Лучше всего использовать для планирования встречи календарь с расписанием коллег, чтобы не получилось конфликтов между встречами. Стоит заранее узнать, не будет ли отсутствовать кто-то из обязательных участников встречи в этот день и не будет ли кто-то занят, чтобы такие детали не выяснились, когда все уже собрались и не сорвали встречу.
5. Заранее огласите тему и цели встречи участникам. Это можно также сделать через календарь, рассылая приглашения. Опишите для участников зачем вы их собираете и какую цель хотите решить этой встречей. Во-первых, встречей без названия и подробностей можно заранее вывести человека из себя и он придет в неподходящем настрое для продуктивного общения, а может и вообще не прийти. Во-вторых, так вы даете участникам возможность подготовиться, собрать нужную информацию и так далее.
6. Готовьтесь ко встречам. Это относится абсолютно ко всем участникам и к организатору, и к ведущему, и к приглашенным. Все должны заранее посмотреть, что за встреча предстоит, посмотреть на цели, собрать нужную информацию.
7. Составьте план встречи. Ведущий должен заранее составить план встречи, расписать основные части встречи и прикинуть ограничение времени. Без следования плану, встреча может пройти совершенно неэффективно и целей достичь не получится.
8. Используйте ограничение времени. Если встреча подразумевает обсуждения и споры, ведущему стоит использовать таймер или просто следить за временем, чтобы ограничивать основные этапы встречи. Иногда спор может длится бесконечно и нужно определить момент, когда нужно принять решение, вне зависимости от того, пришли спорящие к согласию или нет.
9. Назначьте ответственных. Если во время встречи было решено принять какие-то меры или провести какие-то работы, то на них обязательно должен быть выбран ответственный, который продолжит дальнейшую работу. Это не обязательно должен быть конечный исполнитель, но задача должна быть на кого-то назначена, иначе обсуждение может остаться только обсуждением без реальных результатов.
10. Составьте резюме встречи и разошлите его участникам. В конце встречи ведущий должен оставить немного времени, чтобы подвести итоги встречи, записать информацию о принятых решениях и алгоритме дальнейших действий. Лучше всего составить небольшое письмо и разослать его всем участникам, как итог прошедшей встречи. Так у вас, в случае возвращения к обсуждаемому вопросу, будут задокументированы принятые решения и встречу не придется собирать снова.
Александра Шаламова
#чеклист #agile_который_работает
Сложно переоценить важность взаимодействия людей при работе над любым проектом. Не смотря на то, что это является одной из ключевых частей нашей работы, проводить встречи эффективно умеют не многие. Чтобы каждый раз не думать о том, как лучше провести встречу, я составила для вас небольшой алгоритм, который может стать основой для подготовки большинства встреч.
1. Определите тему и цели встречи. Как ни парадоксально это звучит, но иногда об этом пункте забывают. Прежде чем собирать кого бы то ни было, нужно определить зачем вы встречаетесь, какая цель у этой встречи, что в итоге вы должны получить в конце обсуждения.
2. Определите участников встречи. Хорошо подумайте над тем, кто вам действительно нужен для обсуждения. Не приглашайте лишних людей, они могут мешать эффективному общению, а вы потратите их время зря.
3. Определите ведущего встречи. У любой встречи должен быть человек, который направляет общение и следит, чтобы участники двигались к выполнению цели встречи. Это поможет провести встречу эффективно и поддерживать порядок.
4. Заранее спланируйте встречу в удобное для участников время. Лучше всего использовать для планирования встречи календарь с расписанием коллег, чтобы не получилось конфликтов между встречами. Стоит заранее узнать, не будет ли отсутствовать кто-то из обязательных участников встречи в этот день и не будет ли кто-то занят, чтобы такие детали не выяснились, когда все уже собрались и не сорвали встречу.
5. Заранее огласите тему и цели встречи участникам. Это можно также сделать через календарь, рассылая приглашения. Опишите для участников зачем вы их собираете и какую цель хотите решить этой встречей. Во-первых, встречей без названия и подробностей можно заранее вывести человека из себя и он придет в неподходящем настрое для продуктивного общения, а может и вообще не прийти. Во-вторых, так вы даете участникам возможность подготовиться, собрать нужную информацию и так далее.
6. Готовьтесь ко встречам. Это относится абсолютно ко всем участникам и к организатору, и к ведущему, и к приглашенным. Все должны заранее посмотреть, что за встреча предстоит, посмотреть на цели, собрать нужную информацию.
7. Составьте план встречи. Ведущий должен заранее составить план встречи, расписать основные части встречи и прикинуть ограничение времени. Без следования плану, встреча может пройти совершенно неэффективно и целей достичь не получится.
8. Используйте ограничение времени. Если встреча подразумевает обсуждения и споры, ведущему стоит использовать таймер или просто следить за временем, чтобы ограничивать основные этапы встречи. Иногда спор может длится бесконечно и нужно определить момент, когда нужно принять решение, вне зависимости от того, пришли спорящие к согласию или нет.
9. Назначьте ответственных. Если во время встречи было решено принять какие-то меры или провести какие-то работы, то на них обязательно должен быть выбран ответственный, который продолжит дальнейшую работу. Это не обязательно должен быть конечный исполнитель, но задача должна быть на кого-то назначена, иначе обсуждение может остаться только обсуждением без реальных результатов.
10. Составьте резюме встречи и разошлите его участникам. В конце встречи ведущий должен оставить немного времени, чтобы подвести итоги встречи, записать информацию о принятых решениях и алгоритме дальнейших действий. Лучше всего составить небольшое письмо и разослать его всем участникам, как итог прошедшей встречи. Так у вас, в случае возвращения к обсуждаемому вопросу, будут задокументированы принятые решения и встречу не придется собирать снова.
Александра Шаламова
#чеклист #agile_который_работает
Как не погрязнуть в ручных правках
Я давно работаю в IT, поработал в разных компаниях и отделах, оброс знакомствами и контактами. Интересно, что я почти в каждом месте встречаю одну и туже проблему.
Давайте немного напряжем воображение. Вы делаете задачу по приему оплаты за услуги на вашем сайте. В какой-то момент оказывается, что части пользователей выдается немного меньше услуг после оплаты. Но не страшно, бизнес, который управляет приоритетами, приходит и говорит: "ребята, нет времени это чинить, давайте в базе проставим руками, как должно быть и не будем тратить время на правки. Сейчас не до этого, а пользователей таких немного". Знакомая история?
К чему это приводит
Похожие истории имеют обыкновение копиться и множиться. Это приводит к ситуациям, когда появляются сломанные пользовательские сценарии и пути, что приводит к постоянным просьбам в стиле “поменяйте руками в базе доступ”, “посмотрите кто сделал последнее изменение в этом объявлении”, “посмотрите, какая у этого пользователя почта” и таких задач становится все больше и большею. В итоге они начинают занимать значимую часть времени команды. Хотя, казалось бы, времени итак не было. Команда при этом оказывается в ловушке собственной мотивации, ведь все знают, что они хотят двигаться вперед и видеть, как их продуктом пользуются. Поэтому многие разработчики идут на встречу и попадают в ситуацию, когда продукт трещит по швам, а половину дня приходится разбираться с пользовательскими обращениями, чтобы руками поправить их проблему. При этом, такие задачи всегда срочные и требуют резкой смены контекста. Многие заводят в итоге дежурных, которых нужно все больше и больше, что мало меняет общую картину. Если пустить ситуацию на самотек, это в итоге сильно навредить проекту и подорвет мотивацию команды, замученную бесконечными рутинными задачами.
Что же делать?
Я предлагаю следующее решение этой проблемы. Помните, что услуги IT-специалистов дороги и занимать их чем-то отвлеченным крайне дорогая и сомнительная затея. Посчитайте процент пользователей, которых затрагивают проблемы и сколько времени займет ручная обработка всех их проблем. А потом посчитайте время на создание простого интерфейса, где бизнес руками сможет разрешить все сложности. Обычно этот аргумент становится решающим. Конечно нужно подкрепить уверенностью в правильности шага и терпением. Правильно было бы просчитать системное решение проблемы т.е. время на закрытие бага или недоработки функционала. На примере покажите, что разово закрыть проблему будет выгоднее и решите ее раз и навсегда, освободив время команды с рутинных ручных разборов этой проблемы.
После пары таких заходов, соберитесь с бизнесом и договоритесь, что вместо ручной работы вы всегда выбираете один из двух вариантов: интерфейс для ручной правки бизнесом или системное решение проблемы.
Максима Шаламов
#тимлиду #разработчику
Я давно работаю в IT, поработал в разных компаниях и отделах, оброс знакомствами и контактами. Интересно, что я почти в каждом месте встречаю одну и туже проблему.
Давайте немного напряжем воображение. Вы делаете задачу по приему оплаты за услуги на вашем сайте. В какой-то момент оказывается, что части пользователей выдается немного меньше услуг после оплаты. Но не страшно, бизнес, который управляет приоритетами, приходит и говорит: "ребята, нет времени это чинить, давайте в базе проставим руками, как должно быть и не будем тратить время на правки. Сейчас не до этого, а пользователей таких немного". Знакомая история?
К чему это приводит
Похожие истории имеют обыкновение копиться и множиться. Это приводит к ситуациям, когда появляются сломанные пользовательские сценарии и пути, что приводит к постоянным просьбам в стиле “поменяйте руками в базе доступ”, “посмотрите кто сделал последнее изменение в этом объявлении”, “посмотрите, какая у этого пользователя почта” и таких задач становится все больше и большею. В итоге они начинают занимать значимую часть времени команды. Хотя, казалось бы, времени итак не было. Команда при этом оказывается в ловушке собственной мотивации, ведь все знают, что они хотят двигаться вперед и видеть, как их продуктом пользуются. Поэтому многие разработчики идут на встречу и попадают в ситуацию, когда продукт трещит по швам, а половину дня приходится разбираться с пользовательскими обращениями, чтобы руками поправить их проблему. При этом, такие задачи всегда срочные и требуют резкой смены контекста. Многие заводят в итоге дежурных, которых нужно все больше и больше, что мало меняет общую картину. Если пустить ситуацию на самотек, это в итоге сильно навредить проекту и подорвет мотивацию команды, замученную бесконечными рутинными задачами.
Что же делать?
Я предлагаю следующее решение этой проблемы. Помните, что услуги IT-специалистов дороги и занимать их чем-то отвлеченным крайне дорогая и сомнительная затея. Посчитайте процент пользователей, которых затрагивают проблемы и сколько времени займет ручная обработка всех их проблем. А потом посчитайте время на создание простого интерфейса, где бизнес руками сможет разрешить все сложности. Обычно этот аргумент становится решающим. Конечно нужно подкрепить уверенностью в правильности шага и терпением. Правильно было бы просчитать системное решение проблемы т.е. время на закрытие бага или недоработки функционала. На примере покажите, что разово закрыть проблему будет выгоднее и решите ее раз и навсегда, освободив время команды с рутинных ручных разборов этой проблемы.
После пары таких заходов, соберитесь с бизнесом и договоритесь, что вместо ручной работы вы всегда выбираете один из двух вариантов: интерфейс для ручной правки бизнесом или системное решение проблемы.
Максима Шаламов
#тимлиду #разработчику
Нужны ли руководителю технические знания?
В своих статьях и курсах мы много говорим о софт-скиллах руководителей. Давайте сегодня посмотрим на вторую составляющую работы - хард скиллы, а вернее о балансе между ними. Несомненно любая руководящая позиция требует знаний и умений далеко выходящих за технические навыки и знания. Но можно ли обойтись совсем без технических знаний? Ответ на этот вопрос сильно зависит от позиции и обязанностей.
Основная концепция
Понятно, что знания у CIO/CTO, под которым 150 человек и руководителем команды, под которым 5 человек, если не должны, то могут сильно отличаться. Чем больше под руководителем людей, отделов, проектов, тем более высокоуровнево он должен уметь смотреть на проблемы. Нужно уметь выбирать технологии, которые в целом устроят компанию (даже в ущерб конкретному отделу), выбирать методологии работы, выстраивать отделы. На таких позициях обычно количество технологий, с которыми работают подчиненные так велико, что знать их все в деталях человеку просто не под силу, да этого и не требуется.
Однако, чем ближе руководитель к решению конкретных прикладных задач, тем выше должна быть его погруженность в эту специфику. Зачем это нужно? Тут есть несколько моментов.
Понимание специфики
Первое, руководитель будет говорить со своими людьми на одном языке, а это очень важно. Он постоянно работает с людьми, принимает решения и чем лучше его понимают, чем выше уверенность людей, что он понимает то, о чем говорит, что ему можно доверять, тем лучше люди будут слушать своего руководителя и охотнее поддерживать его решения. Конечно я не говорю, что вы, будучи руководителем, должны все и лучше всех знать и уметь, конечно нет. Но нужно понимать специфику того, с чем работаешь. Руководитель должен понимать что делают его люди и зачем, чтобы уметь понять их проблемы, чтобы помочь решать их проблемы.
Оценка качества
Второе, руководитель должен уметь контролировать ход работ и принимать работу своих подчиненных. Для верхнеуровневой приемки из разряда "тыкнул кнопку - лампочка загорелась" есть другие люди. Управленец должен уметь понимать развивается ли продукт правильно, должен уметь оценить качество сделанной работы и понять все ли работают как надо и должны, оправданы ли сроки. Даже если в команде есть техлид, вышестоящий руководитель не можете полностью отдать эти знания в его голову и контроль в его руки. Спросят о результатах в итоге все равно с более высокого руководства и оно должно уметь понять, что хорошо, а что плохо. Естественно привлекать людей для ревью и анализа результата тоже необходимо, сторонний взгляд всегда полезен. Главное нужно, по необходимости, смочь понять как идут дела и хорошо ли выполняется работа.
Оценка качества работы подчиненных
Третье, и временами самое неприятное, руководитель должен уметь контролировать не просто ход работ, а понять насколько хорошо или плохо работает конкретный человек. Поскольку от него будет зависеть повысить его зарплату или нет, увольнять человека или нет, то конечно он должны уметь оценивать человека. А поскольку он оценивает технического специалиста, то оценка его технических знаний необходима для комплексного принятия решений о подчиненном.
Заключение
В заключении, подведем итог. Технические руководители должны обладать техническими знаниями и навыками. От позиции к позиции набор знаний и умений варьируется, от максимального погружения в конкретную область, когда вы тимлид/техлид, до высокоуровневого понимания технологий и методологий управления, достаточного для принятия решений о выборе технологий, но не обязательно достаточного, чтобы самому смочь внедрить технологию в любой проект на более высоких позициях.
Максим Шаламов
#тимлиду #разработчику
В своих статьях и курсах мы много говорим о софт-скиллах руководителей. Давайте сегодня посмотрим на вторую составляющую работы - хард скиллы, а вернее о балансе между ними. Несомненно любая руководящая позиция требует знаний и умений далеко выходящих за технические навыки и знания. Но можно ли обойтись совсем без технических знаний? Ответ на этот вопрос сильно зависит от позиции и обязанностей.
Основная концепция
Понятно, что знания у CIO/CTO, под которым 150 человек и руководителем команды, под которым 5 человек, если не должны, то могут сильно отличаться. Чем больше под руководителем людей, отделов, проектов, тем более высокоуровнево он должен уметь смотреть на проблемы. Нужно уметь выбирать технологии, которые в целом устроят компанию (даже в ущерб конкретному отделу), выбирать методологии работы, выстраивать отделы. На таких позициях обычно количество технологий, с которыми работают подчиненные так велико, что знать их все в деталях человеку просто не под силу, да этого и не требуется.
Однако, чем ближе руководитель к решению конкретных прикладных задач, тем выше должна быть его погруженность в эту специфику. Зачем это нужно? Тут есть несколько моментов.
Понимание специфики
Первое, руководитель будет говорить со своими людьми на одном языке, а это очень важно. Он постоянно работает с людьми, принимает решения и чем лучше его понимают, чем выше уверенность людей, что он понимает то, о чем говорит, что ему можно доверять, тем лучше люди будут слушать своего руководителя и охотнее поддерживать его решения. Конечно я не говорю, что вы, будучи руководителем, должны все и лучше всех знать и уметь, конечно нет. Но нужно понимать специфику того, с чем работаешь. Руководитель должен понимать что делают его люди и зачем, чтобы уметь понять их проблемы, чтобы помочь решать их проблемы.
Оценка качества
Второе, руководитель должен уметь контролировать ход работ и принимать работу своих подчиненных. Для верхнеуровневой приемки из разряда "тыкнул кнопку - лампочка загорелась" есть другие люди. Управленец должен уметь понимать развивается ли продукт правильно, должен уметь оценить качество сделанной работы и понять все ли работают как надо и должны, оправданы ли сроки. Даже если в команде есть техлид, вышестоящий руководитель не можете полностью отдать эти знания в его голову и контроль в его руки. Спросят о результатах в итоге все равно с более высокого руководства и оно должно уметь понять, что хорошо, а что плохо. Естественно привлекать людей для ревью и анализа результата тоже необходимо, сторонний взгляд всегда полезен. Главное нужно, по необходимости, смочь понять как идут дела и хорошо ли выполняется работа.
Оценка качества работы подчиненных
Третье, и временами самое неприятное, руководитель должен уметь контролировать не просто ход работ, а понять насколько хорошо или плохо работает конкретный человек. Поскольку от него будет зависеть повысить его зарплату или нет, увольнять человека или нет, то конечно он должны уметь оценивать человека. А поскольку он оценивает технического специалиста, то оценка его технических знаний необходима для комплексного принятия решений о подчиненном.
Заключение
В заключении, подведем итог. Технические руководители должны обладать техническими знаниями и навыками. От позиции к позиции набор знаний и умений варьируется, от максимального погружения в конкретную область, когда вы тимлид/техлид, до высокоуровневого понимания технологий и методологий управления, достаточного для принятия решений о выборе технологий, но не обязательно достаточного, чтобы самому смочь внедрить технологию в любой проект на более высоких позициях.
Максим Шаламов
#тимлиду #разработчику
Сегодня мы подготовили для вас инфографику о принципах набора людей для маленькой компании. Более развернутую информацию можно найти в статье.
#тимлиду #разработчику
#тимлиду #разработчику
Как я следовал своим же советам и что из этого вышло
Часто получаю вопросы, мол советовать легко, а сам то следуешь своим же советам? На самом деле все, что я пишу, я прогоняю через себя, оно опробовано в работе и дало те результаты, которые я описываю. Это не значит, что это идеальные советы или лучшие решения в конкретной ситуации, но это те вещи, которые работают в тех условиях, что я описываю. Хорошо или плохо - каждый может решить для себя. На эту тему могу рассказать историю о следовании своим же советам.
Увольнение с работы
Прошлый год, я думаю, для многих был сложным, и я не был исключением. Помимо мировых событий сошлось много чего в моей жизни и очередной тупик на работе был в их числе. Вопрос не столько про то, что нет должностей выше (это как раз не так важно для меня), сколько мои ожидания не накладывались на реальность. Попробовав разные варианты и доведя работу до логической точки, собственно как и всегда всем советую, я покинул ТАСС. Что я никому не советовал, дак это уходить в никуда, как сделал я. Уйти в никуда был обдуманный, сложный, но очень нужный шаг. Нужно было время, чтобы переосмыслить свои проблемы и подходы.
Момент выбора
Осмысления закончились в сентябре 2022 (многие наверное помнят, что это было не лучшее время для поиска работы). Вариантов, с учетом ситуации, было не так много, но они были. Основной вопрос был в том, выбрать ли аналогичное место со схожими условиями, но теми же ограничениями, или попробовать сыграть на перспективу. Я выбрал перспективу (что тоже обычно советую другим, конечно при соблюдении минимально необходимых для вас условий), хоть это и значило то, что нужно сделать небольшой шаг назад и снова проявлять себя для возвращения на ожидаемые позиции.
Стоило ли оно того?
В итоге, по прошествии полугода, я прошел через самый сложный релиз из всех, что у меня был (хотя каждый раз думаешь, ну куда уж хуже=)) ), работаю с людьми, с которыми хотел работать, работаю с бизнесом, который хочет результат, а не иллюзию контроля. Если говорить про всякие числовые показатели, люди, команды и т.д, то тут тоже произошел шаг вперед. Это не история про то, как все идеально и лучше быть не может. Нет, проблемы есть и их много, но сейчас есть возможности для их решения, что самое главное для меня, понятны зоны и возможности роста.
Что могу сказать в виде итога для вас:
- биться головой о потолок, который по не зависящим от вас причинам вы не сможете пробить, особого смысла не имеет. Ищете варианты под себя, возможности выбрать сейчас хватает. Люди и подходы в компаниях немного, но отличаются, этого вполне может вам хватить, чтобы получить то, что вы ищете.
- иногда важно взять время на обдумывание ситуации, своих проблем и ограничений. Если есть возможность между работами брать паузу, советую ей пользоваться. Не всегда получается, переходя с работы на работу, осмыслить накопившийся опыт и изменить свои подходы.
- если вы во что-то постоянно упираетесь, то причина, в том числе, кроется и в вас. Не важно, как много вы успели сделать и узнать, учиться и расти нужно всю жизнь.
- не страшно сделать шаг назад, если вы видите перспективу и понимаете ради чего это делаете. Отходя от моего опыта, есть немало биографий, где людям по тем или иным причинам приходилось делать шаг назад и это помогало им прийти к большему.
В остальном, верьте себе, прорабатывайте свои проблемы, двигайтесь вперед и все у вас получится.
Максим Шаламов
#советы
Часто получаю вопросы, мол советовать легко, а сам то следуешь своим же советам? На самом деле все, что я пишу, я прогоняю через себя, оно опробовано в работе и дало те результаты, которые я описываю. Это не значит, что это идеальные советы или лучшие решения в конкретной ситуации, но это те вещи, которые работают в тех условиях, что я описываю. Хорошо или плохо - каждый может решить для себя. На эту тему могу рассказать историю о следовании своим же советам.
Увольнение с работы
Прошлый год, я думаю, для многих был сложным, и я не был исключением. Помимо мировых событий сошлось много чего в моей жизни и очередной тупик на работе был в их числе. Вопрос не столько про то, что нет должностей выше (это как раз не так важно для меня), сколько мои ожидания не накладывались на реальность. Попробовав разные варианты и доведя работу до логической точки, собственно как и всегда всем советую, я покинул ТАСС. Что я никому не советовал, дак это уходить в никуда, как сделал я. Уйти в никуда был обдуманный, сложный, но очень нужный шаг. Нужно было время, чтобы переосмыслить свои проблемы и подходы.
Момент выбора
Осмысления закончились в сентябре 2022 (многие наверное помнят, что это было не лучшее время для поиска работы). Вариантов, с учетом ситуации, было не так много, но они были. Основной вопрос был в том, выбрать ли аналогичное место со схожими условиями, но теми же ограничениями, или попробовать сыграть на перспективу. Я выбрал перспективу (что тоже обычно советую другим, конечно при соблюдении минимально необходимых для вас условий), хоть это и значило то, что нужно сделать небольшой шаг назад и снова проявлять себя для возвращения на ожидаемые позиции.
Стоило ли оно того?
В итоге, по прошествии полугода, я прошел через самый сложный релиз из всех, что у меня был (хотя каждый раз думаешь, ну куда уж хуже=)) ), работаю с людьми, с которыми хотел работать, работаю с бизнесом, который хочет результат, а не иллюзию контроля. Если говорить про всякие числовые показатели, люди, команды и т.д, то тут тоже произошел шаг вперед. Это не история про то, как все идеально и лучше быть не может. Нет, проблемы есть и их много, но сейчас есть возможности для их решения, что самое главное для меня, понятны зоны и возможности роста.
Что могу сказать в виде итога для вас:
- биться головой о потолок, который по не зависящим от вас причинам вы не сможете пробить, особого смысла не имеет. Ищете варианты под себя, возможности выбрать сейчас хватает. Люди и подходы в компаниях немного, но отличаются, этого вполне может вам хватить, чтобы получить то, что вы ищете.
- иногда важно взять время на обдумывание ситуации, своих проблем и ограничений. Если есть возможность между работами брать паузу, советую ей пользоваться. Не всегда получается, переходя с работы на работу, осмыслить накопившийся опыт и изменить свои подходы.
- если вы во что-то постоянно упираетесь, то причина, в том числе, кроется и в вас. Не важно, как много вы успели сделать и узнать, учиться и расти нужно всю жизнь.
- не страшно сделать шаг назад, если вы видите перспективу и понимаете ради чего это делаете. Отходя от моего опыта, есть немало биографий, где людям по тем или иным причинам приходилось делать шаг назад и это помогало им прийти к большему.
В остальном, верьте себе, прорабатывайте свои проблемы, двигайтесь вперед и все у вас получится.
Максим Шаламов
#советы
Советы увольняющимся
Многие используют выходные дни, как возможность подготовиться к поиску новой работы. Но важно не только понравится на новом месте, но и правильно уйти с предыдущего. Мы собрали для вас 6 важных пунктов, которые нужно сделать перед увольнением, чтобы оставить о себе хорошее впечатление.
#советы #разработчику
Многие используют выходные дни, как возможность подготовиться к поиску новой работы. Но важно не только понравится на новом месте, но и правильно уйти с предыдущего. Мы собрали для вас 6 важных пунктов, которые нужно сделать перед увольнением, чтобы оставить о себе хорошее впечатление.
#советы #разработчику