Должны ли все сотрудники мыслить, как руководитель?
История про то, что сотрудники не мыслят, как руководитель, гложет многих управленцев. Многие руководители настолько убивают инициативу или так напирают, что все просто повторяют их слова, и это тоже считается достижением. Я же считаю, что ваша команда должна обогащать и дополнять вас. Вы итак уже есть, от команды вам нужны дополнительные идеи, эмоции, подходы. Помимо этого вам нужно, чтобы люди могли решать задачи самостоятельно, а не ждать пока вы напишите или перепишите инструкцию.
Но чтобы это работало, нужно учесть несколько важных моментов.
Первое, вы должны уважать и ценить своих людей, считаться с их мнением, даже если вы с этим мнением в итоге не согласитесь. Слушайте своих сотрудников, старайтесь при прочих равных выбрать их способ решения, чтобы повысить их мотивацию.
Четкое описывайте рамки, за которые нельзя выходить, и четко формулируйте цели, к которым нужно прийти. Все остальное должно отдаваться на откуп сотрудников их опыта и креатива. Естественно вы постоянно будете корректировать рамки и цели, без этого никак. Зато будет и общее видение и достаточно свободы для развития и самореализации команды.
И самое главное, ваше слово должно быть решающим. Да у всех свое мнение и видение. Вы всех послушали, но принимаете решение в итоге именно вы. И ваша команда должна это принимать, как должное, и не пытаться работать в обход.
Плюсом к последнему идет то, что вы также, как и все в команде, работаете по договоренностям. Чью бы идею вы не выбрали, свою или чужую, пока вы не приняли и не донесли до всех изменения, вы тоже работаете по заданным правилам. Нет ничего разрушительнее при попытке наладить работу, чем демонстративно показывать, что вы выше своих же слов и договоренностей.
В работе с командой есть очень много нюансов и сложностей. Если вы столкнулись с проблемой в вашем ИТ-отделе, которую решить самостоятельно не получается, то вы можете обратиться к нам за личной консультацией через нашего бота или форму на сайте.
Максим Шаламов
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
История про то, что сотрудники не мыслят, как руководитель, гложет многих управленцев. Многие руководители настолько убивают инициативу или так напирают, что все просто повторяют их слова, и это тоже считается достижением. Я же считаю, что ваша команда должна обогащать и дополнять вас. Вы итак уже есть, от команды вам нужны дополнительные идеи, эмоции, подходы. Помимо этого вам нужно, чтобы люди могли решать задачи самостоятельно, а не ждать пока вы напишите или перепишите инструкцию.
Но чтобы это работало, нужно учесть несколько важных моментов.
Первое, вы должны уважать и ценить своих людей, считаться с их мнением, даже если вы с этим мнением в итоге не согласитесь. Слушайте своих сотрудников, старайтесь при прочих равных выбрать их способ решения, чтобы повысить их мотивацию.
Четкое описывайте рамки, за которые нельзя выходить, и четко формулируйте цели, к которым нужно прийти. Все остальное должно отдаваться на откуп сотрудников их опыта и креатива. Естественно вы постоянно будете корректировать рамки и цели, без этого никак. Зато будет и общее видение и достаточно свободы для развития и самореализации команды.
И самое главное, ваше слово должно быть решающим. Да у всех свое мнение и видение. Вы всех послушали, но принимаете решение в итоге именно вы. И ваша команда должна это принимать, как должное, и не пытаться работать в обход.
Плюсом к последнему идет то, что вы также, как и все в команде, работаете по договоренностям. Чью бы идею вы не выбрали, свою или чужую, пока вы не приняли и не донесли до всех изменения, вы тоже работаете по заданным правилам. Нет ничего разрушительнее при попытке наладить работу, чем демонстративно показывать, что вы выше своих же слов и договоренностей.
В работе с командой есть очень много нюансов и сложностей. Если вы столкнулись с проблемой в вашем ИТ-отделе, которую решить самостоятельно не получается, то вы можете обратиться к нам за личной консультацией через нашего бота или форму на сайте.
Максим Шаламов
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
Почему ты вечно все узнаешь последним?
Типичная история: отдаешь команде задачу, получаешь сроки готовности, запускаешь рекламную компанию со всеми датами, вливаешь туда уйму денег. А в день, когда функционал должен быть уже на проекте, узнаешь, что команда не смогла сделать задачу в полном объеме. Так что всего, что ты уже наобещал пользователям и партнерам у тебя на проекте не случилось. А самое главное, что именно тот, кто потом разбирается со всеми последствиями, узнает обо всем этом самым последним, когда сделать уже ничего нельзя. Почему так происходит?
Ответ очень простой. Если вы о чем-то узнаете последним, значит у вас в команде нет механизмов, которые позволили бы вам как можно раньше отследить приближающуюся катастрофу. У вас попросту не работают нужные процессы предупреждения рисков. Вы плывете по океану полному айсбергов без бинокля с завязанными глазами, надеясь, авось пронесет. В какой-то раз вы как-нибудь да выкрутитесь, но однажды, напоретесь на настоящую катастрофу, и узнаете об этом уже сидя на дне с разбитым проектом. А команда будет только разводить руками.
Почему команда сама не в состоянии предотвратить беду? Причин много, от того, что команда вообще знать не знает про ваши рекламные компании и внешние договоренности, поэтому не может определить, что это проблема, до того, что команда не знает, где и когда вас найти, чтобы о проблеме сообщить.
Первой реакцией многих руководителей будет желание в следующий раз следить получше и принимать полное участие в разработке, чтобы знать обо всем. Но есть же и свои дела, не так ли? К тому же это все равно не поможет. С микроменеджментом команда начинает работать еще хуже, чем до него.
На эту проблему есть только одно правильное решение, которое реально работает, - настроить хорошие процессы работы команды. Сюда будет входить и порядок взаимодействия с командой, и предупреждение рисков, и метрики, которые помогут отслеживать, как хорошо команда укладывается в сроки. Подробно, с самого начала про процессы мы рассказываем в нашей книге, но если времени на чтение у вас нет, а проблему надо решать прямо сейчас, то приходите на консультацию. Будем разбираться вместе.
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
Типичная история: отдаешь команде задачу, получаешь сроки готовности, запускаешь рекламную компанию со всеми датами, вливаешь туда уйму денег. А в день, когда функционал должен быть уже на проекте, узнаешь, что команда не смогла сделать задачу в полном объеме. Так что всего, что ты уже наобещал пользователям и партнерам у тебя на проекте не случилось. А самое главное, что именно тот, кто потом разбирается со всеми последствиями, узнает обо всем этом самым последним, когда сделать уже ничего нельзя. Почему так происходит?
Ответ очень простой. Если вы о чем-то узнаете последним, значит у вас в команде нет механизмов, которые позволили бы вам как можно раньше отследить приближающуюся катастрофу. У вас попросту не работают нужные процессы предупреждения рисков. Вы плывете по океану полному айсбергов без бинокля с завязанными глазами, надеясь, авось пронесет. В какой-то раз вы как-нибудь да выкрутитесь, но однажды, напоретесь на настоящую катастрофу, и узнаете об этом уже сидя на дне с разбитым проектом. А команда будет только разводить руками.
Почему команда сама не в состоянии предотвратить беду? Причин много, от того, что команда вообще знать не знает про ваши рекламные компании и внешние договоренности, поэтому не может определить, что это проблема, до того, что команда не знает, где и когда вас найти, чтобы о проблеме сообщить.
Первой реакцией многих руководителей будет желание в следующий раз следить получше и принимать полное участие в разработке, чтобы знать обо всем. Но есть же и свои дела, не так ли? К тому же это все равно не поможет. С микроменеджментом команда начинает работать еще хуже, чем до него.
На эту проблему есть только одно правильное решение, которое реально работает, - настроить хорошие процессы работы команды. Сюда будет входить и порядок взаимодействия с командой, и предупреждение рисков, и метрики, которые помогут отслеживать, как хорошо команда укладывается в сроки. Подробно, с самого начала про процессы мы рассказываем в нашей книге, но если времени на чтение у вас нет, а проблему надо решать прямо сейчас, то приходите на консультацию. Будем разбираться вместе.
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
Стоит ли давать свободу подчиненным
Очень частая тема сейчас про свободу действий, излишние правила и ограничения. Люди часто думают, что им не хватает свободы действий и, получив ее, они раскроются на полную.
Люди сами не знаю, что для них свобода
Во-первых, многие, требующие свободы, даже не понимают, что такое “более свободно” для них. Меня, как довольно требовательного руководителя, периодически просят давать больше свободы, но на вопрос, как это должно работать, конкретики почти никогда нет.
Свобода идет в комплекте с ответственностью
Главное, что я думаю о свободе действий и принятии решений - это то, что это большая ответственность, о чем многие даже не думают. Конечно здорово получить свободу действий: есть цель и ты дальше к ней идешь. Но ведь это должно включать в себя самостоятельное решение всех проблем, стоящих перед вами на пути. Иначе ни о какой самостоятельности речи быть не может.
А что на практике?
Многие, получив самостоятельность, все равно бегают по каждой сложной ситуации к руководителю или «радуют» тем, что задача не будет сделана в срок в последний момент. Поэтому эксперименты со свободой быстро заканчиваются.
Вообще, в реальности, многие не хотят никакой самостоятельности и будут бегать от этого, как только поймут цену вопроса. Поэтому надо всегда смотреть на людей, как они работают и справляются.
Мне очень повезло с текущим руководителем, который всегда старался давать мне максимум свободы в рамках моей зоны обязанностей, но взамен он ожидал и ожидает самостоятельного решения всех вопросов, которые я могу закрыть самостоятельно. Меня всегда это устраивало, я так максимально эффективно работаю. Я стараюсь искать таких же подчиненных, но таких единицы, и большая удача, что в моей команде они есть.
Как делаю я
По самостоятельности, я всегда понимаю, как надо идти к целям и результатам в рамках своих проектов и требую идти этим курсом и подчиненных. Когда я вижу, что человек справляется, то стараюсь перейти на работу через синки, постановку целей и обсуждение результатов (помогаю, когда человек сам не может, стараюсь учить). Я очень ценю людей, кто так умеет работать, но обычно они ничего не просят, а просто естественным образом получают необходимую свободу, справляясь со своей работой.
Больше о моих подходах в управлении командой, я рассказываю в своем учебнике для руководителей.
Максим Шаламов
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
Очень частая тема сейчас про свободу действий, излишние правила и ограничения. Люди часто думают, что им не хватает свободы действий и, получив ее, они раскроются на полную.
Люди сами не знаю, что для них свобода
Во-первых, многие, требующие свободы, даже не понимают, что такое “более свободно” для них. Меня, как довольно требовательного руководителя, периодически просят давать больше свободы, но на вопрос, как это должно работать, конкретики почти никогда нет.
Свобода идет в комплекте с ответственностью
Главное, что я думаю о свободе действий и принятии решений - это то, что это большая ответственность, о чем многие даже не думают. Конечно здорово получить свободу действий: есть цель и ты дальше к ней идешь. Но ведь это должно включать в себя самостоятельное решение всех проблем, стоящих перед вами на пути. Иначе ни о какой самостоятельности речи быть не может.
А что на практике?
Многие, получив самостоятельность, все равно бегают по каждой сложной ситуации к руководителю или «радуют» тем, что задача не будет сделана в срок в последний момент. Поэтому эксперименты со свободой быстро заканчиваются.
Вообще, в реальности, многие не хотят никакой самостоятельности и будут бегать от этого, как только поймут цену вопроса. Поэтому надо всегда смотреть на людей, как они работают и справляются.
Мне очень повезло с текущим руководителем, который всегда старался давать мне максимум свободы в рамках моей зоны обязанностей, но взамен он ожидал и ожидает самостоятельного решения всех вопросов, которые я могу закрыть самостоятельно. Меня всегда это устраивало, я так максимально эффективно работаю. Я стараюсь искать таких же подчиненных, но таких единицы, и большая удача, что в моей команде они есть.
Как делаю я
По самостоятельности, я всегда понимаю, как надо идти к целям и результатам в рамках своих проектов и требую идти этим курсом и подчиненных. Когда я вижу, что человек справляется, то стараюсь перейти на работу через синки, постановку целей и обсуждение результатов (помогаю, когда человек сам не может, стараюсь учить). Я очень ценю людей, кто так умеет работать, но обычно они ничего не просят, а просто естественным образом получают необходимую свободу, справляясь со своей работой.
Больше о моих подходах в управлении командой, я рассказываю в своем учебнике для руководителей.
Максим Шаламов
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
⬆️ Что если все еще остались сомнения, совместим ли кандидат с командой
Если остаются сомнения, я советую выписать список плюсов человека: это и сильные профессиональные навыки, и личностные качества, которые вам понравились, а рядом выпишите список недостатков. Посмотрите перекрывают ли достоинства недостатки, а главное, знаете ли вы, как работать с недостатками человеками. Например, если в вашем стартапе кипит бурная деятельность, нужно рваться вперед всеми силами, а кандидат хорош технически, но привык очень размеренно и неспешно работать, вам нужно понять, сможете ли вы встроить человека в процессы, понимаете ли вы, как и обеспечить ему комфортное место работы и получить желаемый результат.
Больше о том, как работать с людьми и командой, смотрите в моем учебнике для руководителей технических команд.
Максим Шаламов
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
Если остаются сомнения, я советую выписать список плюсов человека: это и сильные профессиональные навыки, и личностные качества, которые вам понравились, а рядом выпишите список недостатков. Посмотрите перекрывают ли достоинства недостатки, а главное, знаете ли вы, как работать с недостатками человеками. Например, если в вашем стартапе кипит бурная деятельность, нужно рваться вперед всеми силами, а кандидат хорош технически, но привык очень размеренно и неспешно работать, вам нужно понять, сможете ли вы встроить человека в процессы, понимаете ли вы, как и обеспечить ему комфортное место работы и получить желаемый результат.
Больше о том, как работать с людьми и командой, смотрите в моем учебнике для руководителей технических команд.
Максим Шаламов
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
Самая недооцененная проблема проекта
Давайте поговорим о компоненте, который есть в ходе любого проекта и который постоянно игнорируется. Это наверное самый избегаемый и игнорируем компонент в проектной деятельности и, даже когда с ними работают, обычно делают это очень интуитивно и не системно. Поговорим сегодня о рисках.
Многие думают, да чего там о них думать, делаем да и все, а там, как получится. Всего не угадаешь. В итоге, мы получаем постоянные непредсказуемые для клиентов и руководства сдвиги сроков и несоответствующее качество, а все потому что не проработали риски и не подсветили их наличие для всех участников проекта.
Риски есть повсюду. Не могу придумать ни один проект без рисков. Даже если взять какой-нибудь разрабатываемый вами вечерами проект не связанный с работой, его основные риски это ситуации, в которых у вас не останется на него времени и/или мотивации.
Работаете вы скажем по спринтам и разрабатываете продукт в себе, без интеграций, смежников и прочего головняка. Ну какие тут могут быть риски? Да все, как у всех:
– Текучка кадров
– Болезнь ключевых исполнителей
– Ошибка в оценке сроков, например при создании функционала, который ваша команда до этого не делала
– Выбор неправильного инструмента. Допустим, выбрали вы какую-то библиотеку для ускорения разработки, а оказалось, что вот именно как вам надо она не умеет и либо меняй, либо дорабатывай, - все равно это удар по срокам.
– Или, скажем, проверка безопасности выявит критические проблемы в библиотеках или системах, которые вы используете. Менять или закрывать уязвимости придется и пострадают сроки.
И чем система больше и сложнее, тем больше рисков. Поэтому риски нужно видеть, от них не нужно прятаться. Риски всегда нужно учитывать и думать, как уменьшить их влияние при наступлении, как работать с проектам при наличии рисков реализация которых может наступить, а может нет. О рисках и их последствии должны знать все участники проекта и все заинтересованные лица, иначе это приведет к огромной череде конфликтов и скандалов и в целом приведет к потере вашей репутации.
Если у вас есть проблемы с оценкой своих рисков, приходите на консультацию, подберём, на что именно в вашей ситуации стоит обращать внимание.
Максим Шаламов
#риски #руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
Давайте поговорим о компоненте, который есть в ходе любого проекта и который постоянно игнорируется. Это наверное самый избегаемый и игнорируем компонент в проектной деятельности и, даже когда с ними работают, обычно делают это очень интуитивно и не системно. Поговорим сегодня о рисках.
Многие думают, да чего там о них думать, делаем да и все, а там, как получится. Всего не угадаешь. В итоге, мы получаем постоянные непредсказуемые для клиентов и руководства сдвиги сроков и несоответствующее качество, а все потому что не проработали риски и не подсветили их наличие для всех участников проекта.
Риски есть повсюду. Не могу придумать ни один проект без рисков. Даже если взять какой-нибудь разрабатываемый вами вечерами проект не связанный с работой, его основные риски это ситуации, в которых у вас не останется на него времени и/или мотивации.
Работаете вы скажем по спринтам и разрабатываете продукт в себе, без интеграций, смежников и прочего головняка. Ну какие тут могут быть риски? Да все, как у всех:
– Текучка кадров
– Болезнь ключевых исполнителей
– Ошибка в оценке сроков, например при создании функционала, который ваша команда до этого не делала
– Выбор неправильного инструмента. Допустим, выбрали вы какую-то библиотеку для ускорения разработки, а оказалось, что вот именно как вам надо она не умеет и либо меняй, либо дорабатывай, - все равно это удар по срокам.
– Или, скажем, проверка безопасности выявит критические проблемы в библиотеках или системах, которые вы используете. Менять или закрывать уязвимости придется и пострадают сроки.
И чем система больше и сложнее, тем больше рисков. Поэтому риски нужно видеть, от них не нужно прятаться. Риски всегда нужно учитывать и думать, как уменьшить их влияние при наступлении, как работать с проектам при наличии рисков реализация которых может наступить, а может нет. О рисках и их последствии должны знать все участники проекта и все заинтересованные лица, иначе это приведет к огромной череде конфликтов и скандалов и в целом приведет к потере вашей репутации.
Если у вас есть проблемы с оценкой своих рисков, приходите на консультацию, подберём, на что именно в вашей ситуации стоит обращать внимание.
Максим Шаламов
#риски #руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
Как скинуть балласт – избавляемся от нерадивого сотрудника
Итак, в вашу команду, не смотря на все ваши старания, попал нерадивый сотрудник. Вы уже все перепробовали и наконец решились на его увольнение. Что делать дальше?
Открою тайну для многих, но наше законодательство очень хорошо защищает права сотрудника, если конечно сотрудник подписывает нормальный трудовой договор, а не ставит подпись не глядя. И вот вы, как руководитель, пришли к тому, что хотите уволить подчиненного, что дальше? Прежде, чем говорить с человеком и кидаться громкими заявлениями, нужно понять, на что у вас реально есть право в вашем случае. Поэтому первым делом отправляйтесь на консультацию к вашим кадровикам или юристам, если таких в компании нет, то можно обратиться к сторонним специалистам. Они вам расскажут все нюансы по вашему трудовому договору и правилам компании с юридической точки зрения. Однако, есть общие подходы, которые помогут в любой ситуации и с которых можно начать работу с проблемным человеком.
Если человек явно отказывается работать или саботирует работу, то он скорее всего и уходить по-хорошему не захочет. А значит добиться от него увольнения по собственному желанию не получится. В любом случае, вам нужно провести разговор с сотрудником, где вы зафиксируете проблемы и послушаете его возражения. Дальше вы составляете план и обсуждаете конкретные шаги выхода из этих проблем. Все обязательно фиксируете. Фиксируйте хоть в электронной почте, если нет ничего другого, но обязательно фиксируйте.
Дальше вы идете по намеченному плану и смотрите, есть ли отклонения. То есть что-то, что сотрудник не выполняет из договоренностей, и если да, есть ли у них внятные оправдания или сотрудник просто пытается отделаться отговорками. Если вы поняли, что сотрудник опять ничего не сделал и оправданий у него нет, то все это снова фиксируете. Вам придется фиксировать факты несвоевременно выполненной работы или работы сданной в неподобающем качестве. А дальше проводить это через выговоры и т.д., точный формат вы уже обсудите с вашими юристами. Ваша же задача собрать и записать информацию, чтобы были реальные кейсы, доказывающие, что сотрудник не справляется с работой.
Главное, всегда быть спокойным и конструктивным. Отвечать на вопросы сотрудника, даже если он вам неприятен, и все, вообще все, фиксировать письменном виде.
Совсем отбитых сотрудников на самом деле немного, но они есть и тратят очень много времени и сил. Однако, при желании и правильном подходе уволить можно даже самого упертого.
Если задача работы со сложными людьми дается вам нелегко, вы не уверены в своей правоте, не знаете с чего начать и боитесь навредить своей работе, то обращайтесь к нам за личной консультацией. Мы поможем найти лучший подход именно для вашей ситуации и разработать четкий план дальнейших действий.
Максим Шаламов
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
Итак, в вашу команду, не смотря на все ваши старания, попал нерадивый сотрудник. Вы уже все перепробовали и наконец решились на его увольнение. Что делать дальше?
Открою тайну для многих, но наше законодательство очень хорошо защищает права сотрудника, если конечно сотрудник подписывает нормальный трудовой договор, а не ставит подпись не глядя. И вот вы, как руководитель, пришли к тому, что хотите уволить подчиненного, что дальше? Прежде, чем говорить с человеком и кидаться громкими заявлениями, нужно понять, на что у вас реально есть право в вашем случае. Поэтому первым делом отправляйтесь на консультацию к вашим кадровикам или юристам, если таких в компании нет, то можно обратиться к сторонним специалистам. Они вам расскажут все нюансы по вашему трудовому договору и правилам компании с юридической точки зрения. Однако, есть общие подходы, которые помогут в любой ситуации и с которых можно начать работу с проблемным человеком.
Если человек явно отказывается работать или саботирует работу, то он скорее всего и уходить по-хорошему не захочет. А значит добиться от него увольнения по собственному желанию не получится. В любом случае, вам нужно провести разговор с сотрудником, где вы зафиксируете проблемы и послушаете его возражения. Дальше вы составляете план и обсуждаете конкретные шаги выхода из этих проблем. Все обязательно фиксируете. Фиксируйте хоть в электронной почте, если нет ничего другого, но обязательно фиксируйте.
Дальше вы идете по намеченному плану и смотрите, есть ли отклонения. То есть что-то, что сотрудник не выполняет из договоренностей, и если да, есть ли у них внятные оправдания или сотрудник просто пытается отделаться отговорками. Если вы поняли, что сотрудник опять ничего не сделал и оправданий у него нет, то все это снова фиксируете. Вам придется фиксировать факты несвоевременно выполненной работы или работы сданной в неподобающем качестве. А дальше проводить это через выговоры и т.д., точный формат вы уже обсудите с вашими юристами. Ваша же задача собрать и записать информацию, чтобы были реальные кейсы, доказывающие, что сотрудник не справляется с работой.
Главное, всегда быть спокойным и конструктивным. Отвечать на вопросы сотрудника, даже если он вам неприятен, и все, вообще все, фиксировать письменном виде.
Совсем отбитых сотрудников на самом деле немного, но они есть и тратят очень много времени и сил. Однако, при желании и правильном подходе уволить можно даже самого упертого.
Если задача работы со сложными людьми дается вам нелегко, вы не уверены в своей правоте, не знаете с чего начать и боитесь навредить своей работе, то обращайтесь к нам за личной консультацией. Мы поможем найти лучший подход именно для вашей ситуации и разработать четкий план дальнейших действий.
Максим Шаламов
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
Как формируется лидерство: моя история
Многие молодые и не только руководители, часто страдают от ощущения, что не могут осуществлять свои управленческие решения. То их руководство не принимает, то команда. Всем постоянно повторяю, что любая должность лишь дает возможность, сами по себе решения от должности не внедрятся. Многое будет строится на вашем авторитете, умение убеждать и настойчивости.
Как я управлял запуском без должности руководителя
Первый свой крупный проект я запускал в Рамблере будучи разработчиком. Тогда мы были в группе RDS с идей быстро запускать и развивать новые направления. Первую версию проекта Путешествий мы сделали меньше чем за месяц, а вот сопровождение всего было все еще частью старой структуры и они еще даже не начали готовить наши сервера. И, в общем, тут бы и сказке конец, ждем и надеемся. Но я обошел все руководство, до которого дотянулся, включая свое направление бизнеса, и мне выдали людей, с которыми мы к 4 часам ночи запустили наш проект. Руководитель, который был в команде, от этой задачи устранился со словами, что лучше подождать. Может лучше, может нет - выбирает каждый сам. Была цель, были найдены возможности, ни должностей ничего тогда у меня не было, лишь умение настаивать на своем. Причем довольно однобоко и топорно на тот момент. Это сейчас уже у меня есть готовый алгоритм, как что-то запустить с помощью ситуационного лидерства, который я описывал в нашем руководстве по борьбе с рутиной, тогда еще я действовал больше интуитивно.
Как я запускал компонент чужого отдела
Следующая интересная история про ситуационное лидерство была в Домклик. Я тогда возглавлял команду оценки недвижимости и нескольких статистических проектов. В один из дней мне поручили пролидировать запуск компонента другой команды, который должен был быть готов к утру следующего дня, но все никак. Общий посыл был, что нужно разобраться и заставить сделать правильно, причем быстро. На вопросы, почему я, получил ответ: "твоего авторитета и знаний хватит, выдай результат". В итоге, я пошел к людям, которые, как выяснилось, знают меня, но которых я особо не знал. Пол дня ушло на понимание в чем проблема и вечер и ночь ушли на то, чтобы проконтролировать, что все будет переделано согласно новой логике (руками в проект я не лез, ни желания, ни возможности не было). Опять же, я был консультантом. Мог ли я сказать, что ничего не выйдет и просто посидеть рядом? Мог. Могло ли случаться, что меня не стали бы слушать? Конечно. Но в этом и есть суть. В такие моменты можно понять готов ты что-то возглавить, а главное не получив ничего взамен (не всегда, но на старте или в моменте так бывает) взять ответственность или нет.
Основное всегда лежит в области вашего желания и готовности. Вы всегда должны быть готовы брать ответственность за неудачу и придумать решение, если другие впали в ступор (придумать самому или добыть идею другим способом, это не важно). Берите на себя ответственность и будьте настойчивы, тогда вы сможете сделать многое даже без официальной должности. А если умения делать без должности у вас нет, то и должность вам никак не поможет.
Максим Шаламов
#руководителю #разработчику #советы #бизнес #управлениекомандой #разработка #ит #менеджмент
Многие молодые и не только руководители, часто страдают от ощущения, что не могут осуществлять свои управленческие решения. То их руководство не принимает, то команда. Всем постоянно повторяю, что любая должность лишь дает возможность, сами по себе решения от должности не внедрятся. Многое будет строится на вашем авторитете, умение убеждать и настойчивости.
Как я управлял запуском без должности руководителя
Первый свой крупный проект я запускал в Рамблере будучи разработчиком. Тогда мы были в группе RDS с идей быстро запускать и развивать новые направления. Первую версию проекта Путешествий мы сделали меньше чем за месяц, а вот сопровождение всего было все еще частью старой структуры и они еще даже не начали готовить наши сервера. И, в общем, тут бы и сказке конец, ждем и надеемся. Но я обошел все руководство, до которого дотянулся, включая свое направление бизнеса, и мне выдали людей, с которыми мы к 4 часам ночи запустили наш проект. Руководитель, который был в команде, от этой задачи устранился со словами, что лучше подождать. Может лучше, может нет - выбирает каждый сам. Была цель, были найдены возможности, ни должностей ничего тогда у меня не было, лишь умение настаивать на своем. Причем довольно однобоко и топорно на тот момент. Это сейчас уже у меня есть готовый алгоритм, как что-то запустить с помощью ситуационного лидерства, который я описывал в нашем руководстве по борьбе с рутиной, тогда еще я действовал больше интуитивно.
Как я запускал компонент чужого отдела
Следующая интересная история про ситуационное лидерство была в Домклик. Я тогда возглавлял команду оценки недвижимости и нескольких статистических проектов. В один из дней мне поручили пролидировать запуск компонента другой команды, который должен был быть готов к утру следующего дня, но все никак. Общий посыл был, что нужно разобраться и заставить сделать правильно, причем быстро. На вопросы, почему я, получил ответ: "твоего авторитета и знаний хватит, выдай результат". В итоге, я пошел к людям, которые, как выяснилось, знают меня, но которых я особо не знал. Пол дня ушло на понимание в чем проблема и вечер и ночь ушли на то, чтобы проконтролировать, что все будет переделано согласно новой логике (руками в проект я не лез, ни желания, ни возможности не было). Опять же, я был консультантом. Мог ли я сказать, что ничего не выйдет и просто посидеть рядом? Мог. Могло ли случаться, что меня не стали бы слушать? Конечно. Но в этом и есть суть. В такие моменты можно понять готов ты что-то возглавить, а главное не получив ничего взамен (не всегда, но на старте или в моменте так бывает) взять ответственность или нет.
Основное всегда лежит в области вашего желания и готовности. Вы всегда должны быть готовы брать ответственность за неудачу и придумать решение, если другие впали в ступор (придумать самому или добыть идею другим способом, это не важно). Берите на себя ответственность и будьте настойчивы, тогда вы сможете сделать многое даже без официальной должности. А если умения делать без должности у вас нет, то и должность вам никак не поможет.
Максим Шаламов
#руководителю #разработчику #советы #бизнес #управлениекомандой #разработка #ит #менеджмент
Самые главные проблемы с целеполаганием
Проходя очередной цикл бюджетного и проектного планирования на год, не мог в очередной раз не задуматься о целеполагании. Да, сейчас можно много чего почитать про KPI и OKR, так что найти материал не сложно. Но материал материалом, а проблемы с целеполаганием никуда не деваются.
Основное, в моем понимании, с целями это понятность для всех и совпадение по амбициям. Если цели непонятны, то и как их закрывать и зачем их делать никто не поймет. В итоге получаем механическую работу, лишь бы отстали. Все цели нужно формулировать понятно, указать критерии успеха. А потом доносить, причем постоянно, до своих сотрудников. Эта работа регулярная и постоянная, по ходу работы могут возникать сомнения и противоречия, на которые вы должны находить ответ. Надеяться, что люди прочитают ваши мысли и поймут замысел, точно не стоит.
Второе, не менее важное, это совпадение амбиций целей и команды. Например, имея цели держаться на уровне окупаемости, не так просто будет привлечь амбициозную команду. У нас в свое время в Домклик была сформулирована цель как «классифайд по недвижимости №1». Были критерии и во круг этого собралась команда. Все критерии на момент моего ухода достигнуты не были, но по многим был большой прогресс. И главное команду мотивировала эта цель и движение по ней. Важно подбирать команду под цели, иначе вы можете получить неудовлетворительный результат или большую текучку, когда не попадете в ожидания сотрудников.
Максим Шаламов
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
Проходя очередной цикл бюджетного и проектного планирования на год, не мог в очередной раз не задуматься о целеполагании. Да, сейчас можно много чего почитать про KPI и OKR, так что найти материал не сложно. Но материал материалом, а проблемы с целеполаганием никуда не деваются.
Основное, в моем понимании, с целями это понятность для всех и совпадение по амбициям. Если цели непонятны, то и как их закрывать и зачем их делать никто не поймет. В итоге получаем механическую работу, лишь бы отстали. Все цели нужно формулировать понятно, указать критерии успеха. А потом доносить, причем постоянно, до своих сотрудников. Эта работа регулярная и постоянная, по ходу работы могут возникать сомнения и противоречия, на которые вы должны находить ответ. Надеяться, что люди прочитают ваши мысли и поймут замысел, точно не стоит.
Второе, не менее важное, это совпадение амбиций целей и команды. Например, имея цели держаться на уровне окупаемости, не так просто будет привлечь амбициозную команду. У нас в свое время в Домклик была сформулирована цель как «классифайд по недвижимости №1». Были критерии и во круг этого собралась команда. Все критерии на момент моего ухода достигнуты не были, но по многим был большой прогресс. И главное команду мотивировала эта цель и движение по ней. Важно подбирать команду под цели, иначе вы можете получить неудовлетворительный результат или большую текучку, когда не попадете в ожидания сотрудников.
Максим Шаламов
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
Не бросайте лучших сотрудников без внимания
Не часто, но все же бывает, что у вас появляется человек, который закрывает свои задачи полностью и максимально самостоятельно. Прям вот, ставишь цели, берешь сроки и получаешь результат, и так раз за разом. В итоге, у многих руководителей создается соблазн сократить регулярные встречи с таким человеком, мол и так все хорошо, есть и другие люди, которым нужна помощь и внимание. Я категорически не советую так делать. И вот почему:
1. Теряется контакт. И со временем тот, кто хорошо понимал ваши цели и приоритеты, может уйти не в ту сторону и вы получите не предсказуемый результат.
2. Такие люди обычно хорошо понимают вас и эффективны в вашем понимании, значит их мнение ценно и нужно постоянно быть с ними на связи, чтобы получать обратную связь, советоваться и самому получать полезные озарения.
3. В целом, человек тоже может не правильно понять, почему вы не тратите на него время. Даже если вы ему объясните в чем смысл, это ещё не значит, что он с этим согласится. Может создаться впечатление, что вы бегаете от него и не хотите участвовать в его делах. Ведь все равно есть какие-то проблемы, которые без влияния на команду можно обсудить только с руководителем, просто выровняться по своему движению или поговорить, чтобы не терялся контакт. Это все важно и ценно для человека (возможно не для всех, но для большинства).
Старайтесь уделять внимание своим подчинённым вне зависимости от того, справляются они со своими задачи самостоятельно или нет.
Если нужна консультация по работе с вашей командой, пишите запрос в нашего бота.
Максим Шаламов
#руководителю #управлениекомандой #ит #менеджмент
Не часто, но все же бывает, что у вас появляется человек, который закрывает свои задачи полностью и максимально самостоятельно. Прям вот, ставишь цели, берешь сроки и получаешь результат, и так раз за разом. В итоге, у многих руководителей создается соблазн сократить регулярные встречи с таким человеком, мол и так все хорошо, есть и другие люди, которым нужна помощь и внимание. Я категорически не советую так делать. И вот почему:
1. Теряется контакт. И со временем тот, кто хорошо понимал ваши цели и приоритеты, может уйти не в ту сторону и вы получите не предсказуемый результат.
2. Такие люди обычно хорошо понимают вас и эффективны в вашем понимании, значит их мнение ценно и нужно постоянно быть с ними на связи, чтобы получать обратную связь, советоваться и самому получать полезные озарения.
3. В целом, человек тоже может не правильно понять, почему вы не тратите на него время. Даже если вы ему объясните в чем смысл, это ещё не значит, что он с этим согласится. Может создаться впечатление, что вы бегаете от него и не хотите участвовать в его делах. Ведь все равно есть какие-то проблемы, которые без влияния на команду можно обсудить только с руководителем, просто выровняться по своему движению или поговорить, чтобы не терялся контакт. Это все важно и ценно для человека (возможно не для всех, но для большинства).
Старайтесь уделять внимание своим подчинённым вне зависимости от того, справляются они со своими задачи самостоятельно или нет.
Если нужна консультация по работе с вашей командой, пишите запрос в нашего бота.
Максим Шаламов
#руководителю #управлениекомандой #ит #менеджмент
Мой топ-5 прочитанных книг 2024 года
2024 год заканчивался сложно, поэтому было не до итогов. Время ушло, поэтому я пожалуй поделюсь списком самой полезной на мой взгляд литературы, которую я прочитал в 2024 году. Я люблю читать и всегда стараюсь читать много и разное, чего и всем советую.
Начну я с не профессиональной литературы. Казалось бы и зачем она нам? Что я могу полезного в этом почерпнуть? У хороших авторов (особенно в классике) вы можете посмотреть на различные типажи людей в разных ситуациях. Если автор действительно хороший, то вы будете узнавать типажи в жизни и лучше понимать таких людей, а работа руководителя во многом состоит из взаимодействий. Своим опытом всего не получишь. Особенно я люблю нашу классику за это, люди то везде одинаковые, но своих узнавать проще и полезнее в жизни. Научную фантастику я читаю для вдохновения. Интересно смотреть видение и фантазии авторов на развитие мира, на то, чего добьется человечество, а еще обычно там появляется сложная проблема, которую решают не только (и не столько) силовым путем.
Страна багровых туч. Стругацкие
Я вообще не фанат Стругацких, но в 2024 году углубился в их произведения и «Страна багровых туч» вошла в топ моих любимых книг. Считается, что это не лучшая книга Стругацких и тут еще нет их фирменного стиля. Может и так, но мне очень понравились персонажи и их поведение в книге. Будущее не очень далекое, немного наивное видение (с современной точки зрения), но читается на одном дыхании и мне очень понятны проблемы ряда людей. Советую всем почитать.
Волоколамское шоссе. Александр Бек
Что может быть интересно в книге о войне? Если читать в лоб, то только любителям военной литературы. Я бы ее рассматривал с точки зрения управления. Очень хорошо показано, как генерал Панфилов учит своих людей понимать его задумки, думать как он хочет в ситуациях, где его не будет рядом. Показаны проблемы, сопротивление людей и озарения. Показано как это потом спускается ниже. С точки зрения управления и вовлечения в свои идеи очень интересно и жизненно.
Профессиональная литература тоже порадовала. Начну с книги, которую советовали прочитать всему Сберу в виду пробы подхода к целеполаганию через ОКР.
Управление по целям и ключевым результатам. Ветри Веллор
Книга мне в целом понравилась, показано как на практике можно поставить цели сверху вплоть до целей каждого исполнителя. Есть много примеров и пояснений для чего это делается. Почитать полезно, внедрять или нет тут каждый сам решает.
Путь камикадзе. Йордон Эдвард
Книга не самая новая и я долго обходил ее стороной. Но, на самом деле, это великолепная книга по описанию проблем проектного управления. Много очень живых примеров и ситуаций. Я постоянно ловил себя на мысли, что вот такое я видел и такое. Очень советую почитать, примеры могут быть полезны для общения с коллегами и руководством, чтобы донести до них последствия выбранных действий.
Искусственный интеллект и экономика. Роджер Бутл
Сейчас у нас глобальная мода на ИИ, поэтому советую почитать книгу, в которой рассматриваются варианты изменения жизни при повальном внедрении ИИ. Рассмотрены разные мнения от совсем пессимистичных, где люди теряют работу, до совсем утопичных.
А что вам особенно запомнилось из прочитанного в 2024 году? Делитесь в комментариях.
Максим Шаламов
#советы #книги #топ2024 #руководителю
2024 год заканчивался сложно, поэтому было не до итогов. Время ушло, поэтому я пожалуй поделюсь списком самой полезной на мой взгляд литературы, которую я прочитал в 2024 году. Я люблю читать и всегда стараюсь читать много и разное, чего и всем советую.
Начну я с не профессиональной литературы. Казалось бы и зачем она нам? Что я могу полезного в этом почерпнуть? У хороших авторов (особенно в классике) вы можете посмотреть на различные типажи людей в разных ситуациях. Если автор действительно хороший, то вы будете узнавать типажи в жизни и лучше понимать таких людей, а работа руководителя во многом состоит из взаимодействий. Своим опытом всего не получишь. Особенно я люблю нашу классику за это, люди то везде одинаковые, но своих узнавать проще и полезнее в жизни. Научную фантастику я читаю для вдохновения. Интересно смотреть видение и фантазии авторов на развитие мира, на то, чего добьется человечество, а еще обычно там появляется сложная проблема, которую решают не только (и не столько) силовым путем.
Страна багровых туч. Стругацкие
Я вообще не фанат Стругацких, но в 2024 году углубился в их произведения и «Страна багровых туч» вошла в топ моих любимых книг. Считается, что это не лучшая книга Стругацких и тут еще нет их фирменного стиля. Может и так, но мне очень понравились персонажи и их поведение в книге. Будущее не очень далекое, немного наивное видение (с современной точки зрения), но читается на одном дыхании и мне очень понятны проблемы ряда людей. Советую всем почитать.
Волоколамское шоссе. Александр Бек
Что может быть интересно в книге о войне? Если читать в лоб, то только любителям военной литературы. Я бы ее рассматривал с точки зрения управления. Очень хорошо показано, как генерал Панфилов учит своих людей понимать его задумки, думать как он хочет в ситуациях, где его не будет рядом. Показаны проблемы, сопротивление людей и озарения. Показано как это потом спускается ниже. С точки зрения управления и вовлечения в свои идеи очень интересно и жизненно.
Профессиональная литература тоже порадовала. Начну с книги, которую советовали прочитать всему Сберу в виду пробы подхода к целеполаганию через ОКР.
Управление по целям и ключевым результатам. Ветри Веллор
Книга мне в целом понравилась, показано как на практике можно поставить цели сверху вплоть до целей каждого исполнителя. Есть много примеров и пояснений для чего это делается. Почитать полезно, внедрять или нет тут каждый сам решает.
Путь камикадзе. Йордон Эдвард
Книга не самая новая и я долго обходил ее стороной. Но, на самом деле, это великолепная книга по описанию проблем проектного управления. Много очень живых примеров и ситуаций. Я постоянно ловил себя на мысли, что вот такое я видел и такое. Очень советую почитать, примеры могут быть полезны для общения с коллегами и руководством, чтобы донести до них последствия выбранных действий.
Искусственный интеллект и экономика. Роджер Бутл
Сейчас у нас глобальная мода на ИИ, поэтому советую почитать книгу, в которой рассматриваются варианты изменения жизни при повальном внедрении ИИ. Рассмотрены разные мнения от совсем пессимистичных, где люди теряют работу, до совсем утопичных.
А что вам особенно запомнилось из прочитанного в 2024 году? Делитесь в комментариях.
Максим Шаламов
#советы #книги #топ2024 #руководителю
Как бизнесу наладить общение с командой разработки. Часть 2
Продолжаем тему, как бизнесу наладить хороший контакт с командой разработки, еще четырьмя важными пунктами.
Формализация требований
Избегайте ненужных конфликтов за счет формализации требований. Все требования, договоренности и сроки должны быть зафиксированы. Устные договоренности не имеют смысла, если их не фиксировать. Все могут вынести разные вещи из встречи, кто-то забыл, кто-то не услышал. В итоге мы получаем кучу конфликтов на приемке или кучу обманутых ожиданий, которых вообще не должно было быть. Выберите инструмент и фиксируйте все. Проработайте задачу в том виде, как вы бы хотели ее видеть, как пользователь системы, тогда вы сможете ожидать, что получите именно то, что заказали. Иначе, вы получите, что-то, что может быть далеко от ваших ожиданий. Но если они не зафиксированы, то никакой конструктивной критики и работы над ошибками не получится. Будут только конфликты и потеря мотивации. Как хорошо фиксировать требования в задаче на разработку вы можете посмотреть в нашем руководстве по описанию задач.
Работайте с идеями команды
Всегда собирайте идеи и предложения вашей команды по деталям задач или вообще идеи по улучшению продукта. Если они разумны, всегда старайтесь брать их в работу. То, что людей слышат и дают влиять на продукт, который они делают, очень сильно повышает мотивацию. Как и наоборот: мотивацию убивает нежелание слушать свою команду и обсуждать ее идеи.
Отслеживание процесса
Используйте системы трекинга задач и регулярные встречи для отслеживания прогресса по задачам. Не дергайте команду каждую минуту. Это очень выбивает из контекста, а так же выглядит, как недоверие, и ведет к конфликтам. Не пытайтесь оценивать задачи сами, иначе вы получите либо не работающий вариант в свои сроки, либо перенос сроков и огромное негодование своей команды. Учитесь работать по оцененным срокам, доверяйте своей команде, а если есть проблемы, то улучшайте процессы для повышения прозрачности, ну или нужно менять членов команды, которые не тянут (но это должны делать технические лидеры вашей компании, которые разбираются в специфике и работе IT, делайте это через них).
Будьте на связи
Последние о чем хотелось бы сказать, будьте на связи. К вам всегда будут вопросы за уточнениями (которые тоже все всегда нужно фиксировать) и чем оперативнее вы отвечаете, тем меньше простой в работе команды.
Заключение
Я общался с многими ПО и понимаю их проблемы: надо и развитие продукта проработать, и бюджеты утвердить, и встретиться с клиентами и пользователями и многое другое. Где тут взять время на команду? Тут нужно понимать, что если вам все же нужна команда, то все, что я написал нужно делать. Не успеваете сами? Наймите человека, который будет работать с командой, расписывать задачи, ходить на встречи, будет все время на связи. На определенном этапе развития проекта брать помощь не просто можно, но и нужно.
Может показаться, что это все повлечет за собой просадку в производительности. Однако, когда все знают, что и как им делать, задачи в итоге решаются быстро и качественно, а еще пропадает миллион переписок или созвонов для уточнения требований. Я проходил процедуры аудита, которые раз от раза показывали, что команды, работающие в таких реалиях, работают как минимум выше среднего по компании, а обычно близко к верхним границам производительности.
Максим Шаламов
_____________________
Если у вас есть сложность с организацией работы своей разработки, вы всегда можете обратиться за помощью к нашей команде. Просто опишите свою проблему через нашего бота, почту info@oros-it.ru или форму на сайте, мы ответим вам в ближайшее время и предложим варианты решения.
#советы #бизнесу #agile #управлениекомандой #руководителю
Продолжаем тему, как бизнесу наладить хороший контакт с командой разработки, еще четырьмя важными пунктами.
Формализация требований
Избегайте ненужных конфликтов за счет формализации требований. Все требования, договоренности и сроки должны быть зафиксированы. Устные договоренности не имеют смысла, если их не фиксировать. Все могут вынести разные вещи из встречи, кто-то забыл, кто-то не услышал. В итоге мы получаем кучу конфликтов на приемке или кучу обманутых ожиданий, которых вообще не должно было быть. Выберите инструмент и фиксируйте все. Проработайте задачу в том виде, как вы бы хотели ее видеть, как пользователь системы, тогда вы сможете ожидать, что получите именно то, что заказали. Иначе, вы получите, что-то, что может быть далеко от ваших ожиданий. Но если они не зафиксированы, то никакой конструктивной критики и работы над ошибками не получится. Будут только конфликты и потеря мотивации. Как хорошо фиксировать требования в задаче на разработку вы можете посмотреть в нашем руководстве по описанию задач.
Работайте с идеями команды
Всегда собирайте идеи и предложения вашей команды по деталям задач или вообще идеи по улучшению продукта. Если они разумны, всегда старайтесь брать их в работу. То, что людей слышат и дают влиять на продукт, который они делают, очень сильно повышает мотивацию. Как и наоборот: мотивацию убивает нежелание слушать свою команду и обсуждать ее идеи.
Отслеживание процесса
Используйте системы трекинга задач и регулярные встречи для отслеживания прогресса по задачам. Не дергайте команду каждую минуту. Это очень выбивает из контекста, а так же выглядит, как недоверие, и ведет к конфликтам. Не пытайтесь оценивать задачи сами, иначе вы получите либо не работающий вариант в свои сроки, либо перенос сроков и огромное негодование своей команды. Учитесь работать по оцененным срокам, доверяйте своей команде, а если есть проблемы, то улучшайте процессы для повышения прозрачности, ну или нужно менять членов команды, которые не тянут (но это должны делать технические лидеры вашей компании, которые разбираются в специфике и работе IT, делайте это через них).
Будьте на связи
Последние о чем хотелось бы сказать, будьте на связи. К вам всегда будут вопросы за уточнениями (которые тоже все всегда нужно фиксировать) и чем оперативнее вы отвечаете, тем меньше простой в работе команды.
Заключение
Я общался с многими ПО и понимаю их проблемы: надо и развитие продукта проработать, и бюджеты утвердить, и встретиться с клиентами и пользователями и многое другое. Где тут взять время на команду? Тут нужно понимать, что если вам все же нужна команда, то все, что я написал нужно делать. Не успеваете сами? Наймите человека, который будет работать с командой, расписывать задачи, ходить на встречи, будет все время на связи. На определенном этапе развития проекта брать помощь не просто можно, но и нужно.
Может показаться, что это все повлечет за собой просадку в производительности. Однако, когда все знают, что и как им делать, задачи в итоге решаются быстро и качественно, а еще пропадает миллион переписок или созвонов для уточнения требований. Я проходил процедуры аудита, которые раз от раза показывали, что команды, работающие в таких реалиях, работают как минимум выше среднего по компании, а обычно близко к верхним границам производительности.
Максим Шаламов
_____________________
Если у вас есть сложность с организацией работы своей разработки, вы всегда можете обратиться за помощью к нашей команде. Просто опишите свою проблему через нашего бота, почту info@oros-it.ru или форму на сайте, мы ответим вам в ближайшее время и предложим варианты решения.
#советы #бизнесу #agile #управлениекомандой #руководителю
Самоорганизующаяся команда за 6 шагов
Залили первую статью на VC. Большой материал о том, что нужно делать, чтобы создать самоорганизующуюся команду разработки, которая реально делает задачи самостоятельно и не дергает своего руководителя по поводу и без. Для каждого пункта подобрали наглядные примеры, что будет, если их выполнять правильно и что будет, если их выполнят неправильно. В одном из примеров даже рассказали, как напрочь убить у команды желание проявлять инициативу)
https://vc.ru/dev/1770594-kak-sozdat-samoorganizuyushuyusya-komandu-razrabotki
#разработка #управлениекомандой #agile #бизнес #руководителю
Залили первую статью на VC. Большой материал о том, что нужно делать, чтобы создать самоорганизующуюся команду разработки, которая реально делает задачи самостоятельно и не дергает своего руководителя по поводу и без. Для каждого пункта подобрали наглядные примеры, что будет, если их выполнять правильно и что будет, если их выполнят неправильно. В одном из примеров даже рассказали, как напрочь убить у команды желание проявлять инициативу)
https://vc.ru/dev/1770594-kak-sozdat-samoorganizuyushuyusya-komandu-razrabotki
#разработка #управлениекомандой #agile #бизнес #руководителю
vc.ru
Как создать самоорганизующуюся команду разработки — Разработка на vc.ru
ИТ-Беседка Разработка сейчас
Заказал одно - получил другое: почему команда делает не то, что просишь?
Я занимаюсь разработкой и управлением команд разработки еще с первых курсов института. Поработал я и как фрилансер, и как малый предприниматель, и как сотрудник и управленец малых и крупных компаний. Проблема с приемкой результатов возникает часто (к счастью не всегда, и сам учишься с этим работать и коллеги / заказчики бывают очень адекватными). Давайте пробежимся по распространенным ситуациям.
Начнем с того, что обычно, так или иначе, есть три звена в работе над задачей:
- бизнес-заказчик (это могут быть и руководители компании и руководители отделов, чьи процессы нужно автоматизировать или включить в свои);
- постановщики задачи в команду (ПО, бизнес-аналитик, ПМ - названия не так и важны, это люди, которые являются точкой входа для заказчика)
- команда разработки.
Основные виды проблем, из-за которых заказчик получает не то, что заказывал
1. Частая история, когда бизнес-заказчик вообще слабо понимает, что он хочет, и слабо мотивирован в участии в постановке задачи. Он уверен, что все итак понятно и что там делать-то. В итоге, половину или большую часть постановки приходится делать ПО и / или команде. Даже если таким людям отдать на проверку постановку, то обычно комментариев будет немного или наоборот ситуация просто застопорится, потому что всегда будет все неправильно. В итоге, максимально абстрактно поставленная задача, получает воплощение, которое шокирует заказчика и вызывает его негодование. Если вы сами хотите научиться хорошо прорабатывать задачи или научить этому своего бизнес-заказчика, обязательно используйте наше руководство по описанию задач. В нем есть все необходимое.
2. Предположим, бизнес-заказчик оказался мотивирован и из него удается получить нужную информацию. Следующий этап проблем возникает на стороне ПО и бизнес-аналитика. Многие такие ребята считают, что все знают лучше всех, и часто добавляют свои идеи или полностью меняют идею бизнес-заказчика. В итоге, сделанная по бизнес требованиям задача, оказывается совершенно не тем, что хочет заказчик.
3. Будем честными, даже если вам дошла качественная постановка задачи, бывают творцы и на стороне разработки, которые на полном серьезе считают, что сделают лучше и правильнее. И потом, когда презентуют результат, очень удивляются, что же не так.
4. Также у любого требования есть разница в понимании между людьми, которые находятся в разных контекстах. Бизнес-заказчик очень хорошо знает предметную область и ему все очевидно, тогда как команда может вообще еще не разбираться в предметной области. Тогда возникает много вопросов и, при плохо выстроенных процессах, выяснение деталей будет постоянно теряться, изменяться или стопориться между тремя группами. Это приводит либо к затягиванию согласований, либо к появлению большого числа расхождений между тем, что хотели бизнес-заказчики, и тем, как их поняли исполнители.
5. Большой проблемой многих проектов бывают ограничения в ресурсах. Не важно каких: временных, людских, серверных и т.д. И тут обычно бизнес-заказчик не хочет идти на уступки. Поэтому он получает либо кусок функционала (обычно не с самым лучшим качеством), либо может и весь функционал, но с совершенно не устраивающим качеством.
Я думал, какой сделать тут вывод. Проектное управление не самое простое занятие и несет множество рисков и конфликтов. Но, чем лучше вы понимаете тонкости, чем лучше обучите команду и выстроите процессы, тем проще вам будет.
А если вам нужно помощь с выстраивание процессов для своей разработки, вы всегда можете обратиться за к нашей команде. Просто опишите свою проблему через нашего бота, почту info@oros-it.ru или форму на сайте, мы ответим вам в ближайшее время и предложим варианты решения.
Максим Шаламов
#руководителю #бизнесу #управлениекомандой #разработка
Я занимаюсь разработкой и управлением команд разработки еще с первых курсов института. Поработал я и как фрилансер, и как малый предприниматель, и как сотрудник и управленец малых и крупных компаний. Проблема с приемкой результатов возникает часто (к счастью не всегда, и сам учишься с этим работать и коллеги / заказчики бывают очень адекватными). Давайте пробежимся по распространенным ситуациям.
Начнем с того, что обычно, так или иначе, есть три звена в работе над задачей:
- бизнес-заказчик (это могут быть и руководители компании и руководители отделов, чьи процессы нужно автоматизировать или включить в свои);
- постановщики задачи в команду (ПО, бизнес-аналитик, ПМ - названия не так и важны, это люди, которые являются точкой входа для заказчика)
- команда разработки.
Основные виды проблем, из-за которых заказчик получает не то, что заказывал
1. Частая история, когда бизнес-заказчик вообще слабо понимает, что он хочет, и слабо мотивирован в участии в постановке задачи. Он уверен, что все итак понятно и что там делать-то. В итоге, половину или большую часть постановки приходится делать ПО и / или команде. Даже если таким людям отдать на проверку постановку, то обычно комментариев будет немного или наоборот ситуация просто застопорится, потому что всегда будет все неправильно. В итоге, максимально абстрактно поставленная задача, получает воплощение, которое шокирует заказчика и вызывает его негодование. Если вы сами хотите научиться хорошо прорабатывать задачи или научить этому своего бизнес-заказчика, обязательно используйте наше руководство по описанию задач. В нем есть все необходимое.
2. Предположим, бизнес-заказчик оказался мотивирован и из него удается получить нужную информацию. Следующий этап проблем возникает на стороне ПО и бизнес-аналитика. Многие такие ребята считают, что все знают лучше всех, и часто добавляют свои идеи или полностью меняют идею бизнес-заказчика. В итоге, сделанная по бизнес требованиям задача, оказывается совершенно не тем, что хочет заказчик.
3. Будем честными, даже если вам дошла качественная постановка задачи, бывают творцы и на стороне разработки, которые на полном серьезе считают, что сделают лучше и правильнее. И потом, когда презентуют результат, очень удивляются, что же не так.
4. Также у любого требования есть разница в понимании между людьми, которые находятся в разных контекстах. Бизнес-заказчик очень хорошо знает предметную область и ему все очевидно, тогда как команда может вообще еще не разбираться в предметной области. Тогда возникает много вопросов и, при плохо выстроенных процессах, выяснение деталей будет постоянно теряться, изменяться или стопориться между тремя группами. Это приводит либо к затягиванию согласований, либо к появлению большого числа расхождений между тем, что хотели бизнес-заказчики, и тем, как их поняли исполнители.
5. Большой проблемой многих проектов бывают ограничения в ресурсах. Не важно каких: временных, людских, серверных и т.д. И тут обычно бизнес-заказчик не хочет идти на уступки. Поэтому он получает либо кусок функционала (обычно не с самым лучшим качеством), либо может и весь функционал, но с совершенно не устраивающим качеством.
Я думал, какой сделать тут вывод. Проектное управление не самое простое занятие и несет множество рисков и конфликтов. Но, чем лучше вы понимаете тонкости, чем лучше обучите команду и выстроите процессы, тем проще вам будет.
А если вам нужно помощь с выстраивание процессов для своей разработки, вы всегда можете обратиться за к нашей команде. Просто опишите свою проблему через нашего бота, почту info@oros-it.ru или форму на сайте, мы ответим вам в ближайшее время и предложим варианты решения.
Максим Шаламов
#руководителю #бизнесу #управлениекомандой #разработка
Почему обязательно нужно смотреть задачи вместе с командой?
Продолжаем тему почему иногда мы получаем в задачах не то, что заказывали. Смотреть задачи с командой - это один из инструментов по получению желаемого результата. Как я и писал, разница между тем, что ты хочешь и тем, как тебя поймут и сделают бывает большая. Поэтому ваша задача сделать так, чтобы вас поняли правильно. Лучшего способа, чем сесть и пройти все с командой или хотя бы их лидером - нет.
Многие ИТ-лидеры скажут, что для для бизнеса (ПО и БЗ) то да, но я та говорю с ребятами на одном языке, у меня проблем не будет. Заманчивая точка зрения, но в корне неверная. Возьму себя и одну из своих задач 2024 года по внедрению автоматического регрессионного тестирования. Я поставил задачу, мы нарисовали дорожную карту, со всеми договорились и пошли делать. Отклонений по дорожной карте особо не было и я посмотрел демо того, что сделано уже ближе к концу. И все было бы хорошо, только я ожидал, что мы делаем регресс всего продукта, а мы сделали регресс отдельных частей (по сути поделив по командам). И это решает часть проблем, но не все, которые ожидалось.
Можно много кого обвинять, но правильнее посмотреть на себя, лучше ставить задачи и разбираться поняли ли их также, как понимаете их вы.
Всегда старайтесь убедиться правильно ли вас поняли и не экономьте время на это, иначе вы будете неприятно удивлены по итогу, когда задачу придется частично или полностью переделывать в дополнительное время.
Подробнее, как проводить подобные встречи с командой, мы писали в нашей книге "Гибкие методологии на практике". Там вы найдете все необходимое про работу с задачами и процессами в своей команде разработки, в том числе описание всех церемоний, которые помогут вовремя отследить разницу в понимании задач.
Максим Шаламов
#руководителю #бизнесу #управлениекомандой #разработка #agile #гибкиеметодологии
Продолжаем тему почему иногда мы получаем в задачах не то, что заказывали. Смотреть задачи с командой - это один из инструментов по получению желаемого результата. Как я и писал, разница между тем, что ты хочешь и тем, как тебя поймут и сделают бывает большая. Поэтому ваша задача сделать так, чтобы вас поняли правильно. Лучшего способа, чем сесть и пройти все с командой или хотя бы их лидером - нет.
Многие ИТ-лидеры скажут, что для для бизнеса (ПО и БЗ) то да, но я та говорю с ребятами на одном языке, у меня проблем не будет. Заманчивая точка зрения, но в корне неверная. Возьму себя и одну из своих задач 2024 года по внедрению автоматического регрессионного тестирования. Я поставил задачу, мы нарисовали дорожную карту, со всеми договорились и пошли делать. Отклонений по дорожной карте особо не было и я посмотрел демо того, что сделано уже ближе к концу. И все было бы хорошо, только я ожидал, что мы делаем регресс всего продукта, а мы сделали регресс отдельных частей (по сути поделив по командам). И это решает часть проблем, но не все, которые ожидалось.
Можно много кого обвинять, но правильнее посмотреть на себя, лучше ставить задачи и разбираться поняли ли их также, как понимаете их вы.
Всегда старайтесь убедиться правильно ли вас поняли и не экономьте время на это, иначе вы будете неприятно удивлены по итогу, когда задачу придется частично или полностью переделывать в дополнительное время.
Подробнее, как проводить подобные встречи с командой, мы писали в нашей книге "Гибкие методологии на практике". Там вы найдете все необходимое про работу с задачами и процессами в своей команде разработки, в том числе описание всех церемоний, которые помогут вовремя отследить разницу в понимании задач.
Максим Шаламов
#руководителю #бизнесу #управлениекомандой #разработка #agile #гибкиеметодологии
Шпаргалка по росту в руководителя команды
Чаще всего к нам на карьерные консультации приходят люди, которые не знают, как им дальше двигаться по карьерной лестнице или не могут определить, в какое направление лучше всего направить усилия, чтобы достичь желаемого. В первую очедерь мы обсуждаем, чего хочется самому человеку. Потому что без желания к чему-то двигаться никакие карьерные советы не помогут. Бывает так, что направление выбрано, но желания нет, поэтому и движения не получается. Также помогаем определиться с направление с помощью аналитики текущего рынка и наклонностей самого человека. Определив направление уже ставим конкретную цель и составляем план действий.
Один из самых тяжелых карьерных переходов это переход от исполнителя к должности руководителя. Именно на нем у человека часто возникают сложности и сомнения. Сложно с представление, что нужно будет делать, потому что есть множество стереотипов, сложно понять, как двигаться в нужном направлении, как сделать первые шаги. Именно поэтому мы часто поднимаем тему роста именно в руководителя и в этот раз решили сделать вам такую подборку-шпаргалку по росту в руководителя из материалов, которые уже есть на канале.
Первое, что нужно понять, что вообще из себя представляет должность руководителя:
- Карточки с описанием обязанностей руководителя команды (тимлида)
- Карточки с описанием обязанностей технического руководителя команды (техлида)
- Подробный пример, чем занят руководитель в свой рабочий день
- Чем отличается руководитель от разработчика
Дальше определяем, а нужно ли оно именно вам:
- 4 признака, что вам не дано быть руководителем
- Какие требования СТО предъявляет руководителям команд на собеседовании в том числе личные качества
- Правда ли нужно быть стрессоустойчивым, чтобы быть руководителем
- Зачем вообще становится руководителем, если разработчику итак хорошо платят?
Ну и конечно разбираемся, как сделать первые шаги:
- Подробная инструкция, как стать руководителем команды
- Нужны ли руководителю разработкой технические знания
- 6 универсальные советов для руководителей
- Что больше всего мешает разработчику стать руководителем
- Надо ли проработать 10 лет разработчиком, чтобы управлять командой разработки
- Как формируется лидерство
Очень полезно смотреть на опыт тех, кто уже прошел прошел по этому пути, поэтому рекомендую перечитать интервью Максима, о том, как он проходил свой путь от разработчика до СТО. Там есть и полезные советы по росту.
Сохраняйте этот пост, чтобы не потерять все ссылки, пересылайте коллегам и подчинённым, чтобы помочь им найти свой путь к управлению командой. Иногда даже пара советов от опытного управленца могут сэкономить годы собственного опыта и ошибок. А если вы все уже прочитали, но у вас есть какие-то трудности, то приходите к нам карьерную консультацию. Нужно просто подать запрос через нашего бота, почту info@oros-it.ru или форму на сайте.
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
Чаще всего к нам на карьерные консультации приходят люди, которые не знают, как им дальше двигаться по карьерной лестнице или не могут определить, в какое направление лучше всего направить усилия, чтобы достичь желаемого. В первую очедерь мы обсуждаем, чего хочется самому человеку. Потому что без желания к чему-то двигаться никакие карьерные советы не помогут. Бывает так, что направление выбрано, но желания нет, поэтому и движения не получается. Также помогаем определиться с направление с помощью аналитики текущего рынка и наклонностей самого человека. Определив направление уже ставим конкретную цель и составляем план действий.
Один из самых тяжелых карьерных переходов это переход от исполнителя к должности руководителя. Именно на нем у человека часто возникают сложности и сомнения. Сложно с представление, что нужно будет делать, потому что есть множество стереотипов, сложно понять, как двигаться в нужном направлении, как сделать первые шаги. Именно поэтому мы часто поднимаем тему роста именно в руководителя и в этот раз решили сделать вам такую подборку-шпаргалку по росту в руководителя из материалов, которые уже есть на канале.
Первое, что нужно понять, что вообще из себя представляет должность руководителя:
- Карточки с описанием обязанностей руководителя команды (тимлида)
- Карточки с описанием обязанностей технического руководителя команды (техлида)
- Подробный пример, чем занят руководитель в свой рабочий день
- Чем отличается руководитель от разработчика
Дальше определяем, а нужно ли оно именно вам:
- 4 признака, что вам не дано быть руководителем
- Какие требования СТО предъявляет руководителям команд на собеседовании в том числе личные качества
- Правда ли нужно быть стрессоустойчивым, чтобы быть руководителем
- Зачем вообще становится руководителем, если разработчику итак хорошо платят?
Ну и конечно разбираемся, как сделать первые шаги:
- Подробная инструкция, как стать руководителем команды
- Нужны ли руководителю разработкой технические знания
- 6 универсальные советов для руководителей
- Что больше всего мешает разработчику стать руководителем
- Надо ли проработать 10 лет разработчиком, чтобы управлять командой разработки
- Как формируется лидерство
Очень полезно смотреть на опыт тех, кто уже прошел прошел по этому пути, поэтому рекомендую перечитать интервью Максима, о том, как он проходил свой путь от разработчика до СТО. Там есть и полезные советы по росту.
Сохраняйте этот пост, чтобы не потерять все ссылки, пересылайте коллегам и подчинённым, чтобы помочь им найти свой путь к управлению командой. Иногда даже пара советов от опытного управленца могут сэкономить годы собственного опыта и ошибок. А если вы все уже прочитали, но у вас есть какие-то трудности, то приходите к нам карьерную консультацию. Нужно просто подать запрос через нашего бота, почту info@oros-it.ru или форму на сайте.
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
Вы никогда не найдете исполнителя для своей задачи, если будете делать так
Недавно на одной из конференций в зале взяла микрофон женщина, которая выплеснула просто крик души, что они на своем заводе по производству Х уже 4 года не могут найти исполнителя для создания цифрового двойника системы отвода воды для заводах по производству Х. Их просто нет! Конечно же тут же нашлось минимум 3 человека, которые делают цифровые двойники и могут ей помочь. Так в чем же проблема?
Часто с подобной проблемой поиска можно столкнуться, например, при работе с HR. Однажды я общался с одним из наших крупных маркетплейсов на позицию руководителя отдела. HR сказала мне, что по их мнению у меня маловато опыта для отдела, в который она ищет. Забавно, что параллельно, другой их HR меня звал уже сразу пообщаться с руководителем по направлению путешествий, которое они открывали, потому что я точно подхожу и уже надо запускать. Что же отличало эти ситуации, одна компания, равные должности разные отделы? Просто у меня был опыт в проектах с путешествиями, поэтому талантливые HR нашли совпадение в проекте, а в другом отделе такого совпадения не нашли. При том, что техническому руководителю такие детали абсолютно не критичны. Но с позиции HR, ищущего совпадения в названии проектов в резюме, это не известно.
Так же и в задаче поиска исполнителей. Ваша задача всегда чем-то уникальна или вы, например, первые из своей отрасли хотите автоматизации. Ищите профессионалов в нужной вам сфере, они смогут адаптироваться решение под вас. Нужно найти, как сделать цифровой двойник вашего завода по производству сверхтонких спичек, найдите профессионалов по цифровым двойникам, посмотрите работали ли они с заводами и нравится ли вам то, что они делают. Да, вашего кейса там не будет, но этого и не нужно. В этом кейсе от вас и ваших сотрудников понадобится многих усилий для создания двойника (и не важно делали ли точно такой же завод или нет, нужна именно ваша история). Более того, от того, что кто-то делал двойник похожего спичечного завода не значит, что делал успешно, не значит, что подойдет именно вам по срокам, стоимости, формату результатов и т.д. и т.п. Работать вам и исполнителя подбирайте под себя.
Попытка найти человека, делавшего прямо вашу задачу понятна, но часто это сильно ограничивает вас в выборе и иногда вообще лишает возможностей. Смотрите на ключевые навыки и результаты. Это и есть точка отсчета для вас при поиске сотрудников и подрядчиков. Выбирайте наиболее важные для вас вещи. Это могут быть как личностные (ответственность, исполнительность), так и сугубо профессиональные (знание контрактных технологий, опыт в определенных сферах, проекты с похожей спецификой и нагрузкой и т.д.).
Если у вас есть сложность с поиском исполнителей или формированием команды разработки, вы всегда можете обратиться за помощью к нашей команде. Просто опишите свою проблему через нашего бота, почту info@oros-it.ru или форму на сайте, мы ответим вам в ближайшее время и предложим варианты решения.
Максим Шаламов
#руководителю #бизнесу #заказчику #разработка #поискисполнителей
Недавно на одной из конференций в зале взяла микрофон женщина, которая выплеснула просто крик души, что они на своем заводе по производству Х уже 4 года не могут найти исполнителя для создания цифрового двойника системы отвода воды для заводах по производству Х. Их просто нет! Конечно же тут же нашлось минимум 3 человека, которые делают цифровые двойники и могут ей помочь. Так в чем же проблема?
Часто с подобной проблемой поиска можно столкнуться, например, при работе с HR. Однажды я общался с одним из наших крупных маркетплейсов на позицию руководителя отдела. HR сказала мне, что по их мнению у меня маловато опыта для отдела, в который она ищет. Забавно, что параллельно, другой их HR меня звал уже сразу пообщаться с руководителем по направлению путешествий, которое они открывали, потому что я точно подхожу и уже надо запускать. Что же отличало эти ситуации, одна компания, равные должности разные отделы? Просто у меня был опыт в проектах с путешествиями, поэтому талантливые HR нашли совпадение в проекте, а в другом отделе такого совпадения не нашли. При том, что техническому руководителю такие детали абсолютно не критичны. Но с позиции HR, ищущего совпадения в названии проектов в резюме, это не известно.
Так же и в задаче поиска исполнителей. Ваша задача всегда чем-то уникальна или вы, например, первые из своей отрасли хотите автоматизации. Ищите профессионалов в нужной вам сфере, они смогут адаптироваться решение под вас. Нужно найти, как сделать цифровой двойник вашего завода по производству сверхтонких спичек, найдите профессионалов по цифровым двойникам, посмотрите работали ли они с заводами и нравится ли вам то, что они делают. Да, вашего кейса там не будет, но этого и не нужно. В этом кейсе от вас и ваших сотрудников понадобится многих усилий для создания двойника (и не важно делали ли точно такой же завод или нет, нужна именно ваша история). Более того, от того, что кто-то делал двойник похожего спичечного завода не значит, что делал успешно, не значит, что подойдет именно вам по срокам, стоимости, формату результатов и т.д. и т.п. Работать вам и исполнителя подбирайте под себя.
Попытка найти человека, делавшего прямо вашу задачу понятна, но часто это сильно ограничивает вас в выборе и иногда вообще лишает возможностей. Смотрите на ключевые навыки и результаты. Это и есть точка отсчета для вас при поиске сотрудников и подрядчиков. Выбирайте наиболее важные для вас вещи. Это могут быть как личностные (ответственность, исполнительность), так и сугубо профессиональные (знание контрактных технологий, опыт в определенных сферах, проекты с похожей спецификой и нагрузкой и т.д.).
Если у вас есть сложность с поиском исполнителей или формированием команды разработки, вы всегда можете обратиться за помощью к нашей команде. Просто опишите свою проблему через нашего бота, почту info@oros-it.ru или форму на сайте, мы ответим вам в ближайшее время и предложим варианты решения.
Максим Шаламов
#руководителю #бизнесу #заказчику #разработка #поискисполнителей
А что если убрать руководителя команды?
Я давно работаю в крупных компаниях и прошел период, когда в ряде компания (и в нашей тоже) пытались отказаться от руководителей команд. Для крупных компаний это казалось не так критично, потому что руководящая прослойка все равно была, но даже для них это не сработало. Давайте подумаем, на какие вопросы нужно найти ответ и почему в итоге появляется руководитель команды, СТО и другие руководители.
Отмечу, что я верю, что существуют компании, где на какой-то период из этого правила было исключение и компания работала успешно и эффективно. Вопрос этого периода и того, что сложно воспроизвести такой результат. Итак вопросы, на которые вам надо найти ответы при работе команды:
1. Найм людей;
2. Удержание людей;
3. Работа с мотивацией и повышениями;
4. Оценка адекватности называемых сроков;
5. Оценка качества работы;
6. Стратегическое развитие технической части проектов;
7. Технологический стек;
8. Споры в командах ;
9. Закрытие вопросов безопасности;
10. Работа с качеством поставок функционала;
11. Обеспечение отказоустойчивости;
12. И т.д. и т.п.
В целом, если сотрудник один, то он обычно и сам себе режиссер. Но остается много вопросов с тем, что делать, когда он уйдет. Обычно в небольших компаниях кто-то в руководстве или один из учредителей обладает инженерной компетенцией и является СТО, это по сути, в таких масштабах, и делает его руководителем технической команды. Но если его нет, то на все вопросы отвечать придется собственнику или ответственному за бизнес.
А если людей больше, то все очень быстро перестает работать. Достигать согласованности решений и проводить оценку качества все равно кто-то должен. В компании у вас должен быть как минимум один технический руководитель, на которого вы можете положиться, в малых масштабах это руководитель команды-СТО, дальше, с ростом, это будет полноценная управленческая позиция.
Я не говорю, что выделил руководителя и все разработало, это даже близко не так. Я говорю, что есть много задач, которые нужно делать и логичнее и правильнее их погрузить в руководителя команды (отдела).
Если у вас есть сложность с поиском исполнителей или формированием команды разработки, вы всегда можете обратиться за помощью к нашей команде. Просто опишите свою проблему через нашего бота, почту info@oros-it.ru или форму на сайте, мы ответим вам в ближайшее время и предложим варианты решения.
Максим Шаламов
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент
Я давно работаю в крупных компаниях и прошел период, когда в ряде компания (и в нашей тоже) пытались отказаться от руководителей команд. Для крупных компаний это казалось не так критично, потому что руководящая прослойка все равно была, но даже для них это не сработало. Давайте подумаем, на какие вопросы нужно найти ответ и почему в итоге появляется руководитель команды, СТО и другие руководители.
Отмечу, что я верю, что существуют компании, где на какой-то период из этого правила было исключение и компания работала успешно и эффективно. Вопрос этого периода и того, что сложно воспроизвести такой результат. Итак вопросы, на которые вам надо найти ответы при работе команды:
1. Найм людей;
2. Удержание людей;
3. Работа с мотивацией и повышениями;
4. Оценка адекватности называемых сроков;
5. Оценка качества работы;
6. Стратегическое развитие технической части проектов;
7. Технологический стек;
8. Споры в командах ;
9. Закрытие вопросов безопасности;
10. Работа с качеством поставок функционала;
11. Обеспечение отказоустойчивости;
12. И т.д. и т.п.
В целом, если сотрудник один, то он обычно и сам себе режиссер. Но остается много вопросов с тем, что делать, когда он уйдет. Обычно в небольших компаниях кто-то в руководстве или один из учредителей обладает инженерной компетенцией и является СТО, это по сути, в таких масштабах, и делает его руководителем технической команды. Но если его нет, то на все вопросы отвечать придется собственнику или ответственному за бизнес.
А если людей больше, то все очень быстро перестает работать. Достигать согласованности решений и проводить оценку качества все равно кто-то должен. В компании у вас должен быть как минимум один технический руководитель, на которого вы можете положиться, в малых масштабах это руководитель команды-СТО, дальше, с ростом, это будет полноценная управленческая позиция.
Я не говорю, что выделил руководителя и все разработало, это даже близко не так. Я говорю, что есть много задач, которые нужно делать и логичнее и правильнее их погрузить в руководителя команды (отдела).
Если у вас есть сложность с поиском исполнителей или формированием команды разработки, вы всегда можете обратиться за помощью к нашей команде. Просто опишите свою проблему через нашего бота, почту info@oros-it.ru или форму на сайте, мы ответим вам в ближайшее время и предложим варианты решения.
Максим Шаламов
#руководителю #бизнес #управлениекомандой #разработка #ит #менеджмент