Даже те, кто отлично пишет постановку задач, забывает об этом
У меня были коллеги PO, которые хорошо ставили задачи. Это правда редкость, и такое нужно ценить. Но даже для них есть одна вещь, которую вообще на практике почти невозможно встретить. А ведь это один из ключевых способов гарантировать, что до пользователя дойдет функционал именно в том виде, который был задуман.
Если вы хотите получить точное выполнение функционала, то мало просто описать, что вы хотите увидеть в задаче. Нужно ещё подумать о том, как эту задачу принять, чтобы удостовериться, что функционал действительно удовлетворяет всем требованиям. И как раз это почти все забывают сделать на практике. В итоге, задачи принимаются "на глазок", а потом оказывается, что самое главное та и сделать забыли и проверить, что оно сделано не подумали.
Как же этого избежать? Думайте уже при постановке задачи, как вы будете ее принимать. Как именно это делать, мы подробно рассказываем в руководстве по описанию задач. Там вы научитесь прямо идеальному, правильному варианту, который гарантирует, что задача не дойдет до пользователя, если исполнитель что-то упустит при разработке. Обязательно научитесь это делать, если хотите добиться точного выполнения своих задач от любых исполнителей, будь то ваш подчиненный или коллега из соседнего отдела.
Александра Шаламова
#agile_который_работает
У меня были коллеги PO, которые хорошо ставили задачи. Это правда редкость, и такое нужно ценить. Но даже для них есть одна вещь, которую вообще на практике почти невозможно встретить. А ведь это один из ключевых способов гарантировать, что до пользователя дойдет функционал именно в том виде, который был задуман.
Если вы хотите получить точное выполнение функционала, то мало просто описать, что вы хотите увидеть в задаче. Нужно ещё подумать о том, как эту задачу принять, чтобы удостовериться, что функционал действительно удовлетворяет всем требованиям. И как раз это почти все забывают сделать на практике. В итоге, задачи принимаются "на глазок", а потом оказывается, что самое главное та и сделать забыли и проверить, что оно сделано не подумали.
Как же этого избежать? Думайте уже при постановке задачи, как вы будете ее принимать. Как именно это делать, мы подробно рассказываем в руководстве по описанию задач. Там вы научитесь прямо идеальному, правильному варианту, который гарантирует, что задача не дойдет до пользователя, если исполнитель что-то упустит при разработке. Обязательно научитесь это делать, если хотите добиться точного выполнения своих задач от любых исполнителей, будь то ваш подчиненный или коллега из соседнего отдела.
Александра Шаламова
#agile_который_работает
Как я не позволял подчиненным совершать ошибки и что из этого вышло
Откуда идет большая часть желания все проверить или сделать за своих сотрудников? От страха ошибки. Особенно это распространено у начинающих руководителей, но кто-то живет с этим всю свою карьеру. Вы боитесь ошибок своих людей, потому что считаете это своей ошибкой. Но даже если этот страх преодолевается, дальше идет череда ситуаций пока люди учатся и набираются опыта. Они ошибаются и ошибаются часто, поэтому соблазн сделать что-то за них слишком велик. И в краткосрочной перспективе это дает вам результат. Многие удивляются, я же сделал, задача решена в чем проблема? А проблема в том, что ошибки учат людей лучше всего. Это самый яркий и ценный опыт. Лишая его, вы забираете у людей самый лучший способ учиться. Второе следствие ваших действия это то, что люди будут терять веру в себя и мотивацию что-то делать. Никому не нравится, когда за каждым шагом следят и не дают развернуться. Так же люди привыкают, что проблемы за них решат и подстрахуют, и со временем на вас будет все больше и больше работы.
На самом деле очевидно, что не всегда можно дать ошибиться, где-то цена ошибки слишком велика. Или действие новое для всех и вы все вместе учитесь и решаете проблемы. Поиск баланса происходит постоянно. Работая техдиректором в ТАСС, я тоже понял, что слишком опекал свою команду и мои лиды не понимали реалии работы в компании и много где не могли помочь. Со временем слишком много текучки скопилось в одних руках и это стало огромной проблемой, не только в плане скорости работы, но и в собственной мотивации заниматься этим. Поэтому вкладываясь в рост команды, давая ошибаться вы решаете свою проблему, проблему того, что все решения и вся рутина упадут на вас и вы просто не сможете или не захотите этим всем заниматься.
Больше о том, как правильно работать с командой, ищите в нашем учебнике для руководителей.
Максим Шаламов
#руководителю
Откуда идет большая часть желания все проверить или сделать за своих сотрудников? От страха ошибки. Особенно это распространено у начинающих руководителей, но кто-то живет с этим всю свою карьеру. Вы боитесь ошибок своих людей, потому что считаете это своей ошибкой. Но даже если этот страх преодолевается, дальше идет череда ситуаций пока люди учатся и набираются опыта. Они ошибаются и ошибаются часто, поэтому соблазн сделать что-то за них слишком велик. И в краткосрочной перспективе это дает вам результат. Многие удивляются, я же сделал, задача решена в чем проблема? А проблема в том, что ошибки учат людей лучше всего. Это самый яркий и ценный опыт. Лишая его, вы забираете у людей самый лучший способ учиться. Второе следствие ваших действия это то, что люди будут терять веру в себя и мотивацию что-то делать. Никому не нравится, когда за каждым шагом следят и не дают развернуться. Так же люди привыкают, что проблемы за них решат и подстрахуют, и со временем на вас будет все больше и больше работы.
На самом деле очевидно, что не всегда можно дать ошибиться, где-то цена ошибки слишком велика. Или действие новое для всех и вы все вместе учитесь и решаете проблемы. Поиск баланса происходит постоянно. Работая техдиректором в ТАСС, я тоже понял, что слишком опекал свою команду и мои лиды не понимали реалии работы в компании и много где не могли помочь. Со временем слишком много текучки скопилось в одних руках и это стало огромной проблемой, не только в плане скорости работы, но и в собственной мотивации заниматься этим. Поэтому вкладываясь в рост команды, давая ошибаться вы решаете свою проблему, проблему того, что все решения и вся рутина упадут на вас и вы просто не сможете или не захотите этим всем заниматься.
Больше о том, как правильно работать с командой, ищите в нашем учебнике для руководителей.
Максим Шаламов
#руководителю
А сами исполнители умеют описывать задачи?
Я заикнулась в прошлый раз, что разработке, да и любым исполнителям или тем, кто когда-то работал исполнителем, может казаться, что они на отлично умеют описывать задачи, потому что постоянно сталкиваются с проблемами в описании задач и знают, что нужно. А вот как бы не так!
Одно дело знать, чего тебе не хватает, а другое самому описать так, чтобы всего хватало исполнителю. Я столкнулась с этой проблемой больше всего, когда занялась разработкой собственных проектов и перелезла в шкуру бизнес-заказчика. На первом же серьезном заказе дизайна для проекта я облажалась в написании ТЗ везде, где только можно. Многим разработчикам иногда приходят задачи от коллег из соседнего отдела, таких же разработчиков, в которых вообще ничего не понятно. Так почему же даже опытные исполнители не всегда хорошо описывают задачи?
Исполнители также забывают нюансы, как и все. Только если бизнес может о них не знать, то разработчик забывает потому что для него это все уже кажется очевидным.
В моем случае самый типовой пример - авторизация. Я про нее забываю буквально в каждом проекте. Я ее сама сто раз делала, но я о ней просто не помню, потому что она сбоку от основного функционала. Когда ты думаешь о проекте, ты всегда сосредоточен на главной задаче, главной функции. А потом ловишь себя на том, что забыл описать, как пользователь в этой главной функции вообще оказался.
И эта проблема исчезает только тогда, когда ты начинаешь мыслить пользовательскими путями. Именно поэтому в нашем руководстве по описанию задач мы начинаем именно с умения использовать пользовательские пути в описании задач. Это лучший способ ничего не забыть. Так что, если вы описываете задачи, пусть даже технические, какого бы опыта разработки у вас не было, все равно этому придется отдельно учиться.
Александра Шаламова
#agile_который_работает
Я заикнулась в прошлый раз, что разработке, да и любым исполнителям или тем, кто когда-то работал исполнителем, может казаться, что они на отлично умеют описывать задачи, потому что постоянно сталкиваются с проблемами в описании задач и знают, что нужно. А вот как бы не так!
Одно дело знать, чего тебе не хватает, а другое самому описать так, чтобы всего хватало исполнителю. Я столкнулась с этой проблемой больше всего, когда занялась разработкой собственных проектов и перелезла в шкуру бизнес-заказчика. На первом же серьезном заказе дизайна для проекта я облажалась в написании ТЗ везде, где только можно. Многим разработчикам иногда приходят задачи от коллег из соседнего отдела, таких же разработчиков, в которых вообще ничего не понятно. Так почему же даже опытные исполнители не всегда хорошо описывают задачи?
Исполнители также забывают нюансы, как и все. Только если бизнес может о них не знать, то разработчик забывает потому что для него это все уже кажется очевидным.
В моем случае самый типовой пример - авторизация. Я про нее забываю буквально в каждом проекте. Я ее сама сто раз делала, но я о ней просто не помню, потому что она сбоку от основного функционала. Когда ты думаешь о проекте, ты всегда сосредоточен на главной задаче, главной функции. А потом ловишь себя на том, что забыл описать, как пользователь в этой главной функции вообще оказался.
И эта проблема исчезает только тогда, когда ты начинаешь мыслить пользовательскими путями. Именно поэтому в нашем руководстве по описанию задач мы начинаем именно с умения использовать пользовательские пути в описании задач. Это лучший способ ничего не забыть. Так что, если вы описываете задачи, пусть даже технические, какого бы опыта разработки у вас не было, все равно этому придется отдельно учиться.
Александра Шаламова
#agile_который_работает
Должны ли все сотрудники мыслить, как руководитель?
История про то, что сотрудники не мыслят, как руководитель, гложет многих управленцев. Многие руководители настолько убивают инициативу или так напирают, что все просто повторяют их слова, и это тоже считается достижением. Я же считаю, что ваша команда должна обогащать и дополнять вас. Вы итак уже есть, от команды вам нужны дополнительные идеи, эмоции, подходы. Помимо этого вам нужно, чтобы люди могли решать задачи самостоятельно, а не ждать пока вы напишите или перепишите инструкцию.
Но чтобы это работало, нужно учесть несколько важных моментов.
Первое, вы должны уважать и ценить своих людей, считаться с их мнением, даже если вы с этим мнением в итоге не согласитесь. Слушайте своих сотрудников, старайтесь при прочих равных выбрать их способ решения, чтобы повысить их мотивацию.
Четкое описывайте рамки, за которые нельзя выходить, и четко формулируйте цели, к которым нужно прийти. Все остальное должно отдаваться на откуп сотрудников их опыта и креатива. Естественно вы постоянно будете корректировать рамки и цели, без этого никак. Зато будет и общее видение и достаточно свободы для развития и самореализации команды.
И самое главное, ваше слово должно быть решающим. Да у всех свое мнение и видение. Вы всех послушали, но принимаете решение в итоге именно вы. И ваша команда должна это принимать, как должное, и не пытаться работать в обход.
Плюсом к последнему идет то, что вы также, как и все в команде, работаете по договоренностям. Чью бы идею вы не выбрали, свою или чужую, пока вы не приняли и не донесли до всех изменения, вы тоже работаете по заданным правилам. Нет ничего разрушительнее при попытке наладить работу, чем демонстративно показывать, что вы выше своих же слов и договоренностей.
В работе с командой есть очень много нюансов и сложностей. Если вы столкнулись с проблемой в вашем ИТ-отделе, которую решить самостоятельно не получается, то вы можете обратиться к нам за личной консультацией через нашего бота или форму на сайте.
Максим Шаламов
#руководителю
История про то, что сотрудники не мыслят, как руководитель, гложет многих управленцев. Многие руководители настолько убивают инициативу или так напирают, что все просто повторяют их слова, и это тоже считается достижением. Я же считаю, что ваша команда должна обогащать и дополнять вас. Вы итак уже есть, от команды вам нужны дополнительные идеи, эмоции, подходы. Помимо этого вам нужно, чтобы люди могли решать задачи самостоятельно, а не ждать пока вы напишите или перепишите инструкцию.
Но чтобы это работало, нужно учесть несколько важных моментов.
Первое, вы должны уважать и ценить своих людей, считаться с их мнением, даже если вы с этим мнением в итоге не согласитесь. Слушайте своих сотрудников, старайтесь при прочих равных выбрать их способ решения, чтобы повысить их мотивацию.
Четкое описывайте рамки, за которые нельзя выходить, и четко формулируйте цели, к которым нужно прийти. Все остальное должно отдаваться на откуп сотрудников их опыта и креатива. Естественно вы постоянно будете корректировать рамки и цели, без этого никак. Зато будет и общее видение и достаточно свободы для развития и самореализации команды.
И самое главное, ваше слово должно быть решающим. Да у всех свое мнение и видение. Вы всех послушали, но принимаете решение в итоге именно вы. И ваша команда должна это принимать, как должное, и не пытаться работать в обход.
Плюсом к последнему идет то, что вы также, как и все в команде, работаете по договоренностям. Чью бы идею вы не выбрали, свою или чужую, пока вы не приняли и не донесли до всех изменения, вы тоже работаете по заданным правилам. Нет ничего разрушительнее при попытке наладить работу, чем демонстративно показывать, что вы выше своих же слов и договоренностей.
В работе с командой есть очень много нюансов и сложностей. Если вы столкнулись с проблемой в вашем ИТ-отделе, которую решить самостоятельно не получается, то вы можете обратиться к нам за личной консультацией через нашего бота или форму на сайте.
Максим Шаламов
#руководителю
Почему разработчики задают столько вопросов
На прошлой неделе я заказала разработку нашего нового проекта у команды разработчиков. И началось... Бесконечные вопросы, уточнения, согласования и тому подобное. В таком формате заниматься собственными задачами становится практически невозможно. Приходится постоянно переключаться, разбираться, что от тебя хотят, вспоминать, что ты сам вообще хотел сделать, потому что ТЗ было написано 3 месяца назад и ты уже не помнишь, что и почему ты там написал.
Я много писала последнее время про описание задач, что это дает, почему это сложно, как этому научиться и какие преимущества можно получить. И могу добавить, что оно также уменьшает количество вопросов разработчиков к вам уже в процессе выполнения задачи. Но почему же я сама погрязла в уйме вопросов от разработчиков, если знаю, как хорошо описывать задачи? Потому что в случае вопросов разработчиков одного хорошего описания недостаточно.
Я уже говорила, что разработка иначе смотрит на систему, потому что у нее другой набор знаний, более глубокий в технической области. И даже разработчики из другой сферы не смогут предсказать многие проблемы во время разработки в незнакомой им среде. И даже в чужом проекте на тех же технологиях. Везде есть своя специфика. Разработчик, смотря на задачу, видит вопросы более глубокие, касающиеся реализации и технических нюансов разработки. Этой информации просто не может быть в изначальном описании задачи. Автор просто не знает таких нюансов. Так что же получается, невозможно избавиться от постоянных, бесконтрольных вопросов во время разработки?
Здесь вам на помощь приходят процессы. Не просто так в большинстве компаний есть регулярные встречи по уточнению бэклога и оценке. Именно они помогают бизнесу дополнить описания задач с участием разработки, чтобы заранее, в специально отведенное для этого время, решить все вопросы разработки и доработать задачи с учетом этих вопросов. Как проводить такие встречи мы подробно разбираем в нашей книге по построению процессов работы команды "Гибкие методологии на практике". Научившись правильно работать по этим процессам, вы освободите свое время и до минимума сократите количество потока бесконечных вопросов от команды.
Александра Шаламова
#agile_который_работает
На прошлой неделе я заказала разработку нашего нового проекта у команды разработчиков. И началось... Бесконечные вопросы, уточнения, согласования и тому подобное. В таком формате заниматься собственными задачами становится практически невозможно. Приходится постоянно переключаться, разбираться, что от тебя хотят, вспоминать, что ты сам вообще хотел сделать, потому что ТЗ было написано 3 месяца назад и ты уже не помнишь, что и почему ты там написал.
Я много писала последнее время про описание задач, что это дает, почему это сложно, как этому научиться и какие преимущества можно получить. И могу добавить, что оно также уменьшает количество вопросов разработчиков к вам уже в процессе выполнения задачи. Но почему же я сама погрязла в уйме вопросов от разработчиков, если знаю, как хорошо описывать задачи? Потому что в случае вопросов разработчиков одного хорошего описания недостаточно.
Я уже говорила, что разработка иначе смотрит на систему, потому что у нее другой набор знаний, более глубокий в технической области. И даже разработчики из другой сферы не смогут предсказать многие проблемы во время разработки в незнакомой им среде. И даже в чужом проекте на тех же технологиях. Везде есть своя специфика. Разработчик, смотря на задачу, видит вопросы более глубокие, касающиеся реализации и технических нюансов разработки. Этой информации просто не может быть в изначальном описании задачи. Автор просто не знает таких нюансов. Так что же получается, невозможно избавиться от постоянных, бесконтрольных вопросов во время разработки?
Здесь вам на помощь приходят процессы. Не просто так в большинстве компаний есть регулярные встречи по уточнению бэклога и оценке. Именно они помогают бизнесу дополнить описания задач с участием разработки, чтобы заранее, в специально отведенное для этого время, решить все вопросы разработки и доработать задачи с учетом этих вопросов. Как проводить такие встречи мы подробно разбираем в нашей книге по построению процессов работы команды "Гибкие методологии на практике". Научившись правильно работать по этим процессам, вы освободите свое время и до минимума сократите количество потока бесконечных вопросов от команды.
Александра Шаламова
#agile_который_работает
Как я облажалась в описании задачи
Я в прошлом посте рассказывала, как я получила кучу вопросов от разработчиков по моему ТЗ. И хочу поделиться с вами самым большим моим провалом среди этих вопросов. Как пример того, что все продумать невозможно и ошибки все рано будут случаться. Главное их видеть и думать, как избежать их в будущем.
Итак, приложение с прохождением чего-то вроде опросника, где динамически меняются вопросы в зависимости от ответов пользователя. Дизайнер нарисовал внизу классическую нумерацию шагов "шаг 3/6", мне показалось это логичным, поэтому я внесла это в ТЗ. Во время разработки мне пишет менеджер с просьбой внести в АПИ количество вопросов в каждом опроснике. Я начинаю объяснять, что количество вопросов динамическое и зависит от ответов пользователя. На что он мне присылает этот скриншот с комментарием, что посчитать финальное количество шагов в динамическом опросе невозможно 🤦🏼♀️
Лучше всего конечно такие нюансы всплывают во время разработки, когда ты уже в контексте и думаешь, как именно будет реализована задача. С другой стороны дизайн уже отрисован и изменения приходится вносить буквально на ходу. И не всегда это получается делать гладко и без доработок. Поэтому такие ошибки иногда могут встать поперек горла. Поэтому стоит учиться описывать задачи как можно точнее.
А какие у вас были недочеты в описании задач? Забывали что-нибудь критичное? Или вам приходил запрос сделать что-то невозможное? Делитесь в комментариях.
Александра Шаламова
Я в прошлом посте рассказывала, как я получила кучу вопросов от разработчиков по моему ТЗ. И хочу поделиться с вами самым большим моим провалом среди этих вопросов. Как пример того, что все продумать невозможно и ошибки все рано будут случаться. Главное их видеть и думать, как избежать их в будущем.
Итак, приложение с прохождением чего-то вроде опросника, где динамически меняются вопросы в зависимости от ответов пользователя. Дизайнер нарисовал внизу классическую нумерацию шагов "шаг 3/6", мне показалось это логичным, поэтому я внесла это в ТЗ. Во время разработки мне пишет менеджер с просьбой внести в АПИ количество вопросов в каждом опроснике. Я начинаю объяснять, что количество вопросов динамическое и зависит от ответов пользователя. На что он мне присылает этот скриншот с комментарием, что посчитать финальное количество шагов в динамическом опросе невозможно 🤦🏼♀️
Лучше всего конечно такие нюансы всплывают во время разработки, когда ты уже в контексте и думаешь, как именно будет реализована задача. С другой стороны дизайн уже отрисован и изменения приходится вносить буквально на ходу. И не всегда это получается делать гладко и без доработок. Поэтому такие ошибки иногда могут встать поперек горла. Поэтому стоит учиться описывать задачи как можно точнее.
А какие у вас были недочеты в описании задач? Забывали что-нибудь критичное? Или вам приходил запрос сделать что-то невозможное? Делитесь в комментариях.
Александра Шаламова
Полная переделка проекта - камень преткновения на старых проектах
В большинстве старых, больших проектов есть две силы: разработка, которая хочет все переписать, и бизнес, который ни в коем случае не хочет этого допустить. Кто прав? Давайте разбираться.
Почему разработка все время хочет все переписать
Сразу развеем один распространенный миф. Среди многих бизнес команд бытует мнение, что IT команде совсем не интересен продукт, - это не так. Все любят делать проект для людей, чтобы им пользовались и чтобы он приносил пользу. Ничего так не демотивирует команду, как задачи сделанные “в стол”.
Но несмотря на это, IT команда отвечает за работоспособность проекта и занимается кодовой базой проекта каждый рабочий день, большую часть своего рабочего времени. Поэтому качество и удовлетворенность от работы с кодовой базой проекта со временем перевесят все крутые фичи, которые можно выпустить. Мотивация от работы с запущенным кодом быстро падает и начинается текучка. Об этом нужно помнить всем участникам команды, так как страдает от этого не только техническая часть проекта, но и продуктовая.
Бывает, что проект большой и старый, и некоторые его части остались без документации, а разработчиков, которые делали эту часть или хотя бы помнят, что в ней происходит, в компании уже не осталось. Тогда с этим кодом тоже становится очень сложно работать и проще эту часть написать заново, с документацией и по новым стандартам компании, чтобы любой участник команды мог с ним работать.
Еще одна проблема - на устаревшей кодовой базе становится все сложнее делать новый функционал, возрастает вероятность ошибок, сложнее вводить в проект новых людей. Работа идет все медленнее, команду начинают критиковать за падение производительности и требовать ускорится. Но устаревший код не позволяет этого сделать. И желание все переделать здесь совершенно понятно.
Почему бизнес сопротивляется
Бизнес при этом не видит каждый день тех проблем в коде, которые видит разработка. У него все идет, как обычно, возможно задачи стали делаться чуть дольше, возможно ошибок на проекте стало больше, может немного текучка разработки увеличилась, но это все бывает и по другим причинам. Однако, чаще всего, сам продукт работает, как обычно (если проблемы с кодом не сказываются на производительности проекта). Он приносит деньги, приходят пользователи, клиенты, идут продажи. Есть много планов на будущее, которые хочется реализовать. А самое главное, есть конкуренты, которые постоянно дышат в затылок и стараются обойти.
И тут приходит разработка и говорит, что надо все срочно останавливать и переписывать проект с нуля ближайшие полгода - год. Если разработка видит после переписывания удобно отлаженный проект, то бизнес видит потерю позиций на рынке, падение прибыли, а может быть и полное банкротство, потому что конкуренты за этот год уйдут так далеко вперед, что догнать их может уже не получится. Желание тут же категорически отказаться тоже вполне понятно.
Так кто же прав?
Все зависит от ситуации на конкретном проекте. Бывают случаи, когда разработка слишком спешит и предлагает слишком радикальные меры. А бывает, что проект действительно нужно срочно спасать, иначе никакая конкурентоспособность на рынке ему не светит уже по причине полной потери работоспособности. Как решить, что делать конкретно вам, расскажем в следующих постах.
А если вам срочно нужна помощь, чтобы решить, что делать с вашим проектом прямо сейчас, то вы можете записаться к нам на консультацию через бота или форму на сайте.
В большинстве старых, больших проектов есть две силы: разработка, которая хочет все переписать, и бизнес, который ни в коем случае не хочет этого допустить. Кто прав? Давайте разбираться.
Почему разработка все время хочет все переписать
Сразу развеем один распространенный миф. Среди многих бизнес команд бытует мнение, что IT команде совсем не интересен продукт, - это не так. Все любят делать проект для людей, чтобы им пользовались и чтобы он приносил пользу. Ничего так не демотивирует команду, как задачи сделанные “в стол”.
Но несмотря на это, IT команда отвечает за работоспособность проекта и занимается кодовой базой проекта каждый рабочий день, большую часть своего рабочего времени. Поэтому качество и удовлетворенность от работы с кодовой базой проекта со временем перевесят все крутые фичи, которые можно выпустить. Мотивация от работы с запущенным кодом быстро падает и начинается текучка. Об этом нужно помнить всем участникам команды, так как страдает от этого не только техническая часть проекта, но и продуктовая.
Бывает, что проект большой и старый, и некоторые его части остались без документации, а разработчиков, которые делали эту часть или хотя бы помнят, что в ней происходит, в компании уже не осталось. Тогда с этим кодом тоже становится очень сложно работать и проще эту часть написать заново, с документацией и по новым стандартам компании, чтобы любой участник команды мог с ним работать.
Еще одна проблема - на устаревшей кодовой базе становится все сложнее делать новый функционал, возрастает вероятность ошибок, сложнее вводить в проект новых людей. Работа идет все медленнее, команду начинают критиковать за падение производительности и требовать ускорится. Но устаревший код не позволяет этого сделать. И желание все переделать здесь совершенно понятно.
Почему бизнес сопротивляется
Бизнес при этом не видит каждый день тех проблем в коде, которые видит разработка. У него все идет, как обычно, возможно задачи стали делаться чуть дольше, возможно ошибок на проекте стало больше, может немного текучка разработки увеличилась, но это все бывает и по другим причинам. Однако, чаще всего, сам продукт работает, как обычно (если проблемы с кодом не сказываются на производительности проекта). Он приносит деньги, приходят пользователи, клиенты, идут продажи. Есть много планов на будущее, которые хочется реализовать. А самое главное, есть конкуренты, которые постоянно дышат в затылок и стараются обойти.
И тут приходит разработка и говорит, что надо все срочно останавливать и переписывать проект с нуля ближайшие полгода - год. Если разработка видит после переписывания удобно отлаженный проект, то бизнес видит потерю позиций на рынке, падение прибыли, а может быть и полное банкротство, потому что конкуренты за этот год уйдут так далеко вперед, что догнать их может уже не получится. Желание тут же категорически отказаться тоже вполне понятно.
Так кто же прав?
Все зависит от ситуации на конкретном проекте. Бывают случаи, когда разработка слишком спешит и предлагает слишком радикальные меры. А бывает, что проект действительно нужно срочно спасать, иначе никакая конкурентоспособность на рынке ему не светит уже по причине полной потери работоспособности. Как решить, что делать конкретно вам, расскажем в следующих постах.
А если вам срочно нужна помощь, чтобы решить, что делать с вашим проектом прямо сейчас, то вы можете записаться к нам на консультацию через бота или форму на сайте.
Как решить стоит ли переписывать проект?
Итак, в один прекрасный день, когда вы думали, что у вас на проекте все хорошо, к вам приходит разработка и говорит: шеф, все пропало, скоро проект перестанет работать, срочно нужно все переписать. Что же делать? Как решить соглашаться или нет?
Для представителей бизнес команд хочется дать совет, который позволит не только сохранить сильную и мотивированную команду, но и позволит не завести проект в тупик в техническом плане. Не упирайтесь при словах рефакторинг и переписывание кода, это абсолютно нормальный процесс. Рынок постоянно меняется, проекту нужно за ним успевать, поэтому и код постоянно меняется и дорабатывается, и архитектуру на годы вперед продумать невозможно. В таком режиме работы, иногда нужно приводить проект в порядок. Иногда нужен легкий рефакторинг, а иногда надо решиться и на полную переделку, пока не стало хуже.
Но как понять, не перегибает ли команда палку? Требуйте показать понятные метрики, которые доказывают проблемы на проекте, формулируйте свои приоритеты и потребности в плане метрик, обсуждайте, как вы этого достигнете и какими ресурсами. Если вы убедились, что важные для вас метрики правда проседают, значит проекту действительно нужен рефакторинг. После проведенной работы над проектом обязательно проверяйте достижение нужных показателей. Помните, что вы одна команда и плохо работающий проект не позволит вам развивать продукт не в меньшей степени, чем вашей IT команде.
Метрики, как обязательная составляющая рефакторинга
Первое, что вам нужно сделать, когда вы начали обсуждать изменения в проекте - определить и настроить метрики. Нельзя подходить к вопросу о глобальном рефакторинге или отказе от него без метрик. Метрики могут быть, как влияющими на бизнес на прямую, например баги, t2m и скорость работы проекта. Так и косвенно влияющие на бизнес составляющую: скорость погружения сотрудников в проект, количество человек владеющих кодовой базой, уровень дублирования кода (а порой и сервисов), количество возвратов PR (пулл реквестов) и т.д. На самом деле, все эти метрики влияют на качество продукта. Те, что кажутся косвенными, обычно приводят к большой текучке и вымыванию сильных разработчиков из команды, что замедляет выпуск нового функционала и напрямую влияет на отказоустойчивость и общее качество продукта.
Именно метрики помогут вам понять и необходимость рефакторинга на проекте и то, насколько удачным получился результат. Также не забывайте в процессе отслеживать метрики работы команды, чтобы понимать насколько удачно проходят работы и движетесь ли вы с нужной скоростью. Подробной работе с метриками команды вы можете научиться с помощью нашей книги "Гибкие методологии на практике". Такое умение пригодится вам и в любое другое время работы над проектом. Это вообще обязательные знания для любого, кто работает с ИТ-проектами.
Итак, в один прекрасный день, когда вы думали, что у вас на проекте все хорошо, к вам приходит разработка и говорит: шеф, все пропало, скоро проект перестанет работать, срочно нужно все переписать. Что же делать? Как решить соглашаться или нет?
Для представителей бизнес команд хочется дать совет, который позволит не только сохранить сильную и мотивированную команду, но и позволит не завести проект в тупик в техническом плане. Не упирайтесь при словах рефакторинг и переписывание кода, это абсолютно нормальный процесс. Рынок постоянно меняется, проекту нужно за ним успевать, поэтому и код постоянно меняется и дорабатывается, и архитектуру на годы вперед продумать невозможно. В таком режиме работы, иногда нужно приводить проект в порядок. Иногда нужен легкий рефакторинг, а иногда надо решиться и на полную переделку, пока не стало хуже.
Но как понять, не перегибает ли команда палку? Требуйте показать понятные метрики, которые доказывают проблемы на проекте, формулируйте свои приоритеты и потребности в плане метрик, обсуждайте, как вы этого достигнете и какими ресурсами. Если вы убедились, что важные для вас метрики правда проседают, значит проекту действительно нужен рефакторинг. После проведенной работы над проектом обязательно проверяйте достижение нужных показателей. Помните, что вы одна команда и плохо работающий проект не позволит вам развивать продукт не в меньшей степени, чем вашей IT команде.
Метрики, как обязательная составляющая рефакторинга
Первое, что вам нужно сделать, когда вы начали обсуждать изменения в проекте - определить и настроить метрики. Нельзя подходить к вопросу о глобальном рефакторинге или отказе от него без метрик. Метрики могут быть, как влияющими на бизнес на прямую, например баги, t2m и скорость работы проекта. Так и косвенно влияющие на бизнес составляющую: скорость погружения сотрудников в проект, количество человек владеющих кодовой базой, уровень дублирования кода (а порой и сервисов), количество возвратов PR (пулл реквестов) и т.д. На самом деле, все эти метрики влияют на качество продукта. Те, что кажутся косвенными, обычно приводят к большой текучке и вымыванию сильных разработчиков из команды, что замедляет выпуск нового функционала и напрямую влияет на отказоустойчивость и общее качество продукта.
Именно метрики помогут вам понять и необходимость рефакторинга на проекте и то, насколько удачным получился результат. Также не забывайте в процессе отслеживать метрики работы команды, чтобы понимать насколько удачно проходят работы и движетесь ли вы с нужной скоростью. Подробной работе с метриками команды вы можете научиться с помощью нашей книги "Гибкие методологии на практике". Такое умение пригодится вам и в любое другое время работы над проектом. Это вообще обязательные знания для любого, кто работает с ИТ-проектами.
Как правильно говорить о рефакторинге с бизнесом со стороны IT команды
Инициаторами рефакторинга должна быть IT команда, поэтому ее задача первым же делом инициировать сбор метрик на проекте, если они по какой-то причине не ведутся (а ведь они могли бы помочь раньше увидеть проблемы и не допускать тяжелой ситуации на проекте). Дальше нужно смотреть динамику этих метрик (например, рост числа багов, рост времени починки багов и т.д), вы должны увидеть, как ухудшается ваш проект в реальных значениях. После этого IT команда должна встретится с бизнес командой и обсудить с ними эти метрики и их изменение, узнать (если еще не узнали) рост каких метрик для бизнеса критичен и насколько (обычно говорят о t2m и багах). После чего нужно представить свой план рефакторинга, в котором обязательно должны быть:
- сроки. Без сроков на рефакторинг нет смысла даже начинать разговор;
- ресурсы. То есть, что и кто вам нужен для рефакторинга;
- потребность в остановке выпуска бизнес фич. В идеале фичи хоть какие-то выпускать нужно или договориться с бизнес командой будет очень сложно. Важно заранее продумать этот вопрос;
- на какие метрики и как повлияют работы по рефакторингу;
- какие запланированные шаги.
Если все разложить в таком ключе, то договориться с бизнесом о начале работ будет возможно. Скорее всего это потребует времени и терпения, но разговор с конкретными цифрами, сроками и ресурсами проще для понимания и несет минимум субъективности.
А если хотите еще лучше подготовиться, то обязательно пройдете наш мини-курс о том, как правильно общаться с PO и бизнес-командой в целом. Там мы как раз подробно разбираем, как наверняка доказать, что вашему проекту нужны технические улучшения. После использования такого подхода вам будет очень сложно отказать. Переходите к курсу по ссылке.
Инициаторами рефакторинга должна быть IT команда, поэтому ее задача первым же делом инициировать сбор метрик на проекте, если они по какой-то причине не ведутся (а ведь они могли бы помочь раньше увидеть проблемы и не допускать тяжелой ситуации на проекте). Дальше нужно смотреть динамику этих метрик (например, рост числа багов, рост времени починки багов и т.д), вы должны увидеть, как ухудшается ваш проект в реальных значениях. После этого IT команда должна встретится с бизнес командой и обсудить с ними эти метрики и их изменение, узнать (если еще не узнали) рост каких метрик для бизнеса критичен и насколько (обычно говорят о t2m и багах). После чего нужно представить свой план рефакторинга, в котором обязательно должны быть:
- сроки. Без сроков на рефакторинг нет смысла даже начинать разговор;
- ресурсы. То есть, что и кто вам нужен для рефакторинга;
- потребность в остановке выпуска бизнес фич. В идеале фичи хоть какие-то выпускать нужно или договориться с бизнес командой будет очень сложно. Важно заранее продумать этот вопрос;
- на какие метрики и как повлияют работы по рефакторингу;
- какие запланированные шаги.
Если все разложить в таком ключе, то договориться с бизнесом о начале работ будет возможно. Скорее всего это потребует времени и терпения, но разговор с конкретными цифрами, сроками и ресурсами проще для понимания и несет минимум субъективности.
А если хотите еще лучше подготовиться, то обязательно пройдете наш мини-курс о том, как правильно общаться с PO и бизнес-командой в целом. Там мы как раз подробно разбираем, как наверняка доказать, что вашему проекту нужны технические улучшения. После использования такого подхода вам будет очень сложно отказать. Переходите к курсу по ссылке.
Почему ты вечно все узнаешь последним?
Типичная история: отдаешь команде задачу, получаешь сроки готовности, запускаешь рекламную компанию со всеми датами, вливаешь туда уйму денег. А в день, когда функционал должен быть уже на проекте, узнаешь, что команда не смогла сделать задачу в полном объеме. Так что всего, что ты уже наобещал пользователям и партнерам у тебя на проекте не случилось. А самое главное, что именно тот, кто потом разбирается со всеми последствиями, узнает обо всем этом самым последним, когда сделать уже ничего нельзя. Почему так происходит?
Ответ очень простой. Если вы о чем-то узнаете последним, значит у вас в команде нет механизмов, которые позволили бы вам как можно раньше отследить приближающуюся катастрофу. У вас попросту не работают нужные процессы предупреждения рисков. Вы плывете по океану полному айсбергов без бинокля с завязанными глазами, надеясь, авось пронесет. В какой-то раз вы как-нибудь да выкрутитесь, но однажды, напоретесь на настоящую катастрофу, и узнаете об этом уже сидя на дне с разбитым проектом. А команда будет только разводить руками.
Почему команда сама не в состоянии предотвратить беду? Причин много, от того, что команда вообще знать не знает про ваши рекламные компании и внешние договоренности, поэтому не может определить, что это проблема, до того, что команда не знает, где и когда вас найти, чтобы о проблеме сообщить.
Первой реакцией многих руководителей будет желание в следующий раз следить получше и принимать полное участие в разработке, чтобы знать обо всем. Но есть же и свои дела, не так ли? К тому же это все равно не поможет. С микроменеджментом команда начинает работать еще хуже, чем до него.
На эту проблему есть только одно правильное решение, которое реально работает, - настроить хорошие процессы работы команды. Сюда будет входить и порядок взаимодействия с командой, и предупреждение рисков, и метрики, которые помогут отслеживать, как хорошо команда укладывается в сроки. Подробно, с самого начала про процессы мы рассказываем в нашей книге, но если времени на чтение у вас нет, а проблему надо решать прямо сейчас, то приходите на консультацию. Будем разбираться вместе.
Типичная история: отдаешь команде задачу, получаешь сроки готовности, запускаешь рекламную компанию со всеми датами, вливаешь туда уйму денег. А в день, когда функционал должен быть уже на проекте, узнаешь, что команда не смогла сделать задачу в полном объеме. Так что всего, что ты уже наобещал пользователям и партнерам у тебя на проекте не случилось. А самое главное, что именно тот, кто потом разбирается со всеми последствиями, узнает обо всем этом самым последним, когда сделать уже ничего нельзя. Почему так происходит?
Ответ очень простой. Если вы о чем-то узнаете последним, значит у вас в команде нет механизмов, которые позволили бы вам как можно раньше отследить приближающуюся катастрофу. У вас попросту не работают нужные процессы предупреждения рисков. Вы плывете по океану полному айсбергов без бинокля с завязанными глазами, надеясь, авось пронесет. В какой-то раз вы как-нибудь да выкрутитесь, но однажды, напоретесь на настоящую катастрофу, и узнаете об этом уже сидя на дне с разбитым проектом. А команда будет только разводить руками.
Почему команда сама не в состоянии предотвратить беду? Причин много, от того, что команда вообще знать не знает про ваши рекламные компании и внешние договоренности, поэтому не может определить, что это проблема, до того, что команда не знает, где и когда вас найти, чтобы о проблеме сообщить.
Первой реакцией многих руководителей будет желание в следующий раз следить получше и принимать полное участие в разработке, чтобы знать обо всем. Но есть же и свои дела, не так ли? К тому же это все равно не поможет. С микроменеджментом команда начинает работать еще хуже, чем до него.
На эту проблему есть только одно правильное решение, которое реально работает, - настроить хорошие процессы работы команды. Сюда будет входить и порядок взаимодействия с командой, и предупреждение рисков, и метрики, которые помогут отслеживать, как хорошо команда укладывается в сроки. Подробно, с самого начала про процессы мы рассказываем в нашей книге, но если времени на чтение у вас нет, а проблему надо решать прямо сейчас, то приходите на консультацию. Будем разбираться вместе.
Стоит ли давать свободу подчиненным
Очень частая тема сейчас про свободу действий, излишние правила и ограничения. Люди часто думают, что им не хватает свободы действий и, получив ее, они раскроются на полную.
Люди сами не знаю, что для них свобода
Во-первых, многие, требующие свободы, даже не понимают, что такое “более свободно” для них. Меня, как довольно требовательного руководителя, периодически просят давать больше свободы, но на вопрос, как это должно работать, конкретики почти никогда нет.
Свобода идет в комплекте с ответственностью
Главное, что я думаю о свободе действий и принятии решений - это то, что это большая ответственность, о чем многие даже не думают. Конечно здорово получить свободу действий: есть цель и ты дальше к ней идешь. Но ведь это должно включать в себя самостоятельное решение всех проблем, стоящих перед вами на пути. Иначе ни о какой самостоятельности речи быть не может.
А что на практике?
Многие, получив самостоятельность, все равно бегают по каждой сложной ситуации к руководителю или «радуют» тем, что задача не будет сделана в срок в последний момент. Поэтому эксперименты со свободой быстро заканчиваются.
Вообще, в реальности, многие не хотят никакой самостоятельности и будут бегать от этого, как только поймут цену вопроса. Поэтому надо всегда смотреть на людей, как они работают и справляются.
Мне очень повезло с текущим руководителем, который всегда старался давать мне максимум свободы в рамках моей зоны обязанностей, но взамен он ожидал и ожидает самостоятельного решения всех вопросов, которые я могу закрыть самостоятельно. Меня всегда это устраивало, я так максимально эффективно работаю. Я стараюсь искать таких же подчиненных, но таких единицы, и большая удача, что в моей команде они есть.
Как делаю я
По самостоятельности, я всегда понимаю, как надо идти к целям и результатам в рамках своих проектов и требую идти этим курсом и подчиненных. Когда я вижу, что человек справляется, то стараюсь перейти на работу через синки, постановку целей и обсуждение результатов (помогаю, когда человек сам не может, стараюсь учить). Я очень ценю людей, кто так умеет работать, но обычно они ничего не просят, а просто естественным образом получают необходимую свободу, справляясь со своей работой.
Больше о моих подходах в управлении командой, я рассказываю в своем учебнике для руководителей.
Максим Шаламов
#руководителю
Очень частая тема сейчас про свободу действий, излишние правила и ограничения. Люди часто думают, что им не хватает свободы действий и, получив ее, они раскроются на полную.
Люди сами не знаю, что для них свобода
Во-первых, многие, требующие свободы, даже не понимают, что такое “более свободно” для них. Меня, как довольно требовательного руководителя, периодически просят давать больше свободы, но на вопрос, как это должно работать, конкретики почти никогда нет.
Свобода идет в комплекте с ответственностью
Главное, что я думаю о свободе действий и принятии решений - это то, что это большая ответственность, о чем многие даже не думают. Конечно здорово получить свободу действий: есть цель и ты дальше к ней идешь. Но ведь это должно включать в себя самостоятельное решение всех проблем, стоящих перед вами на пути. Иначе ни о какой самостоятельности речи быть не может.
А что на практике?
Многие, получив самостоятельность, все равно бегают по каждой сложной ситуации к руководителю или «радуют» тем, что задача не будет сделана в срок в последний момент. Поэтому эксперименты со свободой быстро заканчиваются.
Вообще, в реальности, многие не хотят никакой самостоятельности и будут бегать от этого, как только поймут цену вопроса. Поэтому надо всегда смотреть на людей, как они работают и справляются.
Мне очень повезло с текущим руководителем, который всегда старался давать мне максимум свободы в рамках моей зоны обязанностей, но взамен он ожидал и ожидает самостоятельного решения всех вопросов, которые я могу закрыть самостоятельно. Меня всегда это устраивало, я так максимально эффективно работаю. Я стараюсь искать таких же подчиненных, но таких единицы, и большая удача, что в моей команде они есть.
Как делаю я
По самостоятельности, я всегда понимаю, как надо идти к целям и результатам в рамках своих проектов и требую идти этим курсом и подчиненных. Когда я вижу, что человек справляется, то стараюсь перейти на работу через синки, постановку целей и обсуждение результатов (помогаю, когда человек сам не может, стараюсь учить). Я очень ценю людей, кто так умеет работать, но обычно они ничего не просят, а просто естественным образом получают необходимую свободу, справляясь со своей работой.
Больше о моих подходах в управлении командой, я рассказываю в своем учебнике для руководителей.
Максим Шаламов
#руководителю
♟3 главных урока шахмат: как хобби помогает карьере
В школе я довольно плотно увлекался шахматами. Ретроспективно я понимаю, что это дало мне очень полезный опыт для работы над целями и своими недостатками.
Победа команды важнее твоего эго
Первое, что мне дали занятия шахматами это понимание, что общие (командные) цели важнее собственного эго, если в результате выиграет вся команда, включая тебя. У нас были городские и областные соревнования, в которых участвовало по 5 человек. Обычно людей ставили по силе от первой до пятой доски, но наш тренер всегда ставил людей для набора максимального количества очков, что в сумме и давало результат команды. Я стабильно играл за третьей доской, что довольно сильно меня раздражало, но результат был всегда высок и я почти не проигрывал. Команда наша занимала первое или второе место стабильно.
Считай до 10
Второй очень полезный урок до сих пор помогает мне в работе. По характеру я очень нетерпеливый и люблю всегда быстро принимать решения и быстро воплощать их в жизнь. Но многие ситуации в жизни требуют осмысления и взвешенного подхода. В шахматах это проявлялось в том, что я постоянно торопился и делал поспешные ходы, после чего попадал в трудные положения и уже после этого начинал думать. Выиграть получалось не всегда. Поэтому мой тренер заставил меня перед любым ходом засовывать руки под ноги, сидеть на них, считая до 10 и думать еще раз перед ходом. Так я научился брать паузу перед важными решениями.
Эмоциональная подготовка важна
Третий и очень важный урок, это эмоциональная подготовка, как бы не складывалась ситуация, ты должен держать удар, верить в успех и не давать другим усомниться в себе. На самом деле, я понял это на довольно непримечательной игре, которую тогда выиграл довольно легко. Но легко это было по результату. Девушка с которой я играл просто излучала уверенность в себе. Казалось, что она предвидит каждый ход и я делаю все, что она хочет. В ее случае это привело не со всем к тому, что она хотела. Я полностью собрался и максимально долго обдумывал каждый ход. В итоге игра шла часа 2, но я до сих пор помню тот эффект, который вызывало ее поведение.
Все, что я тогда приобрел от занятий, помогает мне в моей работе. Те, кто проходил наше обучение тому, как сделать свою ежедневную работу увлекательной, знают, как дополнительные инициативы мощно прокачивают не только ваши навыки, но и карьеру. Если осознанно подходить к своим занятиям, они могут дать много неожиданного опыта. Не упускайте этих возможностей.
Максим Шаламов
#советы
В школе я довольно плотно увлекался шахматами. Ретроспективно я понимаю, что это дало мне очень полезный опыт для работы над целями и своими недостатками.
Победа команды важнее твоего эго
Первое, что мне дали занятия шахматами это понимание, что общие (командные) цели важнее собственного эго, если в результате выиграет вся команда, включая тебя. У нас были городские и областные соревнования, в которых участвовало по 5 человек. Обычно людей ставили по силе от первой до пятой доски, но наш тренер всегда ставил людей для набора максимального количества очков, что в сумме и давало результат команды. Я стабильно играл за третьей доской, что довольно сильно меня раздражало, но результат был всегда высок и я почти не проигрывал. Команда наша занимала первое или второе место стабильно.
Считай до 10
Второй очень полезный урок до сих пор помогает мне в работе. По характеру я очень нетерпеливый и люблю всегда быстро принимать решения и быстро воплощать их в жизнь. Но многие ситуации в жизни требуют осмысления и взвешенного подхода. В шахматах это проявлялось в том, что я постоянно торопился и делал поспешные ходы, после чего попадал в трудные положения и уже после этого начинал думать. Выиграть получалось не всегда. Поэтому мой тренер заставил меня перед любым ходом засовывать руки под ноги, сидеть на них, считая до 10 и думать еще раз перед ходом. Так я научился брать паузу перед важными решениями.
Эмоциональная подготовка важна
Третий и очень важный урок, это эмоциональная подготовка, как бы не складывалась ситуация, ты должен держать удар, верить в успех и не давать другим усомниться в себе. На самом деле, я понял это на довольно непримечательной игре, которую тогда выиграл довольно легко. Но легко это было по результату. Девушка с которой я играл просто излучала уверенность в себе. Казалось, что она предвидит каждый ход и я делаю все, что она хочет. В ее случае это привело не со всем к тому, что она хотела. Я полностью собрался и максимально долго обдумывал каждый ход. В итоге игра шла часа 2, но я до сих пор помню тот эффект, который вызывало ее поведение.
Все, что я тогда приобрел от занятий, помогает мне в моей работе. Те, кто проходил наше обучение тому, как сделать свою ежедневную работу увлекательной, знают, как дополнительные инициативы мощно прокачивают не только ваши навыки, но и карьеру. Если осознанно подходить к своим занятиям, они могут дать много неожиданного опыта. Не упускайте этих возможностей.
Максим Шаламов
#советы
При отборе кандидатов в свои команды, помимо необходимых знаний и умений, одним из важнейших факторов, я считаю совместимость с командой. Расскажу, что такое совместимость и как ее определить на собеседовании.
Говоря о совместимости, я не имею в виду поиск похожих людей или какие-то сложно объяснимые материи. Под этим я понимаю то, насколько сложно или легко новому человеку будет в команде, и наоборот, насколько команде будет просто взаимодействовать с новичком. От этого зависит и скорость вливания человека в команду, и удовлетворенность нового сотрудника, и его желание или не желание работать и оставаться в компании. Также от этого зависит эффективность командного взаимодействия. Если неудачно подобрать людей, то вы получите море конфликтов по любому поводу, полное нежелание работать вместе и искать компромиссы. Да, при наличии времени, сил и желания, такие ситуации можно выправить, но скорее всего люди уйдут раньше, да и состояние вашего проекта будет вызывать вопросы, после работы над ним командой, которая ни о чем не может договориться.
Как определить совместимость с командой
Если совместимость так важна, как же понять, что вы выбираете правильного человека? Прежде всего вам нужно хорошо знать свою команду. Ответьте на следующие вопросы:
- какие люди в ней работают, интроверты/экстраверты, веселые, громкие, тихие и т.д.?
- как они привыкли работать, как они взаимодействуют друг с другом, открыто и прямолинейно или аккуратно и осмотрительно?
- как дают обратную связь?
- в каком релизном цикле живут?
- как работают с проблемами, багами, инцидентами?
Только понимая все это, вы сможете оценить впишется ли человек. Например, у меня в командах принято дружеское подшучивание над коллегами и вообще ценится юмор. Если у человека нет определенной самоиронии и спокойного отношения к шуткам, то ему будет крайне сложно адаптироваться. Блокер ли это само по себе для найма - обычно нет (хотя бывают очень плохо воспринимающие любые шутки люди, и для сохранения их нервной системы и нервов команды, стоит по возможности выбрать другого кандидата), но из мелочей должна сложиться картина, подойдете вы друг другу или нет. Хорошим примером может быть форма того, как дается и принимается обратная связь, допустим в моих командах принято давать ОС сразу, четко и прямолинейно (конечно без грубостей и переходов на личности). Как показала практика, не каждый человек готов к такому и не каждый человек хочет настолько прямо получать и давать ОС. Опять же, одна мелочь, но из суммы факторов вы поймете насколько вам по пути.
Что важно помнить на собеседовании
Для того, чтобы вы смогли оценить все это, на собеседовании вам нужно дойти с кандидатом до определенной точки обоюдного комфорта, чтобы вы просто смогли поговорить открыто. Постройте эту часть собеседования в виде диалога, где вы спрашиваете о том, как работал кандидат, как ему привычно работать и как бы ему хотелось работать с коллегами, задачами, процессами. Обязательно подробно рассказывайте о том, как принято в вашей команде и компании, следите за реакцией человека, спрашивайте его мнение о том, что вы рассказываете. К сожалению, я не знаю формулы, по которой можно математически оценить совместимость, но обычно, если вы проводите часть собеседования, нацеленную на совместимость в формате общения, в конце вы понимаете хотите работать с этим человеком или нет.
продолжение в следующем посте
Please open Telegram to view this post
VIEW IN TELEGRAM
⬆️ Что если все еще остались сомнения, совместим ли кандидат с командой
Если остаются сомнения, я советую выписать список плюсов человека: это и сильные профессиональные навыки, и личностные качества, которые вам понравились, а рядом выпишите список недостатков. Посмотрите перекрывают ли достоинства недостатки, а главное, знаете ли вы, как работать с недостатками человеками. Например, если в вашем стартапе кипит бурная деятельность, нужно рваться вперед всеми силами, а кандидат хорош технически, но привык очень размеренно и неспешно работать, вам нужно понять, сможете ли вы встроить человека в процессы, понимаете ли вы, как и обеспечить ему комфортное место работы и получить желаемый результат.
Больше о том, как работать с людьми и командой, смотрите в моем учебнике для руководителей технических команд.
Максим Шаламов
#руководителю
Если остаются сомнения, я советую выписать список плюсов человека: это и сильные профессиональные навыки, и личностные качества, которые вам понравились, а рядом выпишите список недостатков. Посмотрите перекрывают ли достоинства недостатки, а главное, знаете ли вы, как работать с недостатками человеками. Например, если в вашем стартапе кипит бурная деятельность, нужно рваться вперед всеми силами, а кандидат хорош технически, но привык очень размеренно и неспешно работать, вам нужно понять, сможете ли вы встроить человека в процессы, понимаете ли вы, как и обеспечить ему комфортное место работы и получить желаемый результат.
Больше о том, как работать с людьми и командой, смотрите в моем учебнике для руководителей технических команд.
Максим Шаламов
#руководителю
Почему задача обязательно должна быть маленькой
Одно из непременных условий задачи, которую команда с большей вероятностью сделает в сроки и без ошибок, является ее размер. Задача должна укладывать в одну рабочую итерацию, а лучше быть еще меньше. Зачем это нужно?
Гибкость
Преимущество, которое получает автор задачи. Если вы делите работу на мелкие части, то вы получаете больше возможностей ими жонглировать. Если вы дали в разработку большую задачу, то изменить ее без вмешательства в процесс разработки уже невозможно. А если вы отдали маленькую часть, то все остальные части, которые еще не в работе, вы еще можете менять.
Быстрее результат
Разбив задачи на много частей, вы можете (и должны) выбрать самые критичные из них и отправить их в работу в первую очередь. Так вы получите самый критичный функционала намного быстрее, чем если бы отдали в работу огромную задачу и ждали ее полного выполнения.
Возможность управлять эффективностью
Один из очень важных плюсов маленьких задач - возможность правильно вести статистику работы команды. Если команда работает по итерациям (а вы знаете, что так лучше), то задачи, которые укладываются в итерацию, дают возможность точно посчитать какой объем работы сделала команда (те, кто читал нашу книгу по процессам уже знают, как это делать). Так вы четко следите за снижением и повышением эффективности команды и можете вовремя реагировать на эти изменения. А если команда ушла в работу на 2 или, не дай Бог, 6 месяцев, делая одну задачу, вы по сути останетесь в слепой зоне и узнаете о проблемах в команде уже слишком поздно.
Лучшая мотивация людей
Закрывая маленькую задачу, исполнитель получает дозу положительной мотивации, это дает ему немного энергии, чтобы начать следующую. Делать очень долгую работу без получения результата требует очень больших затрат. Держать мотивацию команды на длительных проектах намного сложнее.
Вот такие преимущества дает выполнение всего одного свойства правильной задачи. Если хотите узнать, как выполнить остальные и получить еще больше преимуществ для своего проекта, то берите наше руководство по описанию задач и сегодня же внедряйте в свою работу. Гарантирую, вы сразу же увидите результат!
Александра Шаламова
#agile_который_работает
Одно из непременных условий задачи, которую команда с большей вероятностью сделает в сроки и без ошибок, является ее размер. Задача должна укладывать в одну рабочую итерацию, а лучше быть еще меньше. Зачем это нужно?
Гибкость
Преимущество, которое получает автор задачи. Если вы делите работу на мелкие части, то вы получаете больше возможностей ими жонглировать. Если вы дали в разработку большую задачу, то изменить ее без вмешательства в процесс разработки уже невозможно. А если вы отдали маленькую часть, то все остальные части, которые еще не в работе, вы еще можете менять.
Быстрее результат
Разбив задачи на много частей, вы можете (и должны) выбрать самые критичные из них и отправить их в работу в первую очередь. Так вы получите самый критичный функционала намного быстрее, чем если бы отдали в работу огромную задачу и ждали ее полного выполнения.
Возможность управлять эффективностью
Один из очень важных плюсов маленьких задач - возможность правильно вести статистику работы команды. Если команда работает по итерациям (а вы знаете, что так лучше), то задачи, которые укладываются в итерацию, дают возможность точно посчитать какой объем работы сделала команда (те, кто читал нашу книгу по процессам уже знают, как это делать). Так вы четко следите за снижением и повышением эффективности команды и можете вовремя реагировать на эти изменения. А если команда ушла в работу на 2 или, не дай Бог, 6 месяцев, делая одну задачу, вы по сути останетесь в слепой зоне и узнаете о проблемах в команде уже слишком поздно.
Лучшая мотивация людей
Закрывая маленькую задачу, исполнитель получает дозу положительной мотивации, это дает ему немного энергии, чтобы начать следующую. Делать очень долгую работу без получения результата требует очень больших затрат. Держать мотивацию команды на длительных проектах намного сложнее.
Вот такие преимущества дает выполнение всего одного свойства правильной задачи. Если хотите узнать, как выполнить остальные и получить еще больше преимуществ для своего проекта, то берите наше руководство по описанию задач и сегодня же внедряйте в свою работу. Гарантирую, вы сразу же увидите результат!
Александра Шаламова
#agile_который_работает
Самая недооцененная проблема проекта
Давайте поговорим о компоненте, который есть в ходе любого проекта и который постоянно игнорируется. Это наверное самый избегаемый и игнорируем компонент в проектной деятельности и, даже когда с ними работают, обычно делают это очень интуитивно и не системно. Поговорим сегодня о рисках.
Многие думают, да чего там о них думать, делаем да и все, а там, как получится. Всего не угадаешь. В итоге, мы получаем постоянные непредсказуемые для клиентов и руководства сдвиги сроков и несоответствующее качество, а все потому что не проработали риски и не подсветили их наличие для всех участников проекта.
Риски есть повсюду. Не могу придумать ни один проект без рисков. Даже если взять какой-нибудь разрабатываемый вами вечерами проект не связанный с работой, его основные риски это ситуации, в которых у вас не останется на него времени и/или мотивации.
Работаете вы скажем по спринтам и разрабатываете продукт в себе, без интеграций, смежников и прочего головняка. Ну какие тут могут быть риски? Да все, как у всех:
– Текучка кадров
– Болезнь ключевых исполнителей
– Ошибка в оценке сроков, например при создании функционала, который ваша команда до этого не делала
– Выбор неправильного инструмента. Допустим, выбрали вы какую-то библиотеку для ускорения разработки, а оказалось, что вот именно как вам надо она не умеет и либо меняй, либо дорабатывай, - все равно это удар по срокам.
– Или, скажем, проверка безопасности выявит критические проблемы в библиотеках или системах, которые вы используете. Менять или закрывать уязвимости придется и пострадают сроки.
И чем система больше и сложнее, тем больше рисков. Поэтому риски нужно видеть, от них не нужно прятаться. Риски всегда нужно учитывать и думать, как уменьшить их влияние при наступлении, как работать с проектам при наличии рисков реализация которых может наступить, а может нет. О рисках и их последствии должны знать все участники проекта и все заинтересованные лица, иначе это приведет к огромной череде конфликтов и скандалов и в целом приведет к потере вашей репутации.
Если у вас есть проблемы с оценкой своих рисков, приходите на консультацию, подберём, на что именно в вашей ситуации стоит обращать внимание.
Максим Шаламов
#риски
Давайте поговорим о компоненте, который есть в ходе любого проекта и который постоянно игнорируется. Это наверное самый избегаемый и игнорируем компонент в проектной деятельности и, даже когда с ними работают, обычно делают это очень интуитивно и не системно. Поговорим сегодня о рисках.
Многие думают, да чего там о них думать, делаем да и все, а там, как получится. Всего не угадаешь. В итоге, мы получаем постоянные непредсказуемые для клиентов и руководства сдвиги сроков и несоответствующее качество, а все потому что не проработали риски и не подсветили их наличие для всех участников проекта.
Риски есть повсюду. Не могу придумать ни один проект без рисков. Даже если взять какой-нибудь разрабатываемый вами вечерами проект не связанный с работой, его основные риски это ситуации, в которых у вас не останется на него времени и/или мотивации.
Работаете вы скажем по спринтам и разрабатываете продукт в себе, без интеграций, смежников и прочего головняка. Ну какие тут могут быть риски? Да все, как у всех:
– Текучка кадров
– Болезнь ключевых исполнителей
– Ошибка в оценке сроков, например при создании функционала, который ваша команда до этого не делала
– Выбор неправильного инструмента. Допустим, выбрали вы какую-то библиотеку для ускорения разработки, а оказалось, что вот именно как вам надо она не умеет и либо меняй, либо дорабатывай, - все равно это удар по срокам.
– Или, скажем, проверка безопасности выявит критические проблемы в библиотеках или системах, которые вы используете. Менять или закрывать уязвимости придется и пострадают сроки.
И чем система больше и сложнее, тем больше рисков. Поэтому риски нужно видеть, от них не нужно прятаться. Риски всегда нужно учитывать и думать, как уменьшить их влияние при наступлении, как работать с проектам при наличии рисков реализация которых может наступить, а может нет. О рисках и их последствии должны знать все участники проекта и все заинтересованные лица, иначе это приведет к огромной череде конфликтов и скандалов и в целом приведет к потере вашей репутации.
Если у вас есть проблемы с оценкой своих рисков, приходите на консультацию, подберём, на что именно в вашей ситуации стоит обращать внимание.
Максим Шаламов
#риски
Как скинуть балласт – избавляемся от нерадивого сотрудника
Итак, в вашу команду, не смотря на все ваши старания, попал нерадивый сотрудник. Вы уже все перепробовали и наконец решились на его увольнение. Что делать дальше?
Открою тайну для многих, но наше законодательство очень хорошо защищает права сотрудника, если конечно сотрудник подписывает нормальный трудовой договор, а не ставит подпись не глядя. И вот вы, как руководитель, пришли к тому, что хотите уволить подчиненного, что дальше? Прежде, чем говорить с человеком и кидаться громкими заявлениями, нужно понять, на что у вас реально есть право в вашем случае. Поэтому первым делом отправляйтесь на консультацию к вашим кадровикам или юристам, если таких в компании нет, то можно обратиться к сторонним специалистам. Они вам расскажут все нюансы по вашему трудовому договору и правилам компании с юридической точки зрения. Однако, есть общие подходы, которые помогут в любой ситуации и с которых можно начать работу с проблемным человеком.
Если человек явно отказывается работать или саботирует работу, то он скорее всего и уходить по-хорошему не захочет. А значит добиться от него увольнения по собственному желанию не получится. В любом случае, вам нужно провести разговор с сотрудником, где вы зафиксируете проблемы и послушаете его возражения. Дальше вы составляете план и обсуждаете конкретные шаги выхода из этих проблем. Все обязательно фиксируете. Фиксируйте хоть в электронной почте, если нет ничего другого, но обязательно фиксируйте.
Дальше вы идете по намеченному плану и смотрите, есть ли отклонения. То есть что-то, что сотрудник не выполняет из договоренностей, и если да, есть ли у них внятные оправдания или сотрудник просто пытается отделаться отговорками. Если вы поняли, что сотрудник опять ничего не сделал и оправданий у него нет, то все это снова фиксируете. Вам придется фиксировать факты несвоевременно выполненной работы или работы сданной в неподобающем качестве. А дальше проводить это через выговоры и т.д., точный формат вы уже обсудите с вашими юристами. Ваша же задача собрать и записать информацию, чтобы были реальные кейсы, доказывающие, что сотрудник не справляется с работой.
Главное, всегда быть спокойным и конструктивным. Отвечать на вопросы сотрудника, даже если он вам неприятен, и все, вообще все, фиксировать письменном виде.
Совсем отбитых сотрудников на самом деле немного, но они есть и тратят очень много времени и сил. Однако, при желании и правильном подходе уволить можно даже самого упертого.
Если задача работы со сложными людьми дается вам нелегко, вы не уверены в своей правоте, не знаете с чего начать и боитесь навредить своей работе, то обращайтесь к нам за личной консультацией. Мы поможем найти лучший подход именно для вашей ситуации и разработать четкий план дальнейших действий.
Максим Шаламов
#руководителю
Итак, в вашу команду, не смотря на все ваши старания, попал нерадивый сотрудник. Вы уже все перепробовали и наконец решились на его увольнение. Что делать дальше?
Открою тайну для многих, но наше законодательство очень хорошо защищает права сотрудника, если конечно сотрудник подписывает нормальный трудовой договор, а не ставит подпись не глядя. И вот вы, как руководитель, пришли к тому, что хотите уволить подчиненного, что дальше? Прежде, чем говорить с человеком и кидаться громкими заявлениями, нужно понять, на что у вас реально есть право в вашем случае. Поэтому первым делом отправляйтесь на консультацию к вашим кадровикам или юристам, если таких в компании нет, то можно обратиться к сторонним специалистам. Они вам расскажут все нюансы по вашему трудовому договору и правилам компании с юридической точки зрения. Однако, есть общие подходы, которые помогут в любой ситуации и с которых можно начать работу с проблемным человеком.
Если человек явно отказывается работать или саботирует работу, то он скорее всего и уходить по-хорошему не захочет. А значит добиться от него увольнения по собственному желанию не получится. В любом случае, вам нужно провести разговор с сотрудником, где вы зафиксируете проблемы и послушаете его возражения. Дальше вы составляете план и обсуждаете конкретные шаги выхода из этих проблем. Все обязательно фиксируете. Фиксируйте хоть в электронной почте, если нет ничего другого, но обязательно фиксируйте.
Дальше вы идете по намеченному плану и смотрите, есть ли отклонения. То есть что-то, что сотрудник не выполняет из договоренностей, и если да, есть ли у них внятные оправдания или сотрудник просто пытается отделаться отговорками. Если вы поняли, что сотрудник опять ничего не сделал и оправданий у него нет, то все это снова фиксируете. Вам придется фиксировать факты несвоевременно выполненной работы или работы сданной в неподобающем качестве. А дальше проводить это через выговоры и т.д., точный формат вы уже обсудите с вашими юристами. Ваша же задача собрать и записать информацию, чтобы были реальные кейсы, доказывающие, что сотрудник не справляется с работой.
Главное, всегда быть спокойным и конструктивным. Отвечать на вопросы сотрудника, даже если он вам неприятен, и все, вообще все, фиксировать письменном виде.
Совсем отбитых сотрудников на самом деле немного, но они есть и тратят очень много времени и сил. Однако, при желании и правильном подходе уволить можно даже самого упертого.
Если задача работы со сложными людьми дается вам нелегко, вы не уверены в своей правоте, не знаете с чего начать и боитесь навредить своей работе, то обращайтесь к нам за личной консультацией. Мы поможем найти лучший подход именно для вашей ситуации и разработать четкий план дальнейших действий.
Максим Шаламов
#руководителю
Сделали новое видео, как можно сломать работу своей команды одной маленькой ошибкой в планировании.
YouTube:
https://youtu.be/1D-MDHeNcTM
Boosty: https://boosty.to/itbesedka/posts/47679e45-272d-40b5-a9f4-9bdf710e1205?share=post_link
Дзен: https://dzen.ru/video/watch/6721d7a040e70a5ac4ac8fed
Рутуб: https://rutube.ru/video/0c925f1d21636e999b0ec23b245c02cb/
VK: https://vk.com/video-215961201_456239046
YouTube:
https://youtu.be/1D-MDHeNcTM
Boosty: https://boosty.to/itbesedka/posts/47679e45-272d-40b5-a9f4-9bdf710e1205?share=post_link
Дзен: https://dzen.ru/video/watch/6721d7a040e70a5ac4ac8fed
Рутуб: https://rutube.ru/video/0c925f1d21636e999b0ec23b245c02cb/
VK: https://vk.com/video-215961201_456239046
YouTube
Ужасная ошибка планирования, ее совершают 99% компаний
Главная причина, по которой вы не понимаете, чем занимается ваша команда, никогда не полуаете то, что просили сделать в задаче и никогда не получаете результат в срок.
Руководство по описанию задач: https://oros-it.ru/course/how-to-create-task?utm_source=youtube…
Руководство по описанию задач: https://oros-it.ru/course/how-to-create-task?utm_source=youtube…