Ты можешь не все
Давно хотел написать на тему ограниченных возможностей человека и более адекватного подхода к своим возможностям. В последнее время, в очередной раз лично переживал тонкости этой темы и решил поделиться своими мыслями. Возможно кому-то будет полезно.
Реакция на неудачу
Есть две очевидные реакции на неудачи. Винить себя и винить других. Любые крайности в виде следования только одному из вариантов приведут не к самым лучшим последствиям. Давайте разберем обе крайности.
Вариант первый: винить других
Винить других всегда очень просто и главное очень просто убедить себя в том, что кто-то не прав. Я думаю все встречались с людьми, которые очевидно не правы и при этом никогда в этом не признаются. Более того, многие руководители вообще считают, что нельзя признавать свои ошибки, и, как бы смешно или печально это не выглядело, будут стоять на том, что виновен кто угодно, но не они. Очевидной проблемой данного подхода является отсутствие критического взгляда на себя и свои действия. Это значит, что ошибки будут кочевать из ситуации в ситуацию. С другой стороны, если человек умен и хитер, то продвигаться он будет довольно лихо. Имея дело с такими людьми, учтите, что они очень много времени потратят на подготовку обоснования того, что они не виноваты и будут искать все способы обвинить других. Хотите чувствовать себя спокойно - максимально подробно и своевременно фиксируйте все детали хода проекта и договоренности.
Второй вариант: искать проблему в себе
Второй вариант реакции на неудачу: в любой ситуации искать проблемы в себе. Если я и утрирую, то не очень сильно. Эта проблема мне очень близка, в любой ситуации я в первую очередь смотрю, что я мог сделать лучше, как я мог чего-то избежать. В итоге, это очень эмоционально перегружает. Да, вы много анализируете и учитесь, это прекрасно, но в тоже время вы можете погрязнуть в излишних самокопаниях и негативе. Попадая в такую проблему, помните, что не все зависит от вас. Ваши возможности ограничены и с этим нужно смириться, но в другой раз вы сможете лучше. Я делаю следующее упражнение. Задаю себе вопрос: "все ли сделано, что от меня зависело?". Если да, то смысла винить себя нет. Если нет, то нужно понять, почему не получилось приложить все усилия и сделать вывод на следующий раз.
Что эффективно сделать
Естественно, нет универсального ответа на любую проблему. Прежде чем винить себя или других, разберитесь в ситуации. Восстановите картину случившегося со своей стороны и со стороны участников процесса. Найдите моменты, которые были сделаны неправильно или которые можно улучшить. Постарайтесь зафиксировать системно эти изменения, чтобы не допустить рецидивов. И так отрабатывайте каждую проблему, каждую неудачу. Просто винить себя или других, но главное это извлекать пользу и опыт из своих неудач и в следующий раз все получится, как надо.
Максим Шаламов
#тимлиду
Давно хотел написать на тему ограниченных возможностей человека и более адекватного подхода к своим возможностям. В последнее время, в очередной раз лично переживал тонкости этой темы и решил поделиться своими мыслями. Возможно кому-то будет полезно.
Реакция на неудачу
Есть две очевидные реакции на неудачи. Винить себя и винить других. Любые крайности в виде следования только одному из вариантов приведут не к самым лучшим последствиям. Давайте разберем обе крайности.
Вариант первый: винить других
Винить других всегда очень просто и главное очень просто убедить себя в том, что кто-то не прав. Я думаю все встречались с людьми, которые очевидно не правы и при этом никогда в этом не признаются. Более того, многие руководители вообще считают, что нельзя признавать свои ошибки, и, как бы смешно или печально это не выглядело, будут стоять на том, что виновен кто угодно, но не они. Очевидной проблемой данного подхода является отсутствие критического взгляда на себя и свои действия. Это значит, что ошибки будут кочевать из ситуации в ситуацию. С другой стороны, если человек умен и хитер, то продвигаться он будет довольно лихо. Имея дело с такими людьми, учтите, что они очень много времени потратят на подготовку обоснования того, что они не виноваты и будут искать все способы обвинить других. Хотите чувствовать себя спокойно - максимально подробно и своевременно фиксируйте все детали хода проекта и договоренности.
Второй вариант: искать проблему в себе
Второй вариант реакции на неудачу: в любой ситуации искать проблемы в себе. Если я и утрирую, то не очень сильно. Эта проблема мне очень близка, в любой ситуации я в первую очередь смотрю, что я мог сделать лучше, как я мог чего-то избежать. В итоге, это очень эмоционально перегружает. Да, вы много анализируете и учитесь, это прекрасно, но в тоже время вы можете погрязнуть в излишних самокопаниях и негативе. Попадая в такую проблему, помните, что не все зависит от вас. Ваши возможности ограничены и с этим нужно смириться, но в другой раз вы сможете лучше. Я делаю следующее упражнение. Задаю себе вопрос: "все ли сделано, что от меня зависело?". Если да, то смысла винить себя нет. Если нет, то нужно понять, почему не получилось приложить все усилия и сделать вывод на следующий раз.
Что эффективно сделать
Естественно, нет универсального ответа на любую проблему. Прежде чем винить себя или других, разберитесь в ситуации. Восстановите картину случившегося со своей стороны и со стороны участников процесса. Найдите моменты, которые были сделаны неправильно или которые можно улучшить. Постарайтесь зафиксировать системно эти изменения, чтобы не допустить рецидивов. И так отрабатывайте каждую проблему, каждую неудачу. Просто винить себя или других, но главное это извлекать пользу и опыт из своих неудач и в следующий раз все получится, как надо.
Максим Шаламов
#тимлиду
Верхнеуровневая и точная оценка сроков
Сегодня хотел бы поговорить об оценке сроков, как со стороны исполнителя, так и со стороны руководителя. Последние 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 раз, это повод взвесить все за и против и выстроить работу вокруг принятых решений. Главное - это правильная коммуникация. Такие вопросы должны ставиться не с целью навязать что-то, а с целью поиска лучших решений. Соответственно и восприниматься такие вопросы должны спокойно, с целью найти лучшее решение.
Владелец продукта и тимлид должны взять на себя задачи по построению таких коммуникаций и адекватного общения вокруг них. Команду нужно вовлекать и удерживать от конфликтов и неконструктивных отвлечений. Любые идеи, лучше всего, для начала, собирать в каком-то пространстве, а потом собираться для их обсуждения. Постоянно собираться в моменте может быть неэффективно.
Больше таких фишек в работе с командой мы разбираем с участниками моего интенсива для тимлидов. Там и примеры, что делать, если у вас нет формальной должности, и как привести в порядок отдел, где ничего не работает, и многое другое. Приходите, и узнаете больше. Пока больше 7 человек взять не смогу, так что мест не очень много.
Максим Шаламов
#тимлиду #разработчику
Давайте поговорим об одной из важнейших составляющих успеха любой команды или продукта. Сложно назвать это каким-то одним слово, но пусть это будет драйв. Это непрерывное желание и движение к тому, чтобы сделать лучше, больше, превзойти конкурентов и т.д. В каком-то смысле это энергия, на которой идет развитие продукта и команды, то, что заряжает людей и позволяет двигаться вперед. Давайте обсудим то, как его можно поддерживать и какие методы не работают.
На ком должен держаться драйв команды
Я не сильно хотел бы углубляться в материи типа огня в глазах и всего такого. В больших проектах добиться равной большой вовлеченности всех участников команды очень сложно. Поэтому основные участники процесса должны обладать этим качеством и делиться с командой. Это выражается в постоянном поиске и устранении проблем, как в продукте, так и в процессах. Постоянно должны подниматься вопросы, а как сделать лучше, а не можем ли мы сделать быстрее, не должны ли мы доработать идею или выкинуть то, что плохо работает.
Как поддержание драйва не сработает
Обычно такую роль на себя берут владельцы продукта (PO), которые низводят ее до банального хаоса и постоянного давления на команду. Берут больше задач, чем можно сделать, бегают вокруг с вопросами, а когда будет готово, а уже сроки прошли, надо поднажать и т.д. Если не нормализовать этот процесс, то получим хаос, текучку и весьма слабо рабочий проект.
Забавно, но когда такого воздействия на команду нет совсем, результат получается примерно таким же. Наводя порядок в одном из проектов, я обратил внимание, что на команду никогда не давили сроки, никто особо не рвался вперед, все старались работать ровно. К сожалению, это не дало ожидаемого эффекта, команда со временем стала скучать и утратила мотивацию, а перенос сроков ушел за все разумные границы.
А как подпитать драйв в команде правильно?
В итоге, мы получили снова задачу о балансе, как и все в нашей жизни. Что же можно сделать, чтобы вернуть жизнь в ваш проект и по возможности не выжечь себя и других. Выстраивайте коммуникации так, что все идеи не отбрасываются, а обсуждаются в рамках отдельных встреч (или собираются в каком-то месте, с последующим разбором). Отобранные удачные идеи должны попадать в бэклог и реализовываться, это повысит вовлеченность каждого участника команды.
Всегда должны озвучиваться вопросы, а эффективно ли мы хотим что-то делать или делаем, нет ли способов ускориться или сделать лучше. Это не повод жить на работе, или увеличить сроки в 10 раз, это повод взвесить все за и против и выстроить работу вокруг принятых решений. Главное - это правильная коммуникация. Такие вопросы должны ставиться не с целью навязать что-то, а с целью поиска лучших решений. Соответственно и восприниматься такие вопросы должны спокойно, с целью найти лучшее решение.
Владелец продукта и тимлид должны взять на себя задачи по построению таких коммуникаций и адекватного общения вокруг них. Команду нужно вовлекать и удерживать от конфликтов и неконструктивных отвлечений. Любые идеи, лучше всего, для начала, собирать в каком-то пространстве, а потом собираться для их обсуждения. Постоянно собираться в моменте может быть неэффективно.
Больше таких фишек в работе с командой мы разбираем с участниками моего интенсива для тимлидов. Там и примеры, что делать, если у вас нет формальной должности, и как привести в порядок отдел, где ничего не работает, и многое другое. Приходите, и узнаете больше. Пока больше 7 человек взять не смогу, так что мест не очень много.
Максим Шаламов
#тимлиду #разработчику
Фокусировка - держим команду в фокусе
Важнейшей составляющей для любого успешного релиза является фокусировка. Это становится важнее с ростом размера релиза. Чем больший объем функционала вы хотите сделать (тем соответственно больше сроки реализации), тем важнее становится фактор фокусировки.
Мы всего лишь говорим об умении фокусироваться на главном и отбрасывать лишнее. Однако это бывает очень сложно, когда задач много и все они важные и нужные, а помогать выделить критичное никто не спешит.
Поставьте цели
Фокусировка начинается с малого, у каждого спринта или итерации, обязательно должна быть сформулирована цель. Все задачи работающие на выполнение цели, являются приоритетными и задача команды иметь приоритет на их решение. Все остальные задачи должны идти либо после выполнения цели, либо в случае, если у участников команды появляется время (сидеть и смотреть в монитор никому не нужно). Задача лидера команды все время держать фокус на важном. Переложить задачу на бизнес обычно не получается, потому что, в противном случае, задачи будут прибывать и прибывать. Все в команде должны понимать, что не закрытие цели спринта это отклонение от нормы и нужно разбираться в причинах (Как? Это тема отдельного разговора).
Расставьте приоритеты
Говоря про большие релизы, нужно сформировать не только цель, но и четко приоритезировать все задачи, связанные с целью. Приоритезация будет нужна, потому что в больших релизах от части запланированного функционала придется отказаться. Я рекомендую всегда уменьшать функционал, а не двигать сроки. Это позволяет минимально работать в стол и максимально быстро получить обратную связь от пользователей и понять идет ли все по плану или нет. Сдвиги сроков обычно сильно давят на команду и чем дальше, тем будет становиться хуже. Мое мнение на этот вопрос однозначное: ваша задача к дедлайну иметь работающий и отлаженный проект с набором критичного функционала. Очень важно, что работающего и отлаженного функционала, в который можно пускать пользователей. Тогда можно уже обсуждать в деталях, есть ли смысл в том, что получилось, и какой приоритет у доработок и следующих шагов. Если же вы приходите к дедлайну с набором недоделанных фичей, то ни о каком запуске речи быть не может, как и об успешной работе над взятым функционалом.
Что если бизнес не участвует в приоритезации
Если бизнес не может сам ставить приоритеты, то вам придется, слушая их, делать это самим. Тут очень простая логика, вам все равно нужно сделать каждую задачу в надлежащем качестве, поэтому если вы к дедлайну выберите и сделаете определенные, это как минимум ничего не испортит, как максимум - вы сможете запустить проект раньше. Если Бизнес приоритезирует задачи так, что они не влазят, то делаем тоже самое, выстраиваем максимально возможный по приоритету вариант.
В фокусировке важно, чтобы руководитель всегда доносил это до своих подчиненных, чтобы это не уходило у них из головы: есть цели и к ним нужно идти. Мы не должны умирать в пути к цели или делать плохой продукт. Мы должны искать варианты и обходные пути, где это возможно, а где это невозможно уменьшать число фичей или их сложность. Для руководителя очень важно не терять фокус самому и не переставать доносить важность этого до своей команды, тогда все получится. Найдутся и обходные пути, и результат придет.
Максим Шаламов
#тимлиду #agile_который_работает
Важнейшей составляющей для любого успешного релиза является фокусировка. Это становится важнее с ростом размера релиза. Чем больший объем функционала вы хотите сделать (тем соответственно больше сроки реализации), тем важнее становится фактор фокусировки.
Мы всего лишь говорим об умении фокусироваться на главном и отбрасывать лишнее. Однако это бывает очень сложно, когда задач много и все они важные и нужные, а помогать выделить критичное никто не спешит.
Поставьте цели
Фокусировка начинается с малого, у каждого спринта или итерации, обязательно должна быть сформулирована цель. Все задачи работающие на выполнение цели, являются приоритетными и задача команды иметь приоритет на их решение. Все остальные задачи должны идти либо после выполнения цели, либо в случае, если у участников команды появляется время (сидеть и смотреть в монитор никому не нужно). Задача лидера команды все время держать фокус на важном. Переложить задачу на бизнес обычно не получается, потому что, в противном случае, задачи будут прибывать и прибывать. Все в команде должны понимать, что не закрытие цели спринта это отклонение от нормы и нужно разбираться в причинах (Как? Это тема отдельного разговора).
Расставьте приоритеты
Говоря про большие релизы, нужно сформировать не только цель, но и четко приоритезировать все задачи, связанные с целью. Приоритезация будет нужна, потому что в больших релизах от части запланированного функционала придется отказаться. Я рекомендую всегда уменьшать функционал, а не двигать сроки. Это позволяет минимально работать в стол и максимально быстро получить обратную связь от пользователей и понять идет ли все по плану или нет. Сдвиги сроков обычно сильно давят на команду и чем дальше, тем будет становиться хуже. Мое мнение на этот вопрос однозначное: ваша задача к дедлайну иметь работающий и отлаженный проект с набором критичного функционала. Очень важно, что работающего и отлаженного функционала, в который можно пускать пользователей. Тогда можно уже обсуждать в деталях, есть ли смысл в том, что получилось, и какой приоритет у доработок и следующих шагов. Если же вы приходите к дедлайну с набором недоделанных фичей, то ни о каком запуске речи быть не может, как и об успешной работе над взятым функционалом.
Что если бизнес не участвует в приоритезации
Если бизнес не может сам ставить приоритеты, то вам придется, слушая их, делать это самим. Тут очень простая логика, вам все равно нужно сделать каждую задачу в надлежащем качестве, поэтому если вы к дедлайну выберите и сделаете определенные, это как минимум ничего не испортит, как максимум - вы сможете запустить проект раньше. Если Бизнес приоритезирует задачи так, что они не влазят, то делаем тоже самое, выстраиваем максимально возможный по приоритету вариант.
В фокусировке важно, чтобы руководитель всегда доносил это до своих подчиненных, чтобы это не уходило у них из головы: есть цели и к ним нужно идти. Мы не должны умирать в пути к цели или делать плохой продукт. Мы должны искать варианты и обходные пути, где это возможно, а где это невозможно уменьшать число фичей или их сложность. Для руководителя очень важно не терять фокус самому и не переставать доносить важность этого до своей команды, тогда все получится. Найдутся и обходные пути, и результат придет.
Максим Шаламов
#тимлиду #agile_который_работает
Кто должен быть лидером в команде разработки
Давайте сегодня обсудим вопрос кто и почему должен быть лидером в команде (речь о неформальном лидере, кто направляет команду в реальности, а не на бумаге). Варианта у нас всего два тимлид и владелец продукта (Product Owner, ПО). Очень часто в команде складывается ситуация, когда лидер именно владелец продукта. Уверен, что бывают удачные исключения, но я таких не видел и у своих коллег такого не наблюдал. Основная проблема по в том, что им слишком тяжело нащупать внутренний баланс. Они должны гореть идеей дать как можно больше и как можно быстрее, это не то что нормально, это необходимо для активного роста проекта. Но вместе с этим такой подход приведет к ужасному качеству продукта и выгоранию команды.
Почему ПО становится лидером?
Почему же владелец продукта так часто становятся лидерами команды. ПО роль сама по себе очень активная и направляющая. Хочешь не хочешь, а решать куда двигаться продукту или какие фичи брать, будет ПО (не важно как он к этому приходит). Так же ПО отвечает за бизнес показатели своего проекта или его части, поэтому ему реально нужно быстрее и больше, от этого зависит результат его работы, реализация его амбиций, да и банально сохранение своего места. Опять же ПО роль про коммуникации, поэтому обычно у них хорошо подвешен язык. А главное, с ПО не спросят за развалившийся технически проект, он отправит все вопросы к инженерам (по крайней мере попытается и скорее всего успешно).
Почему лидером не становится тимлид?
Что же касается нас с вами, то есть инженеров, обычно многие лиды (особенно начинающие), вполне довольны просто наличием лычки лида, и как-то особо не пытаются проявлять себя, что ПО обычно устраивает. Часто всплывают проблемы с коммуникациями, умение общаться и ясно излагать свои мысли нужно развивать, что хочется не многим. Многие становятся лидами, потому что они были самыми лучшими разработчиками в команде, но они, получив роль, продолжают быть лучшими разработчиками и не более. Ну и главное: многие не могут и не хотят брать на себя ответственность.
Как должно быть?
Однако, я считаю, что в эффективной команде (опять же в жизни бывает всякое) лидером должен быть именно тимлид. Потому что тимлид должен думать о команде, качестве продукта, поддерживаемости и так далее. Это как минимум часть его работы, причем существенная. Тимлид должен балансировать ПО и его неуемное желание бежать вперед.
А не получим ли с тимлидом туже проблему?
Почему же тимлид не сделает перекос в ненужную сторону? Это может случится, но есть несколько моментов. Первое, большинство людей все же приходят делать что-то значимое и стоящее, и сами заинтересованы в том, чтобы продукт выпускался и пользователи были довольны. Мало кто хочет работать в стол. Второе, тут всегда есть естественная балансировка. Мы в компаниях наняты для развития или поддержки проектов, соответственно если кто-то из инженеров встанет на пути развития компании/проекта без видимых причин, его просто уволят. Я общался с немалым количеством компаний, где искали замены своим техническим лидерам (даже тем с кем стартовали проекты и стартапы), потому что они совсем потеряли баланс и новый функционал просто не появлялся. И тут как раз оправдание, что зато работает скорее всего не сработает.
Максим Шаламов
#тимлиду #разработчику
Давайте сегодня обсудим вопрос кто и почему должен быть лидером в команде (речь о неформальном лидере, кто направляет команду в реальности, а не на бумаге). Варианта у нас всего два тимлид и владелец продукта (Product Owner, ПО). Очень часто в команде складывается ситуация, когда лидер именно владелец продукта. Уверен, что бывают удачные исключения, но я таких не видел и у своих коллег такого не наблюдал. Основная проблема по в том, что им слишком тяжело нащупать внутренний баланс. Они должны гореть идеей дать как можно больше и как можно быстрее, это не то что нормально, это необходимо для активного роста проекта. Но вместе с этим такой подход приведет к ужасному качеству продукта и выгоранию команды.
Почему ПО становится лидером?
Почему же владелец продукта так часто становятся лидерами команды. ПО роль сама по себе очень активная и направляющая. Хочешь не хочешь, а решать куда двигаться продукту или какие фичи брать, будет ПО (не важно как он к этому приходит). Так же ПО отвечает за бизнес показатели своего проекта или его части, поэтому ему реально нужно быстрее и больше, от этого зависит результат его работы, реализация его амбиций, да и банально сохранение своего места. Опять же ПО роль про коммуникации, поэтому обычно у них хорошо подвешен язык. А главное, с ПО не спросят за развалившийся технически проект, он отправит все вопросы к инженерам (по крайней мере попытается и скорее всего успешно).
Почему лидером не становится тимлид?
Что же касается нас с вами, то есть инженеров, обычно многие лиды (особенно начинающие), вполне довольны просто наличием лычки лида, и как-то особо не пытаются проявлять себя, что ПО обычно устраивает. Часто всплывают проблемы с коммуникациями, умение общаться и ясно излагать свои мысли нужно развивать, что хочется не многим. Многие становятся лидами, потому что они были самыми лучшими разработчиками в команде, но они, получив роль, продолжают быть лучшими разработчиками и не более. Ну и главное: многие не могут и не хотят брать на себя ответственность.
Как должно быть?
Однако, я считаю, что в эффективной команде (опять же в жизни бывает всякое) лидером должен быть именно тимлид. Потому что тимлид должен думать о команде, качестве продукта, поддерживаемости и так далее. Это как минимум часть его работы, причем существенная. Тимлид должен балансировать ПО и его неуемное желание бежать вперед.
А не получим ли с тимлидом туже проблему?
Почему же тимлид не сделает перекос в ненужную сторону? Это может случится, но есть несколько моментов. Первое, большинство людей все же приходят делать что-то значимое и стоящее, и сами заинтересованы в том, чтобы продукт выпускался и пользователи были довольны. Мало кто хочет работать в стол. Второе, тут всегда есть естественная балансировка. Мы в компаниях наняты для развития или поддержки проектов, соответственно если кто-то из инженеров встанет на пути развития компании/проекта без видимых причин, его просто уволят. Я общался с немалым количеством компаний, где искали замены своим техническим лидерам (даже тем с кем стартовали проекты и стартапы), потому что они совсем потеряли баланс и новый функционал просто не появлялся. И тут как раз оправдание, что зато работает скорее всего не сработает.
Максим Шаламов
#тимлиду #разработчику