Энерго дефицит - базовая инфраструктура на то и базовая
Защита данных от сбора - прям общая тенденция
Странные формулировки задач, которые призван решать ИИ - вы меня простите, но иногда добиться нормального описания, что хочет заказчик заставляет потратить не мало усилий, что и говорить про применении ИИ
Уровень ЗП руководителям проекта не растет уже 4 года;
Потолок ЗП по управлению портфелем проекта так же очень грустный
Профессионалы остались, просто сменили роль в командах (управляют изменениям, настраивают производственный конвейер, занимаются , прости господи, цифровой трансформацией, кто то ещё чем либо)
Поймите, тяжело управлять людьми ЗП которых в разы выше, а организационные навыки не очень выражены. Я не против больших зарплат (очень даже за) специалистам и экспертам, я за то, что ЗП должны соответствовать результатам
И не могу не упомянуть специалистов по Agile, эти знаю все:
Scrum
Kanban
Lean - это отдельное большое направление, для примера Научная организация труда входит в lean;)
6 sigma
ТОС
TPS
ТРИЗ
Но если уточнить, что они под этим понимают и как использовать данный инструментарий для реализации проекта в срок, с заданными параметрами качества, вас может ожидать разочарование
Можно предположить что каждый Task - это Story (для тех кто любит и умеет в трекер задач)
Помимо ролей, можно указывать системы (да, да, так вы поймете в какой системе что делается, task можно указывать со значком "+" если она в рамках одной системы - потом на отдельной диаграмме уточните)
Если указывать системы и Task с "+" то каждая линия - это интеграция(! очень удобно)
И поняв верхний уровень, уже расписывать каждый Task с "+" отдельно (получиться набор use case)
Результат проверяйте всегда на коллегах:) Помните, если диаграмма сделана хорошо, она будет понятна любому психически здоровому человеку;)
Не соглашусь с видением автора, заказчик в большинстве понимает и знает зачем ему система
К сожалению, не все могут задать простые вопросы:
Какая цель?
Что вы хотите получить от реализации?
Возможно мне везло, и я встречался с компетентными заказчиками, мой опыт подсказывает, подготовка к первой встрече (изучение предметки или углубление в предметную область) очень помогает понять цель заказчика
Сейчас есть телеграмм и прочие штуки (есть на Хабре статья, как спец службы сделали мессенджер и продали по подписке хулиганам, писали всё:))) конечно их закрыли. )
Контролировать некую область желание нормальное, помимо минусов есть и плюсы
Меня если честно куча звонков со странными предложениями уже утомила;)
С точки зрения переключения с основной деятельности на другую, да интересно
А просто ради постов тут пусть решает дорогая редакция
Если статья касается некой бизнес части инженерных решений - это было бы супер, но писать науч поп с ссылкой на инженерную статью очень серьезный труд
Я пользуюсь e-library когда есть потребность в чем либо разобраться или посмотреть критику, возможно науч поп помогает, но проф перекос толкает на спец источники информации:)
давать задачи постепенно и не оставлять один на один с задачей
хвалить за результаты
объяснять откуда задача и её смысл (даст мотивацию Джуну расти)
качественно ревьють его работу с пояснениями
если необходимо, не лениться и писать небольшие инструкции
Профит будет не только для Джуна (вы удивитесь, но при написании небольших инструкций многое откроется с другой стороны)
И согласен с комментариями выше, за наставничество необходимо платить и платить хорошо. По факту от наставника зависит не только плавность входа и скорость начала получения пользы, но и в целом бренд работодателя (часто слышу от коллег, что ушёл из известной компании, так как перестали ценить людей)
Всё это похоже на некий мозговой штурм, очень много статей вышло про эту тему (и не только на хабре)
Накину немного своего взгляда
Необходимо разделять оценку задач по степеням готовности
Согласен с автором что потребность в оценке может исходить от ТОП менеджмента
Дополню автора, от конкретного разработчика она так же может исходить (хороший специалист ценит своё время, и даёт некую оценку, а очень хороший специалист в неё укладывается - важно понимать, что он закладывает время размышлений и поиска решения, даже если решение ему известно)
Предложу так же разграничить уровень оценки по этапам жизненного цикла конкретного проекта/продукта:
Обсуждение идеи - одна оценка (цель останется, но вот подход может измениться)
Первичная проработка архитектуры - другая оценка (определяет границы, но содержание может меняться)
Декомпозиция по итерациям - третья оценка (определяется набор функций, но и он может меняться)
Согласование условий оплаты и сроков - четвертая оценка (хочешь быстро и качественно плати много)
Есть жизненный цикл разработки, там свои этапы и способы оценки
Есть жизненный цикл поддержки со своей спецификой
Задача на самом деле комплексная и многогранная, для себя давно решил, что лучший способ - это адаптация под правила компании с применением здравого смысла, участники процесса должны понимать откуда взялась та или иная оценка и иметь возможность на неё повлиять, при условии понятного обоснования
Эффективное планирование начинается с вышестоящего руководства, если у них отсутствуют годовые и более планы (по выручке, привлечению клиентов и т.д.) планирование на 1-3 месяца провалится:)
Научить на основе психологии и других "оккультных" практик человека верно прогнозировать наверное можно, но сколько адекватных менеджеров разбежится в момент обучения, вопрос открытый
Есть масса фреймворков, в которых методы планирования хоть и спорны на мой взгляд, но позволяют решать задачи планирования и прогноза
Любое решение - это риск, т.к. риск - это вероятность наступления положительного/отрицательного эффекта от решения:)
Система планирования, завязанная на общие планы руководства (смотри п.1) всегда эффективна, но сильно зависит от владельца процесса (по идее владельцем необходимо быть руководителю портфеля или проектного офиса)
Если добавить стоимость планирования и стоимость отсутствия планирования, то ваш подход можно будет проанализировать, уверен получиться интересная статья
В сложившийся системах есть вполне себе понятные метрики производительности, будем честны, большая часть задач довольно однообразно, меняется в основном бизнес контекст (иначе откуда столько low-code платформ)
Для реализации прозрачной системы прогнозирования и системы планирования (я бы их всё же разделил) достаточно выбрать понятные по всему жизненному циклу метрики, которые можно будет применять не только для планирования и прогноза, но и для следующих активностей:
Тут же момент самый интересный в том, что для рутинных задач самое оно, пусть модели учатся (какой будет срач в научной среде, когда 2 и более противоположные позиции будут обсуждаться чатами:))))
При таком подходе важно будет другая задача, задача умения мыслить, она интереснее, и открывает мир с других сторон
Тут развитию мешают ещё несколько факторов:
Энерго дефицит - базовая инфраструктура на то и базовая
Защита данных от сбора - прям общая тенденция
Странные формулировки задач, которые призван решать ИИ - вы меня простите, но иногда добиться нормального описания, что хочет заказчик заставляет потратить не мало усилий, что и говорить про применении ИИ
Отлично!
Прошу рассмотреть корректировку заголовка: Как добиться максимальной концентрации на работе.
Текущий заголовок режет глаз:(
Странный трэк
Из разнообразия проектов и команд
Уходить в операционное управление, самое рутинное дело;)
Я так понял это антиреклама работы на буржуя;)))
Дорогой автор, всё намного проще
Уровень ЗП руководителям проекта не растет уже 4 года;
Потолок ЗП по управлению портфелем проекта так же очень грустный
Профессионалы остались, просто сменили роль в командах (управляют изменениям, настраивают производственный конвейер, занимаются , прости господи, цифровой трансформацией, кто то ещё чем либо)
Поймите, тяжело управлять людьми ЗП которых в разы выше, а организационные навыки не очень выражены. Я не против больших зарплат (очень даже за) специалистам и экспертам, я за то, что ЗП должны соответствовать результатам
И не могу не упомянуть специалистов по Agile, эти знаю все:
Scrum
Kanban
Lean - это отдельное большое направление, для примера Научная организация труда входит в lean;)
6 sigma
ТОС
TPS
ТРИЗ
Но если уточнить, что они под этим понимают и как использовать данный инструментарий для реализации проекта в срок, с заданными параметрами качества, вас может ожидать разочарование
Специалисты есть
Я бы добавил к описанию:
Можно предположить что каждый Task - это Story (для тех кто любит и умеет в трекер задач)
Помимо ролей, можно указывать системы (да, да, так вы поймете в какой системе что делается, task можно указывать со значком "+" если она в рамках одной системы - потом на отдельной диаграмме уточните)
Если указывать системы и Task с "+" то каждая линия - это интеграция(! очень удобно)
И поняв верхний уровень, уже расписывать каждый Task с "+" отдельно (получиться набор use case)
Результат проверяйте всегда на коллегах:) Помните, если диаграмма сделана хорошо, она будет понятна любому психически здоровому человеку;)
Всех нас иногда обманывают, держись товарищ
Нормально всё у нас:)
Я в юном возрасте палкой крапиву бил;)
Участвовал в построении сети между домами через кабеля;)
Гордился рейтингом на торренте;)
Собесов не боюсь, отношусь к ним как к необходимому этапу для понимания: сможем ли мы вместе решать задачи
Не соглашусь с видением автора, заказчик в большинстве понимает и знает зачем ему система
К сожалению, не все могут задать простые вопросы:
Какая цель?
Что вы хотите получить от реализации?
Возможно мне везло, и я встречался с компетентными заказчиками, мой опыт подсказывает, подготовка к первой встрече (изучение предметки или углубление в предметную область) очень помогает понять цель заказчика
Конечно ИМХО
Это очень необычно
Сейчас есть телеграмм и прочие штуки (есть на Хабре статья, как спец службы сделали мессенджер и продали по подписке хулиганам, писали всё:))) конечно их закрыли. )
Контролировать некую область желание нормальное, помимо минусов есть и плюсы
Меня если честно куча звонков со странными предложениями уже утомила;)
Идея идёт от задачи, актуальной задачи
Просто идея ничего не даст;)
С точки зрения переключения с основной деятельности на другую, да интересно
А просто ради постов тут пусть решает дорогая редакция
Если статья касается некой бизнес части инженерных решений - это было бы супер, но писать науч поп с ссылкой на инженерную статью очень серьезный труд
Я пользуюсь e-library когда есть потребность в чем либо разобраться или посмотреть критику, возможно науч поп помогает, но проф перекос толкает на спец источники информации:)
Всё верно, если тема цепляет то отклик будет
Если всё разжевать, то отклик получит дополнительно не релевантную выборку
Отличная статья!
Странно что подобный комментарий я увидел только в конце
Лично мне конструкции было легче и быстрее сделать в Компасе;)
И не сомневаюсь что PLM Компас ничем не хуже
Конечно предстоит рефакторинг конструкторской и технологической документации, но не думаю что это будет длиться вечность;)
Способ очень простой
давать задачи постепенно и не оставлять один на один с задачей
хвалить за результаты
объяснять откуда задача и её смысл (даст мотивацию Джуну расти)
качественно ревьють его работу с пояснениями
если необходимо, не лениться и писать небольшие инструкции
Профит будет не только для Джуна (вы удивитесь, но при написании небольших инструкций многое откроется с другой стороны)
И согласен с комментариями выше, за наставничество необходимо платить и платить хорошо. По факту от наставника зависит не только плавность входа и скорость начала получения пользы, но и в целом бренд работодателя (часто слышу от коллег, что ушёл из известной компании, так как перестали ценить людей)
Всё это похоже на некий мозговой штурм, очень много статей вышло про эту тему (и не только на хабре)
Накину немного своего взгляда
Необходимо разделять оценку задач по степеням готовности
Согласен с автором что потребность в оценке может исходить от ТОП менеджмента
Дополню автора, от конкретного разработчика она так же может исходить (хороший специалист ценит своё время, и даёт некую оценку, а очень хороший специалист в неё укладывается - важно понимать, что он закладывает время размышлений и поиска решения, даже если решение ему известно)
Предложу так же разграничить уровень оценки по этапам жизненного цикла конкретного проекта/продукта:
Обсуждение идеи - одна оценка (цель останется, но вот подход может измениться)
Первичная проработка архитектуры - другая оценка (определяет границы, но содержание может меняться)
Декомпозиция по итерациям - третья оценка (определяется набор функций, но и он может меняться)
Согласование условий оплаты и сроков - четвертая оценка (хочешь быстро и качественно плати много)
Есть жизненный цикл разработки, там свои этапы и способы оценки
Есть жизненный цикл поддержки со своей спецификой
Задача на самом деле комплексная и многогранная, для себя давно решил, что лучший способ - это адаптация под правила компании с применением здравого смысла, участники процесса должны понимать откуда взялась та или иная оценка и иметь возможность на неё повлиять, при условии понятного обоснования
Не соглашусь с подходом:
Эффективное планирование начинается с вышестоящего руководства, если у них отсутствуют годовые и более планы (по выручке, привлечению клиентов и т.д.) планирование на 1-3 месяца провалится:)
Научить на основе психологии и других "оккультных" практик человека верно прогнозировать наверное можно, но сколько адекватных менеджеров разбежится в момент обучения, вопрос открытый
Есть масса фреймворков, в которых методы планирования хоть и спорны на мой взгляд, но позволяют решать задачи планирования и прогноза
Любое решение - это риск, т.к. риск - это вероятность наступления положительного/отрицательного эффекта от решения:)
Система планирования, завязанная на общие планы руководства (смотри п.1) всегда эффективна, но сильно зависит от владельца процесса (по идее владельцем необходимо быть руководителю портфеля или проектного офиса)
Если добавить стоимость планирования и стоимость отсутствия планирования, то ваш подход можно будет проанализировать, уверен получиться интересная статья
В сложившийся системах есть вполне себе понятные метрики производительности, будем честны, большая часть задач довольно однообразно, меняется в основном бизнес контекст (иначе откуда столько low-code платформ)
Для реализации прозрачной системы прогнозирования и системы планирования (я бы их всё же разделил) достаточно выбрать понятные по всему жизненному циклу метрики, которые можно будет применять не только для планирования и прогноза, но и для следующих активностей:
поиск специалистов
объект для применения новых технологий
объект для роста производительности
И как итог рост конкурентоспособности
Зачем?
Зачем при всеобщей гонке и конкуренции учить людей методологии:), эффективной методологии
Тут как в старом анекдоте про врачей, отец и сын
Сын приходит к отцу и говорит, я вылечил пациента, которого ты лечил 20 лет
Отец отвечает: Он нас кормил
Но самое интересное большинство и учится не хочет:) Можно же просто выучить слова, повторять их и иметь профит
А зачем?
Тут же момент самый интересный в том, что для рутинных задач самое оно, пусть модели учатся (какой будет срач в научной среде, когда 2 и более противоположные позиции будут обсуждаться чатами:))))
При таком подходе важно будет другая задача, задача умения мыслить, она интереснее, и открывает мир с других сторон