Так наиболее ярко проблемы управления видны в проектном управлении и это иллюстрирует тот факт, что среднее удорожание проектов в РФ составляет более 50%, а 83.5% проектов в РФ подорожали более чем на 10% (Статья "Удорожание стоимости инвестиционно-строительных проектов" Ушакова, Вьонг).
Если одновременно учесть, что большинство крупных проектов иностранными транснациональными корпорациями, в противоположность общероссийским трендам, реализуются в срок и в рамках бюджетов
1. насколько понимаю, указанная статья оперирует 30тью избранными произвольно проектами. Всего 30 - как на этом можно строить выводы?
2. по открытым данным PMI (pulse of management) за 20-25 годы в срок завершаются 50-60% проектов и в бюджет 60-70: цифры примерные, по опросам, зато выборка побольше.
после этого все дальнейшие выводы не читаю, давайте с этим разберемся, потому что у вас достаточно смелое заявление (в РФ проекты срываются на 50% в среднем, а за бугром все замечательно). Мой тезис - почти тоже самое. Любопытно поспорить с цифрами.
Я конечно именно про ИТ, на PMI смотрит, например , на все проектное управление, в целом.
вмешаюсь в ваш разговор, потому что интересный тезис и я согласен в чем-то с обоими. но с вашим визави побольше, потому что знаю про серьезную проблему перехода из небольшого ИТ бизнеса в средний (от 0.5 млрд - к ярду выручки, условно). проблема классическая "как СЕО вылезти из операционки".
Если это получается - компания растет и масштабируется.
Если нет - барахтается на этой границе, потому что СЕО не успевает делать все, а делегировать балбеса не получается.
И да, я лично видел, как это бывает (потому что был рядом с таким СЕО, даже не одним), и знаю , почему.
Наверное, рулит баланс: нельзя полностью отпускать контроль и отдавать компанию эффективным менеджерам. Нельзя микроменеджить все. Надо искать середину.
Цифровизация лучше ее отсутствия, в 2026 по-моему уже все СЕО это понимают. В айтишке я других не видел.
Задача уже - как внутренний зоопарк заставить работать? :)
По первой части замечаний нет - потому что все очевидно. Неочевидное начнется после внедрения любой ИСУП, когда выяснится что мало купить и дать доступ.
мало даже собрать требования и реализовать в системе. Надо научить, пересадить и поддержать в переходный период. А дальше надо подстраивать ее под текущую инфраструктуру компании. И вот тут начинаются сюрпризы вида:
каждый чих - сложно и требует доработки/кастомизации
подрядчиков, которые могут недорого доработать мало/нет
система что-то умеет, а что-то нет и надо ждать обновления продукта (это доолго)
взаимодействие с поддержкой продукта (где то быстрые, где то овощи)
и тп
А вот по списку ИСУП конечно наблюдается каша. Потому что их явно надо бить на Энтерпрайз (Адванта, 1С, ЕВА), SMB (Б24, Эльма) и вообще - трекеры (Яшка, Тиметта). Потому что например яшка вообще не ИСУП (почему надеюсь, объяснять коллегам не нужно).
Про Директум ничего не знаю, так что сказать нечего.
Про проекты тейк в конце неясен: говорили про весь российский бизнес, куча ссылок (кстати интересных, спасибо, пойду почитаю все это), а потом "пожаротушение в разработке продуктов" - ну это о чем было?
В конце вывода сильного не хватает. А вывод прост. Российский бизнес такой не просто так, это системное следствие из жизни страны. Тее нафиг не нужна стратегия, когда твоя задача - выжить в ближайшие год-два.
И это касается не только политики , которая прямо влияет на экономику, ключевую ставку и тп. Есть замечательный ВБ, где все начали делать бизнес, а теперь ВБ всех селлеров душит повышением ставок. В РФ исторически горизонт планирования - 3 года. По моему личному опыту ни один СЕО дальше не смотрит, ибо зачем?
Отсюда - нежелание в долгие инвестиции (а это бизнес процессы, которые в ИТ выстраиваются годами)
Отсюда же - склонность к персонализации управления. Все недостатки выше есть. Но есть и достоинста
персонализация управления = быстрые решения
кумовство = СЕО полностью доверяет команде в сложный момент, никто с корабля не сбежит и за бонус не обманет
микроменеджмент - вынужденная смазка в отсутствие времени на оцифровку процессов
Можно ли чтото изменить? Я считаю, что быстро - нет. События 22-26 годов только подтверждают верность выбранной модели управления для РФ , увы.
Я не скажу, что мне это нравится, но я в текущих реалиях другого выхода не вижу
а) использовал достаточно много ИИ для генерации данного текста
б) манипулирует цифрами (он или ИИ - неважно, считаю , что автор , ибо от его имени).
В тексте манипуляции вида:
"Менеджеры больше не нужны", а потом
у пользователей Copilot доля работы над кодом выросла на 5%, а доля управленческих задач снизилась на 10%. (на 10% и Больше не нужны - немного разное)
обесценивают базовую идею, что ИИ убирает попкин администраторский труд, оставляя менеджерам то, за что им всегда и платили - организацию работы и смазку механизма компании.
Давайте так: менеджер в самоорганизующейся команде вообще не нужен. РП просто излишний: планы есть, оценки есть - бери и делай.
Но все сроки едут вправо почему то.
И дело не в отчетах или администрировании. Дело в организации труда человеков. Автоматизировать рутинные функции - да.
критический путь РП знает итак, и этой фичей не пользовался никогда ни я , ни один РП вокруг меня или мои сотрудники
раскрашивать таски от статуса - с ума сойдешь от ганта если у тебя wbs на сотню задач хотябы. Тем более - кто эти статусы обновляет - сам РП? нуну)
поиск по задаче - nice to have но без него норм.
что реально важно писать лень, ибо я сам создавал ИСУПку с нудя как продакт и там 7 требованиями не обойдешься, потому что есть незаметные но крайне важные требования к механике, есть логика , есть вопросы типа "а надо ли в базе считать несколько исполнителей на таску и % занятости, а что с пулом ресурсов и ставками и тд и тп)
Все выглядит стройно и красиво, но у меня вопрос к критериям оценки. А точнее, не к ним даже, а к тому кто оценивал и кто решал по полноте и достоверности ответа?
Тесты и правда симпатичные, но разные РП с разным опытом дадут разные оценки за один и тот же ответ: что джуну будет "превосходно", синьор воспримет как "шляпа, но сойдет", а его руководитель - как просто шляпу.
Судьи кто?
А ведь на этом построены все остальные выводы, так что вопрос выглядит критичным
Я пишу комментарии, статьи на Хабре и даже канал веду не самоутверждения ради, а обсуждения для. Другое дело, готовы ли вы привести такие факты, которые смогут поколебать мой информационный пузырь, основанный на личном опыте и внедрений и консалтинга?
А то пока что я слышал очень много красивых слов. Реальных примеров видел немного и по трудозатратам и достоверности у меня существенные вопросы.
Впрочем, допускаю, что тут может быть не только хайп. Так что рассказывайте, если время есть :)
ИИ врет. Причем красиво и убежденно, причем даже тогда, когда говоришь ему не врать. Причем в любой модификации и версии. Причем, за последние 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, а то и меньше. Так что тем, кому кажется, что шеф несет хрень - стоит перечитать этот абзац.
В-третьих, от руководителя скажу: бывает так, что сотрудник пытается регламентировать процесс, который фиг регламентируешь. причем шеф это видит, а сотрудник - нет. Спорить про это бессмысленно - сотруднику конечно виднее, как надо рулить )) Еще бывает, как в статье, говоришь ему, как делать, а он кивает и делает вообще иначе, не то не там и не так. А потом смотрит и кивает, как он не прав. И че с ним делать? :))
Резануло вот это
Так наиболее ярко проблемы управления видны в проектном управлении и это иллюстрирует тот факт, что среднее удорожание проектов в РФ составляет более 50%, а 83.5% проектов в РФ подорожали более чем на 10% (Статья "Удорожание стоимости инвестиционно-строительных проектов" Ушакова, Вьонг).
Если одновременно учесть, что большинство крупных проектов иностранными транснациональными корпорациями, в противоположность общероссийским трендам, реализуются в срок и в рамках бюджетов
1. насколько понимаю, указанная статья оперирует 30тью избранными произвольно проектами. Всего 30 - как на этом можно строить выводы?
2. по открытым данным PMI (pulse of management) за 20-25 годы в срок завершаются 50-60% проектов и в бюджет 60-70: цифры примерные, по опросам, зато выборка побольше.
после этого все дальнейшие выводы не читаю, давайте с этим разберемся, потому что у вас достаточно смелое заявление (в РФ проекты срываются на 50% в среднем, а за бугром все замечательно). Мой тезис - почти тоже самое. Любопытно поспорить с цифрами.
Я конечно именно про ИТ, на PMI смотрит, например , на все проектное управление, в целом.
кстати отличное замечание, да :)
вмешаюсь в ваш разговор, потому что интересный тезис и я согласен в чем-то с обоими. но с вашим визави побольше, потому что знаю про серьезную проблему перехода из небольшого ИТ бизнеса в средний (от 0.5 млрд - к ярду выручки, условно). проблема классическая "как СЕО вылезти из операционки".
Если это получается - компания растет и масштабируется.
Если нет - барахтается на этой границе, потому что СЕО не успевает делать все, а делегировать балбеса не получается.
И да, я лично видел, как это бывает (потому что был рядом с таким СЕО, даже не одним), и знаю , почему.
Наверное, рулит баланс: нельзя полностью отпускать контроль и отдавать компанию эффективным менеджерам. Нельзя микроменеджить все. Надо искать середину.
Цифровизация лучше ее отсутствия, в 2026 по-моему уже все СЕО это понимают. В айтишке я других не видел.
Задача уже - как внутренний зоопарк заставить работать? :)
По первой части замечаний нет - потому что все очевидно. Неочевидное начнется после внедрения любой ИСУП, когда выяснится что мало купить и дать доступ.
мало даже собрать требования и реализовать в системе. Надо научить, пересадить и поддержать в переходный период. А дальше надо подстраивать ее под текущую инфраструктуру компании. И вот тут начинаются сюрпризы вида:
каждый чих - сложно и требует доработки/кастомизации
подрядчиков, которые могут недорого доработать мало/нет
система что-то умеет, а что-то нет и надо ждать обновления продукта (это доолго)
взаимодействие с поддержкой продукта (где то быстрые, где то овощи)
и тп
А вот по списку ИСУП конечно наблюдается каша. Потому что их явно надо бить на Энтерпрайз (Адванта, 1С, ЕВА), SMB (Б24, Эльма) и вообще - трекеры (Яшка, Тиметта). Потому что например яшка вообще не ИСУП (почему надеюсь, объяснять коллегам не нужно).
Про Директум ничего не знаю, так что сказать нечего.
Про проекты тейк в конце неясен: говорили про весь российский бизнес, куча ссылок (кстати интересных, спасибо, пойду почитаю все это), а потом "пожаротушение в разработке продуктов" - ну это о чем было?
В конце вывода сильного не хватает. А вывод прост. Российский бизнес такой не просто так, это системное следствие из жизни страны. Тее нафиг не нужна стратегия, когда твоя задача - выжить в ближайшие год-два.
И это касается не только политики , которая прямо влияет на экономику, ключевую ставку и тп. Есть замечательный ВБ, где все начали делать бизнес, а теперь ВБ всех селлеров душит повышением ставок. В РФ исторически горизонт планирования - 3 года. По моему личному опыту ни один СЕО дальше не смотрит, ибо зачем?
Отсюда - нежелание в долгие инвестиции (а это бизнес процессы, которые в ИТ выстраиваются годами)
Отсюда же - склонность к персонализации управления. Все недостатки выше есть. Но есть и достоинста
персонализация управления = быстрые решения
кумовство = СЕО полностью доверяет команде в сложный момент, никто с корабля не сбежит и за бонус не обманет
микроменеджмент - вынужденная смазка в отсутствие времени на оцифровку процессов
Можно ли чтото изменить? Я считаю, что быстро - нет. События 22-26 годов только подтверждают верность выбранной модели управления для РФ , увы.
Я не скажу, что мне это нравится, но я в текущих реалиях другого выхода не вижу
Я считаю что автор
а) использовал достаточно много ИИ для генерации данного текста
б) манипулирует цифрами (он или ИИ - неважно, считаю , что автор , ибо от его имени).
В тексте манипуляции вида:
"Менеджеры больше не нужны", а потом
у пользователей Copilot доля работы над кодом выросла на 5%, а доля управленческих задач снизилась на 10%. (на 10% и Больше не нужны - немного разное)
обесценивают базовую идею, что ИИ убирает попкин администраторский труд, оставляя менеджерам то, за что им всегда и платили - организацию работы и смазку механизма компании.
Давайте так: менеджер в самоорганизующейся команде вообще не нужен. РП просто излишний: планы есть, оценки есть - бери и делай.
Но все сроки едут вправо почему то.
И дело не в отчетах или администрировании. Дело в организации труда человеков. Автоматизировать рутинные функции - да.
Заменить - ну камон, что за дешевый хайп, Каитен?
на самом деле нет)
критический путь РП знает итак, и этой фичей не пользовался никогда ни я , ни один РП вокруг меня или мои сотрудники
раскрашивать таски от статуса - с ума сойдешь от ганта если у тебя wbs на сотню задач хотябы. Тем более - кто эти статусы обновляет - сам РП? нуну)
поиск по задаче - nice to have но без него норм.
что реально важно писать лень, ибо я сам создавал ИСУПку с нудя как продакт и там 7 требованиями не обойдешься, потому что есть незаметные но крайне важные требования к механике, есть логика , есть вопросы типа "а надо ли в базе считать несколько исполнителей на таску и % занятости, а что с пулом ресурсов и ставками и тд и тп)
ну нет, сильно поправлено у вас.
выше отличный пример но есть и еще.
ничего страшного, идея ок, просто стиль у ИИшницы пластмассовый слишком гладкий и однообразный.
описанная система и правда всем нравится, но есть нюанс: почти всегда она или неактуальна или серьезно отстает от жизни = процесса разработки ПО.
Данные вносятся менеджерами
Риски вносятся менеджерами
И вот мы уже вместо реальных данных проецируем руководству "видимость", которую захотел показать РП/РПО.
Все выглядит стройно и красиво, но у меня вопрос к критериям оценки. А точнее, не к ним даже, а к тому кто оценивал и кто решал по полноте и достоверности ответа?
Тесты и правда симпатичные, но разные РП с разным опытом дадут разные оценки за один и тот же ответ: что джуну будет "превосходно", синьор воспримет как "шляпа, но сойдет", а его руководитель - как просто шляпу.
Судьи кто?
А ведь на этом построены все остальные выводы, так что вопрос выглядит критичным
Я пишу комментарии, статьи на Хабре и даже канал веду не самоутверждения ради, а обсуждения для. Другое дело, готовы ли вы привести такие факты, которые смогут поколебать мой информационный пузырь, основанный на личном опыте и внедрений и консалтинга?
А то пока что я слышал очень много красивых слов. Реальных примеров видел немного и по трудозатратам и достоверности у меня существенные вопросы.
Впрочем, допускаю, что тут может быть не только хайп. Так что рассказывайте, если время есть :)
ИИ врет. Причем красиво и убежденно, причем даже тогда, когда говоришь ему не врать. Причем в любой модификации и версии. Причем, за последние 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, а то и меньше. Так что тем, кому кажется, что шеф несет хрень - стоит перечитать этот абзац.
В-третьих, от руководителя скажу: бывает так, что сотрудник пытается регламентировать процесс, который фиг регламентируешь. причем шеф это видит, а сотрудник - нет. Спорить про это бессмысленно - сотруднику конечно виднее, как надо рулить ))
Еще бывает, как в статье, говоришь ему, как делать, а он кивает и делает вообще иначе, не то не там и не так. А потом смотрит и кивает, как он не прав. И че с ним делать? :))