Комментарии 21
Интересно какой в Купере burnout rate и статистика по увольнениям
"Самонаводящийся боец продолжал бы раз в день-два спрашивать, как поживает его задача и пушил ее дальше. " - быть пинальщиком это не работа инженера, это всякие PM и прочие администраторы.
Положить задачу в чужой бэклог так чтобы ее взяли ,при этом забив на свои задачи чтобы ее выполнить? )) -- Ну серьезно что ли? Это решаетвся тимлидами и,чаще всего ,с привлечением вышестоящего начальства.
Мне не пофиг -но шевелить я буду своего менеджера ,а не делать его работу.
Софтскиллы нужны тем,у кого с хардскиллами плохо )
В общем, в этом и различие. Самонаводимый человек считает, что его работа — это доставить ценность клиенту.
А если для того, чтобы толкнуть задачу, нужны тимлиды и вышестоящее руководство, то это приведет к росту сроков и тонне лишней коммуникации на ровном месте.
С таким человеком, конечно, менеджеру работать проще - чего там, чувак за свою ЗП тянет ещё немножко и менеджерскую часть работы, но в сознании исполнителей часто присутствует иерархия: "чего это мне тут кто-то кидает работу, у меня своих дел, поставленных начальством, по горло". И задача пропадает, а менеджер потом руками разводит:"А кто мне сказал?" Я вообще замечал у менеджеров такую привычку - размазать свои обязанности по подчинённым и таким образом ещё и ответственности избежать - инициатива же наказуема...
А вот тут мы подбираемся к вопросу о хорошем процессе поставки ценности. Если на сотруднике одновременно висит сразу несколько задач и это происходит регулярно, такой процесс нельзя назвать хорошим. Можно выставить WIP-лимит или ограничить поток входящих задач, потому что незавершенная работа — это яд, который постепенно разъедает проект.
И разводить руками менеджеру тут нельзя, его прямая задача — не допустить подобных ситуаций. Хорошего руководителя отличает понимание, что процессные проблемы — это именно его проблемы, и решать их надо ему. Но не любой блокер является процессной проблемой.
"Если на сотруднике одновременно висит сразу несколько задач и это происходит регулярно, такой процесс нельзя назвать хорошим." Странно, по собственному опыту мог бы сказать, что как правило на сотруднике висит не просто несколько, а много задач, причём часть из них напрямую связаны с его рутинными должностными обязанностями, а часть - с входящими внеплановыми задачами... То есть, может быть, идеально отлаженный рабочий процесс теоретически и можно представить, но на практике так, по-моему, не бывает. Да и нет ничего катастрофического в наличии у работников некоего пула текущих задач, главное, чтобы работник четко представлял, что он может отложить в сторону, на что переключиться, а что нельзя просто бросить посередине - а это значит, что всякого рода дедлайны должны достаточно гибкими и предполагающими разделение ответственности за них между менеджером и работником, чтобы не вводить последнего в перманентно стрессовое состояние...
А если для того, чтобы толкнуть задачу, нужны тимлиды и вышестоящее руководство
То это правильно постренный процесс управления. У рядового сотрудника нет никаких полномочий ставить задачи другим отделам и контролировать их выполнение. У другого отдела есть план и свои задачи. Если есть задача для другого отдела, сотрудник обращается к тимлиду своей команды, он идет к тимлиду другой команды, тимлид другой команды на выделенном для планирования созвоне добавляет ее в план и контролирует выполнение. Тогда, если задача оказалсь просрочена, то ответственный за это тимлид/менеджер другой команды, он не выполнил свои обязанности.
Каких только причин менеджеры не придумают, лишь бы не делать свою работу.
то это приведет к росту сроков и тонне лишней коммуникации на ровном месте
У вас в примере к росту сроков привело противоположное действие. Не видите проблем в своей логике? Можно жаловаться, какие разработчики плохие, не хотят делать менеджерскую работу, а можно выстроить процессы так, чтобы этого не происходило.
О правильность процесса можно сломать много копий. Мой взгляд: эффективнее наладить взаимодействие между командами и отделами, чем любое взаимодействие вести через руководителя.
Если у разработчика возникла необходимость получить помощь другой команды, например, допилить API их сервиса, то он может пойти и к тимлиду другой команды, и к линейному сотруднику. Оба могут на следующем PBR'е, груминге или даже дейлике внести таску в бэклог спринта (некоторые команды закладывают время на непредвиденные задачи в спринт) или заложить капасити на следующий спринт. Мы живем в мире распределенных систем, и сервисы взаимодействуют друг с другом — поэтому взаимодействие людей неизбежно. Как бы программист не продумал API сервиса, доработки и фиксы будут.
Такой подход работает быстрее, потому что меньше оверхэд на коммуникацию.
Такой подход снижает басфактор, потому что не все упирается в тимлида. Что если тимлид заболеет? Команда будет отрезана от внешнего мира, потому что контакты не налажены.
Такой подход расширяет знание самой команды о сервисах вне ее скоупа. Это полезно и для архитектуры, и в случае инцидента.
Такой подход поможет вырастить людей, которым интересен дальнейший рост в менеджмент.
Тогда, если задача оказалсь просрочена, то ответственный за это тимлид/менеджер другой команды, он не выполнил свои обязанности.
Мне удобнее считать, что за свою задачу отвечаю я, и самый заинтересованный в выполнении человек — тоже я. Менеджер другой команды может забыть, отвлечься, потерять блокнотик с записями, многое может произойти. Так что даже если часть моей задачи лежит в бэклоге другой команды, убедиться, что по ней есть прогресс должен тоже я. Главное, не возводить это в чайка-менеджмент и микро-контроль. Важна умеренность.
Не видите проблем в своей логике?
Искренне — нет. Не троллю :) Если более явно подсветите, будет здорово.
можно выстроить процессы так, чтобы этого не происходило.
Соглашусь, но только в определенных условиях. В реальной жизни команды меняются, компания может нанять целые отделы, которые еще не влились в выстроенные процессы. Тот же тимлид может уволиться и его преемнику потребуется время, чтобы влиться в процессы. Как бы не был крут онбординг, он займет время.
Я люблю повторять, что hope — is not a strategy (спер у гугла) и лучше убедиться, что задачу взяли в работу, чем надеятся, что ее взяли в работу. Тем более, если процессы хорошие, для этого достаточно просто зайти на доску команды и увидеть свою задачу в To Do и потом в In Progress. Это не займет более одной минуты. Тем более, что у любого процесса есть свои точки роста и абсолютного идеала, где все работает как часы, даже условная Toyota не достигла.
Такой подход работает быстрее, потому что меньше оверхэд на коммуникацию.
Ну как это работает, если вы сами привели пример, что не работает. А всего-то надо было, чтобы тимлид сказал тимлиду, а не разработчик разработчику.
Что если тимлид заболеет?
Вы прикалываетесь что-ли?) Еще и менеджером называетесь. Если тимлид заболеет, назначается тот, кто будет выполнять его обязанности. Процесс остается тем же.
Мне удобнее считать, что за свою задачу отвечаю я, и самый заинтересованный в выполнении человек — тоже я.
При чем тут ваша задача, если разговор про задачу другому человеку из другой команды? Она связана с вашей, но это другая задача.
Хотите быть менеджером - пожалуйста, непонятно, почему вы ждете это от всех разработчиков.
Менеджер другой команды может забыть, отвлечься, потерять блокнотик с записями, многое может произойти.
Неважно, что может произойти, важно, что управление задачами команды это его прямая обязанность, и причина, по которой он получает зарплату.
убедиться, что по ней есть прогресс должен тоже я
У вас как разработчика есть свои задачи, за которые вы получаете зарплату. Если вы будете заниматься посторонними вещами, ваши задачи не будут выполнены в срок, что плохо для проекта и компании.
Если более явно подсветите, будет здорово.
Я это сделал в предыдущем комментарии. Вы предлагаете способ как избежать роста сроков, при этом сами приводите пример, как он привел к росту сроков.
Тот же тимлид может уволиться и его преемнику потребуется время, чтобы влиться в процессы.
И? Я не понимаю, как это связано с моими словами. Если он не знает, к кому обращаться, пусть пойдет и спросит, хоть у того же разработчика.
и лучше убедиться, что задачу взяли в работу, чем надеятся, что ее взяли в работу
Я не говорил про надежду, что за подмена понятий. Есть человек, чьей обязанностью является убеждаться и контролировать, и это тимлид или менеджер проекта. Тот, кто имеет полномочия ставить задачи разработчикам.
Это не займет более одной минуты.
И? Я не понимаю, как из этого следует, что эту минуту должен тратить не тот, в чьи обязанности это входит.
И нет, это не одна минута. Разработчик зашел, увидел, что задача еще в To Do, потратил еще 2 минуты на сообщение вида "Привет, что там с задачей?", начал делать свою задачу 10 минут, потом ему пришел ответ, он отвлекся, прочитал его, выпал из контекста, потратил еще 8 минут, что вернуться обратно в контекст. В итоге минус полчаса, 6% рабочего времени. А что в это время делает тимлид? Ничего не делает.
Ох уж этот локус контроля ... Лучше бы его не было совсем
«Расскажи про свой самый большой провал. Что привело тебя к нему?» — максимально лобовой вопрос. Если виноваты вообще все, кроме самого человека это повод копнуть глубже, но делайте выводы лишь на основании одного ответа!
«Расскажи про случаи, когда не удалось выстроить отношения с другой командой или человеком». Если соискатель обвиняет лишь другую сторону, это не здорово. Часто в проваленной коммуникации виноваты обе стороны, здорово, если соискатель подсветит эти моменты.
Существует вероятность, что если в провалах обвинять только себя, то на собеседовании просто откажут такому кандидату. "Зачем он нужен, если такие ошибки делает..."
Статья мне понравилась, буду учитывать данные скиллы и вопросы на собеседованиях...
P.S. "Проактивность" не нравиться ичарам. У меня уже было несколько случаев, когда я несколько дней ждал результатов по моему отклику на вакансию, потом звонил или писал в компанию ичару. В результате через несколько минут приходил отказ по вакансии.
На интервью кампания смотрит кандидата, а кандидат — компанию. Если так получается, что в компании не принято брать ответственность за ошибки, а к самим ошибкам относятся как к чему-то непростительному и пытаются замести под ковер, для меня это стало бы красным флагом :)
Ошибка — это шанс стать лучше. Главное, чтобы одни и те же ошибки не повторялись из раза в раз, вот это действительно печально.
https://youtu.be/KV0h0j0eCSM?si=tV3t9kk5QpN6pXRv
Мастеркласс по перекладыванию ответственности с руководства на разработку
Можно статью переименовать "Как нанять сотрудника который будет выполнять обязанности менеджера и не подозревать об этом"
Для меня странно требовать от сотрудников другого отдела выполнения своей работы. У них есть менеджер, который ставит им задачи и возможно моя задача не самая приоритетная. Все что мне нужно сделать, это сообщить моему менеджеру что моя часть работы сделана.
Инициативность это конечно хорошо, но часто для этого есть аналитики или техлид, которые планируют изменения и развитие проектов. Кроме того, далеко не все менеджеры в восторге от того что часть процессов проходит мимо них, как например в случае пообщаться с коллегами из других отделов
Скорее, все три заявленных качества нужны сотруднику, который претендует на сеньора и лида. Но ждать от среднего сотрудника это не нужно, всё равно на рынке их сильно меньше половины. Разве что локус контроля в той или иной степени проверить, если человек совсем инфантильный, то брать не стоит даже джуном
Если у вашей команды или отдела проблема, готовьтесь услышать на 1-1 критику в ваш адрес.
Если у вашей команды или отдела проблема, то есть лайфхак - не проводить встречи 1-1
Как увидеть три важнейших софт-скилла, чтобы нанять лучшего инженера