Руководство менеджера: как понять, что разработчики действительно работают

Имхо, без рефакторинга невозможно написание нового функционала. Чем дольше рефакторинг откладывается на потом, тем больше код превращается в лапшу, которую очень трудно поддерживать в дальнейшем. На более менее сложном проекте без тестов не обойтись. Они нужны не только, чтобы «заметить» что что-то сломалось, но и понять, как это исправить.

100% согласна про источники корпоративной культуры. К сожалению, ни разу не удалось убедить в этом собственников, все соглашались, что toxic культура присутствует, но не считали это корнем всех зол. А в итоге — система не функционирует, а корчится в попытках выжить.

У разработчиков и не должно быть цели привлечь новых клиентов, так же, как и задачи «успеха» бизнеса, тк они не собственники и просто не могут разделять то же стремление к успеху и отношение к бизнесу (мне категорически не нравится популярное отношение «давайте сделаем так, чтобы все себя вели как собственники, при этом будучи наемными сотрудниками»). Но, «работающий продукт», «чтобы никогда не сидеть в пятницу после 6 вечера из-за внезапного бага на продакшене» — вот это ближе к людям, это будет всем понятно :) Ну и, конечно, «светлое будущее» — глобальные цели, не слишком фантастические, чтобы быть недостижимыми, но достаточно вдохновляющие.

>>Менеджеры бывают и не причем в создавшихся проблемах. Пишу как менеджер.
Как удобно всегда на кого-то переложить ответственность.

Частично с вами согласен. В моем случае менеджером является собственник, у которого есть опыт работы разработчиком. Но это скорее исключение. По поводу управления программистами и взаимодействия с начальством (собственником) рекомендую послушать выступления Григория bobuk Бакунова из Яндекса.

Не все понимают такой тонкий юмор))

Не own, но отвечу.

А что если менеджер хочет ЕЩЕ больше результатов?
Его задача именно выжимать максимум из доступных ресурсов.

Оный максимум задаётся при проектировании технического задания и, зачастую, не находится в области компетенции менеджера. Действующих критериев оценки работы девелопера — всего три:
1. Соблюдение ТЗ
2. Нарекания от пользователя (количество и серьёзность проблем)
3. Нарекания от поддержки (аналогично)

Планку нужно выставить. Вы не описали как.

Очень просто: составить ТЗ.

суть развития в повышении планки.

Всё правильно. Поэтому специалисты, занимающиеся составлением ТЗ, учитывают не только пожелания заказчика продукта, но и результаты выполнения прошлых работы, а также сравнивают их со статистикой по отрасли.

Или вы сводите все к интуиции и тому, что измерить это нереально?

Я так понимаю, суть статьи — в том, что загрузка разработчика, видимая или фактическая, не может являться показателем эффективности его работы и поэтому подлежит регулированию только квалифицированными в области разработки управляющими. Если совсем просто: менеджер, управляющий разработчиками, должен быть специалистом не только в области менеджмента, но и в разработке.

Shing Надеюсь, вы учли, что это перевод. Все, что написано ниже, мое личное мнение.
Чтобы правильно оценивать работу программистов, нужно самому иметь опыт в разработке. Есть еще человеческий фактор. Если у проджект менеджера нет своего репозитория (напр. на гитхабе), он не учавствует активно в жизни проекта (не делает коммитов, не приходит на код ревью), то наладить контакт с командой разработчиков и пользоваться авторитетом ему будет, мягко говоря, непросто. Очевидно, из-за этого бывают сложности в оценивании работы, срывы дедлайнов и т.д.

Поэтому всегда есть, что исправлять.

Можно что-то усовершенствовать, добавить новый функционал. Исправлять функционал, который работает, покрыт тестами, делает клиентов довольными… не имеет смысла.

Но где пределы? Где предел максимальной эффективности и инструменты измерения?

Для этого существуют и давно применяются эстимейты, скрам, спринты и другие методологии.

