Все выглядит стройно и красиво, но у меня вопрос к критериям оценки. А точнее, не к ним даже, а к тому кто оценивал и кто решал по полноте и достоверности ответа?
Тесты и правда симпатичные, но разные РП с разным опытом дадут разные оценки за один и тот же ответ: что джуну будет "превосходно", синьор воспримет как "шляпа, но сойдет", а его руководитель - как просто шляпу.
Судьи кто?
А ведь на этом построены все остальные выводы, так что вопрос выглядит критичным
Я пишу комментарии, статьи на Хабре и даже канал веду не самоутверждения ради, а обсуждения для. Другое дело, готовы ли вы привести такие факты, которые смогут поколебать мой информационный пузырь, основанный на личном опыте и внедрений и консалтинга?
А то пока что я слышал очень много красивых слов. Реальных примеров видел немного и по трудозатратам и достоверности у меня существенные вопросы.
Впрочем, допускаю, что тут может быть не только хайп. Так что рассказывайте, если время есть :)
ИИ врет. Причем красиво и убежденно, причем даже тогда, когда говоришь ему не врать. Причем в любой модификации и версии. Причем, за последние 2 года что лично я его ежедневно использую, он меньше врать не стал. Джемини врет вообще искушенно, а когда ловишь - очень мило и искренне извиняется и снова врет. Мораль: любой статус собранный ИИ - под вопросом ((
ИИ фиг пойми как оценивает критичность. Согласен, большой соблазн просто скормить джиру конфлю и трекер, попросить сделать магию и поверить в ее результат. Это просто, красиво, инновационно, и потом можно идти гонять латте в кофепойнте с коллегушками. Но даже на скрине автора меня резануло вот такое (понимаю, просто пример, может быть как угодно, но я , как руководитель, всегда сильно напрягаюсь на такое):
"в работе"?! Да я за такое по башке РП дам от души. Это классическая жопа: РП думает что все более-менее, всего на 2 дня просрочено, а на самом деле это треш: он 10 пунктов закрывал за 100% времени, остальные закроет, скорее всего также. Это отставание 200%(( Мораль: любые выводы от ИИ - должны подтверждаться РП
Итог: имеем автоматизацию функции администратора проектов. Что логично: автоматизация убирает низкоквалифицированную работу.
Но у меня пока что есть серьезное подозрение за всем этим хайпом и истериками про ИИ: настройка такой модели, которой можно доверять (точные промпты, ограничения, самопроверки) займет никак не меньше времени, что сейчас тратится на создание аналитических дашбордов в Клике или Повер Биай. А хорошие данные должны быть в любом случае :)
Вот и получается что ИИшница - просто пар над супом.
Что не отменяет того, что какие то прикольные идеи подкидывать она может.
Нужны точные нормативы и стандарты. Для производства и стройки будет работать, наверное. Для ИТ - все эти предварительные оценки - вилами по воде.
Любопытно подумать, что сделать, чтобы так не было, но неохота. Зато ИИ учен убежденно наврет и про риски и про перспективы )
Не, как еще одну туповатую голову его использовать полезно в таких случаях. Я сам постоянно советуюсь. Иногда накидывает прикольное. Но как предсказание и оценка, имеющая вес - не.
Есть Software Lifecycle, а есть Software development lifecycle. Есть цикл производства автомобиля , а есть ЖЦ самого автомобиля. Говорить, что это одно и тоже - некорректно. Даже если это сказано в вики.
В РФ есть стандарт на создание АС, это 34 гГОСТ и там четко прописаны стадии
Эт раз.
Два: 12207 -2010 не содержит очередности, там вообще принцип: мы описали процессы, а про последовательность - сами решайте. А вот в предыдущем она была.
Выяснять, что в 80х кто написал, по моему - пустое занятие.
А вот есть свеженький ГОСТ Р 54869 где планирование идет 2м шагом, как раз между инициацией и исполнением. И планирование там расписано в том числе, как планирование содержания проекта - то есть фаза анализа и планирования связаны.
мы сами настроили систему под себя, тогда как конкурента должны были настраивать интеграторы vs на настройку ушло 9 мес - такое себе экономическое сравнение. Может, интегратором оказалось бы даже дешевле.
Статья не содержит описания преимуществ YG перед другими, она содержит описание преимущества автоматизированного процесса управления vs хаоса, состоящего из экселек.
Обожаю вот это менеджерское "менеджеры теперь не тратят 2 часа в день..." и "экономия более 500 часов, выраженная в деньгах" - любопытно поглядеть на процесс, который до внедрения жрал 2 часа в день (10/неделю). Я прекрасно понимаю, как давалась оценка и понимаю, что, скорее всего, она ничем не подтверждена. При всем уважении, такое надо проговаривать четче: было/стало, на чем точно экономия
Эффективность команд выросла на 18% - коллеги, для начала надо дать определение "эффективности, а потом рассказать методику замера. Даже google в своем исследовании этого не смог. Вы - даете просто цифрой. Нехорошо.
но считаю ее однобокой: автор утверждает, что SDLC, как он был определен давно, утратил смысл, предлагая вместо него V-model, которая выглядит точно также как и SDLC - просто квадратики назвали чуть иначе и детализировали )
Но есть несколько но
Автор ссылается на \ссылку вики про system development LC, и верно все говорит, но говорит про ЖЦ разработки системы, а не ПО. Разработка ПО может быть циклична (привет скраму эджайлу и всем гибридам), более того - она давно циклична и полностью подчиняется что картинке, что v модели - тут вопрос детализации
Автор говорит о том, как важно смотреть на пользователей (интеграция продукта в жизнь людей). Но тут смешение понятия: SDLC - это цикл разработки ПО, а интеграция продукта в жизнь людей - это уже Жизненный цикл продукта, в который SDLC входит, но которым не исчерпывается.
стандарт ISO/IEC/IEEE 12207 определяет ЖЦ разработки ПО по фазам:
Анализ требований: Уточнение User Story на планировании спринта (Sprint Planning) и груминге (Refinement).
Проектирование и дизайн: Обсуждение архитектуры фичи внутри команды перед кодированием.
Разработка (Кодирование): Написание кода разработчиками.
Тестирование (Верификация): QA-инженерия, автотесты и Code Review внутри спринта.
Внедрение (Эксплуатация / Релиз): Поставка готового инкремента в конце спринта (CI/CD).
Поддержка и обратная связь: Демонстрация на Sprint Review и разбор полетов на Ретроспективе.
то есть все тоже самое что и в V-model
итого: выглядит так, что статья ни о чем.
Почему я сюда попал и докопался: искал статью про то что такое SDLC которое даже wiki не описывает (там software development LC по ссылке приводит к system development lifecycle ведет, что приводит как раз к терминологической каше)
Свести - не равно выставить комфортный срок. Если у вас есть опыт проектного управления или вы руководили РП, вы поймете , о чем я.
Комфортно для РП не равно комфортно для бизнеса. Как то один продакт Яндекса сказала что ее best practice - вообще не называть сроки заказчику, потому что они все равно поедут. А полгода назад я был на встрече где были РПО / СТО Сбера, Авито и Альфы и говорили, что они умеют в продукт но очень страдают, что перестало получаться в сроки.
Не бизнес должен подстраиваться под РП, а наоборот. Это важно.
"Не умеешь показывать ценность результата" - если руководству неясна ценность деятельности сотрудника, а он ее все равно делает - это нехорошо :) Нужно или вначале доказать и тогда ОК, или не делать вообще.
Тут решается точно также, как и в статье написано. И ноги - последний шаг, а не первый (потому что такое встречается достаточно часто и менять места при появлении проблем - для меня так себе стратегия. Я ее тоже пробовал, и считаю неэффективной).
Во-первых, "сложно фиксировать" и невозможно - большая разница. Есть очень мало вещей, которые вообще никак не отфиксировать, зато есть мое, как исполнителя, желание, чтобы "мне поставили официально". Задачи могут ставиться на совещаниях, в курилке, просто как идеи. Отвественность за фиксацию - на исполнителе, все так.
Во-вторых, по определию руководитель должен быть немного больше Е по Адизесу, чем исполнители. А значит, исполнителям будет казаться, что он переобувается "на лету". Так и есть, просто потому что его задача - генерить идеи. И хорошо, если из них выживет половина. Статистика стартапов - 1/10, а то и меньше. Так что тем, кому кажется, что шеф несет хрень - стоит перечитать этот абзац.
В-третьих, от руководителя скажу: бывает так, что сотрудник пытается регламентировать процесс, который фиг регламентируешь. причем шеф это видит, а сотрудник - нет. Спорить про это бессмысленно - сотруднику конечно виднее, как надо рулить )) Еще бывает, как в статье, говоришь ему, как делать, а он кивает и делает вообще иначе, не то не там и не так. А потом смотрит и кивает, как он не прав. И че с ним делать? :))
когда я писал в контексте ИИшки о том, почему не взлетели CASE средства программирования в конце 90х-начале нулевых, вспомнил, что главным стоппером там стала необходимость создания и поддержки такого объема документации, что это стало слишком дорого.
проще стало нанять снова кожаных, чтобы они продолжали кодить, чем поддерживать реально полную документацию по которой CASE система напишет код.
То есть тезис "полноты" документации может быть душно оспорен и может обсуждаться.
но это не умаляет важности тезисов статьи для jun-mid и местами sinor менеджеров.
не все знают всех приемов работы с требованиями, перечисленными в статье, так что писать про такое - крайне полезно
это две крайности. обычно голодный исполнитель готов начать работать без контракта но под обещания, которым он поверит. А далее подписывается контракт, к которому приложением идет ТЗ.
А уж какой степени детализации будет то ТЗ - это история индивидуальная.
потому что теории много, а вот как это применять - фиг его знает. Как я всем говорю - вода камень точит, но где эта грань, когда пора прекращать точить камень и просто сменить место работы на то, где руководство потенциально более гибкое?
короче любопытная тема, интересно опытного человека послушать
История хорошая и важная.И действительно, имеет место быть, по моему опыту.
Но есть пара нюансов:
психологическая безопасность крайне завязана на личность лидера команды. Лидер - на своего руководителя, а они - на СЕО компании. Если СЕО манипулятор, не признает свои ошибки и тд и тп - никакой бирюзы на всех остальных уровнях ждать не стоит. Итого - речь не про лидера, а про КУЛЬТУРУ компании.
Культура компаний в РФ, несмотря на все декларации - в большинстве или HiPPO типа или вовсе дисфункциональная - в меру психологической зрелости СЕО. Это ни хорошо, ни плохо - просто такая стадия развития.
продавать "культуру" СЕО не выйдет , ему культура по барабану, его интересуют бабки. Следовательно, надо продавать основной вывод проекта Аристотель: "чем больше культуры в твоей команде, тем больше бабок ты заработаешь" . Но и тут мы столкнемся с тем, что "отпускать" мы предлагаем часто тем, кто отпускать не умеет, а хочет всего и все контролировать сам (тем более, что поводов для этого и правда много)
Короче - слова то красивые, но как практически применять - вопрос ))
Я люблю ITIL, нежно. Сервисный подход я пропогандировал и пропогандирую всегда, хоте сертификата у меня нет. Больше - я вижу, насколько сервисный и продуктовый, ныне модный, подходы похожи. По сути IT Product manager - это IT Service manager by ITIL. Короче - хорошая библиотека.
Статья не несет полезной нагрузки, кроме того что вышел ITIL5. Чем именно отличается, что было , что стало - нету. Мне, как ITIL practioner (причем реальный а не по серту) очень интересно: почему 10 лет прошло, почему от конкретных фреймов - одни общие слова? И тд, но ничего этого нет.
Есть общие слова, явно made by AI. Для меня это неуважение. Промпт вида: "знаю что вышел новый ITIL v5, расскажи, чем он отличается от прошлых версий, что нового, что осталось старого, структурируй по разделам, текст должен быть на 4 минуты чтения + сделай 2 картинки на тему статьи" - я и сам могу вбить хоть в гпт, хоть в джемини, хоть в клод...
Все выглядит стройно и красиво, но у меня вопрос к критериям оценки. А точнее, не к ним даже, а к тому кто оценивал и кто решал по полноте и достоверности ответа?
Тесты и правда симпатичные, но разные РП с разным опытом дадут разные оценки за один и тот же ответ: что джуну будет "превосходно", синьор воспримет как "шляпа, но сойдет", а его руководитель - как просто шляпу.
Судьи кто?
А ведь на этом построены все остальные выводы, так что вопрос выглядит критичным
Я пишу комментарии, статьи на Хабре и даже канал веду не самоутверждения ради, а обсуждения для. Другое дело, готовы ли вы привести такие факты, которые смогут поколебать мой информационный пузырь, основанный на личном опыте и внедрений и консалтинга?
А то пока что я слышал очень много красивых слов. Реальных примеров видел немного и по трудозатратам и достоверности у меня существенные вопросы.
Впрочем, допускаю, что тут может быть не только хайп. Так что рассказывайте, если время есть :)
ИИ врет. Причем красиво и убежденно, причем даже тогда, когда говоришь ему не врать. Причем в любой модификации и версии. Причем, за последние 2 года что лично я его ежедневно использую, он меньше врать не стал. Джемини врет вообще искушенно, а когда ловишь - очень мило и искренне извиняется и снова врет.
Мораль: любой статус собранный ИИ - под вопросом ((
ИИ фиг пойми как оценивает критичность. Согласен, большой соблазн просто скормить джиру конфлю и трекер, попросить сделать магию и поверить в ее результат. Это просто, красиво, инновационно, и потом можно идти гонять латте в кофепойнте с коллегушками. Но даже на скрине автора меня резануло вот такое (понимаю, просто пример, может быть как угодно, но я , как руководитель, всегда сильно напрягаюсь на такое):
"в работе"?! Да я за такое по башке РП дам от души. Это классическая жопа: РП думает что все более-менее, всего на 2 дня просрочено, а на самом деле это треш: он 10 пунктов закрывал за 100% времени, остальные закроет, скорее всего также. Это отставание 200%((
Мораль: любые выводы от ИИ - должны подтверждаться РП
Итог: имеем автоматизацию функции администратора проектов. Что логично: автоматизация убирает низкоквалифицированную работу.
Но у меня пока что есть серьезное подозрение за всем этим хайпом и истериками про ИИ: настройка такой модели, которой можно доверять (точные промпты, ограничения, самопроверки) займет никак не меньше времени, что сейчас тратится на создание аналитических дашбордов в Клике или Повер Биай. А хорошие данные должны быть в любом случае :)
Вот и получается что ИИшница - просто пар над супом.
Что не отменяет того, что какие то прикольные идеи подкидывать она может.
ихнее, ихнее))
а потом разрабы тихонько матеряться от чайка менеджеров, которые проектное управление спутали с администрированием проекта.
Нужны точные нормативы и стандарты. Для производства и стройки будет работать, наверное. Для ИТ - все эти предварительные оценки - вилами по воде.
Любопытно подумать, что сделать, чтобы так не было, но неохота. Зато ИИ учен убежденно наврет и про риски и про перспективы )
Не, как еще одну туповатую голову его использовать полезно в таких случаях. Я сам постоянно советуюсь. Иногда накидывает прикольное. Но как предсказание и оценка, имеющая вес - не.
Есть Software Lifecycle, а есть Software development lifecycle.
Есть цикл производства автомобиля , а есть ЖЦ самого автомобиля. Говорить, что это одно и тоже - некорректно. Даже если это сказано в вики.
В РФ есть стандарт на создание АС, это 34 гГОСТ и там четко прописаны стадии
Эт раз.
Два: 12207 -2010 не содержит очередности, там вообще принцип: мы описали процессы, а про последовательность - сами решайте. А вот в предыдущем она была.
Выяснять, что в 80х кто написал, по моему - пустое занятие.
А вот есть свеженький ГОСТ Р 54869 где планирование идет 2м шагом, как раз между инициацией и исполнением. И планирование там расписано в том числе, как планирование содержания проекта - то есть фаза анализа и планирования связаны.
сыро-сыро (
мы сами настроили систему под себя, тогда как конкурента должны были настраивать интеграторы vs на настройку ушло 9 мес - такое себе экономическое сравнение. Может, интегратором оказалось бы даже дешевле.
Статья не содержит описания преимуществ YG перед другими, она содержит описание преимущества автоматизированного процесса управления vs хаоса, состоящего из экселек.
Обожаю вот это менеджерское "менеджеры теперь не тратят 2 часа в день..." и "экономия более 500 часов, выраженная в деньгах" - любопытно поглядеть на процесс, который до внедрения жрал 2 часа в день (10/неделю). Я прекрасно понимаю, как давалась оценка и понимаю, что, скорее всего, она ничем не подтверждена. При всем уважении, такое надо проговаривать четче: было/стало, на чем точно экономия
Эффективность команд выросла на 18% - коллеги, для начала надо дать определение "эффективности, а потом рассказать методику замера. Даже google в своем исследовании этого не смог. Вы - даете просто цифрой. Нехорошо.
Итог - статья рекламная.
статья ищется по ключу "что такое sdlc?"
но считаю ее однобокой: автор утверждает, что SDLC, как он был определен давно, утратил смысл, предлагая вместо него V-model, которая выглядит точно также как и SDLC - просто квадратики назвали чуть иначе и детализировали )
Но есть несколько но
Автор ссылается на \ссылку вики про system development LC, и верно все говорит, но говорит про ЖЦ разработки системы, а не ПО. Разработка ПО может быть циклична (привет скраму эджайлу и всем гибридам), более того - она давно циклична и полностью подчиняется что картинке, что v модели - тут вопрос детализации
Автор говорит о том, как важно смотреть на пользователей (интеграция продукта в жизнь людей). Но тут смешение понятия: SDLC - это цикл разработки ПО, а интеграция продукта в жизнь людей - это уже Жизненный цикл продукта, в который SDLC входит, но которым не исчерпывается.
стандарт ISO/IEC/IEEE 12207 определяет ЖЦ разработки ПО по фазам:
Анализ требований: Уточнение User Story на планировании спринта (Sprint Planning) и груминге (Refinement).
Проектирование и дизайн: Обсуждение архитектуры фичи внутри команды перед кодированием.
Разработка (Кодирование): Написание кода разработчиками.
Тестирование (Верификация): QA-инженерия, автотесты и Code Review внутри спринта.
Внедрение (Эксплуатация / Релиз): Поставка готового инкремента в конце спринта (CI/CD).
Поддержка и обратная связь: Демонстрация на Sprint Review и разбор полетов на Ретроспективе.
то есть все тоже самое что и в V-model
итого: выглядит так, что статья ни о чем.
Почему я сюда попал и докопался: искал статью про то что такое SDLC которое даже wiki не описывает (там software development LC по ссылке приводит к system development lifecycle ведет, что приводит как раз к терминологической каше)
Думал тут мне разъяснят, но нет :)
Мораль: напишу статью сам ))
Свести - не равно выставить комфортный срок. Если у вас есть опыт проектного управления или вы руководили РП, вы поймете , о чем я.
Комфортно для РП не равно комфортно для бизнеса. Как то один продакт Яндекса сказала что ее best practice - вообще не называть сроки заказчику, потому что они все равно поедут. А полгода назад я был на встрече где были РПО / СТО Сбера, Авито и Альфы и говорили, что они умеют в продукт но очень страдают, что перестало получаться в сроки.
Не бизнес должен подстраиваться под РП, а наоборот. Это важно.
"Не умеешь показывать ценность результата" - если руководству неясна ценность деятельности сотрудника, а он ее все равно делает - это нехорошо :)
Нужно или вначале доказать и тогда ОК, или не делать вообще.
Тут решается точно также, как и в статье написано. И ноги - последний шаг, а не первый (потому что такое встречается достаточно часто и менять места при появлении проблем - для меня так себе стратегия. Я ее тоже пробовал, и считаю неэффективной).
Во-первых, "сложно фиксировать" и невозможно - большая разница. Есть очень мало вещей, которые вообще никак не отфиксировать, зато есть мое, как исполнителя, желание, чтобы "мне поставили официально". Задачи могут ставиться на совещаниях, в курилке, просто как идеи. Отвественность за фиксацию - на исполнителе, все так.
Во-вторых, по определию руководитель должен быть немного больше Е по Адизесу, чем исполнители. А значит, исполнителям будет казаться, что он переобувается "на лету". Так и есть, просто потому что его задача - генерить идеи. И хорошо, если из них выживет половина. Статистика стартапов - 1/10, а то и меньше. Так что тем, кому кажется, что шеф несет хрень - стоит перечитать этот абзац.
В-третьих, от руководителя скажу: бывает так, что сотрудник пытается регламентировать процесс, который фиг регламентируешь. причем шеф это видит, а сотрудник - нет. Спорить про это бессмысленно - сотруднику конечно виднее, как надо рулить ))
Еще бывает, как в статье, говоришь ему, как делать, а он кивает и делает вообще иначе, не то не там и не так. А потом смотрит и кивает, как он не прав. И че с ним делать? :))
кстати да.
когда я писал в контексте ИИшки о том, почему не взлетели CASE средства программирования в конце 90х-начале нулевых, вспомнил, что главным стоппером там стала необходимость создания и поддержки такого объема документации, что это стало слишком дорого.
проще стало нанять снова кожаных, чтобы они продолжали кодить, чем поддерживать реально полную документацию по которой CASE система напишет код.
То есть тезис "полноты" документации может быть душно оспорен и может обсуждаться.
но это не умаляет важности тезисов статьи для jun-mid и местами sinor менеджеров.
не все знают всех приемов работы с требованиями, перечисленными в статье, так что писать про такое - крайне полезно
это две крайности. обычно голодный исполнитель готов начать работать без контракта но под обещания, которым он поверит. А далее подписывается контракт, к которому приложением идет ТЗ.
А уж какой степени детализации будет то ТЗ - это история индивидуальная.
По сути спасибо огромное за разбор и вообще все познавательно.
немного понимая логику работы, допускаю, что там есть мысли через макс делать обновления сервисов, запрещенных в аппсторе, а это апк.
то есть не злой умысел, а мысли норм, просто не очень профи и все торопятся.
любопытно, пишите, интересно почитать.
потому что теории много, а вот как это применять - фиг его знает. Как я всем говорю - вода камень точит, но где эта грань, когда пора прекращать точить камень и просто сменить место работы на то, где руководство потенциально более гибкое?
короче любопытная тема, интересно опытного человека послушать
История хорошая и важная.И действительно, имеет место быть, по моему опыту.
Но есть пара нюансов:
психологическая безопасность крайне завязана на личность лидера команды. Лидер - на своего руководителя, а они - на СЕО компании. Если СЕО манипулятор, не признает свои ошибки и тд и тп - никакой бирюзы на всех остальных уровнях ждать не стоит. Итого - речь не про лидера, а про КУЛЬТУРУ компании.
Культура компаний в РФ, несмотря на все декларации - в большинстве или HiPPO типа или вовсе дисфункциональная - в меру психологической зрелости СЕО. Это ни хорошо, ни плохо - просто такая стадия развития.
продавать "культуру" СЕО не выйдет , ему культура по барабану, его интересуют бабки. Следовательно, надо продавать основной вывод проекта Аристотель: "чем больше культуры в твоей команде, тем больше бабок ты заработаешь" . Но и тут мы столкнемся с тем, что "отпускать" мы предлагаем часто тем, кто отпускать не умеет, а хочет всего и все контролировать сам (тем более, что поводов для этого и правда много)
Короче - слова то красивые, но как практически применять - вопрос ))
ага, норм, ценю за честность, спасибо!
Если уж совсем соломоново, то записать снепшот на диск, разрезать его болгаркой пополам и каждому отдать по половине =)
Вижу что автор отвечает, я тогда скажу
Я люблю ITIL, нежно. Сервисный подход я пропогандировал и пропогандирую всегда, хоте сертификата у меня нет. Больше - я вижу, насколько сервисный и продуктовый, ныне модный, подходы похожи. По сути IT Product manager - это IT Service manager by ITIL. Короче - хорошая библиотека.
Статья не несет полезной нагрузки, кроме того что вышел ITIL5. Чем именно отличается, что было , что стало - нету. Мне, как ITIL practioner (причем реальный а не по серту) очень интересно: почему 10 лет прошло, почему от конкретных фреймов - одни общие слова? И тд, но ничего этого нет.
Есть общие слова, явно made by AI. Для меня это неуважение. Промпт вида: "знаю что вышел новый ITIL v5, расскажи, чем он отличается от прошлых версий, что нового, что осталось старого, структурируй по разделам, текст должен быть на 4 минуты чтения + сделай 2 картинки на тему статьи" - я и сам могу вбить хоть в гпт, хоть в джемини, хоть в клод...
Я говорил тут про другое, вы неправильно поняли мой тезис.