Статья действительно очень годная. От себя хочу добавить ещё одно наблюдение.
Не редки ситуации, когда руководитель менеджера сам толкает его на путь "спасателя", и не редко , в директивном стиле. Например: "людей мало, возьми часть задач на себя", "будь играющим тренером" и тому подобное. На крупных проектах одна взятая из пула исполнительская задача часто обходится дорого для всего проекта. Но такие кейсы характерны для одиночных проектов. Не характерны для полноценных портфелей (и хорошо).
Опять же, отрасли , проекты, задачи очень рознятся. И в ряде случаев, решение менеджера взять на себя часть работы вполне оправдано. Но тут важно отметить что оно должно быть взвешанным, объективно обоснованным и принятым не в угоду внешнему давлению или проявлением своего эго. А например, можно временно закрыть брешь в компетенциях собой, если текущая ситуация с проектами такова , что менеджер может под это выделить собственный ресурс без вреда для своих профильных задач и никто в сроки гарантированно задачу не выполнит. Но это "хождение по тонкому льду", не должно войти в обычай, и в перспективе, бреши надо закрывать не собой (повышение квалификации команды через обучение или найм). Наверное так.
При всем уважении, пункт 2 это как раз моя специализация. С 2005 года этим занимаюсь. Возможно, нюансы раскроются в деталях , но в общих чертах - это всё же классика.
Вообще, изложены прописные истины, кто-то посчитает публикацией ради публикации, кто-то увидит тут творчество ИИ, копипаст, кто-то (такое тоже может быть) прочитает и не согласится.
Я вот, прочитал и настроение улучшилось. Вроде как нового ничего не узнал, но! Последнее время читаю статьи про руководителей , в которых описываются совсем иные функции.
Есть функции, которые навязаны руководителю, есть и обратная сторона, когда руководитель меняет их состав чтобы облегчить себе жизнь.
Версий уже настолько много, что пора уже делать "прививки" - постить прописные истины периодически.
Опять про токсиков. Я вот не увидел пользы в статье, уж простите, такие промпты как в примерах пишутся просто интуитивно, на базе минимальных познаний в LLM.
То что статью надо расширять - это точно. Вообще, по хорошему, предварительно ИИ надо обучить. Вот тут можно рассмотреть подходы, модели обучения, конкретные варианты реализации.
С чем я в корне не согласен, так это с красными и зелеными полосками. Не может ИИ провести грамотный анализ и выдать прототип, это бред и фантастика. ИИ можно использовать в процессах как помощника (кстати , именно в задачах из противоположного столбика ИИ будет даже более адекватнее).
Тут посыл - пусть РП витает в облаках, подальше от технической реализации, а за академическую техническую составляющую будет отвечать ИИ. Ну красота, что сказать!
Писать формальные , никому не нужные доки - я сам поручаю ИИ, это разумно. Собрать и структурировать инфу из множества слабо связанных кривых документов - тоже ИИ. Вообще как инструмент ведения локальной базы знаний в части автоматизации контекстного поиска ИИ незаменим, что бы я без него делал, вспоминаю как было раньше и в дрожь бросает.
А ещё я смеюсь с того что к рутинным задачам отнесли прототипирование, анализ и т.п.
А что, чем больше сделаем для галочки, тем больше задач впереди, засаживай в ИИ и повышай производительность (в ущерб качеству... но так тайм ту прод так ничего зато, а там разберутся, ещё задачек поставят, так мы их на анализ и в прототип через LLM )
1 - реклама. Как лечить: наделать чаты в красивой цветной борде под каждую задачу, чтобы уж наверняка от тоски откиснуть. А то в jira это не совсем чаты , в trello тоже. Пусть меня по каждой из 100 500+ задач лога смогут достать )))
2, 3 - не лечится. Как лечить: увольняться нафиг, можно ещё прокрастинировать (кто умеет).
4, 5 - вообще не проблема а фича, удобная всем (кто действительно работает) так как действует в обе стороны. Если действует только в одну сторону - лечить как 2 и 3.
6, 7 - кто может - игнорировать, кто не может - лечить как 2 и 3.
Вообще, 10 а не 7 грехов это потому что их 110, автор поскромничал.
Так то , наверное тут очепятка , не "смертный грех" а , скорее , "смех и грех".
Вообще я проголосовал за замену HR живых на ИИ, но только в ИТ. В массовом сегменте найма не знаю, не берусь судить, но в ИТ зачастую таких набирают... Сколько уже в ИТ работаю, усянил для себя 2 факта:
хочешь набрать эффективную команду на сложный проект - набирай сам;
если вышестоящий руководитель нашел тебе начальника через HR, а не самостоятельно, скорее всего, лучше беги !
Да простит меня великий Ктулху, в 3-ем кейсе где "я была не очень избирательна..." начальник просто яйца подкатывал к молодой стажёрке. Это вообще типичная ситуация с волосатыми тентаклями добившихся положения но теряющих цветущую молодость альфачей.
Мне понравилось. Ни со всем соглашусь (в плане личных предпочтений), но я задумался. Вкусовщина -да , но не за ради красоты мы цвета меняем. Хорошо когда цвет позволяет быстро цепляться за важное глазом. Вообще мы это и так, обычно, подчёркиваем настройкой цветов, и часто это субьективно и зависит от образа мышления, но я пару моментов для себя лично в статье отметил. Автору спасибо!
Если обозначать именно такой состав MVP, то тогда следует дораскрыть именно заголовок статьи. Ведь в своей сути, по сегменту МСБ мы имеем подавляющее число компаний (как по количеству, так и по качественным метрикам), у которых не более 2 data-колодцев. И, зачастую, даже не намеренно в них есть суррогатные индексы, уникальные, подходящие для мэтчинга всех категорий затрат с итоговой выручкой. Даже не берем digital. Просто ID партии есть, ещё выпустил такой то бригадир/начальник смены, рабочие часы работников пробиты, ФОТ есть, стоимость производства , грубо по всем видам затрат расписана до себестоимости единиц по каждой номенклатуре , по поставке данные накладных внесены , связаны с ID партии, по ID накладных идёт поставка в ритейл (далее опускаем доп. данные, которые тоже есть) , всё это выгружается в формализованном виде, остается смэтчить с отчётом от ритейлеров. По сути , вечерок, Excel+VBA (прости хоспади) или пару дней и php+MySQL, и всё, базовая аналитика и в разрезе эффективности продаж на уровне ритейлера, и по типам выкладки внутри ритейлеров, и по гео, да много почему - накидано в объёме, достаточном для длительного пользования среднестатистическим представителем сегмента МСБ. По-моему так.
Но это частенько даже слишком для нижней части МСБ сегмента. Взять, к примеру, омю троюродную тётушку, реализующую товары не собственного производства через озон и wb. Именно аналитики с площадок + excel (даже без VBA) ей более чем достаточно.
Соответственно , хорошо бы в статье с таким заманчивымтзаголовком и дать +/- понятный алгоритм, по которому владелец бизнеса (не знаем какого масштаба) поймёт , нужно ли вкладываться в аналитику и что для него MVP.
Так то , это многим сейчас нужно. А то из каждого подвала сначала слышится "у нас кризис роста, мы внедряем современные подходы" , а потом мебель и оргтехнику за долги выносят ;)
Не понял чем MVP аналитика из статьи отличается от просто аналитики. Тут ведь просто про построение воронки продаж от лида до прибыли. То есть, как будто накинул метки на лидогенерацию (для digital канала - utm, собственно как в статье) и сиди считай ROI, ROMI , чего душе угодно.
Ну да, так все и делают. А скидывать цифры в кучу, что-то на что-то делить это как бы не аналитика и не дорого. В чем тут какое-то ноу-хау? Потом заходит речь про какую-то эволюцию, которая не бьётся с вышеперечисленными тезисами (выращивание аналитика это долго, дорого и до момента его становления компания не будет иметь готовой аналитики).
Другой вопрос про стек и подход. Облако, pgsql, общеизвестные bi программы для визуализации дашиков.
Ну во-первых стек шире, значительно, есть вполне дифференцированные подходы для разного бизнеса (от размера зависит и ещё от ряда факторов).
То есть, если повторить, ничего нового я не вижу, тема MVP так вовсе не раскрыта.
К слову, в одной из известных мне маленьких компаний, так уж сложилось что помощник директора знал php и mysql поверхностно. MVP заключался в построении аналитики по принципу: данные из Excel в csv - csv в сервис на apache (громно сказано, Denver просто развернули) - оттуда выгрузка CSV и в Excel, где графики настроены. Но это они никто VBA не знал. А знал бы помощник VBA, то и промежуточные манипуляции с apache не потребовались бы. Вот это - MVP с минимальными затратами, из того что есть и соразмерно целям и ценностям.
Ближе к владельцу, но дальше от IT . Для многих it-шиков hr , к слову , за компанию с "маркетосами" - ось зла. Это так, лирика, конечно. Я в it около 20 лет и только 1 год наблюдал то, о чем Вы говорите, и хорошего там мало. Так что это, наверное к счастью, скорее исключение чем правило.
Замахиваться на Excel я бы не стал. На Google таблицы , ещё можно. Но до Excel вам со своим решением далековато (именно , до табличного процессора, коим Excel является).
Серьёзно, просто давайте набор встроенных функций смэтчим, или вот, на убой, а извольте предъявить свой VBA??? Давеча водил родственницу к психиатру , а у него там макросы накодены в полный рост, я через плечо глянул , там и формы и range обрабатывает, то есть реальный серьёзный обработчик ручками написан.
Зачем это всё. Есть бинарная логика: сделано/ не сделано.
Хотите аналитику? Хотите знать где сломалось? Самое простое - scrum. И не важно где вы будете задачи вести. Есть другие хорошие методологии.
Но важно. Задачи ставить и оценивать должен тот, кто знает как и какими ресурсами они будут выполняться. Везде критична правильно выстроенная функциональная иерархия.
Если простыми словами: руководитель должен в деталях понимать то , что делают его непосредственные подчиненные, вплоть до того, что может у себя в голове мультик нарисовать, да так, что если, например , в любой момент заглянет подчиненному через плечо, то увидит там то, что у подчиненного в мониторе / на станке / в обработке.
Во многом согласен, но сама формулировка "ничего не делает руками" сильно напрягает.
Контроль - одна из важнейших функций руководителя! Например, если в интеграционных проектах он не способен верифицировать спеку и диаграмму последовательности UML от аналитика/архитектора (нижний и средний уровень руководства) или понять отчёт QA (читать ПМИ, отчёты, это если руководитель уровнем повыше), то грошь цена такому руководителю. А это сразу говорит о неких необходимых компетенциях в части (уметь делать руками), хотя бы на верхнем или абстрактном уровне. И это легко проверить.
За одно всплывут факты по практическим кейсам, хороший руководитель не упустит возможности похвастаться своим опытом.
А можно хотя бы в заголовке ошибок не делать.
"Почему Олег Бартунов не верит Минобразования..."
Ну нельзя так писать! "Министерству образования" , никак иначе в этом падеже не напишешь.
Статья действительно очень годная. От себя хочу добавить ещё одно наблюдение.
Не редки ситуации, когда руководитель менеджера сам толкает его на путь "спасателя", и не редко , в директивном стиле. Например: "людей мало, возьми часть задач на себя", "будь играющим тренером" и тому подобное. На крупных проектах одна взятая из пула исполнительская задача часто обходится дорого для всего проекта. Но такие кейсы характерны для одиночных проектов. Не характерны для полноценных портфелей (и хорошо).
Опять же, отрасли , проекты, задачи очень рознятся. И в ряде случаев, решение менеджера взять на себя часть работы вполне оправдано. Но тут важно отметить что оно должно быть взвешанным, объективно обоснованным и принятым не в угоду внешнему давлению или проявлением своего эго. А например, можно временно закрыть брешь в компетенциях собой, если текущая ситуация с проектами такова , что менеджер может под это выделить собственный ресурс без вреда для своих профильных задач и никто в сроки гарантированно задачу не выполнит. Но это "хождение по тонкому льду", не должно войти в обычай, и в перспективе, бреши надо закрывать не собой (повышение квалификации команды через обучение или найм). Наверное так.
При всем уважении, пункт 2 это как раз моя специализация. С 2005 года этим занимаюсь. Возможно, нюансы раскроются в деталях , но в общих чертах - это всё же классика.
Да что обижаться. Дизлайкать будут всегда.
Вообще, изложены прописные истины, кто-то посчитает публикацией ради публикации, кто-то увидит тут творчество ИИ, копипаст, кто-то (такое тоже может быть) прочитает и не согласится.
Я вот, прочитал и настроение улучшилось. Вроде как нового ничего не узнал, но! Последнее время читаю статьи про руководителей , в которых описываются совсем иные функции.
Есть функции, которые навязаны руководителю, есть и обратная сторона, когда руководитель меняет их состав чтобы облегчить себе жизнь.
Версий уже настолько много, что пора уже делать "прививки" - постить прописные истины периодически.
Опять про токсиков. Я вот не увидел пользы в статье, уж простите, такие промпты как в примерах пишутся просто интуитивно, на базе минимальных познаний в LLM.
То что статью надо расширять - это точно. Вообще, по хорошему, предварительно ИИ надо обучить. Вот тут можно рассмотреть подходы, модели обучения, конкретные варианты реализации.
С чем я в корне не согласен, так это с красными и зелеными полосками. Не может ИИ провести грамотный анализ и выдать прототип, это бред и фантастика. ИИ можно использовать в процессах как помощника (кстати , именно в задачах из противоположного столбика ИИ будет даже более адекватнее).
Тут посыл - пусть РП витает в облаках, подальше от технической реализации, а за академическую техническую составляющую будет отвечать ИИ. Ну красота, что сказать!
Писать формальные , никому не нужные доки - я сам поручаю ИИ, это разумно. Собрать и структурировать инфу из множества слабо связанных кривых документов - тоже ИИ. Вообще как инструмент ведения локальной базы знаний в части автоматизации контекстного поиска ИИ незаменим, что бы я без него делал, вспоминаю как было раньше и в дрожь бросает.
Но это ни то что в статье.
Во истину!
А ещё я смеюсь с того что к рутинным задачам отнесли прототипирование, анализ и т.п.
А что, чем больше сделаем для галочки, тем больше задач впереди, засаживай в ИИ и повышай производительность (в ущерб качеству... но так тайм ту прод так ничего зато, а там разберутся, ещё задачек поставят, так мы их на анализ и в прототип через LLM )
Золотые слова!
7 привычек:
1 - реклама. Как лечить: наделать чаты в красивой цветной борде под каждую задачу, чтобы уж наверняка от тоски откиснуть. А то в jira это не совсем чаты , в trello тоже. Пусть меня по каждой из 100 500+ задач лога смогут достать )))
2, 3 - не лечится. Как лечить: увольняться нафиг, можно ещё прокрастинировать (кто умеет).
4, 5 - вообще не проблема а фича, удобная всем (кто действительно работает) так как действует в обе стороны. Если действует только в одну сторону - лечить как 2 и 3.
6, 7 - кто может - игнорировать, кто не может - лечить как 2 и 3.
Поддерживаю вопрос! Вообще, как заранее оценить вовлеченность и чем она отличается от измеримых показателей по софт скилам 🤔.
Автор не уточняет...
Вообще, 10 а не 7 грехов это потому что их 110, автор поскромничал.
Так то , наверное тут очепятка , не "смертный грех" а , скорее , "смех и грех".
Вообще я проголосовал за замену HR живых на ИИ, но только в ИТ. В массовом сегменте найма не знаю, не берусь судить, но в ИТ зачастую таких набирают... Сколько уже в ИТ работаю, усянил для себя 2 факта:
хочешь набрать эффективную команду на сложный проект - набирай сам;
если вышестоящий руководитель нашел тебе начальника через HR, а не самостоятельно, скорее всего, лучше беги !
Да простит меня великий Ктулху, в 3-ем кейсе где "я была не очень избирательна..." начальник просто яйца подкатывал к молодой стажёрке. Это вообще типичная ситуация с волосатыми тентаклями добившихся положения но теряющих цветущую молодость альфачей.
Мне понравилось. Ни со всем соглашусь (в плане личных предпочтений), но я задумался. Вкусовщина -да , но не за ради красоты мы цвета меняем. Хорошо когда цвет позволяет быстро цепляться за важное глазом. Вообще мы это и так, обычно, подчёркиваем настройкой цветов, и часто это субьективно и зависит от образа мышления, но я пару моментов для себя лично в статье отметил. Автору спасибо!
Если обозначать именно такой состав MVP, то тогда следует дораскрыть именно заголовок статьи. Ведь в своей сути, по сегменту МСБ мы имеем подавляющее число компаний (как по количеству, так и по качественным метрикам), у которых не более 2 data-колодцев. И, зачастую, даже не намеренно в них есть суррогатные индексы, уникальные, подходящие для мэтчинга всех категорий затрат с итоговой выручкой. Даже не берем digital. Просто ID партии есть, ещё выпустил такой то бригадир/начальник смены, рабочие часы работников пробиты, ФОТ есть, стоимость производства , грубо по всем видам затрат расписана до себестоимости единиц по каждой номенклатуре , по поставке данные накладных внесены , связаны с ID партии, по ID накладных идёт поставка в ритейл (далее опускаем доп. данные, которые тоже есть) , всё это выгружается в формализованном виде, остается смэтчить с отчётом от ритейлеров. По сути , вечерок, Excel+VBA (прости хоспади) или пару дней и php+MySQL, и всё, базовая аналитика и в разрезе эффективности продаж на уровне ритейлера, и по типам выкладки внутри ритейлеров, и по гео, да много почему - накидано в объёме, достаточном для длительного пользования среднестатистическим представителем сегмента МСБ. По-моему так.
Но это частенько даже слишком для нижней части МСБ сегмента. Взять, к примеру, омю троюродную тётушку, реализующую товары не собственного производства через озон и wb. Именно аналитики с площадок + excel (даже без VBA) ей более чем достаточно.
Соответственно , хорошо бы в статье с таким заманчивымтзаголовком и дать +/- понятный алгоритм, по которому владелец бизнеса (не знаем какого масштаба) поймёт , нужно ли вкладываться в аналитику и что для него MVP.
Так то , это многим сейчас нужно. А то из каждого подвала сначала слышится "у нас кризис роста, мы внедряем современные подходы" , а потом мебель и оргтехнику за долги выносят ;)
Не понял чем MVP аналитика из статьи отличается от просто аналитики. Тут ведь просто про построение воронки продаж от лида до прибыли. То есть, как будто накинул метки на лидогенерацию (для digital канала - utm, собственно как в статье) и сиди считай ROI, ROMI , чего душе угодно.
Ну да, так все и делают. А скидывать цифры в кучу, что-то на что-то делить это как бы не аналитика и не дорого. В чем тут какое-то ноу-хау? Потом заходит речь про какую-то эволюцию, которая не бьётся с вышеперечисленными тезисами (выращивание аналитика это долго, дорого и до момента его становления компания не будет иметь готовой аналитики).
Другой вопрос про стек и подход. Облако, pgsql, общеизвестные bi программы для визуализации дашиков.
Ну во-первых стек шире, значительно, есть вполне дифференцированные подходы для разного бизнеса (от размера зависит и ещё от ряда факторов).
То есть, если повторить, ничего нового я не вижу, тема MVP так вовсе не раскрыта.
К слову, в одной из известных мне маленьких компаний, так уж сложилось что помощник директора знал php и mysql поверхностно. MVP заключался в построении аналитики по принципу: данные из Excel в csv - csv в сервис на apache (громно сказано, Denver просто развернули) - оттуда выгрузка CSV и в Excel, где графики настроены. Но это они никто VBA не знал. А знал бы помощник VBA, то и промежуточные манипуляции с apache не потребовались бы. Вот это - MVP с минимальными затратами, из того что есть и соразмерно целям и ценностям.
Ближе к владельцу, но дальше от IT . Для многих it-шиков hr , к слову , за компанию с "маркетосами" - ось зла. Это так, лирика, конечно. Я в it около 20 лет и только 1 год наблюдал то, о чем Вы говорите, и хорошего там мало. Так что это, наверное к счастью, скорее исключение чем правило.
Замахиваться на Excel я бы не стал. На Google таблицы , ещё можно. Но до Excel вам со своим решением далековато (именно , до табличного процессора, коим Excel является).
Серьёзно, просто давайте набор встроенных функций смэтчим, или вот, на убой, а извольте предъявить свой VBA??? Давеча водил родственницу к психиатру , а у него там макросы накодены в полный рост, я через плечо глянул , там и формы и range обрабатывает, то есть реальный серьёзный обработчик ручками написан.
А у вас оно где???
Зачем это всё. Есть бинарная логика: сделано/ не сделано.
Хотите аналитику? Хотите знать где сломалось? Самое простое - scrum. И не важно где вы будете задачи вести. Есть другие хорошие методологии.
Но важно. Задачи ставить и оценивать должен тот, кто знает как и какими ресурсами они будут выполняться. Везде критична правильно выстроенная функциональная иерархия.
Если простыми словами: руководитель должен в деталях понимать то , что делают его непосредственные подчиненные, вплоть до того, что может у себя в голове мультик нарисовать, да так, что если, например , в любой момент заглянет подчиненному через плечо, то увидит там то, что у подчиненного в мониторе / на станке / в обработке.
Во многом согласен, но сама формулировка "ничего не делает руками" сильно напрягает.
Контроль - одна из важнейших функций руководителя! Например, если в интеграционных проектах он не способен верифицировать спеку и диаграмму последовательности UML от аналитика/архитектора (нижний и средний уровень руководства) или понять отчёт QA (читать ПМИ, отчёты, это если руководитель уровнем повыше), то грошь цена такому руководителю. А это сразу говорит о неких необходимых компетенциях в части (уметь делать руками), хотя бы на верхнем или абстрактном уровне. И это легко проверить.
За одно всплывут факты по практическим кейсам, хороший руководитель не упустит возможности похвастаться своим опытом.