Согласна. Изменения нужны, но, скорее, не мы меняем людей, а они сами меняются). А менеджеры создают условия, благоприятную среду. Вот так хороший менеджер и меняет людей: они меняются сами — у них просто не остается выбора. Например, если представить камень, который никак не хочет катиться вперед, лучше не продолжать его пинать (чтобы он поменялся и стал идеальным шаром), а чуть поменять рельеф — подрыть ямку перед ним, сдвинуть с места, переложить на бревна и катить :) Не лучший пример, тк камень и остался камнем, но, надеюсь, мысль понятна. «Пока враг рисует карты местности, мы меняем рельеф! Причем, вручную.» :)
Звучит как сказка, конечно, но по моим скромным эмпирическим данным — работает. И не забывайте расставаться с теми, кто выпадает из вашей культуры полностью. Для блага обоих.
Попробую ответить. Статья, конечно, не задумывалась как полное и исчерпывающее руководство, тк, к сожалению, все очень зависит от конкретного случая и команды. Менеджмент в данном случае далек от теории и близок к практике. Скорее это протест против бездумного охаивания менеджерами «ленивых» разработчиков и попытка заставить из посмотреть на это с другой стороны: может быть проблемы и нет? может быть они и не ленивы вовсе, а у нас с целями что-то не так?
А что если менеджер хочет ЕЩЕ больше результатов?
Ему чтобы развивать компанию, продукт, нужно увеличивать результаты.
Он не может быть перманентно доволен.
Его задача именно выжимать максимум из доступных ресурсов.
Как ему определить, что выжат максимум и что youtube это реально разгрузка, чтобы разработчик не умер, а не простой, лень?
По целям) Выполняются? Значит все отлично. Не выполняются? Давайте разбираться. Как разбираться? Тут уже от ситуации зависит) Хотите выжать больше — меняйте цели. Ваша задача, как менеджера, создать для разработчиков своеобразный фреймворк, в котором они бы прекрасно существовали и пользовались свободой в его рамках. Вага задача — подкручивать его тут и там, чтобы все это достигало определнных целей. Это я сейчас говорю уже о несколько большем, чем «успех проекта», я говорю о компании. Если нам нужен успех проекта — это к ТЗ, как ответили выше.
Планку нужно выставить. Вы не описали как.
Плюс как и с цитатой выше, планка не перманентна, суть развития в повышении планки.
Поэтому всегда есть, что исправлять.
Но где пределы? Где предел максимальной эффективности и инструменты измерения?
Или вы сводите все к интуиции и тому, что измерить это нереально?
Как выставить планку и как создать такой фреймворк работы — пишут целые книги. Например, рекомендую — «Management 3.0» by Jurgen Appelo.
Предел максимальной эффективности — это тот, который вы можете достичь. Опытным путем. Пока все не сломается, например. Но нужна ли нам максимальная эффективность или производительность, например? Максимальная «утилизация ресурсов»? Максимизация утилизации ресурсов, например, снижает эффективность. Подняли производительность тут — соседние отделы захлебнулись результатами вашей деятельности.
Да, иногда вам попадаются разработчики, которые просто не хотят работать. Это несложно понять. Решение простое — вы их увольняете.
Были комментарии про то, что менеджер — не программист и не может понять, что программист соврал, запросив неделю на решение задачи, которая занимает час. Я программист, но я вела много проектов за рамками моих компетенций ( я не могу одновременно знать и Objective C и .Net и «что-то там еще про Scala»). Мне врали программисты. Это вскрывается. Нужно много общаться, нужно быть со своей командой, тогда прекрасно видно, кто чем занимается. Кто о чем говорит. Я всегда была менеджером «в полях», никогда не сидела в отдельном кабинете, всегда с командами. 80% моего времени — с командами. Тот же scrum — это изрядная потогонка для разработчиков, все на виду каждый день.
100% согласна про источники корпоративной культуры. К сожалению, ни разу не удалось убедить в этом собственников, все соглашались, что toxic культура присутствует, но не считали это корнем всех зол. А в итоге — система не функционирует, а корчится в попытках выжить.
У разработчиков и не должно быть цели привлечь новых клиентов, так же, как и задачи «успеха» бизнеса, тк они не собственники и просто не могут разделять то же стремление к успеху и отношение к бизнесу (мне категорически не нравится популярное отношение «давайте сделаем так, чтобы все себя вели как собственники, при этом будучи наемными сотрудниками»). Но, «работающий продукт», «чтобы никогда не сидеть в пятницу после 6 вечера из-за внезапного бага на продакшене» — вот это ближе к людям, это будет всем понятно :) Ну и, конечно, «светлое будущее» — глобальные цели, не слишком фантастические, чтобы быть недостижимыми, но достаточно вдохновляющие.
Звучит как сказка, конечно, но по моим скромным эмпирическим данным — работает. И не забывайте расставаться с теми, кто выпадает из вашей культуры полностью. Для блага обоих.
По целям) Выполняются? Значит все отлично. Не выполняются? Давайте разбираться. Как разбираться? Тут уже от ситуации зависит) Хотите выжать больше — меняйте цели. Ваша задача, как менеджера, создать для разработчиков своеобразный фреймворк, в котором они бы прекрасно существовали и пользовались свободой в его рамках. Вага задача — подкручивать его тут и там, чтобы все это достигало определнных целей. Это я сейчас говорю уже о несколько большем, чем «успех проекта», я говорю о компании. Если нам нужен успех проекта — это к ТЗ, как ответили выше.
Как выставить планку и как создать такой фреймворк работы — пишут целые книги. Например, рекомендую — «Management 3.0» by Jurgen Appelo.
Предел максимальной эффективности — это тот, который вы можете достичь. Опытным путем. Пока все не сломается, например. Но нужна ли нам максимальная эффективность или производительность, например? Максимальная «утилизация ресурсов»? Максимизация утилизации ресурсов, например, снижает эффективность. Подняли производительность тут — соседние отделы захлебнулись результатами вашей деятельности.
Были комментарии про то, что менеджер — не программист и не может понять, что программист соврал, запросив неделю на решение задачи, которая занимает час. Я программист, но я вела много проектов за рамками моих компетенций ( я не могу одновременно знать и Objective C и .Net и «что-то там еще про Scala»). Мне врали программисты. Это вскрывается. Нужно много общаться, нужно быть со своей командой, тогда прекрасно видно, кто чем занимается. Кто о чем говорит. Я всегда была менеджером «в полях», никогда не сидела в отдельном кабинете, всегда с командами. 80% моего времени — с командами. Тот же scrum — это изрядная потогонка для разработчиков, все на виду каждый день.
У разработчиков и не должно быть цели привлечь новых клиентов, так же, как и задачи «успеха» бизнеса, тк они не собственники и просто не могут разделять то же стремление к успеху и отношение к бизнесу (мне категорически не нравится популярное отношение «давайте сделаем так, чтобы все себя вели как собственники, при этом будучи наемными сотрудниками»). Но, «работающий продукт», «чтобы никогда не сидеть в пятницу после 6 вечера из-за внезапного бага на продакшене» — вот это ближе к людям, это будет всем понятно :) Ну и, конечно, «светлое будущее» — глобальные цели, не слишком фантастические, чтобы быть недостижимыми, но достаточно вдохновляющие.