Скоро будет пост о самых губительных ошибках в проведении ретроспективы спринта. А на нашем YouTube-канале вы уже можете посмотреть видео на эту тему.
https://youtu.be/VhfFLiGKiTU
https://youtu.be/VhfFLiGKiTU
Командные встречи - это трата времени?
Многие люди считают любые встречи синонимом потраченного времени и стараются их всячески избегать. Как человек немало поработавший в компаниях, где встречи это инструмент поиска виноватых, поиска возможности спихнуть с себя работу или просто попытка показать свою важность и занятость, я в целом понимаю такое отношение и опасения.
Нужны ли команде встречи
Однако, для командных встреч и взаимодействий такое отношение не имеет право на существование. Начнем с того, что команда это группа людей, работающая вместе для достижения единых целей. Чтобы достигать цели, вы должны уметь эффективно работать вместе, четко согласовывать свои действия, знать кто и чем занимается, а также иметь возможность вовремя помочь товарищу по команде или попросить помощь. Все это невозможно без выстроенных и четких коммуникаций.
Кейс, когда командные встречи действительно не нужны
Если случилось так, что вы команда людей, делающих свои задачи в полной изоляции, не думающих и не знающих о других, то вы не команда, вы просто набор специалистов, делающих свои задачи. Это не хорошо и не плохо, при умении управлять таким подходом. Просто тогда у вас нет команды и нет потребности в командных взаимодействиях.
Почему курилка не может заменить встречи
Подходы типа да мы все обсудим за обедом, в курилке и т.д., мало конструктивны. Не все и не всегда соберутся в одном месте, не всегда разговор будет вестись о работе (у нас чаще всего как раз разговоры не о работе в таких местах), не все услышат и не все запомнят. В итоге будет разброд и шатание.
Почему менеджер не может заменить встречи
Конечно можно дойти до того, что в задаче вы, как менеджер, опишите каждую запятую, которую будет нужно сделать вашим сотрудникам, но лично я всегда избегал построения таких пассивных и низкоквалифицированных команд. Плюс конечно вы будете узким местом в такой схеме и при росте числа задач или горящих сроках все развалится. О том, что и зачем кто должен следить я уже много писал, не буду повторяться.
Что я советую делать
По факту, если вы команда, то вы должны уметь и хотеть эффективно взаимодействовать и коммуницировать внутри. Проблемы с коммуникацией это не повод от них отказываться, а повод их налаживать. Если вас что-то смущает или не устраивает, обсуждайте это с командой и приходите к компромиссам, только так вы станете сильны как команда.
Максим Шаламов
#советы
Многие люди считают любые встречи синонимом потраченного времени и стараются их всячески избегать. Как человек немало поработавший в компаниях, где встречи это инструмент поиска виноватых, поиска возможности спихнуть с себя работу или просто попытка показать свою важность и занятость, я в целом понимаю такое отношение и опасения.
Нужны ли команде встречи
Однако, для командных встреч и взаимодействий такое отношение не имеет право на существование. Начнем с того, что команда это группа людей, работающая вместе для достижения единых целей. Чтобы достигать цели, вы должны уметь эффективно работать вместе, четко согласовывать свои действия, знать кто и чем занимается, а также иметь возможность вовремя помочь товарищу по команде или попросить помощь. Все это невозможно без выстроенных и четких коммуникаций.
Кейс, когда командные встречи действительно не нужны
Если случилось так, что вы команда людей, делающих свои задачи в полной изоляции, не думающих и не знающих о других, то вы не команда, вы просто набор специалистов, делающих свои задачи. Это не хорошо и не плохо, при умении управлять таким подходом. Просто тогда у вас нет команды и нет потребности в командных взаимодействиях.
Почему курилка не может заменить встречи
Подходы типа да мы все обсудим за обедом, в курилке и т.д., мало конструктивны. Не все и не всегда соберутся в одном месте, не всегда разговор будет вестись о работе (у нас чаще всего как раз разговоры не о работе в таких местах), не все услышат и не все запомнят. В итоге будет разброд и шатание.
Почему менеджер не может заменить встречи
Конечно можно дойти до того, что в задаче вы, как менеджер, опишите каждую запятую, которую будет нужно сделать вашим сотрудникам, но лично я всегда избегал построения таких пассивных и низкоквалифицированных команд. Плюс конечно вы будете узким местом в такой схеме и при росте числа задач или горящих сроках все развалится. О том, что и зачем кто должен следить я уже много писал, не буду повторяться.
Что я советую делать
По факту, если вы команда, то вы должны уметь и хотеть эффективно взаимодействовать и коммуницировать внутри. Проблемы с коммуникацией это не повод от них отказываться, а повод их налаживать. Если вас что-то смущает или не устраивает, обсуждайте это с командой и приходите к компромиссам, только так вы станете сильны как команда.
Максим Шаламов
#советы
5 ошибок, делающих ваше ретро бесполезным
Ретроспектива - это одна из самых важных церемоний Agile, она помогает команде улучшать свои процессы и повышать эффективность от спринта к спринту. Но бывает так, что ретро есть, а улучшений нет. Давайте рассмотрим ошибки, которые могут быть этому причиной.
Ретро проводится нерегулярно
В погоне за сроками и бизнес целями команды часто жертвуют своими процессами, чтобы успеть свои основные задачи. И это само по себе уже очень большая ошибка. Именно процессы помогают не тратить время на лишнюю работу и успевать задачи в срок. Что касается ретро, то, во-первых, оно поможет выявить проблемы и исправить их в следующем спринте, что даст прирост производительности команды (мы ведь спешим правда?). Во-вторых, если не провести ретро сразу, то проблемы забудутся и их решение отложится до следующего инцидента (если после него снова не будет пропущено ретро). В-третьих, некоторые проблемы, не будучи отловленными у самых истоков, могут стрельнуть в будущем намного сильнее и иногда их уже очень сложно исправить.
На ретро не назначается ответственный за проблему
Итак, вы собрались на ретро, накидали проблем, сказали, что надо что-то с этим делать и пошли дальше работать. И проблемы пошли работать вместе с вами. Я наблюдала, как месяц за месяцем команды писали на ретро одни и те же проблемы, сокрушались над ними и через две недели процедура повторялась. Чтобы этого не происходило в вашей команде, для каждой проблемы должен быть назначен ответственный за ее решение, ему должны быть поставлены соответствующие задачи и выделено время на решение этой проблемы. Дальше задачи на решение проблем проходят обычный цикл, как и любые задачи на разработку. Лучше всего вести список для каждого ретро, где будет указано какая проблема обсуждалась и кто назначен ответственным. Так всегда можно будет просмотреть историю ретро и оценить их эффективность. Заведите правило: начинать ретро с проверки списка прошлой встречи.
На ретро приглашаются лишние люди
Многим людям тяжело говорить о проблемах. Поэтому, собирая состав ретро, важно помнить, что на встрече должны быть только люди из команды, которые могут свободно (насколько это возможно) общаться и обсуждать свои проблемы. На этих встречах не должно быть представителей бизнеса, какими бы друзьями вы с ними не были, и, в особенности, не должно быть незнакомых команде людей. Даже если вы с ребятами из соседнего отдела работали вместе в этом спринте, не надо звать их на ретро свой команды. Особенно хорошо нужно помнить об этом тимлидам, которые много общаются с представителями других команд и чувствуют себя с ними более свободно, думайте прежде всего о комфорте вашей команды, иначе рискуете получить ретро для галочки.
На ретро начинают искать решение проблемы
Еще один момент, о котором я как-то говорила в статье про правила проведения стендапа, на ретро не должно искаться полное решение проблемы, иначе встреча превратится в балаган. Во-первых, некоторые проблемы невозможно решить за 5 минут, начиная обсуждать решение проблемы, вы можете увязнуть надолго и за все ретро успеть обсудить только один вопрос (и то ни к чему не прийти). Во-вторых, помните, что в многофункциональных командах на ретро могут быть люди, которых не касается конкретная проблема, от обсуждения чужих проблем ваши коллеги только утомятся и потеряют интерес ко встрече. Проблема фиксируется, для нее выделяется ответственный и команда движется дальше.
У ретро нет ведущего
Здесь я скажу коротко - у совершенно любой встречи должен быть ведущий. И ретро здесь не исключение. Кто-то должен следить за правилами проведения ретро, фиксировать проблемы, следить за дисциплиной, помогать выбирать ответственного для проблемы. Конечно в идеале это скрам-мастер, но он есть не во всех командах. Тем не менее ведущий должен быть, иначе встреча будет не эффективной.
Надеюсь вам поможет разбор этих ошибок сделать вашу ретроспективу более эффективной. Если вам интересно больше узнать о церемониях Agile, то ставьте пальцы вверх этому посту и я напишу следующий.
Александра Шаламова
#agile_который_работает
Ретроспектива - это одна из самых важных церемоний Agile, она помогает команде улучшать свои процессы и повышать эффективность от спринта к спринту. Но бывает так, что ретро есть, а улучшений нет. Давайте рассмотрим ошибки, которые могут быть этому причиной.
Ретро проводится нерегулярно
В погоне за сроками и бизнес целями команды часто жертвуют своими процессами, чтобы успеть свои основные задачи. И это само по себе уже очень большая ошибка. Именно процессы помогают не тратить время на лишнюю работу и успевать задачи в срок. Что касается ретро, то, во-первых, оно поможет выявить проблемы и исправить их в следующем спринте, что даст прирост производительности команды (мы ведь спешим правда?). Во-вторых, если не провести ретро сразу, то проблемы забудутся и их решение отложится до следующего инцидента (если после него снова не будет пропущено ретро). В-третьих, некоторые проблемы, не будучи отловленными у самых истоков, могут стрельнуть в будущем намного сильнее и иногда их уже очень сложно исправить.
На ретро не назначается ответственный за проблему
Итак, вы собрались на ретро, накидали проблем, сказали, что надо что-то с этим делать и пошли дальше работать. И проблемы пошли работать вместе с вами. Я наблюдала, как месяц за месяцем команды писали на ретро одни и те же проблемы, сокрушались над ними и через две недели процедура повторялась. Чтобы этого не происходило в вашей команде, для каждой проблемы должен быть назначен ответственный за ее решение, ему должны быть поставлены соответствующие задачи и выделено время на решение этой проблемы. Дальше задачи на решение проблем проходят обычный цикл, как и любые задачи на разработку. Лучше всего вести список для каждого ретро, где будет указано какая проблема обсуждалась и кто назначен ответственным. Так всегда можно будет просмотреть историю ретро и оценить их эффективность. Заведите правило: начинать ретро с проверки списка прошлой встречи.
На ретро приглашаются лишние люди
Многим людям тяжело говорить о проблемах. Поэтому, собирая состав ретро, важно помнить, что на встрече должны быть только люди из команды, которые могут свободно (насколько это возможно) общаться и обсуждать свои проблемы. На этих встречах не должно быть представителей бизнеса, какими бы друзьями вы с ними не были, и, в особенности, не должно быть незнакомых команде людей. Даже если вы с ребятами из соседнего отдела работали вместе в этом спринте, не надо звать их на ретро свой команды. Особенно хорошо нужно помнить об этом тимлидам, которые много общаются с представителями других команд и чувствуют себя с ними более свободно, думайте прежде всего о комфорте вашей команды, иначе рискуете получить ретро для галочки.
На ретро начинают искать решение проблемы
Еще один момент, о котором я как-то говорила в статье про правила проведения стендапа, на ретро не должно искаться полное решение проблемы, иначе встреча превратится в балаган. Во-первых, некоторые проблемы невозможно решить за 5 минут, начиная обсуждать решение проблемы, вы можете увязнуть надолго и за все ретро успеть обсудить только один вопрос (и то ни к чему не прийти). Во-вторых, помните, что в многофункциональных командах на ретро могут быть люди, которых не касается конкретная проблема, от обсуждения чужих проблем ваши коллеги только утомятся и потеряют интерес ко встрече. Проблема фиксируется, для нее выделяется ответственный и команда движется дальше.
У ретро нет ведущего
Здесь я скажу коротко - у совершенно любой встречи должен быть ведущий. И ретро здесь не исключение. Кто-то должен следить за правилами проведения ретро, фиксировать проблемы, следить за дисциплиной, помогать выбирать ответственного для проблемы. Конечно в идеале это скрам-мастер, но он есть не во всех командах. Тем не менее ведущий должен быть, иначе встреча будет не эффективной.
Надеюсь вам поможет разбор этих ошибок сделать вашу ретроспективу более эффективной. Если вам интересно больше узнать о церемониях Agile, то ставьте пальцы вверх этому посту и я напишу следующий.
Александра Шаламова
#agile_который_работает
Правильный выбор инструментов для проекта и как делать нельзя.
Сегодня я бы хотел поговорить о выборе инструментов для решения задач и вытекающих из этого проблем.
Как скука разработчиков убивает проекты
Я поработал уже над множеством проектов и главное над множеством проектов, в старте которых я не участвовал. Оставив за рамками многие первопричины их проблем, посмотрим на те, что в руках у инженеров, а именно - инструментарий. Я уже перестал удивляться видеть самописные фреймворки, большие распределенные системы на простых приложениях, новомодные базы или библиотеки. В итоге, все это либо не решает задачу, либо решает ее плохо. В основном виной этому бывает банальная скука и желание развеяться через изучение нового инструмента, который конечно же повысит и рыночную стоимость специалиста. Ведь не секрет, что работа состоит на 80% из рутины и желание встряхнуться совершенно понятно. Не понятна всегда неготовность к последствиям такого выбора.
Оцениваем свои силы правильно
Второй же причиной таких смелых экспериментов может быть излишняя уверенность в себе. Конечно, разве вы не напишите свой фреймворк? Да что может быть проще. Ну разве что простой анализ репозиториев открытых проектов покажет вам число контрибьюторов и сроки разработки, что возможно немного поможет более здраво оценить свои силы.
Выбираем инструменты правильно
Дак как же выбирать инструменты для решения задач?
- Вы и ваша команда должны в них разбираться, иначе любой инструмент принесет проблемы, а не решения. Например, многие любят сейчас тащить mongodb в проекты (и она правда хороша), но если вы будете использовать ее как реляционную базу, то получите малоприятный результат.
- Инструмент должен хорошо решать именно поставленную задачу, а не задачу развлечения себя и других. Написание своего фреймворка, конечно, будет очень познавательным процессом, пока он не начнет рассыпаться под наплывом правок и доработок, а также необходимостью в поддержке версионированиях и починки багов.
- Инструмент должен быть зрелым и развитым. То есть о его применениях можно найти упоминания, основные ошибки должны быть найдены и вычищены. В свое время, когда мы переходили на асинхронный подход с командой, вышел вреймворк Sanic (https://sanic.dev/en/). Он был нереально быстр, но разваливался на части сценариев. В итоге, мы выждали год, прежде чем начали его использовать.
- Хороший принцип при выборе: хорошо проверенный, надежный и поддерживаемый инструмент, лучше нового, стильного, молодёжного, но не обкатанного.
А как внедрить новое?
Может возникнуть ощущение, что так ты никогда ничего нового не добавишь в свой стек. Это не так. Просто все нужно делать правильно. Я вижу два варианта:
- обкатываем на каком-то внутреннем или вообще учебном проекте. После чего, через небольшие или не сильно критичные куски/проекты добавляем себе в копилку новый инструмент.
- имеем план Б на экстренный переход к проверенному инструменту и готовность всех участников эксперимента к такому исходу (потому что при любых раскладах тут возникают переработки).
В целом, в разработке софта, есть много общих от места к месту проблем, но часть из них мы создаем себе сами, причем совершенно неоправданно. Ведь выбор плохого инструмента это не только плохо решенная задача, но и чудовищная головная боль при поддержке и развитии проекта.
Максим Шаламов
#советы #разработчику
Сегодня я бы хотел поговорить о выборе инструментов для решения задач и вытекающих из этого проблем.
Как скука разработчиков убивает проекты
Я поработал уже над множеством проектов и главное над множеством проектов, в старте которых я не участвовал. Оставив за рамками многие первопричины их проблем, посмотрим на те, что в руках у инженеров, а именно - инструментарий. Я уже перестал удивляться видеть самописные фреймворки, большие распределенные системы на простых приложениях, новомодные базы или библиотеки. В итоге, все это либо не решает задачу, либо решает ее плохо. В основном виной этому бывает банальная скука и желание развеяться через изучение нового инструмента, который конечно же повысит и рыночную стоимость специалиста. Ведь не секрет, что работа состоит на 80% из рутины и желание встряхнуться совершенно понятно. Не понятна всегда неготовность к последствиям такого выбора.
Оцениваем свои силы правильно
Второй же причиной таких смелых экспериментов может быть излишняя уверенность в себе. Конечно, разве вы не напишите свой фреймворк? Да что может быть проще. Ну разве что простой анализ репозиториев открытых проектов покажет вам число контрибьюторов и сроки разработки, что возможно немного поможет более здраво оценить свои силы.
Выбираем инструменты правильно
Дак как же выбирать инструменты для решения задач?
- Вы и ваша команда должны в них разбираться, иначе любой инструмент принесет проблемы, а не решения. Например, многие любят сейчас тащить mongodb в проекты (и она правда хороша), но если вы будете использовать ее как реляционную базу, то получите малоприятный результат.
- Инструмент должен хорошо решать именно поставленную задачу, а не задачу развлечения себя и других. Написание своего фреймворка, конечно, будет очень познавательным процессом, пока он не начнет рассыпаться под наплывом правок и доработок, а также необходимостью в поддержке версионированиях и починки багов.
- Инструмент должен быть зрелым и развитым. То есть о его применениях можно найти упоминания, основные ошибки должны быть найдены и вычищены. В свое время, когда мы переходили на асинхронный подход с командой, вышел вреймворк Sanic (https://sanic.dev/en/). Он был нереально быстр, но разваливался на части сценариев. В итоге, мы выждали год, прежде чем начали его использовать.
- Хороший принцип при выборе: хорошо проверенный, надежный и поддерживаемый инструмент, лучше нового, стильного, молодёжного, но не обкатанного.
А как внедрить новое?
Может возникнуть ощущение, что так ты никогда ничего нового не добавишь в свой стек. Это не так. Просто все нужно делать правильно. Я вижу два варианта:
- обкатываем на каком-то внутреннем или вообще учебном проекте. После чего, через небольшие или не сильно критичные куски/проекты добавляем себе в копилку новый инструмент.
- имеем план Б на экстренный переход к проверенному инструменту и готовность всех участников эксперимента к такому исходу (потому что при любых раскладах тут возникают переработки).
В целом, в разработке софта, есть много общих от места к месту проблем, но часть из них мы создаем себе сами, причем совершенно неоправданно. Ведь выбор плохого инструмента это не только плохо решенная задача, но и чудовищная головная боль при поддержке и развитии проекта.
Максим Шаламов
#советы #разработчику
Работа с целями
Все знают о том, что нужно ставить цели, многие даже пытаются это делать, но почти никто не понимает, как делать это правильно. В рабочих процессах есть большое разнообразие целей: бизнес-цели, долгосрочные цели, краткосрочные цели, цели на квартал, на спринт и так далее и тому подобное. Каждая тема достаточна отдельной статьи. Но для начала давайте поговорим в общем о работе с целям, что они из себя представляют и зачем вообще нужны.
Что такое цель?
Цель - заранее установленный ориентир, которого вы намерены достичь за определенный промежуток времени, представление о результате, к которому вы должны прийти в результате своей работы.
Зачем нужны цели?
Во-первых, без заранее поставленной цели, вы не сможете понять, когда вы пришли к нужному результату и на сколько успешно вы это сделали. Чтобы оценить результаты любой работы, необходимо заранее знать, каким должен был быть идеальный результат. Во-вторых, наличие цели помогает правильно распределять ресурсы. Особенно это критично в нестандартных ситуация. Представьте, что в команде неожиданно заболел разработчик и ресурсов на закрытие спринта стало не хватать. Именно цель поможет вам понять, какими задачами можно пожертвовать, чтобы закрыть спринт удачно. В-третьих, цель помогает не сходить с курса. Все нововведения должны проходить проверку на соответствие цели, так легко определяется их необходимость и критичность. Такой подход очень помогает экономить ресурсы и делать правильный продукт.
Хорошие и плохие цели
Цель должна быть четко выражена и снабжена соответствующими метриками для определения ее выполнения. Частая проблема это именно постановка размытых целей без метрик. Выполнение таких целей невозможно четко определить и оценить успешность этого выполнения. Давайте разберем пример. Представим, что владелец продукта ставить команде на квартал цель “улучшить отзывчивость сайта”. По такой постановке совершенно не понятно что на практике нужно делать и как определить, что цель достигнута. Можно убрать тяжелую картинку с главной и сайт начнет на 10 мс открываться быстрее, это выполнит цель? А что будет считаться выполнением? Это пример плохой постановки цели.
Теперь давайте посмотрим как ее можно сделать хорошей. Для начала нужна более четкая постановка. Например: “сайт должен не менее, чем на 95% проходить проверку PageSpeed Insights для десктопной и мобильной версии.” Уже лучше, понятно к чему мы должно придти. Далее мы уже можем расписать конкретные метрики, такие как: загрузка сайта в среднем должна укладываться в 200 мс, размер загружаемых файлов не должен превышать 100кб и так далее. Так мы получаем уже конкретные метрики, по которым мы четко можем понять, как хорошо мы справились с задачей. Метрики наиболее полезны при неполном достижении цели. На пример, мы не смогли достичь 95% на мобилке, но мы можем оценить насколько мы продвинулись по метрикам: мы смогли достичь 200 мс на загрузке, но размеры файлов достигли лишь на 80%. Так сразу видно где мы находимся на пути достижения цели и на сколько мы к ней близки.
SMART цели
Бывает сложно сформулировать цель и понять насколько она правильно поставлена. Здесь на помощь придет техника постановки целей SMART. Это набор критериев, которым должна соответствовать ваша цель. SMART содержит следующие критерии:
Specific - конкретная
Measurable - измеримая
Attainable - достижимая
Relevant - актуальная
Time-bound - ограниченная во времени
Выводы
Не забывайте ставить цели и делайте это правильно. Это поможет вам приходить к ожидаемым результатам и не свернуть с дороги где-нибудь по пути.
#советы
Все знают о том, что нужно ставить цели, многие даже пытаются это делать, но почти никто не понимает, как делать это правильно. В рабочих процессах есть большое разнообразие целей: бизнес-цели, долгосрочные цели, краткосрочные цели, цели на квартал, на спринт и так далее и тому подобное. Каждая тема достаточна отдельной статьи. Но для начала давайте поговорим в общем о работе с целям, что они из себя представляют и зачем вообще нужны.
Что такое цель?
Цель - заранее установленный ориентир, которого вы намерены достичь за определенный промежуток времени, представление о результате, к которому вы должны прийти в результате своей работы.
Зачем нужны цели?
Во-первых, без заранее поставленной цели, вы не сможете понять, когда вы пришли к нужному результату и на сколько успешно вы это сделали. Чтобы оценить результаты любой работы, необходимо заранее знать, каким должен был быть идеальный результат. Во-вторых, наличие цели помогает правильно распределять ресурсы. Особенно это критично в нестандартных ситуация. Представьте, что в команде неожиданно заболел разработчик и ресурсов на закрытие спринта стало не хватать. Именно цель поможет вам понять, какими задачами можно пожертвовать, чтобы закрыть спринт удачно. В-третьих, цель помогает не сходить с курса. Все нововведения должны проходить проверку на соответствие цели, так легко определяется их необходимость и критичность. Такой подход очень помогает экономить ресурсы и делать правильный продукт.
Хорошие и плохие цели
Цель должна быть четко выражена и снабжена соответствующими метриками для определения ее выполнения. Частая проблема это именно постановка размытых целей без метрик. Выполнение таких целей невозможно четко определить и оценить успешность этого выполнения. Давайте разберем пример. Представим, что владелец продукта ставить команде на квартал цель “улучшить отзывчивость сайта”. По такой постановке совершенно не понятно что на практике нужно делать и как определить, что цель достигнута. Можно убрать тяжелую картинку с главной и сайт начнет на 10 мс открываться быстрее, это выполнит цель? А что будет считаться выполнением? Это пример плохой постановки цели.
Теперь давайте посмотрим как ее можно сделать хорошей. Для начала нужна более четкая постановка. Например: “сайт должен не менее, чем на 95% проходить проверку PageSpeed Insights для десктопной и мобильной версии.” Уже лучше, понятно к чему мы должно придти. Далее мы уже можем расписать конкретные метрики, такие как: загрузка сайта в среднем должна укладываться в 200 мс, размер загружаемых файлов не должен превышать 100кб и так далее. Так мы получаем уже конкретные метрики, по которым мы четко можем понять, как хорошо мы справились с задачей. Метрики наиболее полезны при неполном достижении цели. На пример, мы не смогли достичь 95% на мобилке, но мы можем оценить насколько мы продвинулись по метрикам: мы смогли достичь 200 мс на загрузке, но размеры файлов достигли лишь на 80%. Так сразу видно где мы находимся на пути достижения цели и на сколько мы к ней близки.
SMART цели
Бывает сложно сформулировать цель и понять насколько она правильно поставлена. Здесь на помощь придет техника постановки целей SMART. Это набор критериев, которым должна соответствовать ваша цель. SMART содержит следующие критерии:
Specific - конкретная
Measurable - измеримая
Attainable - достижимая
Relevant - актуальная
Time-bound - ограниченная во времени
Выводы
Не забывайте ставить цели и делайте это правильно. Это поможет вам приходить к ожидаемым результатам и не свернуть с дороги где-нибудь по пути.
#советы
Какие плюсы даст типизация вашему проекту
Сегодня хотел бы остановиться на более технической теме, не касаясь вопросов управления и организации. А именно паре простых вещей, которые сделают ваш проект значительно лучше с точки зрения сопровождения.
В последнее время я в основном имею дело с языком 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 раз, это повод взвесить все за и против и выстроить работу вокруг принятых решений. Главное - это правильная коммуникация. Такие вопросы должны ставиться не с целью навязать что-то, а с целью поиска лучших решений. Соответственно и восприниматься такие вопросы должны спокойно, с целью найти лучшее решение.
Владелец продукта и тимлид должны взять на себя задачи по построению таких коммуникаций и адекватного общения вокруг них. Команду нужно вовлекать и удерживать от конфликтов и неконструктивных отвлечений. Любые идеи, лучше всего, для начала, собирать в каком-то пространстве, а потом собираться для их обсуждения. Постоянно собираться в моменте может быть неэффективно.
Максим Шаламов
#тимлиду #разработчику
Давайте поговорим об одной из важнейших составляющих успеха любой команды или продукта. Сложно назвать это каким-то одним слово, но пусть это будет драйв. Это непрерывное желание и движение к тому, чтобы сделать лучше, больше, превзойти конкурентов и т.д. В каком-то смысле это энергия, на которой идет развитие продукта и команды, то, что заряжает людей и позволяет двигаться вперед. Давайте обсудим то, как его можно поддерживать и какие методы не работают.
На ком должен держаться драйв команды
Я не сильно хотел бы углубляться в материи типа огня в глазах и всего такого. В больших проектах добиться равной большой вовлеченности всех участников команды очень сложно. Поэтому основные участники процесса должны обладать этим качеством и делиться с командой. Это выражается в постоянном поиске и устранении проблем, как в продукте, так и в процессах. Постоянно должны подниматься вопросы, а как сделать лучше, а не можем ли мы сделать быстрее, не должны ли мы доработать идею или выкинуть то, что плохо работает.
Как поддержание драйва не сработает
Обычно такую роль на себя берут владельцы продукта (PO), которые низводят ее до банального хаоса и постоянного давления на команду. Берут больше задач, чем можно сделать, бегают вокруг с вопросами, а когда будет готово, а уже сроки прошли, надо поднажать и т.д. Если не нормализовать этот процесс, то получим хаос, текучку и весьма слабо рабочий проект.
Забавно, но когда такого воздействия на команду нет совсем, результат получается примерно таким же. Наводя порядок в одном из проектов, я обратил внимание, что на команду никогда не давили сроки, никто особо не рвался вперед, все старались работать ровно. К сожалению, это не дало ожидаемого эффекта, команда со временем стала скучать и утратила мотивацию, а перенос сроков ушел за все разумные границы.
А как подпитать драйв в команде правильно?
В итоге, мы получили снова задачу о балансе, как и все в нашей жизни. Что же можно сделать, чтобы вернуть жизнь в ваш проект и по возможности не выжечь себя и других. Выстраивайте коммуникации так, что все идеи не отбрасываются, а обсуждаются в рамках отдельных встреч (или собираются в каком-то месте, с последующим разбором). Отобранные удачные идеи должны попадать в бэклог и реализовываться, это повысит вовлеченность каждого участника команды.
Всегда должны озвучиваться вопросы, а эффективно ли мы хотим что-то делать или делаем, нет ли способов ускориться или сделать лучше. Это не повод жить на работе, или увеличить сроки в 10 раз, это повод взвесить все за и против и выстроить работу вокруг принятых решений. Главное - это правильная коммуникация. Такие вопросы должны ставиться не с целью навязать что-то, а с целью поиска лучших решений. Соответственно и восприниматься такие вопросы должны спокойно, с целью найти лучшее решение.
Владелец продукта и тимлид должны взять на себя задачи по построению таких коммуникаций и адекватного общения вокруг них. Команду нужно вовлекать и удерживать от конфликтов и неконструктивных отвлечений. Любые идеи, лучше всего, для начала, собирать в каком-то пространстве, а потом собираться для их обсуждения. Постоянно собираться в моменте может быть неэффективно.
Максим Шаламов
#тимлиду #разработчику
Фокусировка - держим команду в фокусе
Важнейшей составляющей для любого успешного релиза является фокусировка. Это становится важнее с ростом размера релиза. Чем больший объем функционала вы хотите сделать (тем соответственно больше сроки реализации), тем важнее становится фактор фокусировки.
Мы всего лишь говорим об умении фокусироваться на главном и отбрасывать лишнее. Однако это бывает очень сложно, когда задач много и все они важные и нужные, а помогать выделить критичное никто не спешит.
Поставьте цели
Фокусировка начинается с малого, у каждого спринта или итерации, обязательно должна быть сформулирована цель. Все задачи работающие на выполнение цели, являются приоритетными и задача команды иметь приоритет на их решение. Все остальные задачи должны идти либо после выполнения цели, либо в случае, если у участников команды появляется время (сидеть и смотреть в монитор никому не нужно). Задача лидера команды все время держать фокус на важном. Переложить задачу на бизнес обычно не получается, потому что, в противном случае, задачи будут прибывать и прибывать. Все в команде должны понимать, что не закрытие цели спринта это отклонение от нормы и нужно разбираться в причинах (Как? Это тема отдельного разговора).
Расставьте приоритеты
Говоря про большие релизы, нужно сформировать не только цель, но и четко приоритезировать все задачи, связанные с целью. Приоритезация будет нужна, потому что в больших релизах от части запланированного функционала придется отказаться. Я рекомендую всегда уменьшать функционал, а не двигать сроки. Это позволяет минимально работать в стол и максимально быстро получить обратную связь от пользователей и понять идет ли все по плану или нет. Сдвиги сроков обычно сильно давят на команду и чем дальше, тем будет становиться хуже. Мое мнение на этот вопрос однозначное: ваша задача к дедлайну иметь работающий и отлаженный проект с набором критичного функционала. Очень важно, что работающего и отлаженного функционала, в который можно пускать пользователей. Тогда можно уже обсуждать в деталях, есть ли смысл в том, что получилось, и какой приоритет у доработок и следующих шагов. Если же вы приходите к дедлайну с набором недоделанных фичей, то ни о каком запуске речи быть не может, как и об успешной работе над взятым функционалом.
Что если бизнес не участвует в приоритезации
Если бизнес не может сам ставить приоритеты, то вам придется, слушая их, делать это самим. Тут очень простая логика, вам все равно нужно сделать каждую задачу в надлежащем качестве, поэтому если вы к дедлайну выберите и сделаете определенные, это как минимум ничего не испортит, как максимум - вы сможете запустить проект раньше. Если Бизнес приоритезирует задачи так, что они не влазят, то делаем тоже самое, выстраиваем максимально возможный по приоритету вариант.
В фокусировке важно, чтобы руководитель всегда доносил это до своих подчиненных, чтобы это не уходило у них из головы: есть цели и к ним нужно идти. Мы не должны умирать в пути к цели или делать плохой продукт. Мы должны искать варианты и обходные пути, где это возможно, а где это невозможно уменьшать число фичей или их сложность. Для руководителя очень важно не терять фокус самому и не переставать доносить важность этого до своей команды, тогда все получится. Найдутся и обходные пути, и результат придет.
Максим Шаламов
#тимлиду #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_который_работает