Не хотел создать впечатление будто должно быть большое количество митингов в первые недели. Наоборот, я вижу, чтобы количество дополнительных митингов сильно меньше.
Как было у меня по митингам для новичка: 1. Стандартные: daily, планирование, ретро, ревью 2. В первую неделю два дополнительных 30 минутных митинга - первый по системам и организации; второй по плану и ожиданиям 3. 1on1, но каждую неделю первые 3-4 недели, вместо раз в две недели. Потом раз в две недели. Длится 15-20 минут 4. С СЕО и техдиром. Занимает 15-30 минут.
Знакомство внутри команды происходит во время первого daily и во время ревью с кем не было возможности познакомиться на daily. Не занимает много времени - 5-10 минут в целом.
И упор в подходе не на том, чтобы новичок показывал себя в виде "передовика производства", а чтобы он чувствовал себя принятым в процессы команды и не создавалось барьера потом.
На самом деле, вы именно тот, кого я и искал, кто поможет мне отточить подачу постов так, чтобы они заходили большему количеству людей :) -------------------------------------------------------------------------------------------------------------------------
Где вы увидели утверждение в моих словах? Там стоит слово “если”, которое как раз обуславливает моё предположение, иначе мне совсем неясно зачем заниматься критикой без оснований. -------------------------------------------------------------------------------------------------------------------------
Дальше, я не задавал вопрос, почему жёстко, я задал вопрос, почему вообще критика с вашей стороны. Критики бывают разные, бывают те, кто как раз “блаблабла”, бывают те, кто несмотря на жесткую подачу, дают конструктив. Надеюсь вы из второго числа. -------------------------------------------------------------------------------------------------------------------------
После этого, вы говорите про “потому что вы в первом же предложении в целом, то обидели разработчиков”. Первое предложение это “Меня зовут Андрей Глушко. Я менеджер ИТ проектов, занимаюсь менторством, прошёл путь от разработчика до руководителя, в своих подходах опираюсь в первую очередь на людей, а потом уже на практики.”. Где в этом предложении я обидел кого-то? Я сказал за себя, что я прошёл этот путь, и, что я когда работаю с командой, то опираюсь на запросы людей внутри команды. Где я поставил себя выше?
Хорошо, возможно вы имели в виду первое предложение “На своём опыте я понял, что необходимо найти баланс между вовлечением сотрудника в цели компании и его собственными целями.”. Смысл этого предложения заключается в том, что разным сотрудникам, важно не только давать четкие инструкции, а всё-таки давать пространство для анализа и манёвра, потому что это помогает их продуктивности, им не кажется их работа рутинно и тд. Опять же я не вижу, где я здесь вас задел. -------------------------------------------------------------------------------------------------------------------------
Далее по тексту у вас идёт, как вы говорите “блаблабла”, потому что вновь нет аргумента(аргументов). Вы начали абзац с одного, говоря что мои статьи портят представление о хороших РП - {Ну а во вторых такие статьи портят и без того ОЧЕНЬ скудным мир толковых руководителей}. Внутри того же предложения переключились на то, что мои стать дают плохое направление для новичков - {на старте их отправляют туда, куда лучше не ходить и в целом рисуют им корявую парадигму}. Потом решили упомянуть, что по какой-то причине неделя такая на хабре. А закончили совсем другим - {тут иногда и покритиковать могут}. В итоге я не понял ни одной темы, что вы упомянули. -------------------------------------------------------------------------------------------------------------------------
Теперь к этому {имхо, вы видели статьи про докер стратегические?). Банальный пример(утрированный) стратегической задачи по докеру: “Нам необходимо уменьшить время от фидбека клиента до релиза изменений запрашиваемых в фидбеке, докер нам может позволить быстрее пересоздавать environment, если какие-либо изменения в коде происходят. Товарищ Вася, пожалуйста контейнеризируй наш сервис”.
Чтобы я всё это написал и расписал мне требуется время. К сожалению я не могу внутри одной статьи описать проблему со всех сторон, учитывая все детали, расписывая каждый возможный кейс, древо моих мыслей и так далее. -------------------------------------------------------------------------------------------------------------------------
Я не обижаюсь. Я люблю критику, критика это хорошо. Но я люблю конструктивную критику, а не основанную на аргументе, что я не расписал внутри статьи множество вещей, о которых мог бы написать. ------------------------------------------------------------------------------------------------------------------------- Как итог. Вы сами понимаете, что именно вы хотите от меня? Если да, то, пожалуйста, напишите мне конкретно, что именно и где именно не так внутри моей статьи
Это ли не командная работа, когда каждый делает то, что у него получается лучше всего? А там уже и практики создания кросс функциональных команд пригодятся, чтобы процессы не завязывались на одном конкретном человеке
Хорошее замечание. Мой пост действительно не рассказывает про эту часть взаимодействия с сотрудником. У меня есть в планах написать статью про тему, как удерживать сотрудника или лучше сказать, как заинтересовать сотрудника задачами фирмы.
Если вкратце, то в своём подходе я пытаюсь достигнуть хорошей рабочей атмосферы через две вещи. Первое, при найме я дополнительно разговариваю с кандидатом о рабочих принципах, давая ему ситуации, после чего спрашиваю как бы он действовал в них. Так, я по крайней мере набираю людей, которые близки мне по "вайбу". Через это мы сможем легче договариваться. А второе - это уже через открытость к дискуссиям, мы стараемся прийти к компромиссам между его желаниями и тем, что я могу дать внутри проекта, во время нашей совместной работы.
Всё равно ведь в течение проекта потребуется проанализировать разные методы выполнения задачи, проанализировать пути разработки(грубо говоря, нужны ли нам конкретно сейчас микросервисы или нет), также будет возможность сделать презентацию для демо и провести презентацию во время демо, и так далее. Так и появится некая "не рутинность" для сотрудника
Вы правы, что некоторые фирмы этим злоупотребляют и включают эти метрики в УТП, когда продают свой сервис клиентами или стейкхоледрам, хотя на деле это просто цифры. Однако, у меня есть оптимистические ожидания того, что такой подход в некоторых фирмах будет постепенно уходить в прошлое.
Если говорить про ответственность, когда эти метрики не удовлетворяются, то как раз плюшки по гарантии и могут быть причиной для клиента выбрать вас. Вспомните обычные ритейл магазины, раньше там не было ни обмена, ни возврата, могли ещё и не оригинал подсунуть. Сейчас уже почти стандарт, что в случае брака или причины "не понравилось", покупатель сможет вернуть товар и не понесет финансовых потерь.
Почему я делаю такое сравнение? Потому что ИТ услуги по сути тоже ритейл(компания закупает рабочую силу дешевле, а продаёт результаты рабочей силы дороже), но намного более сложного товара. И этот товар требует, мне кажется, больше времени, чтобы вокруг него организовались стандарты и регуляции в случае обмана или недобросовестного исполнения со стороны "продавца".
Согласен, критерии приёмки важны при постановке задачи. Статью можно было бы дополнить этим. При этом, в разных постановках задачи будут разные примеры критериев
Не хотел создать впечатление будто должно быть большое количество митингов в первые недели. Наоборот, я вижу, чтобы количество дополнительных митингов сильно меньше.
Как было у меня по митингам для новичка:
1. Стандартные: daily, планирование, ретро, ревью
2. В первую неделю два дополнительных 30 минутных митинга - первый по системам и организации; второй по плану и ожиданиям
3. 1on1, но каждую неделю первые 3-4 недели, вместо раз в две недели. Потом раз в две недели. Длится 15-20 минут
4. С СЕО и техдиром. Занимает 15-30 минут.
Знакомство внутри команды происходит во время первого daily и во время ревью с кем не было возможности познакомиться на daily. Не занимает много времени - 5-10 минут в целом.
И упор в подходе не на том, чтобы новичок показывал себя в виде "передовика производства", а чтобы он чувствовал себя принятым в процессы команды и не создавалось барьера потом.
Вообще, мне непонятно, почему статья не зашла.
Прям по пунктам буду отвечать
На самом деле, вы именно тот, кого я и искал, кто поможет мне отточить подачу постов так, чтобы они заходили большему количеству людей :)
-------------------------------------------------------------------------------------------------------------------------
Где вы увидели утверждение в моих словах? Там стоит слово “если”, которое как раз обуславливает моё предположение, иначе мне совсем неясно зачем заниматься критикой без оснований.
-------------------------------------------------------------------------------------------------------------------------
Дальше, я не задавал вопрос, почему жёстко, я задал вопрос, почему вообще критика с вашей стороны. Критики бывают разные, бывают те, кто как раз “блаблабла”, бывают те, кто несмотря на жесткую подачу, дают конструктив. Надеюсь вы из второго числа.
-------------------------------------------------------------------------------------------------------------------------
После этого, вы говорите про “потому что вы в первом же предложении в целом, то обидели разработчиков”. Первое предложение это “Меня зовут Андрей Глушко. Я менеджер ИТ проектов, занимаюсь менторством, прошёл путь от разработчика до руководителя, в своих подходах опираюсь в первую очередь на людей, а потом уже на практики.”. Где в этом предложении я обидел кого-то? Я сказал за себя, что я прошёл этот путь, и, что я когда работаю с командой, то опираюсь на запросы людей внутри команды. Где я поставил себя выше?
Хорошо, возможно вы имели в виду первое предложение “На своём опыте я понял, что необходимо найти баланс между вовлечением сотрудника в цели компании и его собственными целями.”. Смысл этого предложения заключается в том, что разным сотрудникам, важно не только давать четкие инструкции, а всё-таки давать пространство для анализа и манёвра, потому что это помогает их продуктивности, им не кажется их работа рутинно и тд. Опять же я не вижу, где я здесь вас задел.
-------------------------------------------------------------------------------------------------------------------------
Далее по тексту у вас идёт, как вы говорите “блаблабла”, потому что вновь нет аргумента(аргументов). Вы начали абзац с одного, говоря что мои статьи портят представление о хороших РП - {Ну а во вторых такие статьи портят и без того ОЧЕНЬ скудным мир толковых руководителей}. Внутри того же предложения переключились на то, что мои стать дают плохое направление для новичков - {на старте их отправляют туда, куда лучше не ходить и в целом рисуют им корявую парадигму}. Потом решили упомянуть, что по какой-то причине неделя такая на хабре. А закончили совсем другим - {тут иногда и покритиковать могут}. В итоге я не понял ни одной темы, что вы упомянули.
-------------------------------------------------------------------------------------------------------------------------
Теперь к этому {имхо, вы видели статьи про докер стратегические?). Банальный пример(утрированный) стратегической задачи по докеру: “Нам необходимо уменьшить время от фидбека клиента до релиза изменений запрашиваемых в фидбеке, докер нам может позволить быстрее пересоздавать environment, если какие-либо изменения в коде происходят. Товарищ Вася, пожалуйста контейнеризируй наш сервис”.
Вот пример статьи, который был в первой строчке запроса в гугл https://bobcares.com/blog/rapid-web-application-deployment-how-to-use-docker-to-reduce-time-to-market/ . Там описывают, как для клиентов важно, чтобы они быстрее получали изменения.
-------------------------------------------------------------------------------------------------------------------------
Чтобы я всё это написал и расписал мне требуется время. К сожалению я не могу внутри одной статьи описать проблему со всех сторон, учитывая все детали, расписывая каждый возможный кейс, древо моих мыслей и так далее.
-------------------------------------------------------------------------------------------------------------------------
Я не обижаюсь. Я люблю критику, критика это хорошо. Но я люблю конструктивную критику, а не основанную на аргументе, что я не расписал внутри статьи множество вещей, о которых мог бы написать.
-------------------------------------------------------------------------------------------------------------------------
Как итог. Вы сами понимаете, что именно вы хотите от меня? Если да, то, пожалуйста, напишите мне конкретно, что именно и где именно не так внутри моей статьи
Это ли не командная работа, когда каждый делает то, что у него получается лучше всего? А там уже и практики создания кросс функциональных команд пригодятся, чтобы процессы не завязывались на одном конкретном человеке
Я рад, если моя статья помогла вам выплеснуть энергию внутри и вам стало от этого лучше/легче
Если отвечать на ваш комментарий, то мне непонятно как вы смогли сделать такой быстрый вывод обо мне, прочитав только одну статью
Хорошее замечание. Мой пост действительно не рассказывает про эту часть взаимодействия с сотрудником. У меня есть в планах написать статью про тему, как удерживать сотрудника или лучше сказать, как заинтересовать сотрудника задачами фирмы.
Если вкратце, то в своём подходе я пытаюсь достигнуть хорошей рабочей атмосферы через две вещи. Первое, при найме я дополнительно разговариваю с кандидатом о рабочих принципах, давая ему ситуации, после чего спрашиваю как бы он действовал в них. Так, я по крайней мере набираю людей, которые близки мне по "вайбу". Через это мы сможем легче договариваться. А второе - это уже через открытость к дискуссиям, мы стараемся прийти к компромиссам между его желаниями и тем, что я могу дать внутри проекта, во время нашей совместной работы.
Всё равно ведь в течение проекта потребуется проанализировать разные методы выполнения задачи, проанализировать пути разработки(грубо говоря, нужны ли нам конкретно сейчас микросервисы или нет), также будет возможность сделать презентацию для демо и провести презентацию во время демо, и так далее. Так и появится некая "не рутинность" для сотрудника
Спасибо за обратную связь. Я добавил себе в закладки эту тему. Заранее могу сказать, что там тоже много подводных камней :)
Вы правы, что некоторые фирмы этим злоупотребляют и включают эти метрики в УТП, когда продают свой сервис клиентами или стейкхоледрам, хотя на деле это просто цифры. Однако, у меня есть оптимистические ожидания того, что такой подход в некоторых фирмах будет постепенно уходить в прошлое.
Если говорить про ответственность, когда эти метрики не удовлетворяются, то как раз плюшки по гарантии и могут быть причиной для клиента выбрать вас. Вспомните обычные ритейл магазины, раньше там не было ни обмена, ни возврата, могли ещё и не оригинал подсунуть. Сейчас уже почти стандарт, что в случае брака или причины "не понравилось", покупатель сможет вернуть товар и не понесет финансовых потерь.
Почему я делаю такое сравнение? Потому что ИТ услуги по сути тоже ритейл(компания закупает рабочую силу дешевле, а продаёт результаты рабочей силы дороже), но намного более сложного товара. И этот товар требует, мне кажется, больше времени, чтобы вокруг него организовались стандарты и регуляции в случае обмана или недобросовестного исполнения со стороны "продавца".
Согласен, критерии приёмки важны при постановке задачи. Статью можно было бы дополнить этим. При этом, в разных постановках задачи будут разные примеры критериев
imho, крайне сырая статья. Очень многие аспекты не объясняются. Готов обсудить какие именно пункты не раскрыты.