Попробую ответить. Статья, конечно, не задумывалась как полное и исчерпывающее руководство, тк, к сожалению, все очень зависит от конкретного случая и команды. Менеджмент в данном случае далек от теории и близок к практике. Скорее это протест против бездумного охаивания менеджерами «ленивых» разработчиков и попытка заставить из посмотреть на это с другой стороны: может быть проблемы и нет? может быть они и не ленивы вовсе, а у нас с целями что-то не так?

А что если менеджер хочет ЕЩЕ больше результатов?
Ему чтобы развивать компанию, продукт, нужно увеличивать результаты.
Он не может быть перманентно доволен.
Его задача именно выжимать максимум из доступных ресурсов.
Как ему определить, что выжат максимум и что youtube это реально разгрузка, чтобы разработчик не умер, а не простой, лень?

По целям) Выполняются? Значит все отлично. Не выполняются? Давайте разбираться. Как разбираться? Тут уже от ситуации зависит) Хотите выжать больше — меняйте цели. Ваша задача, как менеджера, создать для разработчиков своеобразный фреймворк, в котором они бы прекрасно существовали и пользовались свободой в его рамках. Вага задача — подкручивать его тут и там, чтобы все это достигало определнных целей. Это я сейчас говорю уже о несколько большем, чем «успех проекта», я говорю о компании. Если нам нужен успех проекта — это к ТЗ, как ответили выше.

Планку нужно выставить. Вы не описали как.
Плюс как и с цитатой выше, планка не перманентна, суть развития в повышении планки.
Поэтому всегда есть, что исправлять.
Но где пределы? Где предел максимальной эффективности и инструменты измерения?

Или вы сводите все к интуиции и тому, что измерить это нереально?

Как выставить планку и как создать такой фреймворк работы — пишут целые книги. Например, рекомендую — «Management 3.0» by Jurgen Appelo.
Предел максимальной эффективности — это тот, который вы можете достичь. Опытным путем. Пока все не сломается, например. Но нужна ли нам максимальная эффективность или производительность, например? Максимальная «утилизация ресурсов»? Максимизация утилизации ресурсов, например, снижает эффективность. Подняли производительность тут — соседние отделы захлебнулись результатами вашей деятельности.

Да, иногда вам попадаются разработчики, которые просто не хотят работать. Это несложно понять. Решение простое — вы их увольняете.

Были комментарии про то, что менеджер — не программист и не может понять, что программист соврал, запросив неделю на решение задачи, которая занимает час. Я программист, но я вела много проектов за рамками моих компетенций ( я не могу одновременно знать и Objective C и .Net и «что-то там еще про Scala»). Мне врали программисты. Это вскрывается. Нужно много общаться, нужно быть со своей командой, тогда прекрасно видно, кто чем занимается. Кто о чем говорит. Я всегда была менеджером «в полях», никогда не сидела в отдельном кабинете, всегда с командами. 80% моего времени — с командами. Тот же scrum — это изрядная потогонка для разработчиков, все на виду каждый день.

Согласна. Изменения нужны, но, скорее, не мы меняем людей, а они сами меняются). А менеджеры создают условия, благоприятную среду. Вот так хороший менеджер и меняет людей: они меняются сами — у них просто не остается выбора. Например, если представить камень, который никак не хочет катиться вперед, лучше не продолжать его пинать (чтобы он поменялся и стал идеальным шаром), а чуть поменять рельеф — подрыть ямку перед ним, сдвинуть с места, переложить на бревна и катить :) Не лучший пример, тк камень и остался камнем, но, надеюсь, мысль понятна. «Пока враг рисует карты местности, мы меняем рельеф! Причем, вручную.» :)

Звучит как сказка, конечно, но по моим скромным эмпирическим данным — работает. И не забывайте расставаться с теми, кто выпадает из вашей культуры полностью. Для блага обоих.