Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 17
Очень хорошо написано. Всячески поддерживаю. Тоже не люблю микроменеджмент. Но что могу сказать по последним пяти годам руководства разработкой (до этого более десяти лет работал программистом / тим лидом, в целом программирую неплохо):
Как показывает практика — не найдут :(. Тоесть они все сделают, и ЭТО даже будет удовлетворять входящим требованиям, но находящийся внутри код… Он… Как бы так помягче сказать… Будет несколько запутан и не очень готов к дальнейшим изменениям, даже если нарисовать roadmap на коды вперед. И рано или поздно руководитель разработкой ПО, который только ставит задачи и проверяет внешние требования и ограничения, столкнется с классической ситуацией, когда каждое следующее изменение программного продукта будет обходиться все дороже. А в какой-то момент времени будет дешевле переписать все с нуля :(.
И это не потому что разработчики плохие. Просто как-то так на практике получается, что в ряде задач, если нужно сделать что-то более сложное и долгоживущее нежели одноразовый сайт или одноразовая автоматизация бизнеса, требуется какой-то чудовищный опыт чтобы код через полгода оставался поддерживаемым :(. найти на рынке команду таких разработчиков — трудно и дорого. Приходится работать со средним уровнем по больнице.
В результате — как с фотошопом, который пять раз переписывали с нуля (или сколько там).
И что самое неприятное — я до сих пор до конца не понял что с этим делать. Тоесть есть наработки, идеи, я их потихонечку пробую на людях и процессах — но серебряной пули отлить не получается :(. Как-то и с микроменеджментом плохо, и без микроменеджмента тоже не все гладко. А постоянный code review всего кода делать если разработчиков больше пяти человек уже и не получается O_O.
Вот такие вот пироги, с глазами. Их едят, они глядят :).
— сосредоточьтесь на постановке задачи, а не на объяснении способов ее решения. Сообщите ЧТО нужно сделать, а не КАК это нужно делать. Сообщите команде, что должно получиться в результате их совместных магических усилий, а также дайте необходимые пояснения по параметрам или ограничениям, которые нужно учитывать при выполнении задачи. Пусть команда сама обработает исходные данные, использует свой опыт и творческий потенциал и найдет-таки нужный способ действия.
Как показывает практика — не найдут :(. Тоесть они все сделают, и ЭТО даже будет удовлетворять входящим требованиям, но находящийся внутри код… Он… Как бы так помягче сказать… Будет несколько запутан и не очень готов к дальнейшим изменениям, даже если нарисовать roadmap на коды вперед. И рано или поздно руководитель разработкой ПО, который только ставит задачи и проверяет внешние требования и ограничения, столкнется с классической ситуацией, когда каждое следующее изменение программного продукта будет обходиться все дороже. А в какой-то момент времени будет дешевле переписать все с нуля :(.
И это не потому что разработчики плохие. Просто как-то так на практике получается, что в ряде задач, если нужно сделать что-то более сложное и долгоживущее нежели одноразовый сайт или одноразовая автоматизация бизнеса, требуется какой-то чудовищный опыт чтобы код через полгода оставался поддерживаемым :(. найти на рынке команду таких разработчиков — трудно и дорого. Приходится работать со средним уровнем по больнице.
В результате — как с фотошопом, который пять раз переписывали с нуля (или сколько там).
И что самое неприятное — я до сих пор до конца не понял что с этим делать. Тоесть есть наработки, идеи, я их потихонечку пробую на людях и процессах — но серебряной пули отлить не получается :(. Как-то и с микроменеджментом плохо, и без микроменеджмента тоже не все гладко. А постоянный code review всего кода делать если разработчиков больше пяти человек уже и не получается O_O.
Вот такие вот пироги, с глазами. Их едят, они глядят :).
А с этим ничего не поделать. Любые хорошие продукты переписываются по несколько раз.
В любом случае у каждого человека свой взгляд на то, как надо писать код и просто должны быть регламенты, где есть основные договоренности, а все остальное — простор для творчества. Иначе получается вам нужны не специалисты, а дополнительные манипуляторы для себя, чтобы код быстрее писать можно было :)
В любом случае у каждого человека свой взгляд на то, как надо писать код и просто должны быть регламенты, где есть основные договоренности, а все остальное — простор для творчества. Иначе получается вам нужны не специалисты, а дополнительные манипуляторы для себя, чтобы код быстрее писать можно было :)
Ну и конечно забыл написать, что любой код должен рефакториться периодически, чтобы оттянуть тот момент, когда придется выбросить весь код полностью и начать заново :)
> а все остальное — простор для творчества
Когда с этим творчеством начнут вылазить многочисленные проблемы любой тимлид/менеджер пожалеет что оставил это на самотек. Однажды предоставив разработчикам такую свободу у вас накопится большое количество проблемного кода и ближе к релизу вы не будете знать что с этим делать. Решение довольно простое: если вы не уверены в качестве кода кого-то из разработчиков (например новый член команды), делайте постоянные code review. Review делает не обязательно менеджер, так что это вообще говоря не менеджмент. Также review это один из немногих способов junior разработчикам повысть качество кодинга.
Когда с этим творчеством начнут вылазить многочисленные проблемы любой тимлид/менеджер пожалеет что оставил это на самотек. Однажды предоставив разработчикам такую свободу у вас накопится большое количество проблемного кода и ближе к релизу вы не будете знать что с этим делать. Решение довольно простое: если вы не уверены в качестве кода кого-то из разработчиков (например новый член команды), делайте постоянные code review. Review делает не обязательно менеджер, так что это вообще говоря не менеджмент. Также review это один из немногих способов junior разработчикам повысть качество кодинга.
«Совершенный код» и «Чистый код» сильно правят мозги :-)
Особенно переполненные ООП'ом или функциональным стилем, синтаксическим сахаром и т.д.
Мое личное видение: код может быть не лучшего вида, но высокая связность и низкая связанность должны сохраняться, иначе код потом трудно будет переписать.
Если же эти два критерия выполнены — можно скрепя сердце оставить низкоуровневые переплетенные конструкции в их локальном ящике, закрыть его интерфейсом, специфицировать — и пусть работает (если, конечно, работает). До тех пор, пока не понадобится его расширить — тогда и перепишем, если текущий вариант трещит по швам.
Code review за своей командой, IMHO, проводить нужно, но не тыкать на некритичные вещи. Если такие находятся — лучше отдайте этот кусок на review другому коллеге, пусть он их найдет. А вот критические вещи все равно нужно контролировать кому-то достаточно опытному. Особенно когда дело касается оптимизации запросом путем создания индексов, когда ищутся пути избавлений от deadlock'ов и т.д.
Особенно переполненные ООП'ом или функциональным стилем, синтаксическим сахаром и т.д.
Мое личное видение: код может быть не лучшего вида, но высокая связность и низкая связанность должны сохраняться, иначе код потом трудно будет переписать.
Если же эти два критерия выполнены — можно скрепя сердце оставить низкоуровневые переплетенные конструкции в их локальном ящике, закрыть его интерфейсом, специфицировать — и пусть работает (если, конечно, работает). До тех пор, пока не понадобится его расширить — тогда и перепишем, если текущий вариант трещит по швам.
Code review за своей командой, IMHO, проводить нужно, но не тыкать на некритичные вещи. Если такие находятся — лучше отдайте этот кусок на review другому коллеге, пусть он их найдет. А вот критические вещи все равно нужно контролировать кому-то достаточно опытному. Особенно когда дело касается оптимизации запросом путем создания индексов, когда ищутся пути избавлений от deadlock'ов и т.д.
да, кстати, интересная идея иногда просачивается, она такая ненавязчивая, но решает много проблем:
«клонирование себя» ) но когда реально себе это представляешь, то может прийти мысль, что не сработаемся )
> люди, а не ресурс!
Согласен, видимо Вам везет на инициативных.
На мой взгляд, инициатива — это одно, а разработка приложения с продуманным будущим — это другое.
Я не против инициативы, я против быдлокода.
Закрывать глаза на отклонения можно до поры до времени, потом Вам придется эту часть переписать.
Микроменеджмент, он больше от безвыходности, когда вроде бы и рад им не заниматься, но как ни глянешь, лучше бы не смотрел и думал, что все в порядке.
Не знаю как с этим бороться, надо просто заниматься наставничеством, люди разные, перспективных хватает, многие боятся делать по-своему, таким достаточно дать волю и немного подправлять. Есть разработчики, не осознающие что они делают, с ними сложней, тогда и возникает этот ступор и желание давать только маленькие задачи, пока человек не раскроется, показывать не только направление, но и «куда нажимать»
«клонирование себя» ) но когда реально себе это представляешь, то может прийти мысль, что не сработаемся )
> люди, а не ресурс!
Согласен, видимо Вам везет на инициативных.
На мой взгляд, инициатива — это одно, а разработка приложения с продуманным будущим — это другое.
Я не против инициативы, я против быдлокода.
Закрывать глаза на отклонения можно до поры до времени, потом Вам придется эту часть переписать.
Микроменеджмент, он больше от безвыходности, когда вроде бы и рад им не заниматься, но как ни глянешь, лучше бы не смотрел и думал, что все в порядке.
Не знаю как с этим бороться, надо просто заниматься наставничеством, люди разные, перспективных хватает, многие боятся делать по-своему, таким достаточно дать волю и немного подправлять. Есть разработчики, не осознающие что они делают, с ними сложней, тогда и возникает этот ступор и желание давать только маленькие задачи, пока человек не раскроется, показывать не только направление, но и «куда нажимать»
Клонирование себя — любопытная идея, главное, чтобы она не стала общедоступной :)
Я думаю, что микроменеджмент не только от безвыходности, а еще оттого, что управление — это скорее искусство, а не технология. Не хватает метрик, на основании которых можно было бы сколько там нужно раз мысленно щелкнуть хвостом, чтобы все было в порядке. Поэтому приходится постепенно набивать опыт и приходить к успеху со своим личным паноптикумом убитых или не взлетевших проектов.
Наставничество — это хорошо, только к этому тоже не каждый способен. И, наверное, чем меньше руководитель к этому способен, тем чаще ему приходится прибегать к микроменеджменту.
Я думаю, что микроменеджмент не только от безвыходности, а еще оттого, что управление — это скорее искусство, а не технология. Не хватает метрик, на основании которых можно было бы сколько там нужно раз мысленно щелкнуть хвостом, чтобы все было в порядке. Поэтому приходится постепенно набивать опыт и приходить к успеху со своим личным паноптикумом убитых или не взлетевших проектов.
Наставничество — это хорошо, только к этому тоже не каждый способен. И, наверное, чем меньше руководитель к этому способен, тем чаще ему приходится прибегать к микроменеджменту.
Автор, а вы сам — разработчик или менеджер? Даете правильные советы менеджерам — наверное, менеджер, однако, в контексте явно звучит недовольство микроменеджемнтом, примененным к вам же — наверное, разработчик.
Постоянное довление (от «довлеть») над душой никогда не будет результатом качественной работы, это раз.
Два — архитектура проекта все-таки может задаваться опытным специалистом, а накодить код могут и менее опытные, таким образом, остается следить за архитектурой, а это может быть один человек из команды программистов, с которым менеджер может общаться более неформально и на равных, что, мне кажется, способствует качеству и препятствует скорой кончине одной версии проекта с заменой ее на другую с нуля.
И три — зачастую есть не так много времени, чтобы выдумать нереально крутую архитектуру, которая останется на века. Нет времени и все тут, и тут приходится выбирать вариант «давайте сделаем менее мудрено и правильно, чтоб Фаулеру не стыдно было показать, но более быстро», что в достаточно опытных руках, опять же, не приводит к фатальным результатам.
Постоянное довление (от «довлеть») над душой никогда не будет результатом качественной работы, это раз.
Два — архитектура проекта все-таки может задаваться опытным специалистом, а накодить код могут и менее опытные, таким образом, остается следить за архитектурой, а это может быть один человек из команды программистов, с которым менеджер может общаться более неформально и на равных, что, мне кажется, способствует качеству и препятствует скорой кончине одной версии проекта с заменой ее на другую с нуля.
И три — зачастую есть не так много времени, чтобы выдумать нереально крутую архитектуру, которая останется на века. Нет времени и все тут, и тут приходится выбирать вариант «давайте сделаем менее мудрено и правильно, чтоб Фаулеру не стыдно было показать, но более быстро», что в достаточно опытных руках, опять же, не приводит к фатальным результатам.
Большинство менеджеров так или иначе посидело в свое время на стульчиках разработчиков и тимлидов, почитало интересных книжек, посетило n-ное количество тренингов и конф и поумнело от всего вышеперечисленного.
Аллергия на микроменеджмент — это здоровая реакция любого организма, который когда-либо испытывал его на себе (в любой профессиональной сфере), тут главное выработать иммунитет.
Аллергия на микроменеджмент — это здоровая реакция любого организма, который когда-либо испытывал его на себе (в любой профессиональной сфере), тут главное выработать иммунитет.
Статья очень понравилась. Большое спасибо автору.
В ответ на:
Конструктивный диалог и предложение более качественных решений позволяют побороть это явление.
«управляющий» (если он адекватен) видит, что человек в теме, и дает подчиненному свободу решать задачу по его схеме.
Побывал в обоих ролях. Мне удавалось доказывать, свое мнение. И мне тоже доказывали мнение те, кем мне доводилось руководить. Так происходит потому, что человек решающий задачу на месте в самой задаче ориентируется лучше(если, конечно, он не начинающий, или просто новый человек в проекте, или ещё хуже — быдлокодер), чем руководитель.
А теперь позволю себе оставить свое мнение по поводу микроменеджмента:
я думаю, что он необходим только в одном случае — как одно из средств для обучения.
Я делал так:
сначала давал повозиться человеку в своем коде и документации 1-2 дня; пусть сам разберется;
если не разобрался, давал ссылки на документацию, литературу и на примеры — как нужно.
если и это не помогло, то корректировал решение сам, либо часть решения, объяснял как нужно и почему так, заставлял доделать — как нужно; возможно на это уходило несколько итераций
Далее следующая задача по той же схеме. После нескольких задач человек растет быстрее, и достаточно просто проглядывать его код на явные косяки.
Пару раз схема не срабатывала. В проекте было много новичков, не хватало времени работать с каждым. Да и объясняю я не очень понятно. В итоге, быдлокод был жутким… Но к концу проекта народ стал писать по лучше.
Итог, мы все учились понемногу...)
В ответ на:
«Очень хотелось бы услышать от уважаемых хабраграждан, как бороться с микроменеджментом в полевых условиях силами разработчиков. Особенно интересуют случаи успешной борьбы.»
Конструктивный диалог и предложение более качественных решений позволяют побороть это явление.
«управляющий» (если он адекватен) видит, что человек в теме, и дает подчиненному свободу решать задачу по его схеме.
Побывал в обоих ролях. Мне удавалось доказывать, свое мнение. И мне тоже доказывали мнение те, кем мне доводилось руководить. Так происходит потому, что человек решающий задачу на месте в самой задаче ориентируется лучше(если, конечно, он не начинающий, или просто новый человек в проекте, или ещё хуже — быдлокодер), чем руководитель.
А теперь позволю себе оставить свое мнение по поводу микроменеджмента:
я думаю, что он необходим только в одном случае — как одно из средств для обучения.
Я делал так:
сначала давал повозиться человеку в своем коде и документации 1-2 дня; пусть сам разберется;
если не разобрался, давал ссылки на документацию, литературу и на примеры — как нужно.
если и это не помогло, то корректировал решение сам, либо часть решения, объяснял как нужно и почему так, заставлял доделать — как нужно; возможно на это уходило несколько итераций
Далее следующая задача по той же схеме. После нескольких задач человек растет быстрее, и достаточно просто проглядывать его код на явные косяки.
Пару раз схема не срабатывала. В проекте было много новичков, не хватало времени работать с каждым. Да и объясняю я не очень понятно. В итоге, быдлокод был жутким… Но к концу проекта народ стал писать по лучше.
Итог, мы все учились понемногу...)
Спасибо!
По поводу применения микроменеджмента в обучении, соглашусь, это полезная практика. В большинстве случаев приносит результат, правда, необходим контроль, а на это уходит время. Однако, если в планах долгосрочная работа с командой, то есть смысл ее растить и вкладывать в это время и другие ресурсы.
По поводу применения микроменеджмента в обучении, соглашусь, это полезная практика. В большинстве случаев приносит результат, правда, необходим контроль, а на это уходит время. Однако, если в планах долгосрочная работа с командой, то есть смысл ее растить и вкладывать в это время и другие ресурсы.
Написано хорошо. Внесу свои 5 копеек.
Выбор микроменеджмента это должен быть осознанный выбор руководителя. Существует такая теория как ситуационная теория лидерства в частности теория жизненного цикла Херси и Бланшара.По ней стиль руководства и лидерства выбирается от “зрелости” исполнителей. Есть даже диаграммка по этому поводу.
«Зрелость не следует определять в категории возраста. Зрелость отдельных лиц и групп подразумеваем способность нести ответственность за свое поведение, желание достигнуть поставленной цели, а также образование и опыт в отношении конкретной задачи, которую необходимо выполнить.»
Выбор микроменеджмента это должен быть осознанный выбор руководителя. Существует такая теория как ситуационная теория лидерства в частности теория жизненного цикла Херси и Бланшара.По ней стиль руководства и лидерства выбирается от “зрелости” исполнителей. Есть даже диаграммка по этому поводу.
«Зрелость не следует определять в категории возраста. Зрелость отдельных лиц и групп подразумеваем способность нести ответственность за свое поведение, желание достигнуть поставленной цели, а также образование и опыт в отношении конкретной задачи, которую необходимо выполнить.»
про Бланшара тут уже написали, от себя хочу порекомендовать книгу «менеджер за одну минуту». Срубает на корню всю идею микроменеджмента.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Микроменеджмент: время создавать зомби