Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 49
возьмем например
разработчика, у него возникла какая-то
проблема с алгоритмом, который он может
решить самостоятельно, при этом это было
не запланировано и ему придется сегодня
задержаться на работе на часик — значит он
самостоятельно задерживается
не понимаю я студийное рабство, хоть убей не понимаю!
в каком либо виде оно есть в любом случае
Это что же получается — риски и непредвиденные проблемы перекладываются на исполнителя?
Здесь есть тонкая грань в слове «придется». Если вы работаете один, как фрилансер, или на свой проект, то «придется» или «надо доделать» говорите себе вы. По разным причинам: не хочется откладывать на завтра, терять контекст, завтра есть жругие вещи и т.д. Если в «студийном рабстве» вы руководствуетесь этими же мотивами, то это называется ответственность. Не прнимаю, почему в одном случае это рабство, а в другом свобода настоящей работы на себя.
Согласен. Есть емкое слово — самоменеджмент. У тебя есть в распоряжении свое время — ресурс (день, неделя максимум) и есть задачи — которые решаешь в этих временных рамках. Сделал быстрее отлично, не успел — организовывайся. Никто не даст работы больше, чем реально можно сделать за нормальный день в 8 часов.
А то, что сотрудник задерживается на работе после 19:00, то это уже сигнал руководителю. Даже у великих спортсменов есть тренер — не задавали почему? Потому, что сам себя не заставишь перейти какие-то рамки и достичь лучших результатов.
И к сотрудникам не надо относиться как к рабам, все профи и люди. И я подхожу к процессу так — что мы бежим марафонскую дистанцию. К финишу все напрягаемся, в процессе можем расслабиться. Вот создавая напряжения и расслабления — мы получим максимальную эффективность.
Собственно начальник смотрит на приоритеты задач и стратегическое направление.
Я всегда говорю, что мне нужны сотрудники не проблематоры (те, которые только могут что говорить проблема такая-то, не получилось по тому-то), а решаторы (тот который видя проблему приходит ко мне с один/двумя решениями, может отстоять свою точку зрения и взять на себя ответственность решить эту задачу)
Собственно, этим хороший специалист отличается от очень хорошего. И если у вас самоменеджмента, то обязательно появится человек, который будет терпеть ваши факапы, будет считать вас рабом и гонять до седьмого пота :)
Мир очень справедливый и сбалансированный и вы имеете ровно то, что заслуживаете :). Не нравится? Меняйте себя — а мир под вас подстроится. Хотите обсудить это — пишите в личку
А то, что сотрудник задерживается на работе после 19:00, то это уже сигнал руководителю. Даже у великих спортсменов есть тренер — не задавали почему? Потому, что сам себя не заставишь перейти какие-то рамки и достичь лучших результатов.
И к сотрудникам не надо относиться как к рабам, все профи и люди. И я подхожу к процессу так — что мы бежим марафонскую дистанцию. К финишу все напрягаемся, в процессе можем расслабиться. Вот создавая напряжения и расслабления — мы получим максимальную эффективность.
Собственно начальник смотрит на приоритеты задач и стратегическое направление.
Я всегда говорю, что мне нужны сотрудники не проблематоры (те, которые только могут что говорить проблема такая-то, не получилось по тому-то), а решаторы (тот который видя проблему приходит ко мне с один/двумя решениями, может отстоять свою точку зрения и взять на себя ответственность решить эту задачу)
Собственно, этим хороший специалист отличается от очень хорошего. И если у вас самоменеджмента, то обязательно появится человек, который будет терпеть ваши факапы, будет считать вас рабом и гонять до седьмого пота :)
Мир очень справедливый и сбалансированный и вы имеете ровно то, что заслуживаете :). Не нравится? Меняйте себя — а мир под вас подстроится. Хотите обсудить это — пишите в личку
Спасибо за статью, есть над чем подумать.
Очень интересует пункт «Постоянное повышение качества», какую еще литературу или ресурсы можете посоветовать для изучения в области ИТ?
Очень интересует пункт «Постоянное повышение качества», какую еще литературу или ресурсы можете посоветовать для изучения в области ИТ?
Я в свое время вдохновился вот этой книжкой www.mdk-arbat.ru/bookcard?book_id=1022852 — даже раздал ее всем своим подчиненным региональным руководителям, сейчас есть обновленный вариант тех-же авторов www.e5.ru/product/alternativnyiy-menedjment-put-k-globalnoy-konkurentosposobnosti-izdanie-2_7015018/?utm_source=Yandex.Market&utm_medium=cpc&utm_campaign=main&utm_content=7015018
Ну, а так же все что касается менеджмента Тойоты — ДАО ТОЙОТА, как-то так называется
Есть еще целое направление по качеству — поищите по авторам книги.
Ну, а так же все что касается менеджмента Тойоты — ДАО ТОЙОТА, как-то так называется
Есть еще целое направление по качеству — поищите по авторам книги.
Могу порекомендовать хорошие подборки книг для креативных бизнесменов и управленцев и лидеров
Про it не скажу, но вообще рекомендую книгу «3 ключа к созданию новой структуры управления» кеннета бланшара — она как раз про процесс вовлечения сотрудников в управление компанией. Книга достаточно универсальна и подходит и it и не it компаниям
Это все написано из жизни и собственного опыта.
У меня опыт 7+ лет управления, в том числе создание департамента разработки интернет проектов с нуля до 50+ человек + распределенное по стране матушке (региональные офисы) в компании 5000+ человек (очень известной, но называть не буду).
Это управление современное, оно реально работает, возьмите например, Яндекс или Битрикс.
PS: то что у вас не получилось, не значит, что это не работает.
Я за свои слова отвечаю! :)
У меня опыт 7+ лет управления, в том числе создание департамента разработки интернет проектов с нуля до 50+ человек + распределенное по стране матушке (региональные офисы) в компании 5000+ человек (очень известной, но называть не буду).
Это управление современное, оно реально работает, возьмите например, Яндекс или Битрикс.
PS: то что у вас не получилось, не значит, что это не работает.
Я за свои слова отвечаю! :)
А можете кинуть ссылку на какой-нибудь внятный текст, где описано, в чем же заключается эта существенная разница? Давно хотел понять, да никто не мог объяснить.
ПС Автору за статью спасибо. Многое из сказанного подтверждено и моим опытом.
ПС Автору за статью спасибо. Многое из сказанного подтверждено и моим опытом.
Хм…
Итак, обладая 10 летним опытом работы в IT, и пройдя множество ролей: тестировщик, дизайнер, программист, ведущий программист, руководитель: группы, отдела, подразделения, департамента интернет проектов, директора по развитию и наконец директора :)
Это как? Я насчитал 7 должностей (тестировщик, дизайнер, программист, ведущий программист, руководитель, директора по развитию, директора ) на 10 лет работы, это получается в среднем 1,5 года на каждой должности?
И в каждой должности за 1,5 года используя выше изложенный подход можно достигать вершины совершенства?
За статью спасибо, но верится с трудом и очень похоже на летуна или прыгуна (как там в терминах HR правильно), хотя не исключаю что автор стати действительно Гений.
Итак, обладая 10 летним опытом работы в IT, и пройдя множество ролей: тестировщик, дизайнер, программист, ведущий программист, руководитель: группы, отдела, подразделения, департамента интернет проектов, директора по развитию и наконец директора :)
Это как? Я насчитал 7 должностей (тестировщик, дизайнер, программист, ведущий программист, руководитель, директора по развитию, директора ) на 10 лет работы, это получается в среднем 1,5 года на каждой должности?
И в каждой должности за 1,5 года используя выше изложенный подход можно достигать вершины совершенства?
За статью спасибо, но верится с трудом и очень похоже на летуна или прыгуна (как там в терминах HR правильно), хотя не исключаю что автор стати действительно Гений.
Дизайн и тестирование, как и программист и ведущий программист уложатся максимум в год, суммарно — это была студенческая подработка и начальный опыт, в основном у меня идет все по управлению с технической подковкой.
Для HR — компаний менял мало, но часто менял должности вверх :)
По поводу Гений ли я — оставлю на ваш суд
Для HR — компаний менял мало, но часто менял должности вверх :)
По поводу Гений ли я — оставлю на ваш суд
>… за его косяки он может выполнять больше не престижной работы, например, для разработчика — это правка багов.
Уже не первый раз встречаю такое мнение, мол, вот ТВОРИТЬ — это престижно, а багфиксинг — мура и неблагодарный рабский труд. Почему? В моих глазах человек, способный исправить баги и заставить продукт работать как раз и является творцом и объектом уважения, а вот чудики, которые в отрыве от внешнего мира лабают чёрти-что, содержащие эти самые баги в огромных количествах и не отвечающие за них — чудики и есть.
Уже не первый раз встречаю такое мнение, мол, вот ТВОРИТЬ — это престижно, а багфиксинг — мура и неблагодарный рабский труд. Почему? В моих глазах человек, способный исправить баги и заставить продукт работать как раз и является творцом и объектом уважения, а вот чудики, которые в отрыве от внешнего мира лабают чёрти-что, содержащие эти самые баги в огромных количествах и не отвечающие за них — чудики и есть.
Так-то оно так, но разбираться в чужом говнокоде чем-то сродни чистке чужих сортиров. Это надо уважать, но делать это не хочется — вот почему это наказание.
Еще одна непрестижная профессия — написание тестов. Написать тест, способный поймать ошибку (да еще в сложных условиях, например в многопоточной среде) — большое искусство, но почему-то плятят за это меньше, чем тем, кто эти ошибки делает.
Еще одна непрестижная профессия — написание тестов. Написать тест, способный поймать ошибку (да еще в сложных условиях, например в многопоточной среде) — большое искусство, но почему-то плятят за это меньше, чем тем, кто эти ошибки делает.
Когда меня сажают на чужой проект с целью править баги я воспринимаю это весьма негативно. Свои править? Ну да — нормально, ведь это же я делаю продукт, а не правлю косяки в стороннем уже готовом продукте.
В таких случаях только деньги хорошая мотивация, а в противном случае это действительно рабский труд.
Если б я от этого кайфовал, то скорее всего сидел бы целыми днями на гитхабе и правил баги опенсорцных проектов, но что-то таких людей я много не вижу.
В таких случаях только деньги хорошая мотивация, а в противном случае это действительно рабский труд.
Если б я от этого кайфовал, то скорее всего сидел бы целыми днями на гитхабе и правил баги опенсорцных проектов, но что-то таких людей я много не вижу.
Я по своему опыту правил много и своих и чужих багов.
Если только влился в проект, правка багов заставляет тебя изучить существующий код. Параллельно простой правке багов приходят идеи по локальной оптимизации кода. Если в проекте уже давно и знаешь код, то править чужие баги легче, чем свои — ты сразу видишь «неправильный код». Локализация ошибки и её исправление требуют от тебя гораздо большего, чем просто кодинг. И, как правило, это интересно (пока не упираешься в сторонний код без возможности получить исходники)
Приводить в порядок проект почти всегда приятно.
Если только влился в проект, правка багов заставляет тебя изучить существующий код. Параллельно простой правке багов приходят идеи по локальной оптимизации кода. Если в проекте уже давно и знаешь код, то править чужие баги легче, чем свои — ты сразу видишь «неправильный код». Локализация ошибки и её исправление требуют от тебя гораздо большего, чем просто кодинг. И, как правило, это интересно (пока не упираешься в сторонний код без возможности получить исходники)
Приводить в порядок проект почти всегда приятно.
Я в своей команде играю роль менеджера среднего звена. Работаем в НИИ, пишем САПР. Проект большой, несколько человек, 2 года уже проекту.
Вот как по-вашему, по позитивному:
При завершении каждой локальной разработки коллеги зовут меня и говорят — смотри.
Смотрю. Нахожу ошибки. Показываю. Иногда вообще бросается в глаза то, что сделано нелогично на мой взгляд.
Но на сообщения об этом все реагируют по разному.
И некоторые (не все!) даже обижаются, когда им говоришь что надо доработать.
Периодически начинают спорить. Часто спор на уровне — «кнопка должна быть слева» — «нет кнопка должна быть справа».
Как грамотный менеджер будет показывать людям на их ошибки, чтобы это никого не задевало?
Вот как по-вашему, по позитивному:
При завершении каждой локальной разработки коллеги зовут меня и говорят — смотри.
Смотрю. Нахожу ошибки. Показываю. Иногда вообще бросается в глаза то, что сделано нелогично на мой взгляд.
Но на сообщения об этом все реагируют по разному.
И некоторые (не все!) даже обижаются, когда им говоришь что надо доработать.
Периодически начинают спорить. Часто спор на уровне — «кнопка должна быть слева» — «нет кнопка должна быть справа».
Как грамотный менеджер будет показывать людям на их ошибки, чтобы это никого не задевало?
Часто спор на уровне — «кнопка должна быть слева» — «нет кнопка должна быть справа».
Ну это же просто: аргументируем позицию, просим собеседника аргументировать свою. Неужели два взрослых человека не могут договориться, с какой стороны должна быть кнопка?
Попробуйте перенести споры про кнопки на этап перед реализацией. И постройте диалог в стиле — «а как ты думаешь что бы сказал Раскин если кнопку перенести туда-то?». А если пофиг с какой стороны кнопка то и не тратить на это время вообще.
Для начала попробуйте задать себе вопрос — почему у меня не получается указывать на ошибки людей, чтобы их это не задевало?
Второе, спросите у людей, почему они считают, что кнопка должна быть именно слева/справа? Пользуйтесь открытыми вопросами — чтобы достучасться до истины. И пытайтесь вопросами привести человека к нужному ответу. Обязательно расскажите, как вы видите ситуацию со своей стороны — это будет обратная связь для человека, со всем сомнениями, рисками, требованиями сверху и вашим пожеланием к системе.
И третье, тех кто самый спорщик или ярый противник всего и вся :), получите от него план решения какого-то вопроса, поспрашивайте почему так и эдак (т.е. тут вы меняетесь местами — он вам доказывает что нужно сделать, а вы только слушаете и задаете вопросы. Здесь лучше воздержаться от оценок плохо, совсем не то и тд, если что-то звучит правильно и созвучно с вашей мыслью — говорит хорошо, отлично. Это поможет сотрудникам адаптироваться под вас и лучше понимать что нужно предлагать.
И четвертое — назначьте ответственным за решение такого рода вопросов именно на этого самого ярого противника, тем самым он будет самым лучшим партнером и сам будет подсказывать в будущем, куда лучше двигаться
В итоге вы получите не иссекаемый поток идей снизу и все что вам нужно будет это его модерировать.
Более подробно можете почитать литературу по коучинг и корпоративный кроудсорсинг
Второе, спросите у людей, почему они считают, что кнопка должна быть именно слева/справа? Пользуйтесь открытыми вопросами — чтобы достучасться до истины. И пытайтесь вопросами привести человека к нужному ответу. Обязательно расскажите, как вы видите ситуацию со своей стороны — это будет обратная связь для человека, со всем сомнениями, рисками, требованиями сверху и вашим пожеланием к системе.
И третье, тех кто самый спорщик или ярый противник всего и вся :), получите от него план решения какого-то вопроса, поспрашивайте почему так и эдак (т.е. тут вы меняетесь местами — он вам доказывает что нужно сделать, а вы только слушаете и задаете вопросы. Здесь лучше воздержаться от оценок плохо, совсем не то и тд, если что-то звучит правильно и созвучно с вашей мыслью — говорит хорошо, отлично. Это поможет сотрудникам адаптироваться под вас и лучше понимать что нужно предлагать.
И четвертое — назначьте ответственным за решение такого рода вопросов именно на этого самого ярого противника, тем самым он будет самым лучшим партнером и сам будет подсказывать в будущем, куда лучше двигаться
В итоге вы получите не иссекаемый поток идей снизу и все что вам нужно будет это его модерировать.
Более подробно можете почитать литературу по коучинг и корпоративный кроудсорсинг
Приходит консультант на свиноферму, собирают там колхозников.
-Ну, господа колхозники! Свиней надо кормить.
-Верно!
-Ну, а еще их надо держать в тепле.
-Верно!
-А еще надо навоз убирать.
-Ну а как же! Господин консультант, а как же привес у поросят повысить?
-Ну это вы уж как-нибудь сами, я стратегией занимаюсь…
;)
-Ну, господа колхозники! Свиней надо кормить.
-Верно!
-Ну, а еще их надо держать в тепле.
-Верно!
-А еще надо навоз убирать.
-Ну а как же! Господин консультант, а как же привес у поросят повысить?
-Ну это вы уж как-нибудь сами, я стратегией занимаюсь…
;)
только за его косяки он может выполнять больше не престижной работы, например, для разработчика — это правка багов.
А как по-вашему стоит наказывать «отдел технической поддержки» (занимаемся допиливанием и модификацией сайтов, у нас 70% работы — правка чужих багов)?
Цель — получить однозначное подтверждение по выполнению задачи и взятие ответственности за это, т.е. решение где-то должно быть зафиксировано — пусть даже собственноручно записано в блокноте менеджера, либо как комментарий к задаче в каком-либо софте по управлению проектами или багтрекере
Очень трудно планировать сроки, если знаешь, что каждые пол часа тебя будут дергать «найти вот это», «поправить другой более срочный баг», «переключиться 5 раз на разные другие срочные новые задачи». А руководитель же снял с себя всю ответственность, сотрудник ведь сроки сам предложил, мог бы и догадаться, что будет от 1 до 10 других срочных задач!
В точку.
И везде нужно успевать — сроки то уже озвучил и обязался сделать…
И этот «супер-экстра критичный баг» не можешь не исправить!
Обычно при планировании почему-то забывают учитывать время на выполнение вот таких вот срочных и внезапных работ по поддержке.
Отсюда и конфликты.
И везде нужно успевать — сроки то уже озвучил и обязался сделать…
И этот «супер-экстра критичный баг» не можешь не исправить!
Обычно при планировании почему-то забывают учитывать время на выполнение вот таких вот срочных и внезапных работ по поддержке.
Отсюда и конфликты.
Делегирование не равно спихиванию ответственности. Почитайте об этом :)
А во вторых, для этого есть пункт 3, к вам приходят с новым супер срочным багом, а вы говорите — ок, что двигаем? Этот вопрос уже не в вашей компетенции, вы его тут же эскалируете и получаете решение (расстановку приоритетов) и идете дальше выполнять задачи.
Бывает так, что пришел какой-то постановщик с маленькой задачкой, например, на час, а в процессе выполенения давал уточнения, корректировки на пять часов :) было такое? Так вот тут нужно сразу ставить своего руководителя в известность и это уже его профессиональная работа разруливать такие вопросы.
А во вторых, для этого есть пункт 3, к вам приходят с новым супер срочным багом, а вы говорите — ок, что двигаем? Этот вопрос уже не в вашей компетенции, вы его тут же эскалируете и получаете решение (расстановку приоритетов) и идете дальше выполнять задачи.
Бывает так, что пришел какой-то постановщик с маленькой задачкой, например, на час, а в процессе выполенения давал уточнения, корректировки на пять часов :) было такое? Так вот тут нужно сразу ставить своего руководителя в известность и это уже его профессиональная работа разруливать такие вопросы.
Соглашаюсь с предыдущими ораторами в комментариях, но также отмечу, что в статье есть и дельные советы. Спасибо.
Спасибо за статью.
Хороший практический опыт.
Ждём продолжения.
>>Потом, вы очень скоро увидите, что люди переживают за результат не меньше вашего и готовы >>объединяться в кружки качества, сами двигают идеи и как не странно ужесточают стандарты, а самое >>интересное — такая система начинает мультиплицировать правильное поведение у всех сотрудников, а >>тем более у новых без вашего участия.
Э-эх…
А вот и нет.
Всем наплевать на результат.
Обычный ответ: ты менеджер — тебе за это дополнительные деньги платят — ты и переживай!
Пока ходишь — пинаешь, работа идёт, иначе останавливается…
Какие вы можете посоветовать способы поощрения/наказания для сотрудников?
Системы мотивации? Не материальные, т.к. не всегда можно влиять на з/п сотрудника.
Как повысить заинтересованность сотрудников — которым на всё и на всех наплевать?
Хороший практический опыт.
Ждём продолжения.
>>Потом, вы очень скоро увидите, что люди переживают за результат не меньше вашего и готовы >>объединяться в кружки качества, сами двигают идеи и как не странно ужесточают стандарты, а самое >>интересное — такая система начинает мультиплицировать правильное поведение у всех сотрудников, а >>тем более у новых без вашего участия.
Э-эх…
А вот и нет.
Всем наплевать на результат.
Обычный ответ: ты менеджер — тебе за это дополнительные деньги платят — ты и переживай!
Пока ходишь — пинаешь, работа идёт, иначе останавливается…
Какие вы можете посоветовать способы поощрения/наказания для сотрудников?
Системы мотивации? Не материальные, т.к. не всегда можно влиять на з/п сотрудника.
Как повысить заинтересованность сотрудников — которым на всё и на всех наплевать?
Присоединяюсь к вопросу.
Спасибо за интерес.
На эту тему уже написана мною статья "Позитивный менеджмент (Управление без управления — часть 2)", так же если интересно у меня есть уже и несколько других статей в этой тематике.
На эту тему уже написана мною статья "Позитивный менеджмент (Управление без управления — часть 2)", так же если интересно у меня есть уже и несколько других статей в этой тематике.
up
К сожалению, не работает. Подобные процессы возможны исключительно на основе какой-нибудь бюрократии, что неизбежно влечёт пробуксовку. Простейший пример:
1. Нашёл проблему, написал менеджеру.
2. Работа стоит.
3. У менеджера стопицот подобных запросов.
4. Работа стоит.
…
666. 70% времени тратится на пробуксовку.
Проэскалировать-то не проблема, а сколько ждать ответа? А если команда географически распределённая? Я в такой ситуации жил, уходило до недели на разрешение простейших вопросов.
Такой подхож возможен разве что в какой-нибудь конвейерной системе, где 90% сотрудников взаимозаменяемы, задачи разбиты на атомарный подзадачи, которые кто угодно может делать. А если не конвейер, а разработка в условиях непрерывно меняющихся требований?
1. Нашёл проблему, написал менеджеру.
2. Работа стоит.
3. У менеджера стопицот подобных запросов.
4. Работа стоит.
…
666. 70% времени тратится на пробуксовку.
Проэскалировать-то не проблема, а сколько ждать ответа? А если команда географически распределённая? Я в такой ситуации жил, уходило до недели на разрешение простейших вопросов.
Такой подхож возможен разве что в какой-нибудь конвейерной системе, где 90% сотрудников взаимозаменяемы, задачи разбиты на атомарный подзадачи, которые кто угодно может делать. А если не конвейер, а разработка в условиях непрерывно меняющихся требований?
Материал очень интересный, спасибо.
Единственный недостаток: ваш русский язык хромает, как минимум на полторы ноги.
Единственный недостаток: ваш русский язык хромает, как минимум на полторы ноги.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление без управления — часть 1