Такое впечатление, что все менеджеры/управленцы делятся на два типа:
— те кто считает, что можно выстроить управляемую таким образом вертикаль и автоматизировать ее. При этом, когда они видят негативные примеры, то списывают это на ошибки внедрения и конечно же: «Я все сделаю по другому и правильно»;
— те, кто уже пробовал и понял, что таким образом это не работает.
Есть еще третий тип, это профессиональные «внедренцы» средств автоматизации. Я как раз занимаюсь именно этой работы и до момента пока я не попробовал внедрить все «лучшие практики» у себя в компании тоже думал, что все проекты по внедрению были нами блестяще выполнены.
Так а в чем смысл пересекается или нет?
Человек мог заработать за период времени X денег, а заработал 0,05X.
Какой ROI его затеи и можно ли считать ее успешной? Вот вы говорите «вышел в плюс», а я вижу что просто потерял деньги.
Смог выйти в плюс или смог окупить собственные затраты? Я думаю если посчитать стоимость часа его работы и сколько он вложил времени в этот проект, то все станет на свои места.
Ну и если мы говорим о «нормальности», то нормальный предприниматель дает работу десятку программистов, дизайнеров, маркетологов. А здесь человек не смог даже выйти на уровень самозанятости.
Программисты всегда думают, что они царь зверей в мире высоких технологий, пока не приходится столкнуться с маркетингом, продажами, PR и всеми выходящими. И как результат больно часто «цари» убегают с поджатым хвостом в родную савану.
Мне нечего возразить, но в части наших ожиданий от менеджера я не вижу больших противоречий.
За определение адекватности спасибо, наверное с этого и стоило начать.
Что-то мне кажется, что вы сильно усложняете. Понятие адекватности вполне универсальное:
— уважение к чужому труду, чужому мнению, потребностям;
— наличие компетенций и знаний в области деятельности;
— честность, смелость отстаивать интересы команды и брать на себя ответственность;
— умение слушать;
— желание и возможность учиться новому.
Поэтому адекватный менеджер будет эффективный в какой был методологии он не работал и какие процессы бы не поддерживал. Другое дело, что если процессы противоречат его ценностям, то как честному человеку ему лучше найти другую работу и оставаться в душевном спокойствии.
Вот тут браво просто. Адекватный менеджер это для вас неэффективный значит :)? Который заваривает кофе и развлекает всех в паузах? Это называется секретарша.
Спасибо за материал, очень крутой. Для многих сигналов инструменты внедрили уже, а для остальных на подходе.
Обидно только, что сейчас набегут скулящие разработчики, которые в любом порядке видят посягательство на их нелегкую судьбу.
Фулстечности программиста будет достаточно для менеджера? Ну что же, это будет неплохим стартом и можно даже получить титул Middl Project manager и уважение в лице разработчиков команды. Но дальше разобраться еще как минимум придется в маркетинге (PPC, SEO, SMM, копирайтинг), продажах, дизайне (UX/UI), аналитике (GA, Unit-экономика), HR и методологиях управления проектами. Разобраться естественно будет мало и нужно будет уметь ручками это делать самому и делать регулярно, как минимум для того чтобы дизайнеры, маркетологи, аналитики, продажники не закатывали глазки, когда получают свои задания от менеджера, а как максимум потому что людей с этими ролями в команде нет и делать нужно все самому. Еще скорее всего придется стать экспертом в предметной области, которой работает компания. Что еще? Еще зависит от компании. Возможно потребуется время пройти разные гавнообучения и сдать экзамен на PMbok или упаси Господи вступить в секту Agile и через 10 лет плясок тамадой стать Agile коучем.
Все ли менеджеры такие? Конечно нет, но я же не думаю, что автора устроит быть гавноменеджером с узкими и поверхностными знаниями и нормально разбираться только в разработке, при этом пойти сходу на понижение ЗП, а для всех других ролей в команде оставаться вечным неучем и безруким, который даже не может настроить рекламную кампанию за пару часов.
А, ну собственно к чему это я. Рассказываю, что менеджером быть сложнее, чем программистом? Нет, я не преследую цели сравнивать вообще. Это может делать человек, который и в той и в той области добился больших успехов. Я говорю о том, что фулстечность это бич не только разработчиков и убегая от нее в коде можно попасть в ловушку фулстечности в управлении
Я за разумные буфера в рамках задач. Есть набор задач, которые объединены в один пакет и общая оценка пакета в районе 50-60 часов. Добавляем к задаче буфер в районе 10-15% от общего скоупа всех задач и тогда по каждой задаче не нужно отслеживать получилось 6 часов или 8. Точка мониторинга это не превышение общего буфера по пакету задач.
Это значит только то, что нужно быть сфокусированным и стараться выполнить работу в рамках оценки. Работать можно тоже с разным уровнем отдачи: например параллельно отвлекаясь на флуд с коллегами, перекуры, посещение необязательных митингов. Оценка позволяет смотреть на некоторые вещи по другому, а стоит ли например прямо сейчас поучаствовать в политической дискуссии или поспорить с кем-то на хабре или все таки уделить время задаче?
Почему? В моем случае это неотъемлемая процедура в рамках процесса управления разработкой.
Я делаю продукт и сколько на него времени нужно столько и трачу, и это разумное время не больше не меньше нужного, другое меня не интересует.
Мне кажется вы банально не понимаете зачем нужна менеджеру оценка. Оценка инструмент управления проектом, который позволяет управлять ожиданиями стейкхолдеров с одной стороны, а с другой стороны сделать загрузку всех участников равномерной (без трудовых подвигов и без спадов в рабочей нагрузке).
Есть ли у разработчика право на ошибку? Конечно есть, в этой ситуации главное, чтобы он обновил оценку на новую, а не ждал дедлайна задачи и только потом сообщал, что ничего не готово. Задача менеджера при изменениях оценки оценить импакт на общий ход проекта и если риски изначально это не покрывали уладить вопрос со стейкхолдерами.
Как часто разработчик может ошибаться? Столько, сколько будет нужно чтобы он обучался нормально оценивать задачи. Главное видеть улучшения качества оценок с его стороны и заинтересованность выдавать правильные оценки.
Если его нет, то действительно всем будет проще пожелать друг другу удачи.
Могу подписаться под каждым словом. Задача менеджера/руководства оценивать риски заранее и компенсировать их, а разработчик любой квалификации может ошибиться с оценкой. Это часть рабочего процесса, а не трагедия и трагедию из-за неправильной первоначальной оценки делают только недальновидные люди.
Оценка не должна быть обязательством, это инструмент управления проектом, а не перестраховка риска за счет разработчика.
— те кто считает, что можно выстроить управляемую таким образом вертикаль и автоматизировать ее. При этом, когда они видят негативные примеры, то списывают это на ошибки внедрения и конечно же: «Я все сделаю по другому и правильно»;
— те, кто уже пробовал и понял, что таким образом это не работает.
Есть еще третий тип, это профессиональные «внедренцы» средств автоматизации. Я как раз занимаюсь именно этой работы и до момента пока я не попробовал внедрить все «лучшие практики» у себя в компании тоже думал, что все проекты по внедрению были нами блестяще выполнены.
Вы случайно не из тех менеджеров, кто доводит «уровень исполнительской дисциплины» до 90% и с чувством выполненного долга меняет предприятие?
«На порядки» это как минимум в 100, если что
Человек мог заработать за период времени X денег, а заработал 0,05X.
Какой ROI его затеи и можно ли считать ее успешной? Вот вы говорите «вышел в плюс», а я вижу что просто потерял деньги.
Ну и если мы говорим о «нормальности», то нормальный предприниматель дает работу десятку программистов, дизайнеров, маркетологов. А здесь человек не смог даже выйти на уровень самозанятости.
За определение адекватности спасибо, наверное с этого и стоило начать.
— уважение к чужому труду, чужому мнению, потребностям;
— наличие компетенций и знаний в области деятельности;
— честность, смелость отстаивать интересы команды и брать на себя ответственность;
— умение слушать;
— желание и возможность учиться новому.
Поэтому адекватный менеджер будет эффективный в какой был методологии он не работал и какие процессы бы не поддерживал. Другое дело, что если процессы противоречат его ценностям, то как честному человеку ему лучше найти другую работу и оставаться в душевном спокойствии.
Обидно только, что сейчас набегут скулящие разработчики, которые в любом порядке видят посягательство на их нелегкую судьбу.
Все ли менеджеры такие? Конечно нет, но я же не думаю, что автора устроит быть гавноменеджером с узкими и поверхностными знаниями и нормально разбираться только в разработке, при этом пойти сходу на понижение ЗП, а для всех других ролей в команде оставаться вечным неучем и безруким, который даже не может настроить рекламную кампанию за пару часов.
А, ну собственно к чему это я. Рассказываю, что менеджером быть сложнее, чем программистом? Нет, я не преследую цели сравнивать вообще. Это может делать человек, который и в той и в той области добился больших успехов. Я говорю о том, что фулстечность это бич не только разработчиков и убегая от нее в коде можно попасть в ловушку фулстечности в управлении
Почему? В моем случае это неотъемлемая процедура в рамках процесса управления разработкой.
Мне кажется вы банально не понимаете зачем нужна менеджеру оценка. Оценка инструмент управления проектом, который позволяет управлять ожиданиями стейкхолдеров с одной стороны, а с другой стороны сделать загрузку всех участников равномерной (без трудовых подвигов и без спадов в рабочей нагрузке).
Есть ли у разработчика право на ошибку? Конечно есть, в этой ситуации главное, чтобы он обновил оценку на новую, а не ждал дедлайна задачи и только потом сообщал, что ничего не готово. Задача менеджера при изменениях оценки оценить импакт на общий ход проекта и если риски изначально это не покрывали уладить вопрос со стейкхолдерами.
Как часто разработчик может ошибаться? Столько, сколько будет нужно чтобы он обучался нормально оценивать задачи. Главное видеть улучшения качества оценок с его стороны и заинтересованность выдавать правильные оценки.
Если его нет, то действительно всем будет проще пожелать друг другу удачи.
Оценка не должна быть обязательством, это инструмент управления проектом, а не перестраховка риска за счет разработчика.