Вхід і реєстрація
Про роботу · 27 серпня 2009, 6:29 64
Ole G, Trainer в MTI hi-tech дистрибуція

incorrect management

Предлагаю на обсуждение еще одну злободневную тему — менеджмент, который мог бы быть/стать значительно лучше.

Example (из личного опыта):

Утро. Секретарь.- Срочно зайти к Боссу, дело жизни и смерти.

Босс — Вот миссия№ 1, которую нужно выполнить исключительно до обеда.

Через 3 часа — звонок Босса — приоритеты поменялись, миссия№ 1 подождет, срочно нужно сделать большое дело № 2.

Еще через 2 часа — Босс: «Ты № 2 делаешь? », отлично, параллельно сделай еще задания № 3, № 4, № 5, они небольшие, это большому делу № 2 не повредит.

Еще через 1, 5–2 часа — Босс, а как там обстоят дела с миссией№ 1?

Ну хорошо, закончишь большое дело№ 2, доделай миссию№ 1.

Думаю, у многих есть чем поделиться по этому поводу.

Теми: менеджмент
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
anonymous 10.09.2009 18:37
По теме
1. Равная з/п практически у всего тима (точнее 2 зарплаты — большая и маленькая), причем меленькая только у жуниоров. Другими словами менеджер понятия не имеет насколько и кто ценен или не ценен для работы.
2. Составление эстимейшинов без совета с конкретными исполнителями и вообще с кем либо при полном незнании, что нужно делать и насколько сложными/простыми являются задачи с указанием конкретной даты релиза и информированием об этом топ менеджмента.
3. Полное игнорирование потребностей тима, включая человеческие, например за успешно, вовремя и без багов сданный проект даже спасибо не говорят.
4. Постановка стратегии управления не «понимать почему все работает как часы и делать все возможное чтобы сохранить и улучьшить ситуацию», а «тушения пожаров». Тушение пожаров невероятно отличная стратегия для карьериста, так как каждый день новая проблема и рапорт про её «успешное решение» высшему руководству. При правильном подходе (сохранять все врабочем состоянии) говорить с руководством не о чем, все ведь работает... итого, уделять такому менеджеру босс будет 5 минут в неделю, относительно других, которые на его глазах тушат пожар — холить и лелеять как наиболее успешных (столько проблем решили за неделю, а этот — «ни одной»).
5. Неправильное понимание руководством, что если откуда-то нет отчетов о проблемах, но ВСЕ ДОСТОВЕРНО работает без нареканий от кого-либо, то это стоит много дороже, чем бригада бестолковых «пожарников» на другом фланге. Пример — высказывание мега босса «последняя наделя была крайне напряженной, менеджер Х, на прошлой неделе, 3 раза бегал в другой офис нашей-же компании чтобы подписать бумаги» (другими словами должен был начать заниматься этой проблемой месяц назад) и это при том, что программеры + аналитики работали над этой программой не покладая рук в течении 5 месяцев и в эту последнюю неделю наблюдали (т.е. багрепорт был пустой) как нерадивые пожарники с удивлением узнали про надвигающийся релиз и хаотично пытались согласовать документ на 5 листах уже после того, как было закуплено (проблемы с поставщиками, таможней), установлено и настроено (не очень квалифицированный персонал) оборудование, программа написана с нуля (25 физических серверов, 19 модулей с трудоемкостью по 2−3 человеко-месяца) успешно прошла этап тестирования и до сих пор работает без багов. Реально за ИТ было на порядок больше согласований и решено значительно больше проблем, но они были решены без вовлечения в этот процесс мега босса и в срок.
По поводу решения проблемы, которую выдвинул автор темы — Тут надо добавлять «лежачего полицейского». Обычно это делается в виде формальной (написанной на бумаге в НОРМАЛЬНОМ виде) спецификации. + нечто типа Jira с указанием приоритетов. Кроме того, в качестве лежачего полицейского можно смело каждый раз объяснять, что «разогнать паровоз» и «остановить паровоз» это 2 часа времени. И если таск занимает 15 минут, то его реальное время исполнения 2 часа 15 минут. Если босс вменяемый — будет реже дергать, если нет — будет достаточно времени на «попить кофе» + четко показать боссу про правидность сделанных эстимейшинов.
2 Oleg Seryogin
При праильной атмосфере в коллективе всегда можно узнать, что что-то кого-то не устраивает и почему. Значительно хуже, когда подобный фидбек изложенный даже в письменном виде в сторону менеджмента грубо игнорируется.
2 Tim

