да ладно: 5% не отменяют 95%. Кросскультурным особенностям можно посвятить отдельную статью (верно, я работаю в американо-российской системе ценностей менеджмента и в азии не прокатит), но
сколько у нас (= читающих данную статью) компаний и менеджеров, которые работают с Азией? не более 5%
у меня просто нет опыта в этом дальше Казахстана
ну и кстати, опыть Тинькова. развивающего Plata показывает, что культурные особенности можно сглаживать, если цель интересная.
Любой руководитель с определенного уровня должен принимать решения быстро, делегируя часть ответственности своим сотрудникам-менеджерам.
Не будет ответственной команды под таким менеджером среднего звена - он всегда (да, категорично) будет по уши в операционке. Потому что не умеет делегировать.
Я категоричен не просто так: у меня опыта в айти больше 25 лет , из которых 20 - управленческий, и я много общался с СЕО и другими менеджерами. Везде одно и тоже: если не учить своих РП разбираться самостоятельно (да, через боль и их ошибки) - они не научатся, сколько не разжевывай.
Больше того, сами ребята менеджеры мне много раз признавались, что так было им больнее, но намного эффективнее. Пока начальник - папка, можно прятаться за его спиной бесконечно.
если речь про менеджеров, то, независимо от возраста, менеджер должен уметь говорить кратко, по существу и выделяя самое главное.
Не умеет - должен учиться.
На практике сам проверил: пока решаешь задачи за менеджеров, объясняешь им все по 10 раз - они не учатся. Учить это 1-2 раза объяснить а дальше спрашивать результат. А реально крутого даже учить особо не надо - сам потыкается и найдет самые эффективные пути (но таких очень мало)
Удивительно мало комментариев, статья то хорошая. Ясно что ребята себя продвигают, ну и ничего страшного.
По трендам наблюдаю тоже самое, кроме ИИшницы. Нифига она не способна ничего заменить в проектном управлении, кроме ведения протоколов встреч.
Даже тупая работа Администратора проектов по сведению таймшитов из джиры не автоматизируется через ИИ, там просто правильно надо выстроить процесс и убрать администратора, как факт.
Облака, фокус на людей (привет комментатору выше) и data driven управление - это то что нас ждет.
хороший пример непроработанной для начальника эскаляции) вы скажете "нет бюджета, иди еще думай" - и пошлете менеджера подумать еще раз, не тратя кучу времени на выслушивание обоснования. Что и есть экономия вашего (и его) времени.
В следующий раз он придет с другими вариантами, которые вам подойдут лучше, но начнет не с прелюдии а с того, о чем я писал отдельно: "есть проблема, есть такие то варианты решения, прошу вас выбрать".
Суть подхода не в правильной формулировки цели - про это есть отдельная статья (кстати, надо добавить ссылку). Суть в том, чтобы сразу сказать цель, чтобы собеседник выбрал сам: слушать дальше или нет.
Одобряю в той части, где про выделение критичного для заказчика и максимального встраивания в существующие процессы.
В статье мало данных по примеру: реально сказано только о добавлении одного шага в процесс обновления базы знаний. И это серьезно все? Если так, зачем про это сказано, если не так, то где же детали (
В частности, очень хорошее начало про РП, которые там уже 15 лет EPR внедряют с помощью Экселя и такой то матери. И как именно вы их уговорили переехать на ИСУП? или не уговорили? Ведь главный их аргумент - "вы не ускорите, а замедлите нам работу, дорого СЕО, имей ввиду, что теперь я буду тратить времени больше на соблюдение этих глупых правил" не так то просто побить )
Если вы руководитель PMO, предлагаю вам подумать о следующем: ваши сотрудники, которые загружены до предела и не имеют времени/желания на прокачивание смежных навыков, по сути не растут, могут чаще выгорать, теряются как только попадают в непривычные условия и надо сделать шаг влево-вправо от привычной конвы. Это точно в интересах вашей организации?)
Мне мои менеджеры в полном составе говорят "спасибо" за развитие. Я даже менторингом занялся из-за этого.
Я наверное сходу резковато сказал, так иногда словами выглядит. Реально я категорически ЗА развитие любого человека в рамках организации. Сам писал про это: взаимное развитие возможно только при совпадении целей организации и сотрудника (тут можно сделать ремарку, что далеко не все сотрудники осознаны, чтобы понимать свои цели на 1-3-5 лет, но фиг с ним).
Но есть нюанс. У меня правда много опыта, я очень много где работал и сам в роли РП и я знаю, какие навыки РП нужны, а какие нет. И для меня, как представителя компании, и для моих РП, которые хотят и готовы расти профессионально, важно развивать то, что нужно чаще. А это софтскиллы: умение работать с заказчиками и капризным бизнесом, умение работать в потоке задач, делегирование и прочие веселости.
И вот этому я учу своих на практике. А заодно учу ценить себя, выпихиваю в отпуск, чтобы не выгорели (потому что нафиг оно мне надо - искать хорошего РП с рынка долго и дорого) и так далее.
В этом списке есть навык РП быть аналитиком и разбираться в технике ровно настолько, чтобы иногда взять на себя отвествтенность за какое-то решение, предложенное командой (или хотябы просто понять изменения и уметь пояснить заказчикам при необходимости).
Но нет навыка разработки, так как все кейсы, когда это было надо (и приведенный выше вами) решался на уровне описания требований и постановки тикета разработчику.
Так-то, разумеется, веселится каждый так, как хочет. Я вот знаю CDTO очень большой компании, который на досуге балуется Питончиком, чтобы чувствовать себя "в строю" :)
Но к его работе отношения это, конечно, не имеет. Когда ему необходимы серьезные дашборды (а у него 10 тыс человек в организации), он зовет свое аналитическое управление, а то управление зовет подрядчиков, чтобы те подогнали данные для отчетности. То есть в реале оно вот так.
судя по описанию и вашему ответу, б) у вас есть, это ясно. но а) у вас пока что нет, а точнее, вы выковыриваете его из заявок, что , скорее всего, боль и место для оцифровки.
собственно это то о чем я говорил в п 1 выше: обычное ресурсное планирование в ИСУП решает такую проблему: вам, как линейному руководителю на доске будет видна планируемая загрузка аналитиков, исходя из 90-100% вероятных входящих проектов на полгода, будет виден перегруз и все что вам нужно.
Далее у вас будет (уже есть) фактическая утилизация. А далее вы будете более точно стучать по рукам вашим нерадивым РП, которые всегда бронируют больше, а списывают меньше, а вы за утилизацию отвечай ))
Я осилил. Во-первых, любопытно сделали и это точно лучше, чем отсутствие планирования.
у меня вопросы к автору
Почему ресурсы РП сразу не бронируют в ИСУП, а вы оперируете словом "заявки"? Стандартное управление ресурсами, когда есть пул ресурсов и менеджер планирует из этого пула. Если есть ограничения, там же можно их вводить (но лучше не надо) точно так же, при бронировании ресурсов на входящие проекты, РП столкнутся с тем, что ресурсов нет и придут к вам, как Руководителю аналитиков с запросом. Придут заранее, так как проекты и ресурсы к ним планируются заранее. Вопрос: у вас нет ИСУП? или есть, но там нет ресурсов? Совет: попробуйте, должно стать проще (ну или напишите, почему нет, интересно)
Как вы оцениваете освоение ресурса, если аллоцирование только в заявке? Или все таки данные есть в ИСУП? если нет, есть ощущение, что вы сами себя заставляете страдать: если сделать так, как в п1, все станет сильно проще: есть план от РП с запросом ресурсов (например 2 мес, на 100% 1FTE), его фиксируем в ИСУП. Далее берем списания из трекера по этому проекту (круто, что они у вас есть) и сравниваем, получая вашу аналитику. Проще же? или нет?
"пришли к выводу что нужен прогноз ресурсов". Прогноз на 3 мес - просто необходимость, иначе HR просто не успеет найти. 6 мес - должно быть просто стандартом отрасли. Я тут прямо категоричен. Если у вас нет такого пайплайна - пинайте своих РП или правьте процессы компании (может быть что проекты то есть просто до вас долетают поздно, что неправильно
Мысль немного вбок: как и сдаваемая посуточно в аренду квартира в среднем занята до 80-85%, так и ресурсы больше чем на 85% занять не получится. Исключение - большие проекты, где аналитики фигачат фуллтайм на год. Все равно будут разрывы. И кстати. надо отличать коммерческую утилизацию (та, что приносит деньги компании) от некоммерческой.
В целом все. но основное - где ваша корпоративная ИСУП? Если она есть, вы просто план берете оттуда, факт из трекера и крутите любые сравнения.
А если надо поглядеть, какие аналитики по каким проектам работают - в джире есть дашборды для этого.
осуждаю ведение проектных планов в миро, коллеги. это прямо ужасная практика: неясно кто поменял, как поменял. Нет версионирования и если ктото удалит - будет беда печаль.
неясно как фиксировать отставания и тд и тп.
для всего этого придуманы системы управления проектами, куда вы занисите ваши стримы и фичи, связываете и ведете. Да, они стоят денег, но условный онлан тул типа юджайла или ганттпро или аналогов (их куча) решит все вышеуказанные проблемы.
А так выглядит как косяк проектного управления (не ваш, для вас это данность), но РПО надо задуматься.
в карму плюс за смелость, минус за статью, потому что не согласен с изложенным.
Если вы менеджер, у которого есть время на изучение программирования - вы недозагруженный менеджер. Лиду аналитиков еще можно играться в скрипты, питоны и сиквели, а вот менеджер должен учиться делегировать.
тотже трекер (нормальный) имеет открытое апи, изучить которое можно поручить разработчику (4 часа), потом понять , какие данные нужны вашему PMO (8 часов с учетом кофе и обеда и , к примеру, нескольких дашбордов), поставить задачку на создание дашбордов на основании данных (пара дней, но зависит от требований к отчетам и фронту).
И это я говорю, как руководитель ПМО, который такие задачи и ставил. Но я не шарю в питоне и в sql ничего кроме select * from all не знаю :) и мне оно и не надо. Фокус на другом у менеджера должен быть.
Ощущение, что вы основываетесь на своей личной ситуации, делая из нее далекоидущие выводы. По моему опыту (а это 25 лет в айтишке), есть люди, которые не хотят расти не потому что БОЯТСЯ отвественности, а потому что совершенно осознанно сохраняются тот самый work|life balance на который многие менеджеры забивают ради карьеры.
Знаю одного отличного девопса, например, который получает денег больше, чем его РП и совсем не торопится в менеджеры. А зачем? Денег столько же, ответственности больше, еще и пинать начнут, а тут ты - эксперт.
И это совершенно не про нарушение правил компании и прочие оправдания неисполнению своих обязательств. Просто вы встретили на работе бездельника, который успешно прикрывается опытом работы. Но это частный случай.
единственное - вот эти формальные 1:1 отдельно не нужно проводить. Если знаешь, что сотрудник перфекционист (а хороший РП знает свою команду), достаточно постучасться в мессенджер, спросить как дела и созвониться на 5 минут.
вот тебе и статус узнал, и пинганул и взбодрил, и рамку задал и 1:1 провел. И не чайка ни разу - позвонил узнать как дела/помочь, а не просто крякать.
Сам факт наблюдения меняет работу людей. В творческих областях это приводит к худшему. Почти невозможно работать творчески, если приходится оправдывать свою работу на ежедневной основе.
в творческих - да. Но постановка задач и программирование по постановке - пусть и творческая, но регулярная задача, которая может быть оценена. 20 лет наблюдаю за холиварами программистов, которые хотят, чтобы их принимали исключительно за творцов, неограниченных рамками "а вы, манагеры, идите и решается свои вопросы отдельно"
Но так не получится тоже: манагеры программистам деньги платят и продают сделанное. Пока механизм не работает , как единое целое - будут вот такие детские жалобы на жизнь, как эта статья. А ничем, кроме как жалобой, даже называть не хочется: автор просто перечислали недостатки всех подходов, ничего не предложил и ушел в туман.
Я уже выше написал, тут кратко сформулирую еще раз.
ИТ производство - НЕ завод и вы сами это доказали своей статьей. На данном этапе развития технологий оценки задач могут быть только примерными. И это - принципиальное отличие
Тем не менее, подход применим с оговорками (лучше так, чем никак)
Оценивать точно также можно в часах, избегая дорогостоящей истории с покером планирования.
А еще лучше ориентироваться на списанное время. Да я в курсе критики списаний, но вы же сами сказали, что везде должен быть разумный подход. Если не драть команду за задержки, списания - отличный инструмент, а вы получаете планфактный анализ.
В целом, радует, что люди стараются считать себест. В больших конторах эффективные менеджеры считают по утилизации из таймшитов (а она там всегда 100%, как вы понимаете)
да ладно: 5% не отменяют 95%.
Кросскультурным особенностям можно посвятить отдельную статью (верно, я работаю в американо-российской системе ценностей менеджмента и в азии не прокатит), но
сколько у нас (= читающих данную статью) компаний и менеджеров, которые работают с Азией? не более 5%
у меня просто нет опыта в этом дальше Казахстана
ну и кстати, опыть Тинькова. развивающего Plata показывает, что культурные особенности можно сглаживать, если цель интересная.
Если уж вы предлагаете раскрыть карты - расскажите для начала, какое это имеет отношение к разговору о коммуникации и делегировании?
Мне просто любопытно.
Это без агрессии, просто я,
а) когда открываю карты, всегда готов пояснить что и зачем первым.
б) не считаю возраст определяющим фактором для руководителя (только если ему не 25, там другой механизм).
Любой руководитель с определенного уровня должен принимать решения быстро, делегируя часть ответственности своим сотрудникам-менеджерам.
Не будет ответственной команды под таким менеджером среднего звена - он всегда (да, категорично) будет по уши в операционке. Потому что не умеет делегировать.
Я категоричен не просто так: у меня опыта в айти больше 25 лет , из которых 20 - управленческий, и я много общался с СЕО и другими менеджерами. Везде одно и тоже: если не учить своих РП разбираться самостоятельно (да, через боль и их ошибки) - они не научатся, сколько не разжевывай.
Больше того, сами ребята менеджеры мне много раз признавались, что так было им больнее, но намного эффективнее. Пока начальник - папка, можно прятаться за его спиной бесконечно.
когда речь про исполнителей - разговор один.
если речь про менеджеров, то, независимо от возраста, менеджер должен уметь говорить кратко, по существу и выделяя самое главное.
Не умеет - должен учиться.
На практике сам проверил: пока решаешь задачи за менеджеров, объясняешь им все по 10 раз - они не учатся. Учить это 1-2 раза объяснить а дальше спрашивать результат. А реально крутого даже учить особо не надо - сам потыкается и найдет самые эффективные пути (но таких очень мало)
Удивительно мало комментариев, статья то хорошая. Ясно что ребята себя продвигают, ну и ничего страшного.
По трендам наблюдаю тоже самое, кроме ИИшницы. Нифига она не способна ничего заменить в проектном управлении, кроме ведения протоколов встреч.
Даже тупая работа Администратора проектов по сведению таймшитов из джиры не автоматизируется через ИИ, там просто правильно надо выстроить процесс и убрать администратора, как факт.
Облака, фокус на людей (привет комментатору выше) и data driven управление - это то что нас ждет.
хороший пример непроработанной для начальника эскаляции) вы скажете "нет бюджета, иди еще думай" - и пошлете менеджера подумать еще раз, не тратя кучу времени на выслушивание обоснования. Что и есть экономия вашего (и его) времени.
В следующий раз он придет с другими вариантами, которые вам подойдут лучше, но начнет не с прелюдии а с того, о чем я писал отдельно: "есть проблема, есть такие то варианты решения, прошу вас выбрать".
Суть подхода не в правильной формулировки цели - про это есть отдельная статья (кстати, надо добавить ссылку). Суть в том, чтобы сразу сказать цель, чтобы собеседник выбрал сам: слушать дальше или нет.
Вы на своем примере тезис подтвердили )
Прикольно, спасибо. То есть каитен можно +- использовать в роли трекера.
Есть только большие вопросы к донастройке в нем рабочих правил вида:
на одном разработчике не должно быть более 2х задач в работе одновременно
счетчики возвратов (для расчета эффективности разработки)
и тп. Так как это проприетарный софт, наверняка невозможно, тогда как JIRA & Yt это позволяют.
Ну и без Гантта и ресурсов - это только у вас часть работы.
И да - контроль узких мест, контроль метрик. Короче, путь хороший, вы прошли где то процентов 30 :)
Одобряю в той части, где про выделение критичного для заказчика и максимального встраивания в существующие процессы.
В статье мало данных по примеру: реально сказано только о добавлении одного шага в процесс обновления базы знаний. И это серьезно все? Если так, зачем про это сказано, если не так, то где же детали (
В частности, очень хорошее начало про РП, которые там уже 15 лет EPR внедряют с помощью Экселя и такой то матери. И как именно вы их уговорили переехать на ИСУП? или не уговорили? Ведь главный их аргумент - "вы не ускорите, а замедлите нам работу, дорого СЕО, имей ввиду, что теперь я буду тратить времени больше на соблюдение этих глупых правил" не так то просто побить )
да, тут может быть прикольно, тем более, что можно чат гпт подогнать в помощь)
Мне мои менеджеры в полном составе говорят "спасибо" за развитие. Я даже менторингом занялся из-за этого.
Я наверное сходу резковато сказал, так иногда словами выглядит. Реально я категорически ЗА развитие любого человека в рамках организации. Сам писал про это: взаимное развитие возможно только при совпадении целей организации и сотрудника (тут можно сделать ремарку, что далеко не все сотрудники осознаны, чтобы понимать свои цели на 1-3-5 лет, но фиг с ним).
Но есть нюанс. У меня правда много опыта, я очень много где работал и сам в роли РП и я знаю, какие навыки РП нужны, а какие нет. И для меня, как представителя компании, и для моих РП, которые хотят и готовы расти профессионально, важно развивать то, что нужно чаще. А это софтскиллы: умение работать с заказчиками и капризным бизнесом, умение работать в потоке задач, делегирование и прочие веселости.
И вот этому я учу своих на практике. А заодно учу ценить себя, выпихиваю в отпуск, чтобы не выгорели (потому что нафиг оно мне надо - искать хорошего РП с рынка долго и дорого) и так далее.
В этом списке есть навык РП быть аналитиком и разбираться в технике ровно настолько, чтобы иногда взять на себя отвествтенность за какое-то решение, предложенное командой (или хотябы просто понять изменения и уметь пояснить заказчикам при необходимости).
Но нет навыка разработки, так как все кейсы, когда это было надо (и приведенный выше вами) решался на уровне описания требований и постановки тикета разработчику.
Так-то, разумеется, веселится каждый так, как хочет. Я вот знаю CDTO очень большой компании, который на досуге балуется Питончиком, чтобы чувствовать себя "в строю" :)
Но к его работе отношения это, конечно, не имеет. Когда ему необходимы серьезные дашборды (а у него 10 тыс человек в организации), он зовет свое аналитическое управление, а то управление зовет подрядчиков, чтобы те подогнали данные для отчетности. То есть в реале оно вот так.
ладно, если вам так нормально то и нормально, не буду брюзжать))
ага, все понял, да.
по пункту 2 вам помучаю еще:
что такое освоение ресурса?
а) Это планируемая загрузка
б) это фактическая загрузка
в) это планфактный анализ
судя по описанию и вашему ответу, б) у вас есть, это ясно. но а) у вас пока что нет, а точнее, вы выковыриваете его из заявок, что , скорее всего, боль и место для оцифровки.
собственно это то о чем я говорил в п 1 выше: обычное ресурсное планирование в ИСУП решает такую проблему: вам, как линейному руководителю на доске будет видна планируемая загрузка аналитиков, исходя из 90-100% вероятных входящих проектов на полгода, будет виден перегруз и все что вам нужно.
Далее у вас будет (уже есть) фактическая утилизация. А далее вы будете более точно стучать по рукам вашим нерадивым РП, которые всегда бронируют больше, а списывают меньше, а вы за утилизацию отвечай ))
речь идет о навыке, необходимом для работы менеджера. программирование - не нужно :)
Я осилил. Во-первых, любопытно сделали и это точно лучше, чем отсутствие планирования.
у меня вопросы к автору
Почему ресурсы РП сразу не бронируют в ИСУП, а вы оперируете словом "заявки"? Стандартное управление ресурсами, когда есть пул ресурсов и менеджер планирует из этого пула. Если есть ограничения, там же можно их вводить (но лучше не надо)
точно так же, при бронировании ресурсов на входящие проекты, РП столкнутся с тем, что ресурсов нет и придут к вам, как Руководителю аналитиков с запросом. Придут заранее, так как проекты и ресурсы к ним планируются заранее.
Вопрос: у вас нет ИСУП? или есть, но там нет ресурсов?
Совет: попробуйте, должно стать проще (ну или напишите, почему нет, интересно)
Как вы оцениваете освоение ресурса, если аллоцирование только в заявке? Или все таки данные есть в ИСУП? если нет, есть ощущение, что вы сами себя заставляете страдать: если сделать так, как в п1, все станет сильно проще: есть план от РП с запросом ресурсов (например 2 мес, на 100% 1FTE), его фиксируем в ИСУП.
Далее берем списания из трекера по этому проекту (круто, что они у вас есть) и сравниваем, получая вашу аналитику. Проще же? или нет?
"пришли к выводу что нужен прогноз ресурсов". Прогноз на 3 мес - просто необходимость, иначе HR просто не успеет найти. 6 мес - должно быть просто стандартом отрасли. Я тут прямо категоричен. Если у вас нет такого пайплайна - пинайте своих РП или правьте процессы компании (может быть что проекты то есть просто до вас долетают поздно, что неправильно
Мысль немного вбок: как и сдаваемая посуточно в аренду квартира в среднем занята до 80-85%, так и ресурсы больше чем на 85% занять не получится. Исключение - большие проекты, где аналитики фигачат фуллтайм на год. Все равно будут разрывы. И кстати. надо отличать коммерческую утилизацию (та, что приносит деньги компании) от некоммерческой.
В целом все. но основное - где ваша корпоративная ИСУП? Если она есть, вы просто план берете оттуда, факт из трекера и крутите любые сравнения.
А если надо поглядеть, какие аналитики по каким проектам работают - в джире есть дашборды для этого.
осуждаю ведение проектных планов в миро, коллеги. это прямо ужасная практика: неясно кто поменял, как поменял. Нет версионирования и если ктото удалит - будет беда печаль.
неясно как фиксировать отставания и тд и тп.
для всего этого придуманы системы управления проектами, куда вы занисите ваши стримы и фичи, связываете и ведете. Да, они стоят денег, но условный онлан тул типа юджайла или ганттпро или аналогов (их куча) решит все вышеуказанные проблемы.
А так выглядит как косяк проектного управления (не ваш, для вас это данность), но РПО надо задуматься.
Ну или расскажите, почему МИРО, а не ИСУП?
в карму плюс за смелость, минус за статью, потому что не согласен с изложенным.
Если вы менеджер, у которого есть время на изучение программирования - вы недозагруженный менеджер. Лиду аналитиков еще можно играться в скрипты, питоны и сиквели, а вот менеджер должен учиться делегировать.
тотже трекер (нормальный) имеет открытое апи, изучить которое можно поручить разработчику (4 часа), потом понять , какие данные нужны вашему PMO (8 часов с учетом кофе и обеда и , к примеру, нескольких дашбордов), поставить задачку на создание дашбордов на основании данных (пара дней, но зависит от требований к отчетам и фронту).
И это я говорю, как руководитель ПМО, который такие задачи и ставил. Но я не шарю в питоне и в sql ничего кроме select * from all не знаю :) и мне оно и не надо. Фокус на другом у менеджера должен быть.
Ощущение, что вы основываетесь на своей личной ситуации, делая из нее далекоидущие выводы. По моему опыту (а это 25 лет в айтишке), есть люди, которые не хотят расти не потому что БОЯТСЯ отвественности, а потому что совершенно осознанно сохраняются тот самый work|life balance на который многие менеджеры забивают ради карьеры.
Знаю одного отличного девопса, например, который получает денег больше, чем его РП и совсем не торопится в менеджеры. А зачем? Денег столько же, ответственности больше, еще и пинать начнут, а тут ты - эксперт.
И это совершенно не про нарушение правил компании и прочие оправдания неисполнению своих обязательств. Просто вы встретили на работе бездельника, который успешно прикрывается опытом работы. Но это частный случай.
хорошая, понятная и простая статья.
единственное - вот эти формальные 1:1 отдельно не нужно проводить. Если знаешь, что сотрудник перфекционист (а хороший РП знает свою команду), достаточно постучасться в мессенджер, спросить как дела и созвониться на 5 минут.
вот тебе и статус узнал, и пинганул и взбодрил, и рамку задал и 1:1 провел. И не чайка ни разу - позвонил узнать как дела/помочь, а не просто крякать.
Сам факт наблюдения меняет работу людей. В творческих областях это приводит к худшему. Почти невозможно работать творчески, если приходится оправдывать свою работу на ежедневной основе.
в творческих - да. Но постановка задач и программирование по постановке - пусть и творческая, но регулярная задача, которая может быть оценена. 20 лет наблюдаю за холиварами программистов, которые хотят, чтобы их принимали исключительно за творцов, неограниченных рамками "а вы, манагеры, идите и решается свои вопросы отдельно"
Но так не получится тоже: манагеры программистам деньги платят и продают сделанное. Пока механизм не работает , как единое целое - будут вот такие детские жалобы на жизнь, как эта статья. А ничем, кроме как жалобой, даже называть не хочется: автор просто перечислали недостатки всех подходов, ничего не предложил и ушел в туман.
молодец, чо.
Я уже выше написал, тут кратко сформулирую еще раз.
ИТ производство - НЕ завод и вы сами это доказали своей статьей. На данном этапе развития технологий оценки задач могут быть только примерными. И это - принципиальное отличие
Тем не менее, подход применим с оговорками (лучше так, чем никак)
Оценивать точно также можно в часах, избегая дорогостоящей истории с покером планирования.
А еще лучше ориентироваться на списанное время. Да я в курсе критики списаний, но вы же сами сказали, что везде должен быть разумный подход. Если не драть команду за задержки, списания - отличный инструмент, а вы получаете планфактный анализ.
В целом, радует, что люди стараются считать себест. В больших конторах эффективные менеджеры считают по утилизации из таймшитов (а она там всегда 100%, как вы понимаете)