Agile это очередная попытка выстроить отношения (причем экономические) между Заказчиком и Исполнителем. Автор рассмотрел только со стороны интереса Исполнителя, мол ему интересно работать вечно, постоянно получая свои бонусы за работу. При этом, в начале статьи очень верные написал слова…
"
все руководители во все времена использовали гибкую методику для создания своего внутреннего (на свой страх и риск) продукта потому, что:
достаточно компетентны для проектирования конечного результата;
достаточно компетентны для контроля за ходом процесса;
имеют достаточно власти над подчинёнными участниками процесса;
соотношение срока, стоимости и качества работ не являются для них догмой и могут при необходимости пересматриваться (так как «сам себе хозяин»);
а самое главное — и конечный результат и процесс его достижения находится в одних руках, и преследуют один коммерческий интерес.....
Важным является компетентность людей, которые МОГУТ гарантировать сроки и определнное качество. Почему же в течении многих лет, все активнее проталкивается идея гибких технологий на смену классической.
На мой взгляд, нежелание заказчика платить за «опытные образцы». Мы все прекрасно понимаем, что сфера программной разработки все время находится для заказчика на стадии кастомизации. Он же не желает купить то что есть, потому что у него почти все также только есть несколько нюансов. Однако Исполнителю хочется продать, заработать. Вот на этом канате финансовых интересов и начинает работать механизм торговли неведомым, но очень красивым и нужным результатом. Исполнитель естественно пытается себя оградить от «лишней» работы, а Заказчик считает, что все пробные варианты. Демо, которые устраивает Исполнитель — почему-то считается, что если я как Заказчик не принял, потому что посмотрев, я понял, что надо изменения внести — я трактую как неверно понятые Исполнителем требования. И истинно считаю, что и платить за это не должен. Встречаются 2 полюса интереса. Исполнителю кажется, что он работает вечно и бесплатно, Заказчику кажется, что вот же архаровцы — хорошо устроились. По часам с меня деньги стригут, а то, что я хочу — сделать не могут. Реальность же такова, что сущности ИТ решений иногда сложно донести до Заказчику, слишком разные понятия в голове у людей из разных предметных областей. И вот тут как раз велика роль руководителя проекта со стороны Исполнителя, который может с бизнесом разговаривать на его языке, а с проектной командой на их языке. НО! Если у заказчика только фараон, и отсутствует виночерпий ВЕЛИКИ риски врюхаться в долгострой и неплатежи. А agile — лишь способ представления грамотно выстроенной системы работы над проектом, которая увы теряет свое качество ввиду отсутствия компетентности на разных уровнях взаимодействия Заказчика и Исполнителя.
Спасибо за статью.
все руководители во все времена использовали гибкую методику для создания своего внутреннего (на свой страх и риск) продукта потому, что:
Важным является компетентность людей, которые МОГУТ гарантировать сроки и определнное качество. Почему же в течении многих лет, все активнее проталкивается идея гибких технологий на смену классической.
На мой взгляд, нежелание заказчика платить за «опытные образцы». Мы все прекрасно понимаем, что сфера программной разработки все время находится для заказчика на стадии кастомизации. Он же не желает купить то что есть, потому что у него почти все также только есть несколько нюансов. Однако Исполнителю хочется продать, заработать. Вот на этом канате финансовых интересов и начинает работать механизм торговли неведомым, но очень красивым и нужным результатом. Исполнитель естественно пытается себя оградить от «лишней» работы, а Заказчик считает, что все пробные варианты. Демо, которые устраивает Исполнитель — почему-то считается, что если я как Заказчик не принял, потому что посмотрев, я понял, что надо изменения внести — я трактую как неверно понятые Исполнителем требования. И истинно считаю, что и платить за это не должен. Встречаются 2 полюса интереса. Исполнителю кажется, что он работает вечно и бесплатно, Заказчику кажется, что вот же архаровцы — хорошо устроились. По часам с меня деньги стригут, а то, что я хочу — сделать не могут. Реальность же такова, что сущности ИТ решений иногда сложно донести до Заказчику, слишком разные понятия в голове у людей из разных предметных областей. И вот тут как раз велика роль руководителя проекта со стороны Исполнителя, который может с бизнесом разговаривать на его языке, а с проектной командой на их языке. НО! Если у заказчика только фараон, и отсутствует виночерпий ВЕЛИКИ риски врюхаться в долгострой и неплатежи. А agile — лишь способ представления грамотно выстроенной системы работы над проектом, которая увы теряет свое качество ввиду отсутствия компетентности на разных уровнях взаимодействия Заказчика и Исполнителя.
Спасибо за статью.