Ты можешь не все
Давно хотел написать на тему ограниченных возможностей человека и более адекватного подхода к своим возможностям. В последнее время, в очередной раз лично переживал тонкости этой темы и решил поделиться своими мыслями. Возможно кому-то будет полезно.
Реакция на неудачу
Есть две очевидные реакции на неудачи. Винить себя и винить других. Любые крайности в виде следования только одному из вариантов приведут не к самым лучшим последствиям. Давайте разберем обе крайности.
Вариант первый: винить других
Винить других всегда очень просто и главное очень просто убедить себя в том, что кто-то не прав. Я думаю все встречались с людьми, которые очевидно не правы и при этом никогда в этом не признаются. Более того, многие руководители вообще считают, что нельзя признавать свои ошибки, и, как бы смешно или печально это не выглядело, будут стоять на том, что виновен кто угодно, но не они. Очевидной проблемой данного подхода является отсутствие критического взгляда на себя и свои действия. Это значит, что ошибки будут кочевать из ситуации в ситуацию. С другой стороны, если человек умен и хитер, то продвигаться он будет довольно лихо. Имея дело с такими людьми, учтите, что они очень много времени потратят на подготовку обоснования того, что они не виноваты и будут искать все способы обвинить других. Хотите чувствовать себя спокойно - максимально подробно и своевременно фиксируйте все детали хода проекта и договоренности.
Второй вариант: искать проблему в себе
Второй вариант реакции на неудачу: в любой ситуации искать проблемы в себе. Если я и утрирую, то не очень сильно. Эта проблема мне очень близка, в любой ситуации я в первую очередь смотрю, что я мог сделать лучше, как я мог чего-то избежать. В итоге, это очень эмоционально перегружает. Да, вы много анализируете и учитесь, это прекрасно, но в тоже время вы можете погрязнуть в излишних самокопаниях и негативе. Попадая в такую проблему, помните, что не все зависит от вас. Ваши возможности ограничены и с этим нужно смириться, но в другой раз вы сможете лучше. Я делаю следующее упражнение. Задаю себе вопрос: "все ли сделано, что от меня зависело?". Если да, то смысла винить себя нет. Если нет, то нужно понять, почему не получилось приложить все усилия и сделать вывод на следующий раз.
Что эффективно сделать
Естественно, нет универсального ответа на любую проблему. Прежде чем винить себя или других, разберитесь в ситуации. Восстановите картину случившегося со своей стороны и со стороны участников процесса. Найдите моменты, которые были сделаны неправильно или которые можно улучшить. Постарайтесь зафиксировать системно эти изменения, чтобы не допустить рецидивов. И так отрабатывайте каждую проблему, каждую неудачу. Просто винить себя или других, но главное это извлекать пользу и опыт из своих неудач и в следующий раз все получится, как надо.
Максим Шаламов
#тимлиду
Давно хотел написать на тему ограниченных возможностей человека и более адекватного подхода к своим возможностям. В последнее время, в очередной раз лично переживал тонкости этой темы и решил поделиться своими мыслями. Возможно кому-то будет полезно.
Реакция на неудачу
Есть две очевидные реакции на неудачи. Винить себя и винить других. Любые крайности в виде следования только одному из вариантов приведут не к самым лучшим последствиям. Давайте разберем обе крайности.
Вариант первый: винить других
Винить других всегда очень просто и главное очень просто убедить себя в том, что кто-то не прав. Я думаю все встречались с людьми, которые очевидно не правы и при этом никогда в этом не признаются. Более того, многие руководители вообще считают, что нельзя признавать свои ошибки, и, как бы смешно или печально это не выглядело, будут стоять на том, что виновен кто угодно, но не они. Очевидной проблемой данного подхода является отсутствие критического взгляда на себя и свои действия. Это значит, что ошибки будут кочевать из ситуации в ситуацию. С другой стороны, если человек умен и хитер, то продвигаться он будет довольно лихо. Имея дело с такими людьми, учтите, что они очень много времени потратят на подготовку обоснования того, что они не виноваты и будут искать все способы обвинить других. Хотите чувствовать себя спокойно - максимально подробно и своевременно фиксируйте все детали хода проекта и договоренности.
Второй вариант: искать проблему в себе
Второй вариант реакции на неудачу: в любой ситуации искать проблемы в себе. Если я и утрирую, то не очень сильно. Эта проблема мне очень близка, в любой ситуации я в первую очередь смотрю, что я мог сделать лучше, как я мог чего-то избежать. В итоге, это очень эмоционально перегружает. Да, вы много анализируете и учитесь, это прекрасно, но в тоже время вы можете погрязнуть в излишних самокопаниях и негативе. Попадая в такую проблему, помните, что не все зависит от вас. Ваши возможности ограничены и с этим нужно смириться, но в другой раз вы сможете лучше. Я делаю следующее упражнение. Задаю себе вопрос: "все ли сделано, что от меня зависело?". Если да, то смысла винить себя нет. Если нет, то нужно понять, почему не получилось приложить все усилия и сделать вывод на следующий раз.
Что эффективно сделать
Естественно, нет универсального ответа на любую проблему. Прежде чем винить себя или других, разберитесь в ситуации. Восстановите картину случившегося со своей стороны и со стороны участников процесса. Найдите моменты, которые были сделаны неправильно или которые можно улучшить. Постарайтесь зафиксировать системно эти изменения, чтобы не допустить рецидивов. И так отрабатывайте каждую проблему, каждую неудачу. Просто винить себя или других, но главное это извлекать пользу и опыт из своих неудач и в следующий раз все получится, как надо.
Максим Шаламов
#тимлиду
Верхнеуровневая и точная оценка сроков
Сегодня хотел бы поговорить об оценке сроков, как со стороны исполнителя, так и со стороны руководителя. Последние 7-8 лет я участвую в оценке сроков, как на собственные задачи, так и на задачи команд и отделов в целом. Поэтому сразу хотелось бы сказать, что мы можем говорить о реальных сроках на задачи и верхнеуровневых оценках.
Верхнеуровневые оценки и работа с бизнесом
Верхнеуровневые оценки нужны для долгосрочного планирования и обычно их нужно давать по очень расплывчатым описаниям, но без этого, в рамках большинства бизнес процессов, невозможно строить планирование развития продукта. Основной проблемой тут является то, что сроки эти, естественно, никогда не бывают точными. Это понятно каждому исполнителю по причине отсутствия достаточного количества деталей для оценки. Однако, бизнес команда обычно очень сильно цепляется за такие сроки и потом начинаются интересные процессы согласования реальных сроков. Какого-то идеального решения я не знаю, советую закладывать хорошие запасы на максимально видимую постановку задачи. Не соглашайтесь на убеждения, что задача будет простой просто пока не ясно на сколько, скорректировать сроки в минус всегда можно без особых проблем и споров, а вот в плюс почти никогда не работает без проблем. Также, при каждой оценке приучайте коллег к пониманию, что сроки будут пересчитаны при детализации задач. С некоторыми в итоге это приведет к вполне конструктивному общению в рамках планирования.
Как собирать сроки с людей
С конкретными задачами, тоже все не очень ладно. Почти каждый руководитель понимает, что нужно делать наценку на непредвиденные ситуации, но, когда собирает информацию с исполнителей, забывает учить каждого этому простому подходу. В итоге обычно собираются очень оптимистичные сроки и запаса не хватает. Что же делать? Не требовать ответ с людей в моменте и даже не принимать его. Дайте людям все хорошо взвесить, найти проблемные места и заложить на это время. Я стараюсь собирать итог не раньше чем через день (если только не горящая задача, но такие обычно берутся в работу и делаются пока не будут готовы в первом приоритете). В итоге такой подход + ваша наценка, дадут неплохое представление о времени реализации задачи.
Как закладывать сроки разработчику
Будучи разработчиком, я тоже всегда продумывал все моменты, где что-то может пойти не так, где надо заложить времени и где могут понадобиться дополнительные усилия. Советую каждому не пытаться дать ответ о сроках сходу. Это довольно сложно, наш мозг любит отбрасывать «мелочи» при беглом просмотре, а из таких мелочей может состоять 80% времени реализации задачи. Берите время на проработку и оценку. Не пытайтесь угадывать, анализируйте и оценивайте.
В целом решать проблемы с точностью оценок нужно через адекватное восприятие невозможности всегда попадать на 100% и ретроспективы, на которых разбираться, что пошло не так и что можно улучшить. Главное пытаться устранить причины плохой оценки, а не искать виноватых.
Максим Шаламов.
#тимлиду #разработчику #agile_который_работает
Сегодня хотел бы поговорить об оценке сроков, как со стороны исполнителя, так и со стороны руководителя. Последние 7-8 лет я участвую в оценке сроков, как на собственные задачи, так и на задачи команд и отделов в целом. Поэтому сразу хотелось бы сказать, что мы можем говорить о реальных сроках на задачи и верхнеуровневых оценках.
Верхнеуровневые оценки и работа с бизнесом
Верхнеуровневые оценки нужны для долгосрочного планирования и обычно их нужно давать по очень расплывчатым описаниям, но без этого, в рамках большинства бизнес процессов, невозможно строить планирование развития продукта. Основной проблемой тут является то, что сроки эти, естественно, никогда не бывают точными. Это понятно каждому исполнителю по причине отсутствия достаточного количества деталей для оценки. Однако, бизнес команда обычно очень сильно цепляется за такие сроки и потом начинаются интересные процессы согласования реальных сроков. Какого-то идеального решения я не знаю, советую закладывать хорошие запасы на максимально видимую постановку задачи. Не соглашайтесь на убеждения, что задача будет простой просто пока не ясно на сколько, скорректировать сроки в минус всегда можно без особых проблем и споров, а вот в плюс почти никогда не работает без проблем. Также, при каждой оценке приучайте коллег к пониманию, что сроки будут пересчитаны при детализации задач. С некоторыми в итоге это приведет к вполне конструктивному общению в рамках планирования.
Как собирать сроки с людей
С конкретными задачами, тоже все не очень ладно. Почти каждый руководитель понимает, что нужно делать наценку на непредвиденные ситуации, но, когда собирает информацию с исполнителей, забывает учить каждого этому простому подходу. В итоге обычно собираются очень оптимистичные сроки и запаса не хватает. Что же делать? Не требовать ответ с людей в моменте и даже не принимать его. Дайте людям все хорошо взвесить, найти проблемные места и заложить на это время. Я стараюсь собирать итог не раньше чем через день (если только не горящая задача, но такие обычно берутся в работу и делаются пока не будут готовы в первом приоритете). В итоге такой подход + ваша наценка, дадут неплохое представление о времени реализации задачи.
Как закладывать сроки разработчику
Будучи разработчиком, я тоже всегда продумывал все моменты, где что-то может пойти не так, где надо заложить времени и где могут понадобиться дополнительные усилия. Советую каждому не пытаться дать ответ о сроках сходу. Это довольно сложно, наш мозг любит отбрасывать «мелочи» при беглом просмотре, а из таких мелочей может состоять 80% времени реализации задачи. Берите время на проработку и оценку. Не пытайтесь угадывать, анализируйте и оценивайте.
В целом решать проблемы с точностью оценок нужно через адекватное восприятие невозможности всегда попадать на 100% и ретроспективы, на которых разбираться, что пошло не так и что можно улучшить. Главное пытаться устранить причины плохой оценки, а не искать виноватых.
Максим Шаламов.
#тимлиду #разработчику #agile_который_работает
Илон Маск заявил, что все его сотрудники, считающие работу исключительно в офисе устаревшей концепцией, могут притворяться, что работают в другой компании. Что мы думаем по поводу подобных высказываний знаменитого предпринимателя? Что ж, гений и миллиардер может себе и такое позволить. Всем остальным советуем изучать, как считаются метрики эффективности при удаленной работе команды.
#тимлиду
#тимлиду
Как бороться с усталостью
Мы уже говорили про выгорание и что это не равносильно усталости. В последнее время очень большой акцент делается на выгорании, не только потому, что люди осознали это как проблему, но и потому, что это модно и молодежно.
Однако проблемы связанные с банальной усталостью и переутомлением никуда не делись и ее влияние на ваше состояние или состояние вашей команды тоже может стать разрушительным. На самом деле с усталостью все кажется проще: вовремя отдыхаешь, быстро переключаешься на отдых и всего-то. В целом, если это получается, то на этом можно и закончить, но, обычно, бывают периоды, когда работа не выпускает и наваливается как лавина. Находясь в процессе, ты реально можешь не замечать, что просто вымотан до предела и работаешь на чистом адреналине от стрессовой составляющей такого подхода. И в таком состоянии не всегда бывает очевидно, что отдых уже критически необходим. На самом деле встречал я такое у большинства своих коллег, впрочем как у и себя.
Признаки усталости
Дак какие же признаки могут нам помочь отследить это состояние:
- Вы бегаете от всего нового. Вообще от всего: новые люди, музыка, фильмы, любые новые впечатления.
- Пропадает желание и мотивация заниматься своими хобби. У вас банально нет сил, но обычно ощущается, как отсутствие желания, что может вводить в заблуждение.
- В работе вы цепляетесь за рутинные задачи не требующие долгого осмысления.
- Концентрация на новых задачах и проблемах дается с огромным трудом
Для отслеживания этого у себя, коллег или подчиненных нужно внимательно следить за этими признаками. Банально слушать человека, или себя, и анализировать информацию будет достаточно. Так же, как руководитель, я принял для себя правило сразу отпускать человека в отпуск, если он сам хочет или ему нужно. Я максимально стараюсь искать возможности, чтобы не делать исключения в этом правиле. Релизы и прочее есть всегда, но мне нужен бодрый, мотивированный и сосредоточенный человек, а не тот кто может с трудом разгребать рутинные задачи.
Если в отпуск уйти не получается
В связи с этим появляется вопрос, а что делать если время пришло, а в отпуск уйти не получается? Есть ли лайфхак? На мой взгляд - нет. Все что можно тут предложить это смягчить ход событий:
- Больше спите, когда чувствуете в этом потребность.
- Получайте новые эмоции и впечатления, это поможет вам вырываться из уныния, которое идет вкупе с накатывающей усталостью.
- Не берите лишних задач, раз уж вы не тянете то, что у вас уже есть.
- Берите отпуск сразу, как будет возможность, не ждите идеальный момент.
Вообще последний пункт довольно важный, идеальных моментов для отпуска не бывает, поэтому передавайте дела (подойдите к этому ответственно) и спокойно отдыхайте. Берегите себя и окружающих людей, отдыхайте вовремя тогда и работа и жизнь будут значительно приятнее.
Максим Шаламов
#советы #тимлиду #разработчику
Мы уже говорили про выгорание и что это не равносильно усталости. В последнее время очень большой акцент делается на выгорании, не только потому, что люди осознали это как проблему, но и потому, что это модно и молодежно.
Однако проблемы связанные с банальной усталостью и переутомлением никуда не делись и ее влияние на ваше состояние или состояние вашей команды тоже может стать разрушительным. На самом деле с усталостью все кажется проще: вовремя отдыхаешь, быстро переключаешься на отдых и всего-то. В целом, если это получается, то на этом можно и закончить, но, обычно, бывают периоды, когда работа не выпускает и наваливается как лавина. Находясь в процессе, ты реально можешь не замечать, что просто вымотан до предела и работаешь на чистом адреналине от стрессовой составляющей такого подхода. И в таком состоянии не всегда бывает очевидно, что отдых уже критически необходим. На самом деле встречал я такое у большинства своих коллег, впрочем как у и себя.
Признаки усталости
Дак какие же признаки могут нам помочь отследить это состояние:
- Вы бегаете от всего нового. Вообще от всего: новые люди, музыка, фильмы, любые новые впечатления.
- Пропадает желание и мотивация заниматься своими хобби. У вас банально нет сил, но обычно ощущается, как отсутствие желания, что может вводить в заблуждение.
- В работе вы цепляетесь за рутинные задачи не требующие долгого осмысления.
- Концентрация на новых задачах и проблемах дается с огромным трудом
Для отслеживания этого у себя, коллег или подчиненных нужно внимательно следить за этими признаками. Банально слушать человека, или себя, и анализировать информацию будет достаточно. Так же, как руководитель, я принял для себя правило сразу отпускать человека в отпуск, если он сам хочет или ему нужно. Я максимально стараюсь искать возможности, чтобы не делать исключения в этом правиле. Релизы и прочее есть всегда, но мне нужен бодрый, мотивированный и сосредоточенный человек, а не тот кто может с трудом разгребать рутинные задачи.
Если в отпуск уйти не получается
В связи с этим появляется вопрос, а что делать если время пришло, а в отпуск уйти не получается? Есть ли лайфхак? На мой взгляд - нет. Все что можно тут предложить это смягчить ход событий:
- Больше спите, когда чувствуете в этом потребность.
- Получайте новые эмоции и впечатления, это поможет вам вырываться из уныния, которое идет вкупе с накатывающей усталостью.
- Не берите лишних задач, раз уж вы не тянете то, что у вас уже есть.
- Берите отпуск сразу, как будет возможность, не ждите идеальный момент.
Вообще последний пункт довольно важный, идеальных моментов для отпуска не бывает, поэтому передавайте дела (подойдите к этому ответственно) и спокойно отдыхайте. Берегите себя и окружающих людей, отдыхайте вовремя тогда и работа и жизнь будут значительно приятнее.
Максим Шаламов
#советы #тимлиду #разработчику
Использование грейдов: частые ошибки
К теме грейдов подходят очень по-разному, в каждой компании свои требования и ожидания, я даже заставал эксперимент по плоской структуре в рамках большой компании (сюрприз, но оно не заработало). Я много общаюсь и читаю на тему организации работы команд. Поговорим о том, что я выделил из разговоров по ожиданиям к людям и что я об этом думаю.
Частые ошибки в использовании грейдов
Многие руководители в принципе считают, что им грейды не нужны. В идеальной картине мира куда как проще иметь кучу взаимозаменяемых людей, равной производительности. По такому принципу стараются жить веб-студии, правда даже им приходится обзаводиться грейдами.
Что еще обязательно выделяют - это самостоятельность. Конечно же сам от клиента получил задачу, сам сделал, сам выкатил - красота. Конечно, желательно, чтобы время на ревью и прочие мелочи типа тестирования не тратилось. Вообще когда продукт разрабатывает много людей и он разрастается, то такая самостоятельность будет чудовищно бить по качеству и поддерживаемости проекта. Не говоря о потере контроля за имеющимся функционалом.
Конечно же ответственность и вовлеченность, ну чтобы работал побольше, возмущался поменьше. У клиента есть проблема - все бросил и пошел решать (приоритетов нет), потом доделываешь то, что делал в те же сроки.
По грейдам, джун это тот, кто будет умирать на работе 24/7, он ведь ничего не знает, а задач будут выдавать примерно как всем. Мидл, ну он должен решать задачи, ну по сути любые. Синьоры - это вообще в таком концепции волшебники, которым можно скинуть что угодно и получить за 5 минут решение. А лиды: ну чтобы удержать синьора можно и грейд дать.
Естественно я говорю не о всех компаниях и руководителях, но таких очень немало и они схожи в своих ожиданиях. Многие запросы скрывают нежелание и неумение выстраивать работу. В целом в таком виде это приводит к большой текучке и довольно печальным продуктам.
Как я работаю с грейдами
Что касается моего мнения, то грейды нужны и людям, чтобы отмерять свой прогресс и статус, и руководителям, чтобы адекватно понимать какие к кому можно предъявлять требования. В маленькой команде высококлассных специалистов, формализмы не нужны, в остальных случаях без этого будет сложно.
Ответственность, самостоятельность и вовлеченность, необходимы любому сотруднику и таких людей нужно искать. Но во-первых, если демотивировать людей плохо выстроенными процессами, то любое вовлечение и ответственность начнут отказывать. А второе, что все свои усилия люди должны направлять в рамках зафиксированных (устно или письменно) внутрикомандных правил, тогда это будет хорошо работать и не приводить к проблемам.
Если говорить о самих грейдах, то джуны для меня это люди с неплохой теоретической базой, желающие расти и развиваться, которым интересна область, в которой они работают. Мидлы - люди, которые имеют неплохой практический опыт и могут решать основные типовые задачи на проекте. Синьоры - это люди, которые могут решить любую задачу в рамках проекта, могут помочь другим участникам команды, умеют коммуницировать вне команды. Про тех и тимлидов я писал отдельно.
Но в целом нужны вам грейды или нет, кого вы ищите и как, в итоге будете решать только вы.
Максим Шаламов
#сто #тимлиду #руководителю
К теме грейдов подходят очень по-разному, в каждой компании свои требования и ожидания, я даже заставал эксперимент по плоской структуре в рамках большой компании (сюрприз, но оно не заработало). Я много общаюсь и читаю на тему организации работы команд. Поговорим о том, что я выделил из разговоров по ожиданиям к людям и что я об этом думаю.
Частые ошибки в использовании грейдов
Многие руководители в принципе считают, что им грейды не нужны. В идеальной картине мира куда как проще иметь кучу взаимозаменяемых людей, равной производительности. По такому принципу стараются жить веб-студии, правда даже им приходится обзаводиться грейдами.
Что еще обязательно выделяют - это самостоятельность. Конечно же сам от клиента получил задачу, сам сделал, сам выкатил - красота. Конечно, желательно, чтобы время на ревью и прочие мелочи типа тестирования не тратилось. Вообще когда продукт разрабатывает много людей и он разрастается, то такая самостоятельность будет чудовищно бить по качеству и поддерживаемости проекта. Не говоря о потере контроля за имеющимся функционалом.
Конечно же ответственность и вовлеченность, ну чтобы работал побольше, возмущался поменьше. У клиента есть проблема - все бросил и пошел решать (приоритетов нет), потом доделываешь то, что делал в те же сроки.
По грейдам, джун это тот, кто будет умирать на работе 24/7, он ведь ничего не знает, а задач будут выдавать примерно как всем. Мидл, ну он должен решать задачи, ну по сути любые. Синьоры - это вообще в таком концепции волшебники, которым можно скинуть что угодно и получить за 5 минут решение. А лиды: ну чтобы удержать синьора можно и грейд дать.
Естественно я говорю не о всех компаниях и руководителях, но таких очень немало и они схожи в своих ожиданиях. Многие запросы скрывают нежелание и неумение выстраивать работу. В целом в таком виде это приводит к большой текучке и довольно печальным продуктам.
Как я работаю с грейдами
Что касается моего мнения, то грейды нужны и людям, чтобы отмерять свой прогресс и статус, и руководителям, чтобы адекватно понимать какие к кому можно предъявлять требования. В маленькой команде высококлассных специалистов, формализмы не нужны, в остальных случаях без этого будет сложно.
Ответственность, самостоятельность и вовлеченность, необходимы любому сотруднику и таких людей нужно искать. Но во-первых, если демотивировать людей плохо выстроенными процессами, то любое вовлечение и ответственность начнут отказывать. А второе, что все свои усилия люди должны направлять в рамках зафиксированных (устно или письменно) внутрикомандных правил, тогда это будет хорошо работать и не приводить к проблемам.
Если говорить о самих грейдах, то джуны для меня это люди с неплохой теоретической базой, желающие расти и развиваться, которым интересна область, в которой они работают. Мидлы - люди, которые имеют неплохой практический опыт и могут решать основные типовые задачи на проекте. Синьоры - это люди, которые могут решить любую задачу в рамках проекта, могут помочь другим участникам команды, умеют коммуницировать вне команды. Про тех и тимлидов я писал отдельно.
Но в целом нужны вам грейды или нет, кого вы ищите и как, в итоге будете решать только вы.
Максим Шаламов
#сто #тимлиду #руководителю
Как развлечься на работе
Довольно часто я слышу о том, что людям в какой-то момент становится скучно от выполнения их обязанностей, все надоело и нужно менять работу. В целом, не вижу ничего криминального в смене работы, просто для себя важно понимать истинные причины этого. Скука она весьма субъективна и обычно найдет вас везде, если вы не научитесь правильно к этому подходить. Говорить о случаях когда есть иные причины для недовольства я не буду.
Зона комфорта
Скука выплывает обычно в контексте того, что работа по ведению проекта устаканилась и идет своим чередом, соответственно больше не дает дополнительных вызовов и роста. На самом деле это самообман и вы просто вошли в зону комфорта, из которой сами себя вытаскивать не хотите, а смена работа естественным образом решит эту проблему на время, но именно на время. Почему я в уверен, что скука идет от зоны комфорта? Потому что идеальных ситуаций/проектов/команд/технологий/... не бывает. Просто со временем вы принимаете некоторые вещи как данность и перестаете пытаться их улучшить. Дальнейшие упражнения имеют смысл, если вас в целом все устраивает и нет других серьезных причин для увольнения. Так же оставим в стороне случаи, когда вы хотите других позиций в целом.
Как выбраться из зоны комфорта не меняя работу
Итак принимаем за данность, что ничего идеального в нашем мире не бывает. Выделяем для себя время не менее часа в день, на протяжении хотя бы недели. В это время начинаем подробно смотреть на свою работу. Смотрим на все составляющие вашего проекта, на процессы, по которым работает команда (причем ваша позиция в такой ситуации значения не имеет, хотя конечно и сложность с внедрениями зависит от позиции), тех. долг, подходы к автоматизации и тестированию и прочие компоненты, из которых состоит ваша работа и работа вашей команды. Составьте список проблем и отсортируйте их по собственному видению приоритетов. Дальше Возьмите топ-3 проблем и проработайте их, то есть опишите (прямо в документе) суть проблемы, ее влияние на проект и команду, и ваше видение ее решения. Очень вдумчиво подойдите к этому процессу, не спешите и все детально описывайте. Пока вы будете писать и перечитывать, вы сможете хотя бы немного со стороны посмотреть на свои идеи, это поможет вам их сформулировать максимально доступно. После этого представьте свои идеи руководству и команде, обсудите с ними ваше видение, предложите попробовать и возьмите на себя ответственность. Даже если первые идеи отсеют, то вы найдете те проблемы, над которыми сможете поработать и вовлечь других. Начинайте с малых шагов, всегда помните о том, что нужно иметь метрики как было и как стало, обязательно показывайте результаты команде и руководству, помогайте другим вовлекаться в изменения, слушайте обратную связь и корректируйте свои подходы.
Что если идей по улучшениям нет
Бывают ситуации, когда у вас нет идей, как что-то улучшить. Тогда воспользуйтесь знаниями других, читайте книги, смотрите доклады, обсуждайте с коллегами внутри и вне компании (главное без обсуждения чувствительных вещей для компании). В итоге вы наберете набор идей и подходов, которые можно попробовать. Выберите наиболее подходящий и идите по плану описанному выше.
Таким образом, можно все время улучшать окружающие вас рабочие моменты, изучать что-то самому, приносить пользу себе и компании, а главное заскучать таким образом будет довольно сложно.
Максим Шаламов
#советы #разработчику #тимлиду
Довольно часто я слышу о том, что людям в какой-то момент становится скучно от выполнения их обязанностей, все надоело и нужно менять работу. В целом, не вижу ничего криминального в смене работы, просто для себя важно понимать истинные причины этого. Скука она весьма субъективна и обычно найдет вас везде, если вы не научитесь правильно к этому подходить. Говорить о случаях когда есть иные причины для недовольства я не буду.
Зона комфорта
Скука выплывает обычно в контексте того, что работа по ведению проекта устаканилась и идет своим чередом, соответственно больше не дает дополнительных вызовов и роста. На самом деле это самообман и вы просто вошли в зону комфорта, из которой сами себя вытаскивать не хотите, а смена работа естественным образом решит эту проблему на время, но именно на время. Почему я в уверен, что скука идет от зоны комфорта? Потому что идеальных ситуаций/проектов/команд/технологий/... не бывает. Просто со временем вы принимаете некоторые вещи как данность и перестаете пытаться их улучшить. Дальнейшие упражнения имеют смысл, если вас в целом все устраивает и нет других серьезных причин для увольнения. Так же оставим в стороне случаи, когда вы хотите других позиций в целом.
Как выбраться из зоны комфорта не меняя работу
Итак принимаем за данность, что ничего идеального в нашем мире не бывает. Выделяем для себя время не менее часа в день, на протяжении хотя бы недели. В это время начинаем подробно смотреть на свою работу. Смотрим на все составляющие вашего проекта, на процессы, по которым работает команда (причем ваша позиция в такой ситуации значения не имеет, хотя конечно и сложность с внедрениями зависит от позиции), тех. долг, подходы к автоматизации и тестированию и прочие компоненты, из которых состоит ваша работа и работа вашей команды. Составьте список проблем и отсортируйте их по собственному видению приоритетов. Дальше Возьмите топ-3 проблем и проработайте их, то есть опишите (прямо в документе) суть проблемы, ее влияние на проект и команду, и ваше видение ее решения. Очень вдумчиво подойдите к этому процессу, не спешите и все детально описывайте. Пока вы будете писать и перечитывать, вы сможете хотя бы немного со стороны посмотреть на свои идеи, это поможет вам их сформулировать максимально доступно. После этого представьте свои идеи руководству и команде, обсудите с ними ваше видение, предложите попробовать и возьмите на себя ответственность. Даже если первые идеи отсеют, то вы найдете те проблемы, над которыми сможете поработать и вовлечь других. Начинайте с малых шагов, всегда помните о том, что нужно иметь метрики как было и как стало, обязательно показывайте результаты команде и руководству, помогайте другим вовлекаться в изменения, слушайте обратную связь и корректируйте свои подходы.
Что если идей по улучшениям нет
Бывают ситуации, когда у вас нет идей, как что-то улучшить. Тогда воспользуйтесь знаниями других, читайте книги, смотрите доклады, обсуждайте с коллегами внутри и вне компании (главное без обсуждения чувствительных вещей для компании). В итоге вы наберете набор идей и подходов, которые можно попробовать. Выберите наиболее подходящий и идите по плану описанному выше.
Таким образом, можно все время улучшать окружающие вас рабочие моменты, изучать что-то самому, приносить пользу себе и компании, а главное заскучать таким образом будет довольно сложно.
Максим Шаламов
#советы #разработчику #тимлиду
План по приведению отдела в порядок, разбираем предновогодний кейс
Сегодня хочу поделиться опытом с пылу с жару так сказать. Представьте, что вы уже закрыли год, все распланировали на новый и до конца года осталось 3 недели. И тут вам прилетает новый отдел, где из вводных есть только то, что едут все сроки, нет прозрачности и вообще людей, которыми усиливали отдел, хотят вернуть на другие задачи. Надо бы все завести, а до конца года хотя бы погасить пожары и составить общее видение и план. Вот такая абстрактная ситуация, которая со мной случается чаще, чем я ожидал. Итого, есть: вы и свободные 60% дня (другие задачи сами себя не сделают), установочная встреча с бизнес лидером и тем, кто пытался до вас.
С чего начать
Итак, что делаем, прямо по шагам.
• Верхнеуровнево вникаем в детали бизнеса, смотрим цели и планы. Собираем видение проблем с бизнеса. Записываем выжимку полученной информации.
• Дальше параллельно идем двумя путями:
◦ знакомимся с ПО каждой команды и тем, что они делают. Записываем основные моменты, планы, смотрим как они пересекаются с общими планами. Выписываем основные проблемы
◦ знакомимся с лидами. Записываем их видение дел и проблем.
• Выписываем все полученные проблемы, объединяя общие. Приоритезируем проблемы. Из списка проблем выделяем смежников, на которых завязаны.
• Знакомимся со смежниками и пытаемся наладить контакт, собираем их версию проблем.
• Выделяем проблемы, требующие немедленного решения и назначаем ответственных, желательно как можно больше делать не самому (времени мало, а дел много). В проблемах указываем ожидаемый результат и шаги, если они понятны. Не переживаем, что не знаем людей, за одно они себя и покажут в реальных условиях. Не забываем держать каждую проблему на контроле.
• Верхнеуровнево знакомимся с процессами команд и архитектурой проектов. В детали не лезем, времени мало. Выписываем основные проблемы, которые видим, они уйдут в план на первый или второй квартал.
Что имеем после первых действий
Итого, получаем:
• знакомство с основными участниками отдела;
• верхнеуровневое понимание бизнеса, целей и задач команд, архитектуры и ее проблем;
• самые насущные проблемы, часть из которых оперативно будет закрыта;
• знакомство со смежниками, от которых зависим и понимание их проблем и роли в рабочем процессе.
Имея это, мы начинаем контролировать основные блокеры, мешавшие запустить проекты, даже если не можем быстро на них повлиять. Мы уже можем составить план на первый квартал. В реальных условиях смотрим на то, как работают лиды и возможно ПО.
Важные уроки
Какие моменты могу выделить в очередной раз:
• многие проблемы со смежниками кроются в отсутствии нормально выстроенной коммуникации и понимания блокеров и приоритетов друг друга;
• команды, которые смогли запустить хоть что-то имеют зачатки адекватных процессов работы. Хаотичная работа, показывает нулевой результат;
• проекты без адекватного технического IT-руководства, при очень быстрых темпах роста, имеют тенденцию так же быстро разваливаться;
• мотивацией людей нужно заниматься, сама по себе мотивация к работе, идущая из гиперответственности, есть у единиц.
Надеюсь, что-то из этого будет вам полезно или просто занимательно для чтения.
#сто #тимлиду
Максим Шаламов
Сегодня хочу поделиться опытом с пылу с жару так сказать. Представьте, что вы уже закрыли год, все распланировали на новый и до конца года осталось 3 недели. И тут вам прилетает новый отдел, где из вводных есть только то, что едут все сроки, нет прозрачности и вообще людей, которыми усиливали отдел, хотят вернуть на другие задачи. Надо бы все завести, а до конца года хотя бы погасить пожары и составить общее видение и план. Вот такая абстрактная ситуация, которая со мной случается чаще, чем я ожидал. Итого, есть: вы и свободные 60% дня (другие задачи сами себя не сделают), установочная встреча с бизнес лидером и тем, кто пытался до вас.
С чего начать
Итак, что делаем, прямо по шагам.
• Верхнеуровнево вникаем в детали бизнеса, смотрим цели и планы. Собираем видение проблем с бизнеса. Записываем выжимку полученной информации.
• Дальше параллельно идем двумя путями:
◦ знакомимся с ПО каждой команды и тем, что они делают. Записываем основные моменты, планы, смотрим как они пересекаются с общими планами. Выписываем основные проблемы
◦ знакомимся с лидами. Записываем их видение дел и проблем.
• Выписываем все полученные проблемы, объединяя общие. Приоритезируем проблемы. Из списка проблем выделяем смежников, на которых завязаны.
• Знакомимся со смежниками и пытаемся наладить контакт, собираем их версию проблем.
• Выделяем проблемы, требующие немедленного решения и назначаем ответственных, желательно как можно больше делать не самому (времени мало, а дел много). В проблемах указываем ожидаемый результат и шаги, если они понятны. Не переживаем, что не знаем людей, за одно они себя и покажут в реальных условиях. Не забываем держать каждую проблему на контроле.
• Верхнеуровнево знакомимся с процессами команд и архитектурой проектов. В детали не лезем, времени мало. Выписываем основные проблемы, которые видим, они уйдут в план на первый или второй квартал.
Что имеем после первых действий
Итого, получаем:
• знакомство с основными участниками отдела;
• верхнеуровневое понимание бизнеса, целей и задач команд, архитектуры и ее проблем;
• самые насущные проблемы, часть из которых оперативно будет закрыта;
• знакомство со смежниками, от которых зависим и понимание их проблем и роли в рабочем процессе.
Имея это, мы начинаем контролировать основные блокеры, мешавшие запустить проекты, даже если не можем быстро на них повлиять. Мы уже можем составить план на первый квартал. В реальных условиях смотрим на то, как работают лиды и возможно ПО.
Важные уроки
Какие моменты могу выделить в очередной раз:
• многие проблемы со смежниками кроются в отсутствии нормально выстроенной коммуникации и понимания блокеров и приоритетов друг друга;
• команды, которые смогли запустить хоть что-то имеют зачатки адекватных процессов работы. Хаотичная работа, показывает нулевой результат;
• проекты без адекватного технического IT-руководства, при очень быстрых темпах роста, имеют тенденцию так же быстро разваливаться;
• мотивацией людей нужно заниматься, сама по себе мотивация к работе, идущая из гиперответственности, есть у единиц.
Надеюсь, что-то из этого будет вам полезно или просто занимательно для чтения.
#сто #тимлиду
Максим Шаламов
Как подпитывать драйв в команде
Давайте поговорим об одной из важнейших составляющих успеха любой команды или продукта. Сложно назвать это каким-то одним слово, но пусть это будет драйв. Это непрерывное желание и движение к тому, чтобы сделать лучше, больше, превзойти конкурентов и т.д. В каком-то смысле это энергия, на которой идет развитие продукта и команды, то, что заряжает людей и позволяет двигаться вперед. Давайте обсудим то, как его можно поддерживать и какие методы не работают.
На ком должен держаться драйв команды
Я не сильно хотел бы углубляться в материи типа огня в глазах и всего такого. В больших проектах добиться равной большой вовлеченности всех участников команды очень сложно. Поэтому основные участники процесса должны обладать этим качеством и делиться с командой. Это выражается в постоянном поиске и устранении проблем, как в продукте, так и в процессах. Постоянно должны подниматься вопросы, а как сделать лучше, а не можем ли мы сделать быстрее, не должны ли мы доработать идею или выкинуть то, что плохо работает.
Как поддержание драйва не сработает
Обычно такую роль на себя берут владельцы продукта (PO), которые низводят ее до банального хаоса и постоянного давления на команду. Берут больше задач, чем можно сделать, бегают вокруг с вопросами, а когда будет готово, а уже сроки прошли, надо поднажать и т.д. Если не нормализовать этот процесс, то получим хаос, текучку и весьма слабо рабочий проект.
Забавно, но когда такого воздействия на команду нет совсем, результат получается примерно таким же. Наводя порядок в одном из проектов, я обратил внимание, что на команду никогда не давили сроки, никто особо не рвался вперед, все старались работать ровно. К сожалению, это не дало ожидаемого эффекта, команда со временем стала скучать и утратила мотивацию, а перенос сроков ушел за все разумные границы.
А как подпитать драйв в команде правильно?
В итоге, мы получили снова задачу о балансе, как и все в нашей жизни. Что же можно сделать, чтобы вернуть жизнь в ваш проект и по возможности не выжечь себя и других. Выстраивайте коммуникации так, что все идеи не отбрасываются, а обсуждаются в рамках отдельных встреч (или собираются в каком-то месте, с последующим разбором). Отобранные удачные идеи должны попадать в бэклог и реализовываться, это повысит вовлеченность каждого участника команды.
Всегда должны озвучиваться вопросы, а эффективно ли мы хотим что-то делать или делаем, нет ли способов ускориться или сделать лучше. Это не повод жить на работе, или увеличить сроки в 10 раз, это повод взвесить все за и против и выстроить работу вокруг принятых решений. Главное - это правильная коммуникация. Такие вопросы должны ставиться не с целью навязать что-то, а с целью поиска лучших решений. Соответственно и восприниматься такие вопросы должны спокойно, с целью найти лучшее решение.
Владелец продукта и тимлид должны взять на себя задачи по построению таких коммуникаций и адекватного общения вокруг них. Команду нужно вовлекать и удерживать от конфликтов и неконструктивных отвлечений. Любые идеи, лучше всего, для начала, собирать в каком-то пространстве, а потом собираться для их обсуждения. Постоянно собираться в моменте может быть неэффективно.
Максим Шаламов
#тимлиду #разработчику
Давайте поговорим об одной из важнейших составляющих успеха любой команды или продукта. Сложно назвать это каким-то одним слово, но пусть это будет драйв. Это непрерывное желание и движение к тому, чтобы сделать лучше, больше, превзойти конкурентов и т.д. В каком-то смысле это энергия, на которой идет развитие продукта и команды, то, что заряжает людей и позволяет двигаться вперед. Давайте обсудим то, как его можно поддерживать и какие методы не работают.
На ком должен держаться драйв команды
Я не сильно хотел бы углубляться в материи типа огня в глазах и всего такого. В больших проектах добиться равной большой вовлеченности всех участников команды очень сложно. Поэтому основные участники процесса должны обладать этим качеством и делиться с командой. Это выражается в постоянном поиске и устранении проблем, как в продукте, так и в процессах. Постоянно должны подниматься вопросы, а как сделать лучше, а не можем ли мы сделать быстрее, не должны ли мы доработать идею или выкинуть то, что плохо работает.
Как поддержание драйва не сработает
Обычно такую роль на себя берут владельцы продукта (PO), которые низводят ее до банального хаоса и постоянного давления на команду. Берут больше задач, чем можно сделать, бегают вокруг с вопросами, а когда будет готово, а уже сроки прошли, надо поднажать и т.д. Если не нормализовать этот процесс, то получим хаос, текучку и весьма слабо рабочий проект.
Забавно, но когда такого воздействия на команду нет совсем, результат получается примерно таким же. Наводя порядок в одном из проектов, я обратил внимание, что на команду никогда не давили сроки, никто особо не рвался вперед, все старались работать ровно. К сожалению, это не дало ожидаемого эффекта, команда со временем стала скучать и утратила мотивацию, а перенос сроков ушел за все разумные границы.
А как подпитать драйв в команде правильно?
В итоге, мы получили снова задачу о балансе, как и все в нашей жизни. Что же можно сделать, чтобы вернуть жизнь в ваш проект и по возможности не выжечь себя и других. Выстраивайте коммуникации так, что все идеи не отбрасываются, а обсуждаются в рамках отдельных встреч (или собираются в каком-то месте, с последующим разбором). Отобранные удачные идеи должны попадать в бэклог и реализовываться, это повысит вовлеченность каждого участника команды.
Всегда должны озвучиваться вопросы, а эффективно ли мы хотим что-то делать или делаем, нет ли способов ускориться или сделать лучше. Это не повод жить на работе, или увеличить сроки в 10 раз, это повод взвесить все за и против и выстроить работу вокруг принятых решений. Главное - это правильная коммуникация. Такие вопросы должны ставиться не с целью навязать что-то, а с целью поиска лучших решений. Соответственно и восприниматься такие вопросы должны спокойно, с целью найти лучшее решение.
Владелец продукта и тимлид должны взять на себя задачи по построению таких коммуникаций и адекватного общения вокруг них. Команду нужно вовлекать и удерживать от конфликтов и неконструктивных отвлечений. Любые идеи, лучше всего, для начала, собирать в каком-то пространстве, а потом собираться для их обсуждения. Постоянно собираться в моменте может быть неэффективно.
Максим Шаламов
#тимлиду #разработчику
Фокусировка - держим команду в фокусе
Важнейшей составляющей для любого успешного релиза является фокусировка. Это становится важнее с ростом размера релиза. Чем больший объем функционала вы хотите сделать (тем соответственно больше сроки реализации), тем важнее становится фактор фокусировки.
Мы всего лишь говорим об умении фокусироваться на главном и отбрасывать лишнее. Однако это бывает очень сложно, когда задач много и все они важные и нужные, а помогать выделить критичное никто не спешит.
Поставьте цели
Фокусировка начинается с малого, у каждого спринта или итерации, обязательно должна быть сформулирована цель. Все задачи работающие на выполнение цели, являются приоритетными и задача команды иметь приоритет на их решение. Все остальные задачи должны идти либо после выполнения цели, либо в случае, если у участников команды появляется время (сидеть и смотреть в монитор никому не нужно). Задача лидера команды все время держать фокус на важном. Переложить задачу на бизнес обычно не получается, потому что, в противном случае, задачи будут прибывать и прибывать. Все в команде должны понимать, что не закрытие цели спринта это отклонение от нормы и нужно разбираться в причинах (Как? Это тема отдельного разговора).
Расставьте приоритеты
Говоря про большие релизы, нужно сформировать не только цель, но и четко приоритезировать все задачи, связанные с целью. Приоритезация будет нужна, потому что в больших релизах от части запланированного функционала придется отказаться. Я рекомендую всегда уменьшать функционал, а не двигать сроки. Это позволяет минимально работать в стол и максимально быстро получить обратную связь от пользователей и понять идет ли все по плану или нет. Сдвиги сроков обычно сильно давят на команду и чем дальше, тем будет становиться хуже. Мое мнение на этот вопрос однозначное: ваша задача к дедлайну иметь работающий и отлаженный проект с набором критичного функционала. Очень важно, что работающего и отлаженного функционала, в который можно пускать пользователей. Тогда можно уже обсуждать в деталях, есть ли смысл в том, что получилось, и какой приоритет у доработок и следующих шагов. Если же вы приходите к дедлайну с набором недоделанных фичей, то ни о каком запуске речи быть не может, как и об успешной работе над взятым функционалом.
Что если бизнес не участвует в приоритезации
Если бизнес не может сам ставить приоритеты, то вам придется, слушая их, делать это самим. Тут очень простая логика, вам все равно нужно сделать каждую задачу в надлежащем качестве, поэтому если вы к дедлайну выберите и сделаете определенные, это как минимум ничего не испортит, как максимум - вы сможете запустить проект раньше. Если Бизнес приоритезирует задачи так, что они не влазят, то делаем тоже самое, выстраиваем максимально возможный по приоритету вариант.
В фокусировке важно, чтобы руководитель всегда доносил это до своих подчиненных, чтобы это не уходило у них из головы: есть цели и к ним нужно идти. Мы не должны умирать в пути к цели или делать плохой продукт. Мы должны искать варианты и обходные пути, где это возможно, а где это невозможно уменьшать число фичей или их сложность. Для руководителя очень важно не терять фокус самому и не переставать доносить важность этого до своей команды, тогда все получится. Найдутся и обходные пути, и результат придет.
Максим Шаламов
#тимлиду #agile_который_работает
Важнейшей составляющей для любого успешного релиза является фокусировка. Это становится важнее с ростом размера релиза. Чем больший объем функционала вы хотите сделать (тем соответственно больше сроки реализации), тем важнее становится фактор фокусировки.
Мы всего лишь говорим об умении фокусироваться на главном и отбрасывать лишнее. Однако это бывает очень сложно, когда задач много и все они важные и нужные, а помогать выделить критичное никто не спешит.
Поставьте цели
Фокусировка начинается с малого, у каждого спринта или итерации, обязательно должна быть сформулирована цель. Все задачи работающие на выполнение цели, являются приоритетными и задача команды иметь приоритет на их решение. Все остальные задачи должны идти либо после выполнения цели, либо в случае, если у участников команды появляется время (сидеть и смотреть в монитор никому не нужно). Задача лидера команды все время держать фокус на важном. Переложить задачу на бизнес обычно не получается, потому что, в противном случае, задачи будут прибывать и прибывать. Все в команде должны понимать, что не закрытие цели спринта это отклонение от нормы и нужно разбираться в причинах (Как? Это тема отдельного разговора).
Расставьте приоритеты
Говоря про большие релизы, нужно сформировать не только цель, но и четко приоритезировать все задачи, связанные с целью. Приоритезация будет нужна, потому что в больших релизах от части запланированного функционала придется отказаться. Я рекомендую всегда уменьшать функционал, а не двигать сроки. Это позволяет минимально работать в стол и максимально быстро получить обратную связь от пользователей и понять идет ли все по плану или нет. Сдвиги сроков обычно сильно давят на команду и чем дальше, тем будет становиться хуже. Мое мнение на этот вопрос однозначное: ваша задача к дедлайну иметь работающий и отлаженный проект с набором критичного функционала. Очень важно, что работающего и отлаженного функционала, в который можно пускать пользователей. Тогда можно уже обсуждать в деталях, есть ли смысл в том, что получилось, и какой приоритет у доработок и следующих шагов. Если же вы приходите к дедлайну с набором недоделанных фичей, то ни о каком запуске речи быть не может, как и об успешной работе над взятым функционалом.
Что если бизнес не участвует в приоритезации
Если бизнес не может сам ставить приоритеты, то вам придется, слушая их, делать это самим. Тут очень простая логика, вам все равно нужно сделать каждую задачу в надлежащем качестве, поэтому если вы к дедлайну выберите и сделаете определенные, это как минимум ничего не испортит, как максимум - вы сможете запустить проект раньше. Если Бизнес приоритезирует задачи так, что они не влазят, то делаем тоже самое, выстраиваем максимально возможный по приоритету вариант.
В фокусировке важно, чтобы руководитель всегда доносил это до своих подчиненных, чтобы это не уходило у них из головы: есть цели и к ним нужно идти. Мы не должны умирать в пути к цели или делать плохой продукт. Мы должны искать варианты и обходные пути, где это возможно, а где это невозможно уменьшать число фичей или их сложность. Для руководителя очень важно не терять фокус самому и не переставать доносить важность этого до своей команды, тогда все получится. Найдутся и обходные пути, и результат придет.
Максим Шаламов
#тимлиду #agile_который_работает
Кто должен быть лидером в команде разработки
Давайте сегодня обсудим вопрос кто и почему должен быть лидером в команде (речь о неформальном лидере, кто направляет команду в реальности, а не на бумаге). Варианта у нас всего два тимлид и владелец продукта (Product Owner, ПО). Очень часто в команде складывается ситуация, когда лидер именно владелец продукта. Уверен, что бывают удачные исключения, но я таких не видел и у своих коллег такого не наблюдал. Основная проблема по в том, что им слишком тяжело нащупать внутренний баланс. Они должны гореть идеей дать как можно больше и как можно быстрее, это не то что нормально, это необходимо для активного роста проекта. Но вместе с этим такой подход приведет к ужасному качеству продукта и выгоранию команды.
Почему ПО становится лидером?
Почему же владелец продукта так часто становятся лидерами команды. ПО роль сама по себе очень активная и направляющая. Хочешь не хочешь, а решать куда двигаться продукту или какие фичи брать, будет ПО (не важно как он к этому приходит). Так же ПО отвечает за бизнес показатели своего проекта или его части, поэтому ему реально нужно быстрее и больше, от этого зависит результат его работы, реализация его амбиций, да и банально сохранение своего места. Опять же ПО роль про коммуникации, поэтому обычно у них хорошо подвешен язык. А главное, с ПО не спросят за развалившийся технически проект, он отправит все вопросы к инженерам (по крайней мере попытается и скорее всего успешно).
Почему лидером не становится тимлид?
Что же касается нас с вами, то есть инженеров, обычно многие лиды (особенно начинающие), вполне довольны просто наличием лычки лида, и как-то особо не пытаются проявлять себя, что ПО обычно устраивает. Часто всплывают проблемы с коммуникациями, умение общаться и ясно излагать свои мысли нужно развивать, что хочется не многим. Многие становятся лидами, потому что они были самыми лучшими разработчиками в команде, но они, получив роль, продолжают быть лучшими разработчиками и не более. Ну и главное: многие не могут и не хотят брать на себя ответственность.
Как должно быть?
Однако, я считаю, что в эффективной команде (опять же в жизни бывает всякое) лидером должен быть именно тимлид. Потому что тимлид должен думать о команде, качестве продукта, поддерживаемости и так далее. Это как минимум часть его работы, причем существенная. Тимлид должен балансировать ПО и его неуемное желание бежать вперед.
А не получим ли с тимлидом туже проблему?
Почему же тимлид не сделает перекос в ненужную сторону? Это может случится, но есть несколько моментов. Первое, большинство людей все же приходят делать что-то значимое и стоящее, и сами заинтересованы в том, чтобы продукт выпускался и пользователи были довольны. Мало кто хочет работать в стол. Второе, тут всегда есть естественная балансировка. Мы в компаниях наняты для развития или поддержки проектов, соответственно если кто-то из инженеров встанет на пути развития компании/проекта без видимых причин, его просто уволят. Я общался с немалым количеством компаний, где искали замены своим техническим лидерам (даже тем с кем стартовали проекты и стартапы), потому что они совсем потеряли баланс и новый функционал просто не появлялся. И тут как раз оправдание, что зато работает скорее всего не сработает.
Максим Шаламов
#тимлиду #разработчику
Давайте сегодня обсудим вопрос кто и почему должен быть лидером в команде (речь о неформальном лидере, кто направляет команду в реальности, а не на бумаге). Варианта у нас всего два тимлид и владелец продукта (Product Owner, ПО). Очень часто в команде складывается ситуация, когда лидер именно владелец продукта. Уверен, что бывают удачные исключения, но я таких не видел и у своих коллег такого не наблюдал. Основная проблема по в том, что им слишком тяжело нащупать внутренний баланс. Они должны гореть идеей дать как можно больше и как можно быстрее, это не то что нормально, это необходимо для активного роста проекта. Но вместе с этим такой подход приведет к ужасному качеству продукта и выгоранию команды.
Почему ПО становится лидером?
Почему же владелец продукта так часто становятся лидерами команды. ПО роль сама по себе очень активная и направляющая. Хочешь не хочешь, а решать куда двигаться продукту или какие фичи брать, будет ПО (не важно как он к этому приходит). Так же ПО отвечает за бизнес показатели своего проекта или его части, поэтому ему реально нужно быстрее и больше, от этого зависит результат его работы, реализация его амбиций, да и банально сохранение своего места. Опять же ПО роль про коммуникации, поэтому обычно у них хорошо подвешен язык. А главное, с ПО не спросят за развалившийся технически проект, он отправит все вопросы к инженерам (по крайней мере попытается и скорее всего успешно).
Почему лидером не становится тимлид?
Что же касается нас с вами, то есть инженеров, обычно многие лиды (особенно начинающие), вполне довольны просто наличием лычки лида, и как-то особо не пытаются проявлять себя, что ПО обычно устраивает. Часто всплывают проблемы с коммуникациями, умение общаться и ясно излагать свои мысли нужно развивать, что хочется не многим. Многие становятся лидами, потому что они были самыми лучшими разработчиками в команде, но они, получив роль, продолжают быть лучшими разработчиками и не более. Ну и главное: многие не могут и не хотят брать на себя ответственность.
Как должно быть?
Однако, я считаю, что в эффективной команде (опять же в жизни бывает всякое) лидером должен быть именно тимлид. Потому что тимлид должен думать о команде, качестве продукта, поддерживаемости и так далее. Это как минимум часть его работы, причем существенная. Тимлид должен балансировать ПО и его неуемное желание бежать вперед.
А не получим ли с тимлидом туже проблему?
Почему же тимлид не сделает перекос в ненужную сторону? Это может случится, но есть несколько моментов. Первое, большинство людей все же приходят делать что-то значимое и стоящее, и сами заинтересованы в том, чтобы продукт выпускался и пользователи были довольны. Мало кто хочет работать в стол. Второе, тут всегда есть естественная балансировка. Мы в компаниях наняты для развития или поддержки проектов, соответственно если кто-то из инженеров встанет на пути развития компании/проекта без видимых причин, его просто уволят. Я общался с немалым количеством компаний, где искали замены своим техническим лидерам (даже тем с кем стартовали проекты и стартапы), потому что они совсем потеряли баланс и новый функционал просто не появлялся. И тут как раз оправдание, что зато работает скорее всего не сработает.
Максим Шаламов
#тимлиду #разработчику
Как правильно принимать решение
Довольно часто в нашей жизни нужно принимать решения. Сегодня мы конечно будем говорить о принятии решений в работе. Есть решения, которые вам нужно принять лично, есть решения, которые нужно принять совместно с другими. Решать нужно и руководителям, и людям, которые отвечают только за себя.
Возможности в принятии решений в зависимости от должности
Будучи исполнителем, в зависимости от компании, вы имеете рамки, в которых выполняете задачи, в них часто бывает достаточный простор для выбора способов решений и выбора инструментов.
Как часть команды, вы можете договариваться о способах решения командных проблем и взаимодействий, выбор инструментария и т.д.
Как руководитель, вы имеете много возможностей для принятия решений, главное находить баланс (об этом отдельно).
Ключевые моменты для правильного принятия решения
Что я считаю критично для принятия решений:
- каждое решение должно быть принято своевременно, то есть нужно ставить конечные сроки принятия решения. Даже если вы будете ставить их сами себе. Слишком поздно принятые решения могут сильно повлиять на сроки и качество проекта. Плюс, многие забывают про неприятный момент в виде того, что, если вы не приняли решение, за вас его примет руководство. Например, если я готов отдать принятие решения на откуп команды или исполнителя, по достижению оговоренного конечного срока принятия решения, если я готовое решение от команды не получаю, то решение выбираю я сам. Также делают многие руководители. Поэтому своевременность и оперативность в этом вопросе имеет большое значение.
- после принятия решения нужно собирать установки метрики/критерии успешности. Это нужно, чтобы понять насколько хорошо мы приняли решение, не обходится ли это нам слишком дорого и не создало ли это больше проблем, чем решило. Эти критерии нужно выбрать в момент выбора и ориентироваться на них в процессе решения.
- после принятия решения, пока не выбрано иное, нужно целенаправленно и четко следовать этому решению. Не нужно метаться и пытаться попробовать что-то еще. Идите к цели, не распыляйтесь.
- в случае, если решение перестает удовлетворять установленным критериям, то нужно взвесить снова все за и против и, либо изменяйте решение, либо скорректируйте метрики и ожидания.
Готовность принимать решения и отвечать за них - одно из важнейших умений руководителя и любого хорошего специалиста. Помимо ответственности, это позволит получить вам больше возможностей. Поэтому не бойтесь принимать решения, а то их примет кто-то другой.
Максим Шаламов
#разработчику #тимлиду
Довольно часто в нашей жизни нужно принимать решения. Сегодня мы конечно будем говорить о принятии решений в работе. Есть решения, которые вам нужно принять лично, есть решения, которые нужно принять совместно с другими. Решать нужно и руководителям, и людям, которые отвечают только за себя.
Возможности в принятии решений в зависимости от должности
Будучи исполнителем, в зависимости от компании, вы имеете рамки, в которых выполняете задачи, в них часто бывает достаточный простор для выбора способов решений и выбора инструментов.
Как часть команды, вы можете договариваться о способах решения командных проблем и взаимодействий, выбор инструментария и т.д.
Как руководитель, вы имеете много возможностей для принятия решений, главное находить баланс (об этом отдельно).
Ключевые моменты для правильного принятия решения
Что я считаю критично для принятия решений:
- каждое решение должно быть принято своевременно, то есть нужно ставить конечные сроки принятия решения. Даже если вы будете ставить их сами себе. Слишком поздно принятые решения могут сильно повлиять на сроки и качество проекта. Плюс, многие забывают про неприятный момент в виде того, что, если вы не приняли решение, за вас его примет руководство. Например, если я готов отдать принятие решения на откуп команды или исполнителя, по достижению оговоренного конечного срока принятия решения, если я готовое решение от команды не получаю, то решение выбираю я сам. Также делают многие руководители. Поэтому своевременность и оперативность в этом вопросе имеет большое значение.
- после принятия решения нужно собирать установки метрики/критерии успешности. Это нужно, чтобы понять насколько хорошо мы приняли решение, не обходится ли это нам слишком дорого и не создало ли это больше проблем, чем решило. Эти критерии нужно выбрать в момент выбора и ориентироваться на них в процессе решения.
- после принятия решения, пока не выбрано иное, нужно целенаправленно и четко следовать этому решению. Не нужно метаться и пытаться попробовать что-то еще. Идите к цели, не распыляйтесь.
- в случае, если решение перестает удовлетворять установленным критериям, то нужно взвесить снова все за и против и, либо изменяйте решение, либо скорректируйте метрики и ожидания.
Готовность принимать решения и отвечать за них - одно из важнейших умений руководителя и любого хорошего специалиста. Помимо ответственности, это позволит получить вам больше возможностей. Поэтому не бойтесь принимать решения, а то их примет кто-то другой.
Максим Шаламов
#разработчику #тимлиду
Как не погрязнуть в ручных правках
Я давно работаю в IT, поработал в разных компаниях и отделах, оброс знакомствами и контактами. Интересно, что я почти в каждом месте встречаю одну и туже проблему.
Давайте немного напряжем воображение. Вы делаете задачу по приему оплаты за услуги на вашем сайте. В какой-то момент оказывается, что части пользователей выдается немного меньше услуг после оплаты. Но не страшно, бизнес, который управляет приоритетами, приходит и говорит: "ребята, нет времени это чинить, давайте в базе проставим руками, как должно быть и не будем тратить время на правки. Сейчас не до этого, а пользователей таких немного". Знакомая история?
К чему это приводит
Похожие истории имеют обыкновение копиться и множиться. Это приводит к ситуациям, когда появляются сломанные пользовательские сценарии и пути, что приводит к постоянным просьбам в стиле “поменяйте руками в базе доступ”, “посмотрите кто сделал последнее изменение в этом объявлении”, “посмотрите, какая у этого пользователя почта” и таких задач становится все больше и большею. В итоге они начинают занимать значимую часть времени команды. Хотя, казалось бы, времени итак не было. Команда при этом оказывается в ловушке собственной мотивации, ведь все знают, что они хотят двигаться вперед и видеть, как их продуктом пользуются. Поэтому многие разработчики идут на встречу и попадают в ситуацию, когда продукт трещит по швам, а половину дня приходится разбираться с пользовательскими обращениями, чтобы руками поправить их проблему. При этом, такие задачи всегда срочные и требуют резкой смены контекста. Многие заводят в итоге дежурных, которых нужно все больше и больше, что мало меняет общую картину. Если пустить ситуацию на самотек, это в итоге сильно навредить проекту и подорвет мотивацию команды, замученную бесконечными рутинными задачами.
Что же делать?
Я предлагаю следующее решение этой проблемы. Помните, что услуги IT-специалистов дороги и занимать их чем-то отвлеченным крайне дорогая и сомнительная затея. Посчитайте процент пользователей, которых затрагивают проблемы и сколько времени займет ручная обработка всех их проблем. А потом посчитайте время на создание простого интерфейса, где бизнес руками сможет разрешить все сложности. Обычно этот аргумент становится решающим. Конечно нужно подкрепить уверенностью в правильности шага и терпением. Правильно было бы просчитать системное решение проблемы т.е. время на закрытие бага или недоработки функционала. На примере покажите, что разово закрыть проблему будет выгоднее и решите ее раз и навсегда, освободив время команды с рутинных ручных разборов этой проблемы.
После пары таких заходов, соберитесь с бизнесом и договоритесь, что вместо ручной работы вы всегда выбираете один из двух вариантов: интерфейс для ручной правки бизнесом или системное решение проблемы.
Максима Шаламов
#тимлиду #разработчику
Я давно работаю в IT, поработал в разных компаниях и отделах, оброс знакомствами и контактами. Интересно, что я почти в каждом месте встречаю одну и туже проблему.
Давайте немного напряжем воображение. Вы делаете задачу по приему оплаты за услуги на вашем сайте. В какой-то момент оказывается, что части пользователей выдается немного меньше услуг после оплаты. Но не страшно, бизнес, который управляет приоритетами, приходит и говорит: "ребята, нет времени это чинить, давайте в базе проставим руками, как должно быть и не будем тратить время на правки. Сейчас не до этого, а пользователей таких немного". Знакомая история?
К чему это приводит
Похожие истории имеют обыкновение копиться и множиться. Это приводит к ситуациям, когда появляются сломанные пользовательские сценарии и пути, что приводит к постоянным просьбам в стиле “поменяйте руками в базе доступ”, “посмотрите кто сделал последнее изменение в этом объявлении”, “посмотрите, какая у этого пользователя почта” и таких задач становится все больше и большею. В итоге они начинают занимать значимую часть времени команды. Хотя, казалось бы, времени итак не было. Команда при этом оказывается в ловушке собственной мотивации, ведь все знают, что они хотят двигаться вперед и видеть, как их продуктом пользуются. Поэтому многие разработчики идут на встречу и попадают в ситуацию, когда продукт трещит по швам, а половину дня приходится разбираться с пользовательскими обращениями, чтобы руками поправить их проблему. При этом, такие задачи всегда срочные и требуют резкой смены контекста. Многие заводят в итоге дежурных, которых нужно все больше и больше, что мало меняет общую картину. Если пустить ситуацию на самотек, это в итоге сильно навредить проекту и подорвет мотивацию команды, замученную бесконечными рутинными задачами.
Что же делать?
Я предлагаю следующее решение этой проблемы. Помните, что услуги IT-специалистов дороги и занимать их чем-то отвлеченным крайне дорогая и сомнительная затея. Посчитайте процент пользователей, которых затрагивают проблемы и сколько времени займет ручная обработка всех их проблем. А потом посчитайте время на создание простого интерфейса, где бизнес руками сможет разрешить все сложности. Обычно этот аргумент становится решающим. Конечно нужно подкрепить уверенностью в правильности шага и терпением. Правильно было бы просчитать системное решение проблемы т.е. время на закрытие бага или недоработки функционала. На примере покажите, что разово закрыть проблему будет выгоднее и решите ее раз и навсегда, освободив время команды с рутинных ручных разборов этой проблемы.
После пары таких заходов, соберитесь с бизнесом и договоритесь, что вместо ручной работы вы всегда выбираете один из двух вариантов: интерфейс для ручной правки бизнесом или системное решение проблемы.
Максима Шаламов
#тимлиду #разработчику
Нужны ли руководителю технические знания?
В своих статьях и курсах мы много говорим о софт-скиллах руководителей. Давайте сегодня посмотрим на вторую составляющую работы - хард скиллы, а вернее о балансе между ними. Несомненно любая руководящая позиция требует знаний и умений далеко выходящих за технические навыки и знания. Но можно ли обойтись совсем без технических знаний? Ответ на этот вопрос сильно зависит от позиции и обязанностей.
Основная концепция
Понятно, что знания у CIO/CTO, под которым 150 человек и руководителем команды, под которым 5 человек, если не должны, то могут сильно отличаться. Чем больше под руководителем людей, отделов, проектов, тем более высокоуровнево он должен уметь смотреть на проблемы. Нужно уметь выбирать технологии, которые в целом устроят компанию (даже в ущерб конкретному отделу), выбирать методологии работы, выстраивать отделы. На таких позициях обычно количество технологий, с которыми работают подчиненные так велико, что знать их все в деталях человеку просто не под силу, да этого и не требуется.
Однако, чем ближе руководитель к решению конкретных прикладных задач, тем выше должна быть его погруженность в эту специфику. Зачем это нужно? Тут есть несколько моментов.
Понимание специфики
Первое, руководитель будет говорить со своими людьми на одном языке, а это очень важно. Он постоянно работает с людьми, принимает решения и чем лучше его понимают, чем выше уверенность людей, что он понимает то, о чем говорит, что ему можно доверять, тем лучше люди будут слушать своего руководителя и охотнее поддерживать его решения. Конечно я не говорю, что вы, будучи руководителем, должны все и лучше всех знать и уметь, конечно нет. Но нужно понимать специфику того, с чем работаешь. Руководитель должен понимать что делают его люди и зачем, чтобы уметь понять их проблемы, чтобы помочь решать их проблемы.
Оценка качества
Второе, руководитель должен уметь контролировать ход работ и принимать работу своих подчиненных. Для верхнеуровневой приемки из разряда "тыкнул кнопку - лампочка загорелась" есть другие люди. Управленец должен уметь понимать развивается ли продукт правильно, должен уметь оценить качество сделанной работы и понять все ли работают как надо и должны, оправданы ли сроки. Даже если в команде есть техлид, вышестоящий руководитель не можете полностью отдать эти знания в его голову и контроль в его руки. Спросят о результатах в итоге все равно с более высокого руководства и оно должно уметь понять, что хорошо, а что плохо. Естественно привлекать людей для ревью и анализа результата тоже необходимо, сторонний взгляд всегда полезен. Главное нужно, по необходимости, смочь понять как идут дела и хорошо ли выполняется работа.
Оценка качества работы подчиненных
Третье, и временами самое неприятное, руководитель должен уметь контролировать не просто ход работ, а понять насколько хорошо или плохо работает конкретный человек. Поскольку от него будет зависеть повысить его зарплату или нет, увольнять человека или нет, то конечно он должны уметь оценивать человека. А поскольку он оценивает технического специалиста, то оценка его технических знаний необходима для комплексного принятия решений о подчиненном.
Заключение
В заключении, подведем итог. Технические руководители должны обладать техническими знаниями и навыками. От позиции к позиции набор знаний и умений варьируется, от максимального погружения в конкретную область, когда вы тимлид/техлид, до высокоуровневого понимания технологий и методологий управления, достаточного для принятия решений о выборе технологий, но не обязательно достаточного, чтобы самому смочь внедрить технологию в любой проект на более высоких позициях.
Максим Шаламов
#тимлиду #разработчику
В своих статьях и курсах мы много говорим о софт-скиллах руководителей. Давайте сегодня посмотрим на вторую составляющую работы - хард скиллы, а вернее о балансе между ними. Несомненно любая руководящая позиция требует знаний и умений далеко выходящих за технические навыки и знания. Но можно ли обойтись совсем без технических знаний? Ответ на этот вопрос сильно зависит от позиции и обязанностей.
Основная концепция
Понятно, что знания у CIO/CTO, под которым 150 человек и руководителем команды, под которым 5 человек, если не должны, то могут сильно отличаться. Чем больше под руководителем людей, отделов, проектов, тем более высокоуровнево он должен уметь смотреть на проблемы. Нужно уметь выбирать технологии, которые в целом устроят компанию (даже в ущерб конкретному отделу), выбирать методологии работы, выстраивать отделы. На таких позициях обычно количество технологий, с которыми работают подчиненные так велико, что знать их все в деталях человеку просто не под силу, да этого и не требуется.
Однако, чем ближе руководитель к решению конкретных прикладных задач, тем выше должна быть его погруженность в эту специфику. Зачем это нужно? Тут есть несколько моментов.
Понимание специфики
Первое, руководитель будет говорить со своими людьми на одном языке, а это очень важно. Он постоянно работает с людьми, принимает решения и чем лучше его понимают, чем выше уверенность людей, что он понимает то, о чем говорит, что ему можно доверять, тем лучше люди будут слушать своего руководителя и охотнее поддерживать его решения. Конечно я не говорю, что вы, будучи руководителем, должны все и лучше всех знать и уметь, конечно нет. Но нужно понимать специфику того, с чем работаешь. Руководитель должен понимать что делают его люди и зачем, чтобы уметь понять их проблемы, чтобы помочь решать их проблемы.
Оценка качества
Второе, руководитель должен уметь контролировать ход работ и принимать работу своих подчиненных. Для верхнеуровневой приемки из разряда "тыкнул кнопку - лампочка загорелась" есть другие люди. Управленец должен уметь понимать развивается ли продукт правильно, должен уметь оценить качество сделанной работы и понять все ли работают как надо и должны, оправданы ли сроки. Даже если в команде есть техлид, вышестоящий руководитель не можете полностью отдать эти знания в его голову и контроль в его руки. Спросят о результатах в итоге все равно с более высокого руководства и оно должно уметь понять, что хорошо, а что плохо. Естественно привлекать людей для ревью и анализа результата тоже необходимо, сторонний взгляд всегда полезен. Главное нужно, по необходимости, смочь понять как идут дела и хорошо ли выполняется работа.
Оценка качества работы подчиненных
Третье, и временами самое неприятное, руководитель должен уметь контролировать не просто ход работ, а понять насколько хорошо или плохо работает конкретный человек. Поскольку от него будет зависеть повысить его зарплату или нет, увольнять человека или нет, то конечно он должны уметь оценивать человека. А поскольку он оценивает технического специалиста, то оценка его технических знаний необходима для комплексного принятия решений о подчиненном.
Заключение
В заключении, подведем итог. Технические руководители должны обладать техническими знаниями и навыками. От позиции к позиции набор знаний и умений варьируется, от максимального погружения в конкретную область, когда вы тимлид/техлид, до высокоуровневого понимания технологий и методологий управления, достаточного для принятия решений о выборе технологий, но не обязательно достаточного, чтобы самому смочь внедрить технологию в любой проект на более высоких позициях.
Максим Шаламов
#тимлиду #разработчику
Сегодня мы подготовили для вас инфографику о принципах набора людей для маленькой компании. Более развернутую информацию можно найти в статье.
#тимлиду #разработчику
#тимлиду #разработчику
Офис или удаленка? Личный опыт.
Сейчас очень много идет споров и обсуждений на тему “офис против удаленки”. Крупные компании пытаются вернуть сотрудников в офис, в то время, как большинству сотрудников хорошо работается удаленно. Расскажу свою историю и к какому выводу я в итоге пришел.
Как я перешел на полную удаленку
Сам я познакомился с полной удаленкой на старте пандемийных проблем. У нас была довольно зрелая команда, и мы, одни из первых, опробовали возможности полной удаленки. Затем, уже перейдя в ТАСС, я собрал полностью удаленную команду. В целом, на удаленке и с удаленной командой я проработал 3 года (за исключением посещения очных совещаний с руководством компании). Я обустроил удобное рабочее место и зарезервировал интернет. Переход на удаленные коммуникации для моей команды прошел довольно безболезненно. Плюсом мы получили возможность усиливаться ребятами со всей страны, а не только с локации нахождения офиса. Вообще, это был довольно хороший опыт, результаты были достигнуты, какого-то дискомфорта от работы дома не наблюдалось. Однако, когда я искал новую работу, удаленку я не стал ставить обязательным условием и вообще скорее склонялся к возвращению в офис.
Дак как так случилось, если эксперимент получился удачным? Начну лично с моих проблем, а потом перейду к общим для команды.
Проблема командного духа
На удаленке у большинства из нас пропало ощущение, что мы команда. И вернуть это так и не получилось. Новые ребята быстро интегрировались в работу, но не было того ощущения сплоченности для решения поставленной задачи. Если раньше мы довольно хорошо чувствовали, кто начинает выдыхаться и ему нужно отдохнуть или дать смену деятельности, то на удаленке с этим случались проблемы. Естественно мы улучшили уровень удаленной коммуникации, но это не могло заменить эффект от частого неформального общения в офисе. Наверное, это показывает, что есть куда расти в этом плане, но по моим наблюдениям и опросам, эта проблема накрыла многих.
Проблема срочных, критичных задач
Следующей сложностью было то, что какие-то срочные и критичные вещи проще решать собравшись вместе в одном месте. Первое время нештатных ситуаций было много и поток созвонов и зумов затягивал. Бесконечные совместные зумы частично решили проблему, но когда экран пошарить надо было двоим или троим все затягивалось. С учетом, что я в основном беру проекты, которые нужно вытаскивать из сложных ситуаций, эта проблема бьет всегда.
Проблемы участников команды
Если говорить в общем, то на удаленке некоторые люди теряют связь с командой, чувствуют себя в изоляции. Часть людей просто не умеет в домашних условиях спланировать свой день и их производительность стремится к нулю.
Что выбираю я
Имея возможность сравнивать, мне ближе офисная история с возможностью гибрида, но я вижу много плюсов от удаленки и для компании и для людей, поэтому у меня к сотрудникам есть простой подход. Адаптация в основном проходит в команде, затем, если человек способен сохранять эффективность на удаленке, то это его право. Конечно, есть ряд работ, которые, по ряду причин, не возможны на удаленке, а у некоторых компаний есть особые требования к удаленке, но это все можно легко узнается на собеседовании.
А какой у вас был опыт удаленной работы? Какие были проблемы, а что понравилось больше, чем в офисе?
Максима Шаламов
#разработчику #тимлиду
Сейчас очень много идет споров и обсуждений на тему “офис против удаленки”. Крупные компании пытаются вернуть сотрудников в офис, в то время, как большинству сотрудников хорошо работается удаленно. Расскажу свою историю и к какому выводу я в итоге пришел.
Как я перешел на полную удаленку
Сам я познакомился с полной удаленкой на старте пандемийных проблем. У нас была довольно зрелая команда, и мы, одни из первых, опробовали возможности полной удаленки. Затем, уже перейдя в ТАСС, я собрал полностью удаленную команду. В целом, на удаленке и с удаленной командой я проработал 3 года (за исключением посещения очных совещаний с руководством компании). Я обустроил удобное рабочее место и зарезервировал интернет. Переход на удаленные коммуникации для моей команды прошел довольно безболезненно. Плюсом мы получили возможность усиливаться ребятами со всей страны, а не только с локации нахождения офиса. Вообще, это был довольно хороший опыт, результаты были достигнуты, какого-то дискомфорта от работы дома не наблюдалось. Однако, когда я искал новую работу, удаленку я не стал ставить обязательным условием и вообще скорее склонялся к возвращению в офис.
Дак как так случилось, если эксперимент получился удачным? Начну лично с моих проблем, а потом перейду к общим для команды.
Проблема командного духа
На удаленке у большинства из нас пропало ощущение, что мы команда. И вернуть это так и не получилось. Новые ребята быстро интегрировались в работу, но не было того ощущения сплоченности для решения поставленной задачи. Если раньше мы довольно хорошо чувствовали, кто начинает выдыхаться и ему нужно отдохнуть или дать смену деятельности, то на удаленке с этим случались проблемы. Естественно мы улучшили уровень удаленной коммуникации, но это не могло заменить эффект от частого неформального общения в офисе. Наверное, это показывает, что есть куда расти в этом плане, но по моим наблюдениям и опросам, эта проблема накрыла многих.
Проблема срочных, критичных задач
Следующей сложностью было то, что какие-то срочные и критичные вещи проще решать собравшись вместе в одном месте. Первое время нештатных ситуаций было много и поток созвонов и зумов затягивал. Бесконечные совместные зумы частично решили проблему, но когда экран пошарить надо было двоим или троим все затягивалось. С учетом, что я в основном беру проекты, которые нужно вытаскивать из сложных ситуаций, эта проблема бьет всегда.
Проблемы участников команды
Если говорить в общем, то на удаленке некоторые люди теряют связь с командой, чувствуют себя в изоляции. Часть людей просто не умеет в домашних условиях спланировать свой день и их производительность стремится к нулю.
Что выбираю я
Имея возможность сравнивать, мне ближе офисная история с возможностью гибрида, но я вижу много плюсов от удаленки и для компании и для людей, поэтому у меня к сотрудникам есть простой подход. Адаптация в основном проходит в команде, затем, если человек способен сохранять эффективность на удаленке, то это его право. Конечно, есть ряд работ, которые, по ряду причин, не возможны на удаленке, а у некоторых компаний есть особые требования к удаленке, но это все можно легко узнается на собеседовании.
А какой у вас был опыт удаленной работы? Какие были проблемы, а что понравилось больше, чем в офисе?
Максима Шаламов
#разработчику #тимлиду
Плюсы и минусы продолжительной работы на одном месте
Плюсы:
- вы получаете возможность расти в глубину. Конечно это здорово попробовать много всего и разного, но не менее увлекательно копать в глубь. Например, только осев в компании надолго, я смог на практике разобраться в тонкостях работы с проектами под разными типами нагрузки, хорошо разобрался в том, как работает postgres и elasicsearch и т.д. Этот опыт для меня оказался ценнее, чем поверхностные изучения кучи разных технологий.
- можете получить опыт в становлении и работе реально сильной и сплоченной команды. Конечно все мы работаем в коллективе. Но, когда часто меняешь работу, не сильно вкладываешься в команду, не всегда даже успеваешь пройти тот этап, когда набор людей реально станет командой. Работа в реально сильной и сплоченной команде - это опыт, который я бы не променял на несколько переходов с повышением. Наша команда формировалась примерно 2 года, после чего костяк не менялся в течении трех лет.
- ощущение сопричастности к результату совершенно другое. Если вы долго работаете над проектом и он становится успешным, то чувство вашей причастности и вклада в результат значительно выше, чем если бы вы поучаствовали в этом год.
- со временем вам становится все проще работать в компании. Вы всех знаете, вас все знают, вы знаете, как и что работает. Соответственно вы тратите минимум времени на условности и рутину (по крайней мере не больше, чем необходимо). Вы становитесь центром знаний и компетенций, к вам ходят за советом и помощью.
Из сложностей можно выделить необходимость в выстраивании долгосрочных отношений в компании, вход в зону комфорта, из которой сложно выйти, также вы можете застрять в неактуальном стеке (если работаете с устаревшими технологиями, которые не собираются менять).
Как и всегда, каждый сам выбирает свой путь. Нет однозначно выигрышной или проигрышной позиции, нужно уметь выжимать максимум из каждой и не упускать свои возможности.
Максим Шаламов
#советы #разработчику #тимлиду
Плюсы:
- вы получаете возможность расти в глубину. Конечно это здорово попробовать много всего и разного, но не менее увлекательно копать в глубь. Например, только осев в компании надолго, я смог на практике разобраться в тонкостях работы с проектами под разными типами нагрузки, хорошо разобрался в том, как работает postgres и elasicsearch и т.д. Этот опыт для меня оказался ценнее, чем поверхностные изучения кучи разных технологий.
- можете получить опыт в становлении и работе реально сильной и сплоченной команды. Конечно все мы работаем в коллективе. Но, когда часто меняешь работу, не сильно вкладываешься в команду, не всегда даже успеваешь пройти тот этап, когда набор людей реально станет командой. Работа в реально сильной и сплоченной команде - это опыт, который я бы не променял на несколько переходов с повышением. Наша команда формировалась примерно 2 года, после чего костяк не менялся в течении трех лет.
- ощущение сопричастности к результату совершенно другое. Если вы долго работаете над проектом и он становится успешным, то чувство вашей причастности и вклада в результат значительно выше, чем если бы вы поучаствовали в этом год.
- со временем вам становится все проще работать в компании. Вы всех знаете, вас все знают, вы знаете, как и что работает. Соответственно вы тратите минимум времени на условности и рутину (по крайней мере не больше, чем необходимо). Вы становитесь центром знаний и компетенций, к вам ходят за советом и помощью.
Из сложностей можно выделить необходимость в выстраивании долгосрочных отношений в компании, вход в зону комфорта, из которой сложно выйти, также вы можете застрять в неактуальном стеке (если работаете с устаревшими технологиями, которые не собираются менять).
Как и всегда, каждый сам выбирает свой путь. Нет однозначно выигрышной или проигрышной позиции, нужно уметь выжимать максимум из каждой и не упускать свои возможности.
Максим Шаламов
#советы #разработчику #тимлиду
О чем еще нужно помнить
Нужно помнить, что наша задача, как руководителей, организовать успех в рамках своих полномочий. Это и найм нужных людей, и своевременные релизы и т.д. и т.п. В идеале, вы должны делать работу под ключ на своем уровне (важно что свою и на своем уровне). Если сделать можно, то найти способ преодолеть все преграды, если нет, то вовремя сообщить об этом и предложить варианты решения проблемы.
Обязательно нужно быть готовым к различным спорам, конфликтам, обидам, завистям, эскалациям и прочим видам не самых приятных взаимодействий. Всегда решить все мирно и дружно вряд ли возможно и нужно. В баланс к этому, нужно учиться и искать компромиссы и договариваться, иначе вы утонете в склоках и конфликтах. Здесь нужно искать золотую середину.
В завершении я могу сказать, что работа руководителя не для всех. Многим это просто не нужно, просто есть стереотип, что счастье оно в этом. Занимайтесь тем, что вам действительно нравится, тем более, что в ИТ хорошие деньги получают и не руководители, а в крупных компаниях есть вертикали специалистов, для тех, кто не хочет руководить, но хочет роста.
Максим Шаламов
#тимлиду #разработчику
Нужно помнить, что наша задача, как руководителей, организовать успех в рамках своих полномочий. Это и найм нужных людей, и своевременные релизы и т.д. и т.п. В идеале, вы должны делать работу под ключ на своем уровне (важно что свою и на своем уровне). Если сделать можно, то найти способ преодолеть все преграды, если нет, то вовремя сообщить об этом и предложить варианты решения проблемы.
Обязательно нужно быть готовым к различным спорам, конфликтам, обидам, завистям, эскалациям и прочим видам не самых приятных взаимодействий. Всегда решить все мирно и дружно вряд ли возможно и нужно. В баланс к этому, нужно учиться и искать компромиссы и договариваться, иначе вы утонете в склоках и конфликтах. Здесь нужно искать золотую середину.
В завершении я могу сказать, что работа руководителя не для всех. Многим это просто не нужно, просто есть стереотип, что счастье оно в этом. Занимайтесь тем, что вам действительно нравится, тем более, что в ИТ хорошие деньги получают и не руководители, а в крупных компаниях есть вертикали специалистов, для тех, кто не хочет руководить, но хочет роста.
Максим Шаламов
#тимлиду #разработчику
Командность
Все мы работаем в команде и нужно учиться взаимодействовать с людьми, работать в рамках принятых процессов. Выражать свое несогласие и критику нужно уметь, ровно как и участвовать в изменениях процессов. Я люблю работать с людьми с характером и внутренним стержнем, но если они отталкиваются от вводных, что все хуже их и они делают своим присутствием всем одолжение, то обычно ждать от них эффективной работы не приходится. Умение работать в команде и с людьми приходит с опытом. Обычно тут нужно проявлять терпение (если человек не переходит границ) и помогать человеку. Большинство моих ребят хотели и старались развиваться в этом направлении, но это занимало годы. Были и те, кому это было не надо, мы просто переставали работать вместе.
Субординация
Под этим пунктом я не имел ввиду парадигму “я начальник, ты дурак”. Тут заложен смысл о том, что все внутренние договоренности должны соблюдаться, пока они не были изменены. И ты не ставишь свое мнение выше мнения команды, а работаешь в рамках этой команды. Убедил всех - молодец. Также за начальником остается последнее слово в случаи спорных ситуаций (за моими я естественно тоже оставляю право финального слова). Если говорить о себе, то я не люблю залезать в те решения, которые на мой взгляд должны приниматься не мной. Но, если я вижу критичную проблему или есть неразрешимый спор, то беру это на себя.
Каждый сам ставит приоритеты и идет по ним, я поделился своим видением. Надеюсь вам было полезно.
Максим Шаламов
#тимлиду #разработчику
Все мы работаем в команде и нужно учиться взаимодействовать с людьми, работать в рамках принятых процессов. Выражать свое несогласие и критику нужно уметь, ровно как и участвовать в изменениях процессов. Я люблю работать с людьми с характером и внутренним стержнем, но если они отталкиваются от вводных, что все хуже их и они делают своим присутствием всем одолжение, то обычно ждать от них эффективной работы не приходится. Умение работать в команде и с людьми приходит с опытом. Обычно тут нужно проявлять терпение (если человек не переходит границ) и помогать человеку. Большинство моих ребят хотели и старались развиваться в этом направлении, но это занимало годы. Были и те, кому это было не надо, мы просто переставали работать вместе.
Субординация
Под этим пунктом я не имел ввиду парадигму “я начальник, ты дурак”. Тут заложен смысл о том, что все внутренние договоренности должны соблюдаться, пока они не были изменены. И ты не ставишь свое мнение выше мнения команды, а работаешь в рамках этой команды. Убедил всех - молодец. Также за начальником остается последнее слово в случаи спорных ситуаций (за моими я естественно тоже оставляю право финального слова). Если говорить о себе, то я не люблю залезать в те решения, которые на мой взгляд должны приниматься не мной. Но, если я вижу критичную проблему или есть неразрешимый спор, то беру это на себя.
Каждый сам ставит приоритеты и идет по ним, я поделился своим видением. Надеюсь вам было полезно.
Максим Шаламов
#тимлиду #разработчику