Я добавлю данные госты в статью, спасибо! Единственное, в них всё таки нет ответов на многие вопросы. Если брать ГОСТ Р 58302-2018, то по сути это набор показателей (видов затрат), которые надо учесть при оценки стоимости разработки.
Но например, есть показатель: "Затраты на обучение технического персонала", но нет ответа, а как оценить то эти затраты на обучение. Т.е. ГОСТ описывает, как сделать расчёт разных затрат, но не описывает, как их оценивать.
Спасибо за комментарий. Бесспорно! Если человек уже делал что-то подобное, тогда у него есть опыт и он может увидеть больше других, сделать оценку точнее! Но я бы всё таки рекомендовал даже таким опытным людям делать проверки своих оценок (в рамках расчётного метода). Если это конечно требуется, если такой потребности нет, то конечно нет смысла тратить время и ресурсы на формальные оценки.
Оценку снизу вверх тоже надо повторять, как и любые другие оценки. Т.е. её повторно проводят на разных этапах жизненного цикла разработки системы и этапов проекта.
Хорошим предметом для медитации после завершения проекта являются таблицы экспертной оценки трудоёмкости, заполненные до его начала. С неизбежностью обнаруживается, что, даже угадав общую сумму, промахиваемся мимо отдельных слагаемых, а следовательно, суммирование – это имитация оценки, а не реальный метод.
Связка делает подрядчик, отдаёт исходник клиенту, а деплой у клиента - вообще является организационно сложной и может быть крайне тяжело дать оценку. По моему опыту тут важно выстроить процесс т.е. сделать прозрачными все эти неизвестные факторы и договорится со всеми о правилах работы. Если процесса нет, то и оценка не получится.
Я могу лишь оперировать своим опытом и ответить "Да, работает", но есть нюансы. В самом начале статьи, в разделе базовой теории, я старался разделить понятие "оценка" и "планирование". Когда комментарии вы пишите, что ещё ни один проект не был сделан вовремя, то имеете в виду, что он не был выполнен согласно плана. Но оценка не равна плану, оценка это инструмент, которые помогает в дальнейшем планировать и правильно оценивать реальность этих планов. Плюс переоценку полезно делать на разных этапах жизненного цикла разработки и на разных этапах проекта.
В управлении проектами разработки ПО, планирование является кое чем большим, чем просто правильно сделанная оценка. Например, в гибких подходах разработки планируется каждый спринт и важно не забывать про управление рисками, которые всегда есть. Оценка не может повлиять на то, как команда или компания реагирует на риск. Можно конечно закладывать дополнительно время, но это не правильный путь. В общем, я хочу передать мысль, что важно не путать динамический процесс ведения проектов и оценку, как инструмент.
Цель оценки - не выполнить план, а развеять иллюзии, создать прозрачность. Например, в компании принято считать, что аналитик тратит около 4 ч/ч на подготовку требований для нового отчёта, но когда они посмотрели среднее время выполнения таких задач, то обнаружили, что это время 2.5. ч/ч. Очень простой пример, но на нём можно понять разницу между "интуитивными" оценками и сделанными на базе метрик.
Но вы правы, проекты действительно часто не выполняются вовремя. И на это есть 3 ключевые причины:
Изменение скоупа проекта (т.е. его содержания).
Недооценка объёма работы (сложности) и соответственно временных затрат ( и финансовых тоже).
Плохое планирование и управление рисками.
Хочу добавить ещё один важный важный психологический момент. Написанное ниже является моим субъективным мнением.
Не сделать проект вовремя - это не плохо, если изменился его скоуп, если не учли сложные моменты в начале работы, но сделали потом ретроспективу и вторую часть проекта учитывали ошибки.
Не плохо, даже если руководство до конца не может понять ситуацию на проекте, а управляющий менеджер не может её объяснить, но ищет способы всё обсудить со стейкхолдерами и выровнять баланс проекта. Другими словами поехали сроки, но проект важный и надо доделывать, учитывая прошлый опыт. Это жизнь, так бывает. В крупных и дорогих проектах очень много заинтересованных сторон и может быть очень сложно держать баланс.
Но плохо, если не сделали проект вовремя и забили разбираться почему именно, никому не хватило смелости или ответственности взять на себя вину за ошибки.
Кстати, бюджет закладывают часто не потому, что не могут корректно оценить проект, а скорее из за неточности бизнес целей и нежелания проходить повторную защиту бюджета на разных комитетах (актуально для крупных компаний).
В общем, причин почему проекты не делают вовремя целая куча, а вот успешность проекта измеряется не только сроками, но и разными другими факторами. А оценка, это просто инструмент для создания прозрачности и помощник в управлении. Наверное было бы странным, если бы разработчик (аналитик, архитектор, подставь нужное) не давал оценок по своим задачам...А если оценить очень сложно, для этого и есть описанные в статье методы.
В реальности делают очень по разному, даже используют специальные системы для проведения оценок, всё зависит от отрасли и проектов. Но вы правы, часто происходит именно так, как вы описали.
Спасибо за проявленный интерес, откровенно говоря, я старался описание про архитектуру в статье тоже сильно упростить, но мне казалось важным показать картинку в целом. В любом случае, рад, что тема связки БА с архитектурой корпоративных информационных систем вам тоже интересна. Постараюсь по возможности поделится своим опытом.
Да, согласен, примеры всегда лучше помогают понять. В статья я не хотел останавливаться на проектировании слишком сильно. Но в любом случае пожелание учёл и может быть смогу сделать дополнение.
Да, согласен, не полная формулировка. Я старался сделать статью проще, но этот важный момент упустил, как и нюансы использования ESB для крупных компаний. Правильнее сказать, что сейчас есть 4 основных паттерна: общая база данных, файловый обмен, вызов удаленной процедуры и обмен сообщениями. Кафка это брокер сообщений, а использование брокера часто уже выделяют в отдельный архитектурный паттерн в распределённых системах.
Спасибо за комментарий!
Я добавлю данные госты в статью, спасибо! Единственное, в них всё таки нет ответов на многие вопросы. Если брать ГОСТ Р 58302-2018, то по сути это набор показателей (видов затрат), которые надо учесть при оценки стоимости разработки.
Но например, есть показатель: "Затраты на обучение технического персонала", но нет ответа, а как оценить то эти затраты на обучение. Т.е. ГОСТ описывает, как сделать расчёт разных затрат, но не описывает, как их оценивать.
Спасибо за комментарий. Бесспорно! Если человек уже делал что-то подобное, тогда у него есть опыт и он может увидеть больше других, сделать оценку точнее! Но я бы всё таки рекомендовал даже таким опытным людям делать проверки своих оценок (в рамках расчётного метода). Если это конечно требуется, если такой потребности нет, то конечно нет смысла тратить время и ресурсы на формальные оценки.
Оценку снизу вверх тоже надо повторять, как и любые другие оценки. Т.е. её повторно проводят на разных этапах жизненного цикла разработки системы и этапов проекта.
Это классное дополнение, спасибо!
Да, спасибо за комментарий.
Связка делает подрядчик, отдаёт исходник клиенту, а деплой у клиента - вообще является организационно сложной и может быть крайне тяжело дать оценку. По моему опыту тут важно выстроить процесс т.е. сделать прозрачными все эти неизвестные факторы и договорится со всеми о правилах работы. Если процесса нет, то и оценка не получится.
Спасибо за комментарий.
Я могу лишь оперировать своим опытом и ответить "Да, работает", но есть нюансы. В самом начале статьи, в разделе базовой теории, я старался разделить понятие "оценка" и "планирование". Когда комментарии вы пишите, что ещё ни один проект не был сделан вовремя, то имеете в виду, что он не был выполнен согласно плана. Но оценка не равна плану, оценка это инструмент, которые помогает в дальнейшем планировать и правильно оценивать реальность этих планов. Плюс переоценку полезно делать на разных этапах жизненного цикла разработки и на разных этапах проекта.
В управлении проектами разработки ПО, планирование является кое чем большим, чем просто правильно сделанная оценка. Например, в гибких подходах разработки планируется каждый спринт и важно не забывать про управление рисками, которые всегда есть. Оценка не может повлиять на то, как команда или компания реагирует на риск. Можно конечно закладывать дополнительно время, но это не правильный путь. В общем, я хочу передать мысль, что важно не путать динамический процесс ведения проектов и оценку, как инструмент.
Цель оценки - не выполнить план, а развеять иллюзии, создать прозрачность. Например, в компании принято считать, что аналитик тратит около 4 ч/ч на подготовку требований для нового отчёта, но когда они посмотрели среднее время выполнения таких задач, то обнаружили, что это время 2.5. ч/ч. Очень простой пример, но на нём можно понять разницу между "интуитивными" оценками и сделанными на базе метрик.
Но вы правы, проекты действительно часто не выполняются вовремя. И на это есть 3 ключевые причины:
Изменение скоупа проекта (т.е. его содержания).
Недооценка объёма работы (сложности) и соответственно временных затрат ( и финансовых тоже).
Плохое планирование и управление рисками.
Хочу добавить ещё один важный важный психологический момент. Написанное ниже является моим субъективным мнением.
Не сделать проект вовремя - это не плохо, если изменился его скоуп, если не учли сложные моменты в начале работы, но сделали потом ретроспективу и вторую часть проекта учитывали ошибки.
Не плохо, даже если руководство до конца не может понять ситуацию на проекте, а управляющий менеджер не может её объяснить, но ищет способы всё обсудить со стейкхолдерами и выровнять баланс проекта. Другими словами поехали сроки, но проект важный и надо доделывать, учитывая прошлый опыт. Это жизнь, так бывает. В крупных и дорогих проектах очень много заинтересованных сторон и может быть очень сложно держать баланс.
Но плохо, если не сделали проект вовремя и забили разбираться почему именно, никому не хватило смелости или ответственности взять на себя вину за ошибки.
Кстати, бюджет закладывают часто не потому, что не могут корректно оценить проект, а скорее из за неточности бизнес целей и нежелания проходить повторную защиту бюджета на разных комитетах (актуально для крупных компаний).
В общем, причин почему проекты не делают вовремя целая куча, а вот успешность проекта измеряется не только сроками, но и разными другими факторами. А оценка, это просто инструмент для создания прозрачности и помощник в управлении. Наверное было бы странным, если бы разработчик (аналитик, архитектор, подставь нужное) не давал оценок по своим задачам...А если оценить очень сложно, для этого и есть описанные в статье методы.
Спасибо за комментарий!
В реальности делают очень по разному, даже используют специальные системы для проведения оценок, всё зависит от отрасли и проектов. Но вы правы, часто происходит именно так, как вы описали.
Спасибо за проявленный интерес, откровенно говоря, я старался описание про архитектуру в статье тоже сильно упростить, но мне казалось важным показать картинку в целом. В любом случае, рад, что тема связки БА с архитектурой корпоративных информационных систем вам тоже интересна. Постараюсь по возможности поделится своим опытом.
Да, согласен, примеры всегда лучше помогают понять. В статья я не хотел останавливаться на проектировании слишком сильно. Но в любом случае пожелание учёл и может быть смогу сделать дополнение.
Привет! Спасибо за комментарий.
Да, согласен, не полная формулировка. Я старался сделать статью проще, но этот важный момент упустил, как и нюансы использования ESB для крупных компаний.
Правильнее сказать, что сейчас есть 4 основных паттерна: общая база данных, файловый обмен, вызов удаленной процедуры и обмен сообщениями. Кафка это брокер сообщений, а использование брокера часто уже выделяют в отдельный архитектурный паттерн в распределённых системах.