Разделение крупных тасков на мелкие таски — уместно при инкрементном подходе в прогрммировании или багфиксинге (как напоминание чтобы незабыть). В данном случае я бы рекомендовал делить таски по принципу возможности распараллеливания тасков на второго человека + всегда учитывал реального исполнителя + взаимозависимость задачь выполняемых разными исполнителями. Другими словами если есть крупная задача на неделю (и больше), но разрезать её на что-то мелкое и отдельно это мелкое контролировать нет смысла (есть нормальне люди у которых не нужно все время стоять за спиной) — то человек во первых сам оптимизирует свое время, во вторых не будет тратить свое время на ведение этих тасков в системе типа Jira. Например, в одной из компаний в тайм шитах у многих девелоперов честно красовался только 1 таск «подсистема такая-то 100% времени» и вопросы чаще возникали по поводу 2го и других тасков к постановщикам этих тасков — «зачем Вы его отвлекали??? ».

Відповісти
Підтримати
Вадим Міхневич Application Architect в SoftServe 07.09.2009 09:47

Да-да, а еще раньше — расстреливали, или на кол сажали, дабы другим неповадно было. А еще тогда и трава была зеленее, и солнышко ярче...; -)

Відповісти
Підтримати
eugene_n 06.09.2009 13:50

И как же они следили за сроками, если шеф меняет задание 5 раз по дню?

Таких людей в начальство не брали. Или выпирали после закономерно заваленных проектов.

Відповісти
Підтримати
Grez 06.09.2009 12:19

Да неужели?
И как это раньше люди жили, планы составляли, за сроками следили.

И как же они следили за сроками, если шеф меняет задание 5 раз по дню?

Відповісти
Підтримати
eugene_n 06.09.2009 10:50

Кстати, для борьбы с указанным автором положением дел, придумали замечательную методологию scrum.

Да неужели?

И как это раньше люди жили, планы составляли, за сроками следили.

Відповісти
Підтримати
Grez 06.09.2009 09:51
Кстати, для борьбы с указанным автором положением дел, придумали замечательную методологию scrum.

Она не решает многие проблемы, но жить становиться реально легче.

Відповісти
Підтримати
anonymous 31.08.2009 11:11

Добавлю от себя — таски должны быть максимально краткими по времени исполнения. Если таск расчитан на неделю, дробим его на составные, так будет гораздо эффективней для переключения человека на другой таск. Считаю смену таска раз в день вполне допустимым, конечно «3 задачи до обеда» — это очень напряжно и получается что работал кучу времени, а ничего толком не сделал (а обычно так и бывает, особенно если таски слабо связаны между собой и достаточно сложные). Важность утренних стендапов также сомнению не подлежит:), так как отсеивает появление «затяжных тасков». Тут упоминали синдром «не спеши делать работу, все равно задание поменяют» — очень плохое явление, самому довелось поработать в такой среде, явно свидетельствует об очень низком уровне манагеров.

Відповісти
Підтримати
Андрей Трубин VP of Engineering в AgileEngine 30.08.2009 22:51
Вот, зацепило:
www.happy-pm.com/blog p=2403
По теме незапланированных «отвлечений», рандомных эстимейтов и выпадения разработчиков из состояния «потока» есть очень наглядная презентация:
www.slideshare.net/...s09-part-1-of-4 — Показывать боссу (кем бы он ни был) в обязательном порядке.
Добавлю от себя, т.к. нахожусь то по одну то по другую сторону баррикад (т.е. и в девелопменте и в менеджменте в разное время): частая смена задач как своих собственных, так и задач подчиненных, в большинстве случаев ведет к катастрофическому падению продуктивности, ибо начинался жизненный цикл «брошенной» задачи: бросить текущую задачу, покурить-попить кофе, вьехать в новую, начать делать, получить реквест на еще одну задачу, и так по кругу). В особо сложных случаях люди ВООБЩЕ могут перестать работать, свято следуя принципу: не спеши выполнять приказ (задачу) — он может быть отменен либо вышестоящим начальником либо самим начальником. Частая смена приоритетов свидетельствует в общем случае о неправильном процессе планирования (это если обобщить очевидное), либо о неуверенности менеджера в выбранном курсе, из-за чего он дергается сам и дергает подчиненных. Грешен, иногда таски людям менял в вышеупомянутом стиле, когда заказчик в срочном порядке просил исключить из плана уже начатые задачи, чтобы всунуть в него в план другие задачи, более приоритетные. НО! Обычно сразу согласовывались дополнительные сроки/трудоемкость, связанные с «переключением» конкретного человека с одной задачи на другую (иногда запас получался достаточным, чтобы таки завершить «брошенную» задачу, и вдобавок сделать новую -, но такое прокатывало только с довольно вменяемыми заказчиками).
Ну и в заключение, хотел бы немного расширить пункт (4) предыдущего докладчика: людям на любом уровне, будь это исполнители или менеджеры, стоит методично, день за днем, вдалбливать в голову, что переключение между задачами — штука не только НЕБЕСПЛАТНАЯ, но иногда и весьма ДОРОГОСТОЯЩАЯ. Когда это понимание будет достигнуто, дабы всем было ясно что проблема не только ЕСТЬ, но и что ее надо РЕШАТЬ, вот тогда уже и переходить к решению с помощью конкретных методик (варианты указаны в предыдущих постах).

