Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Классаня статья. Увы на новом проекте попал в тим с двумя китайцами — которые имеют очень смутное представление о технологическом стеке и для чего нужны интеграционные тесты.
При слове рефакторинг — пучат глаза и похоже делают под себя. Основной аргумент против рефакторинга — а что если что-то перестанет работать и мы не заметим?
При слове рефакторинг — пучат глаза и похоже делают под себя. Основной аргумент против рефакторинга — а что если что-то перестанет работать и мы не заметим?
Имхо, без рефакторинга невозможно написание нового функционала. Чем дольше рефакторинг откладывается на потом, тем больше код превращается в лапшу, которую очень трудно поддерживать в дальнейшем. На более менее сложном проекте без тестов не обойтись. Они нужны не только, чтобы «заметить» что что-то сломалось, но и понять, как это исправить.
Т.е. если сейчас что-то не работает и они этого не замечают, то это ок? :) А при рефакторинге иногда такое можно выявить.
"… задать метрику «успеха» — достижение каких-то командных целей, релизов, прибыли, счастливых клиентов. Нет с этим проблем? Значит нечего исправлять."
Вот у менеджера по маркетингу, есть четкие измеряемые цели по привлечению новых клиентов по определенным рынкам, а у разработчиков такой цели нет. Можно неделю ждать от них когда сделают элементарный 301 редирект с одной страницы на другую. По опыту, проблемы в управлении всегда идут от собственников к менеджерам и уже потом к разработчикам. Как задали с самого начала генетический код корпоративной культуры, так с этим кодом и живет (или не живет) компания. Нужно писать статью «Руководство собственника». Менеджеры бывают и не причем в создавшихся проблемах. Пишу как менеджер.
Вот у менеджера по маркетингу, есть четкие измеряемые цели по привлечению новых клиентов по определенным рынкам, а у разработчиков такой цели нет. Можно неделю ждать от них когда сделают элементарный 301 редирект с одной страницы на другую. По опыту, проблемы в управлении всегда идут от собственников к менеджерам и уже потом к разработчикам. Как задали с самого начала генетический код корпоративной культуры, так с этим кодом и живет (или не живет) компания. Нужно писать статью «Руководство собственника». Менеджеры бывают и не причем в создавшихся проблемах. Пишу как менеджер.
100% согласна про источники корпоративной культуры. К сожалению, ни разу не удалось убедить в этом собственников, все соглашались, что toxic культура присутствует, но не считали это корнем всех зол. А в итоге — система не функционирует, а корчится в попытках выжить.
У разработчиков и не должно быть цели привлечь новых клиентов, так же, как и задачи «успеха» бизнеса, тк они не собственники и просто не могут разделять то же стремление к успеху и отношение к бизнесу (мне категорически не нравится популярное отношение «давайте сделаем так, чтобы все себя вели как собственники, при этом будучи наемными сотрудниками»). Но, «работающий продукт», «чтобы никогда не сидеть в пятницу после 6 вечера из-за внезапного бага на продакшене» — вот это ближе к людям, это будет всем понятно :) Ну и, конечно, «светлое будущее» — глобальные цели, не слишком фантастические, чтобы быть недостижимыми, но достаточно вдохновляющие.
У разработчиков и не должно быть цели привлечь новых клиентов, так же, как и задачи «успеха» бизнеса, тк они не собственники и просто не могут разделять то же стремление к успеху и отношение к бизнесу (мне категорически не нравится популярное отношение «давайте сделаем так, чтобы все себя вели как собственники, при этом будучи наемными сотрудниками»). Но, «работающий продукт», «чтобы никогда не сидеть в пятницу после 6 вечера из-за внезапного бага на продакшене» — вот это ближе к людям, это будет всем понятно :) Ну и, конечно, «светлое будущее» — глобальные цели, не слишком фантастические, чтобы быть недостижимыми, но достаточно вдохновляющие.
>>Менеджеры бывают и не причем в создавшихся проблемах. Пишу как менеджер.
Как удобно всегда на кого-то переложить ответственность.
Как удобно всегда на кого-то переложить ответственность.
Частично с вами согласен. В моем случае менеджером является собственник, у которого есть опыт работы разработчиком. Но это скорее исключение. По поводу управления программистами и взаимодействия с начальством (собственником) рекомендую послушать выступления Григория bobuk Бакунова из Яндекса.
Wow, спасибо за перевод!
own сорри, но вы имхо не ответили на вопрос.
Так как понять, что разработчики действительно работают?
По достижению целей? Но одна цель будет легкой, другая наоборот недостижимой.
А что если менеджер хочет ЕЩЕ больше результатов?
Ему чтобы развивать компанию, продукт, нужно увеличивать результаты.
Он не может быть перманентно доволен.
Его задача именно выжимать максимум из доступных ресурсов.
Как ему определить, что выжат максимум и что youtube это реально разгрузка, чтобы разработчик не умер, а не простой, лень?
Планку нужно выставить. Вы не описали как.
Плюс как и с цитатой выше, планка не перманентна, суть развития в повышении планки.
Поэтому всегда есть, что исправлять.
Но где пределы? Где предел максимальной эффективности и инструменты измерения?
Или вы сводите все к интуиции и тому, что измерить это нереально?
Но об этом ни слова.
p.s. ах, это перевод. но все равно, значит вы согласны наверно с данным материалом. интересны комментарии.
Так как понять, что разработчики действительно работают?
По достижению целей? Но одна цель будет легкой, другая наоборот недостижимой.
менеджер жалуется «они смотрят видео на youtube в рабочее время», я обычно спрашиваю его/ее — «Но почему это является проблемой? Вы не удовлетворены результатами команды?».
А что если менеджер хочет ЕЩЕ больше результатов?
Ему чтобы развивать компанию, продукт, нужно увеличивать результаты.
Он не может быть перманентно доволен.
Его задача именно выжимать максимум из доступных ресурсов.
Как ему определить, что выжат максимум и что youtube это реально разгрузка, чтобы разработчик не умер, а не простой, лень?
Единственный способ извлечь из этого пользу — задать метрику «успеха» — достижение каких-то командных целей, релизов, прибыли, счастливых клиентов. Нет с этим проблем? Значит нечего исправлять.
Планку нужно выставить. Вы не описали как.
Плюс как и с цитатой выше, планка не перманентна, суть развития в повышении планки.
Поэтому всегда есть, что исправлять.
Но где пределы? Где предел максимальной эффективности и инструменты измерения?
Или вы сводите все к интуиции и тому, что измерить это нереально?
Да, иногда вам попадаются разработчики, которые просто не хотят работать. Это несложно понять. Решение простое — вы их увольняете.
Но об этом ни слова.
p.s. ах, это перевод. но все равно, значит вы согласны наверно с данным материалом. интересны комментарии.
Не own, но отвечу.
Оный максимум задаётся при проектировании технического задания и, зачастую, не находится в области компетенции менеджера. Действующих критериев оценки работы девелопера — всего три:
1. Соблюдение ТЗ
2. Нарекания от пользователя (количество и серьёзность проблем)
3. Нарекания от поддержки (аналогично)
Очень просто: составить ТЗ.
Всё правильно. Поэтому специалисты, занимающиеся составлением ТЗ, учитывают не только пожелания заказчика продукта, но и результаты выполнения прошлых работы, а также сравнивают их со статистикой по отрасли.
Я так понимаю, суть статьи — в том, что загрузка разработчика, видимая или фактическая, не может являться показателем эффективности его работы и поэтому подлежит регулированию только квалифицированными в области разработки управляющими. Если совсем просто: менеджер, управляющий разработчиками, должен быть специалистом не только в области менеджмента, но и в разработке.
А что если менеджер хочет ЕЩЕ больше результатов?
Его задача именно выжимать максимум из доступных ресурсов.
Оный максимум задаётся при проектировании технического задания и, зачастую, не находится в области компетенции менеджера. Действующих критериев оценки работы девелопера — всего три:
1. Соблюдение ТЗ
2. Нарекания от пользователя (количество и серьёзность проблем)
3. Нарекания от поддержки (аналогично)
Планку нужно выставить. Вы не описали как.
Очень просто: составить ТЗ.
суть развития в повышении планки.
Всё правильно. Поэтому специалисты, занимающиеся составлением ТЗ, учитывают не только пожелания заказчика продукта, но и результаты выполнения прошлых работы, а также сравнивают их со статистикой по отрасли.
Или вы сводите все к интуиции и тому, что измерить это нереально?
Я так понимаю, суть статьи — в том, что загрузка разработчика, видимая или фактическая, не может являться показателем эффективности его работы и поэтому подлежит регулированию только квалифицированными в области разработки управляющими. Если совсем просто: менеджер, управляющий разработчиками, должен быть специалистом не только в области менеджмента, но и в разработке.
Shing Надеюсь, вы учли, что это перевод. Все, что написано ниже, мое личное мнение.
Чтобы правильно оценивать работу программистов, нужно самому иметь опыт в разработке. Есть еще человеческий фактор. Если у проджект менеджера нет своего репозитория (напр. на гитхабе), он не учавствует активно в жизни проекта (не делает коммитов, не приходит на код ревью), то наладить контакт с командой разработчиков и пользоваться авторитетом ему будет, мягко говоря, непросто. Очевидно, из-за этого бывают сложности в оценивании работы, срывы дедлайнов и т.д.
Можно что-то усовершенствовать, добавить новый функционал. Исправлять функционал, который работает, покрыт тестами, делает клиентов довольными… не имеет смысла.
Для этого существуют и давно применяются эстимейты, скрам, спринты и другие методологии.
Чтобы правильно оценивать работу программистов, нужно самому иметь опыт в разработке. Есть еще человеческий фактор. Если у проджект менеджера нет своего репозитория (напр. на гитхабе), он не учавствует активно в жизни проекта (не делает коммитов, не приходит на код ревью), то наладить контакт с командой разработчиков и пользоваться авторитетом ему будет, мягко говоря, непросто. Очевидно, из-за этого бывают сложности в оценивании работы, срывы дедлайнов и т.д.
Поэтому всегда есть, что исправлять.
Можно что-то усовершенствовать, добавить новый функционал. Исправлять функционал, который работает, покрыт тестами, делает клиентов довольными… не имеет смысла.
Но где пределы? Где предел максимальной эффективности и инструменты измерения?
Для этого существуют и давно применяются эстимейты, скрам, спринты и другие методологии.
Попробую ответить. Статья, конечно, не задумывалась как полное и исчерпывающее руководство, тк, к сожалению, все очень зависит от конкретного случая и команды. Менеджмент в данном случае далек от теории и близок к практике. Скорее это протест против бездумного охаивания менеджерами «ленивых» разработчиков и попытка заставить из посмотреть на это с другой стороны: может быть проблемы и нет? может быть они и не ленивы вовсе, а у нас с целями что-то не так?
По целям) Выполняются? Значит все отлично. Не выполняются? Давайте разбираться. Как разбираться? Тут уже от ситуации зависит) Хотите выжать больше — меняйте цели. Ваша задача, как менеджера, создать для разработчиков своеобразный фреймворк, в котором они бы прекрасно существовали и пользовались свободой в его рамках. Вага задача — подкручивать его тут и там, чтобы все это достигало определнных целей. Это я сейчас говорю уже о несколько большем, чем «успех проекта», я говорю о компании. Если нам нужен успех проекта — это к ТЗ, как ответили выше.
Как выставить планку и как создать такой фреймворк работы — пишут целые книги. Например, рекомендую — «Management 3.0» by Jurgen Appelo.
Предел максимальной эффективности — это тот, который вы можете достичь. Опытным путем. Пока все не сломается, например. Но нужна ли нам максимальная эффективность или производительность, например? Максимальная «утилизация ресурсов»? Максимизация утилизации ресурсов, например, снижает эффективность. Подняли производительность тут — соседние отделы захлебнулись результатами вашей деятельности.
Были комментарии про то, что менеджер — не программист и не может понять, что программист соврал, запросив неделю на решение задачи, которая занимает час. Я программист, но я вела много проектов за рамками моих компетенций ( я не могу одновременно знать и Objective C и .Net и «что-то там еще про Scala»). Мне врали программисты. Это вскрывается. Нужно много общаться, нужно быть со своей командой, тогда прекрасно видно, кто чем занимается. Кто о чем говорит. Я всегда была менеджером «в полях», никогда не сидела в отдельном кабинете, всегда с командами. 80% моего времени — с командами. Тот же scrum — это изрядная потогонка для разработчиков, все на виду каждый день.
А что если менеджер хочет ЕЩЕ больше результатов?
Ему чтобы развивать компанию, продукт, нужно увеличивать результаты.
Он не может быть перманентно доволен.
Его задача именно выжимать максимум из доступных ресурсов.
Как ему определить, что выжат максимум и что youtube это реально разгрузка, чтобы разработчик не умер, а не простой, лень?
По целям) Выполняются? Значит все отлично. Не выполняются? Давайте разбираться. Как разбираться? Тут уже от ситуации зависит) Хотите выжать больше — меняйте цели. Ваша задача, как менеджера, создать для разработчиков своеобразный фреймворк, в котором они бы прекрасно существовали и пользовались свободой в его рамках. Вага задача — подкручивать его тут и там, чтобы все это достигало определнных целей. Это я сейчас говорю уже о несколько большем, чем «успех проекта», я говорю о компании. Если нам нужен успех проекта — это к ТЗ, как ответили выше.
Планку нужно выставить. Вы не описали как.
Плюс как и с цитатой выше, планка не перманентна, суть развития в повышении планки.
Поэтому всегда есть, что исправлять.
Но где пределы? Где предел максимальной эффективности и инструменты измерения?
Или вы сводите все к интуиции и тому, что измерить это нереально?
Как выставить планку и как создать такой фреймворк работы — пишут целые книги. Например, рекомендую — «Management 3.0» by Jurgen Appelo.
Предел максимальной эффективности — это тот, который вы можете достичь. Опытным путем. Пока все не сломается, например. Но нужна ли нам максимальная эффективность или производительность, например? Максимальная «утилизация ресурсов»? Максимизация утилизации ресурсов, например, снижает эффективность. Подняли производительность тут — соседние отделы захлебнулись результатами вашей деятельности.
Да, иногда вам попадаются разработчики, которые просто не хотят работать. Это несложно понять. Решение простое — вы их увольняете.
Были комментарии про то, что менеджер — не программист и не может понять, что программист соврал, запросив неделю на решение задачи, которая занимает час. Я программист, но я вела много проектов за рамками моих компетенций ( я не могу одновременно знать и Objective C и .Net и «что-то там еще про Scala»). Мне врали программисты. Это вскрывается. Нужно много общаться, нужно быть со своей командой, тогда прекрасно видно, кто чем занимается. Кто о чем говорит. Я всегда была менеджером «в полях», никогда не сидела в отдельном кабинете, всегда с командами. 80% моего времени — с командами. Тот же scrum — это изрядная потогонка для разработчиков, все на виду каждый день.
Позволю не согласится с выводом, что не надо изменять людей. На самом деле, развиваясь и обучаясь, человек ведь меняется. С позитивной точки зрения, хороший руководитель всё же меняет людей, его сотрудники растут, развиваются, становятся способными на большее. И вот для хорошего роста как раз и стоит создавать условия
«Меняй людей или меняй людей» — (развивай, мотивируй, обучай...) или (увольняй) нанимай других
Спасибо за отличный перевод.
«Меняй людей или меняй людей» — (развивай, мотивируй, обучай...) или (увольняй) нанимай других
Спасибо за отличный перевод.
Согласна. Изменения нужны, но, скорее, не мы меняем людей, а они сами меняются). А менеджеры создают условия, благоприятную среду. Вот так хороший менеджер и меняет людей: они меняются сами — у них просто не остается выбора. Например, если представить камень, который никак не хочет катиться вперед, лучше не продолжать его пинать (чтобы он поменялся и стал идеальным шаром), а чуть поменять рельеф — подрыть ямку перед ним, сдвинуть с места, переложить на бревна и катить :) Не лучший пример, тк камень и остался камнем, но, надеюсь, мысль понятна. «Пока враг рисует карты местности, мы меняем рельеф! Причем, вручную.» :)
Звучит как сказка, конечно, но по моим скромным эмпирическим данным — работает. И не забывайте расставаться с теми, кто выпадает из вашей культуры полностью. Для блага обоих.
Звучит как сказка, конечно, но по моим скромным эмпирическим данным — работает. И не забывайте расставаться с теми, кто выпадает из вашей культуры полностью. Для блага обоих.
На самом деле действительно не ясно как понять работает разработчик или нет.
Но результат его работы осязаем (например рабочее приложение).
Главное правильно поставить задачу: что должно получиться в итоге.
Но результат его работы осязаем (например рабочее приложение).
Главное правильно поставить задачу: что должно получиться в итоге.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Руководство менеджера: как понять, что разработчики действительно работают