P.S. Всегда забавляли диаграммы Ганнта, когда на одного человека в один период времени было навешено больше одной задачи (50% — тут, 50% — там). Полтора землекопа... В лучшем случае получается: 25% — тут, 25% — там. А в реале: ХЗ% — тут, ХЗ% — там, но всегда больше суммарного запланированного срока на обе задачи.

Відповісти
Підтримати
Vladyslav Kurmaz CTO 28.08.2009 10:14
Вставлю и свои пять копеек:)
Описанная топикстартером проблема была ключевой для меня при увольнении с недавнего места работы.
В состоянии аффекта даже статью написал:) (www.developers.org.ua/...orum/topic/813
Как было правильно отмечено, подобная активность присуща процессу бизнес исследования.
Когда под заказ рынка создаются прототипы с целью привлечения клиентов и прощупывания ниш.
В идеале, этим должна заниматься выделенная команда в тесной связи с маркетинговым отделом и отделом продаж.
В небольшом коллективе: шеф + исполнитель.
Необходимое условие: чёткая постановка задачи и высокопроизводительный набор инструментария. Количество параллельно идущих «проектов» определяется только квалификаций исполнителя и его финансовым вознаграждением.
Второй вариант, также отмеченный: обработка RFP.
Один из этапов классического аутсорса: прототипирование с целью более детального выявления требований и/или обоснования расширения сроков и бюджета.
Коллектив и условия полностью идентичны первому варианту.
Если автор работает в одной из перечисленных зон — ну что ж — это специфика занимаемой должности.
Если же на него подобные задания навешиваются совместно с основной проектной работой — ничего хорошего из этого не выйдет (я выдержал 2 года:)).
Резюме:
1. Проблема и причины конфликта определены.
2. Решение: эскалация конфликта на тот уровень на котором проблема может быть решена. Если непосредственный начальник не решает её, необходимо идти на уровень выше и т.д.
3. Методология: формализация процесса, необходимо выработать такую схему работы, которая бы удовлетворяла и заказчика (шефа) и исполнителя. Таск-трекер один из вариантов. Введение автоматического расширения времени выполнения уже идущих задач для компенсации пенальти по переключению и т.д и т.п. На каждой фирме ситуация специфическая и набор решений должен быть адекватный.

4. Но самое главное, чтобы в решении были заинтересованы обе стороны. Если этого нет, то и рассчитывать на изменения ситуации в лучшую сторону не стоит.

Відповісти
Підтримати
Вадим Міхневич Application Architect в SoftServe 28.08.2009 09:29

Даже вменяемый человек не всегда в состоянии за всем уследить, особенно за недовольными молчунами. Если что-то не так — с вменяемым человеком надо об этом говорить. Насчет невменяемых согласен.

Відповісти
Підтримати
eugene_n 27.08.2009 14:06

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

А зачем? У человека вменяемого, как правило, не бывает семь пятниц на неделе, а объяснять невменяемому, что он неправ — себе дороже.

Відповісти
Підтримати
Regfor 27.08.2009 12:39
Проблема может быть даже не в боссе/менеджере. Есть слишком много факторов. Проблема например может быть в самом бизнесе и то какими способами он ведется. То что вы написали, по моему мнению, напоминает либо фриланс либо аутсорс причем не самый лучшый. Либо все зависит от личных качеств, остуствии четкой линии и видения проекта, когда требования меняются на лету. С другой стороны то что требования меняются на лету не есть плохо, потому что меняются запросы бизнес, для которого ИТ упрощает жизнь. Важно чтобы был поставлен процесс, чтобы такая изменчивость не была хаотичной. Например моежт стоит попрактиковать SCRUM или какую-то другую методологию которая больше подохдит.

passant правильно сказал необходимо вводить систему таск/баг трекинг с четко установленными приоритетами. Кстати не мешало бы чтобы компания старалась пройти т.н. тест Джоеля состоящий из 12 пунктов. Это может значтительно улучшить процесс разработки.

Відповісти
Підтримати
anonymous 27.08.2009 12:14
Тогда попробую восстановить мой потертый ответ.: -)
Описанная проблема — увы «снизу» не лечитьтся.
Если предположить, что «босс» на самом деле некий «проект-менеджер», то эта проблема лечиться только «сверху», то есть «самым большим боссом». И лечиться жестким (жесточайшим) введением таск-трекинга. Т.е. все задания — только через систему, с указанием приоретета, оценок, сроков, отчета и пр. Нет записи в таск-трекинге — нет задания. Потому как проблема показывает откровенно низкую квалификацию проект-менеджера, а так-же некоторые особенности его психотипа. Все что может сделать «исполнитель» в данной ситуации — подтолкнуть «самого большого босса» к необходимости такого лечения, если у него есть выход на этого начальника. Но мотивировки должны быть обтекаемые — улучшение планирования, контроля, и пр., т.е интересы «конторы» в целом. И никогда не прямая жалоба на «проект-менеджера».

А вот если так ведет себя действительно «босс», т.е. самый большой начальник в фирме — тогда ховайся. Есть выбор — или склонить голову и смириться, или уволиться. Потому-как такое отношение к работе показывает неуважительное отношение к сотрудникам это раз; очевидное неумение оценить реальные трудозатраты на работу- это два, а мой личный опыт говорит, что такого типа «босс» оказывается в случае любых возникающих внешних проблемах склонным к поиску «виновных» именно среди подчиненных, и никогда -"среди себя" -это три. Как следствие все это приводит к неадекватности вознаграждения за потраченный труд (и нервы), и скорее всего к весьма сложным отношениям внутри коллектива. Про пожизненную роль «крайнего» для исполнителя в случае любых производственных проблем я даже не упоминаю.

Відповісти
Підтримати
Ole G 27.08.2009 08:57
to passant
Вы абсолютно правильно поняли мою задумку. Именно «проблема — ищем лекарство от нее».
А в идеале скорее всего «проблема — возможные последствия — ищем лекарство».
Долгое время работаю в менеджменте и знаю, что манагеры далеко не ангелы.
НО! Фидбек манагеры обычно получают только после того, как сотрудник увольняется из компании.
Так вот один из вариантов улучшить качество работы манагеров — это получить обратную связь по конкретным случаям с другими вариантами выхода из проблемы.
Мало того — это опыт для других, кто может попасть в подобную ситуацию.
Из опыта — если инициировать хотя бы просто вариант «поделиться по поводу», то обязательно найдутся люди, которые будут искать варианты выхода из ситуации. А значит автоматически получится вариант «проблема — ищем варианты ее решения».
Очень хорошо, что Вы задали вопрос, в самую тему попали.

Спасибо.

Відповісти
Підтримати
anonymous 27.08.2009 07:43
Я написал ответ, потом его потер. Потому-как возник вопрос, а что топикстартер имел ввиду?
Есть двf варианта — или «обозначаем проблему — ищем лекарства от нее», или просто «поделиться по этому поводу», т.е. картинки из жизни на тему incorrect management. Я написал ответ в первом ключе — потом засомневался, правильно ли я понял замысел автора и стер: -) до прояснения.

А вообще-то в февральском номере «Открытых систем» (кажется) была хорошая статья «Общие ошибки управления проектами». Там их полтора десятка сколлекционировано. Кому интересно — рекомендую.

Відповісти
Підтримати
eugene_n 27.08.2009 07:33

Для отечественного менеджмента это более чем типично, для буржуйского 50−50. Впрочем сейчас конторы без четкого целеуказания посыпались как спелые грушки.

Відповісти
Підтримати

Підписатись на коментарі